Blog › ICP guides

IMS DB developer on retainer: IMS BMP CLMPAY01 accumulates 3,847 POLICY segment exclusive locks over 4 hours 45 minutes without IMS checkpoint — IBM IMS developer, IMS DB developer on monthly retainer

October 10, 2026 · ~15 min read

An IBM IMS DB developer was maintaining the nightly claims payment batch program for a major property/casualty insurance carrier running on IBM z/OS 2.5 with IBM IMS 15 (subsystem IMSA). The company’s core policy administration and claims system was built on IMS DB — an IBM hierarchical database system where data is organized as a tree of parent and child segments rather than as relational tables. The claims database (DBD name CLAIMS_DB) was a HIDAM (Hierarchical Indexed Direct Access Method) full-function IMS database with three segment types: a root segment POLICY (key field: POLICY_NBR, 8 bytes), a dependent CLAIM segment (key field: CLAIM_NBR, 12 bytes, under POLICY), and a dependent PAYMENT segment (key field: PAYMENT_SEQ, 6 bytes, under CLAIM). The batch program was CLMPAY01 — a COBOL IMS BMP (Batch Message Processing) program that ran nightly to process claims approved for payment during the day: for each POLICY with open CLAIM segments in APPROVED_FOR_PAYMENT status, CLMPAY01 inserted a PAYMENT segment recording the payment amount, date, and check number, and updated the CLAIM segment’s status to PAID. On the night of the incident, CLMPAY01 processed 3,847 policy records, each with one or more approved claims.

IMS DB uses DL/I (Data Language/I) calls as its data access interface. Unlike the SQL interface of Db2, DL/I calls are procedural: a COBOL program issues individual DL/I calls by specifying the call type (GU, GN, GHU, GHN, REPL, DLET, ISRT), the PCB (Program Communication Block) identifying which database and what access authority the program has, the I/O area (the WORKING-STORAGE field into which IMS places the retrieved segment data), and zero or more SSAs (Segment Search Arguments — qualifications such as “retrieve the POLICY segment with POLICY_NBR = ‘POL-2024-08742’”). CLMPAY01 had three PCBs in its PSB (Program Specification Block): CLMPOL (sensitivity to POLICY segment, PROCOPT=A — all operations: read, insert, update, delete), CLMCLM (sensitivity to CLAIM under POLICY, PROCOPT=A), and CLMPMT (sensitivity to PAYMENT under CLAIM, PROCOPT=A). For each policy to be processed, the program issued a GHU (Get Hold Unique) call on the CLMPOL PCB with a qualified SSA for the POLICY_NBR: EXEC DLI GHU USING CLMPOL-PCB SEGMENT(POLICY) INTO(WS-POLICY-SEG) WHERE(POLICY_NBR = :WS-POL-KEY) END-EXEC. The GHU call retrieves the named segment and places it in a hold state — IMS acquires an exclusive DB record lock on the entire hierarchical tree rooted at that POLICY segment, preventing other IMS programs from issuing a GHU (or any update-intent call) on any segment in that POLICY’s hierarchy until the hold is released.

In IMS full-function databases (HDAM, HIDAM, HSAM, HISAM — as opposed to IMS Fast Path DEDB databases), the lock acquired by a GHU call is managed by the IMS Internal Resource Lock Manager (IRLM). The IRLM manages locks at the DB record level for full-function databases: a lock on a POLICY segment locks the entire DB record — the POLICY segment plus all its descendant CLAIM and PAYMENT segments. This DB-record-level locking means that once CLMPAY01 issues GHU on POLICY POL-2024-08742, no other IMS program (batch or online) can read-with-update-intent any segment in that policy’s hierarchy until the lock is released. In IMS, a lock acquired by a GHU call is held until either an IMS CHKP (Checkpoint) call is issued (which commits the current unit of work, releases all held locks, and records a checkpoint in the IMS log for restart purposes) or the IMS program terminates normally (normal STOP RUN or GOBACK, which issues an implicit COMMIT / CHKP for BMP programs) or ABENDs (which triggers IMS BACKOUT, rolling back uncommitted changes and releasing all locks). CLMPAY01 issued GHU calls for all 3,847 policies in sequence, issuing the ISRT and REPL calls for each policy’s CLAIM and PAYMENT segments, but issued no intermediate EXEC DLI CHKP calls between policies. After processing 3,847 policies over 4 hours and 45 minutes, all 3,847 POLICY segment DB record locks were held simultaneously by CLMPAY01’s current IMS unit of work.

