HP 3000 developer on retainer: CLMPROC DBOPEN CLAIMDB mode 5 exclusive not closed on validation error STOP RUN — IMAGE error 53 blocks BATCHCLM overnight batch — HP 3000 developer, MPE/iX developer, TurboIMAGE developer on monthly retainer

HP 3000 Series 969 • MPE/iX 7.5 • TurboIMAGE/SQL • CLAIMDB • DBOPEN mode 5 without DBCLOSE • IMAGE error 53 • DBUTIL RESETLOCK • retainer billing

At Pacific Northwest Health Plan, the overnight claims batch job BATCHCLM began failing monthly with a terse error message in its job log: DBOPEN STATUS = 53 : DATABASE LOCKED FOR EXCLUSIVE ACCESS. BATCHCLM needed shared read-write access to the TurboIMAGE database CLAIMDB to process overnight claim adjudication. It was getting IMAGE error 53 — which meant another program had opened CLAIMDB in exclusive mode and had not properly closed it. The problem occurred 3–8 times per month, always after a daytime run of the CLMPROC claims processing program. Operations staff learned to call the HP 3000 retainer developer each time, who would run DBUTIL to clear the stuck exclusive lock before BATCHCLM could proceed. For eighteen months, no one had traced it to the root cause.

When the retainer developer was finally given access to review CLMPROC’s source code, the problem became obvious in minutes: CLMPROC called DBOPEN with access mode 5 (exclusive read/write) at program startup, but three of its four error exit paths called STOP RUN without first calling DBCLOSE. Each time one of those error paths triggered, the TurboIMAGE database dictionary recorded CLAIMDB as still exclusively open — and kept recording it that way until DBUTIL was run to manually reset the lock flag.

TurboIMAGE DBOPEN modes and the exclusive access constraint

TurboIMAGE (later marketed as HP IMAGE/SQL) is the native hierarchical database system for HP 3000 and MPE/iX. It organises data in root datasets (master datasets with unique keys) and detail datasets (child records linked to master records). Application programs access TurboIMAGE through a set of IMAGE intrinsics — DBOPEN, DBCLOSE, DBGET, DBPUT, DBDELETE, DBLOCK, DBUNLOCK — which are called from COBOL/II, SPL, or FORTRAN programs on MPE/iX.

The DBOPEN intrinsic accepts an access mode parameter that determines the level of concurrency allowed while the database is open:

• Mode 1 — Read-only shared. Multiple programs can open the database simultaneously in mode 1 or mode 2. No updates are permitted.
• Mode 2 — Read/write shared. Multiple programs can open in mode 1 or mode 2 simultaneously. Updates are allowed with record-level locking via DBLOCK/DBUNLOCK. This is the standard mode for multi-user update programs.
• Mode 3 — Exclusive read-only. No other program can open the database while this mode is active.
• Mode 5 — Exclusive read/write. No other program can open the database in any mode while this mode is active. Used by programs that require exclusive control over all database access — typically large batch reorganisation or update programs where concurrent access would produce inconsistent results.

When a program calls DBOPEN with mode 5, TurboIMAGE sets an exclusive open flag in the database dictionary file (CLAIMDB.DBDICT on the MPE/iX volume). This flag persists until the program calls DBCLOSE, at which point TurboIMAGE clears the flag. If the program terminates without calling DBCLOSE — via STOP RUN, a program exception, or an MPE/iX job abort — the dictionary flag is not automatically cleared. MPE/iX closes the underlying OS file descriptors on job termination, but TurboIMAGE’s dictionary flag is a separate application-level record that the OS cleanup routine does not touch. Any subsequent attempt to call DBOPEN on that database receives IMAGE error 53 until DBUTIL manually resets the flag.

CLMPROC: DBOPEN mode 5 with four STOP RUN exits, three missing DBCLOSE

