IMS Architecture: Regions, Address Spaces, and Components

Understanding IMS architecture is essential before writing a single line of DL/I code. IMS is a complex multi-region system — multiple z/OS address spaces work together to handle database access, message processing, and online transactions simultaneously. Knowing how these regions interact explains why IMS programs behave the way they do.

The IMS Address Space Model

IMS runs as multiple cooperating address spaces (regions) on z/OS. Each region has a specific role in the overall system:

Control Region (IMSCTL)

The IMS Control Region is the heart of the IMS system. It manages:

System initialisation and shutdown
Resource coordination between all other IMS regions
The IMS log, which records all database changes for recovery
Lock management — ensuring no two programs corrupt each other's data
The system message queue (for IMS TM)

There is exactly one Control Region per IMS system. All other regions connect to it.

DL/I Region (DLISAS)

The DL/I Separate Address Space (DLISAS) handles the actual database I/O for batch programs. When a batch program calls CALL 'CBLTDLI' to retrieve or update IMS segments, the DLISAS is doing the physical database work. It:

Executes DL/I calls on behalf of batch and BMP programs
Manages buffer pools for IMS databases
Handles physical database I/O (VSAM and OSAM)

Message Processing Region (MPP)

MPP regions run online transaction programs in an IMS TM environment. When a user submits a transaction:

The Control Region receives the message from a terminal or OTMA connection
It schedules the transaction in an available MPP region
The MPP region executes the COBOL program
The response message is returned through the Control Region

There are typically multiple MPP regions running simultaneously to handle concurrent transactions.

Batch Message Processing Region (BMP)

BMP regions run programs that need access to both IMS databases and the IMS message queue simultaneously. They are a hybrid between batch and online processing — common for high-volume update jobs that must maintain consistency with online transactions.

IMS Fast Path Region (IFP)

Fast Path regions handle IMS Fast Path databases (DEDBs) and Main Storage Databases (MSDBs) — specialised structures designed for extreme throughput. IFP regions are optimised for very short, high-volume transactions.

IMS Database Components

DBDLIB — Database Descriptions

Every IMS database has a DBD (Database Description) stored in DBDLIB. The DBD defines:

The hierarchical structure (which segments are children of which)
Physical storage access method (HDAM, HIDAM, etc.)
Segment names, lengths, and field layouts
Key fields used for sequencing and indexing

DBDs are assembled from macro code and linked into the DBDLIB partitioned dataset.

PSBLIB — Program Specification Blocks

Every program that accesses IMS databases has a PSB (Program Specification Block) in PSBLIB. The PSB defines:

Which databases the program can access (one PCB per database)
The processing options (read-only, read/write, etc.)
The segment sensitivity (which segments the program is allowed to see)

ACBs — Application Control Blocks

ACBs are the compiled, merged form of DBDs and PSBs. Before a program runs, its PSB is combined with the relevant DBDs into an ACB and stored in ACBLIB. The ACB is what IMS actually loads at runtime.

The IMS Log

The IMS log is a sequential dataset that records every database change made by every program. It is the foundation of IMS recovery. After a failure, IMS uses the log to:

Forward recovery: Apply changes logged after an image copy to bring the database forward
Backout: Undo changes made by an abended program

The IMS Dynamic Backout feature automatically undoes uncommitted changes when a program abends, protecting database integrity without manual intervention.

IMS Buffer Pools

IMS uses buffer pools to cache database blocks in memory, reducing physical I/O. There are separate buffer pools for OSAM (IMS's own access method) and VSAM datasets. Proper buffer pool sizing is one of the most important IMS performance tuning activities.

How a DL/I Call Flows Through the Architecture

When a COBOL program issues a DL/I call (e.g., CALL 'CBLTDLI' USING GU-FUNC PCB-MASK SSA):

The call is intercepted by the IMS language interface module linked into the program
Control passes to the DLISAS (for batch) or the MPP region's IMS interface (for online)
The IMS buffer manager checks whether the required database block is already in memory
If not, a physical I/O request is issued to z/OS for the VSAM or OSAM dataset
IMS navigates the hierarchy to find the requested segment
The segment data is copied to the program's I/O area
Status code GE (not found) or blanks (success) is placed in the PCB
Control returns to the COBOL program

Frequently Asked Questions

Q: How many MPP regions should an IMS system have? The number of MPP regions depends on transaction volume and the mix of transaction types. Each region can run one transaction at a time. A system processing thousands of concurrent transactions needs enough MPP regions to prevent queueing delays. Typically, IMS administrators configure regions based on peak throughput requirements and z/OS processor capacity.

Q: What is OTMA and how does it relate to IMS TM? OTMA (Open Transaction Manager Access) is an IMS facility that allows non-SNA clients — TCP/IP applications, CICS, MQ — to access IMS transactions without 3270 terminal connections. Modern IMS systems use OTMA extensively for web service and API access to IMS transactions.

Q: What is the difference between OSAM and VSAM in IMS? OSAM (Overflow Sequential Access Method) is IBM's own access method, used for HDAM and HIDAM databases by default. VSAM (Virtual Storage Access Method) is z/OS's general-purpose access method and is used for HISAM and some HDAM/HIDAM configurations. OSAM generally performs better for IMS workloads due to IMS-specific optimisations in its I/O path.

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