Overview

• Sender - Receiver
• Requester - Server
• Requester - Sender
• Server - Requester
• Server - Receiver

1.   Entering control commands from the command line.
2.   Entering MQSC commands from within the RUNMQSC utility.
3.   Using programmable command formats (PCF) on supported platforms.

Triggering Channels

• Reduced operational requirements.

If channels are started manually it is reasonable to assume that this will be done one time, immediately after queue manager has been started (or at a set time).

However, because channels rely upon external resources to function properly (i.e., TCP/IP), then error conditions like unavailable remote queue managers, underlying network problems, or operating system failures will prevent a channel from starting, or subsequently cause it to fail.

The required response to these problems depends upon which mechanism was chosen to start the channel.

For manually started channels, operator intervention is required to reissue the START CHANNEL or RUNMQCHL command.

This must be done after the underlying environmental or networking issues have been resolved.

Coordinating these efforts may involve operations personnel at different geographic locations and different operating system disciplines.

Because a channel initiator starts the channel MCA based on the presence of a message on the transmission queue associated with the channel the process runs independently of any operator intervention.

As long as messages exist on the transmission queue (and all other trigger requirements are met), the channel initiator will try to start the channel.

If the required WebSpehereMQ objects and external resources required for channel operation are available, the channel initiator can successfully start the channel.

If the required external resources needed for a channel to start are unavailable, the channel initiator's attempt to start the channel will fail.

Version 5 of MQSeries (now WebSphereMQ) introduced many significant performance enhancements in MCA operation. However, along with these enhancements came some changes to how a channel functioned.

With Version 5 channel status information is retained across invocations. The MCA considers some network errors as 'permanent'.

When a 'permanent' error occurs, the receiver channel retains a status of STOPPED.

In these cases, normal triggering alone cannot successfully restart the channel. A START CHANNEL command must be explicitly issued on the receiver side of the channel to clear the "hard fail" condition that was recorded.

On the sender side of the channel, you may to encounter a channel status of RETRYING.    This condition indicates that the MCA is attempting to restart the channel, but does not have the required resource available to it.

It is also possible that the XMITQ being serviced by the sender side MCA was placed in a "get inhibited" state when the original channel failure occurred.    An 'ALTER QLOCAL' command must be issued to WebSphereMQ to reset the GET attribute of the XMITQ to ENABLED.

• Disconnect Interval.

The 'Channel Disconnect Interval' has much more of a role to play when channels make use of triggering.

The 'Channel Disconnect Interval' determines how long a channel will stay in the RUNNING state while no messages are being transmitted.

When this timer is exceeded, WebSphereMQsets the channel status to INACTIVE.

An INACTIVE channel can be started again with an operator command.   Obviously, with triggering, this will take place 'automatically' when there are new messages on the transmission queue.   When this happens the channel initiator restarts the channel.

Care must be taken to properly specify the disconnect interval.

If the disconnect interval is set too short, CPU resources will be wasted in needlessly shutting down and then quickly restarting channels.

Conversely, setting this parameter value too long defeats its useful purpose, in most cases.

• Security 'Exposure'.

There is a 'negotiation' that takes place (called a BIND) when two Queue Mangers attempt to start a channel.

Part of this negotiation is to agree on various criteria that will exist for the duration of the channel connection.

One of these is (optionally) an encryption token.   Channel encryption makes all message contents 'unreadable' as it flows across the channel.

The longer a channel remains active, the bigger the window of opportunity is to any subversive attempts to 'hack' the channel.

Setting a disconnect interval of 0 tells the MCA to never disconnect the channel.  Doing this means that any encryption token that was negotiated at BIND will be used for the life cycle of this channel execution instance.  This could potentially be days, weeks or even months, giving a large window of opportunity to any potential subversive action.

Conclusion