CLMPROC was a COBOL/II batch program in CLMLIB.CLMPUB that processed a daily EDI claim submission file for Pacific Northwest Health Plan. It opened CLAIMDB exclusively (mode 5) to prevent BATCHCLM or any other program from accessing the claim master records while CLMPROC loaded and validated the day’s submissions. The relevant structure:

WORKING-STORAGE SECTION.
    01 DB-STATUS    PIC S9(5) BINARY.
    01 DB-MODE      PIC S9(5) BINARY  VALUE 5.
    01 CLM-STATUS   PIC XX.
    01 CLM-NUM      PIC X(12).

PROCEDURE DIVISION.

1000-INIT.
    CALL INTRINSIC "DBOPEN" USING CLAIMDB, "CLMPASS ", DB-MODE, DB-STATUS
    IF DB-STATUS NOT EQUAL 0
        DISPLAY "DBOPEN FAILED STATUS=" DB-STATUS
        STOP RUN                     *> EXIT A: safe — open failed, no lock held

2000-PROCESS.
    PERFORM 3000-READ-CLAIM UNTIL END-OF-FILE

    CALL INTRINSIC "DBCLOSE" USING CLAIMDB, "CLMPASS ", DB-STATUS
    STOP RUN.                        *> Normal path: DBCLOSE called before STOP RUN

3000-READ-CLAIM.
    READ EDI-INPUT AT END SET END-OF-FILE TO TRUE
                   NOT AT END PERFORM 4000-VALIDATE-CLAIM
    END-READ.

4000-VALIDATE-CLAIM.
    MOVE CLM-INPUT-STATUS TO CLM-STATUS
    MOVE CLM-INPUT-NUM    TO CLM-NUM

    IF CLM-STATUS = 'DU'            *> Duplicate claim
        DISPLAY "DUPLICATE CLM " CLM-NUM
        STOP RUN                    *> EXIT B: BUG — DBCLOSE not called

    IF CLM-STATUS = 'IN'            *> Invalid claim code
        DISPLAY "INVALID CLM " CLM-NUM
        STOP RUN                    *> EXIT C: BUG — DBCLOSE not called

    IF CLM-STATUS = 'MF'            *> Past timely filing limit
        DISPLAY "PAST FILING " CLM-NUM
        STOP RUN                    *> EXIT D: BUG — DBCLOSE not called

    PERFORM 5000-LOAD-CLAIM.

5000-LOAD-CLAIM.
    CALL INTRINSIC "DBPUT" USING CLAIMDB, "CLMHDR ", CLM-KEY, CLM-DATA, DB-STATUS
    IF DB-STATUS NOT EQUAL 0
        DISPLAY "DBPUT FAILED STATUS=" DB-STATUS
        STOP RUN                    *> EXIT E: BUG — DBCLOSE not called

Exit A (DBOPEN failure) is safe — if DBOPEN itself fails, the database is not open and no DBCLOSE is needed. But exits B, C, D, and E all call STOP RUN without first calling DBCLOSE. On any of these exits, MPE/iX terminates the CLMPROC job, closes all OS-level file handles, but leaves the TurboIMAGE CLAIMDB dictionary flag set to “exclusively open by CLMPROC.”

The next scheduled run of BATCHCLM — which called DBOPEN(CLAIMDB, CLMPASS, 2) for shared read-write access — encountered IMAGE error 53 at its DBOPEN call and aborted. BATCHCLM was designed to stop immediately on any non-zero DBOPEN status, so operations had a failed batch job with a cryptic status code and no claim adjudication output for that night.

DBUTIL INFO: confirming the stuck exclusive lock flag

The diagnostic procedure was DBUTIL, TurboIMAGE’s database administration utility. Invoked from the MPE/iX command interpreter:

:RUN DBUTIL.PUB.SYS

HP IMAGE/SQL DBUTIL  B.06.15  (C) HEWLETT-PACKARD 2003

DBUTIL> INFO CLAIMDB.CLMLIB

