Is there a way to override the limit of 16 @DDSN entries in the ACFFDR?

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

Description:

We have multiple sysplexes sharing the same ACFFDR. Each sysplex has multiple lpars, each having its own set of ACF2 databases. No databases are shared.

We have reached the maximum of 16 @DDSN entries in the ACFFDR. We need to be able to add new databases. Is there a way to do this without using multiple versions of the ACFFDR?

Solution:

There currently is no way to expand the number of @DDSN definitions in the ACFFDR. It is possible to have a unique ACF2 proc for each lpar that specifies DDNAME overrides for the databases. The DDs in the proc will override any DDSN in the START ACF2,PARM='DDSN...' command and the CAIACFxx members. This would offer a great deal of flexibility, but there are drawbacks: 1) the SWITCH command cannot be used, and 2) system programmers and operators have to know and understand where these overrides are being done. ACF2 initialization messages do identify where the DDs for the databases come from (ACFFDR, proc override, etc), but it may not be obvious to a casual inspection.

Alternatively, if the naming standard for the ACF2 databases includes the system id, $SYSCLONE can be used in the ACF2 proc:

Example:

//RULES DD DISP=OLD,DSN=SYS1.ACF2.SC&SYSCLONE..RULES  
//LOGONIDS DD DISP=OLD,DSN=SYS1.ACF2.SC&SYSCLONE..LOGONIDS  
//INFOSTG DD...     
//BACKLID DD... 
//BACKINFO DD...
//BACKRULE DD...
etc.

This would allow the same ACF2 proc to be used by all the lpars, but each proc would result in a unique set of databases being allocated for the overrides. If this isn't feasible, then each lpar will need a unique ACF2 proc that allocates a set of explicitly named databases and backups.