Requesting security services

The following is guidance information for application programmers requesting the services of the security product.

Application writers who need to use the services of a security product should try to write their programs in a way that is compatible with RACF®. In turn, the developer of a security product other than RACF should provide function that is compatible with RACF. In this way, application programs should function with RACF or with some other external security product.

Because the functions of RACF are enhanced in new releases, an application might require a specific minimum level of RACF support in order to work correctly. If this is true, you should document this minimum level so that users of your application who have RACF installed know what level they need. Also, other security-product implementers then know what level of function they must provide to work correctly with your application. And users of other security products know what level they need to install to run your application.

Your application should use RACROUTE rather than the older macros RACHECK, RACDEF, RACLIST, RACXTRT, RACINIT, FRACHECK, and RACSTAT.

Some Programming Interfaces to the security product might not be supported by all RACF-compatible security products. For example, the ICHEINTY interface (described in z/OS Security Server RACF Macros and Interfaces) is a General-Use interface that is only supported by RACF. If you want your application to work for users of RACF and of other security products, you should not make use of interfaces that are RACF-specific. The RACF-specific General-Use interfaces in this documentation are:

The ACEEFCGP pointer to the list-of-groups table in the ACEE control block.
The RACROUTE REQUEST=EXTRACT,TYPE=EXTRACT or TYPE=REPLACE functions that specify FIELDS= with a segment name (specified or implied) of BASE. You should not assume that any security product except RACF supports the extraction or replacement of named field information in the base segment of a profile.
The other security products, however, should support extraction or replacement of data in the other segments, such as DFP and TSO, if they are to be compatible with RACF. They should also support all the other functions of RACROUTE REQUEST=EXTRACT, for RACF compatibility.

As long as you avoid the RACF-specific interfaces, your program should work with any RACF-compatible security product. If you receive an SAF return code of 4 (in register 15) with a return code and reason code of 0 in SAFPRRET and SAFPRREA, that indicates that there is no security product, or the product does not support the request you are making. As an application designer, you are then free to make your own decision to continue with your processing, or to terminate processing.