Message Queuing | An Introduction to IMS: Your Complete Guide to IBMs Information Management System

All full-function input and output messages in IMS are queued in message queues, as shown in Figure 13-2 on page 199. For Fast Path transactions, see "Fast Path Transactions and Message Queues" on page 200.

Figure 13-2. Overview of the Message Queuing Process

IMS uses message queues to enable input processing, output processing, command processing, and application program processing to be performed asychronously, to a large extent. This means, for example, that the input processing of message A can be performed in parallel with the database processing for message B and the output processing for message C. Messages A, B, and C can be different occurrences of the same or different message types or transaction codes.

Messages in the IMS message queues are stored by destination, priority, and the time of arrival in IMS. A destination can be:

A message processing program (MPP) or a message-driven Java application (JMP), which is for transaction input. Ordering is by transaction code.
A logical terminal (LTERM), which is for a message switch, command responses, and output generated by application programs.

For a single instance of IMS, the message queue buffers are maintained in main storage (defined by the MSGQUEUE macro). If the memory-based message queue buffers become full, messages are then stored on the message queue data sets on DASD. The queue blocks in main storage and on direct access storage are reusable. IMS stores as many messages as possible in the message queue buffers to minimize the number of I/O operations required during processing.

Message Queue Size and Performance Considerations

Messages in the IMS message queue are primarily held in buffers in main storage. However, when messages are added to the queues faster than IMS can process these messages, the message queue buffers can fill. In this situation, any new messages are written to the message queue data sets. The performance of these data sets then becomes very important. The data sets should be on a DASD volume with fast response times, and the data sets should be appropriately sized to ensure that there is always space available.

Multiple Message Queue Data Sets

The IMS Queue Manager supports concurrent I/O operations to its message queue data sets, allowing the IMS message queue to be distributed across multiple physical queue data sets. This enhancement supports the long and short message queue data sets.

The multiple message queue data set function is activated when you supply more than one DD statement per message queue data set. You can supply up to ten DD statements for each queue data set. These DD statements can be allocated on different device types, but LRECL and BLKSIZE must be the same for all the data sets of a single queue.

IBM strongly recommends that multiple queue data sets be used, so that in an emergency situation, IMS system performance is not degraded while IMS tries to handle a large volume of messages going to and from the message queue data sets.

Related Reading: See IMS Version 9: Installation Volume 1: Installation Verification and IMS Version 9: Installation Volume 2: System Definition and Tailoring for detailed guidelines about selecting message queue parameters such as block sizes, QPOOL size, and queue data set allocation.

Fast Path Transactions and Message Queues

Fast Path transactions do not use the standard IMS message queues. Fast Path transactions are scheduled by a separate function within the IMS transaction manager, called the Expedited Message Handler (EMH). For more information, see "Scheduling Fast Path Transactions" on page 212.

APPC-Driven Transactions and Message Queues

There are two types of APPC transactions: implicit and explicit. With implicit APPC transactions, IMS receives a transaction request via APPC. This transaction is placed onto the IMS message queues in the same way as a 3270-generated transaction. The message is passed to an MPP for processing, and the response is routed back to the originating APPC partner. The MPP uses the DL/I interface to receive the message from the message queue and put the response back onto the message queue.

With explicit APPC transactions, IMS schedules a program into an MPR (message processing region). This program uses APPC verbs to communicate with the APPC partner program to process the transaction. The standard IMS messages queues are not used for explicit APPC transactions.

OTMA-Driven Transactions and Message Queues

OTMA allows IMS to receive a message through a different communications protocol (for example, WebSphere MQ, remote procedure calls, and IMS Connect for TCP/IP sockets). The message is received by IMS and is placed into the IMS message queue for processing in the usual manner. The response message is passed back to the originator through OTMA.

Shared Queues

IMS provides the ability for multiple IMS systems in a parallel sysplex environment to share a single set of message queues. This is known as shared queues and the messages are held in structures in a coupling facility. All the IMS subsystems in the sysplex share a common set of queues for all non-command messages (that is, input, output, message switch, and Fast Path messages). A message that is placed on a shared queue can be processed by any of several IMS subsystems in the share queues group as long as the IMS has the resources to process the message. Results of these transactions are then returned to the initiating terminal. End users need not be aware of these activities; they view the processing as if they were operating a single system.

Using shared queues is optional and you can continue to process with the non-sysplex message queue buffers and message queue data sets.

Operating in a shared-queues environment allows multiple IMSs in a sysplex environment to share IMS message queues and EMH message queues. The IMSs work together as an IMSplex providing a single-image view of multiple IMSs.

Definitions:

