Does the new parameter ENQDSN CAIACFxx Parmlib Member alter the way GRS is currently handling the ENQ's?'
search cancel

Does the new parameter ENQDSN CAIACFxx Parmlib Member alter the way GRS is currently handling the ENQ's?'

book

Article ID: 44578

calendar_today

Updated On:

Products

ACF2 ACF2 - DB2 Option ACF2 for zVM ACF2 - z/OS ACF2 - MISC PanApt PanAudit

Issue/Introduction

Does the new parameter ENQDSN CAIACFxx Parmlib Member alter the way GRS is currently handling the ENQ's?'

 

Environment

Release:
Component: ACF2MS

Resolution

The answer depends on a site's current GRS exclude list. 

Specifying the ENQDSN parameter overrides the internal ENQDDN processing. 
Using ENQDSN can help reduce contention for users who run multiple CA ACF2 
databases in the same sysplex and choose to to 'convert the ACFVSAM RESERVE'. 

A sample CA ACF2 exclude list for GRS is constructed as follows: 

* LABEL TYPE, MINOR?LENGTH, MAJOR?NAME, MINOR?NAME 
RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF2.LOGONIDS) 
RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF2.ALTLIDS) 
RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF2.RULES) 
RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF2.ALTRULES) 
RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF2.INFOSTG) 
RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF2.ALTINFO) 
RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(ACFVSAM) 
RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSVSAM) RNAME(ACF2) 
RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSDSN) RNAME(ACF2) 
Note: The last GRS exclude entry can be used if the RNAME is only used with the database clusters. 

The general recommendation is to exclude(Not convert as shown above) ACFVSAM 
however sites wanting to 'convert the ACFVSAM reserve' can remove the following 
line from the GRS exclude list recommendations: 

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

The following applies to sites that do not exclude ACFVSAM and choose to 
'convert the ACFVSAM RESERVE'. 

To simplify the following explanation the following will focus on the 
ACF2 LOGONIDS database but the same holds true for the other two ACF2 
databases. 

Prior to the introduction of the ENQDSN option all the ACFVSAM SYSTEMS ENQ 
requests contained a hardcoded minor name of LOGONIDS. This meant that 
when the ACFVSAM ENQ was no longer excluded from GRS processing, an 
EXCLUSIVE ACFVSAM ENQ would lock out all systems in the GRS ring/star 
configuration even though other systems could be accessing different 
ACF2 LOGONIDS databases due to the hardcoded minor name. 

With the introduction of ENQDSN, the minor name on the ACFVSAM SYSTEMS 
ENQ represents the 44 character database name. The assumption is that 
each set of ACF2 databases will have unique names within the GRS 
configuration. For example you have 2 ACF2 LOGONIDS in a GRS configuration 
of SYS1.ACF2.LOGONIDS.SYSTEMA and SYS1.ACF2.LOGONIDS.SYSTEMB. An EXCLUSIVE 
ACFVSAM ENQ issued by a system against SYS1.ACF2.LOGONIDS.SYSTEMA 
will only cause the systems sharing that specific database to wait for 
the ENQ to be released. The other systems accessing 
SYS1.ACF2.LOGONIDS.SYSTEMB will not be affected by the EXCLUSIVE ENQ. 

The same contention described above for systems running without ENQDSN 
will occur for identically named datasets in a GRS configuration in which 
the databases are actually different. This is because the minor name on 
the ACFVSAM ENQ is only differentiated by the dataset name with the 
ENQDSN option. Those systems accessing the duplicate named dataset(s) 
will wait for the ACFVSAM EXCLUSIVE ENQ to be released even though they 

maybe accessing a direct ACF2 database with the same name.