S706: Program marked not executable

What it means

When the binder builds a load module and hits errors, it can still save the module in the library. Under the default options, an error of severity 8, such as a called subroutine it couldn't find, makes it save the module with a not-executable flag in the library directory. Later, when a job asks for the program through EXEC PGM=, a dynamic CALL, LINK, XCTL or LOAD, z/OS finds the member, sees the flag and refuses to run it. The step ends with system completion code 706.

The system stops at the first copy of the module it finds. If a not-executable copy sits in a library earlier in STEPLIB or JOBLIB, a good copy further down is never reached.

The binder normally won't replace a good, executable module with a not-executable one. So S706 most often follows the first link of a new program, or a copy of a broken module into a library the job searches.

Common causes

• The link-edit had an unresolved external reference. The program calls a subroutine that wasn't in SYSLIB or in the INCLUDE statements, so the binder couldn't resolve it.
• A compile failed, but the link-edit step ran anyway and saved a broken module. The COND or IF logic in the build JCL didn't stop it.
• Someone copied a not-executable module, for example with IEBCOPY, into a load library the job searches. The flag travels with the member.
• The link-edit used the STORENX option, which lets the binder store a not-executable module over a good one.
• A not-executable copy sits earlier in the STEPLIB or JOBLIB concatenation than the good copy.

How to find the problem

1. Get the program name. For EXEC PGM= it's on the EXEC statement. For a dynamic CALL it's the name the calling program passed.
2. Work down the STEPLIB or JOBLIB concatenation in order and find the first library that holds a member of that name. That is the copy the system tried to run.
3. Find the link-edit job that last built that member and read its SYSPRINT. Look at the return code and at any binder messages (they start with IEW) that end in E or S. Unresolved symbols, reported as IEW2456E, are the usual finding.
4. If the link-edit output is gone, link the module again from its object code into a test library and read the new listing.

How to fix it

• Fix what the binder complained about. Add the missing subroutine's library to SYSLIB, add an INCLUDE statement, or correct a misspelled CALL name. Then link again and check for a return code of 0 or 4.
• Replace or delete the not-executable copy in any library the job searches before the good one.
• Change the build JCL so the link-edit step is skipped when the compile fails.
• Don't use the LET option to force the module executable unless you know the unresolved routine is never called. If it is called at run time, the program fails somewhere much harder to diagnose, often with an S0C1 or S0C4.
• If the module came from a vendor or a change management tool, ask the team that installed it to rebuild it.

What it looks like

Build job:
IEF142I PAYBLD01 LKED - STEP WAS EXECUTED - COND CODE 0008

Next run of the payroll job:
$HASP373 PAYRUN01 STARTED - INIT 3    - CLASS A        - SYS PRD1
$HASP395 PAYRUN01 ENDED - ABEND=S706

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