WLM Work Manager Delays

Fabio Massimo Ottaviani
June 2006

Since many years performance analysts look at the WLM General Execution Delay states to understand the reasons why a service class is not getting good performance.

Unfortunately there are situations where most of the delay samples are in the “unknown” bucket (waiting for WLM not managed resources). In this case a further step is needed.

By defining a transaction service class for IMS or CICS transactions it is possible to collect useful information about the delay states experienced inside the subsystems. DB managers such as DB2 and IMS cooperate with the transaction managers providing their delay samples. This information is maintained by WLM and used for managing and reporting purposes.

Since z/OS 1.4 also subsystems using enclaves (such as the Websphere Application Servers) may collect delay states information. Also in this case a transaction service class has to be defined and used in order to collect them. This information is sampled by WLM and used for reporting purposes only.

This paper shortly describes the services used to collect the information, the implications of the different subsystems structure and the meaning of each delay state. Some real life examples showing how to use this information are also presented.