Every minute of a typical workday, RACF is bombarded with hundreds, if not thousands, of requests to validate user IDs and passwords and to verify users are authorized to access resources. Almost every user action prompts a RACF check, whether to execute a program, log on to a particular CICS region, open a data set, enter an IMS transaction, access a DB2 table, initiate an operator command, perform a storage administration function, or run a Time Sharing Option (TSO) logon procedure. All the while, RACF is updating last used dates on user IDs during logons, responding to RACF commands, and initiating System Management Facilities (SMF) logging. Many of these tasks require RACF to perform I/O to its primary database and sometimes to the backup, too. Any requests that arrive while RACF is busy are placed in a queue to wait their turn. Many requestors can’t proceed until they’ve received RACF’s response. Work throughout the system can bog down while RACF works its way through any backlogs.
P roper tuning is essential to ensure that RACF doesn’t become a performance bottleneck. This article offers the following 10 suggestions for ensuring RACF operates at peak efficiency:
1 Implement the Global Access Table (GAT)
The GAT contains a list of resources everyone is given immediate access to without further checking. The GAT check occurs early in RACF’s access authorization decision process before there’s any I/O to find and fetch a profile. A well-designed GAT can greatly improve performance.
The GAT is constructed from a set of profiles defined to the GLOBAL class. A GLOBAL profile is a resource class name (e.g., DATASET). Within each profile is a list of entries related to the associated resource class. These entries look similar to normal resource profiles to include the use of generic masking characters. Associated with each entry is an access level (e.g., READ) that’s the highest level the GAT grants to everyone. Once a GLOBAL profile has been created for a specific resource class, it must be activated with the command SET ROPTS GLOBAL(classname). Figure 1 shows the commands for building and activating a GAT profile and entry. Figure 2 provides sample entries.
&RACUID is a variable available for use with the GAT and is substituted with the user’s logon user ID. This variable is especially useful in coding entries for resources where the user would be considered the owner of the resource and automatically granted access. An example is a TSO user data set; hence, the entry &RACUID.*.** or equally acceptable &RACUID.**. &RACGPID, another GAT variable, is substituted with the user’s current connect group (i.e., the group the user logged on with).
When working with the GAT, remember that:
- The list of entries should be as short as possible to minimize time spent checking the GAT.
- If no GAT entries are to be defined for a specific resource class, deactivate GAT checking for the class to avoid wasting CPU cycles. Enter the command SET ROPTS NOGLOBAL(classname).
- After changing entries in a GLOBAL profile, activate the changes with the command SETROPTS GLOBAL (classname) REFRESH .
- Access granted via the GAT isn’t logged, so if logging is essential, don’t add an entry.
- Be careful that GAT entries don’t compromise security. An entry in the GAT supersedes any corresponding RACF resource profiles and may grant access the profiles would otherwise deny.
2 Maximize in-storage resident data blocks
The RACF database is organized into blocks, each 4K in size. A block may contain either a portion of the database index or one or more profiles or profile segments. RACF retrieves data from the database in blocks and not by individual profiles.