Functions shared by all tasks are very frequently isolated and concentrated into a single task (e.g. I/O operations for special data sets, database calls, etc.).
If the task occupancy time for this central task is too long, wait states will result for the tasks which draw upon it.
A bottleneck ahead of a UTM application as a result of too small a number of (UTM) server tasks can be measured directly (see the explanations in "Threshold value monitoring of the number of UTM tasks using openSM2" (Optimizing the various phases)).
Often wait states can be detected by the increasing number or duration of “active waits” computed by the SM2 monitoring program TASK for the calling tasks. In the case of TP tasks, the number of “active waits” also contains not only those “waiting for input/output” but also those “waiting for terminal input”. This portion is negligible when the central task has a long task occupancy time.
The server task must be programmed so as not to require any locks, which it might then have to wait out. If the server task is not given priority over other tasks, it likewise runs the risk of encountering sudden losses in throughput. Due to the way jobs are handled between the job source task and the server task, congestion may occur in the event of programming which is not error-free, causing the server task to come to a halt. All of these problems are indications that the especially high quality of the coding required for server tasks is not being attained.
Example (simplified)
Figure 18: Time behavior of multi-level task concepts