Controlling JES2 initiators

JES2 associates one logical initiator residing in JES2 with each system initiator interfacing with JES2. You can control the number of active logical initiators and, using commands or during JES2 initialization, you associate logical initiators with the order in which JES2 selects the classes. During execution, an initiator selects non-held jobs in priority order within each non-held class in the order specified for that initiator. That is, the lowest priority job in the first non-empty class is selected ahead of the highest priority job of the next class assuming neither job nor class is held. the only exception is the processing of a job with a name duplicating a job currently in execution. The following two settings control the duplicate jobname processing:

JOBDEF DUPL_JOB
JOBCLASS(x) DUPL_JOB

If you specify DUPL_JOB=DELAY on the JOBDEF statement or DUPL_JOB=DELAY is the default, no two batch jobs with the same name will execute at the same time in the MAS, except when DUPL_JOB=NODELAY is specified on the JOBCLASS(x) statement.

If you specify DUPL_JOB=NODELAY on the JOBDEF statement, jobs with the same name can run at the same time, no matter what DUPL_JOB= is specified on the JOBCLASS(x) statement.

At system initialization, JES2 uses the initialization deck to assign an identifier to each initiator, to a maximum of 9999. Use these identifiers with JES2 commands to control the initiators. For information about naming initiators, see z/OS JES2 Initialization and Tuning Reference, SA32-0992.

When JES2 finishes reading a job that is to be executed locally, it is converted and placed in one of the execution queues according to its job class. The appropriate job class is determined by:

The CLASS= parameter on the JCL JOB statement.
The JES2 command $T J(n), C=class, which you may issue to change the job class after the job has been read and queued.
The default class assigned for that particular reader if the CLASS= parameter is not specified on the JCL JOB statement and you did not alter the job class.

Jobs are placed on the queues in priority sequence. Jobs of the same priority are selected on a first-in first-out basis. A job's priority is determined by:

The JES2 command $T J(n), P=priority, which you may issue to change the job's priority after the job has been read and queued.
The /*PRIORITY control statement.
The job time estimate information on the JOB statement or /*JOBPARM statement.

When an initiator is started, it will search its assigned queues for a job to process. On completion, it searches its queues for another job. The initiator processes jobs in priority order; for example, if the initiator is assigned classes A, B, and X, it will initiate only class A jobs as long as there are class A jobs ready for execution. When no class A jobs are available, the initiator will select only class B jobs or, if no class A or B jobs are available, class X. If there are no jobs available in the assigned classes, the initiator is inactive until such jobs are available.

Start of change For initiator processing, class groups exist within the priority-ordered class list. However, they are considered to be a conglomerated 'class'. Classes within a group are selected in a round robin scheme (across all job selection). This ensures an even distribution of work across all classes in the group. For example, if a group has classes A, B, and FRED, then those classes are chained in a ring off the job class group structure. One class is at the head of that loop and is the first searched when looking for work. If work is found in class B in this example, the head is updated to class FRED. The next selection will search class FRED first, and if work is found in that class, the head is updated to class A. End of change

This process is repeated each time an initiator attempts to select a job. An exception to this order of selecting jobs occurs when an execution batch monitor is active. Inthis case, the execution batch monitor class temporarily assumes the highest priority (for as long as the execution batch monitor remains active), thus reducing the overhead of bringing an execution batch monitor in and out of the system.