When authorization checking takes place and why

When a user requests access to a RACF®-protected resource (such as a data set), the resource manager issues the RACROUTE macro with REQUEST=AUTH specified (or the RACHECK macro¹). For ease of reference, this topic calls such a request a RACF authorization request.

Based on the specifications on the RACF authorization request, RACF determines whether the requesting user is authorized to access the resource.

If the user is authorized to the resource, RACF returns a "successful" return code to the resource manager. The resource manager then allows the request to complete.
If the user is not authorized to the resource, RACF returns an "unauthorized" return code to the resource manager. The resource manager then fails the request.
RACF issues a message indicating that the user is not authorized to the resource.
If the resource is not protected (for example, if no profile exists for it), RACF returns the default return code for the class.
For general resource classes, the default return code is the "not protected" return code, unless otherwise specified in the class descriptor table (CDT) entry for the class.

For the DATASET class, the default return code is the "not protected" return code, unless the SETROPTS PROTECTALL(FAILURES) option is in effect, in which case the default return code is the "not authorized" return code.

If the "not protected" return code is issued, the resource manager then either fails or allows the request. Most resource managers allow the request.

RACF issues a message indicating that the resource is not protected.

Note:

SMF log records or messages might be generated, depending on the options in effect and whether RACF granted or denied access to the resource.
When checking authorization for a directed command, RACF uses the authorization of the target user ID, not the issuing user ID.