Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Job streams

BS2000 is supplied with predefined job classes. If no job classes are defined in a BS2000 system, all jobs are assigned to class $SYSJC (to which users have no access) and managed by the system job scheduler $SYSJS, which is permanently coupled to the system.

The system job scheduler is a system task which executes as a privileged task in CPU state TPR. Its selection strategy is based on the LIFO (Last In First Out) principle and cannot be influenced.

Independent of the job classes defined and any selection strategies which may have been implemented, the system job scheduler permits jobs to be started under the system administrator ID TSOS at any time during the session.

Job classes defined with the parameter JOB-TYPE=*BATCH are assigned (STREAM=name) to a job stream (also known as a job scheduler). A job class can only belong to one job stream, but a job stream can manage more than one job class.

The jobs in the stream are sorted by the standard job scheduler according to a prescribed selection strategy. The standard job scheduler is an application program that executes in CPU state TU under the system administrator ID TSOS. The selection strategy is specified by means of the stream parameter (STREAM -PARAMETER). It is set by means of the JMU utility (//DEFINE-JOB-STREAM).

In order to implement various selection strategies, the scheduling parameters specified for the stream definition can be dynamically updated (using //MODIFY-JOB-STREAM of the JMU utility routine).

Up to 16 job streams can be installed at the same time.

Selection strategies (STREAM-PARAMETER='...')

  • Selection according to arrival time:

    JOB-PRIORITY=NO,CPU-TIME=NO,WAIT-TIME=NO

    WAIT-TIME defines the waiting time of the job after acceptance.
    This strategy is advisable if the CPU time requirements for the different jobs are more or less the same.

  • Selection according to priority:

    JOB-PRIORITY=YES,CPU-TIME=NO,WAIT-TIME=NO

    This ensures that important jobs will be given priority.

  • Selection according to CPU time required:

    JOB-PRIORITY=NO,CPU-TIME=YES,WAIT-TIME=NO

    Jobs with lower CPU time requirements are given priority.

  • Selection according to priority and CPU time requirements:

    JOB-PRIORITY=YES,CPU-TIME=YES,WAIT-TIME=NO

    When different jobs have the same job scheduling priority, those requiring less CPU time are given priority. When the CPU time required is the same, job scheduling priority is the criterion for selection.

  • Selection according to priority and waiting time:

    JOB-PRIORITY=YES,CPU-TIME=NO,WAIT-TIME=YES

    By including the waiting time after job acceptance, jobs with a lower priority also have a chance of being selected.

  • Selection according to throughput:

    JOB-PRIORITY=NO,CPU-TIME=YES,WAIT-TIME=YES

    Jobs with low CPU time requirements are given priority, taking into account the waiting time following acceptance.

  • Selection according to throughput and priority:

    JOB-PRIORITY=YES,CPU-TIME=YES,WAIT-TIME=YES

    In addition to selection according to throughput, the job scheduling priority is taken into account.

The job scheduler passes the jobs it has selected and sorted to the class scheduler.

The class scheduler is not a separate task, but belongs to the core of the job management system. It ensures that the job mix desired by systems support (via the CLASS-LIMIT parameter of the individual job classes) will be adhered to.

When clearing bottleneck situations resulting from system saturation (saturation of the paging area), the CLASS-WEIGHT parameter determines the urgency the individual job classes will have.