Append-only storage means that new records are added only at the end of the file. You never insert a record in the middle or at the beginning. In VSAM, the dataset type that has this behavior is the Entry Sequenced Data Set (ESDS). When you write a record to an ESDS, it goes after the last record that was written; the file grows at the "high" end (increasing relative byte address). This contrasts with a Key-Sequenced Data Set (KSDS), where you can insert a record anywhere in key order, which may trigger CI or CA splits. Append-only storage is simpler: no index to maintain for insert position, no splits, and sequential write is efficient. It fits workloads like logs, audit trails, and event streams where data arrives in order and you only need to add at the end and read in order (or by RBA). This page explains what append-only storage is, how ESDS implements it, when to use it, and how it differs from other VSAM types.
In append-only storage, the only way to add a new record is to append it after the last record in the file. There is no "insert at position X" or "insert in key order between A and B." So the file has a single growing end: the high-used RBA (the byte offset of the last used byte) increases with each write. The beginning and middle of the file do not change when you add data; only the end moves. This is the same idea as appending to a sequential file or a log: you open for extend (or output in append mode), write the new record, and it becomes the new last record. With ESDS, VSAM manages the physical layout (control intervals and control areas), but the logical behavior is append-only: every new record goes at the end.
An ESDS has only a data component (no index). When you open it for output or extend and write a record, VSAM places the record in the next available space at the end of the data component. That "next available space" is the first free byte after the current high-used RBA (or the start of the next control interval if the current CI is full). So physically, the record is stored in the next CI or in the free space at the end of the last used CI. There is no key to compare, no search for "where does this key go," and no need to move existing records or split CIs. The write is a straightforward append. That is why ESDS does not have CI splits or CA splits from inserts: those occur only when you insert in the middle and the target CI is full. In ESDS you never insert in the middle, so you never trigger a split. The file may still extend (allocate more space) when the current allocation is full, but that is normal extent allocation, not a split in the KSDS sense.
In a KSDS, when you insert a record, VSAM must place it in key order. That may be at the beginning, in the middle, or at the end of the file. So the insert position is determined by the key, not by "after the last record." When that position is in the middle and the target control interval is full, VSAM performs a CI split (or CA split if there is no free CI in the CA). So KSDS supports insert anywhere and pays the cost of index updates and possible splits. In an ESDS, the insert position is always "at the end," so there is no search for position, no split, and no index update (no index). That makes append-only storage cheaper for pure append workloads. The tradeoff is that you cannot insert in the middle: if you need to add a record in a specific logical position (e.g. between two existing records), you cannot do it with a single ESDS write. You would need to reorganize (e.g. REPRO to a new file with the desired order) or use a different structure (e.g. KSDS with a key).
| Type | Append-only? | Notes |
|---|---|---|
| ESDS | Yes | New records only at end; no insert in middle |
| KSDS | No | Insert in key order anywhere; CI/CA splits possible |
| RRDS | No | Insert into empty slots by RRN; not strictly append-only |
| LDS | N/A | Byte stream; no record insert concept |
Append-only storage is a good fit when:
Avoid append-only (ESDS) when you need key-based access (use KSDS) or when you need to insert or delete in the middle and reclaim space (ESDS does not physically delete; consider KSDS or RRDS).
Append-only refers to how new records are added (at the end only). It does not mean you cannot update or delete. You can update a record in place with REWRITE if the record length does not increase (or if it does not exceed the space in the CI). So in-place update is allowed. For delete, ESDS does not physically remove a record: the bytes stay in place. So you cannot "reclaim" that space for a new insert in the middle (there is no insert in the middle anyway). Applications often implement logical delete: mark the record as deleted (e.g. a flag byte or a value in the data) and skip it when reading. Or use an alternate index and mark the record as deleted in the AIX. So append-only does not forbid update or logical delete; it only restricts where new records go (at the end).
The high-used RBA (HI-U-RBA) is the byte offset of the last byte that has been written. When you append a record, that value increases by the size of the record (plus any control information). So the high-used RBA is the "end of the file" for append purposes. When you open for extend and write, VSAM writes at or after the current high-used RBA. When the file has used all allocated space (high-used RBA approaches high-allocated RBA), VSAM will allocate a new extent (if secondary was specified at define time) so that the append can continue. So monitoring high-used RBA and allocated space helps you plan for growth and avoid out-of-space conditions.
Imagine a diary where you only write on the next empty page. You never go back and add a new page between page 5 and page 6; you always add at the end. That is append-only. The computer does the same with an ESDS: every new record goes at the end of the file, so the file only grows at the end.
1. Where can a new record be added in an ESDS?
2. Do ESDS inserts cause CI or CA splits?
3. What is a typical use for append-only storage?