Dealing with error IEW2456E during generation of elements
Article ID: 277580
Updated On:
Products
Issue/Introduction
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?
Cause
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.
Resolution
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.
Feedback
