z/OS MVS Programming: Workload Management Services
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 Services

From 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.

Table 2. Execution delay monitoring services
ServicePurposeInformation
IWMWQWRKIdentify where transactions are executing.IWMWQWRK – Query Work Service
IWM4ECRECreating an enclave.IWM4ECRE macro — Create Enclave
IWM4EQRYQuerying enclave attributes.IWM4EQRY macro — Enclave Query
IWM4MABNIndicate that an abnormal event has occurred for the work request represented by the input monitoring environment.IWM4MABN macro — Monitor environment abnormal event
IWM4MCHSRecord the state (such as ready, waiting, idle) of a work request.IWM4MCHS macro — Change State of Work Request
IWM4MCRECreate a monitoring environment, also called performance block.IWM4MCRE macro — Create delay monitoring environment
IWM4MDELDelete a delay monitoring environmentIWM4MDEL macro — Delete delay monitoring environment
IWM4MINIInitialize monitoring environment with information about a work request.IWM4MINI macro — Monitor environment initialization
IWM4MNTFNotify MVS that the execution phase for a work request associated with a monitoring environment has just completed.IWM4MNTF macro — Notify of work execution completion
IWM4MRLTRelate two different monitoring environments that are associated with the same work request.IWM4MRLT macro — Relate monitoring environments (PBs)
IWM4STBGBeginning a request from a caller's work manager queue.IWM4STBG macro — WLM Begin Server Transaction Service
IWM4MSTOStop a work unit which has been started by IWM4MSTR.IWM4MSTO macro — Stops a Work Unit
IWM4MSTRIndicate that a work unit is beginning execution.IWM4MSTR macro — Indicate the start of a work unit
IWM4MSWCReflect that the delay information for a work request may now also reside in another monitoring environment which is not Related to the current environment (Continue) OR that there is no further information for the current work request beyond the current environment (Return).IWM4MSWC macro — Monitoring environment switch
IWM4MUPDUpdate data about a work unit which has been started by IWM4MSTR.IWM4MUPD macro — Updates Data of a Work Unit
IWM4MXFRThe purpose of this service is to reflect that the delay information for a work request may now also reside in a dependent monitoring environment (CONTINUE) OR that delay information is no longer present in a dependent monitoring environment (RETURN).IWM4MXFR macro — Monitoring environment transfer
IWM4MXTRExtract information about the monitoring environment which was previously passed through IWM4MINI/IWM4MRLT.IWM4MXTR macro — Monitor environment extract service
IWM4RPTThe primary purpose of this service is to allow MVS to obtain the total response time for a completed work request and its corresponding service class and (when customer specified) its report class.IWM4RPT macro — Report response time

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014