An Entry Sequenced Data Set (ESDS) does not support physically deleting a record. Once a record is written, it remains in the file at the same relative byte address (RBA) until the file is reorganized or recreated. This is a fundamental design choice: ESDS preserves entry order and RBA stability, and physical deletion would require moving or removing data in a way that would change the RBAs of other records, breaking any stored references and the simple "append only" model. This page explains why ESDS has no physical delete, how that differs from KSDS (where DELETE is supported), and what you can do instead: logical delete, overwriting with a tombstone, or building a new file with REPRO.
Physical delete means the record is removed from the dataset: the bytes that held the record are no longer part of the file, and the space can be reused or the file can be shortened. In a KSDS, when you issue DELETE, the record is removed from the data component and the key is removed from the index; the space may be reused for inserts. In an ESDS, there is no DELETE operation. You cannot remove a record so that it no longer exists at that RBA. The record stays where it is. So "no physical delete" means: the access method does not provide a way to remove a record from an ESDS.
ESDS stores records in entry order. Each record has a fixed RBA from the moment it is written. If you could physically delete a record, you would have two bad options. Option one: leave a "hole" in the file. Then the file would have gaps, and the RBA of every record after the hole would not change—but you would have unused space and complexity in managing which RBAs are valid. Option two: compact the file by shifting all following records forward. That would change the RBA of every record after the deleted one. Anyone who had saved an RBA (for resume, direct read, or update) would now point to the wrong record or the wrong position. So physical deletion would destroy RBA stability, which is the basis of direct access and positioning in ESDS. To avoid that, VSAM simply does not offer physical delete for ESDS. The design choice is: keep entry sequence and stable RBAs, and do not support delete.
In a KSDS, deletion is possible because the index is separate from the data. When you delete a record, the index entry for that key is removed and the data component can mark the space as free (or reuse it). The keys of other records do not change, and the index is updated in place. So KSDS can support DELETE without breaking key-based addressing. ESDS has no index and addresses only by RBA; removing a record would break RBA-based addressing, so DELETE is not provided.
| Aspect | ESDS | KSDS |
|---|---|---|
| Delete supported | No physical delete | Yes; DELETE removes record and updates index |
| Reason | RBA must stay stable; no index to update | Index can be updated; key removed from index |
| Alternative | Logical delete or REPRO to new file | Physical delete is the normal option |
If your application logic requires that a record no longer be treated as valid, you have three main approaches. None of them is a true physical delete; they work within the ESDS constraint.
| Approach | Description |
|---|---|
| Logical delete | Reserve a field (e.g. status byte) in each record. Set it to "deleted" when the record is no longer valid. On read, skip records with that value. |
| Overwrite (REWRITE) | Replace the record content with a same-length "tombstone" or blank record. The RBA stays the same; content indicates deleted. |
| REPRO to new file | Read the ESDS, copy only records you want to keep to a new ESDS, then switch to the new file. Frees space but changes RBAs. |
Logical delete means you reserve part of the record (e.g. a status byte, a code, or a flag) to mean "this record is deleted." When the user or process requests deletion, you do not remove the record; you update it (REWRITE) to set that flag. When you read the file (sequentially or by RBA), you check the flag and skip records that are marked deleted. So the record still exists on disk and still has the same RBA, but your application ignores it. The downside is that the space is not reclaimed; the file can grow over time with many logically deleted records. If that becomes a problem, you can run a periodic job that REPROs only active records to a new ESDS and then switches to the new file. The new file has new RBAs, so any stored RBA values must be updated or regenerated.
Another approach is to REWRITE the record with the same length but with content that means "deleted"—for example, all spaces or a special code in the first byte. The RBA does not change. When you read, you recognize the tombstone and skip it. This is similar to logical delete but uses the whole record as the marker. It works when record length is fixed and you can afford to overwrite with a known pattern.
When you need to reclaim space and actually remove the logical deletes from the dataset, you read the ESDS sequentially, copy only the records that are not logically deleted to a new ESDS (using REPRO or a program that writes to the new file), then delete (or archive) the old cluster and use the new one. The new file has no deleted records and a smaller size. The drawback is that every RBA in the new file is different from the old file. Any application or index that stored RBAs into the old file must be updated to use the new file and new RBAs, or you must rebuild those references from the new file. So REPRO is a "reorganize" that gives you a clean ESDS at the cost of changing all addresses.
If your application frequently deletes records and needs space reclaimed immediately, ESDS may not be the best choice; a KSDS with physical DELETE might be better. If you have an append-heavy, read-mostly workload (e.g. logs, audit trails) where records are rarely "removed" or where logical delete is acceptable, ESDS is a good fit. Understanding that ESDS cannot physically delete helps you design the record layout (e.g. a status field for logical delete) and plan for occasional REPRO if you need to compact.
Imagine a notebook where you can only add new lines at the end. You cannot tear out a page or a line, because then the page numbers (like RBA) of everything after it would change and your bookmarks would point to the wrong place. So the notebook doesn't let you tear pages. If you want to "delete" something, you cross it out (logical delete) or you copy the whole notebook into a new one and only copy the lines you want to keep (REPRO).
1. Why does ESDS not support physical delete?
2. What is logical delete in ESDS?
3. How can you get rid of logically deleted records and reclaim space in ESDS?