RBA access to an Entry Sequenced Data Set (ESDS) means using the relative byte address of a record to position to it or read it directly. An ESDS has no key, so the only stable way to refer to a specific record is by its RBA—the byte offset of that record from the start of the data component. When you read a record, the access method can give you its RBA; if you save that value, you can later position back to the same record (e.g. with START at that RBA and then READ) or, in environments that support it, read the record directly by RBA. RBA access is what makes ESDS more than a simple sequential file: you get both sequential read in entry order and the ability to jump to a known position or re-read a record by its address. This page explains how RBA access works in ESDS, typical use cases (resume, direct read, update in place), and how support differs between batch COBOL and CICS.
RBA access means using the relative byte address to find a record. The RBA is a number (typically 4 bytes) that gives the offset in bytes from the beginning of the data component to the start of the record. So RBA 0 might be the first record, RBA 500 the next, and so on. When you read a record from an ESDS, your program can obtain that record's RBA (the exact mechanism depends on the language and API—e.g. a COBOL register or a parameter). Once you have the RBA, you can use it in a later operation to go back to that record: position to that RBA and then read (e.g. START at RBA, then READ NEXT), or in CICS set RIDFLD to the RBA and issue a READ. That is RBA access: addressability by position rather than by key.
In a KSDS, you identify a record by its primary key; the index maps the key to the location of the record. In an ESDS there is no key and no index. Records are stored in write order. The only fixed attribute of a record's location is where it was placed when it was written—that is, its byte offset (RBA). So RBA is the "address" of the record. It does not change when you open or close the file, or when you read other records. It can change only if the file is reorganized (e.g. REPRO to a new cluster) or the record is removed. For a stable ESDS that is only appended to and not reorganized, saving an RBA and using it later is safe and is the standard way to support direct access and resumable processing.
| Use case | Description |
|---|---|
| Resume sequential processing | Save the RBA after reading N records; next run use START at that RBA and READ NEXT to continue from that position. |
| Direct read of a known record | You previously read a record and saved its RBA; later position to that RBA and read it again without scanning. |
| Update in place | Read a record (get its RBA), modify it, then REWRITE. The RBA identifies which record to rewrite. |
| Browse from a bookmark | Store RBAs of interest (e.g. section boundaries); position to an RBA and read forward for browsing. |
When you read a record from an ESDS, the access method knows the RBA of that record (it had to read the control interval containing that byte offset). The way you receive the RBA depends on your interface. In COBOL, some implementations provide the RBA in a special register or in a field associated with the file (e.g. after a READ). In CICS, when you read a record, the RBA can be returned in RIDFLD so you can use it for a subsequent direct read. In other languages or APIs, there is often a way to request the RBA after a successful read. Once you have it, store it (in a variable, in a key structure, or in another file) so you can use it later for positioning or direct read.
With ACCESS IS DYNAMIC in COBOL, you can often use the START statement to position the file at a specific RBA. You supply the RBA (not a key); the access method sets the current position to that byte offset. The next READ NEXT then returns the record at that position (if the RBA points to the start of a record) or the next record, and subsequent READ NEXT operations continue in entry order. So the pattern is: save an RBA from a previous read, later open the file with dynamic access, START at that RBA, then READ NEXT to get that record and continue. This gives you "resumable" sequential processing and the ability to jump to a known position. Not all batch COBOL environments support START by RBA for ESDS; check your documentation.
In CICS, ESDS files can be read randomly by RBA. You set the RIDFLD (record identifier field) to the RBA of the record you want and issue a READ. CICS uses that RBA to position to the record and return it. So in CICS you do not need to do START then READ NEXT; you can do a single READ with RIDFLD equal to the RBA. This is true direct (random) access by RBA. When you read a record, CICS can return its RBA in RIDFLD so you can store it and use it for a later direct read.
In batch COBOL, ESDS is often described as "sequential only" in the sense that the standard way to process it is READ NEXT in entry order. Some implementations do not support a direct READ by RBA in batch. What is usually supported is sequential read from the beginning, and with ACCESS IS DYNAMIC you may be able to START at an RBA (if the compiler and VSAM support it) and then READ NEXT to read from that point. So "RBA access" in batch may mean "position to RBA, then read sequentially from there" rather than a single random READ by RBA. If you need true random read by RBA in batch, check your COBOL and VSAM documentation; some sites use an alternate index or other techniques.
| Environment | RBA access support |
|---|---|
| Batch COBOL | Often sequential only; dynamic access may allow START at RBA then READ NEXT. Check compiler/docs. |
| CICS | RIDFLD can be set to RBA for direct READ on ESDS; random access by RBA is supported. |
| Assembler / other | VSAM macros can support RBA-based positioning and read; behavior is implementation-dependent. |
After you read a record, you know its RBA. To update it, you use REWRITE. The REWRITE updates the "last record read"—which is the record at the RBA you just read. So the flow is: read the record (and optionally save its RBA), modify the record in your buffer, REWRITE. The record length must not increase (some systems allow shortening). The RBA of the record does not change after the REWRITE; it is still the same record at the same position. So RBA access and update in place work together: the RBA identifies which record you are updating.
A common pattern is to process an ESDS in chunks. You read records sequentially until you have processed a batch (e.g. 10,000 records), then you save the RBA of the "next" record to process (or the last record processed) and end the run. In the next run you open the file, use START at that saved RBA (with dynamic access), and READ NEXT to continue from where you left off. That way you do not reread the first 10,000 records. The RBA is the bookmark. This is one of the most practical uses of RBA access in ESDS.
The high-used RBA (HI-U-RBA) is the byte offset of the first byte past the last valid data in the file. So all valid record RBAs are less than the high-used RBA. When you append a record, it is placed at or after the current high-used RBA, and that offset becomes the new record's RBA. Understanding HI-U-RBA helps you know the valid range of RBA values and when you have reached the end of the file when positioning by RBA.
Imagine a long tape where each sentence is written one after another. The "address" of a sentence is how many inches from the start it begins. If you remember that number (the RBA), later you can fast-forward the tape to that inch and start reading from there. You don't have a "name" for each sentence (no key); you have a position number. RBA access is using that position number to jump to the right place.
1. In ESDS, what is the main way to identify a specific record for direct access?
2. Why is RBA stable in an ESDS?
3. Where is RBA-based direct read commonly supported for ESDS?