The IMS Database component stores data using a hierarchical model, which is quite different from IBM's later released relational database, Db2. In IMS, the hierarchical model is implemented using blocks of data known as segments. Each segment can contain several pieces of data, which are called fields. For example, a customer database may have a root segment (or the segment at the top of the hierarchy) with fields such as phone, name, and age. Child segments may be added underneath another segment, for instance, one order segment under each customer segment representing each order a customer has placed with a company. Likewise, each order segment may have many children segments for each item on the order. Unlike other databases, you do not need to define all of the data in a segment to IMS. A segment may be defined with a size of 40 bytes but only define one field that is six bytes long as a key field that you can use to find the segment when performing queries. IMS will retrieve and save all 40 bytes as directed by a program but may not understand (or care) what the other bytes represent. In practice, often all data in a segment may map to a COBOL copybook. Besides DL/I query usage, a field may be defined in IMS so that the data can be hidden from certain applications for security reasons. The database component of IMS can be purchased standalone, without the transaction manager component, and used by systems such as CICS.
There are three basic forms of IMS hierarchical databases:
"Full Function" databases
Directly descended from the Data Language Interface (DL/I) databases originally developed for Apollo, full function databases can have primary and secondary indexes, accessed using DL/I calls from an application program, like SQL calls to Db2 or Oracle.
Full function databases can be accessed by a variety of methods, although Hierarchical Direct (HDAM) and Hierarchical Indexed Direct (HIDAM) dominate. The other formats are Simple Hierarchical Indexed Sequential (SHISAM), Hierarchical Sequential (HSAM), and Hierarchical Indexed Sequential (HISAM).
Full function databases store data using VSAM, a native z/OS access method, or Overflow Sequential (OSAM), an IMS-specific access method that optimizes the I/O channel program for IMS access patterns. In particular, OSAM performance benefits from sequential access of IMS databases (OSAM Sequential Buffering).
"Fast Path" databases
Fast Path databases are optimized for extremely high transaction rates. Data Entry Databases (DEDBs) and Main Storage Databases (MSDBs) are the two types of Fast Path databases. DEDBs use a direct (randomizer) access technique similar to Full Function HDAM and IMS V12 provided a DEDB Secondary Index function. MSDBs do not support secondary indexing. Virtual Storage Option (VSO) DEDBs can replace MSDBs in modern IMS releases, so MSDBs are gradually disappearing.
DEDB performance comes from use of high performance (Media Manager) access method, asynchronous write after commit, and optimized code paths. Logging is minimized because no data is updated on disk until commit, so UNDO (before image) logging is not needed, nor is a backout function. Uncommitted changes can simply be discarded. Starting with IMS Version 11, DEDBs can use z/OS 64-bit storage for database buffers. DEDBs architecture includes a Unit of Work (UOW) concept which made an effective online reorganization utility simple to implement. This function is included in the base product.
High Availability Large Databases (HALDBs)
IMS V7 introduced HALDBs, an extension of IMS full function databases to provide better availability, better handling of extremely large data volumes, and, with IMS V9, online reorganization to support continuous availability. (Third party tools exclusively provided online reorganization prior to IMS V9.) A HALDB can store in excess of 40 terabytes of data.
Fast path DEDBs can only be built atop VSAM. DL/I databases can be built atop either VSAM or OSAM, with some restrictions depending on database organization. Although the maximum size of a z/OS VSAM dataset increased to 128 TB a few years ago, IMS still limits a VSAM dataset to 4 GB (and OSAM to 8 GB). This "limitation" simply means that IMS customers will use multiple datasets for large amounts of data. VSAM and OSAM are usually referred to as the access methods, and the IMS "logical" view of the database is referred to as the database "organization" (HDAM, HIDAM, HISAM, etc.) Internally the data are linked using 4-byte pointers or addresses. In the database datasets (DBDSs) the pointers are referred to as RBAs (relative byte addresses).
Collectively the database-related IMS capabilities are often called IMS DB. IMS DB has grown and evolved over nearly four decades to support myriad business needs. IMS, with assistance from z/OS hardware – the Coupling Facility – supports N-way inter-IMS sharing of databases. Many large configurations involve multiple IMS systems managing common databases, a technique providing for scalable growth and system redundancy in the event of hardware or software failures.