The following example explains the effects of the various parameters discussed earlier. It is based on the assumption that a UDS/SQL configuration, for which certain system services are to be guaranteed, is being operated on a system at peak load.
The ideal system behavior from a task communication viewpoint is to allow a few requests to be collected and then be processed by the server tasks without interruption. When these requests are being processed, further requests may also be received from other processors if there are more processors present than server tasks.
This effect can be achieved by correctly setting the BS2000 priority and by making use of a BS2000 scheduling principle. In this case, a task with a higher priority that is waiting for a processor to be allocated will not always displace an executing task with a lower priority. The displacement is to occur only if an extreme difference in priority is involved.
If the user tasks have a marginally higher priority than the server tasks, many user tasks will initially place their requests in the request pool, although a server task has already been awakened by the first user task. It is only when all user tasks have been queued for processing that the server task is allocated the processor.
The server task is now executed on the processor and handles all pending requests in succession, even though the first user task has already been awakened following the first request.
This effect can be achieved permanently only if fixed priorities are used both for the server tasks and for the user tasks (in range 127 to 60). If variable priorities (in range 255 to 128) are used, the internal priority values will be changed dynamically by the operating system, which means that the real-time behavior of the system can no longer be predicted accordingly.
If the BS2000 priority of the master task and thus the server tasks is set to 120 (see RUN-PRIO for ENTER jobs in chapter "Starting DBH") and that of the user tasks is set to 119, the following favorable situation will arise on a monoprocessor with a load parameter setting of PP SERVERTASK=1:
The following favorable situation occurs on a biprocessor with the load parameter setting PP SERVERTASK=1 if the CPU share of the user programs is greater than that of the server tasks:
The following favorable situation occurs with n users on a biprocessor with the load parameter setting PP SERVERTASK=2:
If the situation with only one server task when the CPU share of the server tasks is greater than that of the user tasks is to be duplicated on a biprocessor with two server tasks, the load parameter PP SCHEDULING=ASYMMETRIC must be set. In this case, one server task will attempt to continuously process requests, while the other server task will only process one request.
The situation on a quad-processor system is analogous to that of the biprocessor with more than one server task.
The effect of the load parameter PP SCHEDULING=ASYMMETRIC can thus be summarized as follows: Since a server task always executes one request, all other server tasks on the parallel processors are one for a correspondingly longer period.
Other tasks with a lower BS2000 priority on the same system take up the processor time if a typical short-term reduction in the load occurs or if the database configuration requires only a part of the CPU time.
Other tasks with a higher BS2000 priority such as system tasks, for example, have no significant effect on the processing flows described above, unless such tasks occupy a processor permanently.