Group tree in storage

RACF® can improve the performance of selected group attribute use by exploiting z/OS® hardware using the virtual lookaside facility (VLF) to create objects in data spaces. This approach reduces I/O to the RACF database when determining the structure of the group tree.

Group-tree-in-storage processing can shorten RACF processing during logon if a user needs group-OPERATIONS authority to access a data set during the logon process. If someone with group authorities is using those authorities (for example, issuing commands, accessing data sets through group operations), and that user logs on and off multiple times during the day, the installation should see a performance benefit with group-tree-in-storage processing.

Note: If the user's group-related activities are very light, less benefit will be seen.

Group-tree-in-storage processing also improves the time needed to run RACF commands when the user has group-SPECIAL, group-AUDITOR, or group-OPERATIONS authority. If the installation has created multiple users with group authorities and those users have control over some of the same groups, activating the group-tree-in-storage support should provide performance savings.

The default amount of storage supplied with a VLF class should be adequate.

To activate this support for group tree in storage, the class name IRRGTS must be described in the VLF COFVLFxx PARMLIB member. If IRRGTS is not described, then the support for group tree in storage is not active.

The activation or deactivation is not effective until the next VLF restart or the next IPL.

COFVLFxx PARMLIB member:

CLASS NAME(IRRGTS)     /* VLF class name for RACF GTS function   */
      EMAJ(GTS)        /* Major name of IRRGTS class             */

Refer to z/OS MVS Initialization and Tuning Guide for more details on the coding of the COFVLFxx PARMLIB member.