How RESLEVEL can affect the checks made

Depending on how you set up your RESLEVEL profile, we can change which user IDs are checked when access to a resource is requested. The possible checks are:

The user IDs checked depend on the user ID used at connection time, that is, the CICS address space user ID. This control enables you to bypass API-resource security checking for WebSphere MQ requests coming from one system (for example, a test system, TESTCICS,) but to implement them for another (for example, a production system, PRODCICS).

Note:
If you set up your CICS address space user ID with the "trusted" attribute in the STARTED class or the RACF started procedures table ICHRIN03, this overrides any user ID checks for the CICS address space established by the RESLEVEL profile for your queue manager (that is, the queue manager does not perform the security checks for the CICS address space). For more information, see the CICS Transaction Server for OS/390 V1.3 CICS RACF Security Guide.

The following table shows the checks made for CICS connections.

Table 51. Checks made at different RACF access levels for CICS connections
RACF access level Level of checking
NONE Check the CICS address space user ID and the task or alternate user ID.
READ Check the CICS address space user ID.
UPDATE Check the CICS address space user ID and, if the transaction has been defined with RESSEC=YES, also check the task or alternate user ID.
CONTROL No check.
ALTER No check.