IMS vs DB2: When to Use Each on z/OS Mainframe

One of the most common questions for mainframe developers is: when should I use IMS and when should I use DB2? Both are IBM products running on z/OS, both store enterprise data, and both are used in the same organisations. But they are fundamentally different in their data model, access patterns, and programming interfaces.

The Core Difference: Data Model

IMS stores data in a hierarchical model — a strict tree structure where every record (segment) has exactly one parent, except for the root segment. To access data, you navigate down the tree from parent to child. This maps well to data that is naturally hierarchical: a customer has accounts, each account has transactions, each transaction has line items.

DB2 stores data in a relational model — tables with rows and columns. Data relationships are expressed through foreign keys and navigated with JOINs in SQL queries. The relational model is more flexible: any table can be joined to any other, and the structure can be queried in ways not anticipated at design time.

Performance Characteristics

IMS Performance Strengths

IMS excels when:

• Access always starts at a known root segment (e.g., retrieve customer by customer number, then get their accounts)
• The access path is predictable and consistent
• Transaction volume is extremely high (millions of transactions per hour)
• Data is hierarchically structured and queries follow the hierarchy

In these scenarios, IMS's direct-path navigation through physical pointers (in HDAM/HIDAM) is faster than SQL query processing. There is no query optimiser, no plan compilation, no JOIN execution — just pointer-following from block to block.

DB2 Performance Strengths

DB2 excels when:

• Queries are ad hoc or unpredictable in their access patterns
• Data must be joined across multiple entities in flexible ways
• Reporting and analytics require aggregation, grouping, and complex filtering
• Schema must evolve frequently (adding columns, changing relationships)
• Multiple applications with different access needs share the same data

Programming Interface

IMS: DL/I Calls in COBOL

IMS programs access data using DL/I (Data Language/I) calls — procedural calls embedded in COBOL, PL/I, or assembler programs. The developer explicitly navigates the hierarchy using calls like GU (Get Unique), GN (Get Next), and GNP (Get Next within Parent).

CALL 'CBLTDLI' USING GU-FUNC
                     CUSTOMER-PCB
                     CUSTOMER-IO-AREA
                     CUSTOMER-SSA.

The programmer controls exactly which path through the database is taken. This explicitness gives maximum performance but requires detailed knowledge of the hierarchy.

DB2: SQL (Embedded or Dynamic)

DB2 programs access data using SQL — either embedded in COBOL (EXEC SQL SELECT ... END-EXEC) or via dynamic SQL at runtime. The DB2 optimiser chooses the access path; the developer describes what data they want, not how to retrieve it.

EXEC SQL
    SELECT ACCT_NO, BALANCE
    FROM ACCOUNTS
    WHERE CUST_ID = :WS-CUST-ID
END-EXEC.

SQL is far more accessible to developers and analysts without mainframe specialisation.

Schema Flexibility

DB2 wins clearly on schema flexibility. Adding a column to a DB2 table is a single DDL statement. Adding a new field to an IMS segment requires regenerating the DBD, possibly rebuilding the database, and recompiling all programs that access that segment.

IMS schema changes are expensive — this is one of the main arguments for choosing DB2 for new development even in mainframe shops.

When to Choose IMS

Use IMS when:

• You are maintaining an existing IMS application (the cost of migration is the decision)
• The access pattern is strictly hierarchical and high-volume
• You need maximum transaction throughput (IMS Fast Path in particular)
• The data model is stable and will not need frequent schema changes
• The application has been running correctly for decades and the risk of change is high

When to Choose DB2

Use DB2 when:

• Starting a new application (DB2 is IBM's recommended choice for new development)
• The access patterns are diverse or unpredictable
• Multiple applications with different needs will share the data
• Reporting and analytics are primary use cases
• You need SQL tooling, BI integration, and easier developer onboarding

Coexistence: IMS and DB2 Together

Many enterprises run both simultaneously. An IMS COBOL program can access DB2 data using embedded SQL in the same program — this is the IMS-DB2 interface and is widely used for reporting or lookups where the primary transaction is IMS-based. The IMS Mastery course covers this in the DL/I programming modules.

Frequently Asked Questions

Q: Is IBM pushing customers to migrate from IMS to DB2? IBM supports both products actively and does not pressure customers to migrate. IBM has stated publicly that IMS will continue to be developed and supported. Many IBM customers have IMS and DB2 running side by side and IBM provides tools to integrate them.

Q: Can IMS and DB2 be accessed from the same COBOL program? Yes. A COBOL program can contain both DL/I calls (for IMS) and embedded SQL (for DB2). Synchronisation between the two is important — SYNCPOINT in IMS and COMMIT in DB2 must be coordinated to maintain consistency.

Q: What about IMS Java access — does that change the IMS vs DB2 equation? IBM's IMS Universal Drivers allow Java applications to access IMS using JDBC, making IMS feel more like a relational database from the application's perspective. This reduces the programming interface gap but does not change the underlying data model differences.

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