| Author |
Message
|
| naory |
 Posted: Thu Oct 06, 2005 5:36 pm Post subject: CODs end up on deadq on the remote qmanager |
 |
|
Novice
Joined: 05 Oct 2005
Posts: 17
|
Hi,
We are using the Java API on a linux machine to send messages to a remote qmanager with the following options:
| Code: |
message.report =
MQC.MQRO_NEW_MSG_ID
| MQC.MQRO_COPY_MSG_ID_TO_CORREL_ID
| MQC.MQRO_DEAD_LETTER_Q
| MQC.MQRO_COD_WITH_FULL_DATA; |
we are sending these messages to a remote qmanager running on windows.
The problem is that COD's end up on the remote qmanager's dead q with MQRC_NOT_AUTHORIZED error.
our counterparty specified that the messages arrive with no user and should arrive with 'cbxmqm'.
we verified that the unix user that starts the mq qmanagers is indeed 'cbxmqm'
this setup was working well but broke in the past when mq was restarted by a different user.
this time everything looks okay but the problem is still there.
i know we can specify a user from the java API using MQC.MQPMO_SET_IDENTITY_CONTEXT but not sure if this is the way to fix the problem as we allways relied on the unix user in the past.
will setting a userid override the OS value and resolve this issue?
any advise would be greatly appreciated.
naor |
|
| Back to top |
|
 |
| naory |
| Posted: Thu Oct 06, 2005 7:22 pm Post subject: |
|
|
Novice
Joined: 05 Oct 2005
Posts: 17
|
I have tried to set the userid option MQC.MQPMO_SET_IDENTITY_CONTEXT from the code and pass the required user but got the following exception:
| Code: |
| com.ibm.mq.MQException: Completion Code 2, Reason 2046 at com.ibm.mq.MQQueue.put(Lcom.ibm.mq.MQMessage;Lcom.ibm.mq.MQPutMessageOptions;)V(MQQueue.java:660) |
any idea? |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Oct 06, 2005 11:02 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Enable authority events on the remote qmgr, and inspect the event msgs to see what authority is missing, and on what object.
Correct the authority, and try again until it works..
I expect that the user putting the COD does not have authority to put to the remote xmtq.
I think it is irrelevant what user started the qmgr. The COD is written when the msg is read from the destination queue, and I think that the COD is put with the authority of the userID the getting app is run under.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Oct 07, 2005 1:28 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| and I think that the COD is put with the authority of the userID the getting app is run under. |
EDIT: see conversation below
_________________
-wayne
Last edited by wschutz on Fri Oct 07, 2005 2:12 am; edited 1 time in total |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 07, 2005 1:49 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| Nigelg wrote: |
I expect that the user putting the COD does not have authority to put to the remote xmtq.
I think it is irrelevant what user started the qmgr. The COD is written when the msg is read from the destination queue, and I think that the COD is put with the authority of the userID the getting app is run under. |
Nigelg are you sure? I wasn't sure myself, since all that the manuals say is
| Quote: |
A confirmation of delivery (COD) report message. This indicates that the message
has been retrieved by a receiving application. It is generated by the queue
manager. |
So I made the following experiment on my PC:
put COD msg with user A and got with user B - report msg had user A stamped on it.
put COD msg with user B and got with user A - report msg had user B stamped on it.
Apparently it uses the same userid of the user that put the msg, which is odd indeed; could anyone could concur/refute what I just said? (seems important enough to be bold)
ps - the PuttingApplicationName is "qmname" and PutApplType is "Queue Manager".
If I didn't botch up my experiment (which is possible  ), the the conclusion in this specific case is clear - the putting user does not have authority on the remote qm to create report msg. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Oct 07, 2005 2:08 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| report msg had user A stamped on it. |
By this, you mean A is in the report message's MQMD.Userid? Of course, thats really a "pass context" issue.
_________________
-wayne |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Oct 07, 2005 2:11 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
And just to make things clearer:
| Quote: |
| 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. |
--MQ Security manual
_________________
-wayne |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 07, 2005 6:59 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
That settles it then - naory, you have to give proper authorities to the userId who sent the message.
(Btw, I find this to be highly problematic (even slightly illogical), since it means you have to spread the same users and authorities throughout your network, which I personally would like to avoid.) |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Oct 07, 2005 7:12 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Well ... there's this:
| Quote: |
| Because of these situations, it might be necessary to substitute one user ID for another in the UserIdentifier field as a message enters a new security domain. This can be done by a message exit at the receiving end of the channel. Alternatively, you can ensure that the user ID in the UserIdentifier field of an incoming message is defined in the new security domain. |
(500 posts! hurray)
_________________
-wayne |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 07, 2005 7:22 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
All hail the new grand-master! (beat me to it!  ) |
|
| Back to top |
|
|
| naory |
| Posted: Sat Oct 08, 2005 9:02 am Post subject: |
|
|
Novice
Joined: 05 Oct 2005
Posts: 17
|
thanks for the tips hopsala.
| Quote: |
| you have to give proper authorities to the userId who sent the message. |
can you please explain how should i do that?
thanks.
naor |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 08, 2005 9:40 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Use the commands "setmqaut" and "dspmqaut" on the remote computer, and give authorities to the user that appears in MQMD.UserId.
Employ the manuals and the Search button to find out more about these commands, they are well documented both here and there. |
|
| Back to top |
|
|
| naory |
| Posted: Sat Oct 08, 2005 10:40 am Post subject: |
|
|
Novice
Joined: 05 Oct 2005
Posts: 17
|
unfortunately, the remote qmanager is at a different organization (our client) and we cannot run commands there. (not much help from their side either)
this setup was working in the past and recently stopped working.
is there a way to check the user on my outgoing messages from the MQ console?
many thanks,
naor |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Oct 08, 2005 11:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Put your outgoing messages to a different queue, and use any of a thousand different tools to look at them.
If it's on the remote end, then it's the remote end's problem.
If it was working recently, and now it's not, somebody made a change that broke it. First ensure that you *didn't* make *any* changes, and then ask your partner, gracefully and gently, what changes they did make...
If you *did* make *any* changes, confirm that you didn't break this.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
