Potential problems when using RESERVE
- Lack of granularity: When a task on one system has issued a RESERVE macro to obtain control of a data set, no programs on other systems can access any other data set on that volume. Protecting the integrity of the resource means delay of jobs that need the volume, but do not need that specific resource, as well as delay of jobs that need only read access to that specific resource. These jobs must wait until the system that issued the reserve releases the device. Even if the owning task only needs to read the data, no programs on other systems can read the data.
- Starvation: From the hardware control
unit perspective, only one system can RESERVE the volume at one time. z/OS's RESERVE processing
holds onto the volume RESERVE when there are outstanding RESERVE requests from the local system. As
such, there is no RESERVE fairness across z/OS® images and a
single system can monopolize a shared device when it encounters multiple reserves for the same
device. No other system can use the device until the reserving system releases the device.
Example: S1 (system 1) issues a RESERVE for a resource with qname,rname (Q1,R1) on V1 (volume 1). S2 (system 2) then issues a RESERVE for (Q2,R2) on that same volume. S1 then issues a RESERVE for resources (Q3,R3), (Q4,R4), (Q5,R5), (Q6,R6),... (Q99,R99), all on V1, which it already owns. It does not matter that S2 made the second request. It does not matter if the majority of the RESERVE requests are DEQed. S2 cannot access that volume until there are no outstanding RESERVEs on S1 for V1.
- Volume
hierarchy deadlock: The installation must manage the full list
of all volumes potentially reserved and pay particular attention to
any application that requires more than one at a time. Regardless
of the underlying qname and rname resource names, mixing the order
of reserves on volumes can cause an interlock (also called a deadlock),
which is an unresolved contention for use of a resource.
Example: S1 requires a resource with qname,rname of (Q1A,R1A) on V1, then (Q1B,R1B) on V2. S2 requires resource (Q2A,R2A) on V2, then (Q2B,R2B) on V1. Even though the qname,rname pairs are all completely different, the order of reserved volumes have been reversed. If these four resource requests had been converted to global ENQs, there would be no contention at all. If they are left in the current order as reserves, they can deadlock. S1 reserves V1, S2 reserves V2, and neither system will be able to complete its second reserve. Reserve processing requires that the installation know the order of all reserve requests from all applications.
- Asynchronous
I/O deadlock: The actual first I/O to the volume can occur asynchronously
to the RESERVE service completing successfully. Even if the installation
maintains the volume hierarchy, it is possible for a deadlock to occur.
To prevent this from happening, use the SYNCHRES=YES parameter, an
option in GRSCNFxx that is dynamically adjustable through the SETGRS
system command. For more information, see Understanding the synchronous RESERVE feature.
Example: Neither system S1 or system S2 have the SYNCHRES option on. There are two shared volumes, V1 and V2. An application running on both systems requires resources on both V1 and V2, and issues a RESERVE for them in that order. The application gets control back from Global Resource Serialization on both images before any I/O occurs; as if both S1 and S2 have exclusive control of both resources. However, the race condition on those first I/O requests gives resource V1 to system S1 and resource V2 to system S2. Due to S1's I/O request on V2, and S2's I/O request on V1, the application becomes locked out on both images. If the installation had SYNCHRES activated on S1 and S2, this scenario would not occur.
- Double serialization contention and deadlock: Global Resource
Serialization processes a corresponding ENQ request with every RESERVE.
When Global Resource Serialization is in ring or star mode, that ENQ
defaults to being scope=systems, causing unnecessary contention. In
certain scenarios, the double serialization can also deadlock. Global
Resource Serialization provides the installation with the choice of
converting the RESERVE request into being only a global ENQ, or alternately
demoting the corresponding ENQ to scope=system and keep the RESERVE.
This is typically done through RNL processing.
Example: S1 issues a RESERVE with qname,rname (Q1,R1) on V1, gaining both the global ENQ and the reserve. S2 issues a RESERVE for (Q2,R2), also on V1. The application obtains the global ENQ for (Q2,R2), but not the reserve. S1 then issues a RESERVE with qname,rname (Q2,R2) for V1. Although S1 already owns the entire volume, the global ENQ for (Q2,R2) is already held. This is not a volume hierarchy problem because there is only one volume involved. If both resources were made scope=system, or both converted to being only global ENQ requests, this scenario would not occur.
- Data integrity exposure upon system reset: A system reset while a reserve exists terminates the reserve. The loss of the reserve can leave the resource in a damaged state if, for example, a program had only partly updated the resource when the reserve ended. This type of potential damage to a resource is a data integrity exposure.
- Compounding problems: Often when an installation encounters one of the problems listed above, it compounds them into several, and any deadlocks from reserved volumes can expand to an increasing number of tasks.