MAPPER developer on retainer: PREMREC run no D verb before I verb — PREM-RESULT folder accumulates 12,848 lines across four months — RECONCILE reports $47.2M premium vs. correct $11.8M — Unisys MAPPER developer, MAPPER BIS developer on monthly retainer

Unisys ClearPath MCP 19.1 • Libra 720 • MAPPER III / MAPPER BIS • PREMREC run • missing D verb • I verb APPEND accumulation • PREM-RESULT 12,848 lines • RECONCILE SUM overcounts • retainer billing

At Pacific States Insurance Group, the month-end premium reconciliation run had always been a reliable overnight job. In January it produced a clean summary of premium activity across all product lines, finishing in four minutes and twelve seconds with totals that matched the actuarial team’s manual calculations. In February the run took seven minutes and forty-four seconds and the totals were slightly off — a few thousand dollars, attributed to a late posting and signed off without investigation. In March it ran eleven minutes and thirty-eight seconds and the discrepancy had grown to a level that triggered a review. In April the run took eighteen minutes and twenty-two seconds and the output reported a current-month premium volume of $47.2 million. The correct April total was $11.8 million.

The Unisys MAPPER retainer developer was called in. Within an hour, a single MAPPER system command identified the root cause: the PREMREC run had no D (Delete) verb at its beginning. Every monthly execution had been silently appending its approximately 3,200 output lines to the PREM-RESULT folder on top of all prior months. By April, PREM-RESULT contained all four months of output — 12,848 lines in total — and the downstream RECONCILE run was summing every line without any date filter, producing a figure four times the correct monthly premium.

MAPPER architecture: folders, runs, and the verb vocabulary

MAPPER (Maintained Accesses to Program and Perform Expected Results) is a Unisys-proprietary 4GL and report-writing system that runs on both ClearPath MCP (formerly Burroughs mainframes) and ClearPath OS 2200 (formerly Sperry UNIVAC mainframes). Pacific States ran MAPPER III — also known as MAPPER BIS (Business Information System) at MCP sites — on a ClearPath MCP 19.1 system hosted on a Libra 720 server.

In MAPPER, the two fundamental concepts are folders and runs. Folders are the data store: each folder holds an ordered list of lines, each line identified by a sequence number and containing structured data in defined field positions. Folders serve the role that tables serve in a relational database, though they are more free-form — a folder’s content is whatever lines have been written into it, with no enforced schema at the folder level. Runs are the programs: a MAPPER run is a sequence of verb statements that read from folders, perform calculations, and write to other folders or to the printer spool.

The core MAPPER verb vocabulary covers every operation a reporting run needs:

Understanding the Insert verb’s default APPEND behavior is the key to understanding the PREMREC bug. When a MAPPER run issues I PREM-RESULT, MAPPER adds the current work-area lines to whatever lines are already in PREM-RESULT. There is no warning, no error, no indication that prior content exists. The folder grows silently with each execution. If the intent is to produce a fresh set of results each run — as every monthly reporting run at Pacific States intended — the folder must be explicitly cleared with D PREM-RESULT before the first I PREM-RESULT.

The PREMREC run structure and the missing D verb

The PREMREC run (Premium Reconciliation) read premium transaction records from monthly source folders, calculated per-product-line totals, and wrote a summary line for each product line into PREM-RESULT. The source folders were named by month: PREMJAN held January’s premium transactions, PREMFEB held February’s, and so on. Each source folder contained approximately 3,200 lines, one per premium transaction.

The run logic, reconstructed from the MAPPER run source in the INSRPT folder library, looked like this:

* PREMREC - Monthly Premium Reconciliation
* Reads current month source folder, calculates product-line totals,
* writes results to PREM-RESULT for downstream RECONCILE run.
*
* NOTE: No D PREM-RESULT here <-- BUG: folder never cleared
*
  L PREMJAN                      * List/read all lines from current-month folder
  S PROD-LINE-CODE A             * Sort ascending by product line code
  * ... subtotal calculation block by product line ...
  I PREM-RESULT                  * Insert (APPEND) totals into results folder
  P PREM-RESULT                  * Print results to spool

