| Author |
Message
|
| Bharat |
 Posted: Thu Mar 10, 2005 11:20 am Post subject: MQ Reason code 2035 (MQRC_NOT_AUTHORIZED) |
 |
|
Acolyte
Joined: 14 May 2002
Posts: 61
Location: Reston, VA, USA
|
We have a J2EE application running on WebSphere appserver making client connections to MQ Server. Both our application and MQ server v5.2 are running on the same Solaris box say ‘oldbox’. We migrated our application to a new Solaris box say ‘newbox’. We replicated all the MQ queues and channels from ‘oldbox’ to the ‘newbox’. When we tried to connect to MQ on the ‘newbox’, we got MQ Reason code 2035 (MQRC_NOT_AUTHORIZED).
One reason that I’m suspecting is: On the ‘oldbox’, our Java application was running with user ID called ‘user1’. So we configured the MQ Server Connection Channel’s MCAUSER parameter to ‘user1’. As we replicated all the MQ queues and channels on to the ‘newbox’, the Server Connection channel on the ‘newbox’ also has MCAUSER ‘user1’. But our application on the new box is running with a different user ID ‘user2’. Besides this, the ‘user1’ user ID doesn’t exist at all on the ‘newbox’.
When we pointed our application back to the queues on ‘oldbox’, it is working fine. So now our application is running on the ‘newbox’ with user ID ‘user2’ and connecting to the MQ on the ‘oldbox’ using Server Connection Channel with MCAUSER ‘user1’.
Another Windows based application running on a different box with a different user ID also got the same MQ Reason code 2035 (MQRC_NOT_AUTHORIZED) when it tried to connect to the MQ on the ‘newbox’. But it is able to connect to the MQ on the ‘oldbox’ with the same Server Connection Channel with out any problems.
Now we want our application to point to the queues on the ‘newbox’. For this, I’m trying to figure out what could be the actual problem. Is this problem b’coz of the MCAUSER issue? Does it work, if I change the Server Connection Channel's MCAUSER parameter on the 'newbox' to 'user2'? Or would it be something else?
I appreciate your help in resolving this issue.
Thanks in advance,
Bharat |
|
| Back to top |
|
 |
