| Author |
Message
|
| ms_mq |
 Posted: Thu Nov 25, 2010 1:46 am Post subject: Issue with COD |
 |
|
Acolyte
Joined: 23 Feb 2007
Posts: 69
|
Hi All,
We are facing some issues with COD (Confirmation of Delivery)generation. I know, COD is generally not recommended by some of the Experts in this forum. But, the sending application wants to have it 
The sending application puts the message to the remote queue which reaches the Local MQ queue at our end.Once it reaches our queue , they are expecting a COD message on a Local queue at their end (SG.GLOBAL.REPLY).
Now the problem is, the message reaches our queue and it gets processed, but they are not receiving the COD. We are getting the below error in my Queue manager Error logs -
________________________________________________________
25/11/2010 14:46:49 - Process(4023.2184) User(mquser) Program(amqzlaa0_nd)
AMQ7310: Report message could not be put on a reply-to queue.
EXPLANATION:
The attempt to put a report message on queue SG.GLOBAL.REPLY on
queue manager SGQMPRD1 failed with reason code 2035. The message will be put
on the dead-letter queue.
ACTION:
Ensure that the reply-to queue is available and operational.
________________________________________________________
Their receiver channel MCAUSER is set to sgprdusr.The user identifier in their sending application code is also sgprdusr. Our sender channel MCAUSER is blank. mquser is our mq admin id .
The id sgprdusr on their server has PUT and setall authorisation on SG.GLOBAL.REPLY.
Please advise why we are getting the 2035 error and what needs to be done to resolve this problem. many thanks in advance.
_________________
Regards,
MS |
|
| Back to top |
|
 |
| ms_mq |
| Posted: Thu Nov 25, 2010 3:22 am Post subject: |
|
|
Acolyte
Joined: 23 Feb 2007
Posts: 69
|
Please let me know what are all the things that needs to be taken care to make COD work ? Thanks.
_________________
Regards,
MS |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Nov 25, 2010 4:33 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
IMHO the COA is put with the userid of the MCA, and the COD is put with the userid of the application. this seems to be "mquser".
first you should check if your MQ object definitions cover the way back (mqopen on replytoq and replytoqmgr). most likely the qmgr is defined by xmitq name or by qmgr alias, but there are other possibilities too.
then define proper security for that "mquser" to allow it to put the COD depending on how you defined the way back.
IMHO, the security needed is for the remote qmgr name, but i did not verify that ....
_________________
Regards, Butcher |
|
| Back to top |
|
|
| ms_mq |
| Posted: Thu Nov 25, 2010 5:15 am Post subject: |
|
|
Acolyte
Joined: 23 Feb 2007
Posts: 69
|
Hi Butcher,
Thanks for your reply.
Do you mean COD is put with userid of the sending application? Then , in that case, sgprdusr is the application id and that is the useridentifier that has beem set in the application code. They PUT with sgprdusr id to our Queue and they expect COD back on their Queue SG.GLOBAL.REPLY.
BY any chance, should our (Receving side) mq id 'mquser' visible on their server or vice versa? It is a authorization problem, and i am still not clear why we are getting this error.
_________________
Regards,
MS |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 25, 2010 6:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You are getting this error on the qmgr sending the COD because the application user on the message is not allowed to put to sdrqmgr on the qmgr sending the COD.
Don't know if setting an mcauser on the receiving channel on the processing MQ server would help...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Nov 25, 2010 7:03 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| Do you mean COD is put with userid of the sending application? |
no, the COD is put with the userid of the receiving (consuming) application, because the COD is created at the time of the MQGET.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 25, 2010 7:04 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
COA message is created by the receiving-end message channel agent. COA message indicates that the app message has arrived on queue.
COD message is created by the qmgr when the message is delivered to a consuming application.
_________________
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 |
|
|
| exerk |
| Posted: Thu Nov 25, 2010 9:34 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| ...COD message is created by the qmgr when the message is delivered to a consuming application... |
Using the sgprdusr userid in the original MQMD - in other words, unless you have the 'same' user defined on the system creating the COD, and with the appropriate authorities to put to the queue, you will hit this error. From the manual: "...In certain circumstances, when a report message is generated, it is put using the authority of the user ID in the UserIdentifier field of the message causing the report. In particular, confirm-on-delivery (COD) reports and expiration reports are always put with this authority..."
If you are on a UNIX platform, have a look at THIS, it's useful as once set you will be given not only the entity making the call, but what call it issued, or if on Windows try THIS one. A little more awkward than the above, but still as useful.
As to the utility of COA/COD messages, consider the fact that they may not make it back to the origin of the message causing them to be created, and what does your application do then?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 25, 2010 10:06 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Now the problem is, the message reaches our queue and it gets processed, but they are not receiving the COD |
COD means only that the message was delivered to (consumed by) some application. COD does not guarantee that the app that consumed the message was the app that was supposed to process the message.
The relative value of COA and COD have been discussed at great length here. Please search, and read. The question that the developers need to ponder is: "what will the requesting app know with certainty if it does or does not receive COA and/or COD?"
Search here also for well-written and well-behaved applications. All part of the same COA/COD discussion.
_________________
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 |
|
|
| ms_mq |
| Posted: Fri Nov 26, 2010 5:12 am Post subject: |
|
|
Acolyte
Joined: 23 Feb 2007
Posts: 69
|
Hi All,
Thanks a lot for the clarification . Thanks once again.
_________________
Regards,
MS |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Nov 28, 2010 3:04 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
COD means only that the message was delivered to (consumed by) some application. COD does not guarantee that the app that consumed the message was the app that was supposed to process the message. |
or that the app is going to process the message correctly...
| Quote: |
| The relative value of COA and COD have been discussed at great length here. Please search, and read. The question that the developers need to ponder is: "what will the requesting app know with certainty if it does or does not receive COA and/or COD?" |
A great way of putting it. I'd add "within a certain time frame".
_________________
Glenn |
|
| Back to top |
|
|
|
|
