In a shared DASD environment where multiple systems (LPARs) share a common ACF2 database, is it possible to write rules specific to an LPAR?

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

Description:

A site has multiple LPARs sharing a common set of ACF2 databases. When adding another LPAR that will share the same DASD, is there a way to write data set access rules that are specific just for that new LPAR?

Note: if the new LPAR has its own unique ACF2 database then the rules used for validation would be specific to that LPAR. However, with shared DASD, those rules can give users access to data sets that are primarily used by another LPAR.

Solution:

The short answer is no. There is no facility within CA ACF2 to identify a specific LPAR within a data set access rule.
However, there are other features that can be used with CA ACF2 to help isolate access to different system data sets.
For data set access rules, rule sets can specify a specific VOLUME for the data set, restricting access to users authorized to use the data on that volume.

For example, you can restrict access to SYS1.PARMLIB (or any other system library) residing on different system residence volumes. Sample rule entries:

$KEY(SYS1)        
 ... 
 PARMLIB UID(sysa_users) VOLUME(RES00A) READ(A)
 PARMLIB UID(sysb_users) VOLUME(RES00B) READ(A)
 PARMLIB UID(sysprogs) VOLUME(RES***) READ(A) WRITE(A) ALLOC(A)
 PARMLIB UID(*)VOLUME(RES***) READ(P)
 ...

Only authorized system "A" users can read SYS1.PARMLIB residing on the system "A" volume RES00A. Only authorized system "B" users can read SYS1.PARMLIB residing on the system "B" volume RES00B. Users on one system cannot read SYS1.PARMLIB for the other system. Only authorized system programmers have full access to SYS1.PARMLIB residing on any system residence volume (RES***). All other users are denied any access to SYS1.PARMLIB residing on any system residence volume (RES***).

Refer to the CA ACF2 Administrator Guide for additional information on rule writing.