Establishing your RACF group structure

You should map your groups to your organization's structure and arrange them hierarchically so that each group is a subgroup of some other group. The group SYS1 is predefined as the highest group in the hierarchy. You should document the resulting group structure as part of the implementation plan. You might want to develop a set of guidelines for your delegated security and group administrators to identify the general categories of resources and users, and the relationships between them.

For groups that might become large, and for which a quick listing of members is not needed, you might want to consider defining the groups using the UNIVERSAL operand of the ADDGROUP command. See Defining large groups with the UNIVERSAL attribute.

Figure 1 shows relationships that can exist between users and groups.

Figure 1. User and group relationships

In Figure 1:

The users' default groups are their owning groups.
Groups X and Y exist and are owned by GROUP1.
Group Z exists and is owned by GROUP2.
The highest level group, SYS1, owns subgroups GROUP1 and GROUP3 and the user IBMUSER.
GROUP1 owns subgroup GROUP2 and the users USER1 and USER2.
USER1 is connected to GROUP1 with group-SPECIAL authority. This gives USER1 (who is a RACF® administrator) control over GROUP1's resources and resources in GROUP1's scope, but not over GROUP3's resources.

Note: If you run with list-of-groups checking inactive (that is, with the SETROPTS NOGRPLIST option in effect), the scope of USER1's group-SPECIAL attribute is limited to his default group or the group he specified when logging on, and the groups below that group in the hierarchy. For more information on list-of-groups checking, see Activating list-of-groups checking (GRPLIST option).