IEC150I: 913 abend, security check failed at open

What it means

Open and end-of-volume processing make several security checks before a program gets a data set. Most go through RACF or another security product. Others are older or more specialized, such as data set passwords, tape label options and APF authorization. If one of them fails, z/OS writes IEC150I and ends the step with abend 913. IEF450I follows with ABEND=S913.

The message gives the abend and return code, the module that found the problem, the job name, step name and DD name, the device number, the volume serial, and the data set name with any member.

Return code 38 is the everyday one. It means the job opened a RACF-protected disk data set or tape volume without enough authority. RACF writes ICH408I just before IEC150I, and that message names the profile, the access the job asked for and the access it has.

Some other return codes:

• 0C means a password check failed, either a wrong password or an I/O error while checking it. It also covers a protected VSAM data space the job has no RACF authority to.
• 10 means an unauthorized program tried to open the VTOC for output.
• 18 and 64 mean a job asked for bypass label processing (BLP) on tape without authority.
• 70 means the user has only EXECUTE authority, which allows a program library to be loaded from but not read as data.
• 74 means a security check failed for a subsystem data set or a z/OS UNIX file opened through a DCB, for example a file opened for output that the user may only read.

The full list, with tape protection codes from 48 to 6C, is under IEC150I in z/OS MVS System Messages for your release.

Common causes

• The job's user ID has no access, or not enough access, to the data set's RACF profile (return code 38). Reading needs READ, writing to an existing data set needs UPDATE, and creating or deleting one needs ALTER.
• The job now runs under a different user ID, for example after moving to a new scheduler or a new surrogate user, and that ID wasn't given the same access.
• A new data set name falls under a profile the user isn't permitted to.
• The JCL codes LABEL=(,BLP) for a tape and the user isn't allowed to bypass labels (return code 64).
• A z/OS UNIX file's permission bits don't allow the access requested (return code 74).
• A program library is protected with EXECUTE access only and something tried to read it as data (return code 70).

How to find the problem

1. In SDSF, open JESYSMSG and find IEC150I. Note the return code and the data set name.
2. Look just above it for ICH408I. It gives the user ID, the profile that protects the data set, the access intent (what was asked for) and the access allowed.
3. Check which user ID the job really ran under. It is in the ICH408I line and in the job's IEF and $HASP messages, and it may not be the person who submitted it.
4. Ask your security team to list the profile, or run LISTDSD DATASET('PROD.PAYROLL.MASTER') GENERIC if you are allowed to see it.
5. For return code 74 on a UNIX file, check the file and directory permissions with ls -l from z/OS UNIX.

How to fix it

• Send the ICH408I message to your RACF administrator and ask for the access level it shows was needed.
• If the step only reads the data set, make sure the program opens it for input and the DD statement doesn't ask for more than it needs.
• Run the job under the user ID that already holds the access, if that is how your installation sets up batch work.
• Remove BLP from the LABEL parameter unless you have authority to use it.
• For a UNIX file, change its permissions or owner with chmod or chown, or have the owner do it.

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