IEFC612I: Procedure not found

What it means

An EXEC statement that names a procedure, such as //STEP010 EXEC PAYPROC, tells the converter to fetch that procedure and expand its statements in place. It looks in three places, in this order. First it checks for an in-stream procedure with that name earlier in the same job. Then it searches the libraries named on a JCLLIB statement, if the job has one. Last, it searches the system procedure libraries that JES assigns to the job. If the member isn't in any of them, it writes IEFC612I with the procedure name.

The system libraries aren't the same for every job. On JES2 they come from the PROCLIB definitions, and the job class decides which concatenation a job gets unless a /*JOBPARM PROCLIB= statement picks another. In a sysplex each system can have its own. So a procedure can be found for one job and not for another, or on one system and not on the next.

The same message appears outside batch jobs. A TSO logon fails with IEFC612I when the logon procedure isn't in the library searched for logons. An operator START command fails the same way when the started task's procedure is missing, and IEFC452I follows on the console.

Sometimes the library is right but couldn't be used. If a JCLLIB data set can't be allocated, for example because another job holds it, IEFC003I reports the allocation error, and IEFC612I follows for every procedure the job wanted from it.

Common causes

• The procedure name on the EXEC statement is misspelled.
• The procedure is in a private library, and the job has no JCLLIB statement, or JCLLIB names the wrong library.
• The job ran in a class, or on a system, whose procedure libraries don't include the procedure. This often happens when a job is routed to another system, or when a new procedure was copied to one system's library only.
• An in-stream procedure is defined after the EXEC statement that calls it. In-stream procedures must come first.
• A JCLLIB library couldn't be allocated because another job held it, shown by IEFC003I before IEFC612I.
• For a TSO logon, the logon procedure named on the logon panel, or in the user's RACF TSO segment, isn't in the procedure library used for logons.

How to find the problem

1. Open JESYSMSG in SDSF. IEFC612I shows the procedure name, and the number to its left is the EXEC statement that called it.
2. Look for IEFC001I lines from other procedures in the same job. Each one says which library a procedure was expanded from, which shows you the libraries the job is using.
3. Check the library you expect, for example by browsing PROD.PAYROLL.PROCLIB in ISPF, and confirm the member is there with exactly that name.
4. On JES2, the operator command $D PROCLIB displays the procedure library concatenations and the data sets in each. Compare that with the job's class.
5. If your JES spans several systems, check in SDSF which system converted the job, and look at that system's libraries.

How to fix it

• Correct the procedure name, or add a JCLLIB statement after the JOB statement and before the first EXEC, such as // JCLLIB ORDER=(PROD.PAYROLL.PROCLIB). Libraries in ORDER are searched before the system libraries.
• Copy the procedure into a library that's in the job class's concatenation, on every system that may run the job.
• Route the job to the right system or class, or use /*JOBPARM PROCLIB= to choose a concatenation that holds the procedure.
• Move an in-stream PROC and PEND block above the EXEC statement that calls it.
• If IEFC003I shows a JCLLIB library was busy, rerun when it's free. On JES2 the CNVT_ENQ setting on JOBDEF decides whether conversion fails or waits for such a data set. WAIT avoids the error.

What it looks like

 STMT NO. MESSAGE
        2 IEFC612I PROCEDURE PAYPROC WAS NOT FOUND

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.