Previous topic |
Next topic |
Contents |
Index |
Contact z/OS |
Library |
PDF
Why Use the Execution Delay Monitoring Services z/OS MVS Programming: Workload Management Services SC34-2663-00 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Why Use the Execution Delay Monitoring ServicesFrom the execution delay monitoring services, workload management knows how well work is executing, and where any delays are occurring. The execution delay monitoring services are for complex work manager configurations that process across systems in a sysplex, but do not allow MVS™ to individually manage resource consumption of the transactions. The services allow MVS to recognize additional address spaces that are processing transactions. When the execution delay monitoring services are used, MVS can allocate resources for address spaces based on the behavior of the transactions being serviced by them. The services also provide execution delay information, so that your customers can determine where work is being delayed. They can then adjust the work manager configuration to consistently meet the goals. Only response time goals can be used with execution delay services. If you need to use velocity goals, discretionary goals, or period switch, consider using enclave services instead. Execution delay monitoring is mutually exclusive with enclaves in the same address space so you must choose whichever function best suits your needs. Enclave services provide more granular resource control and reporting than execution delay monitoring services, but do not provide the capability for the work manager to report its own view of transaction states. The subsystem work manager uses the execution delay monitoring services to tell workload management about their view of the current state of a work request, such as ready state, idle state, or waiting state. The actual state may be different. For example, a work request may be active from the subsystem's view, but might be delayed by a page fault, or for CPU access. The information is kept in performance blocks, also called monitoring environments. The monitoring environments represent work wherever it executes: across multiple dispatchable units, address spaces, and systems. Table 2 shows a summary of the execution delay monitoring services.
|
Copyright IBM Corporation 1990, 2014
|