The task occupancy time consists of the CPU time and the I/O time of a desired user function plus the wait time for the corresponding hardware resources due to their workload.
The longer the task occupancy time, the smaller the number of user requests which this task can execute per unit of time.
Example
Task occupancy time for an average transaction in TP mode:
Ocupancy mode | Time |
Hardware service time of CPU | 200 ms |
Wait time for CPU (with 60% CPU workload, assuming “M/M/1”) | 300 ms |
Hardware service time of all I/O operations | 400 ms |
Waiting for I/O (with 30% workload, assuming “M/M/1”) | 170 ms |
Sum | 1070 ms |
If this application requires a higher transaction rate than 1 / 1.07 sec. per transaction = 0.93 transactions per sec. at peak load time and if only one task is available, that task will create a bottleneck.
The resultant wait periods in front of the task (incoming messages accumulate in the BCAM buffer) can be many times longer than the task occupancy time (see also report “Inwait time distribution” of the "Reports of the report group BCAM-CONNECTION").
The SM2 monitoring program TASK provides information on the task occupancy time.
This task occupancy time can be estimated from the duration entries for the various wait states and the CPU time used. Difficulties arise if it is unsure whether certain wait states are voluntary or inadvertent, i.e. whether or not a task requested the service which is provided for it itself.
The following ratio indicates that the task occupancy time is too long (D = Duration):
(CPU time + CPU-WAIT(D) + DISK-IO-WAITS(D) + NON-DISK-IO-WAITS(D)) / dwell time > 0,7
The dwell time does not include the wait time for other tasks (it may consequently be necessary to add this).
The computed CPU time refers to the TU and TPR processor states; the times for I/O activity refer solely to software service time.