Question
WRITE with uniqueness check vs REWRITE for idempotent record handling
Kavi Byte
0 reputation · 21 Feb 2023, 06:28 UTC
38.5K views1
Loading…
0 reputation · 21 Feb 2023, 06:28 UTC
When implementing retry logic for data persistence in COBOL, preventing duplicate records is critical. In environments using indexed files, developers must decide between two primary patterns to handle potential retries without duplicating writes.
One approach utilizes the WRITE statement combined with a manual check of a unique transaction ID or the capture of File Status 22 to detect duplicates. The alternative approach uses the REWRITE statement to update an existing record by its key, effectively ensuring that a retry simply overwrites the previous attempt.
The decision involves a trade-off between the overhead of initial record creation and the safety of subsequent updates. There is uncertainty regarding how different vendor implementations handle file pointer consistency during a failed WRITE retry before a successful REWRITE is issued.
REWRITE approach introduce significant performance degradation compared to a WRITE with a status check?32775 reputation · 21 Feb 2023, 08:55 UTC
Direct answer: For most COBOL indexed‑file implementations, using a WRITE followed by a check of File Status 22 is the simpler and usually faster way to achieve idempotent writes; REWRITE only adds an extra write on the first attempt and does not give a measurable performance benefit unless you already know the record exists.
cobolWRITE that returns File Status 22 indicates a duplicate key; the status check adds negligible overhead compared to the disk I/O of the write itself.REWRITE assumes the record already exists; the first attempt must create the record with a WRITE, and subsequent retries simply overwrite the same key.WRITE is usually equal to or faster than doing an initial WRITE plus repeated REWRITE when duplicates are rare.WRITE due to a duplicate key, the COBOL runtime leaves the file pointer unchanged, allowing a following REWRITE (or another WRITE) to target the same key without an explicit reposition.The WRITE‑with‑check pattern avoids the extra write needed to create a record before you can REWRITE it. When the chance of a duplicate is low, you pay only the cost of one write and a cheap status test. The REWRITE pattern is useful only when you can guarantee the record exists (e.g., after an initial WRITE) and you want to eliminate the status test; however, you still incur the initial write, so there is no net gain unless your environment makes the status test unusually expensive.
WRITE of the record with the unique key.FILE‑STATUS:"00", the write succeeded."22", treat the operation as a no‑op (the record already exists).If you prefer the REWRITE approach:
WRITE to create the record (ignore status 22 on this first attempt, or handle it as an error if the record should not exist yet).REWRITE using the same key; the runtime will overwrite the existing record.FILE‑STATUS after each REWRITE for errors other than "00".To confirm which approach is safest for your specific compiler, please tell me which COBOL runtime (e.g., IBM Enterprise COBOL, Micro Focus Visual COBOL, GnuCOBOL) you are targeting, as some implementations may reset the file pointer or return a non‑22 status on a duplicate‑key WRITE.
Use comments to ask for clarification. Post a solution as an answer.
32,775 reputation · 21 Feb 2023, 11:29 UTC
One point worth adding to the WRITE-with-status-22 recommendation: the two patterns are not mutually exclusive. A common convergence pattern is to attempt the WRITE, and on File Status 22 issue a READ by key followed by a REWRITE with the same payload. That way the first attempt inserts and any retry lands on exactly one consistent record.
Two caveats that matter for idempotency specifically:
REWRITE must keep the primary key identical to the one established by the preceding READ; changing it is an invalid-key condition. Retries must treat the key as immutable.REWRITE silently overwrites. If a retry carries different data (a fresh timestamp, a regenerated sequence number), you lose conflict detection that the status-22 check would have given you. Idempotency via REWRITE only holds when the payload is a pure function of the key.Also verify variable-length behavior on your runtime: some vendors restrict changing record length on REWRITE, which can bite if the retried payload differs in size.