IMS has been an important part of world-wide computing since its inception.

On May 25, 1961, United States President John F. Kennedy challenged American industry to send an American man to the moon and return him safely to earth. The feat was to be accomplished before the end of the decade, as part of the Apollo program. American Rockwell won the bid to build the spacecraft for the Apollo program and, in 1965, they established a partnership with IBM to fulfill the requirement for an automated system to manage large bills of material for the construction of the spacecraft. In 1966, 12 members of the IBM team, along with 10 members from American Rockwell and 3 members from Caterpillar Tractor, began to design and develop the system that was called Information Control System and Data Language/Interface (ICS/DL/I). During the design and development process, the IBM team was moved to Los Angeles and increased to 21 members. The IBM team completed and shipped the first release of ICS in 1967. In April, 1968, ICS was installed. The first "READY" message was displayed on an IBM 2740 typewriter terminal at the Rockwell Space Division at NASA in Downey California, on August 14, 1968. In 1969, ICS was renamed to Information Management System/360 (IMS/360) and became available to the IT world. Since 1968, IMS:

y Helped NASA fulfill President Kennedy's dream. y Started the database management system revolution. y Continues to evolve to meet and exceed the data processing requirements demanded by today's businesses and governments.
IMS is Strategic for Addressing Customer Needs Customer acceptance of new IMS versions is the best measure of its strategic value. In 2003, the IMS workload, as measured in the millions of instructions per second (MIPS) capacity of IMS systems, increased 67.9% on our latest versions. At the end of 2003, there was almost three times more work being done on our latest versions, Version 7 and Version 8, than on older versions, Versions 5 and Version 6, worldwide. Overall, in 2003, MIPS of IMS systems grew almost 20%. By midyear, IMS Version 7 surpassed IMS Version 6 as the most popular version, measured by number of licenses. Overall, the growth of net new IMS licenses remained positive, fueled largely by expansions required because of mergers and acquisitions among existing customers (in the Americas and Europe) and the selection of IMS for new zSeries footprints (predominantly by emerging opportunities in Asia). It is noteworthy that customers showed continued confidence in the future of IMS, during the years 20012003, when much of the rest of the IT industry was showing a downturn and retrenchment.
Who Uses IMS

Over 90 percent of the top world-wide companies in the following industries use IMS to run their daily operations:

y y y y y y

Manufacturing Finance Banking Retailing Aerospace Communications

y y y y

Government Insurance High technology Health Care

The following quote is an example of how one analyst1 views IMS:

y A 35-year-old hierarchical database and transaction processing system is currently growing faster than the world's most popular relational database system. Pretty funny, huh?
Actually, IMS is not forging new ground with innovative marketing or customer-acquisition strategies. It's more the other way around--it's keeping the same old customer base, but the base is growing, a lot. IMS and the mainframes it runs on underpin the vast majority of banks and banking transactions worldwide. And the banking world is growing. China alone may provide more growth in the next few years than the rest of world has in the last decade, and it is certainly not the only Pacific Rim country modernizing its banking system. Combine that kind of geographic growth with advances in online banking in the developed world and it's no wonder mainframes, especially IBM's newer zSeries machines, and IMS are growing. They're the only products capable of keeping up. IMS is still a viable, even unmatched, platform to implement very large online transaction processing (OLTP) systems and, in combination with Web Application Server technology, it is the foundation for a new generation of Web-based, high-workload applications. Here are some interesting facts about how IMS is used. IMS manages a large percentage of the world's corporate data

y y y

Over 95% of Fortune 1000 companies use IMS. IMS manages over 15 million gigabytes of production data. $2.5 trillion (in US dollars) per day is transferred through IMS by one customer.

IMS processes over 50 billion transactions per day

y y y y y

IMS serves over 200 million users every day. IMS processes over 100 million transactions per day for one customer. IMS processes over 120 million transactions per day (7 million per hour) for another customer. IMS can process 21 000 transactions per second (over 1 billion2 per day) using IMS data sharing and shared queues. A single IMS has processed over 6000 transactions per second over a single TCP/IP connection.

Related Reading: To learn more about the industries and customers that use IMS, visit the IMS Web site at www.ibm.com/ims, and click "Featured Customer", "IMS Newsletter", or "Overview". IMS is Strategic for Addressing IBM Needs IMS's strategic value to IBM can be measured in three areas:

y IMS is Strategic in the On Demand Infrastructure y IMS is Strategic Regarding Continued Investment y IMS is Strategic For the Future
IMS is Strategic in the On Demand Infrastructure

IBM defines an on demand enterprise as one whose business processes are integrated end-to-end across the company and with key partners, suppliers, and customers. An on demand enterprise can respond with flexibility and speed to any customer demand, any market opportunity, and any external threat. This need to respond with urgency must be addressed by an on demand infrastructure. This infrastructure is: Based on open standards IMS fully supports Java standards for application development and XML for transparent document interchange. Heterogeneous IMS applications can be developed on workstations and executed in the host environment. IMS applications and data can be accessed from any platform, including Linux, virtually anywhere on the Internet, through the utilization of the IMS Connect function and the IMS Connector for Java. Integrated Integration has always been an IMS priority. IMS ships connectors and tooling with IBM WebSphere solutions so customers can connect to IMS applications and data utilizing the tools and connectors of their choice. Scalable IMS continues to address scalability needs by providing the highest possible availability, performance, and capacity. IMS Version 8 benchmarks show a single system providing 21 000 transactions, including database access, per second. IMS Version 9 continues this performance and offers 24 x 7 database availability with High Availability Large Database Online Reorganization support. Enabled with self-managing capabilities IMS Version 8 and Version 9 address the need to assist technical support staff in being more productive, keep systems continuously available, and do so in an operating environment that is growing more and more complex. IMS Version 8 contains over a dozen new and improved self-managing functions to enhance the productivity and effectiveness of database administrators and systems programmers. These functions and more are available with IMS Version 9. Reliable One large IMS customer has operated over 3000 days (and counting) without an outage in a 24 x 7 environment.
IMS is Strategic Regarding Continued Investment

