Repository navigation
Answer key: copybook record layouts + CICS RIDFLD, two new ledger fields (#3602, #3649 part 1) - #3672
Merged
Merged
Conversation
The layouts the Java generators depend on mostly live in copybooks, which no key checked. New field `copybook layouts`: - Key: draft_copybook_layouts lays out every COBOL copybook with this tool's own reader and storage arithmetic, as `ROOT/NAME @offset+bytes` per elementary PIC item. - Engine: GalaxyIR.record_layout per root. - The contract is the engine's: a REDEFINES overlay is skipped; items without a PIC take their storage but are not units; an OCCURS item is listed once; an item under a PIC item is not storage. - A copybook that COPYs another member is not keyed (this reader does not expand COPY). Three key-reader errors, found against the corpora and fixed to COBOL's rules: - `1 THROUGH 12.` continuing an 88's VALUES was read as a level-1 item named THROUGH (CardDemo CSUTLDWY); - a POINTER took 0 bytes and shifted every later field (CBSA PROCISRT); POINTER / INDEX / COMP-1 are 4, COMP-2 8; - an item under an elementary PIC item was laid out (GENAPP soaipm1). _pic_bytes also counts CR / DB (2), E, and national N / G (2 each). Result: key and engine agree on all 2,759 units in 113 copybooks (CardDemo 2,131, CBSA 389, GENAPP 188, zOE 34, zECS 17; DSF has no COBOL copybooks). The ledger adds the field at tier draft (update: +0 -0, 0 untriaged; check clean). The field-testing registry marks it development_rounds 6: it was built against every keyed estate, so it stays `untested` until fresh estates or a census. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017ZsVaAkb86P5r5JXDC2Y9g
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017ZsVaAkb86P5r5JXDC2Y9g
The Java repository forge (#3617) maps each CICS FILE command's RIDFLD onto an entity key, and no key compared it. New field `CICS RIDFLD`: `L<line> VERB FILE NAME RIDFLD=OPERAND` per FILE command with a RIDFLD, spacing normalized. - Key: this tool's own EXEC CICS reader (cics_resource_ops now keeps the option), over COBOL, PL/I and assembler sources. - Engine: cics_resource_data.attributes, nested parentheses included. It is a section of its own, so the reviewed `CICS resources` units are untouched. Key and engine agree on all 781 units: CardDemo 46, CBSA 17, GENAPP 7, zECS 22, DSF 689 (PL/I). The field enters at tier draft, with development_rounds 6. Ledger update: +0 -0, 0 untriaged; check clean. Part 2 (the reference-modification texts) needs #3670's engine columns. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017ZsVaAkb86P5r5JXDC2Y9g
squid-protocol
changed the title
Contributor
squid-protocol
added a commit
that referenced
this pull request
Sep 25, 2026
…part 2) (#3676) * Answer key: reference-modification spans, a new ledger field (#3649, part 2) #3655 made the engine keep each reference modification as written, and the IR reads a CICS program's COMMAREA from those texts. No key checked them. New field `refmod spans`: `L<line> VERB SOURCE(start:length) -> TARGET(start:length)` per reference-modified move, with one spelling on both sides (_norm_refmod: whitespace collapsed, no space around + - * / : ( )). - Key: this tool's own data-move reader. _mv_operands now keeps the refmod text, the top-level parenthesis group with a colon, so a subscript is not a refmod. Its srm / trm flags are unchanged. - Engine: data_move_data.source_refmod_text / target_refmod_text. It is a section of its own, so the reviewed `data moves` units are untouched. Key and engine agree on all 373 units: CardDemo 174, CBSA 95, GENAPP 61, zECS 42, zOE 1. DSF's PL/I uses SUBSTR, not refmods. Tier draft, development_rounds 6. Ledger update: +0 -0, 0 untriaged; check clean. Closes #3649 with part 1 (#3672, RIDFLD). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017ZsVaAkb86P5r5JXDC2Y9g * Field testing: refmod spans introduced by #3676 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017ZsVaAkb86P5r5JXDC2Y9g --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #3602; part 1 of #3649 (RIDFLD). The refmod-text half of #3649 follows once #3670's engine columns merge.
Why
The Java generators rest on byte layouts: COMMAREA DTOs (#3615 / #3655), VSAM entity keys (#3617). Those layouts mostly live in copybooks, and the answer key only keyed each program's own DATA DIVISION, and only by field name. Nothing independently checked offsets or widths.
New ledger field:
copybook layoutsdraft_copybook_layouts: this tool's own_data_itemsreader + plain storage arithmetic (the same arithmetic that signs symbolic maps against IBM's DFHMAPS output, #3575)GalaxyIR.record_layoutper record rootThe unit is
ROOT/NAME @offset+bytesper elementary PIC item. The contract is the engine's:A copybook that COPYs another member is not keyed, since this reader doesn't expand COPY.
Key-reader errors found and fixed (each to a COBOL rule, not to "whatever the engine says")
CSUTLDWY.cpy1 THROUGH 12.(continuing an88 … VALUES) read as a level-1 itemTHROUGHPROCISRT.cpyPOINTERtook 0 bytes and shifted every later field by 4soaipm1.cpy05laid out under an elementary03 … PIC 9(10)_pic_bytesalso countsCR/DB(2),E, and nationalN/G(2 each).Result
Key and engine agree on all 2,759 units in 113 copybooks: CardDemo 2,131, CBSA 389, GENAPP 188, zOE 34, zECS 17; DSF has no COBOL copybooks.
ground_truth_ledger.py update: +0 −0, 0 untriaged;check: clean.development_rounds: 6, because it was built against every keyed estate. It staysuntesteduntil a fresh estate or a census; census suite to follow.Also:
CICS RIDFLD(#3649, part 1)L<line> VERB FILE NAME RIDFLD=OPERANDper CICS FILE command, spacing normalized.cics_resource_data.attributes.CICS resourcesunits stay untouched.Verified
🤖 Generated with Claude Code
https://claude.ai/code/session_017ZsVaAkb86P5r5JXDC2Y9g