Creating global access checking table entries

To create an entry in the global access checking table:

Plan the entries for the global access checking table, using the following guidelines:
1. Identify resource profiles that are accessed frequently and for which a performance benefit is desired.
2. If there are resource profiles with UACC other than NONE, consider adding similar entries to the global access checking table. Using this "matched pair" approach, each entry would have the same name as a profile, and the access specified in the entry would generally match the UACC of the profile. Do not add a global access checking table entry if any of the following are true:
  - The profile has a security level, security category, or security label (other than SYSLOW).
    Note: If the profile has a security label of SYSLOW, the global access checking table entry can have an access of READ.
  - The profile has an entry in the standard access list that is lower than the access level of the global access checking table entry.
  - The profile has an entry in a conditional access list that is more restrictive than the access level of the global access checking table entry.
  - The profile requests auditing of successful access attempts at or below the level specified in the corresponding global access checking table entry.
  For example, if you have a data set profile PHONE.DIRECT with UACC(READ) and AUDIT(FAILURES(UPDATE)) specified, you might create a global access checking table entry for it as follows:
```
RALTER GLOBAL DATASET ADDMEM('PHONE.DIRECT'/READ)
```
  However, if there are users or groups in the standard access list of profile PHONE.DIRECT with an access authority of NONE (which is lower than the UACC), do not create a global access checking table entry. A global access checking table entry would allow these users and groups to read the phone directory.
3. If you have resources that are protected by a generic profile with UACC other than NONE, and others that are protected by a more specific (generic or discrete) profile that has specific access requirements such as an access list, consider adding two entries: one for the larger set of resources (with access authority equal to the UACC of the profile) and the other for the smaller set of resources (with access authority of NONE).
  For example, if you have a profile of SYS1.** with a UACC(READ), but you also have some specific profiles with more restrictive entries, such as SYS1.XYZ with UACC(READ) and an access list with JOE/NONE, create two entries:
```
SYS1.XYZ/NONE
SYS1.**/READ
```
  The entry with /NONE does not fail any attempts but stops requests for SYS1.XYZ from being granted by the SYS1.** entry.
See the examples later in this topic for other possible entries.
Add the resource class to the global access checking table using the RDEFINE command with the GLOBAL operand and the class name:
```
RDEFINE GLOBAL classname
```
To allow global access checking for a specific resource, add an entry to the global access checking table using the RALTER command as follows:
```
RALTER GLOBAL classname ADDMEM(resource-name/access-level)
```
where:
resource-name
is the equivalent of a profile name in the class specified. If generic command processing is in effect for classname (through the SETROPTS GENCMD command), resource-name on the ADDMEM operand can include the generic characters *, **, or %. In general, the rules for specifying these characters are the same as the rules for specifying these characters in generic profile names except that generic characters are allowed in any qualifier (even if not allowed in certain qualifiers of the profile names).
After they have been added, generic entries in the global access checking table are used in global access checking even if generic profile checking is turned off (through the SETROPTS NOGENERIC command).
The resource name can include the name qualifiers &RACUID (RACF® user ID) or &RACGPID (current connect group). For example, the following entry allows users to have ALTER access to data sets that begin with their own user IDs.
RALTER GLOBAL DATASET ADDMEM('&RACUID.**'/ALTER)

Note: This entry does not change a user's access to his or her own data sets, but speeds the process by which RACF grants the access. (It also prevents any auditing of such access attempts.)
The resource name can also include variables defined in the RACFVARS class. Note that when defining a resource name for a profile in a mixed-case class, you must enter the character strings &RACUID, &RACGPID, and any RACFVARS variable names in upper case. For more information on RACFVARS usage, see Using RACFVARS with mixed-case classes.
The qualifier &RACGPID allows the user's current connect group to be used in the same way. For example, the following allows all users to have READ access to group data sets for their current connect group:
RALTER GLOBAL DATASET ADDMEM('&RACGPID.**'/READ)

Note: If the current connect group is found in the global access table and list-of-groups processing is in effect, list-of-groups checking is ignored.
access-level

can be NONE, READ, UPDATE, CONTROL, or ALTER.
For more information on specifying the ADDMEM operand, see z/OS Security Server RACF Command Language Reference.
When you are finished updating the global access checking table, issue the SETROPTS command with the GLOBAL operand for each class affected.
```
SETROPTS GLOBAL(classname)
```
Guidelines:
- Save a listing of the global access checking table. This can help you recover from the accidental deletion or alteration of the global access checking table or its entries. You can use the RLIST command to make this listing quickly.
- Write an EXEC that contains the commands you use to create the global access checking table. The EXEC should include the RLIST command to provide an independent record of the actual table created. Also, if the global access checking table is accidentally deleted (using the RDELETE command), the EXEC can readily be used to regenerate the table.
Important: For each entry in the global access checking table, create a similar resource profile. Such a "matched pair" approach can help ensure the continuation of protection if global access checking becomes disabled. For example:
```
RDEFINE classname resource-name UACC(access-level)
```
At the end-of-volume (EOV) processing, RACROUTE REQUEST=AUTH is issued with OLDVOL specified for authority checking with the DATASET and TAPEVOL classes. This check bypasses the global access table checking and uses resource profile definitions for authority checking. By not having a "matched pair" approach, you might get different results.