IMS Has Been an Important Part of World

8/6/2019 IMS Has Been an Important Part of World

1/31

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 anAmerican man to the moon and return him safely to earth. The feat was to be accomplished before theend of the decade, as part of the Apollo program. American Rockwell won the bid to build thespacecraft for the Apollo program and, in 1965, they established a partnership with IBM to fulfill therequirement for an automated system to manage large bills of material for the construction of thespacecraft.

In 1966, 12 members of the IBM team, along with 10 members from American Rockwell and 3members from Caterpillar Tractor, began to design and develop the system that was called InformationControl 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 andshipped the first release of ICS in 1967.

In April, 1968, ICS was installed. The first "READY" message was displayed on an IBM 2740typewriter 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 availableto 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 IMSworkload, 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 workbeing done on our latest versions, Version 7 and Version 8, than on older versions, Versions 5 andVersion 6, worldwide. Overall, in 2003, MIPS of IMS systems grew almost 20%. By midyear, IMSVersion 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 requiredbecause of mergers and acquisitions among existing customers (in the Americas and Europe) and theselection of IMS for new zSeries footprints (predominantly by emerging opportunities in Asia). It isnoteworthy that customers showed continued confidence in the future of IMS, during the years 2001-2003, 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 dailyoperations:

y Manufacturingy Financey Bankingy RetailingyAerospacey Communications


2/31

y Governmenty Insurancey High technologyy Health Care

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

yA 35-year-old hierarchical database and transaction processing system is currently growingfaster than the world's most popular relational database system. Pretty funny, huh?

Actually, IMS is not forging new ground with innovative marketing or customer-acquisitionstrategies. It's more the other way around--it's keeping the same old customer base, but thebase is growing, a lot. IMS and the mainframes it runs on underpin the vast majority ofbanks and banking transactions worldwide. And the banking world is growing. China alonemay 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. Combinethat kind of geographic growth with advances in online banking in the developed world andit'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 anew 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 Over 95% of Fortune 1000 companies use IMS.y IMS manages over 15 million gigabytes of production data.y $2.5 trillion (in US dollars) per day is transferred through IMS by one customer.

IMS processes over 50 billion transactions per day

y IMS serves over 200 million users every day.y IMS processes over 100 million transactions per day for one customer.y IMS processes over 120 million transactions per day (7 million per hour) for another

customer.y IMS can process 21 000 transactions per second (over 1 billion2 per day) using IMS

data sharing and shared queues.y 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 theIMS 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 Infrastructurey IMS is Strategic Regarding Continued Investmenty IMS is Strategic For the Future

IMS is Strategic in the On Demand Infrastructure


3/31

IBM defines an on demand enterprise as one whose business processes are integrated end-to-endacross the company and with key partners, suppliers, and customers. An on demand enterprise canrespond with flexibility and speed to any customer demand, any market opportunity, and any externalthreat. This need to respond with urgency must be addressed by an on demand infrastructure. Thisinfrastructure is:

Based on open standards

IMS fully supports Java standards for application development and XML for transparentdocument 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, virtuallyanywhere on the Internet, through the utilization of the IMS Connect function and the IMSConnector for Java.

Integrated

Integration has always been an IMS priority. IMS ships connectors and tooling with IBMWebSphere solutions so customers can connect to IMS applications and data utilizing thetools 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 providing21 000 transactions, including database access, per second. IMS Version 9 continues thisperformance and offers 24 x 7 database availability with High Availability Large DatabaseOnline Reorganization support.

Enabled with self-managing capabilities

IMS Version 8 and Version 9 address the need to assist technical support staff in beingmore productive, keep systems continuously available, and do so in an operatingenvironment that is growing more and more complex. IMS Version 8 contains over a dozennew and improved self-managing functions to enhance the productivity and effectiveness ofdatabase administrators and systems programmers. These functions and more are availablewith IMS Version 9.

Reliable

One large IMS customer has operated over 3000 days (and counting) without an outage in a24 x 7 environment.

