| Author |
Message
|
| srvm |
 Posted: Thu Feb 10, 2005 1:40 pm Post subject: How to setup this |
 |
|
Apprentice
Joined: 18 Aug 2004
Posts: 43
|
We have remote qmgr accessing local qmgr. Application on the remote side uses different userid's ( abc, def, ...) and passes that in MQMD. The application also requests COA. The COA is failing with 2035. I think this is beacuse the users abc, xyz,..... does not exist on local box/qmgr. I do not want to create these many users for each different env coming to local qmgr and do setmqaut.
Is there something i can set like MCAUSER, USERID etc. to say use one ID that can provide this put on xmitq/remote q to be successful.
Any sugegstions will be welcome. I bascially do not want to create N users for N remote env accessing our q mgr. Also, not expecting any APP changes on the remote side. But, would like to hear if some MQ chnages would mitigate this prob.
TY.
Raj |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Feb 10, 2005 1:45 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can set the MCAUser on the channel from the remote queue manager to your local queue manager.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| srvm |
| Posted: Thu Feb 10, 2005 1:51 pm Post subject: |
|
|
Apprentice
Joined: 18 Aug 2004
Posts: 43
|
Jeff, Thank you. I suppose that will overwrite the id that comes in the MQMD ( as pass dinetity context or set all identity context).
Am I Right? |
|
| Back to top |
|
|
| csmith28 |
| Posted: Thu Feb 10, 2005 2:39 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Actually what happens is, when the Message Channel Agent on the remote MQManager starts it takes the value of MCAUSER instead of the USER value in the MQMD.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| Tibor |
| Posted: Fri Feb 11, 2005 6:02 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Quote: |
| I do not want to create these many users for each different env coming to local qmgr and do setmqaut. |
I agree. But I don't recommend you a plain MCAUSER setting without channel encryption (SSL, and/or a security exit like BlockIP2)
There is a very ugly solution (but works  ). When messages arrives into the dead-letter-queue, runmqdlq can re-route these with mq admin authority. Place this entry into the rules table for runmqdlq:
reason(2035) msgtype(MQMT_REPORT) action(retry)
Tibor |
|
| Back to top |
|
|
| srvm |
| Posted: Fri Feb 11, 2005 7:42 am Post subject: |
|
|
Apprentice
Joined: 18 Aug 2004
Posts: 43
|
Thank you csmith and tibor.
and yes, we are running SSL. So, we just make change on the sender channel of the remote qmgr w/ a given MCAUSER.
Any other options? |
|
| Back to top |
|
|
| kman |
| Posted: Sun Feb 13, 2005 8:21 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
Correct me if I am wrong, but I thought the COA carries the same user identifier of the original message?
So if the original message contains the userid abc, then the report came back with same userid abc. Unless in a couple of occasions.
| Quote: |
| When the report is generated, the ReplyToQ queue is opened and the report message put using the authority of the UserIdentifier in the MQMD of the message causing the report |
and..
| Quote: |
| Applications generating reports should normally use the same authority as they would have used to generate a reply; this should normally be the authority of the user identifier in the original message. |
|
|
| Back to top |
|
|
| Tibor |
| Posted: Mon Feb 14, 2005 2:55 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
kman,
That's why the username abc must exists on destination platform. But when there doesn't exist a full cross-platform user definitions and no plan for it, need some workaround 
Tibor |
|
| Back to top |
|
|
| kman |
| Posted: Mon Feb 14, 2005 5:59 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
hmmmm !
| Quote: |
| COA reports generated by the queue manager are put with whatever authority was used when the message causing the report was put on the queue manager generating the report. For example, if the message was put by a receiving MCA using the MCA’s user identifier, the queue manager puts the COA report using the MCA’s user identifier. |
I thought that means, the report carries the same userid as the one originally puts the message, i.e., the request message. As this report is generated by the queue manager, the userid value is the same as using PASS_IDENTITY_CONTEXT.
If abc was defined on requestor system, puts the request message, the target queue manager generates the report, used the requestor userid abc to place the report on the replytoq. It should not be using xyz authority, since the message causing the report is the request message. This is COA. It has not been delivered to the application on receiver system yet.
hmmm ? I am boink here. |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Feb 15, 2005 12:37 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
kman,
You are correct... I was hasty my post is written about COD not COA. But in this case I don't understand what was the original problem - I'd never got MQRC 2035 because COA.
Tibor |
|
| Back to top |
|
|
| srvm |
| Posted: Tue Feb 15, 2005 8:47 am Post subject: |
|
|
Apprentice
Joined: 18 Aug 2004
Posts: 43
|
Now, I am lost. Can we use the approach that was proposed in 2nd/3rd posting i.e. using MCA userid.
Yes, the problem is with COA not COD. The target ( receiver system) is not able to put Report message on Reply-to Queue beacuse the id that is coming in the request msg is not defined on the target ( recvr system). I hope I clarified the problem.
Raj |
|
| Back to top |
|
|
| EddieA |
| Posted: Tue Feb 15, 2005 9:51 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| Can we use the approach that was proposed in 2nd/3rd posting i.e. using MCA userid. |
Have you tried.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| kman |
| Posted: Tue Feb 15, 2005 4:33 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
If you try that (using MCAUserid) then it will be this;
| Quote: |
..For example, if the message was put by a receiving MCA using the MCA’s user identifier, the queue manager puts the COA report using the MCA’s user identifier.
|
I like to echoe what Tibor said, I never get 2035 with COA report message.
If the userid from the original message (requestor) is not defined on the receiving system, you should be getting 2035 at the receiving system, and the message is, I believe, is sent to DLQ. That should not be COA giving 2035. COA was not generated because of 2035. and this 2035 was seen in the DLQ and error log. That what I think is the situation.
If this is indeed the actual problem, then the problem description above is misleading.
Yes, you can use MCAUserid. The only issue with that is, whoever rides on the same channel, will also be using the same MCAUserid. But, this is what you want in the first place.  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 15, 2005 4:48 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| kman |
| Posted: Tue Feb 15, 2005 4:58 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
Peter,
I read the link.
It is not quite the way it is, I think.
Both COA and COD is generated by the queue manager.
In COA terms, the moment the message arrive on the target system, COA is generated.
In COD terms, it is only generated once queue manager has given the message to the target application.
If MCAUserid is set at default blank - undefined, then MCA is out of the picture. The report is carrying the requestor userid set by the queue manager - useridentifier of the original message. |
|
| Back to top |
|
|
|
|
