COBOL translator: SORT/MERGE (RELEASE/RETURN) have no statement parser; JCL utility steps are not run #4268

Problem

The det port has no parser for the SORT, MERGE, RELEASE and RETURN verbs, so each becomes a hole. Separately, JCL utility steps (SORT/DFSORT, IDCAMS, IEBGENER) are not executed by the oracle, and a batch case runs one program step.

Evidence (file:line, origin/main)

• gitgalaxy/tools/cobol_to_java/det/stmt.py:768-775 (_PARSERS): no SORT, MERGE, RELEASE or RETURN key.
• docs/language_status/oracle_assumptions.md F4 (~222-225): "SORT, IDCAMS, IEBGENER and DFSORT steps are not run. The COBOL SORT verb is not translated by the det port (a hole)." "A batch case runs one program step."
• Note: the Java batch forge does model IEBGENER/ICEGENER copy and GDG generations (cobol_to_java_batch_forge.py:~61, ~744); the gap is the det/equivalence path, so GDG is not claimed missing here.

Impact on a real estate

SORT/MERGE with INPUT/OUTPUT PROCEDURE is ubiquitous in batch estates; programs using it cannot be proven, and multi-step jobs (SORT then program then IDCAMS) cannot be run end to end.

Acceptance criteria

• SORT (USING/GIVING and INPUT/OUTPUT PROCEDURE), MERGE, RELEASE, RETURN parsed and translated
• Equivalence case with a SORT program proven against the oracle (collation per Collation hazards: extract alphanumeric relation conditions, guard the port, and prove it with boundary inputs #4035)
• Utility steps SORT and IEBGENER executed in the oracle, IDCAMS REPRO/DEFINE minimal subset, or each explicitly refused with a register entry
• Multi-step job case (more than one EXEC PGM) runnable in the harness
• Register F4 updated

Out of scope

Full DFSORT control-statement language; spanned-record (RECFM VS) support beyond a documented refusal.

Found during: 2026-10-03 COBOL engine/translator audit

🤖 Generated with Claude Code