One of the prerequisites for a successful forward optimization of the communication is a constant load of requests for the server tasks, i.e. there should always be enough requests present in the request pool for the server tasks to keep the tasks constantly occupied. This eliminates the need to wake up the server tasks.
Similarly, it is also possible to optimize the return to the user task. If the user task was interrupted due to BS2000 scheduling on transferring the request to the server task and is therefore not waiting, the need to wake up the user task is eliminated, so this step can be dropped.
The extent to which the optimizations work can be observed with the following monitoring counters in the COUNTER mask:
The “DML CALLS” counter counts the total number of requests passed to the server tasks.
The “ITC US -> ST” counter contains the number of executed wake-up signals sent from the UDS/SQL connection to the server tasks.
The “ITC ST -> US” counter contains the number of executed wake-up signals sent from the server tasks to the UDS/SQL connection.
Detailed descriptions of these counters can be found in section “Description of UDS/SQL monitor output to a file”.
If both these two counters “ITC US -> ST” and “ITC ST -> US” are almost identical to the counter “DML CALLS”, no effective optimization in task communication could be achieved. The possible causes for this may be:
a very low load
a high number of server tasks (load parameter
PP SERVERTASK)incorrectly set BS2000 priorities
If the “ITC US -> ST” counter is almost equal to the “DML CALLS” request counter of the same monitor mask, this means that the server task had to wait frequently, since they would otherwise not need to be awakened. This indicates that a user task and a server task was switched frequently on the processor, with only one request being processed in each case. In other words, the forward optimization had no effect.
If the “ITC ST -> US” counter is almost the same as the “DML CALLS” request counter of the same monitor mask, this means that the user tasks were frequently already in a waiting state when the DML request had finished processing in the server tasks. In other words, the backward optimization had no effect.
Both counters taken together could, however, never drop below the number of “DML CALLS”, since at least one task communication partner must always wait for each request.
When interpreting counters, bear in mind that the throughput of transactions is the decisive criterion for optimization. The communication counters cannot reflect all the results achieved from BS2000 scheduling; an improvement in throughput may occasionally be accompanied by a marginal deterioration in the communication optimization.