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

• 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:

• 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:

• 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 thecomplete 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

IMS DBCTL Environment

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

• 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:

• 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 batch-region 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:

• 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.