Job streams, job and class scheduler

The job classes are coupled with different job schedulers, using the JMU utility routine (see the “Utility Routines” manual [15]).

Each job scheduler executes within a separate job called the “job stream”.

In accordance with the stipulated job scheduling strategies, the job schedulers decide which of the jobs is to be released for execution.

Job streams, and therefore also job schedulers, control the selection of user jobs by means of specific job scheduling algorithms.

Example

Most data centers have certain central production tasks:

1. Jobs involving the compilation, linkage and loading of programs do not require any special resources.

2. Jobs from end-user departments are usually time-consuming, high-priority jobs with high resource demands.

3. The data center creates a number of jobs for administrative purposes which run at specific times and must be repeated.

Hence the obvious approach is to install three job streams (job schedulers) with appropriate job scheduling strategies for these three production tasks:

for 1)	A FIFO-based job scheduler (FIFO = First In, First Out) is chosen for jobs from the programming department. Jobs for program compilation, linkage, etc. may be combined into job classes that are assigned to a job scheduler which is active during the night hours only. This serves to lighten daytime workloads in the data center.
for 2)	For jobs from end-user departments, a job scheduler based on priority and usage of resources is the best choice.
for 3)	An algorithm covering scheduled jobs is available for data center jobs.

By means of the JMU statement DEFINE-JOB-STREAM systems support specifies the criteria on which the job stream is to be based and in accordance with which the job scheduler will control the jobs. For example, the job priority or the required CPU time can be specified as the criterion with the aid of the S-PAR operand.

A job stream is characterized by a few other qualities in addition to the scheduling algorithm:

• A job stream need not be continuously active. For example, systems support has to decide whether a job stream should be active immediately after BS2000 loading or only during the night. Jobs read in for an inactive stream are collected in a special queue (TYPE1/DO) until the stream is active and the job scheduler takes over management.

• During job stream definition a task scheduling priority is set which governs the stream from the start. Since each job stream runs in its own job, this ensures an unambiguous order of precedence. This order can be altered by means of the MODIFY-JOB-STREAM command.

• A job stream manages batch jobs only. Interactive jobs are not subject to job scheduling; they are started if and when the user is authorized to start interactive jobs in the relevant job class and the job class has not yet reached the specified limit.

The definition of job streams, and hence job schedulers, may take place in two different ways:

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

   The necessary JMU statements are:

   DEFINE-JOB-STREAM 
   DELETE-JOB-STREAM 
   MODIFY-JOB-STREAM

   Changes made to this file do 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 definitions stored in the file $TSOS.SJMSFILE.

   HOLD-JOB-STREAM 
   MODIFY-JOB-STREAM 
   RESUME-JOB-STREAM 
   START-JOB-STREAM 
   STOP-JOB-STREAM

The name of the ENTER file which defines the job stream job is stored in the file $TSOS.SJMSFILE. In principle, this may be any name, but it is recommended for reasons of consistency that SYSENT.JOBSCHED.nnn is used (nnn is the identifier for the operating system version).

The job scheduler is called up from this file by a START-EXECUTABLE-PROGRAM, which specifies its name. Again, any name may in principle be used for the job scheduler; but on grounds of consistency, for which systems support is responsible, the name SYSPRG.JOBSCHED.nnn is recommended (nnn is the identifier for the operating system version).

Agreed logon and logoff procedures are not performed for the stream ENTER job (for information on logon/logoff procedures, see the “SDF Dialog Interface” manual [43]).

There are three kinds of scheduler with different functions:

• the system/emergency job scheduler $SYSJS

• the standard job schedulers

• the class scheduler