Question
Can COBOL Programs Guarantee Rollback Safety After a Schema Change Without Recompilation?
Dev Indigo
0 reputation · 20 Jun 2020, 18:49 UTC
75.7K views1
Loading…
0 reputation · 20 Jun 2020, 18:49 UTC
Goal: ensure that a COBOL program can safely roll back transactions after a database schema change without introducing data corruption or semantic drift.
Constraints: COBOL’s static data division fixes record layouts at compile time, so an ALTER TABLE typically causes a mismatch unless the program is recompiled or uses dynamic SQL descriptors; however, descriptor support is implementation‑dependent and the ANSI/ISO COBOL standard does not define a rollback‑safe migration pattern.
Uncertainty: it is unclear whether recompilation alone guarantees that subsequent EXEC SQL ROLLBACK restores the pre‑change row image, or whether runtime descriptor checks can replace recompilation across heterogeneous DBMS.
Does recompiling the COBOL program after an ALTER TABLE guarantee that a later ROLLBACK restores the original row image? Can dynamic SQL descriptors be used at runtime to detect schema changes and avoid abends without recompilation? Is there a portable COBOL feature that ensures transaction rollback safety across different DBMS platforms?
Recompiling a COBOL program after an ALTER TABLE updates the host-variable record layout in the DATA DIVISION so subsequent SQL statements bind to the new column definitions. However, EXEC SQL ROLLBACK is handled entirely by the database transaction manager. It restores rows to the last commit point as recorded in the database log, independent of the program's compiled copybook. So recompilation alone does not guarantee that a rollback returns the "original row image" as the program sees it; it removes layout-mismatch abends that could otherwise corrupt data before a rollback is attempted. The mismatch, not the rollback, is the real failure point.
Some vendors expose SQLDA-style descriptors (for example, Db2 for z/OS and Oracle Pro*COBOL) that let a program fetch column counts, types, and offsets at runtime. If the program builds its host-variable bindings from a descriptor refreshed after each EXEC SQL PREPARE, an additive change such as a new nullable column at the end of the table can be absorbed without recompilation. The trade-offs: descriptor support, population rules, and type codes are vendor-specific, and errors shift from compile time to runtime. Without explicit descriptor validation code, a mismatch surfaces as a runtime abend instead of a build failure. Column drops or type narrowing invalidate old programs regardless of rollback logic.
The ANSI/ISO COBOL standard does not define embedded SQL behavior for schema migration or rollback safety; EXEC SQL is implemented through vendor precompilers. Consequently, there is no portable COBOL feature that guarantees rollback safety across heterogeneous DBMS platforms after a schema change.
cobolALTER TABLE.Which DBMS are you using, and is your specific ALTER TABLE statement transactional there (PostgreSQL generally yes; some Db2 and Oracle DDL cases no)? If the DDL itself is non-transactional, you cannot rely on ROLLBACK to undo a failed migration, and the recovery plan changes accordingly.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.