Mainframe fact channel: online→batch bridge: a CICS transaction submitting a job via the internal reader #3448

Problem

A CICS program can submit a batch job by writing JCL to an extrapartition TD queue routed to the internal reader. The engine records both halves (the WRITEQ TD in cics_resource_data and the TDQUEUE definition in csd_resource_data) but not the edge "transaction X submits job Y". An online→batch dependency is exactly what breaks in a migration.

Evidence

CardDemo app/cbl/CORPT00C.cbl performs SUBMIT-JOB-TO-INTRDR (lines 238, 255, 435) and writes to TD queue JOBS. CARDDEMO.CSD defines JOBS as an extrapartition TDQUEUE feeding the internal reader.

Proposal

A resolved edge: WRITEQ TD QUEUE(q) → CSD extrapartition TDQUEUE q whose DD/DSN is the internal reader → the submitted job. Where the JCL is built inline in the program (as in CORPT00C), record at least "submits a job", plus the job name if a literal //name JOB card is written.

Acceptance (ground truth, as for every channel since #3210)

• An independent draft reader in tests/tools/cobol_answer_key.py. It must not import the engine; test_draft_readers_never_import_the_parsers_they_grade enforces this.
• A new answer-key section, drafted for all three pinned corpora (zopeneditor, CBSA, CardDemo).
• A blind census of that section with tests/tools/cross_verify.py census, with every disagreement ruled against the source.
• A new scored field in tests/tools/ground_truth_ledger.py, so mainframe-ground-truth.yml fails CI on any regression.
• The channel follows gitgalaxy/core/how_to_add_a_fact_channel.md: extractor, *_data table, delta restore, galaxy_ir.EngineFile reader and SCOPE update.

Part of #3445.

🤖 Generated with Claude Code