IBM Information Management System

IBM Information Management System

Initial release 1966 (1966)
Stable release
IMS V14 / October 5, 2015 (2015-10-05)
Development status Active
Operating system z/OS V2.1 or later
Platform IBM System z
Type Database & transaction processing subsystem
License proprietary
Website IMS V14 Announcement PDF

IBM Information Management System (IMS) is a joint hierarchical database and information management system with extensive transaction processing capabilities.

History

IBM designed the IMS with Rockwell and Caterpillar starting in 1966 for the Apollo program, where it was used to inventory the very large bill of materials (BOM) for the Saturn V moon rocket and Apollo space vehicle.

The first "IMS READY" message appeared on an IBM 2740 terminal in Downey, California, on 14 August 1968.[1] In the interim period, IMS has undergone many developments as IBM System/360 technology evolved into the current z/OS and System z9 and z10 technologies. For example, IMS now supports the Java programming language, JDBC, XML, and, since late 2005, web services.

Vern Watts was IMS's chief architect for many years. Watts joined IBM in 1956 and worked at IBM's Silicon Valley development labs until his death on April 4, 2009.[2] He had continuously worked on IMS since the 1960s.[3]

Database

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

"Fast Path" databases

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)

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.

Transaction Manager

IMS is also a robust transaction manager (IMS TM, also known as IMS DC) — one of the "big three" classic transaction managers along with CICS and BEA (now Oracle) Tuxedo. A transaction manager interacts with an end user (connected through VTAM or TCP/IP, including 3270 and Web user interfaces) or another application, processes a business function (such as a banking account withdrawal), and maintains state throughout the process, making sure that the system records the business function correctly to a data store. Thus IMS TM is quite like a Web application, operating through a CGI program (for example), to provide an interface to query or update a database. IMS TM typically uses either IMS DB or DB2 as its backend database. When used alone with DB2 the IMS TM component can be purchased without the IMS DB component.

IMS TM uses a messaging and queuing paradigm. An IMS control program receives a transaction entered from a terminal (or Web browser or other application) and then stores the transaction on a message queue (in memory or in a dataset). IMS then invokes its scheduler on the queued transaction to start the business application program in a message processing region. The message processing region retrieves the transaction from the IMS message queue and processes it, reading and updating IMS and/or DB2 databases, assuring proper recording of the transaction. Then, if required, IMS 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. IMS TM can handle this whole process thousands (or even tens of thousands) of times per second. A recently completed IBM benchmark demonstrated the ability to process 100,000 transactions per second on a single IMS system.

Application

Prior to IMS, businesses and governments had to write their own transaction processing environments. IMS TM provides a straightforward, easy-to-use, reliable, standard environment for high performance transaction execution. In fact, much of the world's banking industry relies on IMS , including the U.S. Federal Reserve. For example, chances are that withdrawing money from an automated teller machine (ATM) will trigger an IMS transaction. Several Chinese banks have recently purchased IMS to support that country's burgeoning financial industry.

Today IMS complements DB2, IBM's relational database system, introduced in 1982. In general, IMS performs faster than DB2 for the common tasks but may require more programming effort to design and maintain for non-primary duties. Relational databases have generally proven superior in cases where the requirements, especially reporting requirements, change frequently or require a variety of viewpoint "angles" outside the primary or original function.

A relational "data warehouse" may be used to supplement an IMS database. For example, IMS may provide primary ATM transactions because it performs well for such a specific task. However, nightly copies of the IMS data may be copied to relational systems such that a variety of reports and processing tasks may be performed on the data. This allows each kind of database to focus best on its relative strength.

See also

References

  1. ↑ "IMS and the Apollo program". IBM. Retrieved 2015-05-29.
  2. ↑ IBM IMS Newsletter Volume 902
  3. ↑ Luongo, Chris et al. (October 2008). The Tale of Vern Watts. International Business Machines Corporation. Retrieved April 7, 2009.
  4. ↑ IBM’s Information Management System (IMS) Institute for Data Center Professionals
  5. ↑ Lewis, Rich et al. (June 2003). The Complete IMS HALDB Guide All You Need to Know to Manage HALDBs. International Business Machines Corporation. p. 4. ISBN 0-7384-5343-9. Retrieved on June 21, 2008.

External links

This article is issued from Wikipedia - version of the 12/1/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.