IMS is Strategic Regarding Continued Investment

The ability of the IMS team to deliver revenue growth to the IBM company is ameasure of our success as business managers. Success in this area supportscontinued investment by IBM in the development of future versions and the growthof resources devoted to that effort. In 2003, IMS enjoyed another record breakingyear, 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 currentIMS 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:


4/31


5/31

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 havepersonal copies of the data.

Figure 1. Hierarchical Database Model

With IMS DB, you can:

y Maintain data integrity. The data in each database is guaranteed to be consistent andguaranteed to remain in the database even when IMS DB is not running.

y

Define the database structure and the relationships among the database elements.y Provide a central point of control and access for the IMS data that is processed by IMSapplications.

y Perform queries against the data in the database.y Perform database transactions (inserts, updates, and deletes) as a single unit of work so that

the entire transaction either occurs or does not occur.y Perform multiple database transactions concurrently with the results of each transaction kept

isolated from the others.

y Maintain the databases. IMS DB provides facilities for tuning the databases by reorganizingand 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 needto 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 accessmethods. The actual database data is stored on disk storage using normal z/OS access methods. Seethe complete version ofAn Introduction to IMS.

IMS DB provides access to these databases from applications running under:

y IMS Transaction Managery CICS Transaction Server for OS/390 and z/OS


6/31

y z/OS batch jobsy WebSphere Application Server for z/OSy DB2 UDB for z/OS stored procedures

IMS Transaction Manager

IMS TM is a message-based transaction processor.

Definitions:

y A transaction is a specific set of input data that triggers the execution of a specific businessapplication program (a process or job). The message that triggers the application program,and the return of any results, is considered one transaction.

y The word terminalis used throughout this information to describe devices and controllers. Theoperator terminals can be keyboard printers, display stations with keyboards, communicationterminals, or a mixture of these devices.

IMS TM provides services to:

y Process input messages received from a variety of sources (such as the terminal network,other IMSs, and the Web).

y Process output messages created by application programs.y Provide an underlying queueing mechanism for handling these messages.y 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 extremelyhigh transaction volumes. The users of the terminal sessions can be:

y People at terminals or workstations.y 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 thedatabase 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 DB2databases and return results.

You can define a variety of online processing options. For example, you can define transactions forhigh-volume data-entry applications, others for interactive applications, and still others to supportpredefined queries.

IMS TM also enables you to develop a wide range of high-volume, rapid-response applications, and togeographically disperse your data processing locations while keeping centralized control of yourdatabase.

IMS System Services

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

y Provide data integrityy Restart and recover IMS after failuresy Provide security, by controlling access to and modification of IMS resources


7/31


8/31

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

y 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 cannotbe ordered separately.

o IBM High-Level Assembler Toolkit (5696-234), a separately orderable feature of z/OSo RACF (available with the IBM SecureWay Security Server for z/OS and OS/390

RACF product) or equivalent product, if security is usedo ISPF Version 4 Release 2 (5655-042)o e-Network Communications Server for z/OS, if IMS Transaction Manager is used

y 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 productionenvironment.

CICS Subsystems Supported

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

y CICS Transaction Server for z/OS Version 2.2 (5697-E93)y 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 CICS Transaction Server for z/OS Version 2.2 (5697-E93)y 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 DB2 UDB for z/OS Version 8 (5625-DB2)y DB2 for z/OS and OS/390 Version 7 (5675-DB2)y 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 ADAy COBOL for OS/390 & VM


9/31

y Enterprise COBOL for z/OS and OS/390y High Level Assembler for MVS & VM & VSE Version 1 Release 4.0y IBM SDK for z/OS Java 2 Technology Edition, Version 1.3.1y PL/I for z/OS and OS/390y TSO/E REXXy VS Pascal

y WebSphere Studio Site Developer Version 5.0y z/OS C/C++

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

y COBOL for OS/390 & VMy PL/I for z/OS and OS/390

Accessing IMS

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

