RLS Catalog Justification

Serialization of disk resources (data sets) is a necessary evil in any multi-tasking, multi-user, multi-system environment, so the less time you spend performing serialization, the better. Over the decades, z/OS serialization has gotten more refined. Starting with Volume Reserve, moving to Systems Enqueue and most recently Record Level Sharing (RLS), each refinement is designed to allow a greater level of resource sharing across a multi-tasking, multi-user, multi-system environment.

Serialization protects the integrity of a data set in a shared disk environment. It has been said that the only thing worse than shared disk is unshared disk. A shared disk allows all systems to access the most recent, up to date version of the data set. The alternative to shared disk is copies of the same data set for each system, with the new versions being distributed as updates that are coordinated across the systems. Sharing data on unshared disk requires more disk space, network bandwidth, and the overhead of a coordinated update to keep all copies in sync.

Use of Volume Reserve

Use of Volume Reserve prevents all updates to the disk volume and will lock out all access to the systems that did not issue the reserve until the reserving system releases the volume. Protecting the resource may mean that jobs on other systems will be delayed, even if they want to access other data sets that happen to reside on the reserved disk volume. As you might imagine, the larger the capacity of disk volume used, the more data sets are likely to reside on that volume and the greater pain is if reserve is issued. Reserve contention is included in PEND time of Disk service and response time. IntelliMagic Vision includes this component of PEND time as a metric named Device Busy Delay.

Use of a Systems Enqueue

Use of a Systems Enqueue involves the use of a serialization manager like Global Resource Serialization (GRS) or Multi-Image Manager (MIM). These managers largely work as request registration systems. They receive the request, check to see if a prior request is still active, check the nature of the present use (none/read/write/update) against the requested use (read/write/update) and either allow the access or queue the request until the present access completes. The request is called an ENQ, and completion is called a DEQ. ENQ/DEQ activity identifies a specific resource using a Major Name and a Minor Name. Requesting access to a resource and the time spent being queued because of an existing ENQ is called Contention Time. The existing ENQ is called the owner and the requesting ENQ is called the requestor. ENQ/DEQ activity is recorded by RMF in the SMF record type 77.

RLS Catalogs

Record Level Sharing (RLS) was developed for VSAM data sets and makes Coupling Facility structures (consisting of a cache structure and the IGWLOCK00 lock structure) and the system address space SYSVSAM responsible for serialization. Each system in the sysplex has its own SYSVSAM address space and they all share the same Coupling Facility structures. This implementation removes the need to use Reserve/Release or ENQ/DEQ to access the data set for any reason. When estimating the positive impact of implementing RLS Catalogs, you need to either look at the Device Busy Delay (if Volume Reserve is being used) or (more likely) look at the contention time for major name SYSIGGV2 and the catalog name is the minor name for ENQ/DEQ.

Below are sample reports for GRS Contention time reported by IntelliMagic Vision. First is a Contention Rate events report. As you can see, the major name SYSIGGV2 has the highest number of contention events.

Next, we want to look at Contention Times (how long does the contention last). From this chart, you see that the fourth highest contention time is attributed to SYSIGGV2. The bar labeled SYSIGGV2 shows the total contention time for Catalog ENQ/DEQ (for the selected timeframe).

The next chart will take the selected drilldown to Minor Names and select the Major Name SYSIGGV2.

This chart shows the contention by User catalog.

In this environment, it is apparent there are only two user catalogs with any real contention and the rest have little to no contention.

Conclusions

Based on the evidence provided by the first chart of event rate per second, Catalog (or more accurately SYSIGGV2) is GRS’s best customer. The second chart shows the overall benefit of eliminating ENQ/DEQ for catalog activity by calculating contention time that would be removed if RLS catalog is implemented. And lastly the third chart shows, not all catalogs benefit equally, so you could focus the conversion to the catalogs with the highest contention time.

Summary

This blog demonstrates determining initial benefits of RLS Catalog Conversion, shows how to find the higher value targets for implementation as well as the ability to monitor all ENQ/DEQ activity with IntelliMagic Vision.