ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Messaging and Integration Technologies FAQ » Why doesn't my triggered application work?

Post new topic  Reply to topic
 Why doesn't my triggered application work? « View previous topic :: View next topic » 
Author Message
jefflowrey
PostPosted: Wed Jan 21, 2004 12:11 pm    Post subject: Why doesn't my triggered application work? Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

The most common problems with triggered applications are PATH or CLASSPATH (for Java applications) problems.

All triggered applications are started by some sort of trigger monitor process. This means that the environment variables, and the current working directory, for triggered applications are determined by what is in effect for the trigger monitor process.

For example, if your trigger process writes a log file by specifing a relative path instead of an absolute path ("MyLogFile" instead of "C:\MyLogFile" or "/etc/logs/MyLogFile"), then MyLogFile will be written in the current working directory for the Trigger Monitor (which is going to be the path to the trigger monitor binary, and not the path to your application itself).

For example, if your application can't be launched because the binary can't be found, again this is because the PATH for the Trigger Monitor does not include the binary itself, and you specified a relative path to the application ("MyBinary" instead of "C:\Program Files\MyBinary.exe" or "/usr/bin/MyBinary").

The best way to set up a triggered application to avoid all of these problems is to set up a script (either a windows .bat or .com file, or a unix shell script) that is run instead of your application. This script file should set all necessary environment variables (including PATH, CLASSPATH, and MQSERVER or MQCLTTBL), and set the current working directory to the appropriate thing (using the 'cd' command), and then launch your application.

The next most common problem with triggered applications has to do with security. Again, this is because the security that is in effect is the security for the user running the Trigger Monitor. This can't be generically fixed with a script file, but you can change the user authorities that the Trigger Monitor runs under as needed using your normal platform facilities for doing so. If you need to run different applications under different user identities, you will likely need to run separate trigger monitors.

The third most common problem with triggered applications occurs on Windows platforms. Windows trigger monitors usually run as some sort of Windows service. This means that the applications they launch are being run in "the background" - in a different context than that of any currently logged in user. So, if you are launching an application that has any sort of GUI, this application will not be visible to a logged in user - unless that user is the same as the user running the Trigger Monitor. But just because you don't see the application, that does not mean that the application didn't launch. Check the Task List for your application, it's probably there waiting for someone to click 'okay'.

One other thing to keep in mind with triggered applications is that you almost always want to start them as new tasks, rather than having the trigger monitor task wait for each triggered application to finish before it goes on to the next one. This is accomplished by appending the '&' to your application description (like "/usr/bin/MyBinary&") on Unix platforms, and prepending the 'start' command on Windows ("start C:\Program Files\MyBinary.exe").
_________________
I am *not* the model of the modern major general.
Back to top
View user's profile Send private message
hornbeam123
PostPosted: Sat Oct 02, 2004 4:04 am    Post subject: triggered c++ program does not run when runmqtrm win service Reply with quote

Centurion

Joined: 01 Nov 2003
Posts: 101

Jeff,

Success. The notes on the subject are good.

Just one change required to get this working when runmqtrm running as a service, and that was to precede the program exe with a start command.

On PROCESS object Application Identifier set to "start getput.exe"

Some further observations : I found if you start a dos window, initiate runmqtrm itself in another (start runmqtrm ....) window and the appln process itself also invoked with the application identifier of the process object also using the preceding start command (as above) another window is opened for this appln, when it ends the window is closed. If the appln was not started this way and if it waited indefinitely it would wait the runmqtrm also I believe.

As my appln program issues a GET with wait I was able to see it running from task manager and disappearing when the wait expired and the program went to eoj.

Nice one.Thanks.
Back to top
View user's profile Send private message
jefflowrey
PostPosted: Thu Oct 07, 2004 4:53 am    Post subject: Reply with quote

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Actually, I addressed the "start" command.

jefflowrey wrote:
One other thing to keep in mind with triggered applications is that you almost always want to start them as new tasks, rather than having the trigger monitor task wait for each triggered application to finish before it goes on to the next one. This is accomplished by appending the '&' to your application description (like "/usr/bin/MyBinary&") on Unix platforms, and prepending the 'start' command on Windows ("start C:\Program Files\MyBinary.exe").

_________________
I am *not* the model of the modern major general.


Last edited by jefflowrey on Fri Oct 08, 2004 5:25 am; edited 1 time in total
Back to top
View user's profile Send private message
newwmq
PostPosted: Thu Oct 07, 2004 11:57 pm    Post subject: Reply with quote

Newbie

Joined: 07 Oct 2004
Posts: 8

If you want to run your triggered apps asynchronously, you should put the & in the EnvData field of the Process definition.
The reason is that the triggered app is started with some arguments:
ApplicId TMC2 UserData EnvData
Putting the & in the ApplcId will cut the app off from the TMC2 structure, so if any fields from the structure are needed, e.g. qmgr name, they are not available to the triggered app.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Messaging and Integration Technologies FAQ » Why doesn't my triggered application work?
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.