Figure 2 gives an overview of a CICS-DBCTL interface. Each box represents an address space running within a single MVS™ system. The marked area between the second CICS® and the first BMP is the point at which CICS components end and IMS™ components begin.
The following sections give detailed information about each of the major components of the CICS-IMS DBCTL interface. See Figure 3 for an illustration of these components. At this point, you may prefer to go directly to Benefits of using DBCTL and use the following information for reference later.
The components of the CICS-DBCTL interface in the CICS address space are:
The CICS-DL/I router, DFHDLI, forms the interface between your application programs and the DL/I call processor. It accepts requests for remote, local, or DBCTL database processing. If DFHDLI decides that the request is for DBCTL, it passes the request to the CICS-DL/I DBCTL processor, DFHDLIDP. The request then goes to the task-related user exit interface and then to the CICS database adapter transformer, DFHDBAT. (The task-related user exit interface is also referred to as the resource manager interface (RMI). These terms are defined and compared in the Glossary, and you can find programming information about the task-related user exit interface in the CICS Customization Guide.)
The main responsibility of the CICS database adapter transformer, DFHDBAT (also referred to in IMS publications as the adapter, or adapter/transformer) is to communicate with the database resource adapter (DRA), which is described below. DFHDBAT constructs parameter lists for the DRA. These parameter lists enable CICS to connect to and disconnect from DBCTL, and enable DL/I requests to be processed. To summarize, DFHDBAT:
CICS master terminal operators can use the CICS-supplied transaction CDBC to connect to and disconnect from DBCTL. They can also automate connection to DBCTL, as described in Connecting to DBCTL: overview.
The functions of the database resource adapter (DRA) are to:
The components of DBCTL that reside in IMS address spaces are:
The DBCTL subsystem contains support and features required to process full function DL/I databases and DEDBs. Full function supports HSAM, SHSAM, HISAM, SHISAM, HDAM, and HIDAM databases. Each DBCTL subsystem is made up of three address spaces: DBCTL, DLISAS, and DBRC. A single DBCTL can service multiple CICS systems, but a CICS system can connect to only one DBCTL at a time. A CICS system can connect to one DBCTL, disconnect from it, and then connect to a different DBCTL.
DL/I separate address space (DLISAS), which is required with DBCTL, is a separate address space that contains DL/I code, control blocks, buffers for DL/I databases and program isolation (PI), which is DL/I’s lock manager. (Lock management is the process of controlling concurrent requests.) You use PI for lock management unless you need the extra facilities provided by the IRLM, which is described below. For example, you need the IRLM if you are data sharing with another DBCTL subsystem, with local DL/I, or with an IMS/VS DB/DC or IMS DM/TM system. See the IMS System Administration Guide or the IMS Administration Guide: System for guidance information on PI.
Database Recovery Control (DBRC) is an IMS facility that supports log management, recovery control, and database sharing by providing the necessary information to subsystems, batch programs, and utilities. DBRC is required with DBCTL for log control and can optionally be used for database recovery control and data sharing. See Database recovery control (DBRC) for information on DBRC and logging, and the IMS Operations Guide for more general information on using DBRC.
The internal resource lock manager (IRLM) is a global lock manager that is a feature of IMS and resides in its own address space. In simple configurations, you do not need to use the IRLM; program isolation (PI) locking is sufficient. However, you must use the IRLM to maintain data integrity if you are sharing databases at block level. (For VSAM databases, a block is a control interval (CI); for any other kind of database, it is a physical block.) You also need the IRLM if you need to process a set of common databases from multiple IMS (or CICS Transaction Server for z/OS®) subsystems. The IRLM is also the lock manager used by DATABASE 2 (DB2®), and so you may prefer to use it with DBCTL if you already use, or intend to use, DB2. See the IMS System Administration Guide or the IMS Administration Guide: System and the IMS Operations Guide for more information on the IRLM.
Figure 3 summarizes the major components in a simple CICS-IMS DBCTL environment. Each separate box represents an address space. All the components shown in Figure 3 except the IRLM are mandatory.