The run had been written without a D PREM-RESULT line at the start. When PREMREC ran in January, PREM-RESULT was new and empty — the I verb wrote 3,178 summary lines, producing a correct result. When PREMREC ran in February, it read from PREMFEB (a different source folder, correctly), calculated February totals, and then issued I PREM-RESULT — which appended 3,204 lines to the 3,178 January lines already sitting in PREM-RESULT. PREM-RESULT now held 6,382 lines: January and February combined, with no separator and no date filter.

The March run appended another 3,219 lines. April appended 3,247 more. By the time the April reconciliation ran, PREM-RESULT contained:

The progressive run-time increase was a direct consequence of the growing folder size. MAPPER must process all lines in the work area when executing sort and print operations. January’s 3,178-line work area ran in 4m 12s. By April, the accumulated 12,848-line work area took 18m 22s — a fourfold increase in both data volume and runtime that should have signalled a problem months earlier.

MAPPER LIST PREM-RESULT: diagnosing the accumulation

The retainer developer’s first diagnostic step was a direct MAPPER system command from the Coordinator terminal session:

MAPPER SYSTEM COMMAND: LIST PREM-RESULT

Folder: PREM-RESULT
Library: INSRPT
Lines:   12,848
Seq Low: 1
Seq High: 12848
Last Update: 2026-04-30 22:14:07
Owner: PREMCOORD

A monthly premium summary folder should contain approximately 3,200 lines — one per product line per transaction category for a single month’s activity. 12,848 lines immediately indicated that the folder had not been cleared between runs. The developer then examined the first and last lines in the folder to confirm the date spread:

* Lines 1-3 (January output at top of folder):
SEQ  001  RUN-DATE 2026-01-31  PROD-LINE AUTO    PREM-AMT  3847291.22
SEQ  002  RUN-DATE 2026-01-31  PROD-LINE HOMEOWN PREM-AMT  2104832.10
SEQ  003  RUN-DATE 2026-01-31  PROD-LINE COMMERC PREM-AMT  4910045.87
...
* Lines 9602-9604 (April output near bottom):
SEQ 9602  RUN-DATE 2026-04-30  PROD-LINE AUTO    PREM-AMT  3901204.11
SEQ 9603  RUN-DATE 2026-04-30  PROD-LINE HOMEOWN PREM-AMT  2198043.55
SEQ 9604  RUN-DATE 2026-04-30  PROD-LINE COMMERC PREM-AMT  5019887.33

The RUN-DATE field confirmed the accumulation: January lines at sequence 1, April lines at sequence 9602. The downstream RECONCILE run read all 12,848 lines from PREM-RESULT using an L PREM-RESULT with no date-range filter, then issued a SUM on the PREM-AMT field. Summing all four months’ PREM-AMT values across 12,848 lines produced $47.2 million — the exact four-month grand total rather than April’s $11.8 million.

Examining the PREMREC run source confirmed the missing verb. The very first executable statement after the run header comments was L PREMJAN (or whichever source folder was currently designated as the active month). There was no D PREM-RESULT before, between, or after any of the verb blocks. Every month’s output had been quietly appended since the run was first deployed in January.

Why the RECONCILE run had no date filter

A reasonable question is why RECONCILE did not filter PREM-RESULT by RUN-DATE to select only the current month’s lines. The answer is a common pattern in MAPPER shop design: PREM-RESULT was structured as a current results folder, not a historical archive folder. The implicit contract between PREMREC and RECONCILE was that PREM-RESULT always contained exactly one month’s data — the most recent run. RECONCILE was written to read and sum everything in PREM-RESULT unconditionally, because its authors assumed PREMREC would clear the folder before writing.

This design assumption — that the upstream run maintains folder hygiene — is standard practice in MAPPER shop architecture. A results folder is expected to hold the output of the last run that wrote to it, not a cumulative history. The pattern for any reporting run that refreshes a results folder is:

* Safe reporting run pattern:
  D RESULTS-FOLDER               * Clear output folder first
  C RESULTS-FOLDER               * Count (should be 0 — sanity check)
  L SOURCE-FOLDER                * Read source data
  * ... processing ...
  I RESULTS-FOLDER               * Write fresh results (clean folder)
  P RESULTS-FOLDER               * Print

The D verb deletes all lines in the named folder and resets sequence numbering to zero. The optional C verb immediately after the D serves as a sanity counter: if the count is not zero, something went wrong with the delete (permissions issue, folder locked by another run, etc.), and the run can issue an E (Exit) with an error message rather than appending to a non-empty folder. Adding C after D at the start of PREMREC was part of the retainer fix.

