MOVE 125 TO WS-RRN followed by READ ORDER-FILE asks a COBOL relative file for relative record number 125. The number is carried in a separate RELATIVE KEY item; it is not an embedded business key inside the record.
What is COBOL relative file organization?
A relative file is a direct-access file whose records are identified by position relative to the beginning of the file. Record number 1 is the first relative position, record number 10 is the tenth, and so on. On z/OS, Enterprise COBOL implements relative organization with a VSAM relative-record data set, or RRDS.
The RRN remains associated with that record until the record is deleted. The file can contain gaps: sequential processing visits existing records in ascending RRN order and skips positions that do not contain records.
Use the COBOL file-organization overview when comparing sequential, indexed, and relative designs. This page owns the COBOL and RRDS details for relative files.
SELECT and FD entries for a relative file
The ORGANIZATION IS RELATIVE clause establishes the file model. ACCESS MODE selects sequential, random, or dynamic processing. A relative key is always required for random and dynamic access, and it is required for sequential access when the program uses START.
WS-RRN is an unsigned integer item and is outside the FD record description. The RRN controls where COBOL reads or writes; ORDER-ID is ordinary application data and does not position the RRDS.
Fixed-length RRDS versus variable-length RRDS
| Characteristic | Fixed-length RRDS | Variable-length RRDS |
|---|---|---|
| VSAM definition | NUMBERED with equal average and maximum RECORDSIZE | NUMBERED with different average and maximum RECORDSIZE |
| Placement | The data set is divided into fixed-length slots. | Records are ordered by RRN but do not occupy fixed slots. |
| Empty or deleted position | An empty slot can receive a new record with that RRN. | Deleted or shortened record space becomes reusable free space. |
| Index | No prime or alternate index. | VSAM uses an index internally; COBOL still processes it as relative organization. |
| Record length | Fixed | Variable up to the defined maximum |
Neither form supports alternate indexes or spanned records. If the application needs lookup by customer number, surname, or another value stored in the record, the COBOL indexed-file guide is usually the better design reference.
Sequential, random, and dynamic access
| Mode | How records are selected | Best fit |
|---|---|---|
SEQUENTIAL | Existing records are returned in ascending RRN order. | Batch scan of most or all records. |
RANDOM | The program places the requested RRN in the relative-key item. | Independent lookups when only a small part of the file is processed. |
DYNAMIC | Individual statements switch between random lookup and sequential retrieval. | Position by RRN, then process a range of existing records. |
If the access-mode clause is omitted, COBOL assumes sequential access. The sequential-file guide covers physical sequential organization; it should not be confused with sequential access to an RRDS.
Random READ by relative record number
For random or dynamic access, set the relative-key item before READ. A relative-file READ must not contain a KEY IS phrase. If the requested RRN has no record, the operation raises an invalid-key condition.
The updated COBOL READ statement guide explains READ INTO, AT END, INVALID KEY, and failed-read safety across file organizations.
Sequential READ skips empty RRNs
Sequential access follows the ascending RRNs of records that exist. If records 3 and 6 are absent, a scan can return 1, 2, 4, 5, and 7 without presenting empty records to the program. When a relative-key clause is present, each successful sequential READ updates the item with the RRN returned.
Dynamic START and READ NEXT
Dynamic access can position the file at or after a requested RRN and then read forward. NEXT RECORD is required for sequential retrieval when ACCESS MODE IS DYNAMIC.
A successful START establishes the file position; it does not transfer the record into the FD area. The following READ NEXT makes the positioned record available.
WRITE, REWRITE, and DELETE examples
Open the file for I-O when existing records may be changed or deleted. A random WRITE uses the RRN in WS-RRN. If that position already contains a record, the WRITE fails with an invalid-key condition.
A common update pattern reads the RRN, changes the record, and rewrites it. With random or dynamic access, a DELETE identifies the relative record through the current relative-key value.
The COBOL file operations guide covers OPEN modes and the broader READ, WRITE, REWRITE, DELETE, and CLOSE lifecycle.
Common FILE STATUS values
| Status | Relative-file condition | Typical check |
|---|---|---|
00 | Successful operation | Continue processing. |
10 | No next record during sequential retrieval | End the scan. |
22 | A WRITE attempted to use an occupied relative position | Choose another RRN or treat it as an existing record. |
23 | A random READ, START, or direct operation could not find the requested record | Handle the missing RRN. |
24 | A WRITE exceeded the file boundary or the RRN did not fit the relative-key item | Check the data-set limit and key size. |
47 | READ attempted when the file was not open for INPUT or I-O | Correct the OPEN mode and control flow. |
Defining an RRDS with IDCAMS
The COBOL declaration must match a data set defined as RRDS. For a fixed 80-byte record, an IDCAMS definition can use NUMBERED and equal average and maximum record sizes.
Site SMS rules can supply or override allocation attributes, so production definitions should follow local storage standards. See VSAM DEFINE CLUSTER examples for the wider IDCAMS syntax.
When relative organization fits
- Good fit: the application already has a stable numeric slot, such as a bounded table position, terminal number, or internally assigned record number.
- Good fit: direct insert, lookup, and delete by that slot are frequent.
- Poor fit: identifiers are sparse, very large, or change over time.
- Poor fit: users need lookup through alternate business fields.
- Poor fit: a transformation can map two business keys to the same RRN unless the program implements and tests collision handling.
A randomizing calculation can produce an RRN, but it does not make collisions disappear. When key uniqueness and alternate access paths belong to the storage design, a KSDS is usually easier to maintain.
Common relative-file mistakes
- Defining the relative-key item inside the FD record.
- Coding
KEY ISon a READ for a relative file. - Assuming empty RRNs are returned as blank records during a sequential scan.
- Using dynamic access for an application that performs only independent random lookups.
- Writing to an occupied RRN without handling status 22.
- Choosing a key size too small for the largest RRN that the data set can use.
Official IBM references
- Specifying relative organization for VSAM files
- RELATIVE KEY clause
- ACCESS MODE clause
- Fixed-length RRDS structure
- Variable-length RRDS structure
- Reading records from a VSAM file
Frequently asked questions
What is relative file organization in COBOL?
A relative file identifies each record by a relative record number, or RRN, that represents its position relative to the beginning of the file. On z/OS, COBOL relative files use VSAM RRDS organization.
Is the RELATIVE KEY stored inside the record?
No. The RELATIVE KEY data item is defined outside the file record description. It supplies or receives the relative record number used for an I/O request.
Can a COBOL relative file be read sequentially and randomly?
Yes. Relative organization supports sequential, random, and dynamic access. Sequential reads follow ascending RRNs of records that exist; random access uses the RRN placed in the RELATIVE KEY item.
When should an application use an RRDS instead of a KSDS?
Use an RRDS when the application can derive a stable, reasonably dense numeric record number. Use a KSDS when records are naturally identified by business keys, need alternate access paths, or have sparse changing identifiers.
No comments:
Post a Comment