Key Takeaways — Chapter 13: Relative Files and RRDS

Core Concepts

  1. Relative files store records in numbered slots, accessed by relative record number (RRN) rather than by key value. VSAM RRDS provides the fastest possible random access — exactly 1 I/O per lookup, with no index overhead.

  2. The RELATIVE KEY field must be in WORKING-STORAGE, not in the record description. This reflects the fundamental distinction: the RRN is a file position, not business data. It is external to the record content.

  3. CRUD operations follow the same patterns as indexed files but with slot-based semantics: WRITE places a record in a specific slot, READ retrieves from a slot, REWRITE requires a prior READ, and DELETE truly empties a slot.

  4. Empty slots are a normal feature of relative files. Status '23' means "slot is empty" and should be handled as a routine condition, not an error. Sequential reads automatically skip empty slots.

Hashing

  1. Hashing converts business keys to slot numbers when keys are not natural integers. The division/remainder method with a prime divisor is the most common and generally most effective approach.

  2. Collisions are inevitable with hashing. Linear probing (try the next slot) is simple but can cause clustering. Quadratic probing reduces clustering. Always set a maximum probe count to prevent infinite loops.

  3. Load factor determines performance. Target 67-77% occupancy. Below 50% wastes space. Above 90% causes excessive collisions. Size your file at 130-150% of expected record count.

Design Decisions

  1. Relative files excel when keys are natural sequential integers — no hashing, no collisions, maximum performance. This is the ideal use case (e.g., provider codes PRV00001-PRV85000).

  2. Indexed files are more versatile: they support alphanumeric keys, alternate access paths, meaningful sequential order, and efficient use of disk space. Choose KSDS when flexibility matters more than raw speed.

  3. The hybrid cache pattern — using an RRDS as a fast lookup cache in front of a KSDS master file — gives the best of both worlds for high-volume applications with skewed access patterns.

Production Practices

  1. Cache coherence must be managed: if you maintain an RRDS cache, updates to the master file must be reflected in the cache to prevent stale data.

  2. Monitor hash performance over time: as data patterns change, collision rates can increase. Log collision statistics and alert when degradation occurs.

  3. Data-driven translation tables (codes stored in RRDS files) are more maintainable than hardcoded EVALUATE blocks. New codes can be added without program recompilation.

  4. Sparse files are acceptable when the file is small and access is random. When sparsity exceeds 90% or the file is large, consider a hash function to compact the key space.