| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Dynamic loopback |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Thu Aug 23, 2007 5:09 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Guy's
Don't know why you're all so fixed on writing to the xmitq.
If the message's destination as specified in the MQMD contains a remote qmgr the qmgr, you're connecting to, will resolve it as to the default route.
(Note this may well end with the put having a 2087...  )
Now this does not absolve you from creating all those default routes (see intercommunications manual) for more precisions. An MQ Cluster sure will make things easier...
And even your little app does not cover, unless you do use remote queues, the case where you use multiple channels to service the same destination...
Get some monitoring software and get notified when a channel's in trouble...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| LuisFer |
| Posted: Thu Aug 23, 2007 10:07 pm Post subject: |
|
|
Partisan
Joined: 17 Aug 2002
Posts: 302
|
I don't know if this works:
You need 1 local Queue on the QMgrHUB
Build a message with REPORT_ON_ARRIVAL , OBJEC_QMGR = QMgrDEST , OBJECT_QNAME an inexistent Q of the QMgrDEST and Expiry.
The message will go to the DEAD and the QMgr sends the Report to QMgrHUB.
I have a program with this mechanics (but with local queues on Remote QMgrs) |
|
| Back to top |
|
|
| amisinai |
| Posted: Sat Aug 25, 2007 3:07 am Post subject: |
|
|
Novice
Joined: 17 Aug 2007
Posts: 10
Location: Israel
|
Hi,
We have Tivoli for monitoring. Tivoli monitors everything in our facility, mq is just a small part. The problem with Tivoli (maybe other softwares are better), is that when there's a problem, is sends a lot of messages, and the messages are turned off only after the problem stopped + a very annoying delay. We can't tell Tivoli to check everything now! It has cycles between his checks.
This problem's consequence is, if a temporary problem occurs the operator can call us in the middle of the night, even if the problem was momentary…
And the Tivoli in our facility is a responsibility of another team…
We want to create a simple generic on-demand application that checks all the channels between our queue managers (without static definitions, if it's possible).
Leonid,
You have a great idea, I'll try that, it's sounds like it could work…
Luisfer,
I like your method, the only problem is the message accumulation in the dead letter queue (even with the expiry). In our facility they have to stay empty (or the operator will call)…
Supreeth,
Our 50 mq servers topology is divided into 3 almost separated environments (dev, test, prod). Each environment has Zos, windows, Aix, AS400, and some message brokers.
They are not chained in a circular fashion, they are connected according to workload, applicational, security and operating systems considurations…
For some of my queue managers I can't connect as a client (I have to hope throw 1 or 2 other managers)
Thanks for all the replies! I'm going to make some tests… 
Avichai |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Aug 25, 2007 5:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm quite sure you can control, with great detail, what messages Tivoli produces, and how it alerts on them.
I'm pretty darn sure that you can tell Tivoli to wait a period of time after noticing something, and then check it again, and THEN decide to send an alert.
I'm positive you can tell Tivoli to only alert you when channels go to RETRYING state or STOPPED state, rather than INACTIVE state.
And, for the third time...
MQ version 6 COMES WITH a program that will let you TRACE your MQ network, by sending special messages.
Please read the "Monitoring WebSphere MQ" for more information on trace-route messaging.
To Sum up:
1) You don't need to write this program, you should monitor your channels instead
2) You don't need to write this program, you can fix Tivoli so it works better
3) You don't need to write this program, because WebSphere MQ v6 comes with a program already
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| amisinai |
| Posted: Mon Aug 27, 2007 11:03 am Post subject: |
|
|
Novice
Joined: 17 Aug 2007
Posts: 10
Location: Israel
|
Hi Jefflowrey,
You are absolutely right. I can avoid writing this program…
I just wanted to be sure that it’s could be done (you must admit that it’s a nice theoretical question).
To make a long story short, I’ve wrote the program and it works! I’ve used Leonid’s suggestion to add a transmission header… (Thanks)
I’ve read about the trace-route messaging, it looks promising, except two issues, we still have mq 5.3, we have to enable the trace route feature on all the queue managers. And I’m not sure this feature is mature and reliable like the standard transmission protocol.
Thanks for all the input!
Avichai |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 27, 2007 11:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You should never ever ever ever ever ever ever build your own transmission header and write directly to the xmitq.
Ever ever ever.
Even if you know what you're doing. It's always either very dangerous or a waste of time.
If you have an XMITQ anyway, you can just use the name of the XMITQ as the name of the remote queue manager when you execute your PUT.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 27, 2007 11:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, version 5.3 goes out of support in a couple of weeks.
You should be spending your time migrating to version 6, rather than writing overly-clever programs that do things the wrong way.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
