IBM Information Management System

IMS began as a hierarchical database designed for Rockwell for the Apollo program. It was used to track the bill of materials for the Saturn V.

IMS is still running thirty five years later and over time has seen some interesting developments as IBM S/360 technology developed into the current z/OS operating system.

There are three basic forms of hierarchical database.

Full function, which is basically the same Data Language/1 (DL/I) databases as developed for Apollo. Full function databases can have primary and secondary indexes and are accessed using DL/I calls from your application program.

Full function databases can have a variety of access methods, although Hierarchical Direct (HDAM) and Hierarchical Indexed Direct (HIDAM) prevail. The other formats are Simple Hierarchical Indexed Sequential (SHISAM), Hierarchical Sequential (HSAM) and Hierarchical Indexed Sequential (HISAM).

Data in full function databases can be stored using VSAM (a native MVS access method) or Overflow Sequential (OSAM), an IMS specific access method that optimizes the channel program for IMS access. OSAM has the advantage that there is special handling in IMS for sequential access of OSAM databases (OSAM Sequential Buffering) which has a performance benefit.

IMS also has fast path databases - Data Entry Databases (DEDB) and Main Storage Databases (MSDB). These two types of database don't allow for any indexation, but are optimized for extremely high transaction rates. With modern releases of IMS MSDBs can be replaced by a Virtual Storage Option (VSO) DEDB.

The third type of database High Availability Large Database (HALDB) was introduced with IMS V7.1. This is an extension of IMS full function databases to provide better availability, better handling of extremely large data volumes (and with IMS Version 9 to provide online re-organization).

IMS is also a transaction manager. A transaction manager interacts with an end user (connected through VTAM or TCP/IP) and like a web server running a CGI program provides an interface to query or update IMS or DB2 databases. IMS uses an messaging an queuing paradigm. A transaction entered from a terminal is received by the IMS control program and stored on a message queue (in storage or on a dataset). When a transaction has been queued IMS invokes it's schedular to start the users application program in a message processing region. The message processing region retrives the transaction from the IMS message queue processes it reading and updating IMS and DB2 databases, then if required enqueues a response message back onto the IMS message queue. Once the output message is complete and available the IMS control program sends it back to the originating terminal.

If you have ever withdrawn money from an automated teller machine (ATM) there is a fair chance that transaction will have run in an IMS system. Not bad for a product that is more than 35 years old.