ESDS (Entry Sequenced Data Set) is a VSAM dataset type in which records are stored in the order they were written and read in that same order. Sequential datasets accessed with BSAM or QSAM also store records in physical order and are read (or written) sequentially. So ESDS and sequential files share an important trait: no key-based index, and access is either one-way sequential or, in the case of ESDS, by position (Relative Byte Address). This page explains the similarities between ESDS and sequential (BSAM/QSAM), the differences (RBA, storage, creation), and when to choose one over the other.
ESDS is one of the four VSAM dataset types. It has only a data component (no index component). Records are stored in the order they were written and cannot be physically deleted or inserted in the middle; new records are always added at the end. The system assigns each record a Relative Byte Address (RBA)—the offset in bytes from the start of the dataset to the start of that record. You can read sequentially (in entry order) or by RBA if you know the RBA (e.g. you stored it when you wrote the record, or you got it from a previous read). ESDS is created with IDCAMS DEFINE CLUSTER with NONINDEXED and RECORDSIZE. It exists only on DASD.
BSAM (Basic Sequential Access Method) and QSAM (Queued Sequential Access Method) are access methods for sequential datasets. The dataset is a stream of blocks; records are read or written in order. QSAM is the usual choice: it buffers records and presents a simple read-next or write-next interface. BSAM works at the block level. In both cases, there is no index and no key; the only way to reach a given record is to read from the beginning (or from a position the program has tracked). Sequential datasets can be on DASD or tape and are created with JCL (DD with SPACE, DCB). Record format is specified with RECFM, LRECL, and BLKSIZE.
ESDS and sequential datasets are similar in that both preserve write order and support sequential processing. The following table summarizes the main similarities.
| Aspect | Detail |
|---|---|
| Records in write order | Both store and present records in the order they were written |
| Sequential processing | Program can read from start to end without any index |
| Append-only pattern | New records go at the end; no insert in the middle |
| Fixed or variable length | Both support fixed and variable-length records |
| Batch-friendly | Suitable for batch jobs that read or write in order |
In many batch jobs that only read or write a file from start to end, the logical behavior is the same: records in order, no key lookup. So for "read the whole file once" or "append a log," either an ESDS or a sequential file can work. The choice then depends on whether you need RBA, tape, ISPF, or creation method.
| Aspect | ESDS | Sequential (BSAM/QSAM) |
|---|---|---|
| Record order | Entry order (order written); preserved | Physical order; same as write order |
| Sequential read | Yes; read in entry order | Yes; read in physical order |
| Append (write at end) | Yes; new records at end | Yes; write next at end |
| Direct access | Yes; by Relative Byte Address (RBA) | No; no built-in RBA or key |
| Storage | DASD only | DASD or tape |
| Creation | IDCAMS DEFINE CLUSTER NONINDEXED | JCL DD with SPACE and DCB |
| Physical delete | No; logical delete (e.g. flag) only | No; overwrite or new file |
| Alternate index | Can define AIX for keyed access | No |
The main functional difference is RBA. In ESDS, every record has an RBA. The program can save that RBA (e.g. in a control file or in memory) and later open the ESDS and read directly at that RBA. That is useful for logs or audit trails where you write a record and store its RBA for later retrieval. In a sequential file, the system does not give you a standard RBA; you would have to compute and maintain offsets yourself if you needed direct access. ESDS builds that into the access method.
Storage and tools also differ. ESDS is DASD only; sequential can be on tape. Sequential datasets can be browsed and edited with ISPF 3.4; ESDS cannot (you need a VSAM-aware tool). Creation: IDCAMS for ESDS, JCL for sequential.
The Relative Byte Address (RBA) is a 4-byte value: the offset in bytes from the start of the dataset to the start of the record. When you read a record from an ESDS (sequentially or by RBA), the access method can return the RBA of that record. You can store it and use it in a later run to read the same record directly with a direct READ by RBA. That allows patterns like: write a log record, save its RBA in an index or control file, then later read that exact record by RBA without scanning the file. Sequential files do not provide this in the same way; you would have to manage your own byte offsets.
ESDS does not support physical deletion of a record in the middle. Once written, the record stays at its RBA. Applications often use logical delete: a flag byte or field in the record (e.g. "deleted" or "active") that the program checks. When reading sequentially, the program skips records marked deleted. The space is not reclaimed; the file grows. Sequential files are similar—you don't delete in the middle; you might rewrite the whole file or use a flag. So for "delete" behavior, ESDS and sequential are comparable: logical delete or rebuild the file.
Although ESDS has no primary key, you can define an alternate index (AIX) on an ESDS. The AIX is built over one or more fields in the record (e.g. transaction ID, date). Then you can access the ESDS through a path by that alternate key: the system uses the AIX to find the RBA and reads the record. So ESDS can offer keyed access without being a KSDS. Sequential files have no such feature; access is only sequential or by your own bookkeeping.
| Situation | Reason |
|---|---|
| Need RBA-based direct read | ESDS supports read by Relative Byte Address |
| Log or audit trail with known positions | Store RBA for later direct access |
| Want optional alternate index later | ESDS can have an AIX for keyed access |
| VSAM-based design (e.g. IMS, some Db2 use) | Fits VSAM cluster model |
| DASD only, no tape | ESDS is DASD only; use sequential if tape needed |
| Situation | Reason |
|---|---|
| Data must go to tape | Sequential can be on tape; ESDS cannot |
| ISPF browse or edit | Sequential is supported; ESDS is not |
| Simple export/import or transfer | Flat sequential file is universal |
| No need for RBA or alternate index | Sequential is simpler to create (JCL only) |
Imagine a diary: you write on page 1, then page 2, then page 3. You read from the start to the end in that order. Both ESDS and a sequential file work like that—entries (records) in the order you wrote them. The difference: with ESDS, the system also remembers "that record starts at byte 1000," so later you can jump straight to byte 1000 and read that record. With a plain sequential file, you don't have that address stored; you read from the beginning. Also, the diary (ESDS) has to stay in a fixed place (DASD); a sequential file can be copied to a tape reel.
1. What access does ESDS support that pure sequential does not?
2. How are records ordered in both ESDS and a sequential file?
3. Where can an ESDS reside?