This sequence of authorization checks begins in one of the sequences in Authorization checking for RACF-protected resources and continues the RACROUTE REQUEST=AUTH authorization checking service that is begun there.

When the SECLABEL class is active on your system, and a user or job requests access to a resource, RACF® compares the security label of the user with the security label of the resource. For a general description of these comparisons, see Comparing security labels.

1. If the user requesting access does not have a security label and the resource does have a security label, RACF fails the request.
2. If the SETROPTS MLACTIVE(FAILURES) option is in effect and the resource does not have a security label associated with it, and the resource class is DATASET or another class that requires security labels as defined in the class descriptor table (CDT), RACF fails the request.
3. If the SETROPTS MLACTIVE(WARNING) option is in effect, RACF makes the same checks as in Step 2. If the access check fails because the resource does not have a security label, RACF issues a warning message and grants the request.
4. If the SETROPTS MLS(FAILURES) option is in effect, RACF makes the tests shown in Table 1 and fails the request if the test fails.
   If the SETROPTS COMPATMODE option is in effect, RACF checks to see if the user's UTOKEN indicates that the ACEE was created with an older protocol (pre-RACF 1.9.0). If both are true, then RACF checks to see if the user has access to a security label that could allow the requested access to the resource.

   • If the user has no access to any such security label, RACF fails the request.
   • If the user does have access to such a security label, RACF continues authorization checking and logs the request.
5. If the SETROPTS MLS(WARNING) option is in effect for this resource class, RACF makes the same checks as in Step 4. If any test fails the request, RACF issues a warning message and grants the request.
6. If the SETROPTS NOMLS option is in effect, RACF makes the tests shown in Table 1 and fails the request if the test fails.
   If the SETROPTS COMPATMODE option is in effect, RACF checks to see if the user's UTOKEN indicates that the ACEE was created with an older protocol (pre-RACF 1.9.0). If both are true, then RACF checks to see if the user has access to a security label that could allow the requested access to the resource.

   • If the user has no access to any such security label, RACF fails the request.
   • If the user does have access to such a security label, RACF continues authorization checking and logs the request.

If the resource is a JES spool data set, RACF uses the security label in the token associated with the data set (specified on the RTOKEN parameter of the RACROUTE REQUEST=AUTH macro). Otherwise, RACF uses the security label kept in the resource profile protecting the resource, in the FSP for files, or in the ISP for IPC objects.