MAPPER (BIS)

MAPPER - officially Business Information Server (BIS) since the early 2000s, but still called MAPPER by almost everyone who uses it - is a report-processing system and fourth-generation language that grew up inside Sperry Univac’s computer factory in Roseville, Minnesota. It began in 1968 as the 418 CRT Report Processing System, a way for factory staff to keep test-status reports on a UNIVAC 418 and interrogate them from display terminals without programmers. Rewritten for the UNIVAC 1100 mainframes in 1975, sold reluctantly from 1976 and officially from 1979, it became by Sperry’s own account “the most successful software product in the history of Sperry Univac”, credited with roughly every second 1100/60 sale in 1981. Its scripting language, the run, is one of the earliest examples of a language designed so that the people who use data - not the data-processing department - could automate what they had first done by hand at a terminal.

The name is an acronym for MAintain, Prepare and Produce Executive Reports, coined by Sperry engineer Chuck Hanson in 1975; enthusiasts have since offered “Most Amazing Programming Product Ever Released”. Under Unisys it survived the Burroughs-Sperry merger, a port to UNIX and Windows, a web layer called Cool ICE, an embedded JavaScript engine, and a rename to BIS, and it is still released for ClearPath OS 2200, Windows and Linux in the 2020s. It is catalogued here as dormant rather than dead: it is proprietary, has never been open-sourced, has no hobbyist implementation, and lives on almost entirely in long-established enterprise and government installations.

History and Origins

A test technician’s idea (1967-1968)

Lou Schlueter had been a test technician and engineer on Sperry Univac’s factory floor before moving into the Diagnostic Software Development group. In 1968 he was assigned to a small team writing a Test Reporting application: lists of equipment type numbers, serial numbers, status codes and planned versus actual test dates - essentially columns of status data. Rather than code that one application, he proposed a general way to “computerize any reporting task without the specific programming having to be done for each different type of reporting”. His February 1968 paper, 418 Report Processing System, laid out the hardware requirements and the basic report-processing functions, and was accepted by management immediately.

The enabling hardware was the Uniscope 300 display terminal, which Univac had just deployed in bulk for the United and Eastern Airlines reservation systems. The UNIVAC 418, a communications-oriented mid-range machine, was chosen to host the system. Bill Gray managed the group; Jack Olgren, the senior diagnostic programmer who had first declared that “such a generalized, programmer-less method of using computers was not feasible”, reconsidered, became the lead programmer, and died in a motorcycle accident about a year into the project. Chuck Hanson became the key programmer and later the architect of the 1100 version.

The 418 CRT-RPS quickly outgrew the test department. Other Roseville departments took it up, other Univac plants dialled in over telephone lines, and Production Control - under a director who “demanded quick action and strict discipline” - built more than 100 reporting applications and became the showcase for what Schlueter called User Designed Computing. Schlueter wrote the on-line use procedures into report 1A and became the system’s first Coordinator, a role that has been part of every MAPPER installation since.

RPS 1100 versus MAPPER 1100 (1974-1975)

By 1974 the service had become a threat to the corporate Information Systems and Control charter, which absorbed it. Corporate headquarters chartered RPS 1100, an official rewrite for the 1100 mainframes layered on the standard TPS transaction and DMS 1100 database products (Gray and Smith expand the original RPS as Remote Processing System, while Schlueter’s own papers say Report Processing System). Schlueter objected that conventional record structures could not deliver the random-access report processing the factory relied on, left the project with a white paper of concerns, and persuaded Bill Gray’s group to build their own 1100 version from their 418 experience. George Gray and Ronald Smith’s history in the IEEE Annals of the History of Computing records the outcome: RPS 1100 was released in December 1974 “but it never was widely used”, while the factory version - which had to take a new name because RPS was taken - went live as MAPPER 1100 in February 1975 on an 1106 in Final Test and was “stable and fully operational” by March.

Because it was unofficial, MAPPER was written in assembler on a minimal budget and built to depend as little as possible on EXEC 8, whose mean time between failures in those years was, according to Unisys manager Gerry Del Fiacco, “measured in minutes”. The MAPPER team therefore implemented its own batch, on-line, networking, security, printing, database, recovery and administration facilities - a self-contained design that later gave the developers unusual freedom to innovate.

The sale that was not supposed to happen (1976-1979)

