| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| question about report option MQ6 |
« View previous topic :: View next topic » |
| Author |
Message
|
| DTran |
 Posted: Fri Feb 15, 2008 6:50 am Post subject: question about report option MQ6 |
 |
|
Acolyte
Joined: 11 May 2006
Posts: 62
Location: Amsterdam
|
Hi all,
A COA is generated when the message arrive at the end LQ. But is it possible to configure MQ to generate a report when a message is stuck on the XmitQ?
I have read and see that the COD message is putted with the userID of the sender, this cause the COD message fails with 2035 reason code. Is there any option to change the user of the COD message to e.g. mqm?
thnx in advance
Tran
_________________
There are 10 types of people in this world - those who understand binary and those who don't |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Feb 15, 2008 6:58 am Post subject: Re: question about report option MQ6 |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| DTran wrote: |
| A COA is generated when the message arrive at the end LQ. But is it possible to configure MQ to generate a report when a message is stuck on the XmitQ? |
NAFAIK and it's probably undesirable. If messages are backing up on an xmitq then the channel's in trouble & you should be alerting your network people not the guy sending the message.
In an ideal world, the guy sending the message shouldn't worry about where the message is on the grounds WMQ offers assured delivery, hence a receipt is redundant because the message will arrive. This has been the subject of discussion before, and I think the conclusion was that the world is sometimes less than ideal.
You could use the lack of an COA as notification the message is stuck, if you're working to an SLA.
| DTran wrote: |
| I have read and see that the COD message is putted with the userID of the sender, this cause the COD message fails with 2035 reason code. Is there any option to change the user of the COD message to e.g. mqm? |
Again NAFAIK; the sender id should be authorised to use the return route.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| DTran |
| Posted: Fri Feb 15, 2008 9:43 am Post subject: |
|
|
Acolyte
Joined: 11 May 2006
Posts: 62
Location: Amsterdam
|
Thanx Vitor,
Yes in an ideal world then we can trust the network people, but we have lots of problems with those people, purely because they don't do their work. That is why the bosses  wants to have something to check where the message is stuck, because those message have to be deliver on time.
Second question: we can't add every sender ID's to a group and authorised, because it is impossible situation, we have hundreds of those ID's across the world. If I route those messages thru the Broker, user will change to mqm, right?  then i can bypass the COD problem...Am i correct?
_________________
There are 10 types of people in this world - those who understand binary and those who don't |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 15, 2008 10:03 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| DTran wrote: |
Thanx Vitor,
Yes in an ideal world then we can trust the network people, but we have lots of problems with those people, purely because they don't do their work. That is why the bosses wants to have something to check where the message is stuck, because those message have to be deliver on time.
|
Tell the bosses they need to buy an MQ monitoring tool. We use MQSoftware's QPASA. There are lots of others.
| DTran wrote: |
| Second question: we can't add every sender ID's to a group and authorised, because it is impossible situation, we have hundreds of those ID's across the world. If I route those messages thru the Broker, user will change to mqm, right? then i can bypass the COD problem...Am i correct? |
What do you do when you don't get a COD? You can't prove anything becasue there are lots of reasons a COD hasn't arrived. Maybe the channels the COD needs to take back are down. Maybe there is a security error. Or maybe the original mesage hasn't been delivered. You should reevaluate your need for CODs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 15, 2008 10:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| DTran wrote: |
Thanx Vitor,
Yes in an ideal world then we can trust the network people, but we have lots of problems with those people, purely because they don't do their work. That is why the bosses wants to have something to check where the message is stuck, because those message have to be deliver on time.
|
Tell the bosses they need to buy an MQ monitoring tool. We use MQSoftware's QPASA. There are lots of others.
| DTran wrote: |
| Second question: we can't add every sender ID's to a group and authorised, because it is impossible situation, we have hundreds of those ID's across the world. If I route those messages thru the Broker, user will change to mqm, right? then i can bypass the COD problem...Am i correct? |
What do you do when you don't get a COD? You can't prove anything becasue there are lots of reasons a COD hasn't arrived. Maybe the channels the COD needs to take back are down. Maybe there is a security error. Or maybe the original mesage hasn't been delivered. You should reevaluate your need for CODs. |
Especially the part about non-delivered CODs. There have been a few discussions on this (the Search Button Is Your Friend) and it's easy to get into a loop of acknowledging-the-acknowlegment.
It's far easier to prove WMQ is working, and on that basis assume message delivery. Because that's why you pay the license.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 15, 2008 11:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| Tell the bosses they need to buy an MQ monitoring tool. We use MQSoftware's QPASA. There are lots of others. |
We use it too. You will need to set up some alerts and triggers and then you can get notified if something looks like it's stuck...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| DTran |
| Posted: Mon Feb 18, 2008 3:02 am Post subject: |
|
|
Acolyte
Joined: 11 May 2006
Posts: 62
Location: Amsterdam
|
Thanx you all,
My COD failed with 2035 reason, because the sender ID is not exist on the receiver server. To resolved the ID's problem I will route the message thru the broker, so the ID should change to mqm.
We do have monitoring tools, but the problem lies in the people itself. In some country we can't oblige people, and the last few months we have serveral major incidents. That is why I wonder if COA can solve the problem of stucking messages.
Again, thanx you all, I will test with the COD via the broker... if this works I can recommend to our boss.... 
Grz,
Tran
_________________
There are 10 types of people in this world - those who understand binary and those who don't |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Feb 18, 2008 9:22 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi DTran,
Turn your thinking sideways (90% degrees). Send the "reply" message back to the requestor with the same UserId that they sent original message with. That way the COD will return to your system. 
i.e. Most "server" applications will save the incoming message's MsgId and then use it in the reply message's CorrelId. Therefore, just save the incoming message's UserId and then set it on the reply message.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Feb 18, 2008 10:28 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
From my point of view, the usage COA and COD should always be matched with the receiving partner (the one that receives the messages and sends COA and COD). Its not just only the security that has to match, also replytoqmgr must be known for the CO* to find its way back, and this is not always the case, because not every connection design uses real queuemanager names for the XMITQ.......
in addition, if you jsut rely on what you found out (e.g. sending username) - this may change at any time, especially when your partner does not know that you are using this for COA and COD.
i also saw other stuff that may prevent CO* to be routed back, e.g. some kind of channel routeing exits, or similiar stuff.
i'd prefer my customers to tell me BEFORE they switch on COA and COD and let my operators call me at night because of all the alerts created.....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 19, 2008 3:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| DTran wrote: |
| We do have monitoring tools, but the problem lies in the people itself. In some country we can't oblige people, and the last few months we have several major incidents. That is why I wonder if COA can solve the problem of stuck messages. |
Do not worry about the people. With most monitoring tools you set up the monitoring centrally and it will alert you to events reported from across the world. You just need to set up the alerts...
A good monitoring tool should also report on itself...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 19, 2008 7:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Confusing terms (or terms lacking sufficient precision) need clarification:
In a request-reply model, the requesting application creates a request message; the replying application gets the request message from the destination local queue and creates a reply message.
The requesting application may ask that confirmation report messages (COA, COD) be returned to the requesting application. (The requesting application may ask for exception report messages, as well.)
COA and COD messages are not created by application programs. (see post below)
The requesting application must be coded to anticipate both the reply message from the replying application AND the confirmation and exception messages.
--------------------------------------------------------------
I've cut/pasted this is from another post. In other words, I didn't write it.
the difference between the two reports is a subtle one.
COA's are generated by the queue manager itself, (usually) using the mqm userId to put them to the replyToQueue.
COD's, however, are generated by the agent process that is started on behalf of each application that issues an MQCONN call. As soon as you MQGET the application message (and commit, if syncpointed), ie. you perform a destructive get, the agent process will produce the delivery report message, at this time using the userId that the application runs with. Now, this userId needs to have permission to open and put to the replyToQueue (and the transmission queue, if it leaves your QMgr).
---------------------------------------------------------
Bless Mr. Google.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| DTran |
| Posted: Tue Feb 19, 2008 8:21 am Post subject: |
|
|
Acolyte
Joined: 11 May 2006
Posts: 62
Location: Amsterdam
|
Hi Bruce,
about the COA i know that the qmgr itself generates the report, but the COD. I have read the message with the user mqm, but the COD fails with my user as put userID... That's weird thing, because in IBM redbooks the COD report should will be generate by the get application, but it is not
That's why i try to route the sender message thru the broker and see if this do the trick.
Thanx for all your help
Tran
_________________
There are 10 types of people in this world - those who understand binary and those who don't |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 19, 2008 8:35 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Let's assume that the post I quoted is correct (it seems to make sense...):
"...because in IBM redbooks the COD report should will be generate by the get application..."
Which redbook? Publication number and name please.
According to the MQ V6 Application Programming Reference, in the MQMD chapter, MQRO_COA and MQRO_COD:
CODs and COAs are not generated by application programmer code, but by an event, namely: the COD report will be generated by the queue manager agent because the application program did an MQGET
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Feb 20, 2008 1:56 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| CODs and COAs are not generated by application programmer code, but by an event, namely: the COD report will be generated by the queue manager agent because the application program did an MQGET |
what may support the "rumor" that the getting application creates the COD is, that the COD is created with the userid of the getting application (but still its MQ that creates it as written above), while the COA is created with the userid of the putting MCA.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Feb 20, 2008 4:51 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
i have to correct myself...
for COD the the userid within the message (the mqmd) is used to create to COD report message, NOT the userid of the getting application.
sorry for that, dont know why i wrote that wrong stuff before... 
_________________
Regards, Butcher |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
