To open a catalog as a data set, you must have ALTER authority and APF authorization. When defining an SMS-managed data set, the system only checks to make sure the user has authority to the data set name and SMS classes and groups. The system selects the appropriate catalog, without checking the user's authority to the catalog. You can define a data set if you have ALTER or OPERATIONS authority to the applicable data set profile.

Deleting any type of RACF-protected entry from a RACF-protected catalog requires ALTER authorization to the catalog or to the data set profile protecting the entry being deleted. If a non-catalog data set is SMS-managed, RACF® does not check for DASDVOL authority. If a non-catalog, non-SMS-managed data set is being scratched, DASDVOL authority is also checked.

Altering the passwords in a RACF-protected catalog entry requires ALTER authority to the entry being altered, or the OPERATIONS attribute. ALTER authority to the catalog itself is not sufficient for this operation.

For ALTER RENAME, the user is required to have the following two types of authority:

1. ALTER authority to either the data set or the catalog
2. ALTER authority to the new name (generic profile) or CREATE authority to the group.

Be sure that RACF profiles are correct after you use REPRO MERGECAT on a catalog that uses RACF profiles. If the target and source catalogs are on the same volume, the RACF profiles remain unchanged.

REPRO MERGECAT will preserve RACF discrete profiles when the target and source catalog are on different volumes. Profiles will be updated with the target volume, except when the protected data set is DFSMShsm migrated. Profiles for DFSMShsm migrated data sets must be manually changed using RACF commands. Be sure to verify the integrity of discrete profiles after MERGECAT. You should use generic profiles to avoid this situation.

Note that if you run RACF in "warn" mode, you may receive indications of access violations. Catalog processing uses two-step verification for many types of functions. The first test checks to see if the user has authority to the specific data set. If this request fails the security check, the system will attempt to verify if the user has the appropriate authority to the containing catalog. If this request succeeds, the access is granted. However, in warn mode a message will be produced for the first security check that failed, even though the user passes the stated security checks for the access. These messages can be ignored, as they will disappear when RACF is no longer running in 'warn' mode.