DATABASE : CLAIMDB
LOCATION : CLMLIB.CLMPUB
VERSION  : B.06.15
STATUS   : LOCKED (EXCLUSIVE OPEN, MODE 5)
OWNER    : JOB CLMPROC (CLMLIB.CLMPUB) - TERMINATED ABNORMALLY
OPENED   : 2026-10-14 14:37:22
CLOSED   : NOT CLOSED

DATASETS:
  CLMHDR   (MASTER)   230,847 RECORDS   INTEGRITY: OK
  CLMDETL  (DETAIL)   1,204,319 RECORDS INTEGRITY: OK

DBUTIL>

The INFO output confirmed the diagnosis: CLAIMDB was locked in exclusive mode (mode 5) by CLMPROC, which had terminated abnormally at 14:37:22 the previous day. The database had never been closed. The structural integrity check (CLMHDR and CLMDETL both showing INTEGRITY: OK) confirmed that no data corruption had occurred — only the lock flag needed to be cleared.

The recovery command:

DBUTIL> RESETLOCK CLAIMDB.CLMLIB

CLAIMDB: EXCLUSIVE LOCK FLAG CLEARED
CLAIMDB: STATUS = CLOSED

DBUTIL> INFO CLAIMDB.CLMLIB

DATABASE : CLAIMDB
LOCATION : CLMLIB.CLMPUB
STATUS   : CLOSED
OWNER    : NONE

DBUTIL> EXIT

:

After RESETLOCK, BATCHCLM could be resubmitted. Its DBOPEN(CLAIMDB, CLMPASS, 2) returned IMAGE status 0 (success). Claim adjudication ran cleanly. The retainer developer documented the recovery and scheduled the root cause analysis for the next session.

Why RESETLOCK was needed 3–8 times per month

The DU (duplicate) and IN (invalid) status codes that triggered exits B and C came from a specific EDI trading partner — a regional hospital network that occasionally submitted out-of-sequence claim batches. When a resubmitted claim duplicated an already-loaded record, CLMPROC received CLM-STATUS = ‘DU’ and called STOP RUN. The MF (past timely filing) exit fired on claims older than 90 days, which arrived 2–3 times per month from delayed paper-to-EDI conversion. The DBPUT failure exit (exit E) triggered rarely but occasionally on database space issues during large submission batches.

Each occurrence followed the same pattern: CLMPROC ran during business hours (scheduled at 13:00), hit one of the four error exits without DBCLOSE, and left CLAIMDB locked. BATCHCLM ran at 22:00 and got IMAGE error 53. Operations staff discovered the failure at 06:00 morning review, escalated to the HP 3000 retainer, who ran DBUTIL INFO + RESETLOCK (~30 minutes), and BATCHCLM was manually rerun. Eighteen months of this pattern, 3–8 incidents per month, averaging 0.5 retainer hours each: approximately 36–96 hours of recurring retainer work for a problem that required 1.5 hours to fix permanently.

The fix: DBCLOSE before every STOP RUN on error exit paths

The fix is adding a CALL INTRINSIC "DBCLOSE" before each STOP RUN on exits B through E. Because exit A (DBOPEN failure) means CLAIMDB was never successfully opened, DBCLOSE must not be called on that path — calling DBCLOSE on a database that was never opened produces IMAGE error 40. The corrected program:

4000-VALIDATE-CLAIM.
    MOVE CLM-INPUT-STATUS TO CLM-STATUS
    MOVE CLM-INPUT-NUM    TO CLM-NUM

    IF CLM-STATUS = 'DU'
        DISPLAY "DUPLICATE CLM " CLM-NUM
        CALL INTRINSIC "DBCLOSE" USING CLAIMDB, "CLMPASS ", DB-STATUS  *> Added
        STOP RUN

    IF CLM-STATUS = 'IN'
        DISPLAY "INVALID CLM " CLM-NUM
        CALL INTRINSIC "DBCLOSE" USING CLAIMDB, "CLMPASS ", DB-STATUS  *> Added
        STOP RUN

    IF CLM-STATUS = 'MF'
        DISPLAY "PAST FILING " CLM-NUM
        CALL INTRINSIC "DBCLOSE" USING CLAIMDB, "CLMPASS ", DB-STATUS  *> Added
        STOP RUN

    PERFORM 5000-LOAD-CLAIM.