Corporate direction was explicit: MAPPER 1100 was for internal use and was not to be sold. Customers touring the Roseville plant kept asking for it anyway. In 1976 Chicago salesman Joe Bradway sold it to the Santa Fe Railway, which wanted to track its freight cars and was proposing a large 1100 purchase; asked how he dared, he said “he knew they would not turn down such a large order”. GTE Automatic Electric followed, then FTD Florists, Sargent & Lundy, the Chicago Board of Education and Kansas City Power & Light by 1978 - all as unsupported “Category III” software.

Santa Fe also changed the language. The first applications strung together saved function sequences (the RBG/RPG facilities); to make that efficient, the RUN language was designed for application definition, with the railway “mandating” a repeatable command capability. Sperry finally announced MAPPER as a supported product in the fall of 1979, just as the low-cost 1100/60 arrived. Gray and Smith note that the combination “attracted many new customers”: Sperry exceeded its first-year target with 528 processors, and Subaru of America - which chose the 1100/60 over IBM’s not-yet-ready 4300s “interested in Mapper’s potential” - ran an all-MAPPER shop whose 1100/61 was swamped within six months.

The MAPPER decade (1980s)

Sperry’s July 1982 Series 1100 Sales Information Manual is unabashed: MAPPER 1100 “is the most successful software product in the history of Sperry Univac”, in use in-house on about 50 systems with more than 10,000 terminals, “the primary sales argument for approximately every second Series 1100/60 sale” in 1981, with the largest customer processing 2.5 to 3 million transactions (runs plus manual functions) a day on 1100/80 systems. The same manual lists the features that made it a complete environment for its time: search, join, arithmetic and totalising operations, electronic mail, word processing in the terminal with text held in the database, colour graphics, a batch interface, a magnetic-tape history facility, and an on-line tutorial so complete that “a MAPPER user has normally no need to read the printed MAPPER documentation”.

The product line then spread across Sperry’s hardware. MAPPER 80 (1983) brought the same model to System 80 under OS/3. The System 11 - an office-sized 1100 - was reportedly marketed as MAPPER 10 from about 1984. A micro-MAPPER strategy produced the MAPPER 5 microcomputer and then a PC MAPPER with a dedicated MAPPER processor board in a 386 PC, the first MAPPER on IBM-compatible hardware. When Open Systems and UNIX arrived, Sperry rewrote the product in C as U Series MAPPER or MAPPER C for its UNIX machines. Marketing featured “MAPPER Man”, the self-empowered executive, and in Scandinavia a 1983 song, “Do it the MAPPER way!”, performed by an ABBA-style group. Translations reached more than 15 languages, and a 1989 survey found 140 of 224 UNIVAC 1100 customers using it.

Unisys, Cool ICE and BIS (1986-present)

Burroughs bought Sperry in 1986 to form Unisys. Schlueter’s verdict, delivered in 2013, is bitter: the more than $3 billion hardware base sold on MAPPER’s strength built the cash surplus that made Sperry a target, and Unisys then did “non existent promotion” of the product, which nevertheless kept generating over $20 million a year in software revenue from the 1100 base. Del Fiacco, writing from inside Unisys, was more sanguine, noting that OS 2200 MAPPER was still “deployed usefully at half of the 2200/ClearPath/IX accounts” and crediting it with client/server programming “before the industry defined it”, early X/Open certification, and dynamic spreadsheet-style display “before Lotus and EXCEL existed”.

The 1990s added the pieces that define the modern product. Cool ICE (Internet Commerce Enabler), documented from the late 1990s and described in Unisys patents filed in November 1998, sits between web browsers and “Classic MAPPER” on Series 2200, translating HTML form submissions into run invocations so that existing applications could be web-enabled without rewriting. Between the 1998 patents, which still say MAPPER, and Del Fiacco’s 2003 history, which treats the new name as recent, the product was renamed Business Information Server; and its administration and development tooling moved to Windows; at some point the sources located do not date, an embedded JavaScript interpreter with report-as-recordset extensions was also added as an alternative to the run language. OS 2200 BIS 44R1 (2003) scaled to 16-processor ClearPath Plus Dorado systems and added IBM WebSphere MQ messaging. Releases have continued on a roughly two-to-four-year cadence since: 48R1/12.1/12R1 in 2014, 49R1 in 2018, 50R1/14.1/14R1 in 2020, 51R1/15.1/15R1 around the end of 2022, and 16.1/16R1 in 2025.

Design Philosophy

