Security is one of the classic strengths of the S/390 and zSeries platforms and especially of OS/390 and z/OS. RACF is the centerpiece of OS/390 and z/OS security. RACF provides extensive security with the best possible performance. Because more and more products integrate their security into RACF, RACF has evolved many ways to ensure rapid access to security data.

Any claims that IBM is focusing on RACF performance because of alleged performance problems are absolutely false. RACF's focus on performance is to maintain and enhance the industry leading performance of RACF and of MVS.

In fact, a financial services company in the southwest had this to say after moving their production workloads to RACF:

The performance impact of the implementation of RACF in production has been very positive. Forty-five fewer DASD I/Os per second are being performed to the production RACF security data bases than ACF2 required. RACF's support for exploiting the GRS capability to convert hardware reserves on the data base volume to global enqueues has also eliminated a source of frequent slowdowns and occasional outages with ACF2. The implementation of RACF has improved availability and performance (and significantly reduced software license costs) in all environments.

RACF... proven performance!

Let's spend a few moments discussing how RACF provides lightning-fast response. Note: The techniques described below are proven ways that RACF has addressed performance. Your environment determines the effectiveness of each of these techniques. IBM is not making any formal performance test results available. As always, your mileage may vary.

One of the key elements in the performance of any software is the amount of input and output (I/O) activity. Traditionally, I/O devices have been markedly slower than processors. This is the driving force behind the need for intelligent data buffering mechanisms.

RACF has extensive facilities that reduce I/O activity, replacing it with the far faster in-memory operations. Of course, above-the-line storage is used wherever possible for maximum storage efficiency. In fact, before an I/O is performed, RACF has many levels of buffering that it can use before an I/O needs to be initiated. These levels are:

• Global access table

  Your system administrator can define the resources to which everyone requires access. These resources can be defined in an in-storage list called the Global Access Table. When a user requires access to a resource that is defined in this table at a level that covers the access level that they require, RACF allows the access without performing any I/O. This is a high-performance access check path.

• Virtual lookaside facility (VLF) caches for user identity and security context

  The verification of a user's identity and the creation of a security context for a user are two common activities. RACF has a special kind of buffering to support these very specialized activities. When a user's identity is verified or a security context is built for a user, RACF stores an encapsulated version of that identify or context in-storage in the Virtual-Lookaside Facility (VLF) of MVS. VLF allows RACF to recreate the security context without having to perform normal I/O.

• RACLISTed profiles

  Applications which have critical performance requirements can have RACF profiles for their application loaded into storage through the use of the RACLIST service. These profiles can be loaded either by the application (RACROUTE REQUEST=LIST) or by a security administrator (SETR RACLIST(classname)). When a user requires access to a resource covered by a RACLISTed profile, RACF can grant that access based on the in-storage profile check.

  Note that the interface to RACF may be different between these two types of RACLISTed profiles.

• Generic in-storage profiles

  RACF allows the definition of profiles which protect more than one resource, based on resource naming conventions. These profiles are called generic profiles. Since generic profiles protect multiple resources and since users typically access multiple resources of a similar name, RACF keeps all of the generic profiles with the same first-part of the name in storage. This means that on subsequent access checks against a resource with the same first-part of the resource name, RACF doesn't have to perform any I/O.

• Restructured RACF data base

  RACF 1.9 introduced the restructured RACF data base. This data base enhances performance in 3 ways:

  • more data is read in with each I/O,
  • four times the number of RACF data buffers are supported, and
  • relationships between users and groups are more efficiently stored.

    Each of these helps reduce the amount of I/O that is performed.

• Buffers for the RACF data base

  During RACF installation, your systems programmers have the opportunity to request up to 255 buffers for use by the RACF I/O supervisor. These buffers can contain either data in the form of profile data, or RACF control information in the form of indices into the RACF data base. Anytime that RACF wants to access a specific record in the data base, it first looks in these buffers. If the record is found here, then no I/O needs to be done. This buffer is maintained on a most-recently-used basis.

• The coupling facility

  In MVS 5.1, IBM introduced the Coupling Facility, a device which provides shared storage among systems, in addition to several other functions. RACF not only supports applications which use the coupling facility to provide a single-system image of security (such as CICS), but also exploits the coupling facility for another added I/O suppression edge. RACF stores data within the coupling facility so that even if the RACF buffers on one particular system don't have the data being requested, they may be found in the Coupling Facility. If they are, once again, normal I/O has been avoided. Your system programmer can control how much storage is available to RACF in the coupling facility.

• Splitting the RACF data base

  You can split your RACF data base across several DASD, control units, and channel paths, and thus spread the I/O load to multiple devices. In addition, RACF allocates a set of buffers for each data set that is used. Net: Improved performance by eliminating wait time and the elimination of I/O through the use of buffers.

• Buffering on the control unit

  High-performance DASD devices usually contain buffers to improve the throughput and response times of the underlying DASD. While RACF has no control over this buffering, it is another way that I/O can be avoided.

• Solid state devices

  We're finally at the point where I/O takes places. If you are running with a non-solid-state DASD device, then this is where the armature would extend and data would be moved. However, if you have placed your RACF data set on a electronic or solid-state DASD, then no I/O is required.

This page was last updated November 2003.