Overview of IMS/ESA

IMS applications execute in four types of regions, each geared to a specific set of application processing needs. These types are known as:

Message Processing regions (MPRs)
Fast Path regions (IFPs)
Batch Message Processing regions (BMPs)
Batch DL/I regions (DLBs).

MPRs, IFPs, and BMPs are IMS DC-dependent online regions that access an IMS online database. DLBs are stand-alone regions that access an IMS offline database.

DL/I is a language that IMS applications use to manipulate databases and interact with data communications networks. DL/I includes a set of services that can be requested by applications to manipulate database (DB) data and to interact with data communications networks (DC). DL/I application programs communicate with IMS DC by requesting DL/I functions associated with an Input/Output Program Communication Block (I/O PCB) or alternate PCB.

DL/I services use two control blocks to enable application programs to communicate with a database without a pointer to the physical location of the data. Database Descriptors (DBDs) define the physical structure of the database. A database Program Communication Block (DB PCB) refers to a DBD and defines the segments to which the application is sensitive and the type of access the application is permitted. A Program Specification Block (PSB) is a collection of DB PCBs or I/O PCBs that can be assigned to an application.

Some DL/I functions commonly used with IMS/DC are:

GET UNIQUE (GU), to retrieve the first input message
GET NEXT (GN), to retrieve subsequent input messages
INSERT (ISRT), to send an output message.

DL/I applications manipulate IMS database data by requesting DL/I functions with a Database Program Control Block (DB PCB). Some DL/I functions commonly used with IMS DB are:

GET UNIQUE (GU), to retrieve a database segment and establish positioning for further processing
GET HOLD UNIQUE (GHU), to retrieve a database segment, position for further processing, and retain the segment for an update or delete
GET NEXT (GN), to retrieve the next database segment
GET HOLD NEXT (GHN), to retrieve the next database segment and hold it for an update or delete
GET NEXT WITHIN PARENT (GNP), to retrieve the next database segment in the current hierarchy
GET HOLD NEXT WITHIN PARENT (GHNP), to retrieve the next database segment in the current hierarchy and hold it for an update or delete
REPLACE (REPL), to replace the currently held database segment
INSERT (ISRT), to add a new database segment occurrence
IX_IMS_DB_DC_1 •DELETE (DLET), to delete the currently held database segment and its dependents, if any.

A DL/I call can contain one or more Segment Search Arguments (SSAs). SSAs allow DL/I applications to form specific arguments describing the database segments to search, and to define selection criteria for DL/I to use when it executes the service call. DL/I calls can be qualified or unqualified. A qualified call uses one or more SSAs to form a complete path to a segment. An unqualified call contains only a segment name and does not use SSAs.

SSAs can also be qualified or unqualified. An unqualified SSA contains only the segment name. A qualified SSA defines which segment occurrence to access by using field names and values, relational operators, and command codes as qualifiers.

IMS/ESA DB/DC environment

IMS/ESA consists of two components, the Database Manager (DB) and the Transaction Manager (TM). The Database Manager allows you to create batch and database control (DBCTL) environments. The Transaction Manager allows you to create the data communication control (DCCTL) environment. Combining the Database and Transaction Managers produces the database/data communication (DB/DC) system, a multi-region environment with both system and application management facilities.

The following figure illustrates a hypothetical IMS DB/DC system. The figure shows the overall layout of regions composing the system and establishes the execution environment for DL/I applications. Brief descriptions of the region types are given below. For more information, refer to the IBM IMS/ESA Administration Guide: System.

Hypothetical IMS DB/DC System

IMS system regions

This section describes the MVS address spaces known as IMS system regions: the control region, the Database Recovery Control (DBRC) address space, the DL/I Separate Address Space (DLISAS), and the internal resource lock manager (IRLM).

Control Region (CONTROL)	The control region anchors the entire IMS DB/DC system. It supervises message processing and communications with terminals, services DL/I calls, and manages restart, recovery, and the IMS system log.
Database Recovery Control (DBRC)	The control region automatically initiates the DBRC address space to help manage database availability, data sharing, and system logging for data integrity.
DLISAS	Specifying a Local Storage Option (LSO) of “S” causes the IMS control region to initiate the DLISAS, which contains DL/I code, control blocks, and buffers for full-function databases. IMS uses MVS cross-memory services to invoke DL/I to process application database calls.
internal resource lock manager (IRLM)	IRLM controls data sharing among dependent regions and other IMS systems. It is an optional IMS facility that protects database integrity by managing both local and global lock requests for multiple IMS systems, thus controlling access to resources that participate in data sharing. IRLM overrides Program Isolation (PI) locking, which controls local lock requests for single IMS systems. To activate the IRLM component, invoke a procedure from the master terminal with the MVS START command.

Dependent regions