The ability of the IMS team to deliver revenue growth to the IBM company is a measure of our success as business managers. Success in this area supports continued investment by IBM in the development of future versions and the growth of resources devoted to that effort. In 2003, IMS enjoyed another record breaking year, surpassing 2002 as the largest revenue producing year in its 35-plus year history. In the first two quarters of 2004, IMS's revenue grew 9% (year to year). IMS has shown consistent revenue growth each year since adopting the current IMS business model in 2000.
IMS is Strategic For the Future

The focus for IMS in 2004, and beyond, is striving to remain the strategic choice for:

y y

The most business-critical applications of our current customers. The most business-critical applications of emerging enterprises.

Success in that area and support of the open, integrated, self-managing, on demand operating environment, suggest that IMS will continue as a major factor in the growth strategy of the IBM Corporation, as it has been for the past 36 years. IMS consists of three components:

y The Database Manager (IMS DB) y The Transaction Manager (IMS TM) y A set of system services that provide common services to IMS DB and IMS TM
Known collectively as IMS DB/DC3, the three components create a complete online transaction processing environment that provides continuous availability and data integrity. The functions provided by these components are described in more detail later in this information. IMS delivers accurate, consistent, timely, and critical information to application programs, which deliver the information to many end users simultaneously. IMS has been developed to provide an environment for applications that require very high levels of performance, throughput, and availability. IMS uses many of the facilities offered by the operating system and hardware. Currently, IMS runs on z/OS and on zSeries hardware. IMS TM and IMS DB can be ordered and paid for separately if the functions of one component is not required. The appropriate system services are provided for the component ordered. When IMS DB is ordered by itself, it is called DB control (DBCTL). When IMS TM is ordered by itself, it is called DC control (DCCTL). IMS is developed so that each new release of IMS is upwardly compatible, meaning that applications that were written for a previous release of IMS will run without modification (in most cases) with a new release. In this way, IMS protects the investment that our customers have made in their applications. To accommodate the changing requirements of IT systems, many new features have been added to IMS over the years. In many instances, older features have been wholly or partially superseded by the newer features that provide better functionality. Application programs that are written to use IMS functions can be written in a number of programming languages: Assembler, C/C++, COBOL, Java, Pascal, PL/I, and REXX. These applications access IMS resources by calling a number of standard IMS functions through standard application programming interfaces (APIs):

y DL/I y Java database connectivity (JDBC)

IMS Database Manager

IMS DB is a DBMS that helps you organize business data with both program and device independence. Hierarchical databases and data manipulation language (DL/I calls) are at the heart of IMS DB. Data within the database is arranged in a tree structure, with data at each level of the hierarchy related to, and in some way dependent upon, data at the higher level of the hierarchy. Figure 1 shows the

hierarchical database model. In a hierarchical database, data is stored within the database only once. The data item is then available to any user who is authorized to use it. Users do not need to have personal copies of the data. Figure 1. Hierarchical Database Model

With IMS DB, you can:

y y y y y y y

Maintain data integrity. The data in each database is guaranteed to be consistent and guaranteed to remain in the database even when IMS DB is not running. Define the database structure and the relationships among the database elements. Provide a central point of control and access for the IMS data that is processed by IMS applications. Perform queries against the data in the database. Perform database transactions (inserts, updates, and deletes) as a single unit of work so that the entire transaction either occurs or does not occur. Perform multiple database transactions concurrently with the results of each transaction kept isolated from the others. Maintain the databases. IMS DB provides facilities for tuning the databases by reorganizing and restructuring them.

Additionally, IMS DB lets you adapt IMS databases to the requirements of varied applications. Application programs can access common and, therefore, consistent data, thereby reducing the need to maintain the same data in multiple ways in separate files for different applications. IMS databases are accessed internally using a number of IMS's database organization access methods. The actual database data is stored on disk storage using normal z/OS access methods. See the complete version of An Introduction to IMS. IMS DB provides access to these databases from applications running under:

y y

IMS Transaction Manager CICS Transaction Server for OS/390 and z/OS

y y y

z/OS batch jobs WebSphere Application Server for z/OS DB2 UDB for z/OS stored procedures

IMS Transaction Manager

IMS TM is a message-based transaction processor. Definitions:

A transaction is a specific set of input data that triggers the execution of a specific business application program (a process or job). The message that triggers the application program, and the return of any results, is considered one transaction. The word terminal is used throughout this information to describe devices and controllers. The operator terminals can be keyboard printers, display stations with keyboards, communication terminals, or a mixture of these devices.

IMS TM provides services to:

y y y y

Process input messages received from a variety of sources (such as the terminal network, other IMSs, and the Web). Process output messages created by application programs. Provide an underlying queueing mechanism for handling these messages. Provide high-volume, high-performance, high-capacity, low-cost transaction processing for both IMS DB's hierarchical databases and DB2's relational databases.

IMS TM supports many terminal sessions (on a wide variety of terminals and devices) at extremely high transaction volumes. The users of the terminal sessions can be:

y y

People at terminals or workstations. Other application programs, either on the same z/OS system, on other z/OS systems, or on non-z/OS platforms.

