IMS- BMP MPP

IMS runs application programs in different region types. You have already met the MPP (online message processing). Its batch cousin is the BMP (Batch Message Processing) region: a batch job that can access online IMS databases and even the message queues, with checkpoint/restart for recoverability. This module compares the region types and shows BMP checkpoint processing with real code.

Region types at a glance

• MPP (Message Processing Program): online; scheduled by IMS DC per transaction; driven by input messages; commits at each message end; ends with GOBACK on QC.
• BMP (Batch Message Processing): batch JCL; accesses the same online databases (and optionally message queues) as MPPs; runs to completion; uses CHKP/XRST for restart.
• DLI batch region: pure batch access to IMS databases while IMS DC is down or for offline databases; no message queues.
• JMP / IFP: Java Message Processing and Fast Path regions for Java workloads and Fast Path (DEDB/EMH) transactions.
• One PSB can often serve both an MPP and a BMP version of the same logic; the difference is the region and how input is obtained.

BMP vs MPP

• Scheduling: MPP is scheduled by IMS DC when a message arrives; BMP is submitted as a batch job and runs immediately.
• Input: MPP reads input messages via GU to the IO-PCB; BMP typically reads sequential files or GSAM, but can also GU the message queue.
• Commit scope: MPP commits per message; BMP commits at each CHKP call (or at program end).
• Restart: MPP restart is message-level (reprocess the message); BMP restart uses XRST to resume from the last checkpoint.
• Throughput vs duration: MPPs are short-lived and numerous; a BMP can run for hours, which is exactly why checkpoints matter.

Why checkpoints: the problem they solve

• A BMP updating a million segments that abends at 99 percent without checkpoints must restart from the beginning.
• CHKP tells IMS: commit everything so far and remember this point. IMS assigns a checkpoint id and saves up to 7 program data areas.
• On restart, XRST (the first DL/I call in the program) restores the saved data areas, so the program resumes after the last checkpoint instead of at the start.
• Checkpoint too rarely and restart redoes hours of work; checkpoint too often and CHKP overhead slows the job. Every few thousand updates is a common starting point.

Example: BMP with CHKP and XRST

• This BMP reads COURSE segments sequentially, updates MARKS, and checkpoints every 1000 updates. SAVE-AREA holds the restart position.

• After each CHKP, IMS returns the new checkpoint id in CHKP-ID-AREA. Write it to the job log - operators need it for restart.
• At restart, IMS restores SAVE-AREA (LAST-STUDID, UPDATE-COUNT), so processing continues after the last committed segment.
• The program logic must be restartable: it skips segments up to LAST-STUDID instead of reprocessing them. Design the SSA or key logic so repositioning is exact.

BMP execution JCL

• A BMP runs under the IMS region controller DFSRRC00 with PARM='BMP,program,psb'. Key data sets vary by shop; the skeleton below shows the required pieces.

• PARM='BMP,PAYBMP,STUPSB' means: BMP region, program PAYBMP, PSB STUPSB.
• The SYSIN checkpoint id (here 00000012) is read by the program into WS-RESTART-ID for XRST. Leave it blank (or omit) for a cold start.
• Database DD names (STUDDD1) must match the DD1= names in the DBD.

ROLL, ROLS and SYNC

• ROLL: backs out all database changes since the last commit point (last CHKP in BMP, last message in MPP).
• ROLS: sets a rollback savepoint; a later ROLL backs out only to the most recent ROLS.
• SYNC: forces a commit point immediately, without taking a checkpoint id.
• Use ROLL when a BMP encounters bad data it cannot process: back out the partial unit of work, log the record, and continue with the next one.