KSDS (Key Sequenced Data Set) is the VSAM dataset type that provides key-based access with records stored in ascending key order. ISAM (Indexed Sequential Access Method) was the mainframe's earlier way to get indexed, keyed access. KSDS effectively superseded ISAM because it handles inserts and deletes without the overflow chains and fragmentation that made ISAM performance degrade over time. This page compares KSDS and ISAM so you understand the structural differences, why KSDS is preferred, and what that means for keyed files on the mainframe today.
ISAM (Indexed Sequential Access Method) was an access method for indexed sequential files on IBM mainframes. The file had a prime data area (organized by key at load time) and overflow areas. The index pointed to tracks or control intervals in the prime area. When you inserted a record, the system placed it in an overflow area and linked it from the correct position in the prime area. When you deleted a record, the space it occupied in the prime area was not reused for new inserts; new inserts still went to overflow. Over time, files with many inserts and deletes developed long overflow chains and unused space in the prime area. Sequential reads could slow down because the system had to follow overflow pointers, and random access could also degrade as chains grew.
ISAM was designed for a different era of hardware and usage. It did not have the equivalent of VSAM's control intervals and free space, and the index was not dynamically rebalanced. Today, ISAM is obsolete on z/OS; VSAM KSDS (and databases like Db2) are used for keyed access.
KSDS is a VSAM dataset type. Each record has a primary key (a contiguous set of bytes at a fixed offset). Records are stored in ascending key order in the data component. The index component is a B-tree style structure: a sequence set (low-level index entries pointing to control intervals) and an index set (upper levels). Data is stored in control intervals (CIs); multiple CIs form control areas (CAs). When you define a KSDS, you specify KEYS(length offset), RECORDSIZE(average maximum), and optionally FREESPACE(ci ca) to reserve a percentage of each CI and each CA for future inserts.
When you insert a record, VSAM places it in the correct CI in key order, using the free space. When the CI has no room, VSAM splits the CI (and if necessary the CA) and updates the index. When you delete a record, the space in the CI is marked free and can be reused for a later insert. So there are no overflow chains; the index and data stay in balance and performance remains stable as the file is updated.
| Aspect | ISAM | KSDS |
|---|---|---|
| Index structure | Fixed at load; index points to tracks/sectors; overflow chaining | B-tree style; sequence set + index set; index updated on splits |
| Insert handling | New records go to overflow area; chain from prime | Insert in key order into CI free space; CI/CA split when full |
| Delete handling | Space in prime area not reused; overflow chain remains | Space in CI freed and reused for later inserts |
| Record format | Typically fixed-length | Fixed or variable (RECORDSIZE avg max) |
| Alternate keys | Not native | Alternate index (AIX) and path for alternate key access |
| Creation | Load program or utility; prime + overflow allocation | IDCAMS DEFINE CLUSTER; load with REPRO or application |
| Catalog | Older catalog model | Integrated with ICF catalog |
The main advantages of KSDS over ISAM come from dynamic index management and space reuse. The following table summarizes the main benefits.
| Advantage | Detail |
|---|---|
| Space reuse after delete | Deleted record space in a CI can be used for new inserts; no permanent holes |
| No long overflow chains | Splits keep index and data balanced; access path stays short |
| FREESPACE tuning | You set FREESPACE(ci ca) at define time to reduce split frequency |
| Variable-length records | RECORDSIZE(average maximum) supports variable-length data |
| Alternate indexes | AIX and path allow access by more than one key |
| Catalog and naming | KSDS is cataloged; single cluster name; no separate prime/overflow management |
Because KSDS reuses space and uses splits instead of overflow, the access path length stays bounded. In ISAM, the number of overflow chain steps could grow without limit as more inserts occurred. In KSDS, the index tree depth and CI size determine the maximum number of I/Os for a key lookup, and that stays stable. FREESPACE allows you to trade initial space for fewer splits during the life of the file.
In ISAM, the index was built at load time and pointed to fixed locations (e.g. track or cylinder) in the prime area. When a new key did not fit in that location, the record went to overflow and was chained. The index itself did not grow or rebalance; only the overflow chains grew. In KSDS, the index is a B-tree style structure. The sequence set contains one entry per CI (or range of keys) and points to the CI. The index set contains higher-level entries. When a CI is split, new index entries are added and the tree is updated. So the index grows with the data and stays balanced. Lookups require a small, predictable number of index levels plus one or more data CI reads.
In ISAM, an insert found the correct position in the prime area (by key). If that position was full or the key belonged in a full track, the record was written to overflow and linked. So the prime area never changed after the initial load; all growth was in overflow. In KSDS, an insert finds the correct CI (via the index), and the record is placed in key order within the CI, using free space. If the CI has no free space, VSAM splits the CI (and possibly the CA), redistributes records, and updates the index. So growth is absorbed by splitting, not by chaining. For deletes, ISAM left the prime slot empty; KSDS marks the space free in the CI and reuses it for a subsequent insert in that CI.
KSDS supports variable-length records via RECORDSIZE(average maximum). The application can store records of different lengths in the same cluster. ISAM was geared toward fixed-length records. KSDS also supports alternate indexes (AIX) and paths: you can define additional keys (including non-unique) and access the same data by alternate key. ISAM did not offer this in the same way. So KSDS gives you more flexibility in record layout and access paths.
An ISAM file was typically created by a load program that filled the prime area and set up the index; overflow space was pre-allocated. A KSDS is created with IDCAMS DEFINE CLUSTER with INDEXED, KEYS, RECORDSIZE, and optionally FREESPACE. Data is loaded with REPRO or by an application that opens the cluster and writes records. The cluster is cataloged; you reference it by name in JCL. There is no separate "prime" and "overflow" to manage; VSAM handles space and index internally.
ISAM is obsolete, but you may see it in older documentation, in legacy system descriptions, or in migration discussions. Understanding the difference between ISAM and KSDS helps when maintaining or migrating old applications. New keyed files on z/OS should be KSDS (or a database table). If you are designing a new application that needs key-based access, use VSAM KSDS or Db2; do not choose ISAM.
With ISAM, the main area (prime) was set when the file was built. New cards (records) had to go into an overflow box and were linked from the main area. When you threw a card away, its slot in the main area stayed empty. So the main area got holes and the overflow box got long chains. With KSDS, each drawer (control interval) has some empty slots (free space). When you add a card, it goes into the right drawer in order. When a drawer is full, it splits into two drawers and the index is updated. When you remove a card, that slot can be used again. So the filing system stays balanced and doesn't get long chains.
1. Where do new records go when you insert into an ISAM file?
2. How does KSDS avoid the overflow chain problem?
3. What KSDS parameter reserves space for future inserts?