JCL & Batch

JOB, EXEC, DD

Seven videos, each one a lesson, a live demo and your own exercise on the same environment — and every JCL claim proven by a job and read back from the spool. The JOB statement as the header of the whole job: name, accounting and programmer fields, CLASS, MSGCLASS, MSGLEVEL and REGION, continuation and the column-72 edge. EXEC: one step, one program; step names as the labels everything later refers to; PARM as a string the program interprets; step-level REGION and TIME. The DD statement and the most important idea in JCL — a program opens a DDname, never a dataset, so the same program runs against different data by changing only the JCL — walked through IEBGENER’s SYSUT1/SYSUT2/SYSPRINT/SYSIN contract. Instream data with DD * and DD DATA,DLM=, and DD DUMMY. SYSOUT and output classes, and the three files every job gets — JESMSGLG, JESJCL and JESYSMSG — read with the IBM message ID named beside every SteelFrame line. Checking before you run: TYPRUN=SCAN, TYPRUN=HOLD and NOTIFY. Live on the system: JESJCL shrinking from MSGLEVEL=(1,1) to (0,0), a bad jobname rejected as a JCL error, one SuperC program producing two listings from one changed PARM, a deleted SYSUT1 DD ending RC 12 — neither a JCL error nor an abend — a // line ending DD * early while DLM=@@ carries it as data, SCAN catching an unclosed parenthesis, and a held job released to RC 0.