MAPPER Insert modes: APPEND vs. REPLACE

MAPPER’s I (Insert) verb supports two primary modes that every MAPPER developer must understand:

APPEND mode (the default when no mode modifier is specified) adds the current work-area lines after the last existing line in the target folder. Sequence numbers are assigned sequentially following the highest existing sequence number. If PREM-RESULT has 3,178 lines ending at sequence 3178, an APPEND insert of 3,204 new lines starts numbering at sequence 3179. There is no concept of overwrite; the folder grows indefinitely until explicitly cleared with D.

REPLACE mode (specified with the REPLACE modifier on the I verb) matches incoming lines to existing lines by a key field and overwrites the matching existing line. Lines with no match in the folder are inserted as new lines. REPLACE is appropriate for folders that maintain a current-state record per entity — for example, a customer balance folder where each line represents one customer and repeated runs update the balance for that customer rather than adding duplicate lines. REPLACE is not appropriate for historical accumulation folders or for result folders intended to hold a fresh set of output each run.

PREMREC’s use of plain I PREM-RESULT (APPEND mode) was correct in the sense that each month’s data was distinct — there was no natural key by which February lines would replace January lines. REPLACE mode would not have saved PREMREC; only D PREM-RESULT at the start of each run produces the correct result for a monthly-refresh reporting pattern.

In some MAPPER versions, particularly on OS 2200, an alternative to D is RS (Reset Sequence), which also clears folder contents and resets the sequence counter. At MCP BIS sites running MAPPER III, D is the standard and preferred verb for clearing a folder before writing. The PREMREC fix used D PREM-RESULT, consistent with Pacific States’ existing MAPPER III conventions.

MAPPER on MCP vs. OS 2200: a note on platforms

MAPPER runs on both of Unisys’s mainframe lines, which have distinct histories. ClearPath MCP (Master Control Program) traces its lineage to Burroughs Corporation, which merged with Sperry Corporation in 1986 to form Unisys. ClearPath OS 2200 traces its lineage to Sperry UNIVAC, also absorbed in the 1986 merger. Both platform lines have run MAPPER for decades, and many insurance carriers, banks, and government agencies run one or both.

MCP MAPPER BIS (Business Information System) — the product designation used at Pacific States’ Libra 720 site — is the MCP-native version. OS 2200 runs a distinct MAPPER product that shares the same verb vocabulary and folder/run architecture but differs in system administration details, batch job submission syntax (OS 2200 uses EXEC run streams where MCP uses WFL work flow language), and the Coordinator role’s administrative command set. A retainer developer who is proficient on one platform will find the other familiar but not identical; cross-platform engagements should specify which platform and release is in scope.

The MAPPER Coordinator role — the designated responsible person at a MAPPER site for run development, folder maintenance, and user administration — exists on both platforms. The Coordinator has elevated MAPPER system command access that ordinary users do not, including the ability to LIST all folders, execute system-level diagnostic commands, and modify folder access control lists. The retainer developer at Pacific States worked under the Coordinator’s access level to execute LIST PREM-RESULT and to examine and modify the PREMREC run source.

The fix and the verification

The fix was a single added line: D PREM-RESULT at the very beginning of the PREMREC run, before the L PREMJAN read. The retainer developer also added C PREM-RESULT immediately after the D, with a B (Branch) conditional to exit with an error message if the count was not zero after the delete — a defensive check against future incidents where the folder might be locked or the delete might fail silently.

The revised run opening read:

* PREMREC - Monthly Premium Reconciliation (revised 2026-05-01)
*
  D PREM-RESULT                  * Clear results folder before writing
  C PREM-RESULT                  * Count should be 0 after delete
  B PREM-COUNT-OK GT 0 ABORT-RUN * If count > 0, delete failed — exit
  L PREMJAN                      * List source folder for current month
  S PROD-LINE-CODE A             * Sort by product line ascending
  * ... subtotal calculation block ...
  I PREM-RESULT                  * Insert fresh results (folder was cleared above)
  P PREM-RESULT                  * Print
  E                              * Exit clean

ABORT-RUN:
  E PREM-RESULT NOT EMPTY AFTER D - CHECK FOLDER LOCK OR PERMISSIONS

With the fix applied, the April PREMREC run was executed:

