IMS TM Architecture: Message Processing and MPPs

IMS TM (Transaction Manager) is the online transaction processing component of IMS — the system that accepts messages from users and applications, routes them to the correct processing program, and returns responses. IMS TM is a complete OLTP platform, comparable in purpose to CICS, but with a distinct architecture and programming model.

IMS TM vs CICS

Both IMS TM and CICS provide online transaction processing on z/OS. The key differences:

Aspect	IMS TM	CICS
Database access	IMS DB (native)	VSAM, DB2 (CICS-DB2)
Screen design	MFS (Message Format Service)	BMS (Basic Mapping Support)
Transaction definition	IMS transaction codes	CICS transaction IDs
Program invocation	Message-driven MPP	Terminal-driven
State management	Message-driven (stateless)	Pseudo-conversational

Many enterprises run both — CICS for applications that started on CICS, IMS TM for applications closely coupled to IMS DB.

The IMS Message Queue

The heart of IMS TM is the message queue — a set of in-memory and disk-based queues that hold input messages waiting for processing and output messages waiting for delivery.

When a user submits a transaction:

The terminal (or API) sends a message to IMS
IMS places the message on the input queue with the transaction code
IMS TM schedules a program to process it based on the transaction code
The program reads the message from the queue using an IOPCB
The program builds a response and writes it to the output queue
IMS delivers the response to the terminal or calling application

The queue architecture makes IMS TM highly resilient — messages are logged before processing, so a system failure does not lose transactions.

MPP — Message Processing Program Region

An MPP (Message Processing Program) region is a z/OS address space that runs IMS transaction programs. MPP regions:

Are started and managed by the IMS Control Region
Run one transaction at a time
Execute the COBOL program associated with the incoming transaction code
Communicate with the IMS Control Region to read/write messages and access databases

Multiple MPP regions run simultaneously to handle concurrent transactions. IMS schedules incoming messages across available MPP regions.

IOPCB — The Message PCB

Every IMS TM program has a special PCB called the IOPCB (Input/Output PCB) as its first PCB. The IOPCB provides access to the message queue:

cobol

LINKAGE SECTION.
01 IOPCB.
   05 IOPCB-LTERM     PIC X(8).   *> logical terminal name
   05 IOPCB-FILLER    PIC XX.
   05 IOPCB-STATUS    PIC XX.     *> status code
   05 IOPCB-DATE      PIC S9(7) COMP-3.
   05 IOPCB-TIME      PIC S9(6)V9 COMP-3.
   05 IOPCB-MSG-SEQ   PIC S9(5) COMP.
   05 IOPCB-MOD-NAME  PIC X(8).
   05 IOPCB-USER-ID   PIC X(8).

The IOPCB is always listed first in the PROCEDURE DIVISION USING:

cobol

PROCEDURE DIVISION USING IOPCB
                         CUSTOMER-PCB
                         ACCOUNT-PCB.

Reading and Writing Messages

An IMS TM program reads the input message from the queue using GU on the IOPCB:

cobol

* Read the input message
CALL 'CBLTDLI' USING GU-FUNC
                     IOPCB
                     INPUT-MESSAGE-AREA.

IF IOPCB-STATUS NOT = '  '
   PERFORM HANDLE-INPUT-ERROR.

Write the output message back:

cobol

* Send response to terminal
CALL 'CBLTDLI' USING ISRT-FUNC
                     IOPCB
                     OUTPUT-MESSAGE-AREA.

The input message structure must match the MFS format definition (or be a simple character string for non-MFS programs).

Transaction Code Routing

Each IMS transaction is identified by a transaction code (tran code) — a 1–8 character identifier. When a terminal user enters a transaction code (e.g., CUST1001), IMS looks up the code in its transaction definition table, finds the associated program and MPP class, and schedules the program to run.

Transaction codes are defined in the IMS system definition (SYSGEN) or via the IMS IMSGEN macro.

OTMA — Open Transaction Manager Access

OTMA (Open Transaction Manager Access) allows non-3270 clients to submit IMS transactions. Through OTMA, Java applications, TCP/IP clients, CICS programs, and MQ messages can invoke IMS transactions without 3270 terminal connections. OTMA is the primary way modern systems integrate with legacy IMS TM applications.

Frequently Asked Questions

Q: Can an IMS TM program access DB2 as well as IMS databases? Yes. An IMS TM program can contain both DL/I calls for IMS databases and embedded SQL for DB2 in the same program. SYNCPOINT coordination between IMS and DB2 is required to ensure transactional consistency — IMS SYNCPOINT and DB2 COMMIT must be coordinated so both systems commit or both back out together.

Q: What is the difference between a conversational and a non-conversational IMS TM program? A non-conversational program processes one input message and produces one output message, then terminates. A conversational program maintains state across multiple message exchanges with the user by using a scratch pad area (SPA). Conversational programs are more complex — most IMS TM programs are non-conversational, with state maintained in IMS databases rather than in the SPA.

Q: How does IMS TM handle program errors and abends? If an MPP program abends, IMS backs out any uncommitted database changes (dynamic backout), logs the error, and optionally returns an error message to the terminal. The failed message can be held on the suspend queue for reprocessing after the problem is corrected. IMS does not bring down other MPP regions — the failure is isolated to the one region that abended.

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