Managing the SYSDSN qname to protect datasets in a shared DASD environment

Document ID : KB000050805
Last Modified Date : 14/02/2018
Show Technical Document Details

Question:

Resources that are serialized with the SYSDSN qname are generally shared across systems. What is the appropriate manner in which to manage SYSDSN enqs?

Answer:

The SYSDSN qname is used by various IBM dataset allocation modules to serialize access to datasets on DASD. Typically, these datasets are shared across systems. It is important that the SYSDSN qname be properly configured in the resource serialization product that is being used, either the IBM GRS product or the CA MIM product. Proper configuration, and therefore proper serialization, of SYSDSN resources insures data integrity.

When an enq is issued, the enq request must specify a SCOPE value. The 3 possible SCOPE values are STEP, SYSTEM, and SYSTEMS. STEP specifies that the resource can only be used within an address space. SYSTEM specifies that the resource can be used by more than 1 address space within the same system. SYSTEMS means the resource can be shared across systems.

Any resource that is shared across systems should be serialized with an enq that uses SCOPE=SYSTEMS. However, SYSDSN enqs are a notable exception to this rule, and they have been for several decades. IBM owns the SYSDSN qname, and IBM has always used SCOPE=SYSTEM for these requests. This requires special instructions to properly configure the SYSDSN qname when datasets are shared across systems.

In a GRS environment, SYSDSN enqs are managed by specifying the SYSDSN qname in the SYSTEM Inclusion Resource Name List (RNL). GRS will then convert the SCOPE of SYSTEM to SYSTEMS. If there are any exceptions in which an enq should not be propagated globally, the dataset name (rname) is specified in the SYSTEMS Exclusion RNL. The SCOPE on an excluded request will not be converted.

In a MIM environment, SYSDSN enqs are managed by placing SYSDSN in the MIMQNAME list and specifying GDIF=YES with SCOPE=SYSTEM. This has the same result as placing SYSDSN in the SYSTEM Inclusion list in a GRS environment. One notable difference is that MIM does not change the SCOPE from SYSTEM to SYSTEMS. MIM uses its own control block to track an enq request that it is managing, so the corresponding GRS control block (QCB) will reflect the original SCOPE of SYSTEM when MIM propagates an enq. MIM allows for exceptions by providing a GDIEXMPT member in which dataset names (rnames) can be excluded, and this is analogous to the GRS SYSTEMS Exclusion RNL.

To summarize, both CA and IBM recommend that the SYSDSN qname be managed in a shared DASD environment. Both MIM and GRS provide the means to properly configure the SYSDSN qname and allow for any site-specific rname exemptions. The definition varies by product, but the result of globally propagating SYSDSN enqs is the same.