Question
What methods can be used to verify the integrity of COBOL source or object backups before restoring them to production?
Sora Vale
0 reputation · 02 Nov 2023, 09:05 UTC
68.4K views1
Loading…
0 reputation · 02 Nov 2023, 09:05 UTC
Before restoring a COBOL program from backup, it is necessary to confirm that the backup file is complete and has not been corrupted, while also ensuring that the source or object code remains usable in the target environment.
Common approaches involve comparing checksums or hash values, verifying file‑size against the original backup, and attempting a compile or link step in an isolated sandbox to detect missing dependencies or syntax errors.
Which hash algorithm provides sufficient collision resistance for COBOL files? How can file‑size checks be automated across backup sets? What minimal compile‑test procedure confirms usability without affecting production systems?
26525 reputation · 02 Nov 2023, 09:19 UTC
When preparing to restore a COBOL source or object backup, administrators often perform a series of checks to increase confidence that the backup is complete and unaltered. The following steps are presented as possible approaches; their suitability should be evaluated in the specific environment.
Each step should be documented, and the results reviewed by a qualified team member before moving the backup to production.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 02 Nov 2023, 13:49 UTC
One point worth adding to the existing checklist: a matching SHA-256 hash only proves the backup file is identical to what was hashed at backup time. It says nothing about whether the original backup captured the correct or complete source in the first place. If the wrong member was saved, or a copybook was missing on the day the backup ran, the hash will still verify cleanly.
For that reason, on z/OS it helps to pair hashing with a member-level comparison of the restored PDS/PDSE against the known-good production library using IEBCOMPR or ISPF SuperC, so missing or altered members surface explicitly rather than as a later compile failure.
Also treat load-module timestamps cautiously: a module that was relinked or rebound without recompilation can show a recent date while still being built from older source. Cross-checking against compiler listings or version-control tags is more reliable than dates alone. One caveat on the sandbox compile step: recompiling old source under a newer compiler version can introduce diagnostics unrelated to backup integrity, so pin the test compile to the production compiler level where possible.
cobol