det translator: IDMS (IDMS-DC / DMLC) programs are refused by name; model IDMS DML and subschema records #4532

Problem

The det COBOL-to-Java translator refuses IDMS programs by name ("IDMS DML not supported", det/source.unmodelled, since #4462 slice 2). An IDMS-DC program (CA IDMS, the DMLC precompiler's input) declares an IDMS-CONTROL SECTION (PROTOCOL. MODE IS IDMS-DC) and a SCHEMA SECTION (DB <subschema> WITHIN <schema>), and its PROCEDURE DIVISION uses IDMS DML: BIND RUN-UNIT, READY USAGE-MODE IS RETRIEVAL, OBTAIN CALC <record>, FINISH, DC RETURN, and the DB-REC-NOT-FOUND condition. None of this is modelled: the subschema's records (LOAN-ID in the example) come from the dictionary, not a copybook, and the DML statements have no Java runtime.

Evidence

estate-crucible (pin v0.4.0) estate/apps/LOAN/cobol/LNIDMS01.cbl: before slice 2 it failed the tree-sitter grammar unnamed (DATA DIVISION does not parse near expanded line(s) [5, 9], PROCEDURE DIVISION does not parse at line 18); now it is refused by name at line 8 (IDMS-CONTROL SECTION.). Ledger: tests/cobol_mainframe/fact_crosscheck_ledger.json, cause translator-refuses-estate-shape.

Impact on a real estate

An IDMS shop's programs get no translator facts and no translation. Refusal is safe (never silent), but it is a coverage gap for every IDMS-DC / IDMS-CICS estate.

Acceptance criteria

• The subschema's records are laid out (from a dictionary export / punched subschema copybooks the estate supplies), or the program stays refused when they are absent.
• IDMS DML (BIND / READY / OBTAIN CALC / FIND / GET / STORE / MODIFY / ERASE / FINISH / COMMIT, DC RETURN) parses as statements and translates against a runtime interface (a repository per record type), with ERROR-STATUS and the DB-* conditions modelled.
• LNIDMS01 translates; its translator-refuses-estate-shape ledger entry drops.

Found during: #4462 slice 2 (det translator refusals)

🤖 Generated with Claude Code