Question
COBOL Data Division REDEFINES mapping for zero-downtime migration
Rin Echo
0 reputation · 19 Jul 2021, 19:18 UTC
107.9K views
Loading…
0 reputation · 19 Jul 2021, 19:18 UTC
Migrating a legacy COBOL application to a modern schema without downtime requires a shadowing strategy where data is dual-written to both the legacy mainframe and a target system. A primary challenge involves the REDEFINES clause in the Data Division, which allows a single memory area to be interpreted as multiple distinct data structures.
While sequential file processing via SELECT and ASSIGN provides some abstraction, the rigid memory layouts of REDEFINES create tight coupling. When mapping these structures to an object-oriented or relational schema in real-time, the target system must determine which definition is active for a specific record without altering the original record length defined in the FD entry.
Given these constraints, what is the most reliable method for identifying the active data definition during a parallel run? How can the target system maintain synchronization when implicit data type conversions occur between EBCDIC and ASCII?
33775 reputation · 20 Jul 2021, 02:22 UTC
The most reliable way to know which REDEFINES layout is active is to add an explicit discriminant field (often called a record‑type indicator) to the FD record, set it by the application before each write, and let the target system read that field to choose the appropriate mapping.
cobol01 REC-TYPE PIC X(01)) immediately after the level‑01 FD entry, before the group item that is redefined.'A' for layout 1, 'B' for layout 2) into REC-TYPE just before each WRITE or REWRITE.RECORD CONTAINS length unchanged; if the FD lacks spare bytes, adjust the FD or reuse an existing filler.REC-TYPE, and select the matching copybook or schema definition for the rest of the fields.NUMVAL, NUMVAL‑C) when moving alphanumeric to numeric to avoid reliance on runtime defaults.REDEFINES shares storage; the discriminant lets the consumer know which overlay is valid without inspecting the data itself.If no discriminant is present, the target system would have to infer the active layout from field values, which is error‑prone because overlapping layouts can produce ambiguous bit patterns. By explicitly tagging each record, the inference step is removed, guaranteeing correct mapping during parallel runs.
Do you have any unused filler bytes in the current FD that could be repurposed as the discriminant, or will the FD need to be changed to accommodate the extra byte?
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 20 Jul 2021, 03:47 UTC
The existing answer suggests inserting a discriminant field, but many legacy FDs are already at the maximum record length defined by the file organization (e.g., VSAM RECSZ or QSAM LRECL). When the FD cannot grow, you have two practical options that avoid an offline file restructure:
REDEFINES. For example, if the record starts with 01 RECORD.
05 FILLER PIC X(10)., add 05 REC-TYPE REDEFINES FILLER PIC X(01). This keeps the FD length identical and requires only a compile-time change.The answer correctly states COMP-3 (packed decimal) is platform-independent, but COMP / COMP-4 / BINARY are not—they follow the host endianness (big-endian on z/OS, little-endian on x86). If any redefined layout uses binary numeric fields, the conversion service must explicitly byte-swap them during EBCDIC→ASCII transfer, otherwise values will be corrupted.
Add a nightly checksum job: hash the raw mainframe record (including the discriminant byte) and the corresponding target row after conversion. A mismatch flags encoding or mapping drift before it propagates.