IMS MQ Transactions

IMS MQ transactions are the running programs inside IMS Transaction Manager that turn queue bytes into database updates and reply messages. Where CICS developers speak of transactions and CKTI, IMS teams speak of MPP and BMP, PCBs, CHKP, and schedule codes. The queue manager does not understand IMS vocabulary—it delivers messages. IMS must schedule the right program, open the right database PCB, and end with a checkpoint that matches business rules. Message-driven IMS is how overnight files shrink into continuous processing: MQ buffers spikes, IMS commits what it can, and partners on other platforms see orderly events. This tutorial explains transaction types, reading and writing messages in IMS programs, checkpoint coordination with MQ, OTMA-delivered transactions, error and abend behavior, capacity planning for MPR load, and troubleshooting when depth grows on MQ but IMS seems idle.

Transaction Types: MPP and BMP

Choose MPP when each message is one business transaction with tight latency. Choose BMP when processing thousands of messages per cycle is cheaper than per-message scheduling overhead. Mixing both on the same queues without documentation confuses operations.

Message Processing Flow

1. Message arrives on MQ queue—possibly from remote partner or internal producer.
2. IMS region is notified via application MQGET loop, OTMA, or site trigger mechanism.
3. IMS schedules transaction with correct program and PCB masks.
4. Program MQGETs (if not already passed buffer), validates format, updates IMS DB.
5. Program MQPUTs reply or downstream event if required.
6. CHKP commits IMS and coordinated MQ work; or ROLB/backout on failure.

MQI Calls Inside IMS Programs

IMS COBOL and PL/I programs link to MQI entry points like other languages. Connection handles may be acquired per message or pooled per region depending on performance tuning. Use syncpoint-capable options when database updates and messages must align. Log reason codes—2035 authorization and 2085 unknown object dominate bridge cutovers.

1
2
3
4
/* Pseudocode structure — language bindings vary
   MQGET input queue -> process IMS DB -> MQPUT reply queue
   IF business OK -> CHKP (coordinated if configured)
   ELSE -> rollback / negative reply / error queue PUT */

CHKP, ROLB, and MQ Visibility

CHKP makes IMS database changes permanent for the unit of work. When MQ is enrolled, CHKP also commits MQ puts and gets in that UOW. ROLB or abend with rollback reverses coordinated messaging—peers may never see a half-published event. When MQ is not enrolled, a committed IMS record might exist without a matching notification message—architects forbid that combination for money movement flows.

OTMA-Scheduled Transactions

OTMA delivers structured input to IMS with routing tokens. MQ carries the payload; IMS interprets headers to pick program and commit mode. Errors in logical destination or LTERM mapping send work to IMS error transactions—monitor those queues as closely as business queues. OTMA is powerful and unforgiving; change control must include partner simulators.

Capacity and the Message Processing Region

Each concurrent IMS transaction consumes MPR resources. MQ depth spikes can schedule more work than IMS can run, deepening queues and missing SLAs. Tune max threads, prioritize critical message types on separate queues, and use backout thresholds. Compare to CICS MXT limits—same physics, different knobs.

Error Handling Patterns

• Poison message: repeated rollbacks; move to error queue after N attempts via backout counter or application logic.
• Format error: negative acknowledgment without retry storm; log message id and hex dump sample.
• Database deadlock: rollback entire UOW including MQ; rely on redelivery if appropriate.
• Partner timeout on reply queue: correlate request message id in reply MQMD.

Tutorial: Design a Message-Driven MPP

1. Define input and reply queue names and message copybook.
2. Document PCB and database segments updated.
3. State syncpoint: coordinated CHKP yes or no.
4. Define abend path and whether message returns to queue.
5. Agree monitoring thresholds with operations.

Explainer: Ticket Window at the DMV

MQ is the line of people holding tickets. Each IMS transaction is one clerk serving one ticket completely—forms filed (database), receipt printed (reply message), desk closed for that ticket (CHKP). If the clerk tears up the forms on error, the ticket may go back to the line (rollback redelivery).

Explain Like I'm Five

Each letter from the mailbox gets one helper. The helper does all the chores for that letter, then puts a done sticker on the board. If something breaks, the helper erases the chores and puts the letter back.

Practice Exercises

Exercise 1

Decide MPP versus BMP for a queue averaging 10 messages per second with 200 ms IMS processing each.

Exercise 2

Write rollback behavior for coordinated versus uncoordinated MQ on IMS abend.

Exercise 3

List monitoring metrics for IMS and MQ jointly during a cutover weekend.

Frequently Asked Questions

Test Your Knowledge