COBOL DELETE for VSAM records

This page is about the COBOL DELETE verb that removes a logical record from an already opened VSAM dataset—not about IDCAMS DELETE CLUSTER, not about DISP=(,,DELETE) on JCL, and not about RACF profile removal. Beginners collide those ideas because the English word delete appears everywhere on the mainframe. For a KSDS, DELETE removes the keyed row and adjusts index structures so later random reads report not found. For an RRDS, DELETE frees or marks a slot according to relative file semantics. For an ESDS, you should not expect classic physical deletion of an arbitrary middle record; applications simulate removal with flags or copy-forward reorganization jobs. This page explains prerequisites—OPEN I-O, prior READ positioning, FILE STATUS handling—and contrasts dataset-level deletion with record-level deletion so your incident write-ups use precise vocabulary operations staff can act on.

Support matrix by VSAM type

Typical KSDS delete flow

1
2
3
4
5
6
7
8
9
10
       MOVE TARGET-CUST-ID TO CUST-KEY
           READ CUSTFILE
           END-READ
           IF WS-FS NOT = '00'
               GO TO NOT-FOUND-EXIT
           END-IF
           DELETE CUSTFILE
           IF WS-FS NOT = '00'
               PERFORM DELETE-FAILED
           END-IF

Some programs use INVALID KEY on READ rather than FILE STATUS; harmonize styles. After DELETE, inspect FILE STATUS or INVALID KEY phrases per your compiler manual. DELETE-FAILED should escalate when the record disappeared between READ and DELETE because another task removed it—classic concurrency symptom in hot files.

Concurrency and audit

• Log who deleted which business key with timestamp if regulations require retention of evidence.
• Consider soft delete columns if undo windows are business-required; physical delete is immediate.
• Pair DELETE with downstream cache invalidation in hybrid architectures so online regions do not serve stale copies.

Operational mistakes

1. Deleting the wrong record because the key buffer was reused without refresh.
2. Skipping READ and calling DELETE blindly.
3. Pointing DELETE logic at production while testing with production DSN copies—naming discipline matters.

When not to use DELETE

Regulatory retention sometimes forbids physical removal; use REWRITE to mark status inactive instead. Archival systems may export rows before DELETE. Batch programs that physically delete millions of rows may cause CI pressure and long runtimes; storage may prefer IDCAMS REPRO to a filtered cluster or partition strategy. These are design conversations, not single-line syntax fixes.

Decision tree: physical DELETE versus logical delete

Ask whether downstream systems still need the row for historical joins. If yes, prefer logical delete flags. Ask whether storage reclamation is urgent. If yes, physical DELETE or unload-and-redefine strategies enter the conversation. Ask whether undo is required within business hours. If yes, soft delete with timestamps beats immediate physical removal. Ask whether referential integrity spans multiple VSAM files; if yes, delete ordering across files must be scripted and tested like mini-transactions even though VSAM is not a relational engine.

CICS and batch interaction

When online regions hold locks or strings open on the same cluster batch DELETE attempts, you may see contention or status codes indicating the record changed between READ and DELETE. Document handoff windows or enqueue names if your installation mixes CICS file control with batch maintenance on the same DSN. This page stays batch-focused, but operators will mention CICS within five minutes of any hot file incident.

RRDS delete semantics in brief

After DELETE on an RRDS slot, a subsequent random READ may return an empty-slot style status rather than data. Programs that reuse slot numbers for new inserts must coordinate with DEFINE options and business rules about whether deleted slots are immediately eligible for WRITE again. Because RRDS is less common than KSDS in modern shops, treat the first production RRDS DELETE as a rehearsal: capture FILE STATUS matrices in documentation the same way you would for a new payment rail.

Indexing downstream summaries

If nightly batch DELETE removes detail rows that feed a separate summary VSAM or database, reorder jobs so summaries refresh after deletes or mark summaries stale explicitly. Orphans in reporting are not VSAM bugs; they are workflow bugs. Drawing a small dependency graph on the whiteboard during design review prevents the classic Friday-night realization that totals job ran before purge job.

Hands-on exercises

1. Delete one sandbox KSDS row, LISTCAT the cluster, and observe high-used and statistics fields before and after.
2. Simulate double-delete by issuing DELETE twice without intervening READ; capture FILE STATUS.
3. Document the difference between this page and `/tutorials/vsam/vsam-jcl-deleting` in three bullet points for your study notes.

Explain Like I'm Five

COBOL DELETE is erasing one line from a notebook page after you found the line with your finger. IDCAMS DELETE CLUSTER is throwing the whole notebook into recycling. If you throw the notebook away, nobody can erase lines anymore. If you erase a line, the rest of the notebook still exists for other readers—unless your teacher says certain notebooks cannot erase lines at all, which is like ESDS rules.

Test Your Knowledge