Blog › ICP guides

FOCUS developer on retainer: CLMPST MAINTAIN FILE CLAIMHST opens VSAM ESDS with exclusive lock — 28 analysts cannot run TABLE FILE CLAIMHST reports for 3 hours 47 minutes — FOCUS developer, Information Builders WebFOCUS developer, ibi WebFOCUS developer on monthly retainer

October 10, 2026 · ~15 min read

A FOCUS developer was maintaining the claims history processing system for a mid-size property/casualty insurance carrier running on IBM z/OS 2.5, using FOCUS 7.3 for MVS/ESA as the 4GL (fourth-generation language) for all reporting and data management operations. FOCUS — developed by Information Builders, Inc. (IBI) starting in 1975 — was the company’s primary tool for claims data extraction, reporting, and batch data maintenance. The carrier had 28 claims analysts who used FOCUS TABLE procedures running in TSO (Time Sharing Option) sessions to query and report on claims history data throughout the business day. The claims history was stored in a FOCUS native file called CLAIMHST — a proprietary FOCUS database file stored as a VSAM ESDS (Entry-Sequenced Data Set) on disk, with a physical dataset name of MIDATLAN.CLAIMS.HISTORY.FOC. FOCUS manages its own internal indexing and record structure within the VSAM ESDS container. Each month, a FOCUS MAINTAIN procedure called CLMPST.FEX ran to post the monthly claims status updates: for 182,000 open claim records, CLMPST validated eligibility, computed settlement amounts, and updated each claim’s status field to POSTED or DENIED. On a Tuesday morning at 9:00 AM, the operations team received a wave of help desk tickets: all 28 analysts were getting a FOCUS error when they tried to run any report against CLAIMHST.

The FOCUS error message was: (FOC) CANNOT OPEN FILE: CLAIMHST - FILE IS LOCKED — FOCUS message code FOC02200. In FOCUS, this error occurs when a FOCUS task (a TABLE report procedure, a MAINTAIN procedure, or any other FOCUS access) attempts to open a FOCUS native file for which another FOCUS task already holds an exclusive write lock. FOCUS native files use VSAM ESDS as their physical storage layer, and when a FOCUS MAINTAIN procedure opens a FOCUS native file for update operations, FOCUS acquires a VSAM exclusive lock on the ESDS dataset that prevents any other FOCUS task from opening the same file for any access — read or write. The claims analysts’ TABLE FILE CLAIMHST procedures were read-only report requests, but FOCUS’s VSAM locking model under SHAREOPTIONS(1 3) does not distinguish between read-only and write-capable openers for exclusion purposes: if any opener holds the ESDS with write-capable VSAM ACB, no other opener can access the ESDS.

FOCUS MAINTAIN is FOCUS’s data modification language — a procedural sublanguage within FOCUS for updating, inserting, and deleting records in FOCUS native files (and in Db2 or SQL Server tables when using the FOCUS SQL engine). A FOCUS MAINTAIN procedure for CLAIMHST began with the declaration MAINTAIN FILE CLAIMHST, which instructed FOCUS to open CLAIMHST for write (update) access. The MAINTAIN procedure then iterated through claims records using the FOR ALL NEXT CLAIMHST construct — FOCUS’s way of processing all records in a FOCUS file sequentially, similar to a READ loop in COBOL or a FOR ALL NEXT in IMS BMP. For each of the 182,000 claim records, CLMPST.FEX performed eligibility validation, computed amounts, and issued an UPDATE CLAIMHST statement to post the CLAIM_STATUS field. The procedure contained no COMMIT POINT statements. FOCUS MAINTAIN’s COMMIT POINT keyword is the mechanism for releasing the exclusive VSAM lock on the FOCUS native file mid-procedure — it commits the changes made so far to the FOCUS file, releases the exclusive VSAM lock, and then reacquires the lock for the next batch of records. Without COMMIT POINT, FOCUS MAINTAIN holds the exclusive VSAM lock on MIDATLAN.CLAIMS.HISTORY.FOC for the entire 3-hour and 47-minute procedure runtime.