y You can write application programs that tell IMS what to do.y 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 bycalling a number of standard IMS functions through standard APIs: DL/I and JDBC4.

In This Section:

y Accessing IMS From Application Programsy 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. Applicationprograms that use the JDBC interface do so by issuing standard SQL (structured query language)calls.

Accessing IMS from OtherProducts

The scope of these topics is not large enough to fully explain all the products and protocols that canaccess IMS. Instead, some of these products and protocols are briefly mentioned in the followingsections 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 canaccess 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.


10/31

Figure 4. Accessing IMS DB from Other Programs

The following components and products are shown in Figure 4:


11/31

y DL/I.y DRA: The DRA comes with IMS DB, but is run where it is used, not within IMS.y ODBA: ODBA comes with IMS DB, but, like the DRA, is run where it is used, not within IMS.y Distributed z/OS applications: Any z/OS application that follows the guidelines and rules

associated with the ODBA interface can access IMS.

y WebSphere Application Server for z/OS.y

CICS: IBM CICS Transaction Server for z/OS, an IBM licensed program that provides onlinetransaction-processing services and management for business applications. CICS can be atransaction manager for either IMS DB or DB2 UDB for z/OS. In Figure 4, CICS applicationprograms 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.

y DB2 UDB for z/OS: IBM's premier database manager for relational databases. Storedprocedures that run in DB2 UDB for z/OS can access IMS DB through ODBA.

y IBM WebSphere MQ for z/OS: A z/OS subsystem that supports the transfer of messagesacross z/OS address spaces and to other WebSphere MQ products on both IBM and non-IBM platforms. The platforms include AIX, iSeries, OS/2, VSE/ESA, HP-UX, Solaris,Windows, Compaq NonStop Kernel, Compaq Tru64 UNIX, Compaq OpenVMS (Alpha), andLinux, using the IBM SNA LU 6.2 or TCP/IP communications protocols.

y 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 acrossthe 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


12/31


13/31

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 theprocessing of programs. For more information about IMS TM and APPC, see the complete

version ofAn

Introductio

nto IMS.

y z/OS Communications Server: z/OS Communications Server provides both System NetworkArchitecture (SNA) and Transmission Control Protocol/Internet Protocol (TCP/IP) networkingprotocols for z/OS. The SNA protocols are provided by Virtual Telecommunications AccessMethod (VTAM) and include Subarea, Advanced Peer-to-Peer Networking, and HighPerformance Routing protocols. For more information on z/OS Communications Server SNAprotocols or TCP/IP networking protocols for z/OS, see z/OS V1R4.0z/OS CommunicationsServer SNA Network Implementation Guide.

y Communication Controller and Network Control Program (NCP): A combination ofhardware and software that provides support for single-domain, multiple-domain, andinterconnected network capability. The NCP is an IBM licensed program.

y SNA Network: Existing (traditional) network that implements the SNA protocols6 to connectterminals 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 betweenIP and SNA networks), WebSphere Application Server, or WebSphere MQ Everyplace.

y Control Center for IMS: A workstation graphical interface from which you can manage yourIMS 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, seeIMS Control Center.

y OTMA: An open interface to IMS TM through which a z/OS or TCP/IP application programcan 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 messagesacross z/OS address spaces and to other WebSphere MQ products on both IBM and non-IBM platforms. The platforms include AIX, iSeries, OS/2, VSE/ESA, HP-UX, Solaris,Windows, Compaq NonStop Kernel, Compaq Tru64 UNIX, Compaq OpenVMS (Alpha), andLinux, 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 usingthe OTMA callable interface.

y DB2 UDB for z/OS: IBM's premier database manager for relational databases. IMS TM canprovide 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 usessome of the facilities that are a part of the z/OS operating system.

In This Section:

y How IMS Relates to z/OSy Structure of IMS Subsystemsy Running an IMS Systemy Running Multiple IMS Systemsy How IMS Uses z/OS Services


