Task management has to make a number of decisions before a task can execute. Resource management plays a vital role in this connection.
When a task is given the right to occupy space in main memory, this means that the task is activated.
Subsequently the task must be assigned a CPU i.e. the task is initiated.
Activation decisions are based on the following criteria:
multiprogramming level per category
priority
resource utilization (main memory, CPU, paging)
system services provided (CPU time, number of I/O operations).
Time slices
Time slices are used by task management to make CPU and main memory resources available to all tasks in as uniform a manner as possible in accordance with their priority
micro time slice (MTS) for optimum utilization of the CPU and
system service time slice (SSTS) for efficient allocation of main memory
Micro time slice
The micro time slice MTS is the maximum time a task may occupy the CPU without interruption if no task with a higher priority is waiting for allocation of the CPU.
No later than after the micro time slice has elapsed, an interrupt is issued in order to prevent a task from blocking the CPU. If the task has a variable priority (128-255), this will be modified in accordance with the I/O behavior and CPU utilization of the task.
System service time slice
The system service time slice SSTS does not document an absolute time. Instead, it corresponds to a maximum quantum of system services (CPU utilization, I/O rate) that an active task may demand. After the system service time slice has elapsed, the task is deactivated and loses its claim of main memory if tasks of the same category are waiting for activation.
Allocation of the main memory resource
Activating a task
Task activation depends on permission from the internal control facility known as ACF (Activate Control Function). For this purpose ACF measures the utilization of the resources main memory and CPU, and also the paging activities; if an activation sequence is to be performed, it only measures main memory utilization.
Depending on the degree of resource utilization and the predefined category/priority concept, a matrix-based decision is then made as to whether a further activation is permissible or a forced deactivation, a preemption or no action should be performed.The following example shows how PRIOR proceeds during task activation:
Total active: 19 TP, 9 DIALOG and 5 BATCH tasks
Waiting for activation: 2 TP, 2 DIALOG and 2 BATCH tasks
Systems support defined the categories as follows; the IO-PRIORITY operand is set to *NONE (default):
/MODIFY-TASK-CATEGORIES CATEGORY-NAME=DIALOG,- WEIGHT-CODE=100,MINIMUM-ACTIVE-TASKS=25,MAXIMUM-ACTIVE-TASKS=35 /MODIFY-TASK-CATEGORIES CATEGORY-NAME=TP,- WEIGHT-CODE=500,MINIMUM-ACTIVE-TASKS=30,MAXIMUM-ACTIVE-TASKS=40 /MODIFY-TASK-CATEGORIES CATEGORY-NAME=BATCH,- WEIGHT-CODE=3,MINIMUM-ACTIVE-TASKS=5,MAXIMUM-ACTIVE-TASKS=15The selection/activation decision by task management is taken in two steps:
Selection of the category from which a task is to be activated.
Within this category, the task with the highest priority is selected; in the case of identical priorities the task occupying the first position in the queue is activated.
For category selection the following decisions are required
With reference to the example this means:
Only those categories are considered for which at least one task is waiting for activation
This condition is satisfied for all categories
Among these, the following categories are given priority:
all categories (if present) which have not yet reached MINMPL.
MAXMPL has no meaning here.when all categories have reached MINMPL: all categories which have not yet reached MAXMPL.
This condition is satisfied for categories TP and DIALOG
If such preferred categories exist, all other categories are excluded from further selection:
z=0 n (number of active tasks < MIN z=MIN)
z=MIN <= number of active tasks < MAX)
z=MAX (number of active tasks > MAX)–
Explanation:
z=0 for TP (19 < 30)
z=0 for DIALOG ( 9 < 25)
z=5 for BATCH (MIN=5)From these categories the category for which the lowest index is calculated is selected for activation. Index calculation is based on the following algorithm:
Index = (NAT +1 -z) / WT
where:NAT = number of active tasks in the category for which the index is calculated
z = status indicator
WT = weight (urgency)
Index calculation is necessary for categories TP and DIALOG:
Index TP = (19+1-0) / 500 = 20 / 500 = 0,04Index DIA = (9+1-0) / 100 = 10 / 100 = 0,01
In the case of identical indices, activation is carried out in the sequence
TP - DIALOG - BATCHResult:
The highest-priority task of category TP is activated.
Exception:
Tasks with fixed priority are given preference.
Deactivating a task
The purpose of deactivating active tasks is to obtain main memory space for executable inactive tasks.
This takes place when
further processing is impossible
(e.g. due to program-controlled wait calls, waiting for input from display terminal in timesharing mode)the waiting time for events has been exceeded
(e.g. waiting for input from display terminal in inquiry and transaction mode)defined system services are utilized
(e.g. CPU time and number of inputs/outputs) have been used.
Exception
Deactivation is suppressed if systems support has made provisions in the user catalog that preclude deactivation of a user's tasks (see the ADD-USER command, PRIVILEGE=INHIBIT-DEACTIVATION).
Forced deactivation of a task
If the ACF function senses bottlenecks in the course of its survey of resource utilization, forced deactivation of a task is carried out.
Since forced deactivation relies on the category attributes MIN, MAX and WT, systems support can choose appropriate presettings for these values so that forced deactivation is performed only for tasks of less important categories.Exceptions
fixed-priority tasks
tasks in the TPR state
tasks that hold a lock
tasks under a user ID for which PRIVILEGE=INHIBIT-DEACTIVATION was declared (ADD-USER command); forced deactivation is not possible for these.
Preempting a task
Preemption may occur if an activation request has been received, but the ACF function does not permit activation because it has sensed resource bottlenecks. There are two ways of preempting a task:
An active task is preempted by an inactive task from a different category.
The active and inactive tasks belong to the same category.
The preemption rate is proportional to the duration of the overload situation (resource bottleneck) in the system.
Preemption control function (PCF)
PCF periodically monitors the preemption rate. Message:
EXC0455 TASK PREEMPTION LEVEL=iiis a number from 0 through 3 and designates the preemption rate.Level●
Effects on system
Operator action
0
Normal system processing
None
1, 2
Short-term overload conditions
None
3
Long-term overload conditions
The MAX-MPL value of a category is not exceeded. The system reserves main memory for privileged tasks.Reduce the MIN-MPL values of categories
Measures for preventing excessive preemption rates
Modify the MIN-MPL and MAX-MPL values for separate categories such that fewer activation requests are made.
Increase main memory or reduce the load.
Allocation of the CPU resource
After successful activation, each task waits for allotment of the CPU (central processing unit) resource, i.e. for initiation.
After the task has been allocated the CPU resource, the following interrupt causes may lead to deinitiation:
task wants to wait for synchronization event
waiting for termination of an I/O operation
execution of a paging operation
expiration of the micro time slice
Preemption may also occur on the initiation level. This takes place when another active and executable task with a higher priority is waiting for initiation. This can happen, for example, when an I/O operation for a task with a higher priority has terminated.
Assignment of the I/O resources
Assignment of the I/O resources depends on a task’s I/O priority. IORM is responsible for control here, see section "IORM: Control of I/O resources" and the “Utility Routines” manual [15].