IMS Hierarchical Data Model Explained with Examples

The hierarchical data model is the foundation of everything in IMS. Before you can understand DBDs, write DL/I calls, or design a program, you must understand how IMS organises data as a tree. The hierarchy dictates how data is stored physically, how programs navigate it, and what operations are possible.

What is a Hierarchy?

A hierarchy is a tree structure where each node has exactly one parent, except for the top node (the root), which has no parent. Every node can have zero or more children. In IMS terminology, each node is called a segment.

A simple customer-account hierarchy:

CUSTOMER (root)
├── ACCOUNT
│   └── TRANSACTION
└── ADDRESS

• CUSTOMER is the root segment — it has no parent
• ACCOUNT and ADDRESS are children of CUSTOMER
• TRANSACTION is a child of ACCOUNT (grandchild of CUSTOMER)

Every CUSTOMER occurrence can have multiple ACCOUNT occurrences. Each ACCOUNT can have multiple TRANSACTION occurrences. Each CUSTOMER can also have multiple ADDRESS occurrences.

Key Terminology

Segment: The basic unit of data in IMS. A segment is analogous to a row in a relational database. It contains fields and is stored as a contiguous block of bytes.

Root Segment: The topmost segment in the hierarchy — the one with no parent. Every hierarchical path through the database starts at a root segment occurrence.

Dependent Segment: Any segment below the root. A dependent segment always has exactly one parent.

Segment Occurrence: A specific instance of a segment type. The CUSTOMER segment type defines the layout; a specific customer's data is a segment occurrence.

Twin Segments: Multiple occurrences of the same segment type under the same parent are called twins. All of customer 1001's ACCOUNT segments are twins of each other.

Hierarchical Path: The path from root to a specific dependent segment. The path CUSTOMER → ACCOUNT → TRANSACTION is the hierarchical path to a transaction segment.

Physical Storage Implications

The hierarchical model is not just logical — it affects physical storage. In HDAM and HIDAM databases, segments are physically stored with pointers connecting parent to first child and sibling to sibling. IMS maintains these pointers automatically.

When you retrieve a TRANSACTION segment, IMS must:

1. Find the correct CUSTOMER occurrence (via the root key)
2. Navigate to the correct ACCOUNT occurrence (via the sequence field)
3. Navigate to the correct TRANSACTION occurrence

This pointer-following is why IMS is fast for known-path access — it follows pointers directly without scanning or joining.

Sequence Fields and Key Fields

Each segment type can have a sequence field — a field IMS uses to maintain segment occurrences in sorted order within a parent. The sequence field for ACCOUNT might be the account number; IMS stores ACCOUNT segments in account-number order under each CUSTOMER.

The root segment typically has a key field — the unique identifier used to locate a specific root occurrence. In HIDAM databases, the key field is used to build a root-level index.

Rules of the Hierarchical Model

Rule 1: One parent per segment. Every non-root segment occurrence has exactly one parent occurrence. A TRANSACTION belongs to exactly one ACCOUNT.

Rule 2: Delete cascades down. Deleting a parent segment deletes all its dependent segments. Deleting a CUSTOMER deletes all their ACCOUNT and TRANSACTION segments automatically.

Rule 3: Insert requires parent. You cannot insert a dependent segment without an existing parent. You cannot insert an ACCOUNT without first inserting the CUSTOMER.

Rule 4: No lateral navigation. Standard IMS navigation only moves top-down or sequentially. To move from one branch to another (e.g., from ADDRESS to ACCOUNT under the same CUSTOMER), you must re-position using a GU call or use a PCB with appropriate sensitivity.

Hierarchical Sequence Key (HSK)

The full path from root to a segment occurrence is called the Hierarchical Sequence Key. It uniquely identifies every segment occurrence in the database. For a TRANSACTION segment, the HSK might be:

CUSTOMER(1001) → ACCOUNT(CHK001) → TRANSACTION(20260101001)

IMS uses the HSK concept internally for positioning and retrieval.

Designing a Good IMS Hierarchy

Good IMS hierarchy design follows naturally from the application's access patterns:

Put the most-accessed data highest. The root segment and its first-level children are the most efficient to access. Deeply nested segments require more navigation.

Use sequence fields that match retrieval patterns. If you always retrieve transactions in date order, the transaction date should be the sequence field.

Avoid very wide hierarchies at the same level. Having 20 different child segment types under the same parent is difficult to navigate and maintain.

Consider data volumes. A CUSTOMER with 50,000 TRANSACTION occurrences creates a very deep tree that can slow sequential navigation. Consider summarising or archiving historical data.

Frequently Asked Questions

Q: Can an IMS segment have multiple parent types? No — in standard IMS, a segment has exactly one parent type. This is the fundamental constraint of the hierarchical model. IMS does have a concept called "logical relationships" that allows a segment to appear as a child in multiple hierarchies, but this is an advanced feature with significant complexity and is used sparingly.

Q: How does IMS handle the equivalent of a many-to-many relationship? IMS does not natively support many-to-many relationships the way relational databases do with join tables. IMS logical relationships partially address this but add complexity. For truly many-to-many data, DB2 is a better fit. Most IMS designs normalise data to fit the hierarchical model rather than forcing relational patterns.

Q: What happens to the physical database when I add a new child segment type? Adding a new segment type to an existing IMS database requires a DBD change, DBDGEN, and ACBGEN. If the new segment is stored within existing segment occurrences (concatenated), database reorganisation may be required. New child segment types that use separate storage (like HIDAM secondary index databases) can sometimes be added with less disruption.

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