14/31

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 IMSapplication programs. z/OS address spaces are sometimes called regions7, as in the IMS controlregion. 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 IMSSubsystems.

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 controlregion uses many other address spaces that provide additional services to the control region, and inwhich the IMS application programs run.

Some IMS applications and utilities run in separate, standalone regions, called batch regions. Batchregions are separate from an IMS subsystem and its control region and have no connection with it. Formore 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 commandor by submitting job control language (JCL)8 job.

The IMS control region provides the central point of control for an IMS subsystem. The IMS controlregion:

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 IMSsubsystems. The terminals, message queues, and logs are all attached to this region. Fast Path (oneof the IMS database types) database data sets are also allocated by the IMS control region.


15/31

A z/OS type-2 supervisor call (SVC) routine is used for switching control information, message anddatabase 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 IMScontrol regions support the four IMS environments. These environments are discussed in more detailin IMS Environments.

IMS Environments

Each of the IMS environments is a distinct combination of hardware and programs that supportsdistinct processing goals. The four IMS environments are:

y DB/DC, which contains all the functionality of both IMS TM and IMS DB (see IMS DB/DCEnvironment).

y DBCTL (pronounced DB Control), which contains the functionality of only IMS DB (see IMSDBCTL Environment).

y DCCTL (pronounced DC Control), which contains the functionality of only IMS TM (see IMSDCCTL Environment).

y

Batch, which contains the functionality of IMS DB, but is used only for batch jobs (see IMSBatch Environment)

IMS DB/DC Environment

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

y Enable terminal users to retrieve data and modify the database with satisfactory real-timeperformance. Some typical applications are banking, airline reservations, and sales orders.

y Ensure that retrieved data is current.y Distribute transaction processing among multiple processors in a communications network.y Run batch application programs to update databases at certain intervals (for example,

process a payroll or produce an inventory report).y Run database utilities using batch.

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

y Network, which might include a z/OS console, terminals, Web servers, and more.y IMS message queues for IMS applications running in message processing regions (MPRs) or

Java message processing regions.

y IMS libraries.y IMS logs.y Fast Path databases.y DL/I separate address space.y Database Recovery Control (DBRC) facility region.y IMS Fast Path (IFP) region.y Java message processing program (JMP) region.y Java batch processing program (JBP) region.y Batch message processing program (BMP) region.

Related Reading:

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


16/31

y For more information about DBRC, see the complete version ofAn Introduction to IMS.y 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


17/31


18/31

IMS DBCTL Environment

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

y Process network transactions without IMS TM; that is, use IMS DB with a different transaction

management subsystem, such as CICS.y Run batch application programs to update databases at certain intervals (for example,

process a payroll or produce an inventory report).y Run database utilities using batch.

DBCTL can provide IMS database functions to batch message programs (BMP and JMP applicationprograms) connected to the IMS control region, and to application transactions running in CICSregions, as shown in Figure 7.

Figure 7. Structure of a Sample IMS DBCTL Environment


19/31


20/31

When a CICS system connects to IMS using the DRA, each CICS system has a predefined number ofconnections with IMS. Each of these connections is called a thread. Although threads are not jobs fromthe 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 dependentregions.

When a DB/DC environment is providing access to IMS databases for a CICS region, it is referred to insome documentation as providing DBCTL services, though it might, in fact, be a full DB/DCenvironment and not just a DBCTL environment.

IMS DCCTL Environment

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

y Process network transactions without IMS DB by using IMS TM with an external databasemanagement subsystem, such as DB2 UDB for z/OS.

y Use DBRC to maintain system log information that might be needed to restart IMS.y 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 AttachFacility (ESAF), provides a transaction manager facility to external subsystems (for example, DB2UDB for z/OS). Most IMS customers use a DB/DC environment as a transaction manager front end forDB2 UDB for z/OS.

Figure 8. Structure of a Sample IMS DCCTL Environment


21/31


22/31

