Avoiding RECON data set deadlock situations for serial access mode

To eliminate deadlocks (if you are using implementing hardware reserves for the RECON data sets), the RECON data sets must be the only objects cataloged in their respective catalogs and be on the same device as their catalogs. When the RECON data sets are accessed, an enqueue on the RECON data sets can result, followed by an enqueue on the catalog. When the RECON data sets and catalog are on the same device, the possibility of conflicts with another job enqueuing the devices in reverse order is eliminated.

Give special consideration to the placement of RECON data sets that are shared among multiple processors. During a physical open, DBRC reserves RECON1, RECON2, and RECON3. DBRC determines which are available and which are Copy1, Copy2, and spare. DBRC then closes and dequeues the spare (if it exists) and any unusable RECON data sets. So, during the use of DBRC, two RECON data sets are reserved most of the time. DBRC always reserves both RECON data sets in this order: RECON1 and RECON2. If RECON1 and RECON2 are specified consistently throughout jobs, DBRC does not encounter deadlock.

However, other jobs that reserve multiple volumes can cause deadlock if any of the volumes also contain a RECON data set.

Access to the RECON data sets must be controlled to avoid deadlock. The following z/OS® macros are used to control access to the RECON data sets: RESERVE, GRS, OBTAIN, and DEQ. The z/OS macros, DFP Record Management Services, and RECON data set serialization strategies are discussed in the following list.

• RESERVE

  DBRC issues the z/OS RESERVE macro to serialize access to each RECON data set. DBRC keeps the RECON data sets reserved until it completes its processing. The more RECON records DBRC must examine or change, the longer it holds the RECON data sets. The RESERVE macro serializes access to a resource (a data set on a shared DASD volume) by obtaining control of the volume on which the resource resides to prevent jobs on other systems from using any data set on the entire volume. This reserve is done under the major name DSPURI01 and has a scope of SYSTEMS.

  Batch jobs will serialize on another resource name first, before issuing a RESERVE for the RECON data sets. The resource name for batch is DSPURI02 and has a scope of SYSTEM. Each job gets control of the resource, based on the position of the task's request and whether the request was exclusive or share control. The queue is not ordered by the priority of tasks. The effect of this serialization of batch jobs is that an IMS online region never has to wait for more than one batch job to complete before gaining access to the RECON data set.

• Global Resource Serialization (GRS)
  The GRS macro provides a method of converting a RESERVE request into an ENQ request. The ENQ, DEQ, and RESERVE macros identify a resource by its symbolic name. The symbolic name has three parts:

  • Major name (qname)
  • Minor name (rname)
  • Scope (which can be STEP, SYSTEM, or SYSTEMS)

  For example, on an ENQ or DEQ macro, a resource might have a symbolic name of APPL01,MASTER,SYSTEM. The major name (qname) is APPL01, the minor name (rname) is MASTER, and the scope is SYSTEM.

  When an application uses the ENQ, DEQ, and RESERVE macros to serialize resources, global resource serialization uses resource name lists (RNLs) and the scope on the ENQ, DEQ, or RESERVE macro to determine whether a resource is a local resource or a global resource. Global resource serialization identifies each resource by its entire symbolic name. For example, a resource that is specified as A,B,SYSTEMS is considered a different resource from A,B,SYSTEM or A,B,STEP because the scope of each resource is different. To ensure that resources are treated as you want them to be without changes to your applications, global resource serialization provides three resource name lists (RNLs):

  • SYSTEMS EXCLUSION RNL

    The SYSTEMS exclusion RNL contains a list of resources that are requested with a scope of SYSTEMS that you want global resource serialization to treat as local resources.

  • RESERVE CONVERSION RNL

    The RESERVE conversion RNL contains a list of resources that are requested on RESERVE macros for which you want global resource serialization to suppress the RESERVE.

  • SYSTEM INCLUSION RNL

    The SYSTEM inclusion RNL contains a list of resources that are requested with a scope of SYSTEM that you want global resource serialization to treat as global resources.

    Related reading: See the following publications for more information about GRS and the z/OS RESERVE, DEQ, and ENQ macros:

    • z/OS MVS Programming: Assembler Services Reference Vol 1
    • z/OS MVS Planning: Global Resource Serialization
• OBTAIN

  DBRC uses a VSAM DADSM (Direct Access Device Storage Management) OBTAIN request to the FORMAT-4 DSCB (the VTOC) to force an I/O that insures that DBRC really has the RECON data set reserved in a multisystem environment.

  The OBTAIN macro is not issued if the Synchronous RESERVE (SYNCHRES) option is in effect. The Synchronous RESERVE feature allows specification upon installation of whether the hardware RESERVE should be obtained for a device prior to granting a global resource serialization ENQ.

  The SYNCHRES option can be activated through either the GRSCNFxx parmlib member or the SETGRS operator command. The GRSDEF statement of GRSCNFxx contains the SYNCHRES (YES | NO) parameter. The default value for SYNCHRES is YES. During normal system operation, the operator can modify the setting of SYNCHRES by issuing the SETGRS command. Activate SYNCHRES by issuing SETGRS SYNCHRES=YES and deactivate it by issuing SETGRS SYNCHRES=NO.

• DEQ

  DBRC releases the RECON data sets by using the z/OS DEQ macro.

• DFP Record Management Services

  DBRC uses VSAM services to retrieve, manipulate, and store the RECON data set records. These records have a 32-byte record key.

• RECON data set serialization strategies
  Recommendations:

  • In a GRS Star configuration, a RESERVE CONVERSION RNL should be implemented for DSPURI01 if all systems accessing the RECON data sets are within the sysplex (or GRSPlex).
    Note: If the RECON data sets are accessed by systems that are outside of the sysplex, the reserve must not be converted. A SYSTEMS EXCLUSION RNL must be implemented instead.

    If you implement GRS RNL CONVERSION by adding the QNAME for the RECON data set, DSPURI01, to the conversion list, the hardware reserve is eliminated and replaced by a GRS enqueue that is communicated to all other sharing z/OS systems.

    Other data sets on the same DASD volume can be used while the RECON data set is reserved; this is the benefit of performing the RNL conversion. GRS RNL conversion uses CPU and storage and affects system performance positively. The performance (in terms of least CPU time used, least storage used, and least elapsed time) is best using this option in a GRS STAR configuration.

    To implement this method, follow these steps:

    1. Add the RECON data set QNAME to the RESERVE CONVERSION RNL. For example:

       RNLDEF RNL(CON) TYPE(GENERIC) QNAME(DSPURI01)

    2. Consider carefully the placement of the following VSAM QNAMEs: SYSZVVDS and SYSIGGV2.

    Related reading: For more information on implementing GRS RNL CONVERSION, see z/OS MVS Planning: Global Resource Serialization.

  • In a GRS Ring configuration, a SYSTEMS EXCLUSION RNL should be implemented for DSPURI01 so that the RECON is serialized by hardware reserve.

    If you implement GRS SYSTEMS EXCLUSION RNL, then GRS does not perform global serialization and the RESERVE macro is issued. This might work well provided that the RECON data set is located on a DASD volume that does not contain other data sets that are needed by other z/OS systems.

    To implement this method, follow these steps:

    1. Add the RECON data set QNAME to the SYSTEMS EXCLUSION RNL. For example:

       RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(DSPURI01)

    2. Carefully consider the placement of the following VSAM QNAMEs; SYSZVVDS and SYSIGGV2.

    Related reading:  The z/OS MVS Planning: Global Resource Serialization provides more information about VSAM QNAMEs.