User-driven computing

MAPPER’s founding idea, which Schlueter spent four decades and several books promoting, is that the people who own a reporting problem should be able to solve it themselves. Del Fiacco summarised the product’s “first important characteristic” as being “conceived, designed, built and deployed by the end users who needed it”, without “an application software development organization” between users and their problems. The mechanism is deliberate: users design a report form, and “when they design the data form they automatically create a function control language” - the column headings are the schema, and every function reads its parameters “in the context of the user’s own data”. Sperry’s sales literature claimed that a typical end user could master the functions needed to add, compute, copy and print data “within one or two days”.

The Coordinator

Because anyone could create reports and runs, every installation has a Coordinator - Schlueter held the job first - who owns cabinet allocation, user registration, security, backup and training, and who reviews and registers every run before it goes into production. The MAPPER 80 manual describes the workflow: submit a run plan, get it approved, register the run name for debugging, build and debug it, have it evaluated, then register it for use, possibly with conditions such as the hours at which it may execute. The coordinator’s tools also show who is consuming resources, and users who run inefficient processing can be throttled. This governance model is as much a part of MAPPER as its syntax.

Real-time report processing

MAPPER data is visible-record data: what appears on the screen is literally what is stored, in fixed-width character columns under a heading line. There is no separate schema, no compiled program that “reads” the data, and no built-in formula engine. Instead a set of powerful, re-entrant, memory-resident functions - search, sort, match, totalise, calculate - are applied to a report to produce a result, which is a temporary copy with the same structure that can be processed again. Work is pushed to the function rather than the program, and because each function is a tested, shared code module, an application is built from “pretested commands applied successively”, which Sperry argued reduced the opportunity for programming errors.

The Data Model: Cabinets, Drawers and Reports

The database is an electronic filing cabinet. In the original 1100 vocabulary the top level was a Mode (a whole filing cabinet), which contained up to eight Types (drawers), each holding thousands of Reports (tables of data); the modern product calls the same things cabinets, drawers and reports, though the abbreviations M,T,R survive in run syntax. Reports in the same drawer share a line length - up to 132 characters on the 1982 1100 product, “between 40 and up to 998 characters” today depending on platform - and a layout, and every report carries a system line recording the date, time and user of its last update.

A report is addressed by RID, drawer and cabinet - 3C36 is the third report in drawer C of cabinet 36, or simply 3C if the user is already in cabinet 36. Lines within a report carry a line type - a tab line for data, an asterisk line, a period line - which functions can use as a filter, and report 0 supplies both the drawer’s template and the function masks applied to it. The limits have grown with the hardware: the BIS 16.1 User’s Guide reportedly allows up to 2,048 cabinet pairs on OS 2200 and 2,001 on Windows and Linux, 25 report formats per drawer on the open platforms against 6 on OS 2200, and 16 saved results per script. Runs themselves are stored as reports, so an application is a set of reports in a drawer, and the same security that governs data governs code. Access control was originally applied per cabinet (with different passwords for the odd and even views); current versions apply it per drawer with read-only or update rights.

Manual Functions and the Run Language

MAPPER has two layers that share one implementation. Manual functions are what an interactive user types on the control line of a displayed report - Sperry’s 1982 manual counts “more than 100”, Schlueter’s later tally is 150 functions with more than 750 options, and the 2020 release announcement says more than 145 - such as SOR (sort), SRH (search), MAT (match), TOT (totalise), FND (find), LCH (locate and change) and FLD (show field numbers). Run functions are the same operations written as statements: the manual SORT and the run statement @SOR “will invoke the same compiled re-entrant code module”. The MAPPER 80 manual describes the difference bluntly: a run performs the same search, sort and print as the manual sequence but with “virtually no pauses” between functions, so runs were policed for the load they placed on shared systems. Utilities could even generate run statements from a recorded manual session.

Anatomy of a run

A run is a report whose lines are statements. Every statement begins with @ in column 1, followed by a three-letter function name and a comma-separated positional parameter list; @. introduces a comment, and lines that begin with anything else are output text that is assembled into the run’s output area and turned into a result by @BRK. Variables are named V1 through V199 (on MAPPER 80) and are declared with a type letter and width wherever they are first used: V1A3 is a three-character alphanumeric, V2I5 a five-digit integer, V3F6.2 a real with two decimals; type H holds character strings that may not be used in arithmetic. Labels are numbers (1 to 199 on MAPPER 80; reportedly extendable to 399 on OS 2200 or 999 by registration on later systems) written as @100:. Reserved words such as DATE1$, TIME$, USER$, INPUT$ (the run’s parameters, up to 40 variables) and STAT1 (the status of the last function) expose system state. Field references such as F4 or F3,F6-6 select whole columns or slices of them. The current Unisys Developer’s Guide still gives the statement grammar in the same shape - @label:call,report options fields line-type,parameters variables . comment - and its own example could have been written in 1983 apart from the named variables:

