Reading a violation and asking for the right thing
When access is denied you get a specific message naming the userid, the resource, and the access that was attempted. Reading it properly turns a vague 'it does not work' into a precise request that gets actioned quickly.
The message you will see most
ICH408I USER(VSAHA1 ) GROUP(PAYDEV ) NAME(V SAHA ) PROD.PAY.MASTER CL(DATASET ) INSUFFICIENT ACCESS AUTHORITY FROM PROD.PAY.** (G) ACCESS INTENT(UPDATE) ACCESS ALLOWED(READ)
Every field matters:
| Field | Tells you |
|---|---|
| USER / GROUP | Which identity was checked — often a functional userid, not yours |
| Resource name | Exactly what was being accessed |
| CL(…) | The class, which tells you what kind of thing it is |
| FROM … (G) | The profile that governed the decision. (G) means generic |
| ACCESS INTENT | What was attempted |
| ACCESS ALLOWED | What the identity actually has |
Other things that are security problems in disguise
| Symptom | Often is |
|---|---|
| Dataset not found, but you know it exists | No READ access — you are not shown what you cannot see |
| Job fails immediately with no output | No authority for the job class or the accounting field |
| A transaction gives a security abend in CICS | Transaction-level protection in the CICS transaction class |
| SQLCODE -922 | DB2 authorisation on the plan, package, or table |
| Cannot submit a job as another user | Missing SURROGAT authority |
| Permission denied in the Unix shell | POSIX permissions, or a UNIXPRIV rule |
Who the check runs as
This catches people out constantly. A batch job runs under the userid that submitted it, or under a userid specified on the JOB card if allowed. A CICS transaction may run under the terminal user's identity or under the region's, depending on configuration. A scheduled job runs under the scheduler's functional userid. The identity in the error message is the one that needs the access — and it may not be yours.
Auditing exists and you are in it
Access decisions are logged. Reports on failed attempts, on use of powerful attributes, and on changes to profiles are produced routinely and reviewed. This is normal in regulated industries. Work openly: use your own userid, do not share credentials, and if you need elevated access for a task, request it through the process rather than borrowing someone else's.
Common mistakes
Read the USER field in the message. Batch and scheduled work often runs under a functional identity.
The message contains everything needed. Paste it in full.
Copying data to a location you can reach may itself be a policy breach. Ask instead.
What you will see at work
- Keep the ICH408I text when you raise a request. It is the fastest possible route to resolution.
- Functional userids own production work. Understanding which one runs your application is essential knowledge.
- Emergency elevated access usually exists, is logged heavily, and requires justification afterwards. Know the procedure before you need it.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.