In a DCCTL environment, transaction processing and terminal management is identical to transactionprocessing 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 arediscussed 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 ina separate z/OS address space that is not connected to an IMS online control region. These batchapplications are typically very long-running jobs that perform large numbers of database accesses, orapplications that do not perform synchronization-point processing to commit the work. DB Batchapplications can access only full-function databases.

Another aspect of a DB Batch environment is that the JCL is submitted through TSO or a jobscheduler. However, all of the IMS code used by the application resides in the address space in whichthe application is running. The job executes an IMS batch region controller that then loads and callsthe application. Figure 9 shows an IMS batch region.

Figure 9. Structure of an IMS DB Batch Environment


23/31

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 mightbe necessary to take manual action (for example, submit jobs to run IMS utilities) to recover thedatabases to a consistent point. With online dependent application regions, this is done automaticallyby the IMS control region. You can also use DBRC to track the IMS logs and ensure that correctrecovery 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 addressspace without change. You can vary the execution environment of the programs between batch andBMP address spaces to lengthen the run time, support the need of other applications to access thedata 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 caneither take advantage of the IMS Batch Terminal Simulator for z/OS or access an external subsystemthrough the IMS External Subsystem Attach Facility, ESAF. One example of an external subsystem isDB2 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 usethe SSM parameter on the TM batch-region execution JCL and specify the actual name of the batchprogram on the MBR parameter. Alternatively, you can code the DDITV02 DD statement on the batch-region execution JCL and specify the name of the DB2 UDB for z/OS module, DSNMTV01, on theMBR parameter.

TM Batch does not provide DL/I database capabilities.

Related Reading:

y See the DB2 UDB forz/OS: Application Programming and SQL Guide for a description of thesteps required to allow TM batch programs to issue SQL calls.

y See Selecting the Appropriate IMS System Definition in System Definition and Tailoring foradditional 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 subsystemservices.

These regions are automatically started by the IMS control region as part of its initialization, and thecontrol region does not complete initialization until these regions have started and connected to theIMS control region. All separate address spaces (except for DBRC) are optional, depending on theIMS 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 DBRCregion also generates batch jobs for DBRC (for example, for archiving the online IMS log). Every IMScontrol region must have a DBRC region because it is needed, at a minimum, for managing the IMSlogs.

DL/I Separate Address Space


24/31

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 setsand also contains some of the control blocks associated with database access and some databasebuffers.

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 thecontrol region or having the DB/DC region start DLISAS. For performance and capacity reasons, useDLISAS.

DLISAS is not present for a DCCTL environment because the Database Manager functions are notpresent.

Dependent Regions

IMS provides address spaces for the execution of system and application programs that use IMSservices. These address spaces are called dependent regions.

The dependent regions are started by the submission of JCL to the operating system. The JCL issubmitted as a result of a command issued to the IMS control region, through automation, or by aregular batch job submission.

After the dependent regions are started, the application programs are scheduled and dispatched bythe 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 anycombination of the following dependent region types:

y Message processing region (MPR)y IMS Fast Path (IFP) region, processing Fast Path applications or utilities

y Batch message processing (BMP) region, running with or without HSSP (High SpeedSequential Processing)

y Java message processing (JMP) regiony Java batch processing (JBP) regiony 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 AddressSpace Type

DCCTL DBCTL DB/DCDBBatch

TMBatch

MPR Y N Y N N

IFP Y N Y N N

BMP (transaction-oriented)

Y (1) N Y N N


25/31

Table 1. Support for Dependent Region Type by IMS Environment

Application AddressSpace Type

DCCTL DBCTL DB/DCDBBatch

TMBatch

BMP (batch-oriented) Y Y Y N N

JMP Y N Y N N

JBP Y Y Y N N

Batch N N N Y Y

DBT N Y Y N N

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

Message Processing Region

Message processing regions (MPRs) run applications that process messages that come into IMS TMas input (for example, from terminals or online programs). MPRs can be started by IMS submitting theJCL as a result of an IMS command. The address space does not automatically load an applicationprogram but waits until work becomes available.