At 9:00 AM, when the claims analysts began their workday and attempted to run FOCUS TABLE reports against CLAIMHST (CLMPST.FEX had started at 8:53 AM — a scheduled run), every TABLE FILE CLAIMHST request received FOC02200 immediately. FOCUS attempted to open MIDATLAN.CLAIMS.HISTORY.FOC for the analyst’s TABLE report. The VSAM ESDS was held exclusively by the CLMPST.FEX MAINTAIN task. FOCUS returned FOC02200 without waiting — FOCUS TABLE procedures do not queue up for a locked file; they fail immediately with FOC02200 and return control to the analyst’s TSO session. Each analyst had to manually retry their procedure periodically, not knowing how long the lock would be held. By 12:40 PM, when CLMPST.FEX finally finished and FOCUS released the VSAM exclusive lock, 28 analysts had collectively lost approximately 112 analyst-hours of productive work time to repeated FOC02200 failures and manual retries.

FOCUS and WebFOCUS in 2026: the reporting and analytics backbone of insurance, government, and financial services

FOCUS (Fully Optimized COmputing System) was developed by Information Builders, Inc. (IBI) in New York, founded by Gerald Cohen and Gerry Weiss in 1975. The first commercial release of FOCUS was in 1975 on IBM MVS mainframes, making it one of the earliest 4GL products to achieve widespread commercial deployment. FOCUS was designed as an English-like language that allowed non-programmers (business analysts, statisticians, actuaries) to write data queries and reports without COBOL programming expertise. The FOCUS 4GL combined a report-writing language (TABLE FILE), a data modification language (MAINTAIN), a master file definition system (MFD), a procedural language (&-variable parameterization, -IF/-GOTO/-INCLUDE branching), and a native hierarchical database (FOCUS native files stored as VSAM ESDS) into a single unified system.

Information Builders released WebFOCUS — the web-enabled successor to FOCUS — in 1996, originally as a CGI-based web front-end to FOCUS procedure execution. WebFOCUS 7.7, 8.0, and 8.2 became the predominant versions in the 2010s and 2020s, and Information Builders rebranded the product as ibi WebFOCUS following the company’s 2021 acquisition by Tibco Software. The FOCUS mainframe product (FOCUS for z/OS, formerly FOCUS for MVS/ESA) has remained in active production at the insurance carriers, state government agencies, and federal agencies that adopted it in the 1980s and 1990s and have never fully migrated to WebFOCUS or other platforms. A FOCUS developer on monthly retainer at a P/C insurance carrier maintains the TABLE report procedures that actuaries use for reserve analysis, the MAINTAIN procedures that batch-post monthly claims status updates, the master file definitions that describe the fields and segments in the FOCUS native claims and policy databases, and the access files that connect FOCUS procedures to the VSAM ESDS datasets and (in modernized installations) Db2 tables.

FOCUS native files are stored as VSAM ESDS (Entry-Sequenced Data Set) physical datasets on z/OS. Unlike VSAM KSDS (which has a key-indexed structure managed by VSAM itself), the VSAM ESDS for a FOCUS file has no VSAM-managed key structure — records are stored in sequential insertion order within the ESDS, and FOCUS manages its own internal index (stored within the ESDS in FOCUS-proprietary format) for keyed access. When FOCUS opens a native file for a TABLE (read-only) operation, FOCUS opens the VSAM ESDS with read-only MACRF. When FOCUS MAINTAIN opens a native file for update operations, FOCUS opens the VSAM ESDS with write-capable MACRF (MACRF including OUT). The VSAM SHAREOPTIONS of the ESDS dataset governs the concurrency implications. MIDATLAN.CLAIMS.HISTORY.FOC had SHAREOPTIONS(1 3) — the same cross-region exclusive-write SHAREOPTIONS as KEYSTONE.BILLING.MASTER in the Easytrieve scenario. Under SHAREOPTIONS(1 3) with a write-capable opener (MAINTAIN), no other opener can access the ESDS.

