Shared channels
Use this topic to understand the concepts of shared channels and their use with IBM MQ for z/OS .
A number of networking products provide a mechanism to hide server failures from the network, or to balance inbound network requests across a set of eligible servers. The network products make a generic port available for inbound network connection requests, and the inbound request can be satisfied by connecting to one of the eligible servers.
These networking products include:
- VTAM generic resources
- SYSPLEX Distributor
The channel initiator takes advantage of these products to use the capabilities of shared queues
There are two types of shared channels, shared inbound channel, and the shared outbound channel.For further information about channels see
Shared inbound channels
Each channel initiator in the queue sharing group starts an additional listener task to listen on a generic port. This generic port is made available to the network by one of the supporting technologies (VTAM, TCP/IP). Inbound network attach requests to the generic port are dispatched by the network technology, to any one of the listeners in the queue sharing group (QSG) that are listening on the generic port.
We can start a channel on the channel initiator to which the inbound attach is directed if the channel initiator has access to a channel definition for a channel with that name. We can define a channel definition to be private to a queue manager or stored on the shared repository and so available anywhere (a global definition). This means that we can make a channel definition available on any channel initiator in the queue sharing group by defining it as a global definition.
There is an additional difference when starting a channel through the generic port; channel synchronization is with the queue sharing group and not with an individual queue manager. For example, consider a remote queue manager starting a channel through the generic port. When the channel first starts, it might start on queue manager QM1 and messages flow. If the channel stops and is restarted on queue manager QM2, information about the number of messages that have flowed is still correct because the synchronization is with the queue sharing group.
You can use an inbound channel started through the generic port to put messages to any queue. The remote queue manager does not know whether the target queue is shared or not. If the target queue is a shared queue, the remote queue manager connects through any available channel initiator in a load-balanced fashion and the messages are put to the shared queue.
If the target queue is a private queue, the messages are put to the private queue owned by which ever queue manager the current instance of the channel is connected to. In this environment, known as replicated local queues, each queue manager must have the same set of private queues defined.
Configure SVRCONN channels for a queue sharing group
The optimal configuration for SVRCONN channels in a queue sharing group is to set up private listeners in each CHINIT which use a different port number from the point to point channels. These listener ports are then used as the 'back-end' resources for a new workload distribution mechanism such as Sysplex Distributor using Virtual IP addresses (VIPA). The external VIPA address is then used as the target address for the CLNTCONN definitions in the network. The SVRCONN channel can be defined with QSGDISP(GROUP) so the same definition is available to all queue managers in the QSG. This configuration avoids using a shared listener, and therefore the reduces performance effect of the queue sharing group maintaining shared channel state which is not needed for client/server channels.
Shared outbound channels
An outbound channel is considered to be a shared channel if it is taking messages from a shared transmission queue. If it is shared, it holds synchronization information at queue sharing group level. This means that the channel can be restarted on a different queue manager and channel initiator instance within the queue sharing group if the communications subsystem, channel initiator, or queue manager fails. Restarting failed channels in this way is a feature of shared channels called peer channel recovery.
- Workload balancing for shared outbound channels
- An outbound shared channel is eligible for starting on any channel initiator within the queue sharing group, if you have not specified that we want it to be started on a particular channel initiator. The channel initiator selected by IBM MQ is determined using the following criteria:
- Is the communications subsystem required currently available to the channel initiator?
- Is a Db2 connection available to the channel initiator?
- Which channel initiator has the lowest current workload? The workload includes channels that are active and retrying.
Shared channel summary
Shared channels differ from private channels in the following ways:
- Private channel
- Tied to a single channel initiator.
- Outbound channel uses a local transmission queue.
- Inbound channel started through a local port.
- Synchronization information held in SYSTEM.CHANNEL.SYNCQ queue.
- Shared Channel
- Workload balanced with high availability.
- Outbound channel uses a shared transmission queue.
- Inbound channel started through a generic port.
- Synchronization information held in SYSTEM.QSG.CHANNEL.SYNCQ queue.
You specify whether a channel is private or shared when you start the channel by using CHLDISP options with the START CHANNEL command. A shared channel can be started by triggering in the same way as a private channel. However, when a shared channel is started, IBM MQ performs workload balancing and starts the channel on the most appropriate channel initiator within the queue sharing group. (If required, we can specify that a shared channel is to be started on a particular channel initiator.)
Shared channel status
The channel initiators in a queue sharing group maintain a shared channel-status table in Db2. This records which channels are active on which channel initiators. The shared channel-status table is used if there is a channel initiator or communications system failure. It indicates which channels need to be restarted on a different channel initiator in the queue sharing group.
Parent topic: Distributed queuing and queue sharing groups