When IMS TM is used in conjunction with a database manager, IMS TM extends the facilities of the database manager to the online, real-time environment. IMS TM enables terminals, other devices, subsystems to enter transactions that initiate application programs, which access IMS DB or DB2 databases and return results. You can define a variety of online processing options. For example, you can define transactions for high-volume data-entry applications, others for interactive applications, and still others to support predefined queries. IMS TM also enables you to develop a wide range of high-volume, rapid-response applications, and to geographically disperse your data processing locations while keeping centralized control of your database.

IMS System Services

IMS System Services provide the following services to both IMS DB and IMS TM:

y y y

Provide data integrity Restart and recover IMS after failures Provide security, by controlling access to and modification of IMS resources

y y y y

Manage the application programs, by dispatching work, loading application programs, and providing locking services Provide diagnostic and performance information Provide facilities for operating IMS Provide interfaces to other z/OS subsystems that communicate with IMS applications

The IMS System Services are by:

y y y y

Issuing IMS commands Running IMS-supplied utility programs Running IMS-supplied or user-written exit routines Defining the services you want as part of the system definition process

Hardware and Software Requirements for IMS

This section briefly describes the hardware and software that is required by IMS. Related Reading: For the complete details about the hardware and software requirements and compatibility of IMS releases with versions of the operating system and associated products, see the following release planning guides:

y y y

IMS Version 9: Release Planning IMS Version 10: Release Planning IMS Version 11: Release Planning

Hardware IMS Version 9 runs on all IBM processors that are capable of running z/OS System Product Version 1 Release 4 or later. IMS Version 9 can run on either 64-bit processors or 32-bit processors. For all system libraries and working storage space, any device that is supported by the operating system is allowed.

Details about the DASD storage requirements for the following items are listed in the IMS Version 9: Program Directory for Information Management System Transaction and Database Servers:

y y y y y y

SMP/E system entries SMP/E data sets Target libraries Distribution libraries Install process Optional machine-readable material

Software

IMS Version 9 operates in z/OS Version 1 Release 4 (or later) configurations and requires the following minimum version, release, or modification levels:

z/OS Version 1 Release 4 (5694-A01) o DFSMS* o SMP/E* o JES2* o JES3* o TSO/E* Note: * These items are base elements of the z/OS operating environment that cannot be ordered separately. o IBM High-Level Assembler Toolkit (5696-234), a separately orderable feature of z/OS o RACF (available with the IBM SecureWay Security Server for z/OS and OS/390 RACF product) or equivalent product, if security is used o ISPF Version 4 Release 2 (5655-042) o e-Network Communications Server for z/OS, if IMS Transaction Manager is used IRLM Version 2.1 or later (5655-DB2), if data sharing is used

IMS Version 9 also operates in a virtual machine (VM) under the control of z/OS Version 1 Release 4. This environment is intended for use in a program development, testing, and non-XRF production environment.
CICS Subsystems Supported

IMS DB Version 9 can be connected (using the IMS Database Resource Adapter) to the following systems:

y y

CICS Transaction Server for z/OS Version 2.2 (5697-E93) CICS Transaction Server for OS/390 Version 1.3 (5655-147)

IMS TM Version 9 can be connected (using the appropriate TM interface) to the following systems:

y y

CICS Transaction Server for z/OS Version 2.2 (5697-E93) CICS Transaction Server for OS/390 Version 1.3 (5655-147)

DB2 Subsystems Supported

IMS TM Version 9 can be connected to any of the following DB2 products:

y y y

DB2 UDB for z/OS Version 8 (5625-DB2) DB2 for z/OS and OS/390 Version 7 (5675-DB2) DB2 Universal Database for OS/390 Version 6 (5645-DB2)

Programming Language

IMS Version 9 is written in High Level Assembler Release 2, PL/X, C, C++, and Java JDK Version 1.3.
Programming Languages Supported

You can write IMS applications in the current versions of the following languages:

y y

ADA COBOL for OS/390 & VM

y y y y y y y y

Enterprise COBOL for z/OS and OS/390 High Level Assembler for MVS & VM & VSE Version 1 Release 4.0 IBM SDK for z/OS Java 2 Technology Edition, Version 1.3.1 PL/I for z/OS and OS/390 TSO/E REXX VS Pascal WebSphere Studio Site Developer Version 5.0 z/OS C/C++

Requirement: The following languages require the IBM Language Environment for z/OS:

y y

COBOL for OS/390 & VM PL/I for z/OS and OS/390

Accessing IMS
In a broad sense, accessing IMS means telling IMS to perform work for you.

y y

You can write application programs that tell IMS what to do. You can use existing application programs that tell IMS what to do.

These application programs can run in many different environments. They tell IMS what to do by calling a number of standard IMS functions through standard APIs: DL/I and JDBC4. In This Section:

y y

Accessing IMS From Application Programs Accessing IMS from Other Products

Accessing IMS From Application Programs

Application programs that directly use the DL/I interface do so by issuing DL/I calls. Application programs that use the JDBC interface do so by issuing standard SQL (structured query language) calls.

Accessing IMS from Other Products

The scope of these topics is not large enough to fully explain all the products and protocols that can access IMS. Instead, some of these products and protocols are briefly mentioned in the following sections to demonstrate that you can access IMS from almost anywhere in the IT world. Some products are shown in both Figure 4 and Figure 5, which indicates that these products can access both IMS DB and IMS TM. Accessing IMS DB Figure 4 shows the main interfaces to IMS DB (IMS TM, the ODBA interface, and the DRA interface), along with some of the products that use the ODBA and DRA interfaces.

Figure 4. Accessing IMS DB from Other Programs

