Common User Errors with GDIF Reserve Processing
search cancel

Common User Errors with GDIF Reserve Processing

book

Article ID: 28316

calendar_today

Updated On:

Products

MIM Resource Sharing (MIM) MIM Data Sharing (MII) MIM Tape Sharing (MIA) MIM Message Sharing (MIC)

Issue/Introduction

Management of IBM's reserve processing can be a complex issue. If you haven't reviewed your CA MII Data Sharing parameters recently, now is a good time to verify that these are configured correctly.

This article deals strictly with CA MII reserve conversion processing, not the less complicated global ENQ processing. The intent of this article is to point out some common user errors of reserve conversion processing.

Note that the complete decision process that MII's GDIF component uses when converting a reserve can be found in the CA MII Programming Guide.

There are two pieces to a hardware reserve - an ENQ with SCOPE=SYSTEMS and a UCB specification, which results in a hardware reserve on a device. A hardware reserve can lock up the entire volume until the DEQ occurs. In general, a reserve should be converted if there are other critical data sets on the same volume. It should also be converted if the reserve can cause a deadly embrace, like with SYSIGGV2 during catalog processing. In addition, data set placement is a consideration. If you have a shared application control file on a volume by itself, it may be faster to allow reserve/release processing to serialize the data set. Most applications have their own recommendations regarding whether their reserves should be converted to global ENQs. You should always verify these recommendations with the vendor. 

Environment

Release: MIM for z/OS
Component: MIM, MIC, MIA

Resolution

There are four different ways to handle a reserve:

  1. Keep the reserve and do not propagate the ENQ globally
  2. Convert the reserve and propagate the ENQ globally
  3. Keep the reserve and propagate the ENQ globally
  4. Convert the reserve and do not propagate the ENQ globally

The first two ways mentioned above are the most common. The third way is not recommended because it results in "double serialization" and can cause deadlocks. The fourth way is not recommended because it can result in an integrity exposure. In addition, the last requires the use of a special GDIEXPXT exit routine that cannot be accessed through CA MII parameters.

Let's take a look at the relevant CA MII parameters:

In the MIMINIT/MIIINIT member:
GDIINIT PROCESS={SELECT/ALLSYSTEMS},
        RESERVES={CONVERT/KEEP}

In the MIMCMNDS/MIICMNDS member:
SET GDIF EXEMPTRESERVES={YES/NO}

In the MIMQNAME member:
QNAME123  SCOPE={SYSTEMS/SYSTEM/ALL/RESERVES},
          EXEMPT={YES/NO},
          GDIF={YES/NO},
          RESERVES={CONVERT/KEEP}

In the GDIEXMPT member:
DEFAULT  RESOURCE={LOCAL/GLOBAL},JOB={LOCAL/GLOBAL}
LOCAL   QNAME=QNAME123 RNAME=TEST.DATASET
GLOBAL  QNAME=QNAME123 RNAME=TEST.DATASET2 RESERVES={CONVERT/KEEP}

The RESERVES parameter can be specified in three different parmlib members, which can be confusing. The entry in the EXEMPT member overrides the entry in the QNAME member that overrides the entry in the INIT member. However, CA MII will not even look at the EXEMPT member entry unless EXEMPT=YES is coded on the relevant QNAME statement.

Coding RESERVES=KEEP in any of these three parmlib members is not recommended because "double serialization" can occur if you are not careful. Double serialization can cause the deadlocks described in #3 above. For example, consider the following QNAME statement:

QNAME123 SCOPE=SYSTEMS EXEMPT=NO GDIF=YES RESERVES=KEEP

If a RESERVE were issued for QNAME123, CA MII would send a transaction outbound and notify all other systems about this ENQ. The reserve would not be converted because RESERVES=KEEP is specified. Therefore, you are wasting CPU, delaying the ENQ and creating a possible deadlock.

Also, the RESERVES parameter is not valid on the LOCAL statement in the EXEMPT list. By default, the LOCAL statement does not apply to hardware reserves, only ENQs. If you need to keep certain resources LOCAL (in other words, you do not convert and do not propagate the ENQ globally), you need to specify SET GDIF EXEMPTRESERVES=YES (CA Best Practice) in the CMNDS member. If EXEMPTRESERVES=NO is coded, CA MII will ignore the LOCAL statement and do whatever the DEFAULT statement tells it to do, which in most cases is to make the request GLOBAL. Most sites run with DEFAULT RESOURCE=GLOBAL JOB=GLOBAL.

LOCAL statements in the EXEMPT list that apply to hardware reserves are a special case. For example, even if RESERVES=CONVERT were coded in the previous QNAME entry or INIT member, CA MII Data Sharing will still KEEP the reserve if a matching LOCAL statement is found and SET GDIF EXEMPTRESERVES=YES.

CA recommends that you review the CA MII parameters and verify that you have correctly set up CA MII. By setting up CA MII properly, you may be able to reduce CPU usage and prevent possible deadlocks on your systems. If you need assistance with coding the CA MII parameters, converting to ALLSYSTEMS mode, or desire an environmental assessment, please contact the CA MIM Customer Success Team.

Additional Information

Powered by Wolken Software