Execution Delay Monitoring Services for Multiple Address Space Work Managers

The structure of the multiple address space subsystem work manager determines which workload management services you can use to monitor work in multiple address spaces across a sysplex. The relate (IWM4MRLT), transfer (IWM4MXFR), and switch (IWM4MSWC) services provide a way for the work manager to indicate that a transaction is continuing execution somewhere else.

Some questions to help determine which services are appropriate include:

• Are the router, execution, and support address spaces all on one MVS™ image, or can they be distributed across MVS images?

  How many MVS images are involved influences the choice of the relate/transfer pair or switch service. IWM4MXFR requires both monitor environments to be on the same image, and knowledge of the parent monitoring environment. IWM4MSWC says the continuation of this work is “somewhere else,” either waiting within the MVS image, or in the sysplex, or the network. In addition, it indicates that the work request is waiting for the continuation to return.

• What are the addressability requirements?

  Connect (IWM4CON) and create (IWM4MCRE) identify the key in which future services are issued, and IWM4MRLT requires addressability to the parent monitoring environment. IWM4MXFR requires updating the dependent monitoring environment, and requires addressability and key update access to the parent monitoring environment.

• What are the dispatchable units in the servers and support address spaces?

  You must specify the dispatchable unit type on the INIT and RELATE services.

• When are the “arrival time” and the work qualifiers (name, user ID, etc.) known?

  The arrival time for the work request is required for INIT, and the work qualifiers are required for CLASSIFY.

• What is the current communication between the router, servers, and the support address spaces, so that new data can be passed?

  The participating subsystem work managers may want to pass the service class token returned from the IWM4CLSY service, together with the work request using their own communication methods.

Figure 6 shows some suggested services for a multiple address space work manager that take into account the previously discussed considerations.

Figure 6. Example of services that monitor work across multiple address spaces.

In the figure, the router could be like a CICS® TOR that routes the work off to an AOR, the execution address space, for processing. There may be some supporting address space involved that help process the work requests. The router would issue the IWM4CON macro to connect to workload management. It would also issue the IWM4CLSY service to associate the arriving work with a service class. Because it also receives the work request back once it has been processed, it also issues the IWM4RPT service to report the completion, and the IWM4DIS at address space termination.

The execution address spaces would issue the IWM4MCRE to create the monitoring environments and record information about the work with the IWM4MCHS service. It would issue the IWM4MNTF to signify that the execution phase of work request execution has completed. Then, at address space termination, it would issue the IWM4MDEL service to delete the monitoring environments.

The supporting address spaces would also use monitoring environments, so they would issue IWM4MCRE and IWM4MDEL. To show that the information they are keeping in the performance block reflects the same work request as the monitoring environment created by the execution address spaces, they issue the IWM4MRLT and IWM4MXFR services.

IWM4MRLT and IWM4MXFR require the supporting address space to be on the same MVS image, and that the monitoring token be passed from the execution address space to the supporting address space.