A job queue is a list of WFL jobs that are awaiting initiation. Job queues are defined by the system administrator and managed by the operating system.

The purpose of job queue definitions is to allow the system administrator to set up some general parameters affecting the flow of WFL jobs on the system. Because a WFL job is typically an agent for initiating batch programs, the job queue system by implication can be used to regulate the initiation of batch programs in general.

Before defining the job queues, the system administrator usually analyzes the batch programs run on the system in terms of their patterns of resource usage and their relative urgency. The administrator then defines a separate job queue for each set of batch programs that show similar characteristics. For example, if there is a payroll application that has to finish processing before a precise deadline, the administrator might assign the application to a high-priority job queue. The administrator uses an MQ (Make or Modify Queue) system command to define the job queue.

For a complete explanation of job queues and using job queues in system administration, refer to the System Administration Guide. For information about using system commands to monitor and interact with jobs in queues, refer to the System Operations Guide. The following subsections describe the features of job queues that are of most direct interest to a programmer.

Deciding on the Queue for a Job

Depending on the policies that are in effect at your site, you might be required to ask your system administrator to which job queue to submit a particular WFL job. However, if the system administrator allows you to decide on the job queue, then you need to examine the job queue definitions to determine which queue is most suitable to your job.

The system command for displaying job queue definitions is QF (Queue Factors). The following is an example of a QF command and the response:

QF 4
     QUEUE 4:
       MIXLIMIT = 2
       DEFAULTS:
         PRIORITY = 50
         PROCESSTIME = 100
       LIMITS:
         PRIORITY = 60
         PROCESSTIME = 200

In this example, 4 is the job queue number. This number uniquely identifies a job queue. If the QF command does not specify a number, the output displays the definitions of all job queues on the system. The MIXLIMIT value specifies, roughly, the maximum number of jobs and descendant tasks initiated through this job queue that can be running concurrently. If the actual number of jobs and tasks originating from this job queue equals or exceeds the MIXLIMIT value, the system temporarily ceases initiating jobs from this job queue. After one or more of the jobs and tasks in this job queue terminates, the system resumes initiating jobs from this job queue.

The DEFAULTS and LIMITS portions of the job queue definition specify default values and maximum values for various task attributes that restrict the resource usage of a process.

The job queue defaults are inherited by the corresponding task attributes of a WFL job. However, the job can override this inheritance with assignments in the job header; that is, assignments that follow the BEGIN JOB construct but precede any of the declarations and statements in the job. Consider the following example:

?BEGIN JOB;
  CLASS = 4;
  PRIORITY = 55;
  TASK T;
  MYSELF(MAXPROCTIME = 150);
  RUN OBJECT/PROG;
?END JOB

Assume that this job is submitted through the job queue that was previously shown in the QF command example. Queue 4 has default values for both PRIORITY and PROCESSTIME (which corresponds to the MAXPROCTIME task attribute). The PRIORITY assignment in the job is part of the job header and therefore overrides the PRIORITY queue default. However, the MAXPROCTIME assignment in the job is not part of the job header. Therefore, the job does inherit the default MAXPROCTIME of 100 at initiation. The statement that assigns MAXPROCTIME a value of 150 has no effect, because the system does not allow a process to increase its MAXPROCTIME value after initiation.

Now consider the following job:

?BEGIN JOB;
  CLASS = 4;
  PRIORITY = 75;
  MAXPROCTIME = 300;
  TASK T;
  RUN OBJECT/PROG;
?END JOB

The system would never accept this job into queue 4, because the job header assigns values to PRIORITY and MAXPROCTIME that are both higher than the queue limits for these attributes. Since the CLASS attribute explicitly requests queue 4, the system rejects the job and displays a “Q-DS” message. (The CLASS attribute is explained under “Requesting the Queue for a Job,” later in this section.)

The following are the job queue attributesthat establish resource usage limits, and the task attributes that correspond to the job queue attributes.

If the actual resource usage of the job or its tasks exceeds one or more of the resource usage limits, the system discontinues the process that exceeded the limit. The point of this behavior is to encourage you to reexamine the job queue definitions and submit the job through the appropriate job queue.

In summary, you can determine an appropriate job queue for a job by estimating the resource usage requirements of the job and choosing a job queue whose resource usage limits are adequately high. There are, however, some additional restrictions:

Requesting the Queue for a Job

If you have decided that a specific job queue is most appropriate for your job, then you can request the job queue through a CLASS assignment in the job header. For example, the following job requests queue 10:

?BEGIN JOB;
  CLASS = 10;
RUN OBJECT/PROG;
?END JOB

If the job does not include a CLASS assignment, it can inherit a value from the CLASS usercode attribute. An inherited CLASS value has the same effect as an assigned CLASS value.

The system evaluates the eligibility of a job for a requested job queue based on the factors discussed previously: queue resource usage limits, usercode class limits, unit queue assignments, and the FAMILY value. If the job qualifies for the requested queue, the system places the job in the queue. If the job does not qualify for the requested queue, the system rejects the job and displays the message “Q-DS.”

If the job has no assigned or inherited CLASS value, the system attempts to find an appropriate job queue in which to place the job. The method the system uses for making this selection depends on whether the operating system compile-time option QFACTMATCHING is set.

If the job has no CLASS assignment and QFACTMATCHING is set, then the system examines the various job queues to determine their eligibility for receiving the job. The system selects the first job queue that meets the following criteria:

If the job has no CLASS assignment and QFACTMATCHING is reset, then the system selects the default job queue. The system administrator defines the default job queue using the DQ (Default Queue) system command. If no default queue has been defined, the system checks all the job queues, just as it would if QFACTMATCHING were set.

Whether QFACTMATCHING is set or not, the system performs an additional check. If the job queue selected by the system has a FAMILY attribute and the job has a FAMILY assignment in the job header, the system checks to see whether they match. If they do not specify identical family values, the system rejects the job and displays a “Q-DS” message.