The execution priorities may be subdivided as follows:
Priorities 0 - 29 | Priorities for system tasks |
Priorities 30 - 127 | Fixed task scheduling priorities |
Priorities 128 - 255 | Variable task scheduling priorities |
Except for the system priorities, priorities are specified during job class definition and, for each user, in the user catalog.
If the user specifies a priority in the SET-LOGON-PARAMETERS or ENTER-JOB command, this priority is checked both in the job class assigned to the user and in the user catalog.
The priority of a task is considered during both activation and initiation (allocation of CPU).
The system parameter ETMFXLOW also offers the option of setting up a lower area of fixed priorities.
Variable priorities
Variable priorities are characterized by dynamic priority adaptation using the HRN (Highest Response ratio Next) algorithm
HRN based on the ratio residence time / CPU time used and taking into account the start priority in the SET-LOGON-PARAMETERS or ENTERJOB command or an externally assigned priority (CHANGE-TASK-PRIORITY command).
The HRN algorithm causes tasks taking little CPU power and I/O-intensive tasks to be given preference, without creating extreme disadvantages for compute-intensive tasks. Moreover, appropriate handling is also ensured for tasks with a low start priority.
The variable priority is recalculated at the following times:
every time activation is performed
with every PEND/UNPEND following inclusion in the Q5 queue
on expiration of a micro time slice (a time quantum dependent on the CPU speed and on the immediately preceding I/O behavior of the task)
periodically (once per second)
when a MODIFY-TASK-CATEGORIES command is issued
when a CHANGE-TASK-PRIORITY command is issued
Fixed priorities
Fixed priorities never change.
A fixed priority is a great advantage for the task concerned.
Fixed priorities have been conceived for applications with extreme real-time demands. They can bring about performance improvements with the following restrictions:
Fixed priorities greatly reduce the system's leeway for decisions. Therefore, in order to achieve positive results, the resource requests of all tasks must be known. In the case of high resource utilization, fixed-priority tasks waiting for activation lead to the immediate preemption of other tasks, which may cause an overload situation. This in turn has repercussions on performance in the long run.
Fixed priorities should only be used after meticulous analysis of system load and resource utilization data, and in conjunction with load-reducing measures such as the limitation of the category multiprogramming level by means of the MAXIMUM-ACTIVE-TASKS operand in the MODIFY-TASK-CATEGORIES command.
Summary
Priorities of any kind influence the sequence of queued tasks.
Any priority better than the “normal” priority 255 affects the system, regardless of the load situation.
Due to the increased importance of priority, systems support can easily influence the performance of individual tasks just by changing their priority. Especially in the case of low-performance systems with only a few user tasks it is helpful to assign different variable priorities to the tasks. This ensures that each task receives a share of system capacity commensurate with its importance.
If nearly all tasks are working with priority 255, a slight difference in priority (e.g. 5) is sufficient to give strong preference to a task. If the range of priorities is greater, the difference in priority must likewise be greater. Depending on the load, the priority should be varied (e.g. in increments of 5 or 10) until the desired performance target is reached. As a rule it is not necessary to assign fixed priorities, since medium-range variable priorities (around 200) already yield satisfactory performance values. Larger priority intervals are required in the case of consistently high task loads or predominantly I/O-intensive tasks.
The allocation of the resources main memory and CPU to user/system tasks is controlled in accordance with the predefined category/priority concept.
Queues
Tasks may exist within the system in any of five states:
task is occupying a CPU
task is active and executable
task is active but not executable
task is inactive and executable
task is inactive and not executable
The basis for this is the queuing concept of the task management system, which ensures that each task is included in one of the following queues (depending on the relevant task state).
Q0 | Running task | Task in control |
Q1 | Waiting for CPU allocation | a c t i v e |
Q2 | Write tasks of openSM2 | a c t i v e |
Q3 | Waiting for paging | a c t i v e |
Q4 | Waiting during rapid input/output | a c t i v e |
Q5 | Per category: waiting for activation | i n a c t i v e |
Q6 | Per category: waiting for permission from PCS | i n a c t i v e |
Q10 | Waiting in HOLD state | i n a c t i v e |
Q11 | Waiting system tasks | i n a c t i v e |
Q12 | Waiting during lengthy I/O operations and lengthy synchronization functions, especially terminal I/O in interactive mode | i n a c t i v e |
Q13 | Waiting for n seconds (PASS/VPASS) | i n a c t i v e |
Table 31: Queues in task management
If a task is not waiting for input, its primary goal is to occupy the CPU. This usually presupposes several changes of state.
Let us assume a user task (e.g. a batch task) is in Q10 following a HOLD-TASK command.As soon as systems support releases the task via the RESUME-TASK command, its state changes.
The task leaves Q10 and is entered in Q5 (the subqueue for the category involved, e.g. batch). There it waits for PRIOR to access it in the context of the activation process and move it to Q1 and eventually to Q0.
These transitions from one state to another are implemented by means of the PEND/UNPEND routines:
The UNPEND routines move the task towards the CPU, while the PEND routines move the task away from a high-ranking queue and include it in a lower-ranking queue.