Question
Fixed-length record constraints during DATA DIVISION layout updates
Rey Nova
0 reputation · 20 Apr 2021, 08:21 UTC
144.9K views1
Loading…
0 reputation · 20 Apr 2021, 08:21 UTC
COBOL relies on a strict mapping between the FILE SECTION and the physical storage of a dataset. Because the record layout is defined by fixed-length PICTURE clauses, any modification to the data structure—such as inserting a new field or expanding an existing one—shifts the byte offsets for all subsequent fields in the record.
When updating a schema to accommodate new data requirements, the lack of dynamic schema evolution means that existing physical files become incompatible with the updated program logic. While the REDEFINES clause allows for multiple interpretations of the same memory area, it does not provide a mechanism to handle variable-length extensions without altering the total record size.
DATA DIVISION is expanded?REDEFINES to simulate optional fields in a fixed-length file structure?33775 reputation · 20 Apr 2021, 09:53 UTC
When you enlarge a FILE SECTION record, every field that comes after the change shifts its byte offset. That means the program’s layout no longer matches the physical layout of existing files, and the old records become unreadable unless you take one of the following actions:
cobolRECORD group that contains the new fields. Use a REDEFINES on the new group only if the total size stays the same.VERSION indicator at the start of the record and write separate RECORD groups for each version. The program selects the correct group based on the indicator.Although REDEFINES lets you interpret the same memory area in different ways, it has several constraints in the context of fixed‑length files:
RECORD group.REDEFINES clause that overlays the original but includes the optional fields only when a flag is set.If you are unsure whether the new fields will ever appear in existing files, let me know. That will determine whether a simple REDEFINES with padding is sufficient or if a full migration is required.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 20 Apr 2021, 18:14 UTC
A useful check when you keep the record size constant is the RECORD CONTAINS clause in the FD. It locks the physical record length that the runtime expects, so even if the PICTURE clauses sum to the same byte count, a change in usage — e.g., moving from DISPLAY to COMP-3 — can alter storage and alignment without changing the logical size.
For backward compatibility, new optional data is usually appended as FILLER at the end of the existing layout and a version/indicator in the first bytes selects the interpretation. Both the old and new FDs must agree on the total size, otherwise the file is unreadable by the other program. Verifying the implied size in the compiler listing before and after the change avoids silent offset shifts.