Dependent regions are MVS address spaces that are separate from, but functionally dependent on, the IMS control region.

In an IMS subsystem, the IMS control region performs all terminal control functions and schedules incoming transactions for processing in one or more dependent regions. To study the resource demands associated with a particular IMS transaction or function, you need to measure the dependent region that services the transaction or function.

Message Processing Regions (MPRs)	Message Processing applications allow interactive access to IMS online databases and message queues. IMS schedules these applications by associating each one with a transaction name and class. When a terminal input message with the transaction name associated with the application arrives in the control region, IMS DC schedules the application in an available Message Processing region (MPR) dedicated to processing its class. IMS starts the transaction, then gives control to the IMS application program, which issues and services DL/I DB/DC requests. While the application has control of the MPR, Strobe identifies the transaction name and the module currently active or waiting. When the transaction completes, the MPR becomes available to process more transactions.
IMS Fast Path Regions (IFPs)	IMS schedules applications in Fast Path regions (IFPs) through routing codes, which are similar to the transaction names used with Message Processing regions (MPRs). IFP applications use database functionality that is not part of IMS full function (DL/I) database services, such as a Data Entry Database (DEDB) and a Main Storage Database (MSDB). When a terminal input message with a routing code arrives in the control region, IMS Fast Path schedules the application to execute in an available IFP region dedicated to processing the routing code. Once it starts, IMS Fast Path services satisfy any database service requests. While the application has control of the IFP region, Strobe identifies the routing code and the module currently active or waiting. When the application completes, the IFP region becomes available to process more Fast Path applications.
Batch Message Processing Regions (BMPs)	When a user submits a batch application, IMS schedules it to execute in Batch Message Processing regions (BMPs). A transaction name may trigger scheduling. Though applications that execute as BMPs are not interactive, they can access IMS online databases, message queues, and MVS datasets. While the application has control of the BMP, Strobe identifies the name of the module currently active or waiting. When the application completes, the BMP region terminates.

Batch regions

Batch regions are IMS DB regions with no dependence on IMS DC. They start as submitted jobs that allocate all DL/I database datasets. No transaction or routing code is involved. The DL/I DBMS, which resides within the batch region, satisfies all DL/I service requests made by applications in the region. Batch applications are not interactive and do not access an IMS online database.

While the application has control of the batch region, Strobe identifies the name of the module currently active or waiting. When the application completes, the batch region terminates.

How applications communicate with IMS

DL/I application programs are loaded into and executed within IMS dependent and batch regions in the following manner:

The IMS control region handles all messages from terminals and application programs.
Application programs communicate with message queues and databases by issuing DL/I calls.
Programs request a DL/I service using the native program linkage facilities provided by the language in which the application is written.
When it calls DL/I, the program passes a parameter list containing an optional parameter count, a DL/I function, a Program Communication Block (PCB), the data area in the program for DL/I services to return data, and any SSAs containing database data selection criteria. For example, a COBOL DL/I call that supplies DLI-FUNCTION as the data-name for the DL/I function, PCB-MASK as the PCB, I/O-AREA as the return data area, and SSA-AREA as the data selection criteria has the following syntax:
CALL 'CBLTDLI' USING DLI-FUNCTION,
PCB-MASK,
I/O-AREA,
SSA-AREA.
When the application program call is issued, IMS invokes system service routines to examine the parameters, process requested functions, and return the results and control to the application program.

CICS/DBCTL environment

DL/I applications execute as CICS transactions within a CICS address space that is connected to an IMS system through the DBCTL interface. The following figure shows the layout of the region in a hypothetical CICS/DBCTL system and how it establishes the execution environment for DL/I applications. The batch, IRLM, DBRC, and DLISAS regions are the same as those in a IMS DB/DC environment.

Hypothetical CICS/DBCTL System

CICS/ESA regions

CICS/ESA regions contain the CICS system service modules, application code, and the DBCTL Resource Manager Interface (RMI).

DBCTL Thread Tasks	When CICS is connected to IMS DBCTL, MVS tasks are created to service DL/I requests made by CICS transactions. These MVS tasks are called DBCTL threads, and each represents a path to IMS. The CICS/DBCTL Resource Manager Interface assigns a DL/I request to an available thread task for execution.
IMS System Regions	The control, IRLM, DBRC, and DLISAS regions are the same as those in a IMS DB/DC environment.

How DL/I applications execute in CICS/DBCTL environments

When a DL/I application running in a CICS/DBCTL environment issues an EXEC DLI call or a CALLDLI command, the following occurs:

CICS receives the request and determines that a DL/I service is being requested.
ICS assigns the DL/I request to an available DBCTL thread task for execution.
IMS service routines residing in the IMS system regions service the DL/I request.
Upon completion, the thread task returns control to CICS, which returns control and the results to the application.