CardDemo — System Data & Control Flow

CardDemo benchmark corpus — 42 programs, September 2025 pinned version · publication date 2026-08-23 · basis ceb64cf6

What this is

An interactive map of the system's programs and data: every program, every call and control transfer, every dataset, DB2 table, and IMS database, with three levels of drill-down — from the system-wide call/transfer graph, into a program's job & file flow, down to the paragraph-level data flow inside a single program.

How it is made

Every element is derived from deterministically parsed source facts — COBOL programs, JCL decks, and CICS definitions. Nothing is hand-drawn and nothing is guessed by an AI: each arrow traces to specific source lines, and where a dynamic transfer target cannot be proven from the source, it is shown explicitly as unresolved rather than guessed. The same parsed fact base generates the program documentation this map accompanies.

How to use it

Open system_flow.html in any modern browser — it is fully self-contained (no network access, no installation).

Who touches what — the CRUD matrix

Open crud_matrix.html for the programs-by-data-stores view. Each C, R, U, or D marker opens the paragraph and source-line cites that prove that access. Names that cannot be resolved are shown explicitly, and anomaly badges are scoped to the packaged roster rather than claimed as system-wide facts. crud_matrix.tsv carries the same cell summary for spreadsheet and audit workflows.

What runs before what — the batch dependency chain

Open the Batch dependency chain tab in system_flow.html for the corpus-wide job ordering derived from shared datasets, or the Interactive Job-DAG ↗ tab (also batch_job_dependencies.html) for the keyboard-accessible explorer: select a job to read a plain-English summary of what it does and how it fits the chain — composed only from parsed JCL comments, resolved application ownership (including IMS/TSO wrapper steps), the program-purpose catalog, and the dependency facts — then reveal the source cites behind every statement. This is a data-dependency skeleton, not the scheduler calendar; box position is not run order. The page states its actual JCL coverage and excludes unmapped or utility-only decks rather than implying completeness. batch_job_dependencies.svg is a print/offline fallback whose job boxes deep-link back into the interactive page, and batch_job_dependencies.tsv carries every writer/read pair with its deck, step, DD, disposition, and source-line cite. batch_jobs.tsv is the source-cited roster of every job counted in the viewer, including jobs with no cross-job relationship row.

What never runs — the static findings report

Open static_findings.html for the maintenance view over every resident static-analysis finding. Pivot by program or detector family, then expand a row to inspect every recorded field and source cite. “Uninvoked” is a static reachability result, not a runtime observation; the report states that scope and the packaged roster size explicitly. static_findings.tsv contains the same one-row-per-detector inventory for audit workflows.

What breaks if I change this — impact analysis

Open impact.html to select a program or data store and trace its cited upstream and downstream blast radius. The report follows static call and data-access facts, not runtime scheduling, stops at a visible user-adjustable depth, and excludes unresolved dynamic targets rather than guessing them. impact.tsv carries every depth-bounded closure row for audit.

Reading the shapes

Program boxes represent executable units; dataset and database shapes represent persisted stores. Solid arrows are proven control or data dependencies, dashed amber links are shared mutable state whose ordering remains unresolved, and every unresolved dynamic target is labeled rather than guessed. The interactive viewer carries the complete shape and line legend beside the map.