RACF® provides a number of installation exits that enable you to use your own routines to enhance the facilities that are offered by RACF, and also to optimize its usability. For RACROUTE requests, the exits allow an installation to tailor the parameters passed on the macro and to perform any additional security checks or processing that the installation requires.

The RACF initialization routine loads the exit routines during system IPL and, except for IRREVX01 and IRRVAF01, places the exit addresses in the RACF communication vector table (RCVT). If RACF determines (through a search of the LPA) that the exit routines were not supplied, RACF sets the RCVT fields pointing to the exit routines to zero. If you change an exit, except IRREVX01 and IRRVAF01, you must re-IPL MVS™ for the changes to take effect. IRREVX01 and IRRVAF01 are defined to the dynamic exits facility, and you can update them without re-IPLing.

RACF initialization message ICH508I displays the names of the exits that are active for the IPL. Because IRREVX01 and IRRVAF01 are defined to the MVS dynamic exits facility, if either of their names appear in the ICH508I message, at least one active routine is added to the indicated exit point at this particular time in the IPL.

The exit routines must be reenterable and refreshable and must be in the link-pack area: PLPA, FLPA, or MLPA. The exit routines receive control with standard linkage conventions; the exit routines should use standard linkage conventions to return control.

RACF uses the first word of the save area pointed to by register 13. Exits must not modify this part of the save area.

When the preprocessing exit routines for RACROUTE requests receive control, RACF has already validity-checked the macro parameters, but has not yet performed any other processing.

Make changes or additions to the parameter information only in the designated areas. In most cases, if a pointer is provided in the parameter list you can modify the data that it is pointing to; if the parameter list contains a 0 pointer, you can supply data, and then change the pointer to address the data.

There are special considerations for exits when automatic direction is active. For information about these considerations, see Installation exit considerations.

You should provide error recovery for your exits to handle an abend situation and either recover from the situation, or, if recovery is not possible, clean up system resources such as locks and storage obtained by the exit. For information about coding error recovery procedures, see z/OS MVS Programming: Authorized Assembler Services Guide.

See z/OS Security Server RACF Data Areas for a mapping of the accessor environment element (ACEE) data area, which is helpful when you code exit routines.