Data set naming conventions and RACF

Very briefly, the rules for OS/390 data set names are these:

򐂰 A name is up to 44 characters (upper case, counting periods), separated into qualifiers of no more than 8 characters separated by periods. For example, XXX.YYY.AAA.BBB is a

valid name, with four qualifiers. The high level qualifier (HLQ) is XXX. The names XXX.YYY.abc.CCC and XXX.ABCDEFGHIJ.ZZZ are invalid; one contains lower-case characters and the other contains a qualifier than is longer than eight characters.

򐂰 Single-qualifier names are strongly discouraged.

򐂰 There is no inherent meaning to a name. In the PC world, for example, game.exe indicates an executable file; there is no equivalent naming requirement for OS/390. A data set named XXX.YYY might contain executables, or C source, or REXX commands, it might be a library, or it might be a simple sequential file, and so forth. Names do not mean anything.12

򐂰 There are naming conventions, not automatically enforced by the system. The conventions are a little fuzzy, but can usually be recognized. Common conventions include:

– An HLQ should be a userid or group name.

– The letters LIB somewhere in a lower-level qualifier usually indicates a library (PDS or PDSE).

– Qualifiers of CNTL, JOB, or JCL usually indicate JCL and utility programs.

– Qualifiers of COB, COBOL, C, ASM, FORT, and so forth, usually indicate source code (possibly with JCL mixed in).

– Qualifiers of OBJ or OBJECT usually indicate compiler output (before linking). – Qualifiers of LINKLIB, LOAD, LOADLIB indicate a library of executables. – A qualifier of CLIST usually indicates a TSO or REXX command script.

There are only two significant goals for the names. They should indicate the nature of the data set, within reason, and they should meet your security naming requirements.

By default, OS/390 does not protect data sets. By default, any user can create a data set with any name he chooses, and place it on any disk volume that has space. This degree of freedom may be acceptable (but not necessarily desirable) for very small installations. In practice, we need some amount of data set protection—if only to prevent accidental erasure of key system data sets.

The release 10 AD system contains a number of RACF profiles to protect data sets, including:

򐂰 A generic profile for SYS1.* with UACC(READ). This protects key system data sets such as SYS1.PROCLIB, and permits all users to read them. User P390 and any member of group SYS1 are permitted ALTER access. (The inclusion of SYS1 is possibly too broad, since this is the default group for any new user.)

򐂰 Many profiles for product data sets, with UACC(READ). These have no permitted users with higher levels of access. Of course, a user with RACF OPERATIONS privileges can alter any of them. Userids P390 and IBMUSER have this privilege and would normally be used to make changes to various products included with the system.

򐂰 A generic profile for USERCAT.* with UACC(READ), which protects the user catalogs distributed with the system.

򐂰 A number of data set profiles that appear to serve no useful purpose and were probably left over from system testing.

򐂰 No data set profiles for any of the common, supplied userids, such as P390, P390A, P390B, and so forth. There is a profile for IBMUSER.* with UACC(READ).

In summary, there is reasonable protection for the system itself (except for the master catalog, as discussed in “Protecting the catalogs” on page 86), but not for anything else. Therefore, you need to plan your own data set protection and you can assume you are starting from a relatively clean RACF position.

An ideal situation would be something like this:

򐂰 You have a number of users: joe, patti, chris, and bill. When you create each userid, you create a generic data set profile for that userid:

AD ‘joe.*’ OWNER(p390) UACC(read) GENERIC AD ‘patti.*’ OWNER(p390) UACC(none) GENERIC AD ‘chris.*’ OWNER(p390) UACC(read) GENERIIC and so forth

򐂰 You create groups with the names of your major projects: payroll, secret1, projectx, bigbucks, and so forth. When you create each group, you create a generic data set profile for that group name and permit members of the group appropriate access:

AD ‘payroll.*’ OWNER(p390) UACC(none) GENERIC PERMIT ‘payroll.*’ ID(payroll) UACC(ALTER) AD ‘secret1.*’ OWNER(p390) UACC(none) GENERIC PERMIT ‘secret1.*’ ID(secret1) UACC(ALTER) AD ‘projectx.*’ OWNER(p390) UACC(read) GENERIC PERMIT ‘projectx.*’ ID(projectx) UACC(ALTER) and so forth

򐂰 In every case you select a UACC of alter, read or none, as appropriate. The OWNER can be the target userid, but it is typically the system administrator in simple cases.

򐂰 You connect users to groups, as required:

CONNECT joe GROUP(payroll) AUTHORITY(CREATE) CONNECT joe GROUP(projectx) AUTHORITY(CREATE) CONNECT patti GROUP(secret1) AUTHORITY(CREATE) and so forth

򐂰 You create a user catalog, and create an ALIAS in the master catalog (pointing to the user catalog) for every userid and groupid that you create.

򐂰 You protect the master catalog with UACC(READ). (This is awkward to do for the AD system, for reasons pointed out in “Protecting the catalogs” on page 86.

With this arrangement, all the data sets on your volumes should have an HLQ that matches a userid or groupid.13 All these data sets will have basic protection provided by the generic profiles for the HLQ. If a user needs access to another project, this is done with a single

CONNECT to make the user a member of the group that deals with the appropriate project. Situations are seldom as clean as this, so you may need a few individual PERMIT commands, such as:

PERMIT ‘projectx.*’ ID(bill) ACCESS(read)

Ideally, your goals might be as follows:

򐂰 Have as few RACF data set profiles as possible, consistent with protecting your data. Fewer is better because it is much easier and cleaner to administer over time.

򐂰 Discourage users from entering their own RACF data set protection commands. Any user can enter AD and PERMIT commands to protect data sets whose HLQ matches his userid. Over time, this can create large numbers of profiles that are difficult to clean up and control. It might be best if normal users are unaware that they can issue RACF commands.14

13 _{If the master catalog can be protected to be read-only, the inability of normal users to catalog data sets in the master catalog would}

discourage them from creating data sets with unplanned HLQs.

14 _{There are many ways a system owner can control the availability and effect of RACF commands. However, the purpose of this}

document is to discuss using the AD system in a fairly simple environment. Administrators with the skills to highly customize the RACF command environment will probably not be reading this document.

򐂰 Attempt to have PERMIT commands reference group names instead of individual users. However, do not create unreasonable numbers of groups solely for this purpose. You will always have some PERMIT commands for individual users.