Soon after IBM introduced modern mainframes, it became apparent that the mainframe needed to interact with human operators and perform general business processing in real time. This required a different kind of processing involving short and fast units of work that interacted with a screen–called transaction processing. A little later, someone added the idea of data integrity and atomic transactions to the feature set. IBM created two distinct types of transaction processors to meet these needs; the Customer Information Control System (CICS) and Information Management Systems/Transaction Manager (IMS/TM). To manage, protect and organize data, Information Management System/Database (IMS/DB) and DB2 were born. This tip highlights the history and explains the advantages and disadvantages of these popular systems.
Customer Information Control System (CICS)
CICS began life in 1968 as a free online processing system targeted for utility companies. At first, it supported only Assembler programs, but IBM added COBOL and PL/1 a couple of years later. True to its Assembler roots, CICS’ original application programming interface (API) used macros, even for higher-level languages, which looked kind of weird. In the late '70s, IBM introduced the command-level interface, which gradually replaced the macro API. The command API remains the foundation of the product to this day.
Along the way, CICS added support for Virtual Storage Access Method (VSAM) datasets, then IMS and DB2 database management systems (DBMS). It grew in power and flexibility with features such as multi-region operation (MRO), function shipping and dynamic transaction routing. The 21st century saw CICS move into the Internet age with support for service-oriented architecture (SOA), event processing and various Web 2.0 features.
Today, CICS is the mainframe’s most popular transaction processor. It runs on mainframe systems in more than 90% of Fortune 500 companies, powering ATMs, green screens and webpages the world over.
- Can do a lot of work in a small footprint. A single CICS address space can execute millions of transactions while utilizing relatively few resources.
- MRO, coupled with dynamic routing, makes distributed, high-availability solutions easy to implement.
- Can work with major DBMSs as well as flat files and VSAM.
- Supports SNA, TCP/IP, SOA and has an External Call Interface from non-CICS environments
- Can expose legacy systems for SOA
- Cooperative processing environment means all transactions must play nicely, or the CICS address space may bog down or become disrupted.
- Vulnerable to storage overlays when programs inadvertently overlay memory that doesn’t belong to them. A bad overlay could corrupt databases, ABEND innocent transactions or bring CICS down.
- Some programming restrictions and requirement to avoid operating system (OS) calls, which can impede CICS performance at best or cause the whole region to hang up at worst.
Information Management System (IMS)
IBM co-designed IMS with Rockwell International in 1966 to track inventory for the Apollo space program. By 1968, IMS was up and taking online traffic on mainframe systems. After landing a man on the moon, IMS moved on to become the transaction processor of choice for IBM’s largest customers.
IMS/Database (IMS/DB) quickly became the first industrial-strength, full scale DBMS available in the world. Programs accessed the hierarchical databases with a simple call interface using Data Language One (DL/1 or DL/I, some people are still arguing about it). IMS/DB introduced fast-path database for even better performance. In the '80s, IMS added a DB2 interface, giving users a chance to use the best of both types of databases. Lastly, in the '90s, IMS was right there with the mainframe Parallel Sysplex, able to share databases in an IMSPlex.
IMS comes into the 21st century with support for SOA and TCP/IP. In addition to all the traditional mainframe languages, v10 added support for Java. Now it is poised for the future with Dynamic Resource Definition and Common Service Layer that presents a single system image in an IMSPlex.
- Application programs are isolated from system code and each other. This separation makes badly behaving transactions easier to handle and less likely to bring the system down.
- Hierarchical databases, especially Fast Path (a stripped down version of IMS full-function databases), are very fast and easy to maintain.
- Industrial strength message and data integrity. IBM even wrote a utility to retrieve database buffers from a standalone dump (SAD) when the system freezes.
- Few programming restrictions; application programs can use OS APIs.
- Asynchronous nature sometimes requires applications to operate in a pseudo-synchronous manner. For example, to interact with another subsystem, a transaction has to send a message and terminate, effectively committing database updates. The answer would arrive in a separate unit of work where another transaction completes the exchange. However, if the request out didn't work, the application, not the system, has to back out any database changes.
- SOA support still needs fleshing out, such as the ability to manipulate SOAP message headers.
- Size of system may be limited by IMS’ common storage usage, which depends on the number of dependent regions, database buffers and defined resources.
- Database navigation requires knowledge of database structure.
In June 1970, Edgar Codd, an IBM employee, published a paper outlining the concept of relational databases. After some foot dragging, IBM developed the idea into System R, which was later released as DB2. DB2 was not the first relational database on the market, but it was new to big iron. IBM customers spent some time scratching their heads trying to figure out where it fit in mainframe systems already dominated by IMS/DB.
DB2 brought with it a new data language, Structured Query Language (SQL), which was already in common use. SQL provided a simpler, more intuitive interface that concentrated more on what the programmer wanted and less on how to get there. Mainframe users soon realized the productivity gains were worth the slight performance penalty inherent in relational databases.
Mainframe shops enthusiastically embraced DB2 through the late '80s and early '90s. In the meantime, IBM improved DB2 into a robust, scalable system that could handle ever increasing volumes of data. DB2 also had first day support for Parallel Sysplex with the ability to share data across LPARs.
Today, some form of DB2 runs on every major platform, from mainframe systems to Linux, Unix and Windows. DB2 also supports many of the new programming schemes, such as extensible markup language and stored procedures. Distributed data facility makes it easy for clients to get to mainframe data. In addition, every new release touts better performance and reliability, easily supporting billion-row tables.
- High performance, industrial-strength relational database
- Very dynamic system and database configuration
- Native stored procedures can exploit zIIP specialty engines
- Very scalable
- Database locking and performance can sometimes be difficult to diagnosis
- Database utilities sometimes have difficulty sharing table access with ongoing application activity. This creates problems for online reorgs and structural database changes.
- DB2 data sharing groups often have to grow in parallel for availability and to avoid problems associated with running out of virtual storage.
About the expert: Robert Crawford has been a systems programmer for 29 years. While specializing in CICS technical support he has also worked with VSAM, DB2, IMS and assorted other mainframe products. He has programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. The latest phase in his career finds him an operations architect responsible for establishing mainframe strategy and direction for a large Insurance company. He lives and works with his family in south Texas.<