FTP transfer fails due to security policy

When FTP transfer fails due to security policy, read the ICH408I message in the job log first — RACF tells you exactly which profile, user, and access level failed.

What it means

• ICH408I names the user, the resource, the class, and the access attempted — it is the diagnosis, not just a symptom.
• RACF checks the most specific matching profile first; a broad generic profile can grant or deny unexpectedly.
• Authority failures right after a production move usually mean the production profiles were never created.

Common causes

• No profile covers the data set, or the user ID was never added with PERMIT.
• User ID revoked or suspended after password violations (check with LISTUSER).
• The job runs under a different user ID than expected — check USER= on the JOB card or the started-task ID.
• SURROGAT profile missing when submitting a job under another user ID.
• Class is RACLISTed but was never refreshed after the PERMIT (needs SETROPTS RACLIST refresh).
• Conflicting group memberships: one group grants access while another restricts it.

How to diagnose

• Read the ICH408I message: it gives the user, resource name, class, and attempted access level.
• Run LISTDSD 'hlq.dsn' ALL (or GENERIC) to see the profiles and exactly who has what access.
• Run LISTUSER userid to check for REVOKED status, group connections, and last logon.
• For CICS, Db2, or MQ failures, check the region or server user ID — not your own TSO ID.

How to fix it

• PERMIT 'hlq.dsn' ID(userid) ACCESS(UPDATE), then SETROPTS RACLIST(DATASET) REFRESH if the class is RACLISTed.
• Use ALTUSER userid NORESUME to un-revoke an ID — only after confirming it is legitimate.
• For surrogate submit: PERMIT userid.SUBMIT CLASS(SURROGAT) ID(submitter) ACCESS(READ).
• Never hand out SPECIAL or OPERATIONS to fix one access problem — grant the specific access instead.

Example: RACF access diagnosis commands

The REFRESH makes the new PERMIT effective immediately for RACLISTed classes.

Interview tip

• Q: A production job fails with ICH408I on a data set that works in test — the same situation as FTP transfer fails due to security policy. What do you do?
• A: The ICH408I names the exact profile and access level. I run LISTDSD on the production data set and compare with test — usually the production profile was never created or the job user ID lacks a PERMIT. I get the PERMIT added and refresh the RACLIST class instead of changing the job.

Prevention checklist

• Include RACF profile creation in the production deployment checklist.
• Review generic profiles regularly — an over-broad ** profile is a standing risk.
• Alert on ICH408I spikes; a burst of denials usually means a bad deployment, not an attack.