The following components and products are shown in Figure 4:

y y y y y y

y y

DL/I. DRA: The DRA comes with IMS DB, but is run where it is used, not within IMS. ODBA: ODBA comes with IMS DB, but, like the DRA, is run where it is used, not within IMS. Distributed z/OS applications: Any z/OS application that follows the guidelines and rules associated with the ODBA interface can access IMS. WebSphere Application Server for z/OS. CICS: IBM CICS Transaction Server for z/OS, an IBM licensed program that provides online transaction-processing services and management for business applications. CICS can be a transaction manager for either IMS DB or DB2 UDB for z/OS. In Figure 4, CICS application programs that need to access IMS DB can do so in two ways: o Directly through the DRA by issuing CICS EXEC DL/I calls. o Through the DRA using the IMS Java function and issuing the supported SQL calls. DB2 UDB for z/OS: IBM's premier database manager for relational databases. Stored procedures that run in DB2 UDB for z/OS can access IMS DB through ODBA. IBM WebSphere MQ for z/OS: A z/OS subsystem that supports the transfer of messages across z/OS address spaces and to other WebSphere MQ products on both IBM and nonIBM platforms. The platforms include AIX, iSeries, OS/2, VSE/ESA, HP-UX, Solaris, Windows, Compaq NonStop Kernel, Compaq Tru64 UNIX, Compaq OpenVMS (Alpha), and Linux, using the IBM SNA LU 6.2 or TCP/IP communications protocols. IBM IMS DataPropagator:Figure 4 also shows WebSphere MQ for z/OS working in conjunction with IMS DataPropagator and DB2 UDB for z/OS to replicate IMS data across the DB2 family of databases.

Accessing IMS TM Figure 5 shows the main interfaces to IMS TM (the OTMA interface, the IMS Connect function, VTAM, and APPC), along with some of the products and protocols that use these interfaces. Figure 5. Accessing IMS TM from Other Programs

The following components and products are shown in Figure 5:

y DL/I. y Advanced Program-to-Program Communications (APPC): An implementation of the SNA LU 6.2 protocol that allows interconnected systems to communicate and share the processing of programs. For more information about IMS TM and APPC, see the complete version of An Introduction to IMS. y z/OS Communications Server: z/OS Communications Server provides both System Network Architecture (SNA) and Transmission Control Protocol/Internet Protocol (TCP/IP) networking protocols for z/OS. The SNA protocols are provided by Virtual Telecommunications Access Method (VTAM) and include Subarea, Advanced Peer-to-Peer Networking, and High Performance Routing protocols. For more information on z/OS Communications Server SNA protocols or TCP/IP networking protocols for z/OS, see z/OS V1R4.0 z/OS Communications Server SNA Network Implementation Guide. y Communication Controller and Network Control Program (NCP): A combination of hardware and software that provides support for single-domain, multiple-domain, and interconnected network capability. The NCP is an IBM licensed program. y SNA Network: Existing (traditional) network that implements the SNA protocols6 to connect terminals and other devices. y Server Layer for End User: One or more middleware software products that interact with the end user, for example, TN3270 client (TN3270 Telnet server acts as an interface between IP and SNA networks), WebSphere Application Server, or WebSphere MQ Everyplace. y Control Center for IMS: A workstation graphical interface from which you can manage your IMS systems. The Control Center connects to IMS through a TCP/IP network, IMS Connect, and the Structured Call Interface (SCI). For more information about the Control Center, see IMS Control Center. y OTMA: An open interface to IMS TM through which a z/OS or TCP/IP application program can send a transaction or command to IMS without using SNA or VTAM. y IBM WebSphere MQ for z/OS: A z/OS subsystem that supports the transfer of messages across z/OS address spaces and to other WebSphere MQ products on both IBM and nonIBM platforms. The platforms include AIX, iSeries, OS/2, VSE/ESA, HP-UX, Solaris, Windows, Compaq NonStop Kernel, Compaq Tru64 UNIX, Compaq OpenVMS (Alpha), and Linux, using the SNA LU 6.2 or TCP/IP communications protocols. y CICS: In Figure 5, CICS application programs that need to access IMS TM can do so by using the OTMA callable interface. y DB2 UDB for z/OS: IBM's premier database manager for relational databases. IMS TM can provide transaction processing services for DB2 UDB for z/OS.

IMS and z/OS

These topics describe how IMS subsystems are implemented on a z/OS system and how IMS uses some of the facilities that are a part of the z/OS operating system. In This Section:

y y y y y

How IMS Relates to z/OS Structure of IMS Subsystems Running an IMS System Running Multiple IMS Systems How IMS Uses z/OS Services

How IMS Relates to z/OS

IMS is a large application that runs on z/OS. There is a symbiotic relationship between IMS and z/OS. Both are tailored to provide the most efficient use of the hardware and software components. IMS runs as a z/OS subsystem and uses several address spaces: one controlling address space, several separate address spaces that provide IMS services, and several address spaces that run IMS application programs. z/OS address spaces are sometimes called regions7, as in the IMS control region. The term region is synonymous with a z/OS address space. The various components of an IMS system are explained in more detail in Structure of IMS Subsystems.

7. The concept of a region originated in the MVT (Multiprogramming with Variable Number of Tasks) operating system, a precursor to z/OS.

Structure of IMS Subsystems

This section describes the various types of z/OS address spaces and their interrelationships. The control region is the core of an IMS subsystem, running in one z/OS address space. Each control region uses many other address spaces that provide additional services to the control region, and in which the IMS application programs run. Some IMS applications and utilities run in separate, standalone regions, called batch regions. Batch regions are separate from an IMS subsystem and its control region and have no connection with it. For more information, see IMS Batch Environment.

