Using the Subsystem Work Manager Delay State Information

The delay information in IWMWRCAA represent delays encountered by subsystem work managers as they process transactions. Workload management can recognize those address spaces that process transactions on behalf of the transaction managers. Such address spaces are called server address spaces. Workload management manages the server address spaces to achieve the goals of the transactions the server is processing. If a server address space is managing more than one service class, workload management manages the address space to meet the most stringent service class goal. However, resource consumption and address space delays for server address spaces are reported in the server's service classes.

The delay information shows the different states server address spaces experience while processing transactions. The information is provided on a service and report class basis – in the service or report class representing the transactions. This way, the delay states show for the transactions being processed, not for the address spaces serving the transactions. The states include how many times the service or report class was seen active, ready, and waiting. There are several waiting states. Each of these is reported separately. Some other states include whether the transactions are continued somewhere else in the system, in the sysplex, or in the network.

Using the Continued State Information

The state information helps a performance monitor show a picture of how well transactions are being processed. Because multiple address spaces can be involved in processing a transaction, a delay could occur in any of several places. IWMWRCAA provides state information to help a performance monitor pin down when transactions experience delays. The states show whether a service class has continued:

• In the local system
• In the sysplex
• In the network

With the cooperation of the participating subsystem work managers, the information reported divides the lifespan of transactions into two phases: a begin-to-end phase, and an execution phase. A begin-to-end phase shows transaction states from the time the subsystem work manager receives a transaction, processes it, and ends it. An execution phase shows transaction states only during the time a subsystem work manager processes the transaction. Delay states may not always appear in each phase. It depends on how a subsystem work manager is reporting the delays it encounters while processing.

For example, for CICS® transactions, delay states are recorded from the time the TOR receives the transaction and begins processing, through the time the transaction is processed in the AOR, FOR, or elsewhere, and ended back in the TOR. The phase where the TOR receives the transaction, and ends it is called the begin-to-end phase. The phase where the transaction moves into the AOR, FOR, or elsewhere and is processed is called the execution phase.

The delay states for both the begin-to-end and the execution phase are reported together in the service class of the CICS transactions processed. For example, Figure 24 shows the delay states sampled for both begin-to-end phase and the execution phase for one CICS service class representing CICS transactions.

If the execution phase occurs on the same MVS™ image as the begin-to-end phase, then (barring some statistical anomalies), the amount of time the service class spends in the continued - LOCAL state of the begin-to-end phase should approximately equal the amount of time the service class spends in the execution phase.

Figure 24. Using states for presenting CICS delay information

The execution phase could be in the same system as the begin-to-end phase, but could also be on another system in the sysplex, or in the network.

By combining the information collected on each system for a given service class, the performance monitor can resolve the states where the transactions in the service class continued elsewhere in the sysplex. For transactions continued elsewhere in the network, workload management cannot know any more information. Only the count of how many were switched out through the network is provided.

Figure 25 shows how the performance monitor could view the state information to provide a sysplex view. In this example, the states are reported for the CICSFAST service class. In this example, the number of samples of transactions continued somewhere in the sysplex should equal the number of transaction states sampled in the sysplex (summed from each system in the sysplex). The performance monitor can combine all the state data from all the systems in the sysplex to provide a sysplex view, correlating the data by service class.

Figure 25. Combining state information for a sysplex view.