Developer track · Intro → Core · self-paced ~30h (4–6 weeks at 6h/week) · prerequisite: CS100
COBOL for the true beginner, taught the way the language is actually met at work: read a real program before you write one, then grow one program across twelve sessions — a DISPLAY, then data, then bytes, arithmetic, decisions, loops, a file, a report, a table, a copybook, a subprogram — until it is a real batch program with control totals. Every step compiled, run, and checked to the byte.
Self-paced available Cohort
Every session ends in a lab on your own environment. Labs are machine-checked against expected outputs — you and your L&D team always know exactly where you stand.
A production-shaped COBOL program read top to bottom — the account-file batch program from the demo estate — with nothing skipped: IDENTIFICATION, ENVIRONMENT, DATA and PROCEDURE divisions, the coding form and why columns 8 and 12 matter, paragraphs, the read loop, where the record layout lives. How COBOL reads aloud and why that was the point in 1959. You will not write a line yet; you will learn to recognise the shape.
LAB Answer the harness’s questions about the program: which paragraph opens the file, what the record length is, where the loop ends, which FILE STATUS the program checks. All from reading.
What the compiler produces (the listing, the object), what the linkage editor produces (the load module in a PDS), and what the run JCL binds (DD names to datasets). Reading a listing: source with line numbers, messages, severity codes, RC 4/8/12 and what each means for whether you may run. STEPLIB, and why program-not-found is an S806.
LAB Compile a program seeded with five errors; fix each from the listing message until RC 0; run it. The harness reads your listing, not your word.
Your program begins: PIC X and PIC 9, VALUE, MOVE, DISPLAY, STOP RUN. Level numbers and group items; FILLER; what a WORKING-STORAGE item physically is. The habit of naming things so the next reader — you, in six months — can read them aloud.
LAB Growth checkpoint 1: the program prints a three-line header from working storage. Output checked to the byte, including the trailing blanks you did not know you wrote.
Zoned decimal and why 123 is F1F2F3; the sign overpunch; COMP-3 packed decimal nibble by nibble, all six sign nibbles; COMP binary halfword and fullword; what S9(7)V99 COMP-3 stores in five bytes. The S0C7 provoked on purpose — bad data into a packed field — and read from the dump so you never fear it again.
LAB Growth checkpoint 2: add amount fields in each storage type; hex-verify every one against the harness’s expected bytes; then cause the S0C7 and identify the offending statement from the offset.
ADD, SUBTRACT, MULTIPLY, DIVIDE and COMPUTE; intermediate precision; ROUNDED and ON SIZE ERROR and why silent truncation is the enemy; edited pictures — Z, comma, decimal point, CR/DB, floating signs — for money that reads like money.
LAB Growth checkpoint 3: interest and fee lines computed and formatted; the harness checks the cents and the rounding, both directions.
IF/ELSE/END-IF, nested conditions and how to flatten them, EVALUATE as the decision table it really is, 88-level condition names as the readable alternative to magic values, class conditions (NUMERIC) as your first line of defence against bad data.
LAB Growth checkpoint 4: account-status classification with 88-levels and an EVALUATE, graded against a truth table of 24 cases.
PERFORM in all its forms — paragraph, inline, TIMES, UNTIL, VARYING — and the one skeleton every batch program shares: initialise, prime, loop until end, finalise. Why GO TO is not on the syllabus. Counters and accumulators done properly.
LAB Growth checkpoint 5: the program loops over an in-storage table of five accounts and produces totals the harness checks.
SELECT/ASSIGN, the FD, OPEN/READ/CLOSE, AT END and the priming read; FILE STATUS on every I/O — the discipline that separates production code from coursework; the DD statement that binds the SELECT to a dataset; what happens when LRECL disagrees with the record (an S013 — or the silent zero-count run that is worse).
LAB Growth checkpoint 6: the program reads the real account file; record count and a control total of balances must match the harness exactly. No naked READs — the static check enforces it.
WRITE and the output FD; headings, detail lines, page breaks and page counts; final totals; a second output file for records that fail validation, with a reason code, so nothing is ever silently dropped.
LAB Growth checkpoint 7: the account statement report plus an error file, both compared byte-for-byte against expected output, page breaks included.
OCCURS, subscripts, then indexes and why they differ in the bytes; SEARCH and SEARCH ALL and the sorted-table rule; two-dimensional tables. COPY: the record layout moves to a copybook and becomes a contract shared with the JCL, the VSAM cluster and the CICS screen you saw in CS100.
LAB Growth checkpoint 8: interest rates come from a rate table looked up by account type; the record layout comes from a copybook; the harness diffs your copybook against the one it expects.
Static CALL, USING, and the LINKAGE SECTION; BY REFERENCE for real; return codes between programs; how the link-edit joins two objects into one load module — and why a wrong LINKAGE picture corrupts silently instead of failing.
LAB Growth checkpoint 9: the rate calculation moves to a CALLed subprogram with its own compile; output must not change by a byte.
Reading an abend for real: S0C7, S0C4, S013, S001, and the listing offset that points at the statement; DISPLAY as disciplined tracing; the compiler options that help and the ones that hide. A code-review checklist — FILE STATUS everywhere, no GO TO, no naked READ, names that read aloud, one paragraph one job. Restart thinking: what an operator needs from your program at 03:00.
LAB Five broken programs, five different failures; diagnose and fix each; the harness grades the fix and your one-line root-cause statement.
The grown program is run by the harness against a hidden input file with the edge cases production has: bad packed data, a zero balance, an account type not in the table, a page break exactly on a total line. Then where next: CS120 for the batch plumbing, CS130 to make this program keyed over VSAM, CS140 and CS150 for DB2 and CICS — or CS110 if you want the cohort intensive.
LAB Capstone run: report, error file and control totals byte-checked; static craft rules enforced; the certificate is issued from this run.
CobolStack Certificate — COBOL On-Ramp (CS105) is issued from the lab harness’s own record of your runs — not from attendance. To earn it you must clear every gate below:
The certificate attests that you can read, write, compile, run and debug a complete sequential-file COBOL batch program with control totals — the COBOL + JCL + z/OS core that entry-level postings at banks, government and the outsourcers filter on — and that a machine, not an attendance sheet, verified it.
Your seat is a private, full z/OS-compatible environment with the compile-link-run pipeline, hex views and the graded lab harness in the browser — nothing to install, snapshot and reset per exercise. By the end of the course the lab harness will have verified: one program grown through twelve graded checkpoints into a complete batch application, five broken programs diagnosed and fixed, and a hidden-dataset capstone run green.