IMS Control Region The IMS control region is a z/OS address space that can be initiated through a z/OS START command or by submitting job control language (JCL)8 job. The IMS control region provides the central point of control for an IMS subsystem. The IMS control region:

y Provides the interface to z/OS for the operation of the IMS subsystem. y Controls, schedules, and dispatches the application programs that are running in separate regions, called dependent regions. y Provides the interface to the SNA network for IMS TM functions. y Provides the OTMA interface for access to non-SNA networks. y Provides the ODBA interface for DB2 UDB for z/OS stored procedures and other z/OS application programs.
The IMS control region also provides all logging, restart, and recovery functions for the IMS subsystems. The terminals, message queues, and logs are all attached to this region. Fast Path (one of the IMS database types) database data sets are also allocated by the IMS control region.

A z/OS type-2 supervisor call (SVC) routine is used for switching control information, message and database data between the control region, all other regions, and back. Four different types of IMS control regions can be defined using the IMS system definition process. You choose the one you want depending on which IMS functions you want. The four types of IMS control regions support the four IMS environments. These environments are discussed in more detail in IMS Environments. IMS Environments Each of the IMS environments is a distinct combination of hardware and programs that supports distinct processing goals. The four IMS environments are:

y y y y

DB/DC, which contains all the functionality of both IMS TM and IMS DB (see IMS DB/DC Environment). DBCTL (pronounced DB Control), which contains the functionality of only IMS DB (see IMS DBCTL Environment). DCCTL (pronounced DC Control), which contains the functionality of only IMS TM (see IMS DCCTL Environment). Batch, which contains the functionality of IMS DB, but is used only for batch jobs (see IMS Batch Environment)

IMS DB/DC Environment

The DB/DC environment has both IMS TM and IMS DB installed and has the functionality of the entire IMS product. The processing goals of the DB/DC environment are to:

y y y y y

Enable terminal users to retrieve data and modify the database with satisfactory real-time performance. Some typical applications are banking, airline reservations, and sales orders. Ensure that retrieved data is current. Distribute transaction processing among multiple processors in a communications network. Run batch application programs to update databases at certain intervals (for example, process a payroll or produce an inventory report). Run database utilities using batch.

As shown in Figure 6, the DB/DC control region provides access to the:

y y y y y y y y y y y

Network, which might include a z/OS console, terminals, Web servers, and more. IMS message queues for IMS applications running in message processing regions (MPRs) or Java message processing regions. IMS libraries. IMS logs. Fast Path databases. DL/I separate address space. Database Recovery Control (DBRC) facility region. IMS Fast Path (IFP) region. Java message processing program (JMP) region. Java batch processing program (JBP) region. Batch message processing program (BMP) region.

Related Reading:

For more information about the address spaces that provide some of the services of the IMS subsystem, see IMS Separate Address Spaces.

For more information about DBRC, see the complete version of An Introduction to IMS. For more information about the various types of regions for application programs, see Dependent Regions. Figure 6. Structure of a Sample IMS DB/DC Environment

y y

IMS DBCTL Environment

The DBCTL environment has only IMS DB installed. The processing goals of the DBCTL environment are to:

y y y

Process network transactions without IMS TM; that is, use IMS DB with a different transaction management subsystem, such as CICS. Run batch application programs to update databases at certain intervals (for example, process a payroll or produce an inventory report). Run database utilities using batch.

DBCTL can provide IMS database functions to batch message programs (BMP and JMP application programs) connected to the IMS control region, and to application transactions running in CICS regions, as shown in Figure 7. Figure 7. Structure of a Sample IMS DBCTL Environment

When a CICS system connects to IMS using the DRA, each CICS system has a predefined number of connections with IMS. Each of these connections is called a thread. Although threads are not jobs from the perspective of IMS, each thread appears to the IMS system to be another IMS dependent region. When a CICS application issues a DL/I call to IMS, the DL/I processing runs in one of these dependent regions. When a DB/DC environment is providing access to IMS databases for a CICS region, it is referred to in some documentation as providing DBCTL services, though it might, in fact, be a full DB/DC environment and not just a DBCTL environment.
IMS DCCTL Environment

The DCCTL environment is an IMS Transaction Manager subsystem that has no database components. A DCCTL environment is similar to the "DC" component of a DB/DC environment. The primary difference is that a DCCTL control region owns no databases and does not service DL/I database calls. The processing goals of the DCCTL environment are to:

y y y

Process network transactions without IMS DB by using IMS TM with an external database management subsystem, such as DB2 UDB for z/OS. Use DBRC to maintain system log information that might be needed to restart IMS. Run batch application programs in a TM batch region by using IMS TM to do batch processing with DB2 UDB for z/OS.

As shown in Figure 8, the DCCTL system, in conjunction with the IMS External Subsystem Attach Facility (ESAF), provides a transaction manager facility to external subsystems (for example, DB2 UDB for z/OS). Most IMS customers use a DB/DC environment as a transaction manager front end for DB2 UDB for z/OS. Figure 8. Structure of a Sample IMS DCCTL Environment

In a DCCTL environment, transaction processing and terminal management is identical to transaction processing and terminal management in a DB/DC environment.
IMS Batch Environment

The IMS batch environment consists of a batch region (a single address space) where an application program and IMS routines reside. The batch job that runs the batch environment is initiated with JCL, like any operating-system job. There are two types of IMS batch environments: DB Batch and TM Batch. These environments are discussed in DB Batch Environment and TM Batch.
DB Batch Environment