LAB Run your own JOB card with MSGLEVEL=(1,1) and (0,0) and compare the JESJCL. Add a named step with its own TIME= and read the step table. Run an IEBGENER copy, then break its DD contract and report the RC and message ID. Copy instream data containing a /* line intact. List each DD’s allocation and disposition lines from JESYSMSG. SCAN a deck with a planted error, fix it, then run it held and release it. Lab 1.7, build a job from a blank member: NIGHTLY1, typed from an empty member — a job card with CLASS, MSGCLASS, NOTIFY and MSGLEVEL=(1,1), an EXTRACT step copying CardDemo’s 300-record daily-transaction file and a NOTE step with three instream lines — SCANned clean and run to MAX-RC 0. Session 1 checkpoint (JS01, machine-checked online).

Datasets in JCL

Coming soon Video 2.8, the lab walk-through, is coming soon — 2.1–2.7 are recorded, and the JS02 lab spec is below.

Eight videos on datasets in JCL. DSN: qualifiers, the HLQ as ownership, members and the catalog lookup at allocation — and two failures to tell apart on sight: dataset not found (a JCL error; the step never starts) versus member not found (the step starts and the OPEN abends S013). DISP status — NEW, OLD, SHR, MOD — and the course rule: always code DISP. The normal and abnormal dispositions as two separate decisions, and the trap every junior falls into: a step that ends RC 16 has ended normally, so (NEW,CATLG,DELETE) catalogs the half-baked output. SPACE in tracks, cylinders and blocks, primary, secondary and directory blocks, and the x37 abends by name. Where RECFM, LRECL and BLKSIZE come from — the program, the DD, a LIKE= or DCB= model — and the system-determined block size. Temporary datasets with &&names and PASS, and why they are the wrong choice across a restart boundary. Referbacks (*.step.dd for a dataset or its DCB) and concatenation, the everyday yesterday-plus-today pattern. Live on the system: SFE212I (IBM IEF212I) versus IEC141I 013-18 from the same typo class, a record count going 2 → 2 → 3 → 3 through NEW, OLD, MOD and SHR, DISP=NEW on an existing name refused, an SD37 output deleted while an RC 16 output stays cataloged, SD37 and SE37 on purpose and the SPACE that fixes them, three datasets allocated three ways side by side in 3.4, a temporary PASSED then DELETED with no trace left, and one output built from a permanent dataset and a referback, in order.

LAB Reproduce dataset-not-found and member-not-found on your own names. Run NEW → OLD → MOD and report the record count after each step, then trigger the DISP=NEW refusal. Produce both disposition outcomes — an abend and an RC 16 — and read the catalog afterwards. Size a SPACE for the daily-transaction copy that works first time, then show one that fails. Allocate an FB 350 output three ways and report each one’s attributes. Build a two-step temporary hand-off that leaves nothing behind. Concatenate two datasets through a referback. Lab 2.8, a multi-step job passing datasets forward: NIGHTLY2 extracts into a temporary &&EXTR, keeps it as the permanent CS120.EXTRACT through a referback with every DISP coded, and prints its first records — MAX-RC 0, 300 records cataloged FB 350, the temporary gone. Session 2 checkpoint (JS02, machine-checked online).

Multi-step logic

Coming soon The seven Session 3 videos (3.1–3.7) are coming soon; the lessons and the JS03/JS04 lab spec are published here now.

Seven videos on multi-step logic. Return codes: the program sets them, not JCL; the 0/4/8/12/16 conventions; the job’s MAXCC as the highest RC of the steps that ran; and IDCAMS SET MAXCC to manufacture any RC you need for testing. COND=, the backwards test — it tells the system when to skip — with up to eight tests ORed, and job-level COND ending the whole job. IF/THEN/ELSE/ENDIF with relational operators, &, |, NOT and step.RUN, and when to prefer it over COND. The three failure classes and their evidence — a JCL error (the job never ran, or stopped before a step started), an abend (S806, S013, SD37) and a non-zero RC (the program ran and reported a problem) — and what each does to the steps after it. Steps that run because something failed: COND=EVEN, COND=ONLY, IF (ABEND) and IF (step.ABENDCC = S806). Restart thinking: RESTART=stepname, rerunnable steps that delete their own output first, and the design rule that anything crossing a restart point must be a cataloged dataset, never a temporary. Live on the system: a 0-4-8-0 step table and RC=0008 in the job log, a COND read forwards and the step table proving the opposite, the same chain rewritten as IF with an identical step table, a misspelled program giving CSV003I and S806 with the next step flushed, cleanup and alert steps running only after the abend, and a restart past a PASSed temporary failing as a JCL error until the hand-off is made cataloged and delete-first.

LAB Predict a job’s MAXCC from your own RC pattern before running it. Six COND expressions against an RC history, each predicted RUN or BYPASS, then run. Convert three COND steps to IF/THEN/ELSE with identical step tables. Classify three failed jobs you have not seen from the messages alone and name each fix. Add an on-failure step that runs only when an earlier step abends, proven by one clean and one forced-S806 run. Make your JS02 chain restartable at its second step and restart it there. Lab 3.7, conditional chains that skip and resume correctly: NIGHTLY3 — CLEANUP, EXTRACT, an ICETOOL COUNT … EMPTY switch check, SORTIT only if the check is 0, REPORT only if SORTIT ran clean, ALERT only on an abend — graded across a run-everything, a skip-tonight (RC 4) and a forced-abend run, then a RESTART=SORTIT run that must end RC 0. Session 3 checkpoint (JS03 + JS04).

Procedures and symbols

Coming soon The seven Session 4 videos (4.1–4.7) are coming soon; the lessons and the JS05/JS06 lab spec are published here now.

Seven videos on procedures and symbols. Why every shop’s decks are mostly EXEC procname, read first: a compile procedure expanded in a listing, with // for your lines, XX for cataloged-procedure lines, ++ for instream-procedure lines and the substitution lines. Instream procedures with PROC and PEND, and step names that become execstep.procstep in every message. Symbolic parameters, PROC defaults and EXEC overrides, and the period rule — &HLQ..CS120 becomes IBMUSER.CS120 because the first period only ends the symbol. Cataloged procedures through JCLLIB ORDER=, shared fragments through INCLUDE MEMBER=, and search order. SET and job-level symbols — one deck for every environment — and system symbols such as &SYSUID. Changing a procedure without editing it: DD overrides, additions, nullification with KEYWORD=, PARM.procstep= and COND.procstep=, overriding a concatenation, and override order. Live on the system: IGYWCL browsed and its expansion walked, a copy wrapped as an instream procedure and called twice, a single-period symbol producing a 13-character qualifier and the listing line that explains it, a job shrunk to three cards behind JCLLIB, a missing INCLUDE member failing the job, SET ENV=PROD resolving inside a procedure body, and BLKSIZE overridden to 1600, nullified back to the system-determined 27920 and a second input added to a concatenation — the procedure member untouched. Where SteelFrame differs from IBM z/OS here, the video says so on camera.

LAB Report a procedure’s step names and DDnames from its expanded listing. Convert your JS02 deck into an instream procedure called twice with unchanged output. Parameterise its HLQ and output suffix and run it with two suffixes. Catalog it, call it through JCLLIB and INCLUDE one shared DD fragment. Add SET ENV= and run it for TEST and PROD. Using overrides only, change one BLKSIZE, add a second input to a concatenation and nullify one keyword. Lab 4.7, parameterize the nightly job: NIGHTLY3 becomes the cataloged procedure NIGHTLY with HLQ, ENV and INDSN symbolics and its COND/IF logic inside; the calling job is a JOB card, JCLLIB, SET and one EXEC, and its outputs match JS03 byte for byte; then an override run that sends the report to a different SYSOUT class and nullifies one DCB keyword. Session 4 checkpoint (JS05 + JS06).

GDGs

Coming soon The six Session 5 videos (5.1–5.6) are coming soon; the lessons and the JS07/JS08 lab spec are published here now.

Six videos on generation data groups. The same logical file every day — today’s extract, yesterday’s, the day before — held as base.GnnnnV00 generations under a LIMIT and referred to by relative number, so the JCL never changes. Defining the base with IDCAMS DEFINE GENERATIONDATAGROUP: LIMIT, SCRATCH versus NOSCRATCH, EMPTY versus NOEMPTY, and delete-first for rerunnable definitions. Creating generations with (+1) and a model, and two new generations in one job as (+1) and (+2). Reading them with (0), (-1) and the bare base name, and the one rule that explains most GDG bugs: relative numbers are fixed when the job starts, so the (+1) you just wrote stays (+1) for the rest of the job and (0) still means yesterday’s. Cycles and roll-off, and choosing a LIMIT for a retention policy. Live on the system: CardDemo’s own transaction-backup GDG read with LISTCAT, a LIMIT(7) NOEMPTY SCRATCH base defined and listed, a model-driven (+1) cataloged as G0001V00, (0) returning the previous generation inside the creating job, yesterday’s (+1) failing as today’s JCL error, a LIMIT(3) NOEMPTY group rolling off its oldest generation and a LIMIT(2) EMPTY group keeping only the newest. On this system a new generation joins the base at job end, so every GDG LISTCAT runs in the following job — the video says so.

LAB Report CardDemo’s backup GDG LIMIT, SCRATCH setting and newest absolute name. Define your ARCHIVE base and read its attributes. Create three generations, one per job, and report their absolute names. Predict which absolute generation each relative reference in a five-step job resolves to, then run it. Cycle a LIMIT(3) test base past its limit under NOEMPTY, then predict and verify EMPTY on a second base. Lab 5.6, a daily extract with GDG rotation: the NIGHTLY procedure gains an ARCHIVE step writing the day’s extract to ARCHIVE(+1) from the model, and DAILYCMP reports the record counts of (0) and (-1) with ICETOOL COUNT — run four “days” against a LIMIT(3) base, and exactly three generations survive with 250 records in the newest. Session 5 checkpoint (JS07 + JS08).

The utility toolbox

Coming soon The nine Session 6 videos (6.1–6.9) are coming soon; the lessons and the JS09 drill spec are published here now.

Nine videos — the longest session — on the utility toolbox: every step a utility, no program written. IEFBR14, the program that does nothing, so its DDs do the work: create-empty and the rerun-safe delete-if-present (MOD,DELETE,DELETE). IEBGENER to copy, print and reblock, and ICEGENER as DFSORT’s drop-in. DFSORT in three parts: SORT FIELDS with CH, ZD and PD keys and SORT FIELDS=COPY, with control statements that are not JCL — they stop at column 71 and continue with a comma; INCLUDE and OMIT COND, and OUTREC to reshape records and edit numbers; SUM FIELDS to collapse equal keys and OUTFIL to build a report with a header and a trailer count and total. ICETOOL running many operations in one step — COPY, COUNT, SORT … USING, OCCUR and DISPLAY — each with its own RC. IDCAMS in batch: DELETE, LISTCAT, REPRO, PRINT and its own IF LASTCC … SET MAXCC logic (VSAM DEFINE CLUSTER is CS130). IEBCOPY for libraries, with SELECT and EXCLUDE. Live on the system: a delete-if-present ending RC 0 on a name that never existed, a reblocked copy with its attributes before and after, a sort statement typed past column 71 failing ICE003A RC 16 until it is continued, 300 transactions in and 250 purchases out, 250 purchases summed into 50 cards, a one-page report with RECORDS:00000250 and 129200.83 in its trailer, an ICETOOL COUNT of 300, an IDCAMS DELETE that fails every first run until LASTCC is handled, and a PROCLIB backed up member by member.

LAB A CLEANUP step for all of NIGHTLY’s work datasets that ends RC 0 twice running. Reblock the extract to a stated BLKSIZE. Sort the daily transactions descending by amount and report the first transaction. An 80-byte extract of purchases with card number and edited amount. The per-card summary and the one-page report: 50 summary records, the trailer count and the total to the cent. An ICETOOL step that counts, lists type-code frequencies and copies the top ten amounts. A rerunnable IDCAMS housekeeping step. A full PROCLIB backup with IEBCOPY. Lab 6.9, utility drills over real files: six timed decks over CardDemo’s read-only inputs — IEFBR14 cleanup, IEBGENER reblock, SORT with INCLUDE and OUTREC, SORT SUM, ICETOOL COUNT and OCCUR, IDCAMS delete + LISTCAT with an IEBCOPY backup — every output checked. Session 6 checkpoint (JS09).

Capstone

Coming soon The six capstone videos (7.1–7.6) are coming soon; the full NIGHTLY spec and lab are published here now.

Six videos building NIGHTLY, a miniature nightly chain run as a cataloged procedure: CLEANUP (delete-first) → EXTRACT (purchases) → SORTCARD (by card) → SUMCARD (per-card totals) → REPORT (header and trailer) → ARCHIVE (a new GDG generation) → ALERT (only on an abend). Reading the spec and its proof points — 250 extracted, 50 cards, RECORDS:00000250, 129200.83 and exactly one new generation per successful day — and turning it into a step, dataset and DISP table. Designing for restart, each rule tied to an earlier failure: delete-first, no temporaries across a restart point, the GDG written once and last, IF guards and the ALERT step — plus the one restart case where this system is more forgiving than z/OS, named so you never depend on it. Building the procedure from the pieces of Sessions 2–6 and SCANning it before the first run. Breaking it three ways, one per failure class — a space abend, a rerun without cleanup that fails as a JCL error, and a sort error the IF guards contain — and reading the one spool line that names each. Restarting at the failing step after fixing the cause, and proving the result identical to a clean run with one new generation, not two. Then the wrap-up: your job streams mapped to the skills, the honest list of what the course leaves out (the production scheduler, checkpoint restart, OUTPUT statements, SMS classes, tape, VSAM DEFINE) and where to go next.

LAB Fill in the step/dataset/DISP table before the design video, then mark each step with its restart answer. Build NIGHTLY, SCAN it clean and run it to RC 0 against every proof point. Break it three ways and identify each failing step, failure class and evidence line. Lab 7.5, break it, restart it, prove it: the harness plants a fault you have not seen; you diagnose it, fix it, restart at the right step, and prove identical proof points, exactly one new ARCHIVE generation and RC 0. Capstone (JS10 clean run, JS11 break, JS12 restart) — the certificate evidence. Course complete.