Analyzing the data

The MVSPM Applications Waiting on ENQs, Worst Case report shows the number of applications and system functions waiting for the major enqueued resources.

Figure 1. MVSPM Applications Waiting on ENQs, Worst Case report
MVSPM Applications Waiting on ENQs, Worst Case report

Use this report to identify contention for serialized resources. The z/OS enqueue mechanism provides integrity by serializing user access requests to these resources. The number of applications waiting represents the number of users who are swapped in and cannot be dispatched because the resource they need is being held by another user.

Some applications use major names to control their users. This may have an impact on the interpretation of this report. Each major name displayed shows the number of users waiting or using this resource and being controlled by the application. To understand the difference, you must define each major name to either a system function or an application requirement.

Sometimes, when there are other bottlenecks in the system, you may see MPL spikes on the enqueue resource queue, due to a sudden release of multiple users that were being help up. When a job on one system holds onto a DASD device and work on another system needs that device, a whole flurry of requests often go out to enqueued resources, such as RACF, when the second system gets access to the DASD.

Once you have identified a critical resource, such as a serially reusable resource that can be requested on either an exclusive or shared basis, your organization can improve the situation in many ways. You could change the hardware configuration to release device bottlenecks, change data set placement, reschedule jobs to improve throughput, or specify again the enqueue residence value (ERV) installation tuning parameter to give more processor time to the holder of the resource.