Job class characteristics

During JES2 initialization, you can assign job characteristics to jobs queued in each class to determine:

A default performance group for each job.
JCL conversion parameters.
Whether to initiate jobs in this class by JES2 managed initiators or WLM managed initiators.
Whether to impose limits on the maximum number of jobs that can be in execution at one time in the MAS.
Whether to hold jobs in this class after conversion.
Whether to copy jobs in this class directly to the message class output, without undergoing conversion or execution.
Whether to convert the job and queue for output without execution.
Whether to produce a JES2 job log for jobs in this class. (The JES2 job log is a list of all messages and replies issued by, or on behalf of, a job.)
Whether to save a job journal for jobs in this class. If you use checkpoint restart or restart a job step, you need to save the journal or the system can not automatically restart the job if it fails or if there is a system restart.
If you use automatic restart management to restart a job, you do not need to save the journal because automatic restart management of MVS™ does not use the job journal when restarting jobs.
If execution batch monitoring facility jobs can run in this class.
Whether to suppress output for jobs in this class (for example, started tasks).
The procedure library (PROCnn) definition.
SMF options.
If the system can restart this job in the event of a JES2 warm start.
JESLOG options.

When first creating your initialization data set(s), you can define a “universal” job class statement and specifications. Define JOBCLASS(?) as a single JOBCLASS statement; it provides a “universal” set of characteristics for all 36 job classes. (The '?' wild-card character refers to the one-character job classes, as opposed to '*' which would include the 'STC' and 'TSU' classes.) Then add specific JOBCLASS(v) statements after this statement for those classes that require individual specification.

JES2 overrides previously-defined initialization statements with duplicates of the statement it reads later in initialization processing. In this manner, only specific JOBCLASS(v) statements override their “universal” JOBCLASS(?) or JOBCLASS(*) specification and the “universal” characteristics remain valid for all other “non-specifically” defined classes.

For example, in the following initialization statements:

JOBCLASS(?) AUTH=IO,MSGLEVEL=(1,1),PERFORM=10
⋮
JOBCLASS(X) AUTH=INFO,IEFUSO=NO

Job class X overrides the previous value of AUTH=IO with AUTH=INFO, and the IEFUSO value (which defaulted to YES) is changed to NO. Job class X uses the values for MSGLEVEL= and PERFORM= from the JOBCLASS(?) statement.

A default SCHENV can be specified for each JOBCLASS (not for JOBCLASS(STC) or JOBCLASS(TSU)). This value will be provided each job at the end of JCL conversion provided that a SCHENV has not already been associated with the job. A SCHENV can be associated by the user specifying SCHENV= on the // JOB statement or by JES2 installation exits which occur before the end of conversion.

SPINNING of JESLOG data sets is specified by the JESLOG operand.

Jobs are assigned to JES2 or WLM managed initiators based on the MODE parameter on the JOBCLASS statement. JES2 and WLM initiators select jobs using different criteria:

JES2 uses job class and scheduling priority as selection criteria. See JES2 control of batch job initiation for details.
Workload management uses service class as selection criteria. See WLM control of batch job initiation for details.

Note: All JOBCLASS parameter definitions are MAS-wide, and can only be changed with an operator command or a JES2 cold start.