equivalence: model the oracle's MOVE of a non-digit zoned item to a binary item (#4652)

[squid-protocol]

Fixes #4652. Part of #4270.

Stacked on #4653. Merge that first. This branch is cut from equiv/4270-genapp-front-ends, so until #4653 lands the diff against main includes its commits. Only the top commit is this PR's.

Decision

The det port follows the oracle. IBM documents no result for non-digit data in a numeric DISPLAY item. On z/OS, EBCDIC spaces would most likely give 0. Here, though, the data is the program's own: LGTESTP4 leaves CA-BROKERID / CA-PAYMENT as the spaces INITIALIZE puts there. A case can't leave that data out the way C11's #4049 inputs were left out. So the det runtime now reproduces GnuCOBOL 3.1.2's cob_move_display_to_binary:

• each byte counts as its character minus '0' (a space is -16);
• the total is kept in an unsigned 64-bit integer that wraps;
• digits are aligned on the receiver's scale;
• under TRUNC(STD) the result is taken mod 10^digits (not for COMP-5);
• the sign is applied last.

PIC 9(10) of spaces into S9(9) COMP gives 931773840; PIC 9(6) gives 707773840. Register C11 records this: the proof says the port matches GnuCOBOL, not z/OS.

Changes

• det/cobolrt/Cobol.java: move() sends a zoned sender to a binary receiver through the new nonDigitToBinary, but only when a digit position holds a non-digit. Digit-only data takes the old path unchanged.
  • A space in a signed sender's sign position counts -16 and positive. The oracle then rewrites that sign byte as an overpunch (space becomes {, a separate sign becomes +), and the runtime does the same.
  • Any other byte in the sign position (!, X'FF') is refused by name.
  • This is localized to the MOVE path. It does not touch the arithmetic / Cobol.align functions that det runtime: truncate arithmetic intermediates as cobc's ARITHMETIC-OSVS does (#4287) #4654 changes, though both PRs edit Cobol.java (in different hunks).
• tests/cobol_mainframe/test_det_nondigit_binary.py (new) covers TRUNC(STD) and TRUNC(BIN): unsigned, signed, separate sign, scaled, COMP-5, a 2-byte and an 8-byte receiver, and letters. Expected values were measured on GnuCOBOL and an E2E test re-measures them. The test fails before the fix (A10>B9 0 vs 931773840) and passes after.
• genapp-lgtestp4/case.json: the successful add scenario is back in, and the notes are updated.
• det_sweep_coverage.json: genapp-lgtestp4 is refreshed (23 to 25 scenarios, 17 to 18 branches).
• oracle_assumptions.md: the C11 row and section are updated, the cases this does not model are listed (equivalence: the rest of C11 -- non-digit zoned data in arithmetic, comparisons, edited and zoned MOVEs differs from the oracle #4662), and the Q10 row now says it is reached (the add's fault task add--sql-lgapdb01-316).

Other receivers (checked against the oracle)

Spaces moved to COMP-3 or zoned receivers already agree with the oracle (both give 0). Several cases still differ: letters moved zoned to zoned, spaces to a numeric-edited item, COMPUTE/ADD on such items, and comparisons. These are filed as #4662.

Evidence

• genapp-lgtestp4 is PROVED on 25 scenarios, including add. The COBOL side INSERTs 931773840 / 707773840 and the port matches.
• det_port.py check lists all 79 ports as changed, because every port carries a copy of Cobol.java. No generated service changed. A static scan found 27 ports with a MOVE from a zoned item to a binary one, and all 27 re-proved PROVED: every GenApp DB2/front-end case including lgtestp1-4, cbsa-inqacc, cbsa-updacc(-generated), carddemo-dateutil, and the mortgage cases cmort, mlist(-generated) and nbrvl.
• pr_gates.py --fast: 5/5 pass. pr_gates.py --ratchets: 7/7 pass, 0 skipped. The full suite was not run locally; CI runs it.

🤖 Generated with Claude Code

[github-actions]

🐦‍⬛ Muninn Security Scan

✅ No security issues found.

🐦‍⬛ Powered by Muninn · Skald Lab