Dealing with error IEW2456E during generation of elements
search cancel

Dealing with error IEW2456E during generation of elements


Article ID: 277580


Updated On:




Most of the Endevor generate processors compile the element and linkedit the resulting object module using the binder utility (IEWL)

The binder might raise error message IEW2456E 9207 SYMBOL xxxx UNRESOLVED.

How to do to deal with this error?


The program being compiled (or a subroutine called by the program) has a reference to the symbol name mentioned in the message (normally meaning a call to a subroutine having that name).

After having processed all the statements passed to the binder and scanned all the input libraries, the binder could not find any piece of code with that name.


Compiler option DYNAM vs NODYNAM

One possible cause is that the COBOL program codes a static subroutine call (with the subroutine linked within the load module) which is intended to be dynamic (with the subroutine dynamically loaded at runtime).

In COBOL, static subroutine calls are coded as:


Dynamic subroutine calls are coded as:


Where MODNAME is a data division item with PIC X(8) containing the name of the module to be loaded and executed.

A common practice is to code subroutine calls as static (with the CALL 'literal' USING ... format) and specify option DYNAM to the compiler so that it turns them into dynamic calls. The reason for doing that is that it saves the extra coding to define the data division item.

In this situation, if the compiler is mistakenly passed option NODYNAM. the binder will raise message IEW2456E for each and every subroutine called by the program

To fix this, the processor (or the symbolic overrides in the processor group) need to be adjusted so that the compiler receives option DYNAM

Binder statements

If the subroutine is certainly intended to be statically linked within the load module, the binder needs to have it when producing the load module.

The binder may be instructed to incorporate additional modules into the load module being constructed. This is done by statement "INCLUDE ddname(module_name)" passed to the binder. A missing INCLUDE statement is a likely cause for the binder to fail with message  IEW2456E.

To fix this, the processor needs normally to be adjusted so that the binder receives all the required INCLUDE statements.

Sometimes, sites store the binder statements into a separate Endevor element (for example, having the same name as the program with a different type) which is extracted by the processor (for example, by CONWRITE utility) and passed to the binder via SYSLIN DD. If this is the case, the element that contains the binder statements needs to be updated to add the missing INCLUDE statements


An alternative to INCLUDE statements is to have the binder automatically try to resolve the external references by itself.

In the above example with statement CALL 'SUBPGM1' USING ..., the binder will try to load a member named SUBPGM1 in the SYSLIB DD library chain and use its contents to resolve the external reference.

If a library is missing in the chain so that member SUBPGM1 is not found, the binder will raise error IEW2456E.

This may be fixed normally by adjusting the processor:

  • Adding the missing library
  • Correcting IF/THEN/ELSE statements that prevent the library to be added to the chain
  • If symbolics are used in the library dataset names, adjust the symbolic overrides in the processor group

Additional Information

Any technique applicable to fix this error when Endevor is not used (for example, when compiling programs using JCL) is applicable to Endevor as well. The difference is in the way to implement the changes.

  • When using JCL, you normally edit the JCL to change compiler options, binder statements or library chains
  • When using Endevor, you change the processor or the symbolic parameter overrides in the processor group

Note that updating a processor normally requires additional security permissions so this task is normally performed by the Endevor administrator.