At 3:22 AM, three hours into CLMPAY01’s run, the insurance company’s claims department online system received an urgent request. A claims adjuster working the overnight shift was reviewing a high-priority homeowner claim (storm damage, 14 properties in a coastal development) and needed to verify the payment status for policy POL-2024-08742 — one of the 3,847 policies currently locked by CLMPAY01. The adjuster entered the policy number into the CICS/IMS claims maintenance transaction CPMD (Claims Payment Maintenance Display). CPMD was a CICS-attached IMS online MPP (Message Processing Program) — a CICS program that made IMS DL/I calls via the CICS-IMS interface to retrieve IMS database data. The CPMD COBOL program issued a GU (Get Unique, no hold — read-only intent) call: EXEC DLI GU USING CPMD-POL-PCB SEGMENT(POLICY) INTO(WS-POL-DATA) WHERE(POLICY_NBR = :WS-POL-NBR) END-EXEC for POLICY_NBR = ‘POL-2024-08742’. IMS suspended the CPMD thread: the POLICY segment for POL-2024-08742 was held exclusively by CLMPAY01. The CPMD thread waited for the lock. The IMSCONTROL parameter TMTOUT=30 (IMS lock timeout, 30 seconds) governed how long an online MPP could wait for a lock. After 30 seconds, IMS returned PCB status code ‘DC’ to CPMD’s GU call. ‘DC’ is the IMS PCB status code indicating that the DL/I call was rejected because of a deadlock or lock timeout — the resource requested by the call was not available within the TMTOUT period.

The CPMD COBOL program checked the PCB status code after the GU call, as IMS DL/I programming requires. The EVALUATE statement in CPMD’s PROCEDURE DIVISION examined CPMD-POL-PCB-STATUS: EVALUATE TRUE WHEN CPMD-POL-PCB-STATUS = ' ' CONTINUE WHEN CPMD-POL-PCB-STATUS = 'GE' PERFORM POLICY-NOT-FOUND-ROUTINE WHEN CPMD-POL-PCB-STATUS = 'GB' PERFORM END-OF-DATABASE-ROUTINE WHEN OTHER EXEC CICS ABEND ABCODE('DCST') END-EXEC END-EVALUATE. Status code ‘DC’ was not explicitly handled — it fell into the WHEN OTHER clause, which issued EXEC CICS ABEND ABCODE('DCST') END-EXEC. The CICS transaction terminated with user ABEND code DCST. The claims adjuster’s terminal displayed: “CICS system error: DCST. Please contact your system administrator.” The adjuster called the overnight operations help desk. The help desk opened a ticket. This pattern repeated 15 to 20 times per night on nights when CLMPAY01 ran — each occurrence corresponding to an online CPMD query that happened to request a POLICY segment currently locked by CLMPAY01.

IBM IMS DB in 2026: the hierarchical database backbone of insurance, banking, and airlines

IBM IMS (Information Management System) is IBM’s hierarchical database management system for IBM z/OS. IMS DB was introduced by IBM in 1968 as the database for the Apollo Guidance Computer project (developed jointly by IBM, North American Rockwell, and Caterpillar Tractor) and became the dominant database system for large-scale mainframe applications in insurance, banking, airlines, and government through the 1970s and 1980s. IBM IMS 14 entered General Availability in 2014; IBM IMS 15 entered General Availability in 2020 and is the current version. Most major IMS DB installations are running IMS 15 in production and evaluating IMS Connect and z/OS Connect EE for exposing IMS transactions and databases via REST APIs to modern Java and cloud-native applications.

IMS DB remains in active production at organizations whose core business systems were built on IMS in the 1970s and 1980s and whose data volume, transaction throughput, and RAS (reliability, availability, serviceability) requirements justify continuing the platform. Major U.S. property/casualty and life insurance carriers use IMS DB for policy administration (POLICY → COVERAGE → CLAIM → PAYMENT hierarchies with hundreds of millions of segment instances), major U.S. commercial banks use IMS DB for demand deposit account processing (CUSTOMER → ACCOUNT → TRANSACTION hierarchies), and major airlines use IMS DB for reservation systems (FLIGHT → SEAT → RESERVATION → PASSENGER hierarchies). An IMS DB developer on monthly retainer for an insurance carrier’s claims platform maintains: the IMS COBOL and PL/I DL/I programs that process claims (CLMPAY01 and its siblings — CLMINQ01 for inquiry, CLMUPD01 for status updates, CLMRPT01 for reporting data extraction); the DBD and PSB definitions that describe the database structure and program access authority; the IMS utilities for database reorganization and recovery; and the IMS checkpoint and restart strategy for batch programs.