The FOCUS COMMIT POINT statement, placed within a MAINTAIN procedure’s FOR ALL NEXT loop, performs three actions: it commits all UPDATE/INCLUDE/DELETE operations issued since the last COMMIT POINT (or since MAINTAIN FILE opened) to the FOCUS native file’s VSAM ESDS, it releases the exclusive VSAM write lock on the ESDS, and it then reacquires the VSAM write lock for the next batch of records. While the VSAM lock is momentarily released between COMMIT POINT operations, other FOCUS tasks (TABLE FILE reports from analysts) can open the ESDS and complete their read-only access. The window between COMMIT POINT release and re-acquire is small (typically less than one second for a FOCUS file of this size), but it is sufficient for read-only TABLE procedures to open, read the records they need, and close — since TABLE procedures that read CLAIMHST for a small set of claims (by policy number, claims adjuster, or claim date range) complete in 2–8 seconds for the typical analyst query.

FOCUS MAINTAIN lock diagnosis: FOC.PARM ALTLOG, FOCUS HOLD FILE, and IDCAMS LISTCAT

The FOCUS developer’s diagnostic sequence for the CLAIMHST exclusive lock incident:

Step 1: FOCUS FOC.PARM ALTLOG review. FOCUS logs all file open and close events to the ALTLOG dataset when the ALTLOG system parameter is active. The ALTLOG output for the period 8:53 AM – 12:40 PM showed CLMPST.FEX opening MIDATLAN.CLAIMS.HISTORY.FOC for MAINTAIN at 8:53:07 AM and closing it at 12:40:42 PM — confirming the 3-hour-47-minute exclusive hold. The ALTLOG also showed 847 FOC02200 OPEN FAILED entries for analyst TABLE FILE CLAIMHST attempts during this window, one for each failed TABLE attempt across the 28 analysts (averaging 30 failed attempts per analyst over 3 hours 47 minutes).

Step 2: IDCAMS LISTCAT. IDCAMS LISTCAT CLUSTER(MIDATLAN.CLAIMS.HISTORY.FOC) ALL confirmed SHROPTNS(1-3) — the same VSAM SHAREOPTIONS as the BILLMST cluster, the structural root cause of the exclusive conflict.

Step 3: CLMPST.FEX source review. The developer reviewed the FOCUS procedure source in the FOCEXEC PDS. The MAINTAIN FILE CLAIMHST declaration was followed by a FOR ALL NEXT CLAIMHST loop processing 182,000 records. The loop contained COMPUTE statements for eligibility validation and settlement calculation, and UPDATE CLAIMHST statements for posting. The loop contained no COMMIT POINT statement. At the end of the FOR ALL NEXT loop (after all 182,000 records were processed), a single COMMIT (end-of-procedure implicit commit) closed the MAINTAIN and released the VSAM lock. The developer estimated that with 182,000 records and approximately 3h 47m total runtime, the program processed approximately 48,000 records per hour — meaning COMMIT POINT every 500 records would release the lock approximately every 37 seconds.

The fix: The FOCUS developer added a COMMIT POINT statement inside the FOR ALL NEXT CLAIMHST loop using FOCUS MAINTAIN’s periodic commit syntax:

Original CLMPST.FEX structure:

MAINTAIN FILE CLAIMHST
FOR ALL NEXT CLAIMHST
  COMPUTE ELIG_STATUS = ... <eligibility validation>
  IF ELIG_STATUS EQ 'ELIGIBLE' THEN
    COMPUTE SETTLE_AMT = ... <settlement calculation>
    UPDATE CLAIMHST CLAIM_STATUS WITH 'POSTED' SETTLE_AMOUNT WITH SETTLE_AMT
  ELSE
    UPDATE CLAIMHST CLAIM_STATUS WITH 'DENIED'
  END
END-REPEAT
COMMIT

Fixed CLMPST.FEX structure (with COMMIT POINT every 500 records):

