RACF Application Identity Mapping (AIM)

The Application Identity Mapping (AIM) is a RACF feature that provides translation between the RACF userid and the names that other software calls users (e.g. in z/OS Unix System Services the users are called UIDs).

AIM has 4 stages:

  • Stage 0 = Pre-conversion database
  • Stage 1 = Builds and maintains, but doesn’t use, alias index
  • Stage 2 = Uses alias index for lookup and maintains mapping profiles
  • Stage 3 = Uses alias index for lookup and deletes mapping profiles

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.

Why should you convert to AIM stage 3?
AIM stage 3 allows RACF to more efficiently handle authentication and authorisation requests from applications such as z/OS Unix System Services.

Converting to AIM Stage 3

Sample JCL:


  • No parts specified – displays current stage
  • STAGE( 1 | 2 | 3 ) – upgrades to level specified (needs to be sequenced)

Considerations and Notes:

  • You need UPDATE access authority to the live RACF database (primary and backup) to be able to run this job.
  • This job can only be executed against the live RACF database.
  • Try to do the entire conversion, going from stage 0 to 1, 1 to 2, and then 2 to 3, all in one maintenance window.
  • Be sure to take a good IRRUT200 RACF DB backup before starting the conversion process as a fallback.
  • After each conversion, make sure to check the job output and the syslog for errors before proceeding to the next conversion stage.
  • If you find inconsistencies between your UNIXMAP class and actual UID and GID assignments, perform an IRRUT400 reorg of the Primary RACF DB during the same maintenance window.
  • The number of userids that can share a UID, and the number of groups that can share a GID, are limited to 129.
  • To speedup things, deactivate the backup RACF database just prior to starting the conversion. Once the conversion to AIM stage 3 is completed, use IRRUT200 with PARM=ACTIVATE to copy the converted primary RACF DB to the backup RACF DB.
  • IRRIRA00 does not provide RACF database diagnostic information.
  • If you suspect a RACF database error, you should start your problem determination by running the IRRUT200 utility and requesting the INDEX and MAP ALL functions.
  • See Chapter “Recovery procedures” in the IBM manual “z/OS Security Server RACF Diagnosis Guide” for more information on RACF database diagnosis and correction.


Be the first to comment

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.