The IMS CHKP (Checkpoint) call is the mechanism for releasing held locks and committing the current unit of work in an IMS BMP program. When CLMPAY01 issues EXEC DLI CHKP USING CLMPAY01-IOPCB CHKP-PARMS END-EXEC, IMS performs three actions simultaneously: it commits the current unit of work (the ISRT and REPL calls issued since the last CHKP are made permanent in the database), it releases all DB record locks held since the last CHKP (the GHU exclusive locks on the 500 POLICY segments processed in this batch are released, allowing other programs to access those segments), and it writes a checkpoint record to the IMS log (the IMS SLDS log dataset) recording the program’s current position in the database. The checkpoint record in the IMS log enables the program to restart from the most recent checkpoint if it ABENDs mid-run: the restart version of CLMPAY01 issues EXEC DLI XRST USING CLMPAY01-IOPCB XRST-AREA END-EXEC at program start, which reads the most recent checkpoint record from the IMS RECON (recovery control) dataset and repositions the program to continue from the policy after the last committed checkpoint, rather than reprocessing the entire 3,847-policy run from scratch. Without any CHKP calls, an ABEND of CLMPAY01 mid-run forces a complete restart from the beginning — all 3,847 policies must be reprocessed, regardless of how many were successfully processed before the ABEND.

IMS DL/I lock diagnosis: /DISPLAY ACTIVE, IMSCONTROL TMTOUT, and IMS log analysis

The IMS operator command /DISPLAY STATUS PROG CPMD shows the current scheduling status of the CPMD program. After a CICS ABEND DCST, the CPMD program may show NOTSCHD (not scheduled — the program has been taken offline after repeated ABEND occurrences). The command /DISPLAY ACTIVE TRAN CLMPAY01 shows the active BMP CLMPAY01 program, including its current status (ACTIVE), elapsed time, and database name. The combination of CPMD NOTSCHD and CLMPAY01 ACTIVE for 4+ hours immediately suggested that an online program was being blocked by the batch program. The IMS SLDS (System Log Data Set) log analysis confirmed the absence of intermediate checkpoint records: the IMS developer scanned the IMS log for CLMPAY01 checkpoint records (IMS log record type X’37’ = checkpoint record) using the DFSERA10 IMS log print utility and found zero CHKP records for CLMPAY01 between the program start record (X’07’ = program start) and the in-progress execution marker — confirming that no intermediate CHKP calls had been issued.

The IMSCONTROL parameter TMTOUT governs how long an IMS online MPP (or other online IMS thread type) waits for a locked resource before receiving status code ‘DC’. The insurance carrier had TMTOUT=30 (30 seconds). This value was chosen to balance responsiveness (online CSRs should not wait more than 30 seconds for a screen response) against false positives (brief lock conflicts during normal batch/online overlap should not cause premature DC returns). With TMTOUT=30, any POLICY segment locked by CLMPAY01 for more than 30 seconds was inaccessible to online MPP programs. Since CLMPAY01 held locks for 4 hours and 45 minutes, effectively every POLICY segment processed in the first 4 hours was locked and inaccessible for the majority of its online processing window. The 15 to 20 DCST ABENDs per night represented online CPMD queries that happened to request exactly those policies — the ones already processed by CLMPAY01 and locked in its unit of work.

The root cause analysis confirmed that CLMPAY01 was designed without intermediate CHKP calls because the original developer assumed the program would run in a nightly batch window with no concurrent online access (IMS was traditionally a full-batch-offline / full-online-online split at the early insurance carrier: no online access while batch ran). In 2019, the insurance carrier extended online operations to 24/7 to support a new mobile claims app (policyholders can open and check claims from their phones). The nightly CLMPAY01 batch window now overlapped with online operations. The program was never updated to add intermediate CHKP calls. The fix: add EXEC DLI CHKP USING CLMPAY01-IOPCB CHKP-PARMS END-EXEC after every 500 POLICY records processed, with a restart table (CLMPAY01-RESTART-CTL) to store the last checkpointed POLICY_NBR. The CHKP call commits the 500-policy unit of work, releases the 500 GHU exclusive locks, writes the checkpoint to the IMS log (RECON updated), and resumes at the next POLICY. Maximum concurrent GHU locks: 500. Average lock hold time per POLICY at 500-policy batches: approximately 8 minutes (500 policies at CLMPAY01’s average processing rate of ~63 policies per minute). CPMD DCST ABEND rate after fix: 0.

Typical IBM IMS DB developer retainer work and what it looks like in a work log

