In the Common Services r15.0 documentation detailing the installation of CAS9RACL for CICS/TS it states:
Add the programs DFHSIP, CAS9LRAC, and CAS9RACL to the RACF-authorized caller table, ICHAUTAB, for RACLIST right only.
Define the CAS9LRAC program to the current startup and shutdown PLT for CICS using the following entry
DFHPLT TYPE=ENTRY,PROGRAM=CAS9LRAC
However, IBM recommends that this method not be used:
Incorrect use of ICHAUTAB can cause system integrity problems, do not use it; instead run these programs with APF-authorization
What is the right way to resolve this inconsistency ?
Release : 15.0
Component : CAIENF/CICS
The IBM documentation also states that the problem can be caused if RACROUTE=LIST or VERIFY is not used with the entries being added to ICHAUTAB..
CAS9LRAC must reside in the DFHRPL concatenation and gets invoked through the startup PLT so it won’t be APF authorized unless the rest of the RPL is which is something clients will not do. CAS9LRAC does a LINK to CAS9RACL which does the RACROUTE=LIST, a VERIFY is NOT done out of this code. The only way to provide the authorization in this way is to utilize ICHAUTAB. The RACROUTE LIST you see in CAS9SAFC is not for CICS (this is why we have CAS9LRAC/RACL), it is for authorized users issuing a #SECUR macro for resources that have the FASTAUTH=YES in the CAS9RACF table. If a resource has CICS=YES in the CAS9RACF table, it will be RACLIST’d by CAS9LRAC/RACL at CICS initialization time.