MAPPER – A Mission Critical Legacy

It is said colloquially that necessity is the mother of invention. In 1968, the software product known as MAPPER was conceived and borne to serve a need that persists and thrives to the present day. Before describing that need, it is appropriate to appreciate the context in which this software product emerged thirty-five years ago. In that era, the essence of the systems business was the engineering, building, shipping, installing and supporting of computer hardware.

Vendor-provided software was viewed as a necessary burden to sustain that business. Business consulting, services, training and the like were not much more than an afterthought. And, the hard-core engineering community that drove the business of the computer industry in that age had little tolerance or use for euphemisms such as information technology, enterprise assets and business transformation.

My own experience with these phenomena began when I entered the computer industry in 1965 after matriculating in the comfortable environs of graduate school at the University of Minnesota. My first job in industry was with working on a project headed by the legendary Seymour . He had a team of hardware engineers sequestered in an engineering lab on his own property in Chippewa Falls, Wisconsin. At that lab, he was fashioning what was at that time the largest computer system ever envisioned thus far in the early years of the computer industry.

That engineering lab was located far away from the influence of corporate headquarters in Bloomington, Minnesota. There was exactly one telephone in the Chippewa Falls facility. It was a red telephone mounted on the wall of the entryway of the lab, and it was to be used only for emergency purposes. My software colleagues and I were more or less viewed as intruders. We soon discovered that Seymour and his engineers had written a basic for his large-scale computer system entirely in octal, that is, numeric machine language. Our first job was to disassemble the octal code for that operating system into symbolic assembler code. The resulting operating system became known as the Chippewa operating system.

Seymour also had disaffection for other forms of software. It took months of high-level argument within Control Data Corporation to convince Seymour that a complier would be needed to make it feasible for the corporation to market his new computer system. That system was intended to be sold as a scientific number crunching machine. One would think that a FORTRAN compiler would have been an obvious requirement. But, such was the undistinguished fate of software in that era.

My awareness of Sperry Univac computer technology began in 1968 at the Jet Propulsion Laboratory (JPL) of the California Institute of Technology as a customer of Sperry Univac computer systems. At JPL, we helped NASA put spacecraft and astronauts on the surface of the moon and we returned them safely to earth with the aid of IBM and Sperry Univac using what now would be viewed as primitive software. During a launch and mission, we would gather in the mission control center at all hours of the day and night and we would pray that a bug in our software or a breakdown in our hardware would not cause the loss of life or the failure of the mission. Hence was born the term mission-critical.

Meanwhile, a mission-critical need of another nature existed in 1968 at the engineering center and factory where Sperry Univac was building its computer systems in Roseville, Minnesota. A complex of four buildings spread over several acres of land and populated by thousands of employees on three work shifts was required to house activities that encompassed engineering, procurement, storage of parts, assembly, diagnostics, testing, certification, packaging, order entry, inventory management, shipping and receiving, accounts payable and receivable, customer support, etc.

Hardware technology was characterized by discrete components, an infinite amount of wire, the lack of any subassemblies from outside vendors, and the construction of massive hardware units. The primary mass storage device was a flying head drum that resembled a coffin in size and weight. Forklifts, oscilloscopes and slide rules were popular tools. PC’s were unknown even in concept. Pencil and paper means of planning and record keeping were routinely used. Filing cabinets were precious resources.

As the business grew and prospered, the rudimentary methods of running the business that were being used became unmanageable. In fact, this became the limiting factor on what could be accomplished in terms of business volume, revenue, net income and customer satisfaction. It wasn’t printed circuit layout, or power supply design, or robots or any other aspect of sophisticated engineering or manufacturing technology that was the major stumbling block in business growth and success. It was the lack of an electronic means for planning, tracking and execution of the technical, administrative and operational regimen for running the factory.

From this milieu emerged the need for the software tooling that became known as MAPPER. Its first important characteristic was that it was conceived, designed, built and deployed by the end users who needed it. And, it was constructed in a way that it did not require an application software development organization to reside between the end users and the problems those end users were trying to solve in their workplace. This resulted in a rapid application development personality for MAPPER that meets the needs of end users and that persists to this day as a defining characteristic of the product.

