The event-driven task communication for transporting requests between the user and server task is optimized internally by UDS/SQL. No direct measures are usually required by the database administrator to control this communication.
The settings in BS2000 and the load parameters do, however, affect the communication indirectly to some extent. Consequently, to control this effect, the task communication is described below with an explanation of which monitoring counters can be used for analysis.
Description of the task communication
The transfer of a request occurs via a common memory pool called the communication pool (CUP), which is created by UDS/SQL in accordance with the specifications for the load parameter PP CUPSIZE.
The task communication is used to wait and wake up the server tasks and user tasks and is implemented by means of the BS2000 eventing mechanism.
The following diagram illustrates the task communication for each request.
Figure 9: Task communication for each request
The objective of optimizing task communication is to avoid unnecessary wait and wake-up requests to BS2000 and to thus reduce CPU consumption. In this case, a server task is awakened to process a DML only if it has already been activated (“forward optimization”), and when the result is sent back to the user program, that program is awakened only if it has already passed a wait request to BS2000 (“backward optimization”). Both these optimization measures make use of BS2000 scheduling facilities.