VSAM Append-Only Storage

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.

What Is Append-Only Storage?

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.

How ESDS Implements Append-Only

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.

Append-Only vs Insert-in-Middle (KSDS)

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).

Append-only by VSAM type
TypeAppend-only?Notes
ESDSYesNew records only at end; no insert in middle
KSDSNoInsert in key order anywhere; CI/CA splits possible
RRDSNoInsert into empty slots by RRN; not strictly append-only
LDSN/AByte stream; no record insert concept

When to Use Append-Only Storage

Append-only storage is a good fit when:

  • Order of arrival matters — Logs, audit trails, and event streams record events in the order they occurred. Appending at the end preserves that order. Reading from the start (or from a saved RBA) gives you chronological order.
  • You never need to insert in the middle — If all new data goes at the end and you do not need to "insert" between existing records, ESDS append-only is sufficient. If you need key-based insert (e.g. add a customer by customer ID in sorted order), use KSDS.
  • You want simple, fast writes — No index updates and no splits mean that each write is just an append. Throughput for sequential write can be high. You do need to allocate enough space (primary and secondary) so that the file can grow.
  • You can access by RBA when needed — If you need to reread a specific record later, you can save its RBA when you first read it and use that RBA for a direct read. So you get sequential read in order plus random access by RBA, without a key.

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).

Update and Delete in an Append-Only File

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).

High-Used RBA and Growth

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.

Key Takeaways

  • Append-only storage means new records are added only at the end. ESDS is append-only; there is no insert in the middle.
  • Append-only avoids CI and CA splits and index updates, so it is simple and efficient for pure append workloads.
  • Use append-only for logs, audit trails, and event streams where order of arrival matters and you only add at the end.
  • You can still update in place (REWRITE) and use logical delete; append-only only restricts where new records go.

Explain Like I'm Five

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.

Test Your Knowledge

Test Your Knowledge

1. Where can a new record be added in an ESDS?

  • Anywhere in key order
  • Only at the end of the file
  • In the first free slot
  • Only at RBA 0

2. Do ESDS inserts cause CI or CA splits?

  • Yes, like KSDS
  • No; appends do not require splitting
  • Only when the file is full
  • Only for variable-length records

3. What is a typical use for append-only storage?

  • Random lookup by key
  • Transaction logs or event streams where order matters
  • Frequent in-place inserts
  • Alternate index
Published
Updated
Read time4 min
AuthorMainframeMaster
Reviewed by MainframeMaster teamVerified: IBM z/OS 2.5 documentationSources: IBM DFSMS Access Method Services, z/OS VSAM documentationApplies to: z/OS 2.5