MAINTAIN FILE CLAIMHST
COMPUTE COMMIT_CTR/I5 = 0;
FOR ALL NEXT CLAIMHST
  COMPUTE ELIG_STATUS = ... <eligibility validation>
  IF ELIG_STATUS EQ 'ELIGIBLE' THEN
    COMPUTE SETTLE_AMT = ... <settlement calculation>
    UPDATE CLAIMHST CLAIM_STATUS WITH 'POSTED' SETTLE_AMOUNT WITH SETTLE_AMT
  ELSE
    UPDATE CLAIMHST CLAIM_STATUS WITH 'DENIED'
  END
  COMPUTE COMMIT_CTR = COMMIT_CTR + 1;
  IF COMMIT_CTR EQ 500 THEN
    COMMIT POINT
    COMPUTE COMMIT_CTR = 0;
  END
END-REPEAT
COMMIT

With COMMIT POINT every 500 records, the exclusive VSAM write lock on MIDATLAN.CLAIMS.HISTORY.FOC was released and reacquired 364 times during the 182,000-record run (182,000 / 500 = 364 COMMIT POINT cycles). The maximum exclusive lock hold time between commits was approximately 37 seconds. Analyst TABLE FILE CLAIMHST procedures that attempted to open CLAIMHST during the COMMIT POINT window (approximately 1 second per cycle) could now succeed. In practice, analysts experienced occasional 37-second waits for the current COMMIT POINT window to close, but the FOC02200 CANNOT OPEN FILE error — which previously lasted 3 hours 47 minutes without any opening in the lock — was eliminated. A secondary fix was also applied: CLMPST.FEX was rescheduled from its ad-hoc 9:00 AM manual trigger to a 12:00 AM overnight scheduled execution via CA Workload Automation (formerly CA7), running during the hours when analyst TSO sessions were not active. With both fixes in place, FOC02200 exclusive lock conflicts for CLAIMHST: 28 incidents per monthly run to zero.

Typical FOCUS developer retainer work and what it looks like in a work log

FOCUS MAINTAIN FILE without COMMIT POINT holding exclusive VSAM ESDS lock for hours is the canonical invisible FOCUS locking bug for insurance carriers, state government agencies, and financial institutions that run FOCUS MAINTAIN batch procedures during business hours when analysts are actively running TABLE FILE reports. It appears in FOCUS retainer work logs for P/C insurance claims status posting programs (MAINTAIN FILE CLAIMHST FOR ALL NEXT 182,000 records, no COMMIT POINT, 3h 47m exclusive lock), life insurance policy reserve update programs (MAINTAIN FILE POLRESERV FOR ALL NEXT 847,000 policies, no COMMIT POINT, 8h 12m exclusive lock, entire business day blocked), state government benefit eligibility posting programs (MAINTAIN FILE ELIGMST FOR ALL NEXT 34,000 recipients, no COMMIT POINT, 1h 22m exclusive lock, caseworker report access blocked mid-morning), and bank account classification programs (MAINTAIN FILE ACCTCLASS FOR ALL NEXT 2.1M accounts, no COMMIT POINT, 6h exclusive lock). The work log entry: “FOCUS 7.3 MVS/ESA; procedure CLMPST.FEX; MAINTAIN FILE CLAIMHST; MIDATLAN.CLAIMS.HISTORY.FOC VSAM ESDS SHAREOPTIONS(1-3); MAINTAIN opens CLAIMHST with exclusive write VSAM ACB; no COMMIT POINT in FOR ALL NEXT CLAIMHST loop (182,000 records); exclusive lock held 3h 47m (8:53 AM–12:40 PM); 28 analyst TABLE FILE CLAIMHST procedures receive FOC02200 '(FOC) CANNOT OPEN FILE: CLAIMHST - FILE IS LOCKED'; FOCUS ALTLOG: 847 FOC02200 entries for analyst TSO sessions; IDCAMS LISTCAT CLUSTER(MIDATLAN.CLAIMS.HISTORY.FOC) ALL: SHROPTNS(1-3); fix: COMMIT POINT every 500 records in FOR ALL NEXT loop (COMMIT_CTR counter, IF COMMIT_CTR EQ 500 THEN COMMIT POINT); max exclusive lock hold time: 3h 47m → 37 seconds; also CLMPST.FEX rescheduled to 12:00 AM via CA Workload Automation; FOC02200 rate: 28/month → 0; hours: 2h diagnosis + 1h COMMIT POINT restructure + 0.5h scheduling change + 1h test.”

