Using the Execution Delay Monitoring Services

If you have a single address space subsystem work manager, and would like the following functions from workload management:

• Associate work coming into the subsystem with a service class
• Goals vs. actual information for reporting
• Response time information for work requests
• Execution delay information about work for reporting and for MVS™ management purposes

consider using the services shown in Figure 3.

The execution delay monitoring services support response time goals only. If you want your customers to assign velocity or discretionary goals, or if you want to support period switching, consider using enclaves instead. For information about using enclave services, see Creating and Using Enclaves

It is important to use the IWM4CHST service together with the IWM4RPT service, otherwise the delay information is not meaningful.

Figure 3. Work manager and delay monitoring services for a single address space transaction manager.

At address space initialization, the address space issues the IWM4CON service to establish authorization for subsequent services. It then issues the IWM4MCRE (create) service. Create establishes a monitoring environment to keep track of the execution delays encountered by a work request. If the transaction manager sets up multiple tasks to process work, you should create one monitoring environment per task, assuming each task is dedicated to one work request. Similarly, if the task processes multiple work requests at the same time, then it should issue one IWM4MCRE for each work request that may be running under that task at one time. You can use the REQUEST=MULTIPLE parameter on the IWM4MCRE service to create a pool of monitoring environments at initialization time. This saves the repeated system overhead of issuing a single IWM4MCRE service for each monitoring environment needed.

The IWM4MCRE service also defines the PSW key in which the transaction manager is to run. Because monitoring environments are not initially associated with a work request, the IWM4MCRE sets the state of the monitoring environment to “free”.

When you create a monitoring environment, workload management establishes recovery at both the task and address space level. If the address space or the task that created the monitoring environment fails, workload management cleans up the resources associated with the monitoring environment.

When the transaction manager receives a work request, it should issue the IWM4CLSY service to associate an incoming work request with a service class. At that time, the transaction manager should issue an IWM4MINI to initialize the monitoring environment. The IWM4MINI service with the MODE=RESET parameter sets the state of the monitoring environment to “active”, and associates the monitoring environment with the work request.

Whenever that work request encounters a different state, such as waiting on a conversation, waiting on a lock, or for I/O, the transaction manager should issue the IWM4MCHS (change state of work request) service. Since IWM4MCHS is an inline expansion, there is very little overhead, and you can issue it frequently. Workload management can then update the monitoring environment to reflect these changes, and represent the execution delays the work request encountered.

When the transaction manager has completed processing the work request, it should issue the IWM4RPT service. The transaction manager should delete all created monitoring environments at address space clean-up and termination, and disconnect from workload management services.