Priority settings determine which MPR runs the application program. When the IMS determines that anapplication is to run in a particular MPR, the application program is loaded into that region andreceives control. The application processes the message, and any further messages for thattransaction that are waiting to be processed. Then, depending on options specified on the transactiondefinition, 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 thathave been defined as Fast Path transactions.

Fast Path applications are very similar to the applications that run in an MPR. Like MPRs, the IFPregions 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 applicationprogram and handles the transaction messages. To allow for this different processing, IMS imposesrestrictions on the length of the application data that can be processed in an IFP region as a singlemessage.

IMS uses a user-written exit routine (or the IBM-supplied sample) to determine whether a transactionmessage should be processed in an IFP region and in which IFP region it should be processed. TheIMS Fast Path facility that processes messages is called the expedited message handler(EMH). TheEMH speeds the processing of the messages by having the applications loaded and waiting for inputmessages, and, if the message is suitable, dispatching it directly in the IFP region, bypassing the IMSmessage queues.


26/31

IFP regions can also be used for other types of work besides running application programs. IFPregions can be used for Fast Path utility programs. For further discussion on using these regions forother 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 isstarted by submitting a batch job, for example by a user from TSO or by a job scheduler. The batch jobthen connects to an IMS control region that is defined in the execution parameters.

Two types of applications can run in BMP regions:

y Message-driven BMP applications (also called transaction-oriented BMP applications), whichread and process messages from the IMS message queue

y 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 controlregion has the Database Manager component installed. BMP regions can also read and write to z/OSsequential files, with integrity, using the IMS GSAM access method.

BMP regions can also be used for other types of work besides running application programs. BMPregions can be used for jobs that, in the past, were run as batch update programs. The advantage ofconverting batch jobs to run in BMP regions is that the batch jobs can now run along side of atransaction 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 object-oriented COBOL applications:

Java message processing (JMP) regions

JMP regions are similar to MPR regions, but JMP regions allow the scheduling only of Java orobject-oriented COBOL message-processing applications. A JMP application is started whenthere is a message in the queue for the JMP application and IMS schedules the message tobe processed. JMP applications are executed through transaction codes submitted by usersat terminals and from other applications. Each transaction code represents a transaction thatthe JMP application processes. A single application can also be started from multipletransaction codes.

JMP applications are very flexible in how they process transactions and where they send theoutput. JMP applications send any output messages back to the message queues andprocess the next message with the same transaction code. The program continues to run untilthere are no more messages with the same transaction code. JMP applications share thefollowing characteristics:

y They are small.y They can produce output that is needed immediately.y 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 accessthe IMS message queues for output (similar to non-message-driven BMP applications). JBP


27/31

applications are started by submitting a job with JCL or from TSO. JBP applications are likeBMP applications, except that they cannot read input messages from the IMS messagequeue. Similarly to BMP applications, JBP applications can use symbolic checkpoint andrestart calls to restart the application after an abend. JBP applications can access IMS or DB2data 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 Javahierarchical interface calls are passed to the IMS Java layer, which converts them to DL/I calls.

Figure 10. JMP or JBPApplication 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/OScoupling facility on behalf of multiple clients. CQS is used by IMS shared queues and theResource 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 facilityis divided into distinct objects called structures. Authorized programs use structures to implementdata 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 thesame names, known as queues. Resource structures contain data objects organized as uniquelynamed resources.

CQS receives, maintains, and distributes data objects from shared queues on behalf of multipleclients. 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 andshared resources.


28/31

CQS runs in a separate address space that can be started by the client (IMS). The CQS clientmust 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 sysplexsharing of IMS message queues or resource structures. IMS DBCTL can also use CQS and aresource if it is using the IMS coordinated online change function.

Clients communicate with CQS using CQS requests that are supported by CQS macrostatements. Using these macros, CQS clients can communicate with CQS and manipulate clientdata on shared coupling facility structures. Figure 11 shows the communications and therelationship 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 thatprovide the infrastructure needed for systems management tasks.

