Work Management - A Job's Life

The life of a simple batch job begins when you submit it to the system. The job is then sent to a job queue where it waits to enter a subsystem where it can run. After the job moves to the subsystem it is allocated memory in which to run. The printer output file (also called spooled files) is then sent to the output queue to await further instruction on what to do (for example, printing). While not every job follows this exact path, you can better understand how other work is completed on the system by learning more about this typical job life cycle.

Submit the job → Job enters the job queue → Job enters the subsystem → The memory pool allocates memory to the subsystem → The job finishes and moves to the output queue

1. Submitting a job

When a job is submitted, it is created and enters the system. At this time, the attributes are given to the job. The job description holds attributes that the job will use to go through the work management life cycle. These attributes include the user profile the job will start to run under, the request data (which tells the job what it will do), and the initial user portion of the library list, and so on. The job description also holds information that tells the job which job queue to enter and the routing data. The routing data is later used by the subsystem to find the routing entry that contains information needed for the job to start running. The output queue is also defined within the job description. It tells where printer output (also called spooled files) from a job will go. After the job receives its values (initialization, customization) for its job attributes, it moves to the job queue where it waits to enter the subsystem.

2. The job enters the job queue

Job queues are work entry points for batch jobs to enter the system. They can be thought of as ″waiting rooms″ for a subsystem. A number of factors affect when the job is pulled off the job queue into the subsystem, such as the job priority on the job queue, the sequence number of the job queue, and the maximum active jobs. When all of these factors work together, the job will be pulled off the job queue to start running in the subsystem. When the job enters the job queue, it is available to a subsystem that has the job queue allocated to it. Because subsystems can have more than one job queue feeding into them (however, job queues cannot feed into more than one subsystem), a sequence number in the subsystem determines when the subsystem processes a job queue. The subsystem looks at the sequence number of the job queue before the job priority of the jobs in the job queue. The subsystem uses the priority on the job queue to determine when a job can enter relative to other jobs on the job queue. The job priority and the maximum active jobs determine when a job enters the subsystem.

3. The job enters the subsystem

Subsystems are operating environments where the system manages the resources that jobs use and controls the jobs that run within them. After jobs are running in the subsystem, the subsystem job carries out user requests on a job such as holding, releasing, and ending a job. When the job enters the subsystem it becomes active. Like jobs, subsystems have descriptions that carry important information needed to complete the work. In the subsystem description is the routing entry. The routing entry references the class object, which contains the attributes that control the run-time environment. However, before the job can get its routing entry, the routing data must make a match with a compare value in the routing entry. If this association is not made, the job will not run. After the association between the routing data and the routing entry is made, the class object the job will use is determined. Some of the attributes that control the run-time environment include the run priority, the time slice, the maximum wait time, the maximum processing time, the maximum temporary storage, and the maximum number of threads. The subsystem description defines the memory pools that will be allocated to the subsystem. The subsystem description also contains the maximum active jobs, which is the maximum number of active jobs at one time in the subsystem. Until a job gets its activity level and is assigned a memory pool, it cannot run. The subsystem description, like the job description, carries information, such as the memory pool to use, the routing entry, the maximum active jobs, and the number of active jobs currently in the subsystem.

4. The subsystem uses memory from the memory pool to run the job

Memory is a resource from the memory pool that the subsystem uses to run the job. The amount of memory in a memory pool, as well as how many other jobs are competing for memory, affect how efficiently a job runs. Memory pools provide jobs with memory in which to run. Many factors affect how the job runs in the memory pool, such as the size of the memory pool, the activity level in the memory pool, and paging and faulting. The activity level in memory pools directly relates to the number of threads that are allowed to run in the memory pool at one time. Remember, every job has at least one active thread, but some can have multiple threads. Threads give a job the ability to do more than one thing at a time. For example, one thread can go out and do calculations while another thread waits for more data to process. Paging is the movement of data in and out of memory, both synchronously and asynchronously. Pages can be written out to storage or removed from memory without being written if they have not been changed. Faulting causes paging to occur on the server. Faulting occurs when a referenced page, or piece of data, is not in memory. This causes programs to stop because they must wait for the data to be paged in. Subsystems use different memory pools to support different types of jobs that run within them.

5. The job finishes and moves to the output queue

A job’s printer output (also called spooled files) is sent to an output queue where it waits to be sent to a printer or file. The output queue is similar to the job queue in that it controls how the output is made available to the printer. The output queue allows the user to control what files are printed first. Output queues are areas where printer output files wait to be processed and sent to the printer. Printer output is created either by the system or by the user using a print file. A print file is similar to a template or a guideline where the default values for the attributes of printer output are set. It is the beginning of the printer output life cycle.

The print file contains the output queue (OUTQ) and print device (DEV) attributes, which dictate how the printer output is to be directed. The default settings are typically *JOB, meaning that the job attributes of the output queue and printer device determine how the printer output is directed. The job attributes of the output queue and printer device settings are based on information obtained when the job is created. This is based on information from the user profile that the job is running under, the job description, the workstation device description, and the Default printer (QPRTDEV) system value. When the printer output is ready to be created, the system checks the print file and the job attributes (in this order) to see what output queue will process the printer output and which printer device the system will use. If a specified output queue cannot be found, the printer output will be directed to QGPL/QPRINT. After the printer output file is ready to be printed, a writer job, a job that processes the printer output from the output queue to the printer device, takes data from the printer output file and sends it to the designated printer.