RACGLIST is especially valuable for resource classes used across multiple z/OS system images where RACF Sysplex data communications is active. In this configuration, when a RACLIST REF RESH is issued on one system, RACF performs the RACLIST process, saves the post-processed profiles in the database, and informs the other systems to retrieve and load the RACGLIST copy. This is beneficial because it saves all the other systems the CPU cycles needed to RACLIST the profiles for themselves and ensures all the system images are referencing an identical set of in-storage profiles. Without RACGLIST, a profile change could be introduced when the various systems are performing their own separate RACLIST REFRESHes such that some systems incorporate the change when others don’t. These inconsistencies can cause unexpected access failures, especially with CICS inter-region communications, and can be difficult to troubleshoot.

RACGLIST is a resource class whose profiles are the names of RACLISTed classes. To activate RACGLIST for a class, define the RACLISTed member class as a profile in the RACGLIST class as follows: RDEFINE RACGLIST classname. Nothing more is required. RACF will automatically update the profiles with a RACLIST REFRESH. Use of the RACGLIST class profiles does require additional space in the RACF database to store the post-processed profiles, so check available free space first.

 5 Increase Enqueue Residency—(ERV)

When a RACF command executes, the TSO user or batch job initiating the command holds an exclusive enqueue on the database; no other process may access the database until the command completes. Such users are often assigned a low processing priority and may be swapped out in the midst of executing a command. This is especially likely when executing large batches of CO NNECT and REMOVE commands, as these usually entail updates to both a USE RID and a GROUP profile. Unfortunately, the user continues to hold the enqueue while swapped out. All other RACF requests are delayed until the user is allowed to proceed and finish the task. To avoid this, increase the value of the ERV parameter in PARMLIB member IEAOPT xx. This grants more CPU service units to any process with an enqueue on a system resource (e.g., RACF ) to let it complete work before being swapped out. The default value is 500, and the recommended value is 40,000 to 50,000. This change will benefit all processes with enqueued system resources.

 6 Use Virtual Lookaside Facility (VLF) caching

VLF can cache several types of RACF information for instant reuse, including user logon information, group tree structure, and z/OS Unix identity information. Figure 4 shows the entries to be made in the VLF configuration parameters to implement caching. During logon, RACF builds an Accessor Control Environment Element (ACEE) in storage for each user. The ACEE is used in subsequent access authorization checks. It contains information about the user that can be obtained only by retrieving the user’s profile from the database. This information includes the user‘s ID, name, and attributes, as well as installation data and connect groups. A user may perform many logons during a typical workday. A TSO user may submit multiple batch jobs; each results in a separate logon. Characteristics of these various logons are often the same and the ACEE RACF would build for each of them is identical. ACEE s can be cached in VLF and reused to avoid repeated retrieval of the user profile and ACEE re-creation.

Whenever a user attempts to exercise a group-level authority such as changing a profile using Group- SPEC IAL, RACF creates a map of the pertinent portion of the group tree to determine the user’s eligibility to perform the action. This involves I/O to find the owner of each profile in the ownership chain to determine if the target profile or resource falls in the user’s scope of groups. RACF creates this map for each TSO user or batch job individually, storing the results in the user’s address space, where it will be discarded at logoff or job completion. If many users exercise group-level authority, this process can become a burden to RACF. To reduce the work involved in checking successive group authority actions, the group tree mappings can be cached in VLF for reuse. The cached information is available to all users and isn’t discarded when users log off.

When performing certain z/OS Unix functions, Unix uids and gids need to be mapped to their corresponding user IDs and groups, respectively. This mapping process requires interrogation of either every user’s or group’s OMVS segment, UNIXMAP profiles, or the Application Identity Mapping (AIM) index structure if the database was recently restructured. Looking at every OMVS segment certainly hampers performance. Activating the UNIXMAP class avoids this by satisfying the mapping request with a single profile check. (RACF automatically creates and updates these profiles in conjunction with changes to OMVS segments.) Better still is implementing AIM. In any case, this process can be further expedited by caching the mapping results in VLF for reuse. You also can improve the performance of applications using thread level security by caching user security packets in VLF.

 7 Make efficient use of groups

4 Pages