Shared RACF databases

Your RACF® database can be shared by any combination of the following systems:

MVS™ running native
MVS running as a guest machine of VM
VM running native
VM running as a guest machine of VM

Note: In a remote sharing environment, a system configured as an RRSF node can share a RACF database with a system not configured as a RRSF node, including a system running z/VM®. Be aware that if the RRSF node is using password synchronization or automatic direction, database changes made from a system that is not an RRSF node are not propagated to other RRSF nodes, and database inconsistencies can result. See RACF remote sharing facility (RRSF) for more information.

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 configure 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.

The RACF database templates must match the latest level of code on the sharing systems. Use the IRRMIN00 utility to update the database templates when you install a new release or service level. Because the database structure changed for z/OS® V1R8 to allow database templates that are larger than one 4K block, the z/OS V1R8 database templates ares not downwardly compatible unless you install an APAR on the lower-level system.

Requirement: To share a database between a system running z/OS V1R8 (or higher) and a system running a lower-level release of z/OS, you must install APAR OA12443 on the lower release. The APAR is available for z/OS V1R4, V1R5, V1R6, and V1R7. An APAR is not required on z/VM. You can share a RACF database between a system running z/OS V1R8 (or higher) and a z/VM system.

Restriction: If you are sharing a RACF database between a system running z/OS V1R8 (or higher) and a z/OS V1R4 system, do not run the following utilities from the z/OS V1R4 system. Run them only from a system running z/OS V1R8 (or higher) or run them from a z/OS V1R5, V1R6, or V1R7 system with APAR OA12443 installed:

IRRMIN00
IRRUT200
IRRUT400
IRRUT300 (BLKUPD)
IRRDBU00
IRRIRA00

Attention: If you have run the IRRIRA00 utility to convert the RACF database to application identity mapping stage 1 or later, note the following:

You should not run the IRRUT400 utility from a downlevel system.
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.