| csmith28 |
| Posted: Thu Mar 10, 2005 3:47 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1197
Location: Arizona
|
The user2 ID will have to be created on the new MQServer. You can either define the user's permission using setmquat if user2 is "NOT" a member of mqm or you can make user2 a member of the mqm group.
By specifying MCAUSER(user1) you have over ridden the value of UserIdentifier specified by the application in the MQMD. If user1 existed on the MQServer any application that attempted to connect to the MQManager via the SVRCONN channels that have been modified in this way would be able to connect with all the authority of user1 but since it does not exist you are still getting the 2035 error.
That is why you are still able to connect to the old Server with user2 being specified by the applicaiton.
So it would probably be a good idea to change the value of MCAUSER back to blank.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| Bharat |
| Posted: Fri Mar 11, 2005 8:33 am Post subject: MQ Reason code 2035 (MQRC_NOT_AUTHORIZED) |
|
|
Acolyte
Joined: 14 May 2002
Posts: 61
Location: Reston, VA, USA
|
Thanks Smith. I appreciate your solution.
1. Actually this is the second Server Connection Channel that we created on that Queue Manager. We have another Server Connection Channel with MCAUSER 'mqm'. So would it be a good idea to use the Server Connection Channel with MCAUSER 'mqm'? Or would it be better to have MCAUSER blank?
2. Is there any way to test this client connections? The problem is these are our Production servers. We need to schedule an outage and intimate all other applications when we want to point to this new queues. If it doesn't work, then we have to back out. We want to make sure that we don't get 2035 error when we point to the new queues. How can we test for a particular user whether it can make a client connection successfully using a particular Server Connection Channel?
Thanks and Regards,
Bharat |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Mar 11, 2005 8:47 am Post subject: Re: MQ Reason code 2035 (MQRC_NOT_AUTHORIZED) |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1197
Location: Arizona
|
| Bharat wrote: |
Thanks Smith. I appreciate your solution.
1. Actually this is the second Server Connection Channel that we created on that Queue Manager. We have another Server Connection Channel with MCAUSER 'mqm'. So would it be a good idea to use the Server Connection Channel with MCAUSER 'mqm'? Or would it be better to have MCAUSER blank? |
Well having MCAUSER(mqm) defined on your SVRCONN Channels will certainly assure that anyone (and I mean anyone) will be able to connect to the MQManager via those channels.
| Quote: |
| 2. Is there any way to test this client connections? The problem is these are our Production servers. We need to schedule an outage and intimate all other applications when we want to point to this new queues. If it doesn't work, then we have to back out. We want to make sure that we don't get 2035 error when we point to the new queues. How can we test for a particular user whether it can make a client connection successfully using a particular Server Connection Channel? |
If you loaded the samples on you client you should be able to use amqsputc to test the client servers ability to connect.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| Bharat |
| Posted: Fri Mar 11, 2005 9:14 am Post subject: |
|
|
Acolyte
Joined: 14 May 2002
Posts: 61
Location: Reston, VA, USA
|
| Quote: |
| If you loaded the samples on you client you should be able to use amqsputc to test the client servers ability to connect. |
We have the samples loaded. When I do amqsputc, it is working fine. May be because of our application client and MQ Server are on the same box. But it got 2035 when tried to connect using a particular Server Connection channel. So can we test amqsputc for a particular user on that box and using a speficied Server Connection Channel? If so how?
Thanks,
Bharat |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Mar 11, 2005 10:28 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1197
Location: Arizona
|
OK just for clarity. From where did you execute the amqsputc script?
Did you run it on the Client Server?
Did you run it on the MQManager Server?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| Bharat |
| Posted: Fri Mar 11, 2005 1:32 pm Post subject: |
|
|
Acolyte
Joined: 14 May 2002
Posts: 61
Location: Reston, VA, USA
|
It is a single server. MQ Server is installed on a Solaris server. Our Java application also runs on the same server. But it makes client connections to MQ using JMS interface.
So on that Solaris server, I executed the amqsput from the following directory. MQ Server is also there on the same server.
| Code: |
| /opt/mqm/samp/bin/amqsput |
It looks like, I need to test for the Server Connection Channel whether it works or not for a particular user ID. How can I do that?
Thanks,
Bharat |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Mar 11, 2005 1:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
You need to logon with that usrid and try perform the task.
Anyway you should handle your security as groups under unix.
Then give permissions to the group on your qmgrs and queues.
Enjoy  |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Mar 11, 2005 2:00 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1197
Location: Arizona
|
you need to try using the "amqsputc" not amqsput
Log on to the server as the user you want to access the MQManager
Set your MQSERVER environmental variable.
| Code: |
# export MQSERVER=SVRCONN.CHANNEL/TCP/hostname.domain.com
# /opt/mqm/samp/bin/amqsputc QUEUE.NAME |
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| Bharat |
| Posted: Tue Mar 15, 2005 8:18 am Post subject: |
|
|
Acolyte
Joined: 14 May 2002
Posts: 61
Location: Reston, VA, USA
|
I'm getting MQCONN ended with reason code 2059 (MQRC_Q_MGR_NOT_AVAILABLE) when I used the following commands.
All the Queue Managers are running and I'm using the correct Queue Manager name.
| Code: |
| /opt/mqm/samp/bin/amqsputc QUEUE.NAME |
or
| Code: |
| /opt/mqm/samp/bin/amqsputc QUEUE.NAME QUEUEMANAGER.NAME |
I have to use the Queue Manager name apart from queue name as we have multiple Queue Managers on that box.
Thanks,
Bharat |
|
| Back to top |
|
|
| vennela |
| Posted: Tue Mar 15, 2005 8:40 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| You have to start the listener |
|
| Back to top |
|
|
| Bharat |
| Posted: Tue Mar 15, 2005 9:23 am Post subject: |
|
|
Acolyte
Joined: 14 May 2002
Posts: 61
Location: Reston, VA, USA
|
Thanks Vennela, is this listener something specific to the Server Connection channel? Could you please give me more details?
Regards,
Bharat |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 15, 2005 9:29 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| Read the intercommunication manual. The listener needs to be up to access the qmgr through a client connection or to communicate with another qmgr. |
|
| Back to top |
|
|
| drahul |
| Posted: Mon Jan 15, 2007 2:33 am Post subject: '2035 (X'07F3') MQRC_NOT_AUTHORIZED |
|
|
Newbie
Joined: 12 Jan 2007
Posts: 3
|
Hi,
I am getting the following error message while sending the message on MQ.
'2035 (X'07F3') MQRC_NOT_AUTHORIZED
Explanation: The user is not authorized to perform
the operation attempted:
- On an MQCONN or MQCONNX call, the user is not
authorized to connect to the queue manager.
' On z/OS, for CICS applications,
MQRC_CONNECTION_NOT_AUTHORIZED is
issued instead.
Could somebody help me out in resolving this problem.
Regards,
Rahul |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 15, 2007 2:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
At a simple level, give the user authorisation.
At a more complex level, follow the advice given in this post, or the advice given in the multitude of other posts on this subject - 2035 is a very common error!
Happy Reading 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
