The standard job scheduler decides which of the jobs of the assigned job class is to be released for execution.
For this purpose the standard job scheduler employs a certain job scheduling strategy, which is defined by means of the JMU utility routine (static definition) and can be
dynamically changed using the MODIFY-JOB-STREAM command. Up to 16 standard job schedulers with differing scheduling strategies may be installed at any given time. A standard job scheduler executes under a separate job (job stream). These are user programs in the TU state under the system administration ID.
If the control capabilities of the standard job scheduler are not sufficient for the data center, a self-developed job scheduler may be used (see section "Data center job management").
In either case the scheduler is started under the system administration ID. This takes place either automatically or with the START-JOB-STREAM command, depending on what was specified for the START operand in the stream definition of the scheduler in the SJMSFILE.
Job scheduling parameters
During stream definition with the JMU statement DEFINE-JOB-STREAM, the operand STREAM-PARAMETER (or S-PAR) is used to define scheduler-specific parameters.
This operand is ignored by BS2000; it is interpreted only by the job scheduler and provides the basis for calculating the scheduling algorithm.
For the standard job scheduler, the following parameters are specified with the S-PAR operand:
|
|
| |
| |
| |
| |
| |
| |
,MSG-OUTPUT = YES / STD' |
Notes
The definition variants of the first three parameters correspond to the scheduling strategies listed in table 26.
From the jobs, those jobs are selected for which the lowest precedence value is determined in the calculation of the scheduling algorithm. The number of jobs selected depends on the JOB-QUOTA parameter. The job scheduler then attempts to start these jobs in accordance with their sequence in the queue. Following the start, jobs are again selected from the set of jobs. This process is repeated until all the jobs have been
started or the job class limit is reached.The LOGGING parameter controls output of a log for the standard job scheduler. In addition, it defines whether messages generated by the job scheduler are to be output on the console.
These messages include:
JMS0302:Error on execution of an ASSIGN-SYSFILE commandJMS0303:Log aborted owing to lack of storage spaceJMS0304:Unrecoverable errorJMS0305:Invalid stream parameterJMS0306:Job stream waiting for specified pubsets to become availableJMS0307:Job stream terminated owing to missing pubsetsJMS0308:Job stream waiting for the GET-TIME subsystem to become available
The parameter CATID-LIST defines the public volume sets which must be imported before the job scheduler is started up. The parameter is interpreted only at stream
startup time; it delays starting of the job scheduler until all the pubsets specified under CATID-LIST are available. If the CATID-LIST parameter is omitted, the job scheduler is started irrespective of which pubsets have been imported.
The CAT-TIME parameter is used to control this waiting time. If a pubset cannot be imported within the time specified via CAT-TIME, the job scheduler will not be started. If CAT-TIME is omitted from the stream definition, the system waits for however long it takes to import the required pubsets. The time specification for CAT-TIME is in minutes.- The MSG-OUTPUT parameter controls the behaviour of the job scheduler when outputting messages. If the parameter is set to the value YES, then JMS messages generated by the job scheduler are output on the console even if logging is turned off (LOGGING = NO). If the parameter is set to the value STD, the message is output as before depending on the LOGGING parameter.
Systems support can change the S-PAR setting dynamically via the command interface (see the MODIFY-JOB-STREAM command in the “Commands” manual [27]).
Job scheduling algorithm
The job schedulers pass the jobs they have released for execution to the class scheduler. The sequence in which the jobs are released for execution is calculated with the following formula:
M= (Sa * Pc * Rd) / (Wb + S(a*b))
where:
M | Precedence |
| S | CPU time (in seconds) that the job has requested |
| P | Job scheduling priority |
| W | Waiting time (in minutes) of job after job acceptance |
| R | Time (in minutes) remaining at job start until the latest starting time is reached. This is based on the assumption that the start attribute START=WITHIN or START=LATEST is use |
a,b,c | Job scheduler parameters (may assume the value 0 or 1) defined by systems support during stream definition. The following parameters correspond to the following variables:
|
d | d=1 if the job is supplied with the start attribute START=WITHIN or START=LATEST by the user. Otherwise d=0 applies. |
The smaller the value for M, the better the position of the job, irrespective of the job class.
If the same value M is calculated for several jobs, the sequence of the jobs that are released for execution is determined on the basis of the FIFO principle.
The various scheduling procedures resulting from different combinations of the exponential values are described on the next few pages. The values for exponents a, b, c are assigned by means of the S-PAR operand in the stream definition.
In the table, abbreviations are used for the scheduling strategies. A description follows the table.
Scheduling strategy | CPU-TIME | WAIT-TIME | JOB-PRIORITY |
(1) FIFO | NO | YES | NO |
(2) HPF | NO | NO | YES |
(3) HPA | NO | YES | YES |
(4) SJF | YES | NO | NO |
(5) SJP | YES | NO | YES |
(6) HRN | YES | YES | NO |
(7) HRP | YES | YES | YES |
Table 26: Scheduling strategies
(1) Selection by arrival time (FIFO)
This strategy is recommended when the CPU time requests of the jobs to be released do not differ greatly. If they do differ considerably, the exclusive use of this strategy causes time-consuming jobs to be given preference.
Selection of jobs with the option START=WITHIN or START=LATEST in the ENTER-JOB command (FIFO and R (waiting time)):
The STREAM parameter WAIT-TIME=YES is evaluated on the basis of the FIFO selection principle. If the jobs arrived in the system with the start option START=WITHIN, the jobs will not be included in the selection process until the start interval has commenced. For jobs with START=LATEST the probability of being started increases as the latest desired start time approaches.
With WAIT-TIME=YES, FIFO cannot be guaranteed if a stream start is executing and a TSN overflow has occurred. If two jobs were started in the same minute and a TSN overflow then occurred, the job with the TSN 0AAA is started before the job with the last assignable TSN (e.g. 9999).
(2) Selection by priority (HPF)
The jobs are selected according to their externally assigned job scheduling priority. Since the job with the highest priority is always released first, the preference of privileged jobs is guaranteed.
Selection of jobs with the option START=IMMEDIATE or START=AT in the ENTER-JOB command:
These functions cause the scheduling algorithm to set the value M (precedence) for jobs with the option START=IMMEDIATE automatically to 0. For jobs with the option START=AT, M is set to 0 if the specified start time has been reached. Jobs for which M=0 is detected are immediately released for starting and cannot be overtaken by jobs with M>0.
(3) Selection by priority and aging (HPA)
By including the waiting time in the selection strategy, jobs with a lower priority can also be passed to the class scheduler, even when there is a permanent supply of high-priority jobs.
(4) Selection by runtime (SJF)
This strategy prefers short jobs and, in contrast to the FIFO method, reduces the mean waiting time. As batch jobs are aborted when the requested CPU time has expired, this strategy cannot be circumvented. SJF delays the start of time-consuming jobs; in extreme cases, namely where there is a sufficient amount of short jobs, this may result in long jobs not being released for starting.
(5) Selection by CPU time and priority (SJP)
This strategy combines the “selection by runtime” and “selection by priority” methods.For jobs with identical CPU time requests, the priority becomes the selection criterion; jobs with identical job scheduling priorities are selected on the basis of the requested CPU time.
(6) Selection by response ratio (HRN)
The response ratio is expressed by (waiting time + CPU time) / CPU time and constitutes a combination of the HPA and SJF strategies. This gives preference to short jobs, but takes the waiting time into account.
(7) Selection by throughput and priority (HRP)
Short jobs are given preference. The order or precedence of the jobs is determined by the respective job scheduling priorities.
Log of the standard job scheduler
The standard job scheduler logs certain events of the stream tasks to the log file SYS.SCHEDLOG.<yyyy.mm.dd>.<hh.mm.ss>.<streamname>, provided logging has been activated in the stream definition (in the JMU statement DEFINE-JOB-STREAM or in the S-PAR='...,LOGGING=YES' operand of the MODIFY-JOB-STREAM command). The log provides an overview of the scheduler's activities during a session. Moreover it serves as a support document for potential error analysis.
Extract from a log file (the number (1., 2., ...) do not form part of the log file but act as explanatory texts).
FTS BS2000 JOB SCHEDULER JSSTD1 VERSION <version> <date> <time> PAGE 1
** STREAM STARTED
** JSSTD1 JSATTCH 1.
** EVENT 10 (JS_HOLD) 16.
** EVENT 11 (JS_RELEASE) 17.
** EVENT 9 (JC_AVAILABLE) 15. JCLASS=JCDSTD
** JSWAKE 4. WAKE-TIME=2147483647
** EVENT 9 (JC_AVAILABLE) 15. JCLASS=JCDSTD
** EVENT 9 (JC_AVAILABLE) 15. JCLASS=JCDSTD
** EVENT 9 (JC_AVAILABLE) 15. JCLASS=JCDSTD
** EVENT (J_INTRODUCTION) 6. TSN=0FSM
** JSRUNJB 3. TSN=0FSM, JCLASS=JCBSTD,
WAIT-TIME=0, JOB-PRIO=9,
CPU-TIME=32000,
MERIT=45DBBA000000000000000001
** EVENT 1 (J_TERMINATION) 7. TSN=0FSM
** EVENT 9 (JC_AVAILABLE) 15. JCLASS=JCBSTD
** EVENT (J_INTRODUCTION) 6. TSN=0FSN
** JSRUNJB 3. TSN=0FSN, JCLASS=JCBSTD,
WAIT-TIME=0, JOB-PRIO=9,
CPU-TIME=32000,
MERIT=45DBBA000000000000000002
** EVENT 9 (JC_AVAILABLE) 15. JCLASS=JCDSTD
** EVENT 1 (J_TERMINATION) 7. TSN=0FSN
** EVENT 9 (JC_AVAILABLE) 15. JCLASS=JCBSTD
** EVENT (J_INTRODUCTION) 6. TSN=0FSQ
** JSRUNJB 3. TSN=0FSQ, JCLASS=JCBSTD,
WAIT-TIME=0, JOB-PRIO=9,
CPU-TIME=32000,
MERIT=45DBBA000000000000000003
** EVENT (J_INTRODUCTION) 6. TSN=0FSR
** JSRUNJB 3. TSN=0FSR, JCLASS=JCBSTD,
WAIT-TIME=0, JOB-PRIO=9,
CPU-TIME=32000,
MERIT=45DBBA000000000000000004
** EVENT (J_INTRODUCTION) 6. TSN=0FSS
** JSWAKE 4. WAKE-TIME=0
** JOB_HOLD JOB HELD TSN=0FSS
** EVENT 2 (J_HOLD) 8. TSN=0FSS
** JSWAKE 4. WAKE-TIME=10111560
** EVENT 4 (J_CANCEL) 10. TSN=0FSS
** JSWAKE 4. WAKE-TIME=2147483647
** EVENT (J_INTRODUCTION) 6. TSN=0FSS
** JSWAKE 4. WAKE-TIME=0
** EVENT 16 (JS_TIMER) 21. DATE=<date>, TIME=<time>
** JSWAKE 4. WAKE-TIME=10111500
** EVENT 3 (J_RELEASE) 9. TSN=0FSS
** EVENT 1 (J_TERMINATION) 7. TSN=0FSQ
** EVENT 9 (JC_AVAILABLE) 15. JCLASS=JCBSTD
** EVENT 1 (J_TERMINATION) 7. TSN=0FSR
** EVENT 9 (JC_AVAILABLE) 15. JCLASS=JCBSTD
** EVENT 4 (J_CANCEL) 10. TSN=0FSS
** JSWAKE 4. WAKE-TIME=2147483647
** EVENT 13 (JS_CLOSE_IMMEDIATE) 19.
** STREAM CLOSED
** JSSTD1 JSDETCH 2.
Explanation of the job scheduler functions listed in the log (steps evident from the logging information are printed in bold):
JSATTCH
The job stream issues a message indicating that it has started successfully.JSDETCH
The specified job stream is terminating. The job management system no longer
supports the job scheduler. In addition, the task in which the job stream executes is terminated.JSRUNJB
The job scheduler requests the class scheduler to start the specified job. If the CLASS-LIMIT is reached for the job class, information to this effect is returned to the standard job scheduler.JSWAKE
The job scheduler informs the job management system of when it wants to be
reactivated.JSEXPCT
The job management system is requested to pass the next event to the job scheduler. Such an event may be (see items 6 - 21):J_INTRODUCTION
The job scheduler is requested to include a job in the set of jobs for which it is
responsible. The following information is supplied to the job scheduler for this purpose:Job number, name of job class, repeat indicator, CPU time, job scheduling priority, job arrival time, start attribute, job parameters.
J_TERMINATION
A job managed by the relevant job scheduler is terminated after completion of its
runtime.J_HOLD
A job is halted and placed in the hold queue.J_RELEASE
A job in the hold queue is released. The job scheduler is requested to consider the job for selection.J_CANCEL
A job not yet started by the job scheduler is aborted.J_EXPRESS
Acceptance of a job that is to be started as soon as possible. The job is assigned the precedence M=0 (see "Job scheduling algorithm").J_RESCHEDULE
Indicates that the job attributes have been modified by means of the MODIFY-JOB command.JC_HOLD
The specified job class is placed in the wait state. The job scheduler is requested to skip the jobs of this class during the selection process.JC_RELEASE
The job class and hence (implicitly) all its jobs are removed from the wait state.JC_AVAILABLE
The value defined with CLASS-LIMIT has not been reached for the specified job class.JS_HOLD
The specified job stream is placed in the wait state.JS_RELEASE
The job stream is removed from the wait state. The job stream is requested to process all jobs within its sphere of activity.JS_CLOSE QUIET
The system is in the termination phase. This event has the same effect as JS_HOLD, i.e. no further jobs are started.JS_CLOSE IMMEDIATE
The job scheduler is terminated immediately after the STOP-JOB-STREAM command has been processed.JS_CHANGE
Information on modified STREAM-PARAMETERs is output.JS_TIMER
The job scheduler is requested at one minute intervals to check the start attributes of its jobs.