Previous topic |
Next topic |
Contents |
Glossary |
Contact z/OS |
PDF
IMS Environments Introduction to IMS |
|
Each of the IMS environments is a distinct combination of hardware and programs that supports distinct processing goals. The four IMS environments are:
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:
As shown in Figure 6, the DB/DC control region provides access to the:
Related Reading:
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:
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:
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 EnvironmentIn 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 BatchIMS 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:
|
Copyright IBM Corporation 1990, 2010
|