Causes for IEW2456E during Endevor generation

Products

• Endevor

Issue/Introduction

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

The binder might raise error message

IEW2456E 9207 SYMBOL name UNRESOLVED.

Resolution

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) and after having processed all the statements information is passed to the binder. The binder scanned all the input libraries, and the binder could not find any piece of code with that name.

• CEE.SCEELIB z/OS version level
  
  One cause is that your CEE.SCEELIB(########) is not at the correct z/OS level. It may be at an older z/OS version.
  
  The failure:

   IEW2456E 9207 SYMBOL name UNRESOLVED.  MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY.
   
  In CEE.SCEELIB(########) found this:

   IMPORT CODE64,########,'name',D7A 

  See that all those IMPORTs in your output are from CEE.SCEELIB(########)

  In apply output found:

   IEW2322I 1220  4802    IMPORT CODE64,########,'name',D7A    
                                                           
  This is in sync with:

  > CEE.SCEELIB(########)                           
>      <...+....1....+....2....+....3....+....4...
004787  IMPORT CODE64,########,'name',D7A       
  
  In output, check for IMPORT CODE64,########,'name',D7A and if not found this explains:

   IEW2456E 9207 SYMBOL name UNRESOLVED.  MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY.

  May be using an old copy of CEE.SCEELIB(########) from older z/OS version.

• 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:

CALL 'SUBPGM1' USING ...

Dynamic subroutine calls are coded as:

CALL MODNAME USING ...

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

• SYSLIB DD chain

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.