The RACF data set must be a contiguous non-VSAM data set that re"sides on a DASD volume. At IPL time the data set is opened and allocated, and RACF control blocks are updated with the physical location of the data set on the volume. The data set is then closed. Because the control blocks are not updated again, you cannot move the RACF data set to another location on the same pack without causing I/O errors; therefore, all RACF data sets should be marked as unmoveable whenever DF /DSS DEFRAG is run against the volume. If the data set is moved, a re-IPL is required to access the RACF data set again.
Multiple RACF Data Sets
Multiple RACF data set support provides an alternative to maintaining all your RACF profiles on one data set. By using multiple RACF data sets (RACF allows up to 255), you can spread accesses across multiple devices. The use of multiple devices reduces device contention and the number of resources made unavailable by the loss of one data set or device.
Also see "Creating Multiple RACF Data Sets" in Chapter 1 and "RACF Data Set Storage Requirement" in Chapter 9.
Switchable RACF Data Sets
This facility allows an installation to identify alternate RACF data sets that can be switched to, without requiring a re-IPL, in case of a failure on a primary RACF data set. There is a one-to-one relationship between primary RACF data sets and backup data sets. None, some, or all of the primary RACF data sets can have corresponding backup data sets. RACF allocates the backup data sets at the same time as the primary data sets; therefore, the backup data sets must be online during RACF initialization. When electing to use this facility, the installation can choose from three levels of backup:
1. The backup data set is not updated as changes are made to the corresponding primary data set, but is available for switching when needed. Switching to this backup data set brings a down-level RACF data set into operation.
2. The backup data set is available for switching and is also updated to keep current with the primary data set. If this option is selected, the backup data set must be a copy of the corresponding primary data set existing at RACF initialization. Switching to this backup data set is transparent.
3. The third option is similar to the second except that changes made to the corresponding primary data set for the sole purpose of updating statistics counts are not reflected in the backup data set. Switching to this backup data set might cause the loss of some statistics data if you are maintaining
statistics.
The cost, in terms of RACF processing, for option 1 is negligible, for option 2 is extremely high, and for option 3 is appreciable but not nearly as high as for option 2.
For more information on backup data sets, see "RACF Data Set Recovery" and
"Failures During I/O Operations on the RACF Data Set" in Chapter 4. The topic "Data Set Name Table" in Chapter 5 describes how the installation specifies the names of the backup data sets and the options to be used for each.
RACF provides several facilities for use in managing RACF data sets: the split/merge/extend utility (see Chapter 6, "RACF Utilities"), the RVARY and SETROPTS commands (see the Command Language Reference), and two tables -the data set name table (ICHRDSNT) and -the range table (ICHRRNG) (see Chapter 5).
Chapter 2. Operating Considerations 2-15
Maintaining a RACF Data Set
If a RACF data set requires maintenance because of error conditions in the data set, you can issue the RV ARY command to deactivate the RACF data set and use the RACF data set verification utility program (ICHUT200) and the block update utility command (BLKUPD) for maintenance.
The following rules apply when all RACF data sets are deactivated by the RVARY command and RACF failsoft processing is active:
• On shared systems, a RACF data set is deactivated only on the system from which RVARY was issued.
• If a deactivated RACF data set is RACF-protected, the system operator must be aware that the system programmer will be using a utility to access the data set. Attempts to access RACF -protected resources will cause RACF to ask an operator to allow access to a resource. The RACHECK and RACDEF post-processing exit routines do not gain control when RACF failsoft processing is active.
• Batch and TSO users whose profiles are on a deactivated data set can enter the system as if RACF were not installed.
• Attempts to define resources to RACF with RACDEF SVC processing will causes an operator information message. The RACDEF request terminates with a return code of zero. Note that, because the request is allowed, the data set entries may be RACF-indicated but not be RACF-defined. After RACF is reactivated, use the ADDSD or RDEFINE commands to define the appropriate profiles from the information supplied in the operator messages.
• You cannot issue RACF commands against profiles on an inactivated data set.
• Commands that change mUltiple profiles will not perform all the operations if a required profile is on an inactive data set.
Note: Exit routines can examine the data set descriptor table created during RACF initialization to determine if a RACF data set has been deactivated by the RV ARY command.
Coordinating Profile Updates
Installation personnel should plan to update profiles so that they remain
consistent, and so that the updating does not interfere with other jobs running in the system.
Each individual operation performed by RACF serializes on a RACF data set, but a command or function may perform multiple operations on multiple profiles.
For example, the CONNECT command changes both the user profile and the group profile. If two or more RACF commands or functions are executing at the same time and are making contradictory updates, their operations might be interleaved and, therefore, cause the information in the RACF data set to become incomplete or invalid.
Example: A DELUSER command is issued to delete a user from RACF. At the same time, the user, who has the ADSP attribute, is logged on the system and is creating a permanent user data set. (The data set will automatically be defined to RACF.)
The DEL USER command performs the following operations on the RACF data set:
1. Locates the user entry in the RACF data set.
2. Locates any user data set entries; ensures the user does not have any user data sets whose high-level qualifier is his userid. (RACF cannot delete the user until all his user data sets are deleted.)
3. Deletes the user entry.
4. Updates the group entry; removes the user as an eligible member of the group.
5. Deletes the connect entry for the user.
As a result of the ADSP attribute, RACF performs one operation on the RACF data set; RACF adds a data set entry for the permanent user data set.
In this example, if the user adds the new data set entry between Steps 2 and 3 of the DELUSER command, RACF adds a user data set entry to the RACF data set. However, RACF has already deleted the user who owns the entry. To avoid this situation, do not delete a user who is logged on the system or, to prevent a user from logging on, revoke a user (with the AL TUSER command) before deleting him.
Note: If a user is in the system and you update the user's attributes in the RACF data set using the AL TUSER or CONNECT command, the changes, except for the OWNER and AUTHORITY operands, do not take effect until the next time the user enters the system. However, a LISTUSER or LISTGRP command issued immediately after the change shows the new values.
Shared RACF Data Set Considerations
It is possible for the status of the device on which a RACF data set resides to change from nonshared to shared and then back to nonshared without an
intervening IPL. This situation can occur if the device is defined as SHAREDUP at system generation time and the appropriate VARY CPU (for MVSj370) or CONFIG CPU (for MVSjXA) operator commands are issued.
In this case, the following restriction applies. When the device is shared by MVS systems, the processor (CPU) that processed the VARY or CONFIG command must do the RACF processing at least once before the status of the device is changed back to nonshared. To ensure that RACF processing takes place, have a RACF -defined user issue a TSO LOGON command or run a background job. that contains the user parameter on the JOB statement. (This procedure is necessary because RACF needs to be aware of the changing of a RACF data set to shared status so that the resident index blocks and data blocks are maintained correctly.)
Chapter 2. Operating Considerations