Using SETROPTS RACLIST and SETROPTS GENLIST

You can optimize performance by carefully deciding whether to use SETROPTS RACLIST or SETROPTS GENLIST for various classes.

The RACLIST operand on the SETROPTS command improves performance by copying generic and discrete profiles for the designated general-resource class, and for each class that can be RACLISTed and that shares the same POSIT value, from the RACF® database into a data space.

If you use RACROUTE REQUEST=LIST, you can also improve performance by specifying GLOBAL=YES on the request. GLOBAL=YES stores the REQUEST=LIST results in a data space, which can then be shared by other applications that issue the same request. The additional RACROUTE requests do not access the database, they access the data space built by the first RACROUTE. Additionally, the different applications do not need to individually issue RACROUTE REQUEST=LIST deletes followed by RACROUTE REQUEST=LIST creates to refresh the original RACROUTE. The system administrator can do that by a SETROPTS RACLIST(classname) REFRESH, which deletes the existing data space, references the database to rebuild the RACLIST results and stores them in a new data space, which then becomes accessible to any application address space that has issued REQUEST=LIST,GLOBAL=YES for that class.

You can use the RACGLIST class to store the RACROUTE REQUEST=LIST and SETROPTS RACLISTed results on the RACF database. RACGLIST profiles are used during IPL for SETROPTS RACLISTed classes, and when a peer RACF system receives a propagated SETROPTS RACLIST command. (The RACGLIST profiles would also be used on a RACROUTE REQUEST=LIST,GLOBAL=YES if no data space had previously been built on that system.) For a large number of profiles it should be quicker to get the profiles from the RACGLIST class than to read all the individual profiles from the associated classes. It is suggested that you use SETROPTS RACLIST.

The GENLIST operand on the SETROPTS command improves performance by copying generic profiles from the RACF database into storage.

Before issuing a SETROPTS GENLIST or SETROPTS RACLIST for a general resource class, consider the following:

Whether you can afford the storage utilization. This applies only to SETROPTS GENLIST.
Whether you can afford the overhead—an administrator must refresh all profile changes so that they become effective.
Whether the longer IPL time is acceptable. This applies only to SETROPTS RACLIST, and only if you have a large number of class profiles. Using RACGLIST profiles during IPL might reduce time delays associated with SETROPTS RACLIST.
Whether the RACGLIST class is active and the class has been defined in the RACGLIST class; additional storage will be required for your database.

You cannot use both RACLIST and GENLIST for the same general resource class.

If you are not sharing the database with a z/VM® system, using SETROPTS RACLIST with a RACGLIST profile for the class provides the best performance with the lowest usage of common storage. For any profiles that are shared with z/VM (for example, the VMMDISK or TERMINAL classes) you should evaluate the possible trade-offs between GENLIST and RACLIST, especially if the classes have a large number of discrete profiles. On z/VM, RACF has a limited amount of storage available for loading profiles, and it is all below 16 megabytes (24-bit addressing). Using GENLIST rather than RACLIST brings only the generic profiles into storage, rather than all the profiles. Therefore, if the class contains a large number of discrete profiles, using GENLIST significantly reduces the storage utilization. However, it can also hurt performance, especially for the z/OS® system sharing the database.