What it means
RACF decides who may use what on z/OS. When it says no, it writes ICH408I. The message goes to the system log (SYSLOG), to the job log of the job that tried, and to the screen of a TSO user who tried. What happens next depends on who asked. A batch program opening a data set usually abends with S913-38. A TSO command fails with its own message.
A data set refusal has several lines.
- USER, GROUP and NAME identify who was refused.
- The second line gives the resource name and its class, shown in CL(). DATASET means a data set. Other common classes are FACILITY, PROGRAM, OPERCMDS, JESSPOOL, SURROGAT and TCICSTRN for CICS transactions. For z/OS UNIX files you'll see classes such as FSOBJ or DIRSRCH.
- The third line gives the reason, most often INSUFFICIENT ACCESS AUTHORITY.
- FROM names the RACF profile that controls the resource. A (G) after it means a generic profile, one with wildcards that covers many names.
- ACCESS INTENT is what was asked for, and ACCESS ALLOWED is what this user has. The levels run NONE, EXECUTE, READ, UPDATE, CONTROL, ALTER.
Logon and job refusals use a single reason line that begins LOGON/JOB INITIATION. The common ones are INVALID PASSWORD ENTERED AT TERMINAL, REVOKED USER ACCESS ATTEMPT, NOT AUTHORIZED TO SUBMIT JOB (the JESJOBS rules stopped a job by that name being submitted) and SUBMITTER IS NOT AUTHORIZED BY USER (a job coded USER= for an ID the submitter may not act for).
The I at the end of the message number stands for informational. It records the refusal.
Common causes
- The user or group isn't on the profile's access list, or is on it with too low a level, such as READ when the job needs UPDATE.
- A batch job ran under a different user ID than expected. Production jobs often run under a scheduler ID whose access differs from yours.
- A new data set name isn't covered by any profile that gives the job create access.
- The user was recently connected to a group that has access but hasn't logged off and on, so the TSO session still uses the old group list.
- The administrator changed a profile in a class that RACF keeps in memory, and the in-memory copy hasn't been refreshed yet.
How to find the problem
- Copy the whole message, every line. The security team needs all of it.
- Check USER. If it isn't the ID you expected, the job is running under another identity, and that ID is the one that needs access.
- Read the resource name, the class and the FROM profile. They point the administrator to the exact rule.
- Compare ACCESS INTENT with ACCESS ALLOWED. NONE means no access at all, while READ against an intent of UPDATE means some access but not enough.
- A security administrator can list the profile with
LISTDSD DATASET('PROD.PAYROLL.**') GENERIC ALL, orRLIST FACILITY profile-name AUTHUSERfor other classes, and the user's groups withLISTUSER.
How to fix it
- Send the full message and a business reason to your security administrator through the help desk. Ask for the lowest level that does the job, such as READ rather than UPDATE.
- The administrator grants access, for example
PERMIT 'PROD.PAYROLL.**' ID(PAYGRP) ACCESS(UPDATE). For a class RACF keeps in memory, such as FACILITY, they then refresh it withSETROPTS RACLIST(FACILITY) REFRESH. - After a group change, log off TSO and log on again so the new group is used.
- For the password and revoke variants, the help desk resets the password and resumes the ID.
- For NOT AUTHORIZED TO SUBMIT JOB or SUBMITTER IS NOT AUTHORIZED BY USER, the administrator adds access in the JESJOBS or SURROGAT class, or you submit the job under the correct ID.
What it looks like
ICH408I USER(PAYU07 ) GROUP(PAYCLRK ) NAME(PAY CLERK SEVEN ) PROD.PAYROLL.MASTER CL(DATASET ) VOL(PRD001) INSUFFICIENT ACCESS AUTHORITY FROM PROD.PAYROLL.** (G) ACCESS INTENT(UPDATE ) ACCESS ALLOWED(READ ) IEF450I PAYRUN01 STEP020 - ABEND=S913 U0000 REASON=00000038