Switching to Generic RACF Profiles on the MVS North System

The OS/390 standard system that CIT is developing to replace the current MVS North and South systems will focus on the use of generic RACF profiles. CIT is urging all MVS North system users to learn about and use generic RACF data set profiles. One generic profile can cover tens, hundreds, even thousands of similarly-named data sets. A generic profile protects new data sets and provides an access list already in place. This eliminates the need to grant permissions each time a new data set is created. A generic profile is not deleted when a data set is archived but instead remains in place along with its access list, so that if the data set is restored it is properly protected. (See the article, "Switch to Generic RACF Profiles on the MVS North System," in Interface 211, September 1999.)

A difficulty in moving to generic profiles is that the North system uses the automatic data set protection (ADSP) feature, which causes a separate or "discrete" profile to be built each time a data set is created. These discrete profiles always take precedence over any generic profiles. In order to have generic profiles work, you need to do three things:

• Create generic profiles appropriate to your needs. A good discussion of generic profiles is available on the North system Web page http://silkad.nih.gov via the link to "generic profiles."
• Delete similarly-named, existing discrete RACF profiles so that your generic profiles can take effect and cover existing data sets.
• Have your coordinator turn ADSP OFF in your RACF USER profile so that no discrete RACF profiles will be created. The new data sets will be protected by the generic profiles you created.

Commands to Be Used in Creating a Generic Profile

Creating a generic profile—and then deleting existing discrete profiles so that the generic will do the protecting—is straightforward. The following RACF commands can be issued from TSO Ready or ISPF Option 6.

• Add dataset profile (AD)
  To create a generic RACF profile that is applicable to any data set that starts, for example, with "XYZ.EJSPROJ1" and has zero or any number of additional qualifiers, enter the command
  AD 'XYZ.EJSPROJ1.**'
• Permit command (PE)

The PE command is used to put individuals or groups on the access list with either READ, UPDATE or ALTER authority. For example, to give anyone in the group XYZ read authority to any data set that the generic profile "XYZ.EJSPROJ1.**" protects, enter
PE 'XYZ.EJSPROJ1.**' ID(XYZ) ACCESS(READ)
• Search command (SR)
  The following SEARCH command will create a data set containing DELETE commands that can be used as SYSIN input to a BatchTSO job to delete all discrete profiles that match the mask provided.
  SR NOGENERIC MASK(XYZ.EJSPROJ1)
  CLIST('DD ') NOLIST
Qualifiers
• NOGENERIC
  tells the command that you do not want generic profiles considered in the search, only discrete profiles


• MASK
  causes all discrete profiles whose DSN begins with XYZ.EJSPROJ1 to be included.


• CLIST('DD ')
  causes the DSNs found in the search to be put in a data set whose name will be $iii.EXEC.RACF.CLIST (where iii is your RACF ID). Each line in the data set will contain DD 'dsn matching name'. DD is the RACF command for deleting a profile. This data set—if used as SYSIN to a BatchTSO job—will delete all of these matching discrete profiles.



Note: the CLIST data set will be on a scratch pack and will be deleted in 14 days. Also if you run this command again using the CLIST keyword, this data set will be over-written.

• NOLIST
  tells the command not to list matching DSNs on your screen.

JCL for a BatchTSO

Interface 213 (March 15, 2000)