The RECONCILE run was then executed against the corrected PREM-RESULT. Reading 3,247 lines with L PREM-RESULT and summing PREM-AMT produced $11.8 million — matching the actuarial team’s independently-computed April premium total exactly.

The retainer developer also reviewed every other reporting run in the INSRPT folder library that used I to write to a results folder, checking whether any other run was missing D at its start. Two additional runs were found with the same pattern: CLAIMREC (Claims Reconciliation) and LOSSSUMM (Loss Summary). Both were corrected with the same D + C pattern before their next scheduled runs. CLAIMREC’s results folder had accumulated three months of data; LOSSSUMM had two. Neither had yet caused a detected discrepancy, but both were silently building toward the same problem PREMREC had just exhibited.

MAPPER sequence numbers and folder hygiene

Every line in a MAPPER folder carries a sequence number assigned by MAPPER when the line is inserted. Sequence numbers are integers, typically starting at 1 for the first line in a folder and incrementing by 1 for each subsequent insert in APPEND mode. The sequence number is visible in the MAPPER work area and can be used as a sort key or a selection criterion in run logic.

When D is issued against a folder, MAPPER deletes all lines and resets the sequence counter to 0. The next I into the folder will start numbering at sequence 1 again. This is the expected clean-slate behaviour: each monthly PREMREC run should produce PREM-RESULT with sequences 1 through approximately 3,200, with no residual high sequence numbers from prior months that might confuse runs using sequence-based selection.

The accumulating high sequence numbers in the uncorrected PREM-RESULT (eventually reaching 12,848 before the fix) were an observable indicator of the problem that a careful MAPPER Coordinator reviewing folder statistics would have noticed. One operational recommendation from the retainer engagement was to add a monthly Coordinator review of results-folder line counts as a standard checklist item, comparing actual line counts against expected-range values documented for each production results folder.

How HourTab helps Unisys MAPPER retainer developers

The PREMREC diagnosis and fix took four hours of focused retainer work: one hour analysing the RECONCILE output discrepancy and tracing its data lineage back to PREM-RESULT; thirty minutes running LIST PREM-RESULT and reading line header dates to confirm the accumulation; thirty minutes examining the PREMREC run source and the sources of the other reporting runs in INSRPT to understand the full scope; thirty minutes writing and testing the fix, including the defensive C + B ABORT-RUN addition; thirty minutes re-running PREMREC and RECONCILE and verifying the April total; thirty minutes reviewing the other runs in the library for the same missing-D pattern and correcting CLAIMREC and LOSSSUMM; and thirty minutes documenting the fix and writing the operational recommendation for monthly folder-count reviews.

Each segment is distinct retainer work. In a HourTab log, the session reads: “PREMREC missing D PREM-RESULT: MAPPER LIST confirmed 12,848 lines (Jan 3,178 + Feb 3,204 + Mar 3,219 + Apr 3,247); added D PREM-RESULT + C sanity check at run start; RECONCILE April total $47.2M → $11.8M; CLAIMREC and LOSSSUMM same pattern corrected; ops recommendation: monthly folder-count review checklist, 4.0h.” Pacific States’ finance director reads that entry and sees exactly what was wrong — a missing verb, four months of silent accumulation, a fourfold overcount — and what was done to prevent recurrence. There are no vague references to “MAPPER investigation” or “report fix.” The log is audit-ready.

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: Unisys MAPPER developer retainers

What does a Unisys MAPPER developer on retainer typically do?

A Unisys MAPPER developer on monthly retainer covers MAPPER run development and maintenance across ClearPath MCP (MAPPER BIS) and OS 2200 environments: run authoring and debugging using the full MAPPER verb set (L List, I Insert, D Delete, C Count, S Sort, M Modify, P Print, B Branch, E Exit); folder maintenance including sequence number management, size monitoring, and periodic purge runs; MAPPER report writer configuration (field definitions, column layouts, subtotal breaks, grand-total rows, header/footer text); MAPPER BIS administration under the Coordinator role (user ID maintenance, folder access control lists, system command execution); complex run authoring for multi-folder joins, conditional branch logic, and sort-break reporting structures; and cross-platform support for both MCP ClearPath (WFL job integration) and OS 2200 (EXEC run stream integration).

What MAPPER run maintenance work is most commonly underlogged?

