| Author |
Message
|
| romudd |
 Posted: Mon Apr 12, 2004 11:07 am Post subject: send COD to 3rd parties |
 |
|
Apprentice
Joined: 12 Aug 2003
Posts: 31
Location: Sao Paulo - Brazil
|
Hi,
We have a messaging environment that includes other parties' MQservers. Whenever I receive a message from them, the following occurs: my MQSeries returns the COA without any problem, but when trying to put the COD I get the error 2035.
It seems that the MQ is trying to put the report using the remote user id (the user running the remote application which has put the original message), that of course has no authority on my system.
Is there a way to permit my MQ to return the CODs, without need to make specific security settings for each remote system that communicates with me?
I've heard about channel exits that change the user id of incoming messages. Someone has this exit program?
Thanks in advance,
Rodrigo. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Apr 12, 2004 2:02 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
This is normal, because the COD is put with the authority of the original message's UserId, where as the COA is put with the authority of the remote RCVR MCA, typically running under the ID of mqm.
Your choices are:
1. setmqaut all possible IDs present in your messages that ask for CODs
2. stop using CODs
3. use a message exit like you said to change these IDs
4. you could also set the MCAUSER of your RCVR channel to an ID that does have the proper authority, although that would mean all messages coming across this channel would be put with this authority (but the ID in the message would remain unaltered).
#4 is the easiest way to still allow CODs from a wide range of systems and IDs, but make sure you understand the security implications, which may or may not be an issue for you in this case.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| EddieA |
| Posted: Mon Apr 12, 2004 2:24 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Peter,
How can #4 ever work:
| Quote: |
| but the ID in the message would remain unaltered |
In which case the COD will still fail, as it does today.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 12, 2004 4:33 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
QM1 sends a message to QM2, with a COA/COD. QM2 sends back the COA and the COD.
I was thinking the original question was asked because there were 2035 at QM1. It just hit me that he is asking about the 2035s that QM2 is throwing on the COD. Yup, there is no way to override that ID short of an Exit that opens up the MQMD and changes it. Or, you gotta define all those IDs on QM1. (The COA works on the QM2 side because the COA is generated with the ID of the running RCVR channel, and not the MQMD_UserID which is what the COD is generated with).
After typing ALL of the below  , it hit me as to the real question (which I just paraphrased above) being asked  . Rather then waste all that typing, I left it below. It confirms that the MQMD_UserID cannot be changed short of an exit.
EDDIE owns QM1
PETER owns QM2
The ID "EDDIE" has no authority on QM2.
The ID "PETER" has full authority on QM2.
RCVR channel QM1.QM2 is present on QM2.
When messages leave QM1, they have a UserID of EDDIE, because in this case the putting app was running under that ID. These messages are destined for QUEUEA on QM2
When the message is grabbed by the RCVR MCA on QM2, it is put to the local queue with the following authorities:
Case1
RCVR channel MCAUSER=blank
PutAuthority=CONTEXT
The messages all go to the DLQ with 2035, and carry the EDDIE ID, because the RCVR MCA tried to put as EDDIE to QUEUEA, but EDDIE has no rights to any queues on QM2. Presumably, even though the channel is running as CONTEXT, the MCA uses its own ID (mqm) to put to the DLQ.
Case2
RCVR channel MCAUSER=PETER
PutAuthority=CONTEXT
The messages all go to the DLQ with 2035, and carry the EDDIE ID, because the RCVR MCA tried to put as EDDIE to QUEUEA, but EDDIE has no rights to any queues on QM2. Presumably, even though the channel is running as CONTEXT, the MCA uses its own ID (PETER this time to put to the DLQ.
Case3
RCVR channel MCAUSER=PETER
PutAuthority=Default
The messages all make it to the queue, and carry the EDDIE ID. The channel is running as PETER, which has sufficient rights to put to QUEUEA.
Case4
RCVR channel MCAUSER=blank
PutAuthority=Default
The messages all make it to the queue, and carry the EDDIE ID. The channel is running as mqm, which has sufficient rights to put to QUEUEA.
Case5
RCVR channel MCAUSER=EDDIE
PutAuthority=Default or CONTEXT
The messages back up on QM1, and the channel is retrying. The channel running as EDDIE can do nothing on QM2, not even connect and dump to the DLQ.
So it seems to me as long as you set your RCVR up as Case 3 or 4, messages will go to their destination queues regardless of their UserID in the MQMD, and they will maintain their UserID in the MQMD.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| romudd |
| Posted: Tue Apr 13, 2004 3:23 am Post subject: |
|
|
Apprentice
Joined: 12 Aug 2003
Posts: 31
Location: Sao Paulo - Brazil
|
thanks for now, it begins to become clearer.... 
Well, my configuration is like the Case 4
PUTAUT(DEF)
MCAUSER( )
As you said, the incoming messages go to the destination queues. It's ok about it.
However, when the mq tries to send the COD it still fails (2035).
I've just had an "idea" about it (just a guess, please correct me if necessary):
The incoming message is put into the local queue by the RCVRchannel's MCA (it also returns the COA). It stays in the queue, carrying the user id EDDIE (according to the example).
Then, the application comes to get the message. At this moment, the mq tries to send the COD, but maybe the RCVR MCA is not the responsible for that (once it has already done his job). If it's done by another process, then the MCA authority settings will not be used. This process would rather read the user id in the message.
If it's true, I really must change the user id of the message, or find out which process puts the COD and how to have it to use the authority of a mqm user. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Apr 13, 2004 3:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You got it right Rodrigo. In a class, it was explained to me that the process that puts the COD is the Queue Manager, and it uses the UserID of the Message that caused the COD.
I think if you are going to use CODs, you are stuck having to define all the IDs on the QM generating the CODs, or changing the IDs in the messages on their way in.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| josd |
| Posted: Wed Mar 19, 2008 2:40 am Post subject: |
|
|
Newbie
Joined: 28 Mar 2006
Posts: 5
|
Hi,
I think I have about the same problem. I have case 4.
Our situation is as follows. We just migrated one of our customers from MQ 5.2 upd06 to MQ 6.0.2.1 and Solaris 8 to Solaris 10.
Since this update we have the 2035 problem for sending COD messages to the reply-to queue at the other side. Channel and queue definitions are the same. For us it is not an option to change settings at the other party, since we don't have access. So mentioned options are not really applicable for our situation.
Our application has full access (put, passid, inq) on the XMIT queue at our side.
We have a workaround. We use a script to reprocess the messages on the dlq using runmqdlq with reasoncode 2035. This is not really a desireable solution, so I wonder what can be done? Or is there a difference between MQ5.2 and MQ6.0 causing this problem.
Thanks in advance for any suggestions or thoughts. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Mar 19, 2008 6:39 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If you want to send CODs back, you need to authorize all the IDs that could potentially be in the MQMDs of the request messages sitting in your queue on your side.
Or install a Message Exit on your RCVR channel that opens up each message as it arrives and changes the MQMD's User ID to an ID that does have access to the XMITQ going back to you partner.
Ot tell the sending side to only send messages with a particular ID in the header.
Or stop using CODs.
I don't understand why just upgrading MQ on your side caused the CODs to break. Either you had granted these IDs the access to the XMITQ going back or not. Maybe the partner at the sametime started sending new IDs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| josd |
| Posted: Thu Mar 20, 2008 4:21 am Post subject: |
|
|
Newbie
Joined: 28 Mar 2006
Posts: 5
|
Hi Peter,
thanks for your response. The strange thing is however, there were no message exits or extra id's authorized on the old system. That's why I was thinking about an upgrade issue I was not aware of.
There are more queuemanagers on this network. Some of them we control. These parties (MQ 5.2 and 5.3) don't have problems with auth settings, so also your last suggestion is not the case.
Just to make sure I'm not entirely mistaken with the situation. This is our errorreport:
| Code: |
03/20/08 13:12:47 - Process(20347.483) User(our_user) 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 THEIR.LOGQ on queue manager THEIR.QM
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. |
User our_user is in the mqm group and has full authorization on the transmitqueue on our side.
Anyway I will dig into the exit message and do some testing with it. Thanks again. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Mar 20, 2008 4:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Be aware that changing the ID in their request message means you will probably send back the reply message with your new ID. Maybe (probably!) that will cause problems on their end.
Before you go writing exits I would try and find out what changed that caused it to stop working. I highly doubt it was the upgrade alone that did it.
Turn on Authority Events at the QM level and look at the event messages for more clues. Maybe they started using a new ID (or IDs). Maybe it will be simpler to just grant setmqaut on your side for the one or few new IDs they are using.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| josd |
| Posted: Fri Mar 21, 2008 5:53 am Post subject: |
|
|
Newbie
Joined: 28 Mar 2006
Posts: 5
|
Hi Peter,
good idea to check the authority events. I'll pass this info to my colleague. He will solve this while I am on holiday. What a timing... 
Thanks for the input. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 21, 2008 6:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I would have the requesting application coded to SET_IDENTITY_CONTEXT for those messages whose userid will not otherwise have local authority on the responding platform.
_________________
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 |
|
|
| ko.t |
| Posted: Sat Mar 29, 2008 12:50 am Post subject: |
|
|
Newbie
Joined: 29 Mar 2008
Posts: 9
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Mar 29, 2008 4:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| GRTMQMAUT OBJ(RPY2Q) OBJTYPE(*Q) USER(JANE) AUT(*GET *PUT) MQMNAME(QMGR) |
This command is for WMQ on iSeries (as/400). Refer to the WMQ System Administration manual that covers distributed (Windows, UNIX) for setmqaut commands for your platform.
_________________
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 |
|
|
| ko.t |
| Posted: Sat Mar 29, 2008 5:13 am Post subject: |
|
|
Newbie
Joined: 29 Mar 2008
Posts: 9
|
Ok, thanx for your reply. 
I have tried it with setmqauth and <our_user> has full authority (only a change with setmqauth and etc/group (Solaris)???). But still the same:
| Quote: |
03/20/08 13:12:47 - Process(20347.483) User(our_user) 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 <THEIR.ReportQ> on queue manager <THEIRQM>
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. |
Is my previous post about enabling authority events true? The messages in SYSTEM!ADMIN!QMGR!EVENT don't tell me a lot. It seems like copies of messages that were sent.
Does somebody have any ideas? |
|
| Back to top |
|
|
|
|