In the DB Batch environment, IMS application programs that use only IMS DB functions can be run in a separate z/OS address space that is not connected to an IMS online control region. These batch applications are typically very long-running jobs that perform large numbers of database accesses, or applications that do not perform synchronization-point processing to commit the work. DB Batch applications can access only full-function databases. Another aspect of a DB Batch environment is that the JCL is submitted through TSO or a job scheduler. However, all of the IMS code used by the application resides in the address space in which the application is running. The job executes an IMS batch region controller that then loads and calls the application. Figure 9 shows an IMS batch region. Figure 9. Structure of an IMS DB Batch Environment

The batch address space opens and reads the IMS database data sets directly. The batch region controller writes its own separate IMS log. In the event of a program failure, it might be necessary to take manual action (for example, submit jobs to run IMS utilities) to recover the databases to a consistent point. With online dependent application regions, this is done automatically by the IMS control region. You can also use DBRC to track the IMS logs and ensure that correct recovery action is taken in the event of a failure. An application can be written so that it can run in both a batch address space and a BMP address space without change. You can vary the execution environment of the programs between batch and BMP address spaces to lengthen the run time, support the need of other applications to access the data at the same time, or to run your procedures for recovering from application failures.
TM Batch

IMS TM supports a batch region for running TM batch application programs. Using TM batch, you can either take advantage of the IMS Batch Terminal Simulator for z/OS or access an external subsystem through the IMS External Subsystem Attach Facility, ESAF. One example of an external subsystem is DB2 UDB for z/OS. You can connect DB2 UDB for z/OS in an IMS TM batch environment in one of two ways. You can use the SSM parameter on the TM batch-region execution JCL and specify the actual name of the batch program on the MBR parameter. Alternatively, you can code the DDITV02 DD statement on the batchregion execution JCL and specify the name of the DB2 UDB for z/OS module, DSNMTV01, on the MBR parameter. TM Batch does not provide DL/I database capabilities. Related Reading:

y y

See the DB2 UDB for z/OS: Application Programming and SQL Guide for a description of the steps required to allow TM batch programs to issue SQL calls. See Selecting the Appropriate IMS System Definition in System Definition and Tailoring for additional options or requirements of the IMS TM batch environment.

IMS Separate Address Spaces The IMS control region has separate address spaces that provide some of the IMS subsystem services. These regions are automatically started by the IMS control region as part of its initialization, and the control region does not complete initialization until these regions have started and connected to the IMS control region. All separate address spaces (except for DBRC) are optional, depending on the IMS features used. For DL/I, separate address space options can be specified at IMS initialization.
DBRC Region

The DBRC region provides all access to the DBRC recovery control (RECON) data sets. The DBRC region also generates batch jobs for DBRC (for example, for archiving the online IMS log). Every IMS control region must have a DBRC region because it is needed, at a minimum, for managing the IMS logs.
DL/I Separate Address Space

The DL/I separate address space (DLISAS) performs most data set access functions for IMS DB (except for the Fast Path DEDB databases). The DLISAS allocates full-function database data sets and also contains some of the control blocks associated with database access and some database buffers. For a DBCTL environment, the DLISAS is required and always present. For a DB/DC environment, you have the option of having IMS database accesses performed by the control region or having the DB/DC region start DLISAS. For performance and capacity reasons, use DLISAS. DLISAS is not present for a DCCTL environment because the Database Manager functions are not present.
Dependent Regions

IMS provides address spaces for the execution of system and application programs that use IMS services. These address spaces are called dependent regions. The dependent regions are started by the submission of JCL to the operating system. The JCL is submitted as a result of a command issued to the IMS control region, through automation, or by a regular batch job submission. After the dependent regions are started, the application programs are scheduled and dispatched by the IMS control region. In all cases, the z/OS address space executes an IMS control region program. The application program is then loaded and called by the IMS code. Up to 999 dependent regions can be connected to one IMS control region, made up of any combination of the following dependent region types:

y y y y y y

Message processing region (MPR) IMS Fast Path (IFP) region, processing Fast Path applications or utilities Batch message processing (BMP) region, running with or without HSSP (High Speed Sequential Processing) Java message processing (JMP) region Java batch processing (JBP) region DBCTL thread (DBT)

Table 1 describes the support for dependent regions by IMS environment type. Table 1. Support for Dependent Region Type by IMS Environment Application Address Space Type MPR IFP BMP (transactionoriented) DB Batch N N TM Batch N N

DCCTL

DBCTL

DB/DC

Y Y Y (1)

N N

Y Y

Table 1. Support for Dependent Region Type by IMS Environment Application Address Space Type BMP (batch-oriented) JMP JBP Batch DBT 1. DB Batch N N N Y N TM Batch N N N Y N

DCCTL

DBCTL

DB/DC

Y Y Y N N

Y N Y N Y

Y Y Y N Y

BMP regions attached to a DCCTL control region can access only IMS message queues and DB2 UDB for z/OS databases.

Message Processing Region

Message processing regions (MPRs) run applications that process messages that come into IMS TM as input (for example, from terminals or online programs). MPRs can be started by IMS submitting the JCL as a result of an IMS command. The address space does not automatically load an application program but waits until work becomes available. Priority settings determine which MPR runs the application program. When the IMS determines that an application is to run in a particular MPR, the application program is loaded into that region and receives control. The application processes the message, and any further messages for that transaction that are waiting to be processed. Then, depending on options specified on the transaction definition, the application either waits for further input, or another application program is loaded to process a different transaction.
IMS Fast Path Region