1
2
3

@007:srh,0,c,1 d 'producttype' |,blackbox7 <finds>i5,\
<lines>i6 . Search 1C
@if USER$ EQ jdoer gto 002 ; gto 001 . check user

The example below is adapted from the examples and sample ‘Corporate Order Status’ database in the 1983 Sperry MAPPER 80 Run Functions User Guide (UP-9734): an order-status summary that joins an order report with a price list, extends prices, subtotals by customer, displays the result and optionally prints it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@BRK
@SFS U100 /V1A3                        . GET AUX NUMBER
@CHG V2H6 DATE1$                       . GET DATE
@CHG V3A2 V2(1-2) CHG V4A2 V2(3-2) CHG V5A2 V2(5-2)   . EDIT DATE
@CHG V11H8 TIME$                       . GET TIME
                      ORDER STATUS SUMMARY
        DATE: V3/V4/V5                 TIME: V11
@MCH,102,C,1,102,D,1 '' F1,F5 ,1,A F3,F6 ,1,A   . GENERATE RESULT FROM 1D,
@.                                     . INCLUDE RETAIL PRICE FROM 1C
@TOT,102,D,-0 '' F4,F6,F7 ,*,+,2       . MULTIPLY RETAIL PRICE
@.                                     . BY NUMBER OF ORDERS
@RNM -1                                . SAVE RESULT
@TOT,102,D,-1 '' F4,F7 ,+,+ V13I3,V14I6          . TOTALIZE NUMBER OF
@.                                     . ORDERS AND RETAIL SALES
        CUSTOMER          ORDER QTY   RETAIL SALES
@SUB,102,D,-1 '' F4,F7,F10 ,+,+,S V15I3,V16I8,V17S17   . SUBTOTAL BY CUSTOMER
        V17               V15         V16
        TOTALS : V13 ORDERS  $V14 SALES
@BRK
@DSP 102,G,-0                          . DISPLAY THE RESULT
@IF V1 = ' ' GTO 99                    . TEST IF RESULT IS TO
@.                                     . BE PRINTED ON AUX
@AUX,102,G,-0,V1,,Y                    . PRINT RESULT ON AUX V1
@99:XIT                                . SIGN OFF

Reading it: @SFS displays a pre-built screen format and reads the printer name into V1; @MCH matches report 1 in drawer C of cabinet 102 (the price list) against report 1 in drawer D (orders) on the product-type field; @TOT multiplies quantity by price into a new column and, after the result is saved as -1, totals orders and sales into variables; @SUB produces subtotals per customer, with the output-area lines between statements laying out headings and the substituted variable values; @DSP shows the result and @IF ... GTO 99 branches to the labelled @99:XIT sign-off when no printer was given. The user starts it by typing its registered run name.

Statement families

The run vocabulary has grown from the few dozen statements on the Sperry reference cards preserved by the VIP Club to “175 statements” by Schlueter’s count and the still larger set covered by a community Sublime Text package for modern BIS, but the core groups have been stable for forty years:

Later platforms added @LDV (load variables), @INC/@DEC, @CALL with parameters, @CAL column calculations, networking (@NET, @LNK), SQL access to external databases (@SQL, @RDB), PC interaction (@PCW, @PCF), and web helpers used by ICE services.

Modern BIS Script

