Solving the RESERVE problems

One major purpose of global resource serialization is to eliminate the need to protect data sets on shared DASD volumes by issuing a RESERVE macro that causes a reserve of the entire volume. Some installations make it their policy to never issue a reserve.

You can use the following commands to determine which system is holding a RESERVE:

DISPLAY U
DEVSERV PATH

You can also issue D GRS,DEV=ddd command, to see if this system holds reserve on a device.

To use these commands, see z/OS MVS System Commands.

When considering the conversion of reserves to global ENQs, there are some restrictions:

Outside the complex: Do not convert a reserve for a resource on a volume if any system in your complex shares the volume with a system that is not part of the complex (or is part of another complex). This case can be particularly relevant for star mode where the global resource serialization complex must equal the parallel sysplex, or if the global resource serialization complex shares resources with another type of system. Some installations choose data transfer and duplication over the use of reserves here.
Inconsistent qnames and rnames: Do not convert the reserve for a resource when different systems in the complex use different names for that resource. This inconsistency can occur when the resource name includes system-dependent information, such as control block addresses. Global resource serialization assumes that the different names represent different resources, and it cannot protect a single resource known by different names. Programs could be modified to use a consistent naming convention, either as reserves to be converted, or simply as global ENQs.
One reserve, multiple resources: An application might be using a RESERVE against multiple resources while another application uses another form of serialization, such as multiple ENQs for resources that all exist on the same volume (this is not recommended). The first application could take advantage of owning the entire volume. This is similar to the inconsistent qname and rname restriction. Before converting this RESERVE, the installation must understand all the resources it serializes and set up consistent qname and rname conventions for all applications to share it.
Ring performance: Do not convert the reserve on a ring-mode global resource serialization complex when it would adversely affect system performance. Your installation might have applications where dependencies on quick access to a resource outweigh the additional availability resulting from converting the reserve. Because of the lack of granularity and starvation issues of reserve processing, this pertains to resources that are obtained and released quickly. This restriction is not applicable to star mode. See RNL candidates for basic recommendations.

The ENQ/DEQ/RESERVE monitor tool can help identify current RESERVEs on a system. For more information, see Using the ENQ/RESERVE/DEQ monitor tool. Once the installation has chosen which RESERVEs to convert, it is typically accomplished through RNL processing. For more information, see Selecting the data.

Many installations use job scheduling instead of a reserve to protect the integrity of data sets on shared DASD volumes. That is, jobs that need the same data set are assigned to the same job class and run at different times. Protecting resources by job scheduling works, but it complicates operations, might increase job turnaround time, and might reduce the additional workload your installation can handle.