ICH408I — RACF access denied

RACF refused an access. Read every field of the message and it tells you whose access, to what, and what is missing.

What happened

A job, TSO session or transaction tried to use a protected resource and RACF said no. Batch jobs usually fail straight after, often with an open abend such as S913 for a dataset.

Typical job log lines (illustrative)

ICH408I USER(PAYBAT1 ) GROUP(PAYROLL ) NAME(PAYROLL BATCH ID   )
  PROD.PAYROLL.MASTER CL(DATASET ) VOL(PRD001)
  INSUFFICIENT ACCESS AUTHORITY
  FROM PROD.PAYROLL.** (G)
  ACCESS INTENT(UPDATE ) ACCESS ALLOWED(READ   )
IEC150I 913-38,IFG0194E,PAYJOB01,STEP020,MASTER,...

What it means

The system asked RACF whether an identity may use a resource at a given access level. RACF found the governing profile, compared the request with what the identity holds, and refused. Each field answers one question:

Field	Use it to
USER(…)	Identify whose access was checked — often a functional userid, not yours
Resource name	Know exactly what was being accessed
CL(…)	See the class: DATASET, FACILITY, TCICSTRN, DSNR, MQQUEUE…
FROM … (G)	Find the profile that made the decision; (G) means a generic profile
ACCESS INTENT	See what was attempted (READ, UPDATE, ALTER…)
ACCESS ALLOWED	See what the identity currently has

Typical causes

The job ran under a different userid than expected (scheduler ID, USER= on the job card, or a surrogate setup).
The program needs more than it has — for example UPDATE where only READ was granted.
A new dataset name, queue or transaction was introduced but no profile change was requested.
The user was recently connected to a group but has not logged on again or the job started before the change.
A general-resource change was made but the in-storage profiles were not refreshed.
The userid is revoked or the password expired (the message text differs in this case).

Symptoms

ICH408I in the job log or on the TSO screen, usually followed by an abend or a failing return code.
For datasets, S913 with reason 38 is the classic partner abend.
In ISPF, a dataset you cannot read may simply not appear in a list — invisible can look identical to deleted.
Unlike a S213 or a 'dataset not found', the resource exists; you just may not use it.

Where to look

JESMSGLG and JESYSMSG in SDSF for the full ICH408I text.
The job card and scheduler definition, to confirm which userid really ran.
The profile named in FROM, listed by the security team or with RACF list commands if you have authority.
For CICS or Db2 resources, the region log or Db2 messages around the same time.

How to diagnose

Copy the whole message, not just the first line.
Confirm the USER is the identity that should be doing this work.
Compare ACCESS INTENT with ACCESS ALLOWED to see the exact gap.
Note the profile in FROM; if it is generic, a more specific profile may be the right fix.
Check whether anything changed recently: new dataset names, new job, new userid, group changes.
Decide whether the access is genuinely needed, or whether the program is asking for more than it should (for example opening I-O when it only reads).

How to fix

Raise a request through your site's change process containing: identity, resource, class, access needed, access currently held, governing profile, and the business reason. Ask for the identity to be connected to an appropriate group rather than for an individual permit. If the program over-asks, fix the program instead. After the change, rerun the failed step; a new logon or new job picks up group changes, and the security team refreshes in-storage profiles for classes that need it.

How to prevent

Include security requests in every change that adds datasets, queues or transactions.
Test under the same functional userid that production uses, not your own.
Follow least privilege: open files in the mode actually needed.
Keep naming standards so new resources fall under existing generic profiles.

Production considerations

Interview question

A batch job fails with ICH408I. Walk me through what you do.