Unisys now calls the language BIS Script (its scripting-guidelines document also uses “BIS Run language” and “ICE Run language”). Named variables (reportedly up to 12 characters), written <name> and declared with the same type-and-width suffixes, supplement the numbered Vnn variables; statements are usually written in lower case; and a (p) suffix substitutes a variable into an output line. The following “99 Bottles of Beer” by Peter Adlerton (2005) shows the modern idiom - @ldv initialises variables, @brk opens the output area, ; introduces the alternative branch of an @if, and @dec combines a decrement with conditional branching:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

 .bottles of beer (Peter Adlerton, 8/31/05, http://99-bottles-of-beer.net)
*===============================================================================
@ldv <bottles>i2=99,<name>a7=bottles .
@brk .
@0010: .
<bottles>(p) <name>(p) of beer on the wall, <bottles>(p) <name>(p) of beer,
@if <bottles> > 0 . ;gto 0020 ;.
@dec <bottles> if <bottles> = 0,(0020) ;if <bottles> = 1 ldv <name>=bottle ;.
Take 1 down, pass it around, <bottles>(p) <name>(p) of beer on the wall.
@gto 0010 .
@0020: .
Take 1 down, pass it around, no more bottles of beer on the wall.
@gto end .

Cool ICE services are runs with an entry point such as @001:() . whose output lines are HTML with <% ... %> substitutions, and a run can equally be written in JavaScript against the same functions. Unisys’s guidelines recommend the I and F types for numbers and H or S for text, and warn against the legacy A type on open platforms.

Platforms

MAPPER has only ever been available as a Unisys (formerly Sperry) commercial product, and the platform list below is drawn from Sperry and Unisys documentation rather than inference:

Rosetta Code’s language page additionally reports past availability on IBM AIX and on the Unisys A-Series (MCP) mainframes; that claim is not confirmed by any Unisys document located for this article.

Evolution

The version numbering itself tells the story: OS 2200 releases count upward from the 1970s (48R1, 50R1, 52R1), while the Windows and Linux products restarted at 1 and use the n.1 and nR1 styles respectively.

Current Relevance

BIS is a living but quiet product. Unisys’s January 2024 product sheet still sells it as “database, scripting language, decision-support tool” with “well over 100 built-in functions”, the filing-cabinet storage model, native access to RDMS 2200, MySQL, Oracle and ODBC sources, built-in charting, a Java EE connector, and “surround” deployments in which a Windows or Linux BIS gives web and mobile front ends to an OS 2200 core. The open-platform releases ship a Developer Workshop IDE, a JavaScript engine, a J2EE resource adapter and ODBC/ADO.NET data sources alongside the classic run language. Release notes continue to fix decades-old edge cases - the 2020 release remediated the 2028 rollover of the TDATE$ reserved word - and the US Department of Veterans Affairs still tracks BIS versions in its Technical Reference Model, listing 16.1 and 16R1 with a March 2025 release date while marking the product for divestiture within the department from 2026.

There is no open-source implementation, no emulator, and no way to try the language outside a licensed installation, which is why this entry carries no Docker image. What community exists is small and veteran: a LinkedIn group, Rob Haeuser’s MAPPERGuru archive of Make Mine MAPPER columns and Del Fiacco’s history, a Sublime Text syntax package published on GitHub by a BIS shop from 2013, the VIP Club of Unisys retirees in Minnesota who preserved Schlueter’s papers and the original Sperry “code cards”, and contract recruiters still advertising for “Unisys BIS/MAPPER developers”. Schlueter, who was still self-publishing books about BIS in the late 2010s and, according to Amazon listings, into the 2020s, remains its most persistent advocate.

Why It Matters

MAPPER is important for three reasons that have little to do with its syntax. First, it is a very early and very large-scale demonstration of end-user computing: a system built by a factory for a factory, in which “99 percent” of 1,300 applications were written by people outside the data-processing department, a decade before personal computers and spreadsheets made that idea ordinary. Its authors’ claims to have preceded Lotus 1-2-3 as a “spreadsheet” and to have invented client/server processing are partisan, but the underlying pattern - users see a table on a screen, apply named functions to it, and freeze successful sequences into scripts - is exactly how spreadsheet macros, SQL query tools and modern low-code platforms work.

Second, it shaped a company. Sperry’s own 1982 sales manual credits MAPPER with approximately every second 1100/60 sale in 1981, the machine that revived the 1100 line, and independent historians agree the combination of a cheap mainframe and an easy report tool “attracted many new customers”. Few pieces of system software have carried a hardware business so visibly.

Third, it is a case study in the governance of citizen developers. The Coordinator role, run registration, resource accounting, the incorruptible transaction log and the read-only odd cabinet were all invented to let thousands of amateurs program a shared production machine without breaking it - problems that low-code and “shadow IT” platforms rediscovered forty years later. MAPPER’s run language is unlikely ever to be taught again, but the organisational discipline that surrounded it is arguably its most durable design contribution.