Easytrieve Linking

Why Linking Exists

Compiled object code is not the same thing as the finished executable used by batch operations. Object code contains the generated Easytrieve logic plus unresolved references to product services for file handling, report formatting, sorting, and environment support. The binder combines object input with runtime libraries and produces a load module that z/OS can load directly when the job starts.

Typical Two-Step Flow

1. Compile step writes object to SYSLIN.
2. Link step reads SYSLIN and writes load module to SYSLMOD.
3. Execute step runs PGM=module from the application load library.

1
2
3
4
5
6
7
8
9
10
//COMPILE  EXEC PGM=EZTPA00
//STEPLIB  DD  DSN=DEV.EASYTRIEVE.CBAALOAD,DISP=SHR
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  DSN=DEV.EZT.SOURCE(INVRPT),DISP=SHR
//SYSLIN   DD  DSN=&&OBJ,UNIT=SYSDA,SPACE=(TRK,(5,5)),DISP=(,PASS)
 
//LINK     EXEC PGM=IEWL,PARM='LIST,MAP,XREF'
//SYSLIN   DD  DSN=&&OBJ,DISP=(OLD,DELETE)
//SYSLMOD  DD  DSN=DEV.APP.LOADLIB,DISP=SHR
//SYSPRINT DD  SYSOUT=*

The compile step passes temporary object &&OBJ to the link step. IEWL reads SYSLIN and stores the executable member in DEV.APP.LOADLIB through SYSLMOD. The module name usually comes from the compile PARM LINK(name) request or binder control statements depending on shop standards.

Key Link DD Names

Module Names and PGM=

The linked module name must align with production execute JCL. If compile requests LINK(INVRPT), the execute step normally uses PGM=INVRPT and STEPLIB that includes the library where SYSLMOD stored the module. A mismatch between linked name, member alias, and execute PGM= is a frequent cause of module-not-found errors that look like runtime failures but are really promotion or naming problems.

PARM LINK vs Separate Binder Step

Reading Binder Output

Binder listings on SYSPRINT show module name, included sections, unresolved references, and map information when requested. Review link listings for regulated changes the same way you review compile listings. A link success with unexpected module name or wrong library can still break production execution later.

Promotion After Link

Development linking into DEV.APP.LOADLIB does not automatically update production. Mature lifecycles copy or promote the approved module into PROD.APP.LOADLIB through controlled procedures. Promotion should record compile listing, link listing, test evidence, and the exact module name promoted. Never assume a test link updated production just because the bind step ended with RC=0.

Common Link Failures

• SYSLIN missing because compile step failed or did not pass the temporary dataset.
• Unresolved external reference because product runtime library was unavailable to the binder.
• Write failure on SYSLMOD due to security or space.
• Module already locked or alias conflict in target load library.
• Wrong binder PARM for site standards, producing unexpected map or module attributes.

Troubleshooting Link Steps

1. Confirm compile step produced SYSLIN and passed disposition correctly.
2. Read binder SYSPRINT for unresolved references or module name results.
3. Verify SYSLMOD library, security, and expected member name.
4. Check execute JCL PGM= against the actual linked module.
5. Compare link JCL with a recent successful application bind.

Explain It Like I'm Five

Linking is putting the finished puzzle pieces into the box with the right picture on the front. Compile cuts the pieces. Linking makes the box and label so the shelf knows exactly which puzzle to grab later. If the label says INVRPT, the shelf must look for INVRPT, not some other name.

Exercises

1. Write compile and link JCL that passes object from SYSLIN to IEWL.
2. Explain why execute PGM= must match the linked module name.
3. List three causes of unresolved external reference during link-edit.
4. Describe how promotion differs from a successful DEV link.
5. Identify which artifact proves link success besides the final return code.