COBOL translator: national/DBCS data (USAGE NATIONAL, PIC N, DBCS literals) not modelled by the det port or the oracle register #4272

Problem

The det port's layout and statement code have no handling of USAGE NATIONAL / PIC N / DISPLAY-1 items or N"..." / G"..." literals, and the oracle assumptions register has no entry for them (what GnuCOBOL does with UTF-16 national data vs z/OS DBCS/SO-SI).

Evidence (file:line, origin/main)

• git grep -i 'national|PIC N|DBCS' gitgalaxy/tools/cobol_to_java/det finds nothing; det/layout.py:58-60,105 enumerate only COMP-1/2, POINTER, INDEX, BINARY/COMP-5.
• docs/language_status/oracle_assumptions.md: no NATIONAL/DBCS entry (registers C, F, Q sections checked).
• What does exist: the engine records and sizes PIC N / NATIONAL (#3816 (part 3): PIC N / G, USAGE NATIONAL / DISPLAY-1 recorded and sized #3926, Mainframe byte level: raw EBCDIC code pages (037/1047/277/278/930/939, FB80 splitting) and DBCS COBOL (PIC N/G, SO/SI) #3816) and the Java forge has national codecs (cobol_to_java_repository_forge.py:85-104, cobol_to_java_compare_forge.py:23), so the gap is the det/proof path.

Impact on a real estate

Japanese, Chinese, Korean and Nordic mainframe estates carry DBCS/national fields; a program with one can be mistranslated or refused with no register entry saying why, and the proof makes no claim about it.

Acceptance criteria

• Determine the current det behaviour on a PIC N program (translated wrongly, hole or refused) and record it
• Either model NATIONAL/PIC N (length, MOVE, compare, INSPECT) with an equivalence case, or refuse with a clear error
• Oracle register entry for national/DBCS (what differs, whether reached)

Out of scope

Engine-side sizing (done in #3926); EBCDIC code-page decoding.

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

🤖 Generated with Claude Code