Tips for trouble shooting trigger problems in UNIX and Windows environments
newcomb 2000000RYP Visits (7064)
Have you set up a queue for triggering and a message is put to the queue that should cause it to trigger but the message just sits there? There's a good chance that there is actually an explanatory message being written but you can't see it. Most people start the trigger monitors in a start script or as a service and so don't get to see the output. Depending on your environment and what changes are allowed, this can be fixed pretty easily.
If you are experiencing a triggering issue, you can just kill the trigger monitor and start it again from your command prompt:
strmqtrm -m myqmgr -p SYST
This trigger monitor will run in the background but messages will be written out to your window. For example, when you start the trigger monitor you will see:
5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED.
06/29/11 17:48:52 : WebSphere MQ trigger monitor started.
06/29/11 17:48:52 : Waiting for a trigger message
Once you cause a trigger event you should see something like the messages below. This is the trigger message that is passed to the application message and the format is defined in the information center if you search on MQTMC. In the example below there is an error because I didn't put single quotes around the name of the process in the APPLICID field of the process definition so it converted it to uppercase and tried to start TRIGPROC which does not exist.
TRIGPROC 'TMC 2myq
sh: TRIGPROC: not found
06/29/11 17:53:56 : End of application trigger.
06/29/11 17:53:56 : Waiting for a trigger message
Once you've diagnosed the problem, just kill the trigger monitor and start it in the normal manner. If you don't want to kill and restart the trigger monitor, another potentially less disruptive process would be to create a new initiation queue and alter the queue that is having the trigger issue to use the new imitation queue then start a trigger monitor as above pointing to the new initiation queue. Once you've diagnosed the problem you can just alter the queue back to use the original initiation queue.
You can also write the output from the trigger monitor to a file. How you do this depends on how you start the trigger monitor. If you start it from a script you can issue a command like:
strmqtrm -m yourqmgr -q yourinitiationqueue >trigger.out 2>trigger.err &
The above will create two files in whatever directory the command is run from (you may want to use the full path). These two files will be recreated every time the trigger monitor is restarted but still could become very large if there is a lot of trigger activity.
If you start the trigger monitor as a service you may want to create a definition like the one below:
DEFINE SERVICE(TRIGMON) CONTROL(QMGR) STAR
STARTARG('-q yourinitiationqueue -m your
Again you may want to put the full path name for the STDERR and STDOUT fields. Also notable is that the files will not be deleted when the queue manager is recycled and the files will just keep getting larger if you don't delete them.
Seeing the messages written by the trigger monitor should help you resolve most triggering issues.