Security

A previous article presented 10 ways to ensure RACF quickly and efficiently processes the thousands of logon and access authorization requests it receives each minute. This article, which is an update to our 2006 article, addresses 10 additional techniques for further improving performance, including the use of new features that have since been added to RACF. However, before we look at the new tips, let’s revisit the original list (available at http://enterprisesystemsmedia.com/article/10-ways-to-improve-racf-performance):

1. Implement the Global Access Table (GAT)
2. Maximize in-storage resident data blocks
3. RACLIST classes whenever feasible
4. RACGLIST the RACLISTed classes
5. Increase Enqueue Residency (ERV)
6. Use Virtual Lookaside Facility (VLF) caching
7. Make efficient use of groups
8. Replace OPERATIONS with storage administration authorities
9. Implement Sysplex coupling facility caching
10. Cease gathering unnecessary statistics.

Now let’s consider 10 new techniques:

1. Increase the sets of generic profiles stored in each address space. Started tasks, batch jobs, and Time Sharing Option (TSO) users frequently access multiple data sets with the same High Level Qualifier (HLQ) and multiple resources associated with the same general resource class. These data sets and resources are often protected by generic profiles. Generic profiles are RACF database entries that usually contain masking characters (e.g., *) and typically protect several data sets or resources with similar names. An example is PAY.MASTER.**, which would protect data sets whose names begin with PAY.MASTER.

Upon receiving the first request for access to a data set in a new HLQ or resource in a new class, RACF retrieves and stores a list of all the related generic profiles in the user's address space. This list is known as a Generic Anchor Table Entry (GATE). RACF uses these GATEs to identify the specific profile protecting each data set or resource the user attempts to access. After identifying the profile, RACF then retrieves and stores a copy of it in the user's address space for access authorization checking. RACF reuses these in-memory copies of profiles for subsequent access checking rather than repeatedly fetching the same profiles. Over time, a user address space will accumulate multiple GATEs and copies of profiles for rapid reuse.

In releases prior to z/OS 1.12, RACF keeps four GATEs in memory for each address space. Once all are in use, a request for a new HLQ or resource class causes RACF to discard the least recently referenced GATE, along with all its accumulated profiles, and replace it with a new GATE. An address space randomly accessing many different HLQs and resource classes may experience GATE thrashing, where lists and copies of profiles are constantly fetched, dropped, and fetched again. When the number of profiles involved is large, such address spaces may experience a noticeable degradation in performance.

In z/OS 1.12, RACF introduced a new option called GENERICANCHOR, which supports retention of more than the default four GATEs. Each address space may now have up to 99 GATEs. The number of GATEs can be specified either for the entire system, for individual jobs, or a combination. The RACF operator command SET GENERICANCHOR is used to establish and modify these specifications. If you have a performance-sensitive address space that conceivably might be experiencing GATE thrashing, consider using this feature to increase its number of GATEs to match the number of HLQs and classes it might reference during normal processing.

If you RACLIST a general resource class as discussed in the previous article, RACF won’t need to build GATEs for it because all the profiles are already stored in memory.

2. Periodically reorganize the RACF database. RACF retrieves data from its database in 4K blocks. Each block may contain one or more profiles or profile segments. Over time, RACF administrative actions can cause the following negative effects on performance:

• A profile can be expanded by commands such as PERMIT and CONNECT, causing it to spill over into an additional block.
• Profile and segment deletions can empty all but a small percentage of a block, wasting database and buffer space.
• Each newly added profile segment may be stored in a different block from its corresponding profile, thereby requiring additional I/O to fetch the segment. This most commonly affects logons involving a user profile and its TSO, CICS, or OMVS segment.

2 Pages