A Program Logic Manual tells you what one program does. The System Data & Control Flow map tells you how the entire estate hangs together: every program, every call and control transfer, every dataset, DB2 table and IMS database. Click any program to drill inside it, all the way down to the data flow between paragraphs.
Best experienced full screen. The map is self-contained: no network calls, no installation.
The system map spans 83 linked views with zoom, pan and three levels of drill-down. That needs a large canvas, so rather than shrink it into a phone-sized panel here, open it in its own tab. It is self-contained: no network calls, no installation.
Open the flow map →Every program and the calls, links and control transfers between them. Legend checkboxes switch whole subsystems on and off so you can isolate one area at a time.
Click a program box and you get its world: the JCL steps that run it, the datasets and DB2 tables it reads and writes, and the programs on either side of it.
Click the program again and you are inside it: how data moves between paragraphs, where each field is set, and which paths lead to which outcomes.
Not everyone who needs this map can read a call graph. A project manager scoping a change, an auditor checking an access claim, a developer in their first week: all of them need the answer without first learning to navigate the picture.
Guided Mode is a plain-language panel on every view. Pick a question, pick a program, and the map drives itself: it pins the subject, highlights what the question is about, then explains in words what it just did and why. Terms that only a mainframe engineer would know are defined inline, so an answer mentioning a CICS XCTL also tells you that an XCTL hands control to another program and does not expect it back.
Every answer names the facts it came from, and this is the part that matters: when the tracked facts do not support an answer, it says so rather than producing a plausible one. The same rule that governs the written manuals governs the interactive view. Expert Mode stays live throughout, so the diagram remains fully explorable for anyone who prefers to drive it directly.
It runs entirely in your browser. There is no server call, no account and no telemetry, so the artifact behaves the same on an air-gapped workstation as it does here. The panel is keyboard navigable and screen-reader labelled throughout.
Hover any program box and a plain-English summary of what that program is for appears immediately, so someone new to the estate is not left decoding eight-character names. The detail that matters: each tooltip is labelled with its own provenance. Text taken from the source header comment is marked as such. Text drawn from the generated Program Logic Manual carries a ◇ and is noted as verified against source facts. Anything describing an external vendor routine carries a † and says whether it is vendor-documented or curated from call context.
Even the hover text refuses to blur the line between what the code proves and what a human wrote about it.
A Program Logic Manual earns trust by citing source lines you can go and read. A diagram is harder, because a picture cites nothing. You are asked to take it on faith that the boxes and arrows still match the code they came from.
Every view in this map ships with a recorded SHA-256 fingerprint, 83 of them, one per pane. The whole publication set carries the same treatment: the map, the CRUD matrix, the impact analysis, the static findings and every underlying data export are listed in a manifest with their sizes and hashes, all generated from a single parse of the source, and nothing is edited afterwards.
If you want to check that rather than believe it, download the publication package and hash its contents against the manifest inside it. Verify the package rather than the pages you are reading: this site is served through a CDN that rewrites links in HTML as it delivers it, which changes those files by a few bytes and would fail the check for reasons that have nothing to do with the documentation. The archive is delivered untouched, so the numbers hold exactly.
It is worth being precise about what this does. It does not prove a diagram is correct. It proves the diagram has not changed since it was generated and reviewed. If a view is edited, re-rendered or swapped afterwards, its fingerprint stops matching and the change becomes detectable instead of invisible.
That is the difference between a diagram you were handed and a diagram you can audit. For a maintenance team it means the map reviewed in March is provably the map on screen in November. For a compliance team it means a picture in an evidence pack has the same chain of custody as the text beside it.
System flow. The call and transfer graph, 51 nodes, with job & file flow and paragraph-level views for each of 40 programs.
CRUD matrix. 34 programs against 38 data stores. Every Create, Read, Update or Delete marker opens the paragraph and source-line cites that prove that access.
Batch dependency chain. Ordering for 15 jobs, derived from shared datasets, with the writer/reader pair, deck, step, DD and disposition behind each link. It states its own JCL coverage rather than implying completeness.
Static findings. 29 findings across 12 programs: uninvoked paragraphs, unreachable code after transfers, silent I/O failures, unrounded computes, accumulator double writes. Each expands to every recorded field and source cite.
Impact analysis. Select any program or data store and trace its cited upstream and downstream blast radius, 2,948 closure rows across 118 assets. Depth is user-adjustable and visible, the trace follows static call and data-access facts rather than runtime scheduling, and unresolved dynamic targets are excluded rather than guessed at. This is the report a change-advisory board asks for and almost never gets.
Each call, transfer and data access maps back to specific source lines. There is no interpretive layer between what the code says and what the picture shows.
Where a dynamic transfer target cannot be established from the source, it is displayed explicitly as unresolved rather than guessed at. An honest gap is more useful to an engineer than a confident invention.
The maps and the Program Logic Manuals are generated from one parsed baseline, so the diagram and the documentation cannot drift apart or contradict each other.
Views are bookmarkable and shareable as links, and the CRUD matrix exports to TSV for spreadsheet and audit workflows.
The full interactive map. One system-wide call and transfer graph plus job & file flow and paragraph-level views for 40 of the 42 programs in the roster, 83 linked views in total. Scroll to zoom, drag to pan, click to drill.
Open the flow map → DRILL-DOWN EXAMPLEWhat you see after clicking a program box: the job and file flow for the daily transaction posting program, its JCL steps, the datasets and tables it touches, and its neighbours. Click the program again for the paragraph-level view.
Open the drill-down → BLAST RADIUSPick a program or data store and see everything it reaches, upstream and downstream, with a citation on every hop. 1,490 depth-bounded closure rows across 118 assets. Unresolved dynamic targets are excluded rather than guessed.
Open impact analysis →34 programs against 38 data stores. Every Create, Read, Update and Delete marker opens the paragraph and source-line citations that prove that access.
Open the matrix → MAINTENANCE VIEW29 findings across 12 programs: uninvoked paragraphs, unreachable code after transfers, silent I/O failures, unrounded computes. Pivot by program or detector family, expand any row for the source cites.
Open static findings → RUN ORDERWhich job must run before which, derived from shared datasets, with deck, step, DD and disposition behind every link. A data-dependency skeleton, not a scheduler calendar, and it says so.
Open the chain →Every report also exports to TSV for spreadsheet and audit workflows: CRUD · impact closure · static findings · batch dependencies