When updating thousands of LID records, what considerations are there so the ACF2 database is not overloaded? Are there any performance considerations?
Making changes to the LID database in small batch jobs during off hours is imperative in order to not overload the database.
A suggestion to ensure issues don't arise when sharing the ACF2 databases between multiple LPARs, please make sure the ACF2 databases are excluded from GRS or MIM if your site uses one of these products to manage enqueue. This is to avoid locking the database as ACF2 already has its own mechanism for controlling the queue.
Example for GRS exclusions:
* 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)
Example for MIM exclusions:
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
If the size of the database is a concern, the ACF2 databases are standard VSAM files, so running the VSAM IDCAMS utility and doing a LISTCAT against the databases will display the space utilization.