Question
COBOL REWRITE on indexed files: required lock state before execution
Rin Finch
0 reputation · 17 Mar 2021, 16:22 UTC
41K views1
Loading…
0 reputation · 17 Mar 2021, 16:22 UTC
Goal: Clarify whether a record must be locked for update before executing REWRITE on an indexed file opened in I-O mode, and how this requirement varies between IBM Enterprise COBOL and GnuCOBOL.
Constraints: The ANSI COBOL 85 standard states that REWRITE updates the current record and requires the record to be locked for update, but it does not mandate explicit locking, leaving the detail to the compiler. IBM Enterprise COBOL documentation specifies that the file must be opened in I-O mode and the last I/O operation must be a successful READ (or START) that positioned the record; otherwise REWRITE fails with file status 90. GnuCOBOL treats REWRITE as permissible after any successful READ that positioned the record, returning file status 92 if the record is not locked for update. The behavior when another process holds a shared lock differs: IBM COBOL rejects REWRITE with file status 92, while GnuCOBOL may allow the rewrite if the underlying OS permits it, risking data corruption.
Uncertainty: It remains unclear which lock state (exclusive, shared, or none) is sufficient to guarantee a successful REWRITE across both compilers without invoking undefined behavior or file corruption.
Does REWRITE require the record to be locked for update prior to execution?
Does the required lock differ between IBM Enterprise COBOL and GnuCOBOL?
Is a successful READ alone sufficient to satisfy the lock prerequisite, or must an explicit lock be obtained?
35275 reputation · 17 Mar 2021, 22:32 UTC
Yes. REWRITE requires the target record to be positioned by a prior successful READ or START and to be in an update-locked state. A successful READ alone is sufficient only in restricted single-process scenarios; it does not guarantee safety when other processes can access the same indexed file.
IBM Enterprise COBOL and GnuCOBOL both mandate I-O mode and record positioning, but they differ in how the lock is acquired and enforced.
A successful READ in I-O mode implicitly locks the record for update. In a single-process program, no explicit lock statement is needed before REWRITE. If positioning is missing, the runtime typically returns file status 90 rather than a lock code.
GnuCOBOL delegates much of the locking behavior to the underlying operating system and runtime library. It generally allows REWRITE after a successful READ, but if another process holds a conflicting lock, the runtime returns file status 92. Because the OS may permit overlapping writes when no explicit lock is enforced, relying on the implicit behavior can lead to data corruption.
An exclusive record lock is the only state that reliably guarantees a successful REWRITE across both compilers without undefined behavior. If your application may run under GnuCOBOL or in a multi-process environment, obtain an exclusive lock before rewriting.
cobolI-O, not INPUT or EXTEND.READ; a non-zero status means positioning failed.REWRITE rather than relying on implicit locking.Does more than one process open the same indexed file for update? If the answer is no, the implicit IBM behavior is sufficient for a single-process test. If yes, the recommendation changes to an explicit exclusive lock regardless of compiler.
Note: Exact lock semantics vary by compiler version and platform. Verify against the current IBM Enterprise COBOL and GnuCOBOL file-status references before relying on these codes in production.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.