RichardHamilton 060001RC0R Visits (16594)
In my "Triggering for beginners" blog entry the focus was triggering user programs. This is a follow-up with details for triggering channels. If you didn't see that post, then I suggest you read it before continuing. Triggering is essentially the same for triggering programs and triggering channels, however there are some important differences.
Triggering WebSphere MQ channels is much easier than triggering programs: you don't need to start a trigger monitor, because the Channel Initiator is a special purpose trigger monitor that runs at MQ start-up. You don't need to define a process, because the Channel Initiator doesn't need that information. You don't need to define an initiation queue, you should use the SYST
Assuming that you already have a working channel, all you need to do is alter your transmission queue with all of the attributes to enable it for triggering. The attributes that are required to enable your transmission queue for triggering are: get (enabled), put (enabled), trigger, trigtype (first), initq (sys
Note: The Trigger control parameter does not have a value, it is expressed as: "trigger" or "notrigger".
Triggering channels and the sequence of events:
Triggering channels and sequence of events. (Click to enlarge)
Trigger type first should always be used when triggering channels, and it requires some special planning and consideration. The Channel Initiator only considers triggering, if the current depth of the transmission queue goes from zero to one. You can also get an extra trigger event message when the queue manager trigger interval expires. The trigger interval is expressed is milliseconds, and by default set to (999999999), 11.5 days, which way too long. Be careful when setting trigger interval; if you set it too low, then it will work like trigger "every", which could cause problems. You can change trigint using the MQSC alter qmgr command.
Note: 99999 milliseconds is about 1.6 minutes
Debugging is a bit more difficult when triggering channels. When things go wrong, messages back up on the transmission queue, and you will need manual intervention to recover. In many cases the Channel Initiator detects an error, and it will set the transmission queue to "notrigger" and also disable gets. If that happens, find the root cause, correct the problem, and then alter the transmission queue to reset the triggering attributes (see Example3 below). You will also need to manually start the sender channel if the current depth is greater than zero.
In the scenario where everything has been working as expected, and then suddenly stops working: I would suspect a channel problem; fix the channel problem, and then reset the triggering attributes on your transmission queue to enable triggering (see Example3 below).
If triggering has never worked. then try to start the channel manually. If the channel doesn't work as expected, then fix the channel problem, and reset the triggering attributes on your transmission queue (see Example3 below). However, if you can manually start your channel, then you need to examine your triggering configuration. Display the transmission queue to ensure that triggering attributes are set correctly with: get (enabled), put (enabled), trigger, trigtype (first), usage (xmitq), and initq (sys
Here is an example of a channel problem that caused a triggering problem: You stop your sender channel, and you don't realize that it will disable triggering. The channel is in "stopped"status and triggering will only happen if the channel is in "running", or "inactive" status (see Picture 1). This is just one example and there are many reasons why a channel, or triggering might fail.
If you examine the transmission queue you will find that triggering is disabled and gets are inhibited. You will also see that the current depth is greater than zero. With trigger type first, triggering is not going to occur until the messages are removed from the queue (see Picture 2).
In this testcase I tried to start the sender channel in an attempt to recover, however the sender channel could not start because, gets were disabled for the transmission queue.
To recover from this failure: I reset the triggering attributes using the alter ql command, and started the sender channel. At that point the messages were transmitted over the channel and triggering was enabled.