Author |
Message
|
vininx |
Posted: Tue Oct 13, 2009 1:49 am Post subject: Confirmation on Delivery (COD) not received from Windows app |
|
|
Acolyte
Joined: 13 Oct 2009 Posts: 69
|
Hai All,
I am using Websphere MQ to communicate between my Solaris and Windows application. I am sending message using MQ Java API to windows app by setting the COD parameter, but I am not getting the COD from the windows app. I saw the COD messages going to Dead letter queue of the Windows queue manager. DL header reports the reason as MQRC_NOT_AUTHORIZED. How the channel should be configured to pass the COD message. Please suggest me on how to get rid of this problem.
Thanks & Regards,
Vinoth.T |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Oct 13, 2009 3:03 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You need authorization on the return route for the user that sent the message. Don't know if you can bypass that by setting an mcauser on the sender channel...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Oct 13, 2009 3:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
fjb_saper wrote: |
You need authorization on the return route for the user that sent the message. Don't know if you can bypass that by setting an mcauser on the sender channel...  |
Given that the COD is sent as the user running the application reading the message... no setting on any channels comes into play....
 |
|
Back to top |
|
 |
vininx |
Posted: Tue Oct 13, 2009 4:27 am Post subject: Confirmation on Delivery (COD) not received from Windows app |
|
|
Acolyte
Joined: 13 Oct 2009 Posts: 69
|
Hai,
Actually I am communicating from Solaris to AIX, VMS and Windows. Please see the following dspmqaut on the channels,
C:\Documents and Settings\ABMWVT1>dspmqaut -m WQTA -n WQTA.TO.SQT3.TCP -t channel -g dbmw
Entity dbmw has the following authorizations for object WQTA.TO.SQT3.TCP:
# dspmqaut -m AQT1 -n AQT1.TO.SQT3.TCP -t channel -g dbmw
Entity dbmw has the following authorizations for object AQT1.TO.SQT3.TCP:
$ dspmqaut -m SQT3 -n BMWA.TO.SQT3.TCP -t channel -g dbmw
Entity dbmw has the following authorizations for object BMWA.TO.SQT3.TCP:
where
AQT1 - AIX QMgr
BMWA - VMS QMgr
SQT3 - Solaris QMgr
WQTA - Windows QMgr
I am getting the COD from AIX app and VMS app but not from Windows app, even though the group dbmw has same auths(i,e I could not find any) on the three channels. Please advise.
Jedi,
You mean the app which is putting the COD message in windows should run under MQM id ?
Thanks & Regards,
Vinoth.T |
|
Back to top |
|
 |
Mr Butcher |
Posted: Tue Oct 13, 2009 5:34 am Post subject: |
|
|
 Padawan
Joined: 23 May 2005 Posts: 1716
|
Quote: |
Jedi,
You mean the app which is putting the COD message in windows should run under MQM id ? |
no, he means that the COD written on windows is done with the userid of the application, that is getting the message. so you msut authorize that id on windows to be able to put to replytoqmgr.
this is not related to channel security! _________________ Regards, Butcher |
|
Back to top |
|
 |
rtsujimoto |
Posted: Tue Oct 13, 2009 6:54 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004 Posts: 119 Location: Lake Success, NY
|
IIRC, the sender's userid needs update authority to the XMITQ that points back to the sender. The MCA uses the sender's userid to put the COD directly on the XMITQ. |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Oct 13, 2009 6:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Richard - is that the COA or the COD?
I didn't think the COD could be created until the message was GOT.
I'm sure I'm remembering poorly, though. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Oct 13, 2009 8:24 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
The RCVR MCA produces the COA, and does so under the eauthority of the RCVR MCA, which is usually mqm and so it can put to the XMITQ going back to the SNDR.
The QM produces the COD and does so under the authority of the UserID in the message that produced the COD when it was consumed. So that ID needs the proper MQ authority to get back.
You now see why its kinda pointless to use COA and COD across QMs - just because you didn't get the report message doesn't mean the original message wasn't delivered! _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Oct 13, 2009 9:16 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
PeterPotkay wrote: |
The QM produces the COD and does so under the authority of the UserID in the message that produced the COD when it was consumed. So that ID needs the proper MQ authority to get back. |
And this is why I was thinking of an mcauser on the sender channel.
So all messages received by the processing qmgr would have the same userid... and thus simplify the authorizations for COD...
But it was just an idea and has not been tested...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Oct 13, 2009 11:26 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Setting a value in the SNDR channel's MCAUSER will not affect the User ID in the messages going over that channel.
Setting an ID into the MCAUSER of a SVRCONN channel will though. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
rtsujimoto |
Posted: Wed Oct 14, 2009 7:59 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004 Posts: 119 Location: Lake Success, NY
|
I'm not sure COAs and CODs deserver a blanket condemnation. I think they can be useful, depending on the application design. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Oct 14, 2009 8:14 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
If you get the COA/COD, you know the message was delivered.
If you don't get the COA/COD, you can't assume anything.
As long as the user realizes that.... _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Vitor |
Posted: Wed Oct 14, 2009 8:37 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
rtsujimoto wrote: |
I'm not sure COAs and CODs deserver a blanket condemnation. I think they can be useful, depending on the application design. |
Give 3 design examples where they're not more trouble than they're worth.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
rtsujimoto |
Posted: Wed Oct 14, 2009 9:30 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004 Posts: 119 Location: Lake Success, NY
|
You only need 1 example to negate the negative. You can use a COA and/or COD to determine if a checkpointed set of messages made it across (a la FTP). There are a million approaches to designing an MQ-like FTP application and the above example is but one. It may not be the best, but it uses COA/COD in a useful manner. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Oct 14, 2009 9:43 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
rtsujimoto wrote: |
You only need 1 example to negate the negative. You can use a COA and/or COD to determine if a checkpointed set of messages made it across (a la FTP). |
How, in this instance, would you deal with the "message received but confirmation not" scenario? Does it still not require code at the application level to detect missing / duplicated packets and respond accordingly?
Also, why not use one of the existying FTP-over-WMQ packages, which has all this built in?
IMHO, the COD/COA facilities are like the ability to manually set message id. The software has these facilities to cater for the emergency case where you need it, but you'd never actually use. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|