Selecting user IDs and group names

In your installation it might be enough for you to isolate development work from production. On the other hand, it might be more practical for you to define many individual users and groups. In either case, you should take a look at what already exists and modify RACF® to adapt to the current environment. For example, do any or all of the system users already have user IDs? If so, perhaps you can make use of them. For example, every data set name has its owner's user ID as its high-level qualifier by default.

Batch Users: Batch users might not already have user IDs. Here, you might consider assigning user IDs based on personnel number or, if appropriate, group name. If it is not clear what to use as a user ID, start by considering group names. Again, examine what already exists:

Is there an existing organizational structure that has groups with suitable abbreviations? Can the existing structure be used as is, or modified to suit?
What conventions already exist in job statements? It is common for the first few characters of the job names to be meaningful in terms of an application name, project, department, or some other such functional group. Could these be used as group names, or even a user ID? Are there any other fields in the job statement (for example, the account number or programmer name) that could be used? That is, could you determine from a job statement to whom or to what functional group the job belongs? (Note: The ability to derive a user ID or group from existing job statement information can be a significant migration aid. It could help you avoid the administrative effort of adding the USER= operands to existing job statements.)
Look at data set names to determine the local naming conventions for data sets. Can you determine to which functional group a data set belongs by looking at the name? Can you say "This is an IMS™ database," or "This data set belongs to the payroll group"?
It is likely that several naming conventions already exist. RACF options enable you to handle most existing variations.

Whatever you choose, consider carefully the longer term security objectives. Adding new groups and users to an existing structure presents few administrative problems. Even deleting users and groups can be done without much difficulty. However, a major reassignment of user IDs and group names, although possible, is best avoided by careful initial selection.