IMS BMP batch program accumulating GHU exclusive locks without intermediate CHKP calls is the canonical invisible IMS locking bug for any organization that ran IMS in a full-batch-offline model before extending to 24/7 online operations. It appears in IMS retainer work logs for insurance carrier nightly claims payment batch programs (POLICY root segment GHU during claims payment processing without CHKP), bank nightly account posting BMP programs (CUSTOMER root segment GHU during account balance posting without CHKP), airline nightly reservation status batch programs (FLIGHT root segment GHU during schedule update without CHKP), and government agency benefit payment BMP programs (RECIPIENT root segment GHU during payment generation without CHKP). The work log entry: “IBM IMS 15 IMSA; CLMPAY01 IMS BMP COBOL; PSB CLMPAY01 PCBs CLMPOL/CLMCLM/CLMPMT PROCOPT=A; GHU POLICY_PCB POLICY_NBR='POL-*' loop for 3,847 policies; ISRT PAYMENT, REPL CLAIM after each GHU; no EXEC DLI CHKP between policies; all 3,847 POLICY segment GHU exclusive DB record locks accumulated 4h 45m; online MPP CPMD GU POLICY_PCB POLICY_NBR='POL-2024-08742' — IMS status 'DC' after TMTOUT=30s; CPMD handles ' ' and 'GE' not 'DC'; WHEN OTHER EXEC CICS ABEND ABCODE('DCST'); DCST rate: 15–20/night; /DISPLAY STATUS PROG CPMD: NOTSCHD; /DISPLAY ACTIVE TRAN CLMPAY01: ACTIVE 4h+; SLDS log DFSERA10: zero X'37' CHKP records for CLMPAY01; fix: EXEC DLI CHKP every 500 policies; XRST warm restart support; max concurrent GHU locks: 500; DCST rate 0; hours: 3h + 4h COBOL + 2h test.”

IMS DB status code ‘GE’ (segment not found) returned after REORG changes HDAM synonyms is the most common IMS operational bug following a database reorganization. After an IMS HDAM (Hierarchical Direct Access Method) database reorganization that changes the FSPC (free space percentage) parameter in the REORG utility parameters, the IMS randomizing module distributes root segments differently, which can change the synonym chain for specific POLICY_NBR keys. If the randomizing module for the CLAIMS_DB HDAM is configured with an overly small root anchor point area (RAPA) relative to the actual number of root segments, a high proportion of root segments become synonyms (segments that hash to the same root anchor point and must be stored in overflow). After REORG, segments that were previously accessible via a two-I/O direct access (hash → anchor point → root) may now require four to six I/Os (hash → anchor point → first synonym → second synonym → root) due to increased synonym chain length. This causes GHU calls to return GE (segment not found) when the synonym chain is broken by a REORG parameter error — specifically if REORG REPLACE was used with incorrect HDAM RAPA parameters that shortened the anchor point area relative to the pre-REORG configuration. Work log: “IMS 15 IMSA; CLAIMS_DB HDAM REORG REPLACE with RAPA=48000 (previous RAPA=72000 — incorrect parameter in REORG JCL after DBA error); post-REORG CLMPAY01 GHU POLICY_NBR='POL-2024-00001' through 'POL-2024-03000' returning PCB status 'GE' (not found); root cause: RAPA reduction caused synonym chain overflow — DFSURGU0 unload confirms all 3,847 POL records exist in unload file; IMS /DISPLAY DB CLAIMS_DB AREA shows HD REORGANIZATION REQUIRED; fix: REORG REPLACE with RAPA=72000 (restored correct parameter); GHU status ' ' (success) restored for all 3,847 POLICY records; hours: 2h diagnosis + 4h REORG re-run.”

IMS DEDB (Data Entry Database) Fast Path area I/O bottleneck from excessive unit-of-work size is the most common IMS Fast Path performance retainer issue for organizations that use DEDB for high-throughput online transaction processing (airline seat reservations, bank ATM processing, insurance quote engines). A DEDB area’s throughput is limited by the UOW (Unit of Work) commit frequency: each UOW commit writes all modified CIs (Control Intervals) for that UOW to the DEDB OLDS (Online Log Data Set). If a CICS-attached DEDB program issues 500 ISRT calls per UOW before SYNCPOINT, the SYNCPOINT must write 500 CIs to the OLDS — a single I/O burst that delays all other UOWs waiting for the OLDS write. Work log: “IMS 15 IMSA; SEATRSV DEDB CICS-attached MPP; RESV_AREA DEDB; CICS SYNCPOINT after every 500 seat ISRTs (program design from 2008 when DEDB had sequential I/O); 500-CI OLDS burst at SYNCPOINT: 2.4-second OLDS drain visible in IMS log X'4B' records; airline seat query throughput 340 TPS → 85 TPS during SYNCPOINT bursts; fix: SYNCPOINT every 20 ISRTs; OLDS burst: 2.4s → 0.11s; throughput 340 TPS restored; hours: 2h DEDB log analysis + 1.5h COBOL SYNCPOINT repositioning.”

