ICHEINTY, ICHETEST, and ICHEACTN macros

The ICHEINTY, ICHETEST, and ICHEACTN macros are described in this topic separately from the other interfaces because of their complexity and the cautions required for their use.

Guidelines:

Use RACROUTE REQUEST=EXTRACT instead of these macros whenever possible. However, only the RACF® command processors completely validate the data entering the database. Therefore, it is preferable to use the RACF commands than either ICHEINTY or RACROUTE REQUEST=EXTRACT when updating the database. For more information about RACROUTE REQUEST=EXTRACT, see z/OS Security Server RACROUTE Macro Reference.
In general, always use the RACF commands to create RACF resource profiles. If you use ICHEINTY instead, create profiles that are supported by the command processors. For instance, ICHEINTY allows you to create a fully-qualified generic profile in a general resource class or a data set profile containing characters that are not valid, but those profiles are not supported by the RACF command processors.

You can use the ICHEINTY, ICHETEST, and ICHEACTN macros to locate (retrieve) and update the various profiles on the RACF database.

ICHEINTY: Locates or updates the profile.
ICHETEST: Tests for user-specified conditions on selected fields in the profile.
ICHEACTN: Retrieves or alters specified fields within the retrieved profile.

If you plan on using these macros, you should exercise caution because they:

Perform only limited parameter validation. The module issuing these macros must be authorized (supervisor state, system key, or APF-authorized).
Do not pass control to any exit routines except indirectly. If FLDACC=YES was specified on the ICHEINTY macro, the RACROUTE REQUEST=AUTH exits are given control during field access checking.
Do not do any logging except indirectly. Logging can occur during field access checking if the RACROUTE REQUEST=AUTH request exit requests it.
Do not complete data consistency checking. For example,
1. They do not ensure that all fields in a profile have the data expected by subsequent RACF processing.
2. They do not ensure that related profiles are updated in a consistent manner. For example, a group profile must point to its superior group profile and the superior group must point to the subgroup profile. The command processors would ensure this, but these macros do not.

Note: You should thoroughly familiarize yourself with the template information contained in RACF database templates before you read this topic.

These macros can be used by callers in either 31- or 24-bit addressing mode. The parameter lists can be located above 16MB if the caller is in 31-bit mode.

Application programs must be structured such that a task requesting RACF services does not do so while other I/O initiated by the task is outstanding. If such I/O is required, the task should either wait for the other I/O to complete before requesting RACF services, or the other I/O should be initiated under a separate task. This is necessary to assure proper processing in recovery situations.