Concept of job classes

The use of job classes enables systems support to classify user jobs.

The job class concept satisfies various demands.

1. The definition of job classes and their allocation to job schedulers permits the job mix to be optimized (e.g. many short-running jobs, few long-running jobs). This promotes well-balanced system utilization. In addition, it is possible to distribute job management privileges among users by issuing authorizations for access to job classes.

2. An additional access control instrument is provided by specific job class authorizations which systems support grants to users at its discretion. If the user does not specify a job class in the SET-LOGON-PARAMETERS or ENTER-JOB command, the user job is included in a standard job class. Systems support can define, modify or delete job classes. This can be done with the aid of the JMU utility routine, which is described in the “Utility Routines” manual [15].

3. Since the user requirements for jobs differ, the job schedulers must ensure differentiated treatment within job classes.

The description of a job class is based on a variety of parameters. The number of potential combinations of job characteristics is very large, and theoretically a separate job class could be defined for each of these combinations. However, such an approach is bound to have an extremely adverse effect on transparency.

Therefore systems support should define the job classes in accordance with the criteria dominating the day-to-day production runs.

Using the JMU routine (DEFINE-JOB-CLASS statement), systems support can define the following attributes and declarations for a job class:

• job class name

• responsible stream or default stream

• urgency (weighting) of the job class

• maximum number of jobs that can execute concurrently within the job class

• number of jobs which should ideally run in the job class

• job type

• job and task scheduling priority

• authorization for the starting of repeat jobs

• repetition cycle for repeat jobs

• maximum CPU time to be used

• start attributes

Whereas the job scheduling priority influences the starting of the job, the task scheduling priority affects the execution of the started job (= execution priority).

The possible values for job management are priorities 1 through 9, and for task management priorities 30 through 255.

The lower the value, the higher the priority.

The term job type refers to the difference between batch jobs and interactive jobs. Job classes may be defined for either job type, with the restriction that interactive job classes are not subject to job scheduling. Here attention is paid only to compliance with the class limits, i.e. the number of interactive jobs held in a job class and the access authorization for this job class are checked.

Example 1

Job classification according to CPU time used:

• Job class JCSHORT
  for jobs using no more than 5 CPU seconds

• Job class JCNORMAL
  for jobs using no more than 500 CPU seconds

• Job class JCLONG
  for jobs using more than 500 CPU seconds

Example 2

Job classification according to the start time:

• Job class JCEXPRES
  for jobs with the start attribute IMMEDIATE

• Job class JCNORMAL
  for jobs with no specific start time

• Job class JCTERMIN
  for jobs to be started at a specific point in time (date/time of day), i.e. scheduled jobs

In addition to the job classes for user jobs, there is a predefined system job class called $SYSJC for system jobs. This system class should not be available to users, as $SYSJC allows all job types and does not impose any limitations on class attributes.

The definition, modification and deletion of job classes may take place in two different ways:

1. The static definition is stored in the $TSOS.SJMSFILE. This file is the basis of every session. It is generated and managed using the JMU utility routine.

   The following JMU statements are available:

   DEFINE-JOB-CLASS
   MODIFY-JOB-CLASS
   DELETE-JOB-CLASS
   GRANT-JOB-CLASS-ACCESS
   SET-JOB-CLASS-DEFAULT
   SET-POSIX-JOB-CLASS-DEFAULT

   If systems support modifies the attributes of a job class or alters the allocation of a user ID to a job class in the $TSOS.SJMSFILE these changes will not take effect until the next session is started.

2. The dynamic definition refers to the current session only and is implemented via the command interface. It is also managed using the JMU utility, where the editing mode SET-MODIFICATION-MODE=*SYSTEM must be set. The same JMU statements are available as above. If SET-MODIFICATION-MODE=*ALL is used, the changes are also made to the file $TSOS.SJMSFILE.

   In addition, you can make modifications via the command interface. The following commands enable systems support to react promptly to overload situations without having to change the $TSOS.SJMSFILE.

   HOLD-JOB-CLASS
   MODIFY-JOB-CLASS
   RESUME-JOB-CLASS