How HourTab tracks IBM IMS DB developer retainer hours

The CLMPAY01 BMP-without-CHKP bug is invisible in batch testing by the same mechanism that makes all lock accumulation bugs invisible when only one program runs at a time. The IMS developer who wrote CLMPAY01 originally designed it for the pre-2019 operational model: nightly batch window, no concurrent online access, entire IMS system in batch mode while CLMPAY01 ran. In that model, the absence of CHKP calls was an optimization — each CHKP call involves writing to the IMS log, updating the RECON dataset, and suspending the program briefly. Without CHKP, CLMPAY01 ran slightly faster and the code was simpler (no restart table, no XRST at program start). The program ran correctly for 6 years with zero issues. In 2019, when the carrier extended online operations to 24/7 to support the mobile app, the operations team added CLMPAY01 to a new overnight batch schedule that ran concurrently with the online CICS/IMS system. No one reviewed CLMPAY01 for CHKP design. The DCST ABEND pattern emerged immediately but was treated as a “batch and online overlap issue” that operations worked around by restricting overnight claims adjuster access to certain policy ranges during the batch window. The workaround lasted 4 years before a claims manager escalated the issue as impacting fraud response SLAs.

The work log entry that makes IMS BMP lock accumulation work auditable must name every element of the causal chain: the IMS version and subsystem (IMS 15, IMSA), the program type (BMP — Batch Message Processing), the PSB and PCB names (CLMPAY01, CLMPOL/CLMCLM/CLMPMT PROCOPT=A), the DL/I call type (GHU — exclusive lock), the lock accumulation count (3,847 POLICY segment locks over 4 hours 45 minutes), the absence of CHKP calls (confirmed via SLDS log DFSERA10 scan), the TMTOUT parameter value (30 seconds), the blocked online program (CPMD MPP), the IMS status code (‘DC’), the CICS ABEND code and frequency (DCST, 15–20/night), the fix (EXEC DLI CHKP every 500 policies, XRST warm restart support), the maximum post-fix lock accumulation (500 POLICY segments), and the zero-ABEND outcome. A log that says “added IMS checkpoint to batch program, 7h” is not auditable to the insurance carrier’s IT operations director who needs to explain to the fraud team why 4 years of overnight claims access restrictions were caused by a single program design decision. HourTab gives IBM IMS DB developers a public retainer-hours URL they send to clients — insurance carriers, banks, airlines, and government agencies that run critical nightly IMS batch programs and 24/7 online IMS transaction systems maintained by an IMS specialist on monthly retainer.

The broader context for IBM IMS DB retainer billing is that an IMS BMP accumulating thousands of GHU exclusive locks without intermediate CHKP calls is the IMS hierarchical database instantiation of the same principle that drives every exclusive lock retainer engagement in this mainframe stack. IBM Db2 developer retainers cover the same pattern at the relational layer: INVUPD01 FOR UPDATE OF cursor accumulating 847,000 Db2 X locks without intermediate COMMIT over 3.5 hours, blocking CICS WPQA queries with SQLCODE -911 — relational database X lock, same root cause. CICS developer retainers cover the same pattern at the CICS application layer: ACMAINT conversational READ UPDATE holding VSAM exclusive record lock for 23 minutes during CSR interaction — VSAM record lock, same pattern. JCL developer retainers cover the same pattern at the z/OS dataset allocation layer: PREMBIL1 STEP020 DISP=OLD holding z/OS ENQ EXCLUSIVE for 63 minutes, blocking PREMRPT1 STEP010 for 61 minutes — z/OS dataset lock, same class of problem. Each layer of the IBM z/OS mainframe stack demands that long-running exclusive reservations be released periodically: DISP=OLD corrected to DISP=SHR in JCL; EXEC SQL COMMIT WORK every 1,000 rows in Db2 batch; EXEC CICS RETURN (pseudo-conversational) instead of EXEC CICS RECEIVE MAP (conversational) in CICS; and EXEC DLI CHKP every 500 segments in IMS BMP.

FAQ: IBM IMS DB developer retainers