An IMS Fast Path (IFP) region runs application programs to process messages for transactions that have been defined as Fast Path transactions. Fast Path applications are very similar to the applications that run in an MPR. Like MPRs, the IFP regions can be started by the IMS control region submitting the JCL as a result of an IMS command. The difference between MPRs and IFP regions is in the way IMS loads and dispatches the application program and handles the transaction messages. To allow for this different processing, IMS imposes restrictions on the length of the application data that can be processed in an IFP region as a single message. IMS uses a user-written exit routine (or the IBM-supplied sample) to determine whether a transaction message should be processed in an IFP region and in which IFP region it should be processed. The IMS Fast Path facility that processes messages is called the expedited message handler (EMH). The EMH speeds the processing of the messages by having the applications loaded and waiting for input messages, and, if the message is suitable, dispatching it directly in the IFP region, bypassing the IMS message queues.

IFP regions can also be used for other types of work besides running application programs. IFP regions can be used for Fast Path utility programs. For further discussion on using these regions for other types of work, see the IMS Version 9: Installation Volume 2: System Definition and Tailoring.
Batch Message Processing Region

Unlike MPR or IFP regions, a BMP region is not usually started by the IMS control region, but is started by submitting a batch job, for example by a user from TSO or by a job scheduler. The batch job then connects to an IMS control region that is defined in the execution parameters. Two types of applications can run in BMP regions:

y y

Message-driven BMP applications (also called transaction-oriented BMP applications), which read and process messages from the IMS message queue Non-message driven BMP applications (batch-oriented), which do not process IMS messages

BMP regions have access to the IMS full-function and Fast Path databases, provided that the control region has the Database Manager component installed. BMP regions can also read and write to z/OS sequential files, with integrity, using the IMS GSAM access method. BMP regions can also be used for other types of work besides running application programs. BMP regions can be used for jobs that, in the past, were run as batch update programs. The advantage of converting batch jobs to run in BMP regions is that the batch jobs can now run along side of a transaction environment and these BMP applications can be run concurrently instead of sequentially. For a further discussion on using these regions for other types of work, see the IMS Version 9: Installation Volume 2: System Definition and Tailoring.
Java Dependent Regions

Two IMS dependent regions provide a Java Virtual Machine (JVM) environment for Java or objectoriented COBOL applications: Java message processing (JMP) regions JMP regions are similar to MPR regions, but JMP regions allow the scheduling only of Java or object-oriented COBOL message-processing applications. A JMP application is started when there is a message in the queue for the JMP application and IMS schedules the message to be processed. JMP applications are executed through transaction codes submitted by users at terminals and from other applications. Each transaction code represents a transaction that the JMP application processes. A single application can also be started from multiple transaction codes. JMP applications are very flexible in how they process transactions and where they send the output. JMP applications send any output messages back to the message queues and process the next message with the same transaction code. The program continues to run until there are no more messages with the same transaction code. JMP applications share the following characteristics:

y y y

They are small. They can produce output that is needed immediately. They can access IMS or DB2 data in a DB/DC environment and DB2 data in a DCCTL environment.

Java batch processing (JBP) regions JBP regions run flexible programs that perform batch-type processing online and can access the IMS message queues for output (similar to non-message-driven BMP applications). JBP

applications are started by submitting a job with JCL or from TSO. JBP applications are like BMP applications, except that they cannot read input messages from the IMS message queue. Similarly to BMP applications, JBP applications can use symbolic checkpoint and restart calls to restart the application after an abend. JBP applications can access IMS or DB2 data in a DB/DC or DBCTL environment and DB2 data in a DCCTL environment. Figure 10 shows a Java application that is running in a JMP or JBP region. JDBC or IMS Java hierarchical interface calls are passed to the IMS Java layer, which converts them to DL/I calls. Figure 10. JMP or JBP Application That Uses the IMS Java Function

JMP and JBP regions can run applications written in Java, object-oriented COBOL, or a combination of the two. Related Reading: For more information about writing Java applications for IMS, see IMS Java.
Common Queue Server Address Space

Common Queue Server (CQS) is a generalized server that manages data objects on a z/OS coupling facility on behalf of multiple clients. CQS is used by IMS shared queues and the Resource Manager address space in the Common Service Layer. CQS uses the z/OS coupling facility as a repository for data objects. Storage in a coupling facility is divided into distinct objects called structures. Authorized programs use structures to implement data sharing and high-speed serialization. The coupling facility stores and arranges the data according to list structures. Queue structures contain collections of data objects that share the same names, known as queues. Resource structures contain data objects organized as uniquely named resources. CQS receives, maintains, and distributes data objects from shared queues on behalf of multiple clients. Each client has its own CQS access the data objects on the coupling facility list structure. IMS is one example of a CQS client that uses CQS to manage both its shared queues and shared resources.

CQS runs in a separate address space that can be started by the client (IMS). The CQS client must run under the same z/OS image where the CQS address space is running. CQS is used by IMS DCCTL and IMS DB/DC control regions if they are participating in sysplex sharing of IMS message queues or resource structures. IMS DBCTL can also use CQS and a resource if it is using the IMS coordinated online change function. Clients communicate with CQS using CQS requests that are supported by CQS macro statements. Using these macros, CQS clients can communicate with CQS and manipulate client data on shared coupling facility structures. Figure 11 shows the communications and the relationship between clients, CQSs, and the coupling facility. Figure 11. Client Systems, CQS, and a Coupling Facility

Related Reading: For complete information about CQS, see Common Service Layer.
Common Service Layer

The IMS Common Service Layer (CSL) is a collection of IMS system address spaces that provide the infrastructure needed for systems management tasks. The IMS CSL reduces the complexity of managing multiple IMS systems by providing you with a single-image perspective in an IMSplex. An IMSplex is one or more IMS subsystems that can work together as a unit. Typically, these subsystems:

y y y

Share either databases or resources or message queues (or any combination) Run in an z/OS sysplex environment Include an IMS CSL

The CSL address spaces include Operations Manager (OM), Resource Manager (RM), and Structured Call Interface (SCI). They are briefly described in the following sections. Related Reading: For a further discussion of IMS in a sysplex environment, see:

y y

The complete version of An Introduction to IMS Administering Sysplex Data Sharing in Administration: System

For a detailed discussion of IMS in a sysplex environment, see:

y y y

IMS in the Parallel Sysplex: Volume I: Reviewing the IMSplex Technology IMS in the Parallel Sysplex: Volume II: Planning the IMSplex IMS in the Parallel Sysplex: Volume III: IMSplex Implementation and Operations

Operations Manager Address Space

The Operations Manager (OM) controls the operations of an IMSplex. OM provides an application programming interface (the OM API) through which commands can be issued and responses received. With a single point of control (SPOC) interface, you can submit commands to OM. The SPOC interfaces include the TSO SPOC, the REXX SPOC API, and the IMS Control Center. You can also write your own application to submit commands.
Resource Manager Address Space

The Resource Manager (RM) is an IMS address space that manages global resources and IMSplex-wide processes in a sysplex on behalf of RM's clients. IMS is one example of an RM client.
Structured Call Interface Address Space

The Structured Call Interface (SCI) allows IMSplex members to communicate with one another. The communication between IMSplex members can happen within a single z/OS image or among multiple z/OS images. Individual IMS components do not need to know where the other components reside or what communication interface to use.

Running an IMS System

IBM supplies the procedures to run IMS address spaces. The procedures for each type of region are located in the IMS.PROCLIB data set. You must modify the procedures in the IMS.PROCLIB data set with the correct data set names for each IMS system. Table 2 contains the procedure member names in IMS.PROCLIB, along with the type of region that each member generates. Table 2. IMS Procedure Members and the Region Type They Generate Procedure Member Name DBC DBRC DCC DFSJBP DFSJMP Region Type DBCTL control region Database Recovery Control region DCCTL control region Java batch processing (JBP) region Java message processing (JMP) region

Table 2. IMS Procedure Members and the Region Type They Generate Procedure Member Name DFSMPR DLIBATCH DLISAS DXRJPROC FPUTIL IMS IMSBATCH IMSFP IMSRDR Region Type Message processing region (MPR) DB batch region DL/I separate address space internal resource lock manager (IRLM) region Fast Path utility region DB/DC control region IMS batch message processing region (BMP) IMS Fast Path (IFP) region IMS JCL reader region

Related Reading: For details of these and other procedures supplied in IMS.PROCLIB, see IMS Procedures in System Definition and Tailoring.

Running Multiple IMS Systems

You can run multiple IMS systems on a single z/OS image or on multiple z/OS images. One instance of an IMS system (a control region and all its associated dependent regions) is referred to as one IMS system. In many cases, these IMS systems would be production and testing systems. A batch IMS system (for example, DB batch) is also considered one IMS system.

IMS Recovery
There are a number of tools and features available with IMS to help in recovery scenarios. This section describes these tools and features. Extended Recovery Facility (XRF) With XRF, you can have an alternate IMS standby system ready to take over within the same site. Remote Site Recovery (RSR) With RSR, you can recover the complete IMS system (or systems) very quickly at another site when complete site disasters occur. Database Recovery Control (DBRC) Facility

DBRC is an integral part of IMS. IMS relies on DBRC to: y Record and manage information about many items. DBRC keeps this information in a set of VSAM data sets that are collectively called the RECoveryCONtrol (RECON) data sets. y Advise IMS (based on the information in the RECON data sets) about how to proceed for certain IMS actions. Fast Database Recovery (FDBR) FDBR provides a solution to sysplex customers who need quick access to shared database resources that might otherwise be locked by a failed IMS until the failed system is restarted. In a sysplex data-sharing environment, multiple IMS subsystems can access a single, shared database resource. If one of the IMS subsystems fails while it has a lock on the database, the other IMS subsystems must wait until the failed IMS is restarted and the locks on the resource are released. Because an emergency restart can take a significant amount of time, waiting for a full restart is unacceptable in situations that require continuous availability of database resources. FDBR creates a separate IMS control region (the Fast Database Recovery region), which monitors an IMS subsystem, detects failure, and recovers any database resources that are locked by the failed IMS, making them available for other IMS subsystems. IMS Database Recovery Facility for z/OS, V2 One of the IBM IMS tools, IMS Database Recovery Facility for z/OS allows you to recover multiple database data sets and Fast Path areas in an IMS DBCTL or DB/DC environment simultaneously. IMS Database Recovery Facility for z/OS simplifies the database recovery process by eliminating the need to run separate recovery jobs for each database data set that requires recovery. Recovery using IMS Database Recovery Facility for z/OS reduces the time that broken databases and areas are unavailable by processing input data in parallel and recovering multiple database data sets and areas simultaneously. Related Reading: For more information about this and other IMS tools, see IMS Tools.

IMS Logging
While IMS is running, it records the event information that is necessary to restart the system if a hardware or software failure occurs. The event information is recorded on an online log data set (OLDS). When an OLDS is filled, or some other event causes IMS to switch from one OLDS to another, it is archived to the system log data set (SLDS). There is a finite number of OLDS data sets, although this number can be dynamically changed, which are pre-allocated and defined to the IMS control region. The OLDS are reused during the duration of the control region. There can be an infinite number of SLDSs, which are created and allocated as needed.