Developer track · Intro · self-paced ~16h (2 days as a cohort) · no prerequisites
Architecture first: what the hardware, the operating system and the subsystems are and why each exists — then your first real sessions: TSO logon, ISPF, datasets, the editor, your first submitted job, and a batch program and an online screen reading the same record.
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.
Five short videos, each ending with you finding the thing on the live system. The roadmap: architecture, then components, then hands-on, then the bridge to your first COBOL program (CS105). Why “mainframe” is a workload word, not a cabinet word: account ledgers, card authorisation, claims, payroll, tax, reservations — and why the numbers that matter are transactions per second, consistency and recovery, not clock speed. Batch versus online and the vocabulary that goes with each: job, step, spool, transaction, task, region. Reliability, availability and serviceability as an engineering discipline, including its honest limit — badly written batch still fails at 03:00, which is why craft matters. Where mainframes sit today: banks, insurers, government, airlines, retailers and the outsourcers that run their estates, what the job postings ask for, and where each of those skills appears in this catalog. Live on the system: the CardDemo account and transaction files browsed in ISPF, an interest-calculation batch job submitted while a CICS screen views one account, and a job log read for the timestamps that bracket every step.
LAB Log on and log off — the harness records it. Find the transaction file’s record count. Submit the interest-calculation job, then view an account on the CICS screen, and report the job’s return code and the account number. From the job output, compute the step’s elapsed time. Classify five CardDemo datasets as VSAM or sequential from the DSORG column in 3.4. Session 1 checkpoint.
Six videos, slide board for the picture and terminal for the proof. z/Architecture in one pass: central processors and specialty engines (why DB2 and Java love the zIIP), central storage, the channel subsystem and the one idea behind it — the CPU never waits for a disk. Addressing modes 24, 31 and 64 with the real numbers (16 MB, 2 GB, 16 EB), the line and the bar, why AMODE/RMODE still matter and why your COBOL compiles 31-bit by default. DASD volumes, the volser, the VTOC and the catalog — the two-step lookup every OPEN performs — and tracks and cylinders as the units in SPACE=. PR/SM logical partitions: one machine, many z/OS images, what “the LPAR” means in a meeting, and sysplex in one sentence. The IPL: the SYSRES volume, the nucleus, PARMLIB, started tasks coming up, and why IPLs are rare and scheduled. The money words — MIPS, MSU, capacity on demand, the four-hour rolling average — decoded so you can follow a capacity conversation without pretending to be a capacity planner. Live on the system: the processor and storage display, the AMODE/RMODE line in a HELLO compile listing, LISTCAT’s VOLSER line, the system name in job output, D A,L on the console, and the CPU-time field in a step-end message.
LAB Record the processor count and storage size the system reports. Find AMODE/RMODE in your own HELLO compile listing. Find the volser of the CardDemo account cluster from LISTCAT. Find the system name in a job’s JESMSGLG. From D A,L, list three started tasks and say what each is for. Report the CPU time of your Session 1 job step from its messages. Session 2 checkpoint.
Five videos around the flagship idea. Every unit of work gets its own address space — a private virtual memory plus a shared common area and the nucleus — and that one idea explains isolation, why a batch job cannot corrupt CICS, why “region size” is a thing, and why a dump is per address space. The three ways work enters the system — started tasks, batch jobs, TSO users — how to tell them apart in SDSF and in the job-name conventions, and why CICS is a started task while your report is a job. Inside the address space: tasks (TCBs), the dispatcher, and Workload Manager in one honest paragraph — the teller’s transaction beats the nightly report, which is why a job can be slow while the system looks idle. Supervisor calls as what an S806 or S0C7 is actually reporting on; SYS1.PARMLIB and PROCLIB at a glance, read-only (system programming is CS430). Live on the system: JES2, the CICS region, a running batch job and your own TSO session visible as separate address spaces; two jobs in different classes and which one starts first, including one submitted to a class with no initiator and left sitting in the queue; the IGYWCL compile procedure browsed in PROCLIB to show it is just JCL.
LAB Capture the address-space list and identify your own TSO session by userid. Classify every entry as STC, JOB or TSU. Submit the provided job to a held class, watch it wait, then release it. Find IGYWCL in PROCLIB and report the name of its compile step. Then read the system as one chain of evidence for the provided job — system name, address-space type, step name, CPU time, volser of the input dataset — five values, machine-checked. Session 3 checkpoint.
Six videos, one map, each box defined by what breaks. JES2 — reads decks, converts and interprets JCL, queues work by class, runs it in initiators, keeps output on the spool — and why “the spool is full” pages the on-call. RACF — userids, groups, dataset profiles, READ/UPDATE/ALTER, and ICH408I, the message you will meet in your first week at a real shop. DFSMS, the master and user catalogs, and VSAM as the keyed access method CICS depends on; why a dataset can exist and still be “not found”; KSDS, ESDS and RRDS by name (CS130 goes inside). DB2 and CICS, the two names beside COBOL in every posting: tables, SQL and SPUFI; regions, transactions, programs and the 3270 screen; why COBOL programs talk to both. Then the rest of the map in one sentence and one message each — IMS, MQ, the batch scheduler, SMF — and where CS120–CS160 each pick up. Live on the system: every started task labelled with its box on the map; a job moving through SDSF’s input, active and output queues; an ICH408I provoked deliberately and read; LISTCAT on a KSDS showing its DATA and INDEX components; a misspelled dataset in JCL and its IEF212I; one SELECT in SPUFI; a CICS sign-on with the transaction and program definitions behind the screen; the scheduler’s definition of the CardDemo nightly chain.
LAB Match the address spaces you see to the map boxes and name the two that are absent on this system. Submit a job, find it in the output queue and purge it. Reproduce ICH408I with the provided command, then allocate the same dataset under your own high-level qualifier. Run LISTCAT on the CardDemo account cluster and report its key length and record count. Run the provided SELECT in SPUFI and view the same account on the CICS screen. From the scheduler view, list the nightly-chain jobs in order. Session 4 checkpoint.
Six videos from the name to the byte. Dataset names: qualifiers, the high-level qualifier as ownership, the 44-character limit, the naming conventions shops enforce; the catalog as the phone book that resolves name to volume, cataloged versus uncataloged, and why DISP=CATLG matters. The organisations — sequential, partitioned (your source lives in a PDS or PDSE), VSAM, and generation data groups for the nightly extract — with DSORG as the column that tells you. RECFM, LRECL and BLKSIZE: fixed versus variable, blocking as the unit of I/O, why LRECL=80 is the punched-card ghost, and what happens when a program’s idea of the record disagrees with the dataset’s (S013 / status 39, the defect class CS105 and CS300 both teach). EBCDIC: the hex view as the truth — C1–C9, D1–D9, E2–E9, F0–F9, and 40 for a space — and how to read a character line over its hex nibbles. A first look at packed decimal: two digits per byte, sign nibble last, just enough to recognise a balance in a hex view. Live on the system: LISTCAT LEVEL; a dataset on a volume that is not catalogued and how 3.4 by volume still finds it; a GDG base and its generations; dataset information on FB 80, FB 300 and VB datasets; an FB 300 file copied into an FB 80 dataset with IEBGENER and the truncation warning that follows; HELLO read as C8 C5 D3 D3 D6 under HEX ON; the account balance located from its copybook offset and read as 00 01 23 45 6C.
LAB Count the datasets under AWS.M2.CARDDEMO with LISTCAT LEVEL. Find one dataset of each organisation and report its name and DSORG. Report RECFM/LRECL/BLKSIZE of three datasets, then allocate a PS with the right attributes for a copy of the account flat file. Decode a 20-byte hex row to text by hand and confirm it with HEX ON. Decode the balance of the first three account records by hand. Then the chain: allocate a PS and a PDS to specification, copy the flat file in, and decode record 5 — account number, name, balance — attributes and values checked to the byte. Session 5 checkpoint.
Four videos. The logon panel field by field — userid, password, procedure — and what READY means. The 3270 screen-at-a-time model: nothing happens until you press Enter or a PF key, and every online program in this world is shaped by that fact (CS150’s pseudo-conversation is this, formalised). The primary option menu as a map — 0, 1, 2, 3, 3.4, 6, SD — the command line, jumping with =3.4, PF keys (3 end, 7/8 scroll, 1 help, 12 retrieve), and split screen. Option 0 and your ISPF profile: PF-key display, command line at the top, the log and list defaults, and why setting them once saves a hundred keystrokes a day. Live on the system: a narrated logon, TSO commands typed at READY, navigation by number and by = jump, split screen with edit on top and 3.4 below, and a profile change that survives a log-off and log-on.
LAB Log on, issue two TSO commands at READY, enter ISPF. Navigation drill: reach five named panels by the shortest route — the harness checks the panel IDs visited. Configure your profile as specified — the harness reads the profile dataset. Then a full working session against the provided targets: logon, ISPF, find a dataset, browse a member, a TSO command from option 6, a clean log-off. Session 6 checkpoint.
Five videos. Entering edit, the line-command area, the column ruler, and why columns 7, 8, 12 and 72 will matter the moment you write COBOL or JCL; SAVE, CANCEL and what END does. Line commands — I, D, R, C, M, the block forms CC, MM and DD with their A and B destinations, UC/LC, the shift commands — and how to RESET a pending block. Primary commands: FIND with ALL, NEXT, PREV and column limits; CHANGE ALL; exclude and flip (X ALL, F); BOUNDS to keep a change away from columns 73–80; RESET. Copying across members — COPY and MOVE with line ranges, CREATE and REPLACE — and the edit profile: NUM, CAPS, and why RECOVERY ON is not optional. Live on the system: a program’s paragraphs rearranged with block moves, an unpaired CC left pending and cleared, a field renamed everywhere under BNDS with the sequence numbers untouched, X ALL then F PERFORM to see only the control flow, a paragraph pulled in with COPY … AFTER, a dropped session recovered — and then the ten edit drills done in two minutes, because the speed is the point.
LAB Create a member and type three lines at specified columns. Put a scrambled JCL deck in the right order using only line commands. Rename a data item throughout a supplied program without touching its comment block — the harness diffs the result. Assemble one member from pieces of three others and set your profile per the checklist. Then the ten edit drills, each one command family, every result machine-checked. Session 7 checkpoint.
Six videos. A starter deck in ten lines and what each statement asks for — JOB (who and how), EXEC (what program), DD (which datasets) — read here, written in CS120. The life of a job: input, conversion and interpretation, queue by class, initiator, execution, spool, output, with each stage’s evidence in SDSF and what “on the input queue” versus “awaiting output” means at 03:00. Reading JESMSGLG and JESYSMSG: IEF236I, IEF237I, IEF285I, IEF142I, IEF375I/376I, IEF453I, and the habit of reading JESYSMSG top to bottom once. Return codes versus abends — RC 0/4/8/12/16 set by programs, S and U completion codes set by the system — and the vocabulary every mainframer reads on sight: S0C7, S0C4, S806, S813, S322, SB37 and the JCL error, one line each on cause and fix. The fix loop — read the message, find the statement, fix, resubmit, confirm RC 0 — and the common JCL errors: missing DD, misspelled DSN, wrong DISP, unbalanced quotes, column-72 overflow. Live on the system: the ten-line deck typed and submitted; one job followed through all three queues with its JESMSGLG, JESJCL, JESYSMSG and program SYSOUT identified; a clean JESYSMSG annotated line by line; six prepared jobs, one per abend code, read and named in a row; a three-fault deck fixed one fault at a time, showing why the second error only appears after the first is fixed.
LAB Copy the starter deck, change the job name to your userid plus A, and submit it. Follow your job through the queues and report which DD its output went to. From a supplied JESYSMSG, extract every dataset the job touched and each step’s return code. Three failed jobs: name each abend and the fix from the messages alone — this is the certificate’s diagnosis gate. Fix the three-fault deck to RC 0; each intermediate submission is checked. Then a two-step job that fails in step 2: diagnose, fix, rerun, and have the output dataset compared byte for byte. Session 8 checkpoint.
Five videos. Reading a COBOL program before writing one: the four divisions, the SELECT and the FD, the read loop and the paragraph conventions — recognition only, because at work you inherit programs, you don’t start them. The copybook as a shared contract: the batch program COPYs it, the CICS program COPYs it, the VSAM cluster’s record length matches it — change it in one place and everything moves, or breaks (the seam CS300 is about). Three views, one truth: the batch report line, the CICS screen and the hex of the VSAM record must agree, and cross-checking them is what makes you trustworthy on a production incident. Where DB2 fits: data that needs ad-hoc questions, joins and reporting lives in DB2 rather than VSAM, the same COBOL program can read both, and SPUFI is how you ask a question without writing a program. Live on the system: CBACT01C scrolled top to bottom with labels; the account copybook opened in COPYLIB and the same COPY statement found in CBACT01C and COACTVWC; the batch job run, one account picked from its report, viewed on the CICS screen and PRINTed from the VSAM cluster with IDCAMS so the balance can be read in hex; the same account SELECTed in SPUFI and compared to the screen.
LAB Answer five questions about CBACT01C: file name, record length, the paragraph that reads, the paragraph that closes, the FILE STATUS field. Report the copybook name, the two programs that COPY it, and the cluster’s record length. For the account the harness assigns you, report the balance from the batch report, the CICS screen and the hex of the VSAM record, then confirm it with the provided SELECT. Then trace that account end to end — job, VSAM, CICS, DB2 — on the four-view worksheet. Session 9 checkpoint.
Four videos. RACF for developers — your groups, why your job failed, how to ask for access — and what you never need (administration). The operator console and syslog as the timeline of the system: how an operator sees your 03:00 abend before you do. The nightly window: jobs triggered by jobs, calendars, conditions, late-job alerts; change control the Endevor way — stages, promotion, and why you never edit production source in place (CS410 and CS450 go deep). The modern edges employers now ask for beside COBOL, placed on the Session 4 map: Git for source with the mainframe as one more target, Zowe CLI and VS Code as a front door to datasets and jobs, CICS transactions exposed as JSON/REST, and the modernization seam (CS300) — same system, new doors. Then the capstone walkthrough: the certificate’s four gates and the recommended level-zero path from here — CS105 for COBOL, CS120 for JCL, CS130/140/150 beyond. Live on the system: D A,L, a job’s WTO in syslog and a WTOR answered from the console; the CardDemo nightly chain in the scheduler with one job demanded and its successor triggering; an element’s history through SCM stages; HELLO submitted through the REST API and appearing in SDSF like any other job; the instructor running the capstone chain start to finish in one take.
LAB Find your Session 8 job in syslog and report the line where step 2 failed. From the scheduler view, name the job that triggers after the interest calculation and the condition it waits on. Submit HELLO through the API with the provided command and find it in SDSF. Then the capstone: run your job chain — allocate, edit, submit, break, fix, verify — submit your estate map drawn from live evidence, and sit the 40-item architecture check. Course complete; certificate issued from the harness record.
CobolStack Certificate — Mainframe Foundations (CS100) 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 sit at a z/OS estate on day one: explain its architecture, navigate TSO/ISPF and datasets, submit and read jobs, and diagnose the common abends — the z/OS + TSO/ISPF + JCL baseline in every mainframe developer job posting.
Your seat is a private, full z/OS-compatible environment in the browser — nothing to install, snapshot and reset per exercise. By the end of the course the lab harness will have verified: an estate map drawn from a live system, a logon, allocated datasets, edited members, three abends read correctly, and a fixed-and-rerun batch job — all verified.