When the RACF® database is to be shared, the device on which the database resides must be configured as shared, or damage to the database is likely. Both primary and backup databases must be shared. For information on how to define a device as shared, see z/OS HCD User's Guide.

Tip: To determine whether the database is on a device that has been configured as shared, issue an RVARY LIST command. If the device is not shared, the output includes a column labeled SHR, with the value N. The column does not appear if the device is shared.

Except when operating in data sharing or read-only mode, RACF serializes access to a shared database through use of the hardware RESERVE/RELEASE capability. Depending on the work characteristics of your systems, this use of RESERVE/RELEASE might cause contention problems. An installation that is experiencing contention problems related to the RACF database can consider converting the RESERVEs. If an installation uses the MVS™ global resource serialization function to convert RESERVES, all z/OS® systems that access the RACF database must be part of the same global resource serialization complex, and there can be no z/VM® systems sharing the database.

When running in data sharing mode or read-only mode, RACF uses global ENQs instead of the hardware RESERVE/RELEASE capability. These ENQs should occur at a lower rate than the RESERVEs would occur. However, when running in non–data sharing mode, RACF uses hardware RESERVES to serialize database access, unless the installation has explicitly converted hardware RESERVEs to ENQs using the MVS global resource serialization function.

If your shared RACF database is at application identity mapping (AIM) level 1 or higher, all systems that update the OMVS segment of USER or GROUP profiles, or update the ALIAS segment of general resource profiles (for example, any SERVAUTH class profile), or run RACF utilities, should have global resource serialization connections between the systems, should be in the same global resource serialization complex, and should be running OS/390® release 10 or any z/OS release. Adding or deleting a profile that has any of these segments, altering these segments, or running RACF utilities from a system outside the global resource serialization complex might result in incorrect results; for example, an alias index entry for an OMVS UID or SERVAUTH alias might point to the wrong profile, or to one that does not exist. To prevent database sharing errors, it might be useful to use RACF program control to restrict access to all RACF commands that can update these segments, to ensure that they cannot be used from systems outside a single global resource serialization complex.

If you do get your alias index out of synchronization with the USER or general resource profiles, you might need to delete and re-create some profiles or alter some data (for example, a UID or GID), in order to correct the inconsistency. For more information, see Recovering from errors with application identity mapping.