# History of IBM mainframes - IBM Mainframe

The first release of the CICS Program Product developed by IBM became available on July 8, 1969, not long after IMS database management system. 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.

Evolution

CICS originally only supported a few IBM-brand devices like the 1965 IBM 2741 Selectric (golf ball) typewriter based terminal. The 1964 IBM 2260 and 1972 IBM 3270 video display terminals eventually played major roles in the evolution of CICS paperless office capabilities.

In the early days of IBM mainframes, computer software was free (bundled at no extra charge with computer hardware). The OS/360 operating system and application support software like CICS were "open" to IBM customers long before the open source software initiative. Corporations like Standard Oil of Indiana (Amoco) made major contributions to CICS.

The IBM Des Plaines team tried to add support for popular non-IBM terminals like the ASCII Teletype Model 33 ASR, but the small low-budget software development team could not afford the $100-per-month hardware to test it. IBM executives incorrectly felt that the future would be like the past with batch processing using traditional punch cards. IBM reluctantly provided only minimal funding when public utility companies, banks and credit-card companies demanded a cost-effective real-time computing system (similar to the 1965 IBM Airline Control Program used by the American Airlines Sabre computer reservations system) for high-speed data access-and-update to customer information for their telephone operators (without waiting for over-night batch processing punch card systems). When CICS was delivered to Amoco with Teletype Model 33 ASR support, it caused the entire OS/360 operating system to crash (including non-CICS application programs). The majority of the CICS Terminal Control Program (TCP - the heart of CICS) and part of OS/360 had to be laboriously redesigned and rewritten by Amoco Production Company in Tulsa Oklahoma. It was then given back to IBM for free distribution to others. In a few short years, CICS generated over$60 Billion dollars in new hardware revenue for IBM, and became their most-successful mainframe software 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. IBM executives did not recognize value in software as a revenue-generation product, until after federal law required software unbundling. In 1980, IBM executives failed to heed Ben Riggins' strong suggestions that IBM should provide their own EBCDIC-based operating system and integrated-circuit microprocessor chip for use in the IBM Personal Computer as a CICS intelligent terminal (instead of the incompatible Intel chip, and immature ASCII-based Microsoft 1980 DOS).

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 only supported application transaction programs written in IBM 360 Assembler. COBOL and PL/I support were added years later.

Multiple-user interactive-transaction application programs were required to be quasi-reentrant in order to support multiple concurrent transaction threads. A software coding error in one application could block all users from the system. The modular design of CICS reentrant / reusable control programs meant that, with judicious "pruning," multiple users with multiple applications could be executed on a computer with just 32K of expensive magnetic core 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 (sysgen) process to establish values for conditional assembly language 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 quasi-reentrant 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 diverse terminal devices.

Considerable effort was required by CICS application programmers to make their transactions 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 reuse the memory occupied by any program not currently in use for another program or other application storage needs. When virtual memory was added to versions OS/360 in 1972, the 4K strategy became even more important to reduce paging and thrashing unproductive resource-contention overhead.

The efficiency of compiled high-level (COBOL and PL/I) language programs left much to be desired. Many CICS application programs continued to be written in assembler language, even after COBOL and PL/I support became available.

With 1960s-and-1970s hardware resources expensive and scarce, a competitive "game" developed among system optimization analysts. When critical path code was identified, a code snippet was passed around from one analyst to another. Each person had to either (a) reduce the number of bytes of code required, or (b) reduce the number of CPU cycles required. Younger analysts learned from what more-experienced mentors did. Eventually, when no one could do (a) or (b), the code was considered optimized, and they moved on to other snippets. Small shops with only one analyst learned CICS optimization very slowly (or not at all).

CICS owes its early popularity to its relatively-efficient implementation when hardware was very expensive, its multi-threaded processing architecture, its relative simplicity for developing terminal-based real-time transaction applications, and many open-source customer contributions, including both debugging and feature enhancement.

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 Multiple Virtual Storage (MVS) region, operated with the same memory protection key including the CICS kernel code. Program corruption and CICS control block corruption was a frequent cause of system downtime. A software error in one application program could overwrite the memory (code or data) of one-or-all currently-running application transactions. Locating the offending application code for complex transient timing errors could be a very-difficult operating-system analyst problem.

These serious shortcomings persisted for multiple new releases of CICS over a period of more than 20 years. CICS application transactions were often mission-critical for public utility companies, large banks and other multi-billion-dollar financial institutions. Top-quality CICS skills were in high demand and short supply. The complex learning curve was shallow and long. Unqualified novice developers could have a major negative impact on company operations.

Eventually, it became possible to provide a measure of advance application protection by performing all testing under control of a monitoring program that also served to provide Test and 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.