Triggering can be used to start applications in response to messages arriving on queues. But what do you do when nothing happens? How do you tell the difference between the queue manager not launching your application, and your application being launched but not doing anything?

Once WebSphere MQ launches the executable, it doesn’t take any further action to determine what happens to it – for example, no return codes from the executable are collected (as the trigger monitor can’t wait for what could be a long-running application). Without any such information, it can sometimes be difficult to confirm whether a triggered application is not being triggered, or is being started but ends, perhaps prematurely, with an error.

The most straightforward way is for users to modify their application so that the first thing it does is to let them know that it has been started – write to a log file, display a message, anything that shows a sign of life. But customers are not always able to make changes to their trigger applications. In these cases, the following is a useful alternative way to find out a little more.

• Alter the WebSphere MQ process object definition so that it contains an APPLICID of cmd.exe /c C:\Temp\TrigAppLauncher.bat
• Write C:\Temp\TrigAppLauncher.bat so that it looks something like

  @echo off
  echo STARTED: %TIME% >> C:\\Temp\\TrigAppLauncher.log
  C:\\Apps\\Customer\\ProblemTriggeredApplication.exe
  echo FINISHED: %TIME% (%errorlevel%) >> C:\\Temp\\TrigAppLauncher.log 

(These instructions are Windows-specific, but the same thing could easily be done using shell scripts in UNIX environments.)

This will record the start and end time of the triggered application app, together with the return code received from it.

Note that if you provide command-line parameters to your triggered application in the WebSphere MQ process object definition, then these will need to be passed on in the batch file using % variables. When the batch file is run, %0 is replaced by the name of the batch file, and the argument variables %1 to %9 are replaced by the corresponding parameters passed to the batch file.

This approach has proved very useful a number of times in quickly distinguishing between situations where an application isn’t being triggered, or is being launched but fails. Being able to get the return code from an application which is difficult to alter can often be enough to diagnose the problem.