This utility advances the application identity mapping stage for RACF® databases created before OS/390® Release 10. You do not need to run the utility against databases created with IRRMIN00 PARM=NEW for OS/390 Release 10 or later because they are already initialized for the final stage of application identity mapping.

Application identity mapping in its final stage, stage 3, is an alternative to the use of mapping profiles to associate RACF user and group names with z/OS UNIX, Lotus® Notes®, and Novell Directory Services identifiers. For these associations, IRRIRA00 converts the database mapping profile information into an alias index, which uses less space. This conversion is accomplished through a series of stage transitions from an initial stage 0 to the completed conversion in stage 3. It is important to verify that your applications relying on the alias information continue to execute properly through the interim stages. Changes made to RACF user and group commands and callable services to support the alias indexes are intended to be transparent. However, you need to modify any application code that references or manipulates the mapping profiles directly to use the standard interfaces.

You can run the IRRIRA00 utility without specifying parameters to determine the current stage of the active RACF database. You cannot run the utility against an inactive database. The stage value is maintained in the ICB of the database master data set. If your database is split across multiple data sets, RACF assumes that they are at the same stage as the master.

IRRIRA00 opens the master primary RACF data set and the master backup RACF data set, if it is active, to write the stage indicator into the ICB. You must have update authority to each data set to allow the data set to open successfully. Failing opens end with ABEND 913.

IRRIRA00 obtains serialization to prevent activities such as RVARY and SETROPTS commands from processing while the utility is running. Processing of RACF commands that add, alter and delete user and group profiles might also be delayed. You should avoid RACF administration while the utility is running.

IRRIRA00 runs fastest when there is minimal activity on the system. For a database with a large number of mapping profiles, the utility converts from stage 0 to stage 1 in about half the time if you set the backup database inactive and run IRRIRA00 against the primary database only. You can use IRRUT200 or IRRUT400 to copy the primary database to the backup database after the utility completes successfully.

IRRIRA00 does not propagate the new alias index entries or the deleted mapping profiles to other databases with RRSF. You need to run the utility for each database when that system is ready to enter a new stage. RACF databases do not need to be at the same stage to be part of the same RRSF network unless specific code is used to manipulate mapping class profiles using RACROUTE or ICHEINTY. Command propagation works correctly between systems whose RACF databases are at different stages.

The size of an alias index entry is limited to 129 user IDs or group names each 8 characters in length (more than 129 if their average lengths are less than 8 characters). As a result, the number of user IDs that can share a UID, and the number of groups that can share a GID, are limited. IRRIRA00 fails if the size of an alias index entry is exceeded. If you exceed the limit, try to combine user ID functions for started tasks or daemons so that fewer user IDs share the same UID. If you exceed the limit because too many user IDs share UID(0), consider using profiles in the UNIXPRIV class to selectively assign superuser privileges, and reduce the number of user IDS with UID(0).

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 this utility from the z/OS V1R4 system. Run it from a system running z/OS V1R8 (or higher) or run it from a z/OS V1R5, V1R6, or V1R7 system with APAR OA12443 installed.