Missing D (Delete) verb at the start of reporting runs that write to a results folder is the most systematically underlogged MAPPER retainer work. The pattern: a run reads source data with L, computes totals, and writes results with I (Insert/Append). Because I defaults to APPEND, omitting D means each execution piles output on top of all prior runs. A monthly reconciliation accumulates silently — no error, no warning — until a downstream run summing the results folder reports multiples of the correct figure. Diagnosis: MAPPER LIST <folder> shows the actual line count; examining line header dates reveals the oldest months at top. Fix: add D <output-folder> as the first statement in the run, plus C (Count) after D as a defensive sanity check. Also underlogged: the time spent tracing all downstream runs that read the corrupted folder and verifying each one after the fix.

What are typical Unisys MAPPER developer retainer rates?

Entry-level Unisys MAPPER developers with run basics (L, I, D, C, S, P verbs; folder read/write patterns; basic report writer column definitions; DEMAND session execution) typically bill at $65 to $110 per hour. Mid-level developers with run debugging (missing D verb diagnosis, folder accumulation tracing, sequence number analysis, downstream dependency mapping), MAPPER BIS administration (Coordinator role, user ID and folder access control, system command execution, folder quota management), and complex run authoring (multi-folder joins, conditional B branch logic, sort-break subtotal structures) typically bill at $95 to $165 per hour. Senior developers with MAPPER release migration (MAPPER II to MAPPER III to MAPPER BIS), system architecture (folder naming conventions, run library organisation, purge and archival strategy, batch scheduling via WFL on MCP or EXEC on OS 2200), integration work (MAPPER output to downstream COBOL programs, CSV extract runs, interface folder maintenance), and Coordinator responsibilities (site-wide run standards, training, performance tuning) typically bill at $140 to $235 per hour. Monthly retainer ranges: $2,500 to $6,000 per month for run maintenance and BIS administration; $5,000 to $12,000 per month for run architecture, release migration, and system integration.

What should a Unisys MAPPER developer retainer agreement include?

A MAPPER retainer agreement should specify: the Unisys platform (ClearPath MCP / MAPPER BIS or ClearPath OS 2200 / MAPPER for OS 2200) and the specific hardware generation and OS release (MCP 19.1 on Libra 720, etc.); the MAPPER release in use (MAPPER II, MAPPER III, MAPPER BIS); whether the Coordinator role and MAPPER system administration are within scope (Coordinator access is required for LIST diagnostics, system command execution, and folder access control changes); whether run development for new reporting requirements is in scope vs. maintenance and debugging of existing runs only; whether integration work is in scope (MAPPER extract runs feeding downstream COBOL programs, WFL/EXEC job stream integration, external file transfers); whether the retainer covers MAPPER release upgrade testing when a ClearPath OS upgrade bundles a new MAPPER BIS version; and the response-time SLA for production run failures, particularly for month-end reconciliation runs that are time-critical for finance and actuarial teams.

How should Unisys MAPPER developer retainer hours be logged?

Log each MAPPER retainer session with the ClearPath platform and OS release, run name, folder names involved, MAPPER LIST line count before and after fix, and the specific verb that was missing or incorrect. For a missing-D diagnosis: Unisys ClearPath MCP 19.1 (Libra 720); MAPPER III / MAPPER BIS; run PREMREC in folder library INSRPT; source folders PREMJAN–PRAPR (approximately 3,200 lines each); output folder PREM-RESULT; MAPPER LIST PREM-RESULT before fix: 12,848 lines (Jan 3,178 + Feb 3,204 + Mar 3,219 + Apr 3,247); run times January 4m 12s → April 18m 22s; downstream RECONCILE L PREM-RESULT SUM PREM-AMT: $47.2M (should be $11.8M); root cause: PREMREC uses I PREM-RESULT with no D PREM-RESULT at start; fix: added D PREM-RESULT + C PREM-RESULT sanity counter + B ABORT-RUN on count>0; reran PREMREC: PREM-RESULT 0 lines at start, 3,247 lines after run, 3m 51s; RECONCILE: $11.8M; also corrected CLAIMREC and LOSSSUMM with same pattern; hours: 1h RECONCILE investigation + 0.5h MAPPER LIST + 0.5h run source review + 0.5h fix + 0.5h test + 0.5h library audit (CLAIMREC/LOSSSUMM) + 0.5h documentation = 4.0h.

See also: IBM AS/400 developer retainer · ALGOL developer retainer · COOL:2E developer retainer