Batch Processing & JCL: How COBOL Programs Actually Run
COBOL Intermediate/Advanced
Chapter 3 · Batch Processing & JCL: How COBOL Programs Actually Run
Every program in this course so far has simply "run." On a real mainframe, a compiled COBOL program never runs by itself — it's submitted as one step of a real batch job, described entirely in a separate, genuinely different language: JCL, Job Control Language.
What JCL Genuinely Is
JCL emerged real and complete during the OS/360 project in the 1960s, built specifically to ensure every real resource a batch job needed — programs, datasets, devices — was declared and allocated before that job ever actually ran.
Three Real Statement Types
| Statement | What It Genuinely Declares |
|---|---|
| JOB | Marks the real start of the whole job — billing, run priority, real time/space limits |
| EXEC PGM= | Names the real compiled program to run for this one step |
| DD | Connects a real dataset (or device) to the specific name a program's own code refers to internally |
Connecting JCL to COBOL: ASSIGN TO a Real DD Name
A mainframe COBOL program's real SELECT ... ASSIGN TO clause doesn't name a literal file path the way a PC-based COBOL program might — it names the exact ddname the runtime expects the executing JCL to supply:
TXNFILE in the COBOL source and //TXNFILE DD DSN=PROD.TXN.DAILY,DISP=SHR in the JCL are the real two halves of the same connection. The compiled program never changes; whoever writes the JCL for a given real run decides which actual dataset TXNFILE genuinely points at that time — a different real file, a different real run, with zero recompilation needed.
RETURN-CODE: A Program's Own Real Exit Status
Before ending, a real COBOL program can set its own genuine condition code — a real special register, RETURN-CODE — by convention ranging from 0 (normal) up through 16 (a real terminal error):
COND: Real, Genuinely Backward Conditional Logic
A real COND parameter on a later EXEC statement can skip that step based on an earlier step's own RETURN-CODE:
COND conditions state when a step is skipped, not when it runs. COND=(4,LT,STEP1) genuinely means "skip STEP2 if 4 is less than STEP1's real return code" — in other words, STEP2 only actually runs if STEP1 finished with a return code of 4 or lower. Reading a COND clause as "run if" instead of "skip if" gets the real logic backwards every time.
Hands-On Exercises
Using this chapter's own real material, explain in your own words why SELECT TRANSACTION-FILE ASSIGN TO TXNFILE lets the exact same compiled TXNBATCH program process a genuinely different real dataset on two separate nightly runs, with no recompilation between them.
📄 View solutionUsing this chapter's own real COND example, explain in your own words exactly when STEP2 genuinely runs and when it's genuinely skipped, and why reading COND=(4,LT,STEP1) as "run STEP2 if 4 is less than STEP1's return code" would be a real, backward misreading of it.
📄 View solutionUsing this chapter's own real RETURN-CODE example, explain in your own words why TXNBATCH setting RETURN-CODE to 16 before a real STOP RUN matters at all to whatever job step comes after it, given that STEP1 has already ended by the time STEP2's own COND is evaluated.
📄 View solutionChapter 3 Quick Reference
- JOB / EXEC PGM= / DD — real JCL statements marking the job, naming the program, and connecting datasets to internal file names
- SELECT ... ASSIGN TO ddname — the real, exact link between a COBOL program's internal file reference and JCL's own DD statement
- RETURN-CODE — a real special register; by convention, 0 is normal, 16 is a real terminal error
- COND=(value,operator,stepname) — real conditional step logic that states when a step is skipped, not when it runs