FOCUS TABLE FILE sort overflow ABEND after FOCUS file reorganization changes record count is the most common FOCUS output failure following a FOCUS native file reorganization. When a FOCUS file is reorganized (using the FOCUS REBUILD utility to compact fragmented VSAM ESDS segments and reconstruct the FOCUS internal index), the record count in the FOCUS file may change if the reorganization removes duplicate or corrupted FOCUS index entries that were being double-counted. FOCUS TABLE procedures that use BY (sort) fields with FOCSORT (the FOCUS sort facility) allocate sort work files based on the record count estimated at procedure start. If the actual sort data volume exceeds the FOCSORT work file allocation (because the FOCUS record count after REBUILD is larger than FOCUS expected from the pre-REBUILD index), FOCUS issues error FOC01730 (SORT OVERFLOW — sort work file exhausted) and the TABLE procedure abends. Work log: “FOCUS 7.3 MVS; procedure CLMRPT.FEX; TABLE FILE CLAIMHST; PRINT CLAIM_NBR CLAIM_STATUS SETTLE_AMT BY POLICY_NBR BY CLAIM_DATE; CLAIMHST FOCUS REBUILD executed to reclaim 847MB of fragmented VSAM ESDS space; post-REBUILD CLAIMHST record count 182,000 → 187,400 (5,400 previously double-counted records now correctly counted — pre-REBUILD index corruption from prior MAINTAIN ABEND); FOCUS TABLE TABLE FILE CLAIMHST: FOC01730 SORT OVERFLOW after 34% of sort completed; FOCSORT work file $FOCWRK1 DISP=NEW allocated 90MB (based on pre-REBUILD 182,000 record estimate); actual sort data 98MB (187,400 records); fix: FOCUS system parameter SORTPGM increased from default DFSORT to DFSORT with SORTALLOC(200M) in FOCPARM; also CLAIMHST FOCUS REBUILD scheduled quarterly with FOCREPORT output reviewed for record count change before next TABLE procedure run; FOC01730 rate: 0; hours: 1.5h diagnosis + 1h FOCPARM SORTALLOC change + 0.5h test.”

WebFOCUS 8.2 data adapter Db2 connection pool exhaustion during concurrent report execution is the most common WebFOCUS performance incident for organizations that migrated FOCUS TABLE reports to WebFOCUS with the Db2 SQL engine adapter. When WebFOCUS reports that access a Db2 data source via the WebFOCUS Db2 adapter all execute concurrently during a peak reporting period, each report execution holds a Db2 connection from the WebFOCUS connection pool for the duration of the report (typically 30 seconds to 3 minutes for large reports). If the connection pool is sized at the default 5 connections and 20 analysts submit reports simultaneously, the 16th through 20th reports receive WebFOCUS error FOC14941 (ADAPTER CONNECTION POOL EXHAUSTED) and fail immediately. Work log: “WebFOCUS 8.2.07M; EDASERVE Db2 adapter (EDACITE DD); connection pool MAXCON=5 (default); 20 concurrent analyst WebFOCUS report requests during 9:00 AM peak; 15 active Db2 connections (5 pool maximum per server instance × 3 WebFOCUS Reporting Server instances); reports 16–20 receive FOC14941 ADAPTER CONNECTION POOL EXHAUSTED; IBI Support: increase EDACONF.CFG MAXCON from 5 to 25 per Reporting Server instance; also HOLD FILE AS intermediate output for large-table scans (read Db2 once, HOLD result to FOCUS work file, multiple reports join against HOLD file without additional Db2 connections); FOC14941 rate: 15–20/day → 0; hours: 1h WebFOCUS EDASERVE log analysis + 0.5h EDACONF.CFG MAXCON change + 1h HOLD FILE restructure for 3 high-volume reports.”

