| Author |
Message
|
| ivanachukapawn |
 Posted: Thu Dec 03, 2009 11:30 am Post subject: triggering in a client environment |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| Research on MQseries.net revealed that this subject was covered in Chapter 12 of the Client Manual, but that appears to no longer be the case (also that manuals are no longer supported in the latest release). Anybody know where a detailed writeup of triggering in a client environment might be found? I'm referring to runmqtmc configuration and operations, and any available help in debugging triggered application failures in a client environment. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Dec 03, 2009 11:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 03, 2009 11:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Dec 03, 2009 11:51 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| In order for a client trigger monitor to work (i.e. monitor an initQ in a remote QM environment) I imagine it should be configured with specification for SVRCONN, host(port), QMname, QName, etc. Yet I see only QMname and QName in the parameters. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 03, 2009 11:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Though in truth there's no difference between server side and client side triggering, apart from the configuration you need for any client application that a server side one doesn't.
Also the supplied trigger monitor is just a trigger monitor. If it doesn't do what you want it's perfectly possible to write your own; it's just a long running app that processes trigger messages (which are documented).
IHMO it's a perfectly good wheel and I've never seen the need to reinvent it (tweeked it a couple of times for a couple of clients back in the day though).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 03, 2009 12:12 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
For Windows (based on your other post), use the MA7K support pack for MQ Client Trigger Monitoring. It sets it up as a real Windows Service and allows you to stop and start it. Lots of options, including tons of logging if you want it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Dec 03, 2009 12:17 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
that windows XP Pro test was just a sideline to verify that 2 TMs could monitor the same initQ.
the production environment has a Windows 2000 environment hosting the QM trigger queue and initQ but a client TM running on Unix. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 03, 2009 12:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ivanachukapawn wrote: |
| the production environment has a Windows 2000 environment hosting the QM trigger queue and initQ but a client TM running on Unix. |
Same principle.
Also (touching on your other post) the links that bruce2359 and myself have posted are what I meant by "post a link".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 03, 2009 1:16 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The things you need to do to configure the CLNTCONN definition that runmqtmc will use are the same regardless of the platform that runmqtmc will execute on, and are the same as any other client application.
In terms of troubleshooting, the best thing you can do is ensure that you pipe or redirect the stdout of runmqtmc into a file somewhere so you can read it if you are doing things to execute runmqtmc in the background as a daemon process. |
|
| Back to top |
|
|
|
|
