If you are using CMS file‑level protection, CA ACF2 for VM performs at least two validations. One when a user LINKs a minidisk against a VM minidisk rule entry, and the other when the user opens a file or performs the first I/O operation against a file.
The net result is that you have combined rules and separate rules depending on the type of files being accessed. For example, consider a user requesting access to the following data:
VSAM Files: TAX.MASTER.INDEX on PAYROLL 0201 minidisk
TAX.MASTER.DATA on PAYROLL 0202 minidisk
CMS Files: CALCTAX MODULE on PAYROLL 0192 minidisk
TAX TABLE on PAYROLL 0193 minidisk
First, LINK to the minidisks. The LINK commands then generate the following DSNs:
PAYROLL.V0201.VOLUME PAYROLL.V0202.VOLUME PAYROLL.V0192.VOLUME PAYROLL.V0193.VOLUME
If the files were opened or an I/O operation occurred against them,
CA ACF2 for VM generates the following DSNs:
TAX.MASTER.INDEX TAX.MASTER.DATA PAYROLL.V0192.CALCTAX.MODULE PAYROLL.V0193.TAX.TABLE
Taking the above DSNs and assuming that you did not use masking, your rules need to have the following DSNs:
$KEY(PAYROLL) V0192.CALCTAX.MODULE V0193.TAX.TABLE V0201.VOLUME V0202.VOLUME V0192.VOLUME V0193.VOLUME $KEY(TAX) MASTER.INDEX MASTER.DATA
The VM minidisk access and CMS file rules are covered in one rule set based on who owns the minidisk. For the VSAM files, there are two rules involved. The PAYROLL rule covers the minidisk access, and the TAX rule covers the VSAM file access. This is because of the need to be compatible with CA ACF2 for VM for OS/390 where typically the high‑level index determines file ownership. A good example is how CA ACF2 for VM for OS/390 generates TSO DSNs based on the logonid as the high‑level index. However, by carefully choosing filenames, you can cover all of the accesses with one rule, for example, if you renamed the TAX.* files to PAYROLL.*.
|
Copyright © 2009 CA Technologies.
All rights reserved.
|
|