Search

Channel Triggering Example

A common problem in new MQ installations is channel management. In the midst of trying to learn the MQI, the RUNMQSC commands, and Queue Manager tuning, it's frustrating to have to continually start, stop or check the status of the channels. The obvious solution is simply to set the timeout parameter so that the channels to stay up all the time. While this has it's advantages, there are many events which can bring the channel down abnormally causing sequence numbers to get out of synch, ghost channels or worse. This approach is rather optimistic in assuming that it is possible to keep the channel up forever and worse, when it does die, the manual intervention required is almost always more involved than a simple restart.

A more robust approach is to use the instrumentation built into MQ to manage the channels automatically. This allows the channels to shut down in an orderly fashion in most cases and subsequently restart on the presence of data in the XMITQ. While down, the channel will be able to ride out system events such as a reboot, beaconing on a token ring or physical connectivity failure without manual intervention. While it is running, the channel will still be vulnerable to abnormal system events but since it is 'up' a lot less, the result should be increased stability and less manual operator intervention.

The was originally set up on HP so there are specific references to that system (for instance the redirection of output in the shell script). Also, the MQ object names have been simplified for convenience. 

>>Sorry if the platform coverage is too narrow, if you can contribute articles on other platforms, please contact the MAMQSUG webmaster here (removed).

That being said, here's the details:


There is a fictional Queue Manager named QMGR. The standard AMQSCOMA.TST definitions were run so it has an INITQ named SYSTEM.CHANNEL.INITQ. It also has an XMITQ named QMGR.XMITQ1 which uses a CHANNEL named QMGR.CHANNEL.NAME. The only additional object definition required for automatic channel initiation is a process. Our fictional process has the same name as the XMITQ it services.

First, the XMIT queue must be defined for triggering:

** --------------------------------------
** Minimal XMITQ definition...
def ql (QMGR.XMITQ1) +
replace +
usage (xmitq) +
** --------------------------------------
** Added for triggering of channels...
initq (SYSTEM.CHANNEL.INITQ) +
process (QMGR.XMITQ) +
trigger +
trigtype (first)

You must specify TRIGGER since the default is NOTRIGGER. Set the trigger type to FIRST. The name of the process is the same as the name of the XMITQ for convenience. Next, we define the process pointed to in the XMITQ definition. Recall that the process name in the example is equal to the XMITQ name. The channel name is placed in the USERDATA attribute for the Channel Initiator program to use.

** --------------------------------------
** Process definition
** Added for triggering of channels...
def process (QMGR.XMITQ) +
replace +
descr ('Start Channel when msgs hit XMITQ') +
userdata (QMGR.CHANNEL.NAME)

The channel definition is listed here for reference but there is nothing special about it:

** --------------------------------------
** Minimal Channel definition...
def chl (QMGR.CHANNEL.NAME) +
chltype (SDR) +
trptype (TCP) +
conname ('MACHINE.NAME.OR.IP.ADDRESS') +
xmitq (QMGR.XMITQ) +
mcauser (mqm) +
replace

It's worth noting here that the three objects just defined point to each other in a closed loop. The XMITQ points to the PROCESS which points to the CHANNEL which in turn points back to the XMITQ.

Finally, a special trigger monitor just for channels, RUNMQCHI, is provided by IBM. It is ordinarily set up to be started with the queue manager on system boot but may be run by a user with sufficient authority. The script we used to start up the Queue Manager in the lab is listed below.

# ----------------------------------------------------------------
# Start up Default Queue Manager and trigger monitor
# Job output appended to log files in mqm home dir
strmqm
runmqtrm SYSTEM.DEFAULT.INITIATION.QUEUE >>/home/mqm/log/mqtrm &

# Added for automatic channel initiation
# Queue used must be same as that named in XMITQ definition
runmqchi -q SYSTEM.CHANNEL.INITQ >>/home/mqm/log/mqchi &

If the definitions are coded as above, all channels will be started via the SYSTEM.CHANNEL.INITQ and only one instance of RUNMQCHI is needed. If it is desired to isolate channels by application, class-of-service or any other criteria, simply define a seperate initiation queue for each and run an instance of RUNMQCHI for every initiation queue. XMITQs may then be defined to point to the initiation queue of your choice.

The system startup script captures logfiles of the output of the trigger monitor and channel initiator processes. This is quite helpful for debugging but be sure to clean the log files out often! Also, the 'runmqtrm' line is the regular trigger monitor and is not relevant to channel initiation.

The channel attributes should be tuned over time to the expected usage patterns. Experiment with long and short channel timeouts. Longer timeouts make the channels more vulnerable to hiccups in the underlying protocol. On the other extreme, too short a timeout will cause excessive round-trip latency while waiting for multiple channels to start up on every message. Although the short-timeout method is slow , it is reliable. With some tuning, a suitable compromise can be arrived at.

Login Form