What are the most common causes of ACF2 database contention/enqueue problems?
Article ID: 26461
Updated On:
Products
Issue/Introduction
Documented below are the most common causes of ACF2 database contention/enqueue problems in a shared DASD environment.
Environment
Release:
Component: ACF2MS
Resolution
ACF2 database contention/enqueue problems in a shared DASD environment can be a result of database volume placement or not excluding ACF2 properly with an enqueue-controlling product such as CA MIM or GRS.
To prevent potential ACF2 Database contention problems the following should be done.
Enqueue-controlling Products
Sites using Unicenter CA-MIM and any other enqueue-controlling product should specify the following ENQ resources in their exclude list:
- Exclude the CA ACF2 data set names from the SYSDSN
ENQUEUE so that CA ACF2 can have the databases as
DISP=OLD on more than one CPU. - Exclude the CA ACF2's name from the SYSVSAM
RNAME(ACF2) ENQUEUE. - Exclude CA ACF2's major name, ACFVSAM, to let CA
ACF2 serialize its function in the system, not the entire ring.
Please consult the CA MIM or GRS documentation for details on the syntax for the exclude statements. Here is an example of the MIM EXCLUDE statement:
LOCAL QNAME=SYSDSN,RNAME=your.primary.INFOSTG
LOCAL QNAME=SYSDSN,RNAME=your.primary.LOGONIDS
LOCAL QNAME=SYSDSN,RNAME=your.primary.RULES
LOCAL QNAME=SYSDSN,RNAME=your.alternat.INFOSTG
LOCAL QNAME=SYSDSN,RNAME=your.alternat.LOGONIDS
LOCAL QNAME=SYSDSN,RNAME=your.alternat.RULES
LOCAL QNAME=SYSVSAM,RNAME=your.primary.*
LOCAL QNAME=SYSVSAM,RNAME=your.alternat.*
LOCAL QNAME=ACFVSAM
Where "your.primary" and "your.alternat" are the qualifer levels for the ACF2 primary and alternate database DSNs.
CA MIM NOTE: If running CA MIM in place of GRS, add the NO-SMC attribute to the MIM address space logonid. This will ensure that concurrent security requests in the MIM address space, which require access to the CA ACF2 databases, do not get single threaded and result in possible system suspends. To change this setting in the logonid, the TSO, ACF command processor can be used as follows.
ACF
SET LID
CHANGE logonid NO-SMC
Database Volume Placement
In a shared ACF2 database environment it is recommended that the ACF2 databases should be the only VSAM files on the volume because of potential contention and/or performance problems.
Ensure that the CAACF2 databases are in their own User Catalog (USERCAT). The USERCAT should not contain any other data sets. The USERCAT should not be on the same device as any of the CA ACF2 databases.
For performance reasons, the CA ACF2 clusters should be allocated on a DASD device with minimal I/O activity. In addition, the device should not contain any z/OS master or user catalogs.
The databases when being shared must be:
- A non‑SMS volume with the product databases being the only VSAM files on the volume. Other non‑VSAM data sets can reside on the volume.
- An SMS volume with only the product data base(s) on the volume. No other files are allowed on the volume.
The databases should not be on volumes that are heavily used by any other system tasks, or on any volume subject to extensive I/O. The same consideration should also be given to the placement of the alternate databases. Additionally, do not place the alternate databases on the same volumes as the primary databases.
NOTE: These are the most common causes of database contention problems. If all of the above has been verified and database contention/enqueues are still occurring for the ACF2 databases, the following documentation is
recommended.
- Console log showing any errors, abends or messages related to the contention/ENQUEUE problem.
- Dump of the CA MIM or GRS address space.
- Dump of the address space holding the database ENQUEUE.
Feedback
