IMS Segments and Fields: Designing the Hierarchy

Segment and field design is the most consequential decision in IMS database development. Unlike relational databases where tables can be joined in any combination, the IMS hierarchy is fixed at design time and changes are expensive. Getting the segment structure right from the start determines the performance and maintainability of the system for decades.

What is an IMS Segment?

An IMS segment is a fixed-length or variable-length block of bytes — the unit of data that IMS stores, retrieves, and manages. Every segment occurrence is read and written as a complete unit. You cannot retrieve a single field from a segment without retrieving the whole segment.

In your COBOL program, a segment is represented by a working storage structure:

01 CUSTOMER-IO-AREA.
   05 CUST-KEY     PIC X(10).
   05 CUST-NAME    PIC X(40).
   05 CUST-ADDRESS PIC X(80).
   05 CUST-PHONE   PIC X(15).
   05 CUST-STATUS  PIC X(2).
   05 FILLER       PIC X(53).

The total length must match the BYTES parameter in the DBD SEGM macro exactly.

Segment Length Rules

Segments can be fixed or variable length:

Fixed-length segments are simplest — every occurrence is the same size. Most production IMS segments are fixed length.

Variable-length segments have a 2-byte binary prefix containing the actual length, followed by the data. Variable-length segments save space when fields frequently contain short values, but add complexity to COBOL programs and reduce I/O efficiency.

For new design, prefer fixed-length segments unless storage cost is a strong constraint.

Key Fields and Sequence Fields

The sequence field controls the order in which twin segment occurrences are stored under a parent. IMS inserts new occurrences in sequence-field order:

FIELD NAME=(ACCT-NO,SEQ,U),BYTES=15,START=1,TYPE=C

• SEQ — marks this as the sequence field
• U — enforces uniqueness (no two ACCOUNT segments under the same CUSTOMER can have the same account number)

Without U, duplicate sequence field values are allowed and occurrences are stored in insertion order among duplicates.

The sequence field in the root segment also serves as the root key — the value used by HIDAM's index to locate root occurrences directly.

Field Types

Sequence fields must be character (C) or packed decimal (P) — IMS uses byte comparison for sequencing.

Designing Segment Hierarchies: Practical Rules

Rule 1: Follow the natural access path. Put the entity you search by most often at the top of the hierarchy or near the root. If you always start with a customer number, CUSTOMER should be the root.

Rule 2: Keep high-frequency data close to the root. Data accessed in every transaction should be at level 1 or level 2. Deeply nested segments require more navigation and are slower to access.

Rule 3: Limit segment types per parent. Having more than 6-8 direct children of a parent creates complex programs. Consider whether some children can be combined or moved to a separate database.

Rule 4: Size segments for I/O efficiency. IMS reads data in blocks. A segment that is 200 bytes in a 2048-byte block allows roughly 10 segments per block read. Design segment sizes to fit neatly into your block size, minimising wasted space.

Rule 5: Plan for growth. Leave spare bytes (FILLER) in segments you expect to expand. Adding fields to an existing segment is possible only if the segment has reserved space, or you can extend BYTES and reorganise the database.

Common Segment Design Patterns

Header-detail pattern: Root segment contains the header information, child segments contain the details. Customer (header) → Transactions (detail). This is the most common pattern.

Multiple attribute types: When an entity has several different kinds of related information, use multiple child segment types rather than cramming everything into one wide segment. Customer → Address, Customer → Phone, Customer → Contact are cleaner than one huge customer segment.

Summary and detail: For performance, store running totals in a parent segment rather than computing them by reading all child segments. Account balance in the ACCOUNT segment, updated by each TRANSACTION insertion.

Frequently Asked Questions

Q: Can I add a new field to an existing IMS segment without rebuilding the database? Only if there is FILLER space at the end of the segment. If a segment is defined as 200 bytes and your COBOL layout only uses 150 bytes, you can redefine the last 50 bytes as new fields without a physical database change — just update the FIELD macros in the DBD (no physical reorganisation needed if bytes don't change), regenerate, and update your COBOL. If you need to increase the segment's BYTES, a full unload-reload is required.

Q: What is the maximum segment size in IMS? The maximum segment size is 32,767 bytes for fixed-length segments. For variable-length segments, the maximum data portion is 32,767 bytes plus the 2-byte length prefix. In practice, segments larger than a few hundred bytes become inefficient because IMS reads them whole — large segments should be split or moved to a separate database.

Q: Should I use packed decimal or character for numeric fields? Use packed decimal (TYPE=P) for numeric amounts and quantities — it saves storage (a 12-byte PIC S9(21) COMP-3 holds 21 digits) and performs well. Use character (TYPE=C) for codes and identifiers even if they contain only digits, because character comparison is simpler and padding/truncation is more predictable in COBOL.

Part of the IMS Mastery Course — Module 6 of 22.