5000-LOAD-CLAIM.
    CALL INTRINSIC "DBPUT" USING CLAIMDB, "CLMHDR ", CLM-KEY, CLM-DATA, DB-STATUS
    IF DB-STATUS NOT EQUAL 0
        DISPLAY "DBPUT FAILED STATUS=" DB-STATUS
        CALL INTRINSIC "DBCLOSE" USING CLAIMDB, "CLMPASS ", DB-STATUS  *> Added
        STOP RUN

Additionally, a 9000-CLEANUP paragraph was added as a defensive measure and called from a global error handling routine, so that any future COBOL/II runtime exception not caught by the explicit IF checks would also close CLAIMDB before terminating:

9000-CLEANUP.
    IF DB-OPEN-FLAG = 'Y'          *> WS flag set 'Y' after successful DBOPEN
        CALL INTRINSIC "DBCLOSE" USING CLAIMDB, "CLMPASS ", DB-STATUS
        MOVE 'N' TO DB-OPEN-FLAG
    END-IF
    STOP RUN.

After recompiling CLMPROC with COBOL/II and deploying to CLMLIB.CLMPUB, the retainer developer ran five test scenarios against a test database: one normal completion, one DU exit, one IN exit, one MF exit, and one simulated DBPUT failure. After each error-path test, DBUTIL INFO confirmed the database was in CLOSED status. The fix was deployed to production at the next scheduled CLMPROC maintenance window. Over the following three months: zero IMAGE error 53 incidents, zero emergency DBUTIL RESETLOCK sessions, zero BATCHCLM overnight failures attributable to CLMPROC lock residuals.

How HourTab helps HP 3000 retainer developers

The Pacific Northwest Health Plan engagement divided across two phases. Phase 1 (recurring RESETLOCK sessions, 18 months): approximately 36–96 one-off sessions of 0.5 hours each — DBUTIL INFO confirming the lock, DBUTIL RESETLOCK clearing it, BATCHCLM manual rerun confirmation. Phase 2 (root cause fix, one session): 0.5h BATCHCLM error log review, 0.5h DBUTIL INFO diagnosis, 0.5h DBUTIL RESETLOCK recovery, 1.5h CLMPROC source review tracing all four error exit paths, 1.5h COBOL/II fix (four DBCLOSE calls plus 9000-CLEANUP paragraph), 1.0h regression test (five scenarios, DBUTIL INFO after each), 0.5h documentation = 6.0h.

In a HourTab retainer log, phase 2 reads: “CLMPROC DBOPEN-without-DBCLOSE root cause fix: DBUTIL INFO confirmed CLAIMDB LOCKED EXCLUSIVE MODE 5, owner CLMPROC terminated; IMAGE error 53 source traced to 4 error exit STOP RUN calls without DBCLOSE in 4000-VALIDATE-CLAIM and 5000-LOAD-CLAIM (DU, IN, MF, DBPUT-failure paths); fix: added CALL INTRINSIC DBCLOSE before each STOP RUN on exits B–E; added 9000-CLEANUP paragraph with DB-OPEN-FLAG guard; recompile + 5 test scenarios + DBUTIL INFO post-each: all CLOSED; zero IMAGE error 53 incidents since deployment; 6.0h.” The health plan’s IT director can compare this 6-hour fix session against the 18 months of 0.5-hour RESETLOCK sessions it replaced, and immediately see the retainer’s value.

HourTab turns a time-tracker CSV into a public retainer-hours URL your client can bookmark — no login, no portal, no “how many hours do I have left?” emails. Free for one retainer. $9/mo for up to ten.

FAQ: HP 3000 developer retainers

See also: COBOL developer retainer · IMS DB developer retainer · Btrieve developer retainer