How HourTab tracks FOCUS developer retainer hours

The CLMPST.FEX MAINTAIN-without-COMMIT-POINT bug was invisible in the original single-session development environment for the same reason all exclusive lock accumulation bugs are invisible in single-user environments: when only CLMPST.FEX is running and no analysts are executing TABLE FILE CLAIMHST procedures concurrently, the exclusive VSAM lock is never contested. The program runs to completion in 3h 47m, releases the lock, and exits — no error, no conflict. The bug emerged only when CLMPST.FEX’s schedule was changed from an overnight 1:00 AM run (before the carrier added a Monday monthly run during business hours to accommodate an accelerated month-end cycle for a new reinsurance contract). The analyst FOC02200 errors appeared for the first time on the following Monday and were initially attributed to “FOCUS file corruption” because the error message says “FILE IS LOCKED” and many FOCUS developers associate locking with corruption in FOCUS file context.

The work log entry that makes FOCUS MAINTAIN lock work auditable must name every element of the causal chain: the FOCUS version (FOCUS 7.3 MVS/ESA), the procedure name (CLMPST.FEX), the data modification command (MAINTAIN FILE CLAIMHST), the FOCUS native file name and physical VSAM dataset name (MIDATLAN.CLAIMS.HISTORY.FOC), the VSAM SHAREOPTIONS (SHROPTNS(1-3) from IDCAMS LISTCAT), the absence of COMMIT POINT in the FOR ALL NEXT loop (confirmed by source review), the lock hold duration (3h 47m — from FOCUS ALTLOG open/close timestamps), the analyst error code and frequency (FOC02200 — 28 incidents per monthly run from 28 analysts), the fix (COMMIT POINT every 500 records), the maximum post-fix lock hold time (37 seconds), and the zero-error outcome. A log that says “fixed FOCUS file locking issue, 4.5h” is not auditable to the insurance carrier’s claims department VP who needs to explain to the reinsurance contract team why 28 claims analysts lost a morning of access to the claims history system. HourTab gives FOCUS developers a public retainer-hours URL they send to clients — P/C insurance carriers, life insurance companies, state government agencies, and financial institutions that run critical FOCUS MAINTAIN batch procedures and daily FOCUS TABLE reports against FOCUS native files maintained by a FOCUS specialist on monthly retainer.

The broader context for FOCUS retainer billing is that a FOCUS MAINTAIN without COMMIT POINT holding an exclusive VSAM ESDS lock for 3h 47m is the FOCUS 4GL instantiation of the same principle that drives every long-running exclusive lock retainer engagement across the mainframe stack. IMS DB developer retainers cover the same pattern at the IMS hierarchical database layer: CLMPAY01 BMP GHU exclusive DB record locks accumulating on 3,847 POLICY segments over 4h 45m without EXEC DLI CHKP — IMS CHKP releases the locks, same role as FOCUS COMMIT POINT. IBM Db2 developer retainers cover the same pattern at the Db2 relational database layer: INVUPD01 FOR UPDATE OF cursor accumulating 847,000 X locks over 3.5h without COMMIT WORK — Db2 COMMIT WORK releases the locks. Easytrieve developer retainers cover the static exclusive access variant: FILE BILLMST VSAM KSDS UPDATE specifying write access for a read-only program, holding BILLMST exclusively for the entire batch run. FOCUS’s COMMIT POINT, IMS’s EXEC DLI CHKP, and Db2’s EXEC SQL COMMIT WORK are each the correct, language-specific periodic release mechanism for the same category of long-running exclusive lock.

FAQ: FOCUS developer retainers