Compiling & Running COBOL on z/OS
Learn the compile-link-go JCL pattern: how COBOL source code becomes a load module, and how JCL's EXEC PGM= statement then runs it.
Introduction
You now know how to read a COBOL program's structure and logic. This lesson closes the loop by explaining how that source code actually becomes something z/OS can run — and, in doing so, ties this entire COBOL detour directly back to the JCL skills you built earlier in this unit. The process is commonly called compile-link-go, and it is one of the most fundamental JCL patterns in any mainframe shop.
From Source Code to Running Program
The COBOL source code you read in the previous lesson — the human-readable IDENTIFICATION/ENVIRONMENT/DATA/PROCEDURE text — is not directly executable. Like most compiled languages, it has to go through a translation process before z/OS can actually run it as a program. On the mainframe, that process traditionally happens in three distinct stages, each of which is itself simply a JCL step running a specific IBM utility program.
| Stage | What Happens | Typical Program |
|---|---|---|
| Compile | COBOL source is translated into machine-oriented object code | IGYCRCTL (the COBOL compiler) |
| Link-Edit | Object code is resolved and packaged into an executable load module | IEWL (the linkage editor / binder) |
| Go (Execute) | The finished load module is actually run | The program's own PGM= name, e.g. DEBITSUM |
The name simply describes the three things that happen, in order: compile the source, link the result into something runnable, and go — run it. Many shops have a single cataloged PROC that performs all three stages together, commonly with a name like COBUCLG (COBOL, Update, Compile, Link, Go) or similar, so a developer or systems person rarely has to hand-code all three steps from scratch.
Step One: Compile
The compile step runs the COBOL compiler against the source code, checking it for syntax errors and translating valid COBOL into an intermediate form called an object module (or object deck). The compiler also produces a detailed listing — showing the source code, any diagnostic messages, and cross-reference information — which is exactly what a programmer or systems person reviews first when a compile fails.
//COMPILE EXEC PGM=IGYCRCTL,REGION=0M//STEPLIB DD DSN=IGY.SIGYCOMP,DISP=SHR//SYSIN DD DSN=PROD.COBOL.SOURCE(DEBITSUM),DISP=SHR//SYSLIN DD DSN=&&OBJSET,DISP=(NEW,PASS),// SPACE=(TRK,(10,5)),// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)//SYSPRINT DD SYSOUT=*Click Run to see what this code prints.
Step Two: Link-Edit
An object module by itself is still not directly executable — it may reference other pieces of code (subroutines, runtime library routines) that need to be resolved and combined into one self-contained unit. The link-edit step (sometimes called binding) takes the object module produced by the compile step and produces a load module: a fully resolved, executable program ready to be placed in a load library and run.
//LKED EXEC PGM=IEWL,REGION=0M,// COND=(4,LT,COMPILE)//SYSLIN DD DSN=&&OBJSET,DISP=(OLD,DELETE)//SYSLMOD DD DSN=PROD.APPL.LOADLIB(DEBITSUM),DISP=SHR//SYSPRINT DD SYSOUT=*Click Run to see what this code prints.
Step Three: Go (Execute)
The final stage is simply running the finished, linked program, exactly the way you have been doing throughout the JCL unit: an EXEC PGM= statement naming the load module, with DD statements supplying whatever files the program's ENVIRONMENT DIVISION expects.
//GO EXEC PGM=DEBITSUM,// COND=((4,LT,COMPILE),(4,LT,LKED))//TRANIN DD DSN=PROD.TRANS.DAILY,DISP=SHR//RPTOUT DD SYSOUT=*A Complete Compile-Link-Go JCL Job
//COBCLGJ JOB (ACCT77),'M PATEL',CLASS=B,MSGCLASS=X,NOTIFY=&SYSUID//COMPILE EXEC PGM=IGYCRCTL,REGION=0M//STEPLIB DD DSN=IGY.SIGYCOMP,DISP=SHR//SYSIN DD DSN=PROD.COBOL.SOURCE(DEBITSUM),DISP=SHR//SYSLIN DD DSN=&&OBJSET,DISP=(NEW,PASS),// SPACE=(TRK,(10,5)),DCB=(RECFM=FB,LRECL=80)//SYSPRINT DD SYSOUT=*//LKED EXEC PGM=IEWL,REGION=0M,COND=(4,LT,COMPILE)//SYSLIN DD DSN=&&OBJSET,DISP=(OLD,DELETE)//SYSLMOD DD DSN=PROD.APPL.LOADLIB(DEBITSUM),DISP=SHR//SYSPRINT DD SYSOUT=*//GO EXEC PGM=DEBITSUM,// COND=((4,LT,COMPILE),(4,LT,LKED))//TRANIN DD DSN=PROD.TRANS.DAILY,DISP=SHR//RPTOUT DD SYSOUT=*Click Run to see what this code prints.
Where Load Modules Live
A load library is simply a partitioned dataset whose members are executable load modules rather than source text or JCL — recognizable in real shops by naming conventions like the LOADLIB qualifier you learned about in the dataset naming lesson. When any later JCL job codes EXEC PGM=DEBITSUM, z/OS searches a defined set of load libraries (system defaults, plus any named on a JOBLIB or STEPLIB DD statement) looking for a member named DEBITSUM, and runs whatever it finds there — completely independent of, and usually much later than, whenever that program was originally compiled and linked.
Common Mistakes
- Assuming a compile alone produces something runnable — an object module still needs the link-edit step before it becomes an executable load module.
- Forgetting COND checks between compile-link-go steps, letting a failed compile waste time attempting to link and run broken or missing object code.
- Confusing a load library with a source library — PGM= searches load libraries specifically, never COBOL source code directly.
- Assuming a running program automatically reflects the latest source code changes — if source was edited but not recompiled and re-linked, the load module (and therefore what actually runs) is unchanged.
Best Practices
- Use a shop's existing cataloged compile-link-go PROC rather than hand-coding all three steps yourself whenever one is available.
- Always check the compile step's SYSPRINT listing first when a compile-link-go job fails — most failures originate there, not in link-edit or execution.
- Chain COND checks between steps so a failed compile does not waste time and resources attempting later stages.
- Keep load libraries and source libraries clearly separated and named according to shop convention, so PGM= searches stay predictable.
Frequently Asked Questions
An object module is the intermediate output of compiling source code — translated but not yet fully resolved or executable. A load module is the finished, executable result of link-editing one or more object modules, ready to be run by an EXEC PGM= statement.
Historically and practically, compiling, linking, and executing are distinct operations that can each fail independently and benefit from being checked separately (via COND) before moving on, and because link-edit can combine multiple separately compiled object modules into a single load module.
It tells z/OS an additional library to search for this step's program (here, the COBOL compiler itself, IGYCRCTL) beyond the standard system search order — commonly needed because compiler and language products are not always in the default system libraries.
No. The change only takes effect once the source is recompiled and re-linked into a new load module that replaces (or newly creates) the corresponding member in the load library. Until that happens, JCL running the old PGM= name continues executing the previous, unchanged load module.
Key Takeaways
- Compile-link-go describes the three-stage process turning COBOL source into a runnable program: compile, link-edit, and execute.
- The compile step (typically PGM=IGYCRCTL) translates COBOL source into an object module and produces a diagnostic listing.
- The link-edit step (typically PGM=IEWL) resolves an object module into an executable load module, stored in a load library.
- The go step is an ordinary EXEC PGM= statement, exactly like every other program execution you have studied in this unit.
- A load module only changes when source is recompiled and re-linked — editing source alone has no effect on what actually runs.
Summary
Compile-link-go is the bridge between the COBOL source code you learned to read and the JCL EXEC PGM= statements you learned to write earlier in this unit — and now you have seen exactly how the two connect, start to finish. With this brief but important COBOL detour complete, the course returns fully to systems territory: the next lesson steps back to look at batch processing itself as a concept, tying together everything you have learned about JCL, utilities, and COBOL into the bigger picture of how mainframe work actually gets organized.