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:
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 ConsiderationsMessages 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 SetsThe 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 QueuesFast 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 QueuesThere 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 QueuesOTMA 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 QueuesIMS 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.
In general, IMS handles messages in the following manner:
Figure 13-3 shows a basic shared-queues environment. Figure 13-3. Basic Shared-Queues Environment
Benefits of Using Shared QueuesThe major benefits of operating in a shared-queues environment are: Automatic workload balancing
Incremental growth
Increased reliability
Recommendations:
Related Reading:
Required Components of a Shared-Queues EnvironmentAlthough 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)
CQS client
z/OS coupling facility list structures
z/OS system log
CQS checkpoint data set
CQS structure recovery data sets (SRDSs)
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 ServerThe 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:
Related Reading:
|