History of the MPS System

A great deal of the mortgages being serviced today utilize a platform referred to as MPS.  Anyone interested in learning more about the technical history of the platform should read this summary which references materials presented from the CICS Wiki.

The first release of the CICS Program Product developed by IBM became available on July 8, 1969, not long after IMS. CICS was originally developed in the United States at an IBM Development Center in Des Plaines, Illinois, beginning in 1966. The first CICS product was released in 1968, named Public Utility Customer Information Control System, or PU-CICS. CICS was originally developed to address requirements from the public utility industry, but it became clear immediately that it had applicability to many other industries, so the Public Utility prefix was dropped with the introduction of the first release of the CICS Program Product. In early 1970 a number of the original developers, including Ben Riggins, the principal architect of the early releases, relocated to California and continued CICS development at IBM’s Palo Alto Development Center. In 1974, CICS development responsibility was shifted to IBM’s Hursley, United Kingdom Laboratory, where development work continues today.

When CICS was first released, it supported programs written in IBM Assembler, PL/I and COBOL. Programs needed to be quasi-reentrant in order to support multiple concurrent transaction threads. Its modular design meant that, with judicious “pruning”, theoretically it could be executed on a computer with just 32K of physical memory (including the operating system). Because of the limited capacity of even large processors of that era every CICS installation was required to assemble the source code for all of the CICS system modules after completing a system generation process to establish values for conditional assembly statements. This process allowed each customer to exclude support from CICS itself for any feature they did not intend to use, such as device support for terminal types not in use. CICS services emulated the functions of the operating system, but provided services tailored to support only transaction processing that were more efficient than the generalized services in the operating system and much simpler for programmers to use, particularly with respect to communication with terminal devices. Considerable effort was still required from CICS application programmers to make their programs as efficient as possible. A common technique was to limit the size of individual programs to no more than 4,096 bytes, or 4K, so that CICS could easily use the memory occupied by any program not currently in use for another program or other application storage needs. As the efficiency of compiled high level language programs left much to be desired, many early CICS application programs were written in assembler language. CICS owes its early popularity to its relatively efficient implementation, its multi-threaded processing architecture, and its relative simplicity for developing terminal based applications.

An earlier, single thread, transaction processing system IBM MTCS existed prior to CICS and an ‘MTCS-CICS bridge’ , a type of middleware, was developed to allow these transactions to execute under CICS with no change to the original application programs.

Each unique CICS “Task” or transaction was allocated its own dynamic memory at start-up and subsequent requests for additional memory were handled by a call to the “Storage Control program” (part of the CICS nucleus – or “kernel”), which is analogous to an operating system.

Because application programs could be shared by many concurrent threads, the use of static variables embedded within a program (or use of operating system memory) was restricted (by convention only).

Unfortunately, many of the “rules” were frequently broken, especially by COBOL programmers who were frequently unaccustomed to the internals of their programs or else did not use the necessary restrictive compile time options. This resulted in “non-re-entrant” code that was often unreliable, leading to many spurious storage violations and entire CICS system crashes.

The entire partition, or region, operated with the same memory protection key including the CICS kernel code and so program corruption and CICS control block corruption was a frequent cause of system downtime.

These shortcomings nevertheless persisted for multiple new releases of CICS over a period of more than 20 years and, as stated above, were often critical applications used by large banks and other financial institutions.

It was possible to provide a good measure of advance protection by performing all testing under control of a monitoring program that also served to provide Test/Debug features. One such software offering was known as OLIVER, which prevented application programs corrupting memory by using instruction set simulation of the application code, providing partial virtualization.

System calls to CICS (for example to read a record from a file) were elicited by a macro call and this gave rise to the later terminology “Macro-level CICS”. An example of a call to the “File Control Program” of CICS might look like this:-

DFHFC TYPE=READ,DATASET=myfile,TYPOPER=UPDATE,….etc

This was converted by a pre-compile Assembly which expanded the conditional assembly language macros to their COBOL or PL/I CALL statement equivalents. Thus preparing a HLL application was effectively a “two-stage” compile; output from the Assembler fed straight into the HLL compiler as input.