A shared queue is a collection of messages that are associated by the same queue name. A shared queue is managed by a Common Queue Server (CQS) and can be shared by CQS clients in an IMSplex.
A Common Queue Server receives, maintains, and distributes data objects from a shared queue that resides in a coupling facility list structure for its client.
A CQS client is an IMS DB/DC or DCCTL system that accesses shared queues through its own CQS.
A coupling facility is a special, logical partition that provides high-speed caching, list processing, and locking functions in a sysplex environment.
A sysplex environment is a set of z/OS systems that communicate and cooperate with one another through certain multisystem hardware components and software services in order to process workloads.
An IMSplex is one or more IMS control regions, managers, or servers that work together as a unit. Typically, but not always, IMSs in an IMSplex:
Share either databases or resources or message queues (or any combination)
Run in an S/390® Parallel Sysplex environment
Include an IMS Common Service Layer (CSL)

In general, IMS handles messages in the following manner:

IMSs register interest in those queues for which they are able to process messages.
When an IMS receives a message and places it on the shared queue, all IMSs that have registered interest in that queue are notified.
One IMS retrieves the message and processes it.
The IMS that processes the message places a response on the queue.
The IMS that submitted the original message is notified that the response message was placed on the queue.
The IMS that submitted the original message sends the response message to the originating terminal.

Figure 13-3 shows a basic shared-queues environment.

Figure 13-3. Basic Shared-Queues Environment

Benefits of Using Shared Queues

The major benefits of operating in a shared-queues environment are:

Automatic workload balancing

A message that is placed on a shared queue can be processed by any participating IMS that is available to process work.

Incremental growth

You can add new IMSs as workload increases.

Increased reliability

If one IMS fails, work that is placed on a shared queue can still be processed by other IMSs.

Recommendations:

Enabling shared queues does not require the use of generic resource groups; however, IBM recommends that you use the two functions together.
IBM recommends that all data in an IMSplex be shared across the IMSplex.

Required Components of a Shared-Queues Environment

Although you can operate many different configurations of a shared-queues environment, the required components of shared-queues processing, shown in Figure 13-4 on page 204, include:

Figure 13-4. Components of a Shared-Queues Environment

Common Queue Server (CQS)

One CQS is required for each client. Each CQS accesses the shared queues, which reside on coupling facility list structures.

CQS client

One or more IMS DB/DC or DCCTL subsystems that can access the shared queues using CQS client requests.

z/OS coupling facility list structures

A type of coupling facility structure that maintains the shared queues.

Definitions:

A list structure is an area of storage in a coupling facility that enables multisystem applications in a sysplex environment to share information that is organized as a set of lists or queues. The list structure consists of a set of lists and an optional lock table.
CQS maintains list structures in pairs, called structure pairs, with a primary list structure and an overflow list structure.
The primary list structure contains the shared queues.
The overflow list structure, if defined, contains shared queues that overflow after the primary list structure reaches a predefined threshold.

z/OS system log

One z/OS system log is used for each structure pair. CQS places recovery information about the work it has processed and about the list structure pair in the z/OS log streams. These log streams are then shared by all CQSs that access the list structure pair.

CQS checkpoint data set

One CQS checkpoint data set is maintained for each structure pair of each CQS. The CQS checkpoint data set contains CQS system checkpoint information.

CQS structure recovery data sets (SRDSs)

CQS maintains two SRDSs for each structure pair so that shared queues on the structures can be recovered. The SRDSs maintain structure checkpoint information for the shared queues.

Related Reading: For more information on CQS requests and other CQS topics, see IMS Version 9: Common Queue Server Guide and Reference.

Overview of the Common Queue Server

The Common Queue Server (CQS) is an internal interface by which IMS communicates with shared message queues. You can use IMS commands to initiate CQS requests. The CQS address space is started by the IMS.

CQS performs the following services:

Notifies registered clients when work exists on the shared queues.
Provides clients with an interface for accessing shared queues and CQS.
Writes CQS system checkpoint information to a CQS checkpoint data set.
Writes structure checkpoint information to an SRDS for recovery of a shared-queues list structure.
Provides structure recovery and overflow processing for the shared-queues list structure.
Drives the following CQS client exit routines:
- The Client CQS Event exit routine notifies the client of system events, such as CQS abnormal termination and CQS restart completion.
- The Client Structure Event exit routine notifies the client of structure events, such as structure copy, structure recovery, structure overflow, structure checkpoint, and structure resynchronization.
- The Client Structure Inform exit routine notifies the client when work exists on the shared queues.
Drives the following CQS user-supplied exit routines:
- The CQS Queue Overflow user-supplied exit routine allows the exit to approve or reject a queue that CQS selects for overflow.
- The CQS Initialization/Termination user-supplied exit routine is notified when CQS initializes and when CQS terminates after disconnecting from all structures (under normal termination conditions).
- The CQS Client Connection user-supplied exit routine participates in connecting clients to structures and in disconnecting clients from structures.
- The CQS Structure Statistics user-supplied exit routine gathers structure statistics during CQS system checkpoints.
- The CQS Structure Event user-supplied exit routine tracks structure activity, such as structure checkpoint, structure rebuild, structure overflow, and structure status change. It also tracks when CQS connects to a structure or disconnects from a structure.
Provides the Log Print utility with sample JCL that enables you to print log records from the z/OS log.