The IMS CSL reduces the complexity of managing multiple IMS systems by providing you with asingle-image perspective in an IMSplex. An IMSplex is one or more IMS subsystems that canwork together as a unit. Typically, these subsystems:

y Share either databases or resources or message queues (or any combination)y Run in an z/OS sysplex environmenty 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 The complete version ofAn Introduction to IMSy Administering Sysplex Data Sharing in Administration: System

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


29/31

y IMS in the Parallel Sysplex: Volume I: Reviewing the IMSplex Technologyy IMS in the Parallel Sysplex: Volume II: Planning the IMSplexy 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 anapplication programming interface (the OM API) through which commands can be issued andresponses received. With a single point of control (SPOC) interface, you can submit commandsto OM. The SPOC interfaces include the TSO SPOC, the REXX SPOC API, and the IMS ControlCenter. 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 andIMSplex-wide processes in a sysplex on behalf of RM's clients. IMS is one example of an RMclient.

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 oramong multiple z/OS images. Individual IMS components do not need to know where the othercomponents 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 arelocated in the IMS.PROCLIB data set.

You must modify the procedures in the IMS.PROCLIB data set with the correct data set names foreach IMS system. Table 2 contains the procedure member names in IMS.PROCLIB, along with thetype of region that each member generates.

Table 2. IMS Procedure Members and the Region Type They Generate

Procedure Member Name Region Type

DBC DBCTL control region

DBRC Database Recovery Control region

DCC DCCTL control region

DFSJBP Java batch processing (JBP) region

DFSJMP Java message processing (JMP) region


30/31

Table 2. IMS Procedure Members and the Region Type They Generate

Procedure Member Name Region Type

DFSMPR Message processing region (MPR)

DLIBATCH DB batch region

DLISAS DL/I separate address space

DXRJPROC internal resource lock manager (IRLM) region

FPUTIL Fast Path utility region

IMS DB/DC control region

IMSBATCH IMS batch message processing region (BMP)

IMSFP IMS Fast Path (IFP) region

IMSRDR IMS JCL reader region

Related Reading: For details of these and other procedures supplied in IMS.PROCLIB, see IMSProcedures 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 instanceof an IMS system (a control region and all its associated dependent regions) is referred to as one IMSsystem. In many cases, these IMS systems would be production and testing systems. A batch IMSsystem (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 sectiondescribes these tools and features.

ExtendedRecovery Facility (XRF)

With XRF, you can have an alternate IMS standby system ready to take over within the samesite.

Remote Site Recovery (RSR)

With RSR, you can recover the complete IMS system (or systems) very quickly at another sitewhen complete site disasters occur.

Database Recovery Control (DBRC) Facility


31/31

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 aset 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 proceedfor certain IMS actions.

Fast Database Recovery (FDBR)

FDBR provides a solution to sysplex customers who need quick access to shared databaseresources 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, shareddatabase resource. If one of the IMS subsystems fails while it has a lock on the database, theother IMS subsystems must wait until the failed IMS is restarted and the locks on the resourceare released. Because an emergency restart can take a significant amount of time, waiting fora full restart is unacceptable in situations that require continuous availability of databaseresources.

FDBR creates a separate IMS control region (the Fast Database Recovery region), whichmonitors 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 recovermultiple database data sets and Fast Path areas in an IMS DBCTL or DB/DC environmentsimultaneously. IMS Database Recovery Facility for z/OS simplifies the database recoveryprocess by eliminating the need to run separate recovery jobs for each database data set thatrequires recovery. Recovery using IMS Database Recovery Facility for z/OS reduces the timethat broken databases and areas are unavailable by processing input data in parallel andrecovering 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 ahardware 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 isarchived to the system log data set (SLDS). There is a finite number of OLDS data sets, although thisnumber 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 ofSLDSs, which are created and allocated as needed.

Documents

IMS Has Been an Important Part of World