The IMS control region has separate address spaces that provide some of the IMS subsystem services.

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

DL/I Separate Address Space

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

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

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

Dependent Regions

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

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

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

• Message processing region (MPR)
• IMS Fast Path (IFP) region, processing Fast Path applications or utilities
• Batch message processing (BMP) region, running with or without HSSP (High Speed Sequential Processing)
• Java message processing (JMP) region
• Java batch processing (JBP) region
• DBCTL thread (DBT)

Table 1 describes the support for dependent regions by IMS environment type.

Message Processing Region

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

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

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

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

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

Two types of applications can run in BMP regions:

• Message-driven BMP applications (also called transaction-oriented BMP applications), which read and process messages from the IMS message queue
• 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 control region has the Database Manager component installed. BMP regions can also read and write to z/OS sequential files, with integrity, using the IMS GSAM access method.

BMP regions can also be used for other types of work besides running application programs. BMP regions can be used for jobs that, in the past, were run as batch update programs. The advantage of converting batch jobs to run in BMP regions is that the batch jobs can now run along side of a transaction 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 or object-oriented COBOL message-processing applications. A JMP application is started when there is a message in the queue for the JMP application and IMS schedules the message to be processed. JMP applications are executed through transaction codes submitted by users at terminals and from other applications. Each transaction code represents a transaction that the JMP application processes. A single application can also be started from multiple transaction codes.

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

• They are small.
• They can produce output that is needed immediately.
• 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 access the IMS message queues for output (similar to non-message-driven BMP applications). JBP applications are started by submitting a job with JCL or from TSO. JBP applications are like BMP applications, except that they cannot read input messages from the IMS message queue. Similarly to BMP applications, JBP applications can use symbolic checkpoint and restart calls to restart the application after an abend. JBP applications can access IMS or DB2 data 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 Java hierarchical interface calls are passed to the IMS Java layer, which converts them to DL/I calls.

Figure 10. JMP or JBP Application 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/OS coupling facility on behalf of multiple clients. CQS is used by IMS shared queues and the Resource 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 facility is divided into distinct objects called structures. Authorized programs use structures to implement data 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 the same names, known as queues. Resource structures contain data objects organized as uniquely named resources.

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

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

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

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

• Share either databases or resources or message queues (or any combination)
• Run in an z/OS sysplex environment
• 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:

• The complete version of An Introduction to IMS
• Administering Sysplex Data Sharing in Administration: System

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

• IMS in the Parallel Sysplex: Volume I: Reviewing the IMSplex Technology
• IMS in the Parallel Sysplex: Volume II: Planning the IMSplex
• 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 an application programming interface (the OM API) through which commands can be issued and responses received. With a single point of control (SPOC) interface, you can submit commands to OM. The SPOC interfaces include the TSO SPOC, the REXX SPOC API, and the IMS Control Center. 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 and IMSplex-wide processes in a sysplex on behalf of RM's clients. IMS is one example of an RM client.

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 or among multiple z/OS images. Individual IMS components do not need to know where the other components reside or what communication interface to use.