ESDS vs BSAM/QSAM

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.

What Is ESDS?

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.

What Are BSAM and QSAM?

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.

Similarities: ESDS and Sequential

ESDS and sequential datasets are similar in that both preserve write order and support sequential processing. The following table summarizes the main similarities.

What ESDS and sequential have in common
AspectDetail
Records in write orderBoth store and present records in the order they were written
Sequential processingProgram can read from start to end without any index
Append-only patternNew records go at the end; no insert in the middle
Fixed or variable lengthBoth support fixed and variable-length records
Batch-friendlySuitable 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.

Differences: ESDS vs Sequential

ESDS vs BSAM/QSAM
AspectESDSSequential (BSAM/QSAM)
Record orderEntry order (order written); preservedPhysical order; same as write order
Sequential readYes; read in entry orderYes; read in physical order
Append (write at end)Yes; new records at endYes; write next at end
Direct accessYes; by Relative Byte Address (RBA)No; no built-in RBA or key
StorageDASD onlyDASD or tape
CreationIDCAMS DEFINE CLUSTER NONINDEXEDJCL DD with SPACE and DCB
Physical deleteNo; logical delete (e.g. flag) onlyNo; overwrite or new file
Alternate indexCan define AIX for keyed accessNo

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.

RBA and Direct Access in ESDS

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.

Logical Delete in ESDS

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.

Alternate Index on ESDS

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.

When to Use ESDS

When ESDS is a good fit
SituationReason
Need RBA-based direct readESDS supports read by Relative Byte Address
Log or audit trail with known positionsStore RBA for later direct access
Want optional alternate index laterESDS can have an AIX for keyed access
VSAM-based design (e.g. IMS, some Db2 use)Fits VSAM cluster model
DASD only, no tapeESDS is DASD only; use sequential if tape needed

When to Use Sequential (BSAM/QSAM)

When sequential is a good fit
SituationReason
Data must go to tapeSequential can be on tape; ESDS cannot
ISPF browse or editSequential is supported; ESDS is not
Simple export/import or transferFlat sequential file is universal
No need for RBA or alternate indexSequential is simpler to create (JCL only)

Summary

  • ESDS and sequential both keep records in write order and support sequential read/write.
  • ESDS adds RBA-based direct access and optional alternate index; sequential does not.
  • ESDS is DASD only and created with IDCAMS; sequential can be on tape and is created with JCL.
  • Use ESDS when you need RBA or AIX; use sequential when you need tape or ISPF or simple JCL-only creation.

Explain Like I'm Five

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.

Test Your Knowledge

Test Your Knowledge

1. What access does ESDS support that pure sequential does not?

  • Key-based read
  • Relative Byte Address (RBA) read
  • Tape storage
  • ISPF edit

2. How are records ordered in both ESDS and a sequential file?

  • By key
  • By RRN
  • In the order they were written
  • Random

3. Where can an ESDS reside?

  • Tape only
  • DASD only
  • Tape or DASD
  • Neither
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