Concurrently, there was a nice operating system taking shape on the Series 1100 computer systems that Sperry Univac was building in its factory in Roseville, Minnesota. Its name was EXEC8. I’m proud to say that I was one of many members of the extended software development team that created and nurtured the operating system known today as OS2200. But, a demanding and varied workload of batch jobs and online time-sharing terminals could bring EXEC8 crashing down easily in its early years. Even well into the 1970’s, we had a saying that the mean-time-between-failure (MTBF) of the operating system was measured in minutes and that we would consider it an accomplishment when that MTBF could be measured in some integral number of hours.

2 Accordingly, the team of factory software developers that conceived of MAPPER committed to building it in somewhat of a self-contained and self-reliant software environment that depended to a lesser extent on the features and capabilities of EXEC8. This was done to ensure the viability, reliability, responsiveness, data integrity and trustworthiness of the software environment with which the factory would be run. This was a mission-critical venture. Ultimately, a multi-billion dollar business enterprise and the demands and expectations of the Series 1100/2200 customer base came to depend on MAPPER exhibiting these industrial strength attributes.

This approach required Series 1100/2200 MAPPER to incorporate a rather comprehensive range of functionality, including many of the batch processing, online processing, networking, security, printing, database management, recovery, administration and operations capabilities normally considered to be within the domain of the operating system. Some argued against doing this as being too costly or ambitious. Others said the cost of failure outweighed the cost of developing MAPPER in this manner. The latter view prevailed. They soon were proved to be right.

A few years after MAPPER was deployed internally, a Sperry Univac customer observed MAPPER in operation during a tour of the Roseville engineering and manufacturing plant. The customer demanded that MAPPER be available on the Series 1100 system they were intending to purchase. The rest, as they say, was history. By the late 1970’s, MAPPER was a driving force in the sale of Series 1100/60/70 systems. Even today, OS2200 MAPPER is deployed usefully at half of the 2200/ClearPath/IX accounts in the worldwide Unisys customer base.

The self-reliant nature of the design of Series 1100/2200 MAPPER afforded its developers great latitude in innovation because their advances did not have to be negotiated and coordinated with disparate software architecture, design and development organizations outside the MAPPER domain. Because of this latitude, MAPPER pioneered many advanced concepts.

MAPPER invented client/server programming before the industry defined it. MAPPER was one of the first software products from Unisys to achieve X/Open certification. MAPPER stored, rendered and displayed digital images on graphical displays before Bill Gates invented Windows. MAPPER rendered data in dynamic, computable spreadsheet form before Lotus and EXCEL existed. MAPPER was Heterogeneous-Multi-Processing (HMP) enabled years before Unisys coined the term and baptized its ClearPath platforms with this name.

Building upon this strong history, much modernization has been done in recent years, most visibly on the surface in terms of renaming MAPPER as the Unisys Business Information Server (BIS) and of adapting to a Microsoft Windows conforming environment for BIS administrators and end users and for programmed implementation of BIS runs on Windows workstations.

3 And beneath the surface, significant redesign and enhancement of the OS2200 BIS engine have occurred in recent years. Much of this has been focused on performance and scaling improvements that are needed to keep pace with the demands of the vibrant OS2200 community of BIS applications and end users, and to exploit the growing capacity and power of OS2200 hardware platforms.

For example, the prior release level of OS2200 BIS 43R1 runs exceptionally well on a ClearPath Plus Dorado 180 system and is capable of fully utilizing up to eight processors, with demonstrated throughput measurements that far surpass what was possible on previous ClearPath HMP IX platforms. Further development work also was done in this regard for the new release of OS2200 BIS 44R1, which is capable of scaling up to utilization of a 16-processor configuration.

Interoperability also is an area of importance because many OS2200 BIS applications and databases are surrounded by open systems BIS applications on Microsoft Windows or Unix servers, or they are required to interoperate within the context of a network of heterogeneous systems. An interesting enhancement in this regard is that OS2200 BIS 44R1 was adapted to support IBM WebSphere MQ message queuing for interoperation with other application environments.

There is a bevy of vital and mission critical BIS applications running worldwide on OS2200 platforms in a variety of industry, commerce and government settings. Unisys is committed fully to moving this customer base forward with enhanced and improved versions of OS2200 BIS. The next article in this series will explore the use of Windows BIS and its companion Internet Commerce Enabler (ICE) for application and data integration in a ClearPath venue thereby extending the value of ClearPath centered application environments.

Gerry Del Fiacco Unisys Corporation Software Engineering Manager BIS/ICE/GIW Product Deliveries and Support Roseville, Minnesota and Salt Lake City, Utah [email protected]

4