S913: Security access denied

What it means

When a program opens a data set, z/OS asks the security product whether the job's user ID may use it in the way the program asked. Opening for input needs at least READ access. Opening for output, update or extend needs at least UPDATE. If the answer is no, the open fails and the step ends with system completion code 913.

The check happens at open time, not when the job starts. A job can allocate a data set in its JCL without trouble and still fail once the program opens it. DISP=SHR doesn't help either, because what counts is how the program opens the file.

Two messages explain the failure. IEC150I gives the code, the reason, the DD name and the data set. ICH408I, from RACF, gives the user ID, the profile that protects the data set, the access the job asked for and the access it actually has.

The reason code you will nearly always see is 38. It means the user ID isn't authorized to a RACF-protected data set on disk or to a protected tape volume. Other reason codes cover less common cases, such as password-protected data sets, and are listed under message IEC150I in IBM's system messages.

Common causes

• The user ID has no access at all to the profile that protects the data set.
• The user ID has READ access, but the program opens the data set for output or update.
• The job runs under a different user ID than you think, such as the scheduler's batch ID or the ID in USER= on the JOB statement.
• The data set has a new name or a new high-level qualifier, and the profile that covers it doesn't include you.
• Access was given through a group, but the change hasn't reached your session or the job's address space yet.

How to find the problem

1. Find ICH408I in the job log. Read the USER, the data set name, the profile after FROM, and compare ACCESS INTENT with ACCESS ALLOWED. If intent is UPDATE and allowed is READ, the program tried to write.
2. Use the DD name in IEC150I to find which file failed and how the program opens it.
3. Confirm the user ID in ICH408I is the one you expected. Production jobs often run under an ID that belongs to the scheduler, not to you.
4. Check your own access from TSO with LISTDSD DATASET('PROD.PAYROLL.MASTER') GENERIC. The output shows the profile and your access to it.
5. On a site with ACF2 or Top Secret, look for that product's violation message instead of ICH408I.

How to fix it

• Ask your security team for access. Paste in the ICH408I lines, and say what access level you need and why. Ask for the lowest level that works.
• If the program shouldn't be writing to the data set, change it to open the file for input instead of asking for more access.
• Run the job under the right user ID, or ask the scheduling team to.
• After access is granted, rerun the job. A TSO user added to a new group must log off and on again. If the change was to a generic profile, the security team may need to refresh generic profiles before running jobs see it.

What it looks like

ICH408I USER(BATCH01 ) GROUP(PAYPROD ) NAME(PAYROLL BATCH       )
  PROD.PAYROLL.MASTER CL(DATASET ) VOL(PRD012)
  INSUFFICIENT ACCESS AUTHORITY
  FROM PROD.PAYROLL.** (G)
  ACCESS INTENT(UPDATE )  ACCESS ALLOWED(READ   )
IEC150I 913-38,IFG0194E,PAYRUN01,STEP030,MASTOUT,0A81,PRD012,PROD.PAYROLL.MASTER
IEF450I PAYRUN01 STEP030 - ABEND=S913 U0000 REASON=00000038

Last reviewed 2026-10-12 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your z/OS, CICS or Db2 release.