IEW2520W messages issued by IBM's Binder in a processor.

Products

• Endevor
• Endevor Natural Integration
• Endevor - ECLIPSE Plugin
• Endevor - Enterprise Workbench
• CA 2E

Issue/Introduction

IBM's Program Binder, when executed in an Endevor processor, may issue a series of IEW2520W messages like this:

IEW2520W 4706 IDRZ IMAGE FFF1 DOES NOT CONTAIN A VALID ESD IDENTIFIER.
IEW2520W 4706 IDRZ IMAGE FFF2 DOES NOT CONTAIN A VALID ESD IDENTIFIER.
IEW2520W 4706 IDRZ IMAGE FFF3 DOES NOT CONTAIN A VALID ESD IDENTIFIER.
IEW2520W 4706 IDRZ IMAGE FFF4 DOES NOT CONTAIN A VALID ESD IDENTIFIER.
IEW2520W 4706 IDRZ IMAGE FFF5 DOES NOT CONTAIN A VALID ESD IDENTIFIER.

The resulting of the above being a Return Code 4 for that step.

This usually occurs when the Binder includes another load module that has previously been footprinted (FOOTPRNT=CREATE on the SYSLMOD DD statement), but it can also occur when relinking a load module in order to expand the ZAP IDR space. There are 5 messages, corresponding to the 5 slots in the ZAP IDR record that Endevor uses for storing a footprint. The Binder regards the footprint as invalid use of this record.

Resolution

The simplest way to deal with these messages is to accept them, along with the return code 4. However, if you want to eliminate them there are 2 options available:

Remove the FOOTPRNT=CREATE from SYSLMOD DD statements pertaining to load modules that will be included in subsequent Binder steps or processors.

You may continue to footprint your csects (FOOTPRNT=CREATE on the SYSLIN DD statement in the compile step) as these are not affected.

OR

Use program objects, which are stored on PDS/E, instead of load modules, which are stored on PDS. The problem only involves footprinted load modules, not program objects, so you can retain the FOOTPRNT=CREATE if you have the SYSLMOD DD statement pointing to a PDS/E rather than a PDS.