Author |
Message
|
brian_r |
Posted: Tue Jun 16, 2009 8:59 am Post subject: Not Authorised 2035 when trying to connect to SVRCONN |
|
|
Apprentice
Joined: 28 Jan 2008 Posts: 31 Location: Dublin
|
Hi All,
Im getting a not authorised message from the command prompt when connecting from a Windows machine to a HPUX machine. Im running a local user account which Ive given all permissions to the target queue and target SVRCONN channel that Im using.
Neither error log has been populated to give me any further details. Is there anything(maybe locally) else I could not be authorised to.
"MQOPEN ended with reason code 2035" is all I get.
thanks in advance
Brian |
|
Back to top |
|
 |
ranganathan |
Posted: Tue Jun 16, 2009 9:05 am Post subject: |
|
|
 Centurion
Joined: 03 Jul 2008 Posts: 104
|
Did you do a dspmqaut ?!
Did you refresh the security ?! |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 16, 2009 9:15 am Post subject: Re: Not Authorised 2035 when trying to connect to SVRCONN |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
brian_r wrote: |
Is there anything(maybe locally) else I could not be authorised to. |
Does the user have connect authority? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Jun 16, 2009 9:16 am Post subject: Re: Not Authorised 2035 when trying to connect to SVRCONN |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Vitor wrote: |
brian_r wrote: |
Is there anything(maybe locally) else I could not be authorised to. |
Does the user have connect authority? |
Would hope the MQCONN would throw the 2035 in that case, not the MQOPEN. |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Jun 16, 2009 11:28 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
"Im getting a not authorised message from the command prompt..."
Can you be a little more specific, please.
What application are you executing from the command prompt?
Is there a qmgr on the platform where you are running the application?
Is it a client-bindings application?
What object is it trying to open? _________________ 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 |
|
 |
vol |
Posted: Tue Jun 16, 2009 11:59 am Post subject: |
|
|
Acolyte
Joined: 01 Feb 2009 Posts: 69
|
Enable auth events on the qmgr, and inspect the auth event queue after the app has run. The auth event will show the action attempted and the auth required.
Generally, the user name on Windows must exist on HP in lower case, and must have +connect +inq +dsp on the qmgr, and +get or +put on the queue depending on the options passed to MQOPEN
No auth is required on the channel just to run it |
|
Back to top |
|
 |
Sam Uppu |
Posted: Tue Jun 16, 2009 12:43 pm Post subject: |
|
|
 Yatiri
Joined: 11 Nov 2008 Posts: 610
|
Are you using the MCAUSER attribute filled with some user id on SVRCONN channel?. If so, you should connect to the QMgr via that SVRCONN channel with the userid used in MCAUSER of SVRCONN channel.
Thanks. |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Jun 16, 2009 12:46 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Are you using a client-channel table? If so, did you set the appropriate environment variables?
If you are not using a client-channel table, did you set the appropriate environment variables?
Is your application really a client app? Is it connecting to the correct qmgr? _________________ 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 |
|
 |
brian_r |
Posted: Wed Jun 17, 2009 12:24 am Post subject: |
|
|
Apprentice
Joined: 28 Jan 2008 Posts: 31 Location: Dublin
|
ranganathan wrote: |
Did you do a dspmqaut ?!
Did you refresh the security ?! |
Yes and Yes |
|
Back to top |
|
 |
exerk |
Posted: Wed Jun 17, 2009 12:29 am Post subject: Re: Not Authorised 2035 when trying to connect to SVRCONN |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
brian_r wrote: |
...Im running a local user account which Ive given all permissions to the target queue and target SVRCONN channel that Im using... |
Obvious question (I'm good at them): is the userid on the Windoze box also defined on the HP-UX box?
Sam Uppu wrote: |
...Are you using the MCAUSER attribute filled with some user id on SVRCONN channel?. If so, you should connect to the QMgr via that SVRCONN channel with the userid used in MCAUSER of SVRCONN channel... |
What would be the point of that? The idea of using an MCAUSER is to limit the access to objects to that MCAUSER which is authorised, of anyone authorised whom connects via that channel. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
brian_r |
Posted: Wed Jun 17, 2009 12:34 am Post subject: |
|
|
Apprentice
Joined: 28 Jan 2008 Posts: 31 Location: Dublin
|
bruce2359 wrote: |
"Im getting a not authorised message from the command prompt..."
Can you be a little more specific, please.
What application are you executing from the command prompt?
Is there a qmgr on the platform where you are running the application?
Is it a client-bindings application?
What object is it trying to open? |
Hi Bruce,
Im running amqsputc from a Dos command line. There is no qmgr on the platform Im using, its just a client installation. Its trying to connect to a queue called BRIAN through a SVRCONN channel.
The only error message I see is:
"Sample AMQSPUT0 start
target queue is BRIAN
MQOPEN ended with reason code 2035
unable to open queue for output
Sample AMQSPUT0 end"
Brian |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Jun 17, 2009 2:43 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
brian_r wrote: |
ranganathan wrote: |
Did you do a dspmqaut ?!
Did you refresh the security ?! |
Yes and Yes |
Show us the output of dspmqaut for the group that contains your ID. This assumes the MCAUSER of the SVRCONN channel is blank allowing your ID to actually be used, otherwise the ID in the MCAUSER is used. In that case we need the dspmqaut for the group that holds that ID. A Security Exit on the channel could be changing the ID, but that would be rare.
Then we need to see the options you are using on your MQOPEN of the queue.
Turning on Authority Events at the QM will cause an event message to be produced. It will tell you what MQ API call is failing on what MQ object with what ID. It also includes the options being used, but just the numerical sum of the bits that you set when you choose your MQOPEN options. I wish IBM would just display the actual options - its not easy to reverse engineer the # to get the actual options. Anyone know of a Support Pack or hidden command that can do this?
But from this:
Code: |
The only error message I see is:
"Sample AMQSPUT0 start
target queue is BRIAN
MQOPEN ended with reason code 2035
unable to open queue for output
Sample AMQSPUT0 end" |
It looks like the first thing to check is does whatever ID being used have +put authority for the BRIAN queue.
Regarding the question of did you run refresh security, that is only needed in this context if you modify group membership after the QM starts. Telling people to run refresh security and refresh cluster is a chronic disease on this forum. People see the word refresh and think refresh = fix all my configuration problems. I'd bet that 99% of the times those 2 refresh commands are being issued in the real world, there is zero actual cause for it. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Jun 17, 2009 4:46 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Please post your complete command prompt interaction - what you typed (the entire command). _________________ 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 |
|
 |
Sam Uppu |
Posted: Wed Jun 17, 2009 5:51 am Post subject: Re: Not Authorised 2035 when trying to connect to SVRCONN |
|
|
 Yatiri
Joined: 11 Nov 2008 Posts: 610
|
exerk wrote: |
brian_r wrote: |
...Im running a local user account which Ive given all permissions to the target queue and target SVRCONN channel that Im using... |
Obvious question (I'm good at them): is the userid on the Windoze box also defined on the HP-UX box?
Sam Uppu wrote: |
...Are you using the MCAUSER attribute filled with some user id on SVRCONN channel?. If so, you should connect to the QMgr via that SVRCONN channel with the userid used in MCAUSER of SVRCONN channel... |
What would be the point of that? The idea of using an MCAUSER is to limit the access to objects to that MCAUSER which is authorised, of anyone authorised whom connects via that channel. |
If the MCAUSER is blank, it will accept any of the user to access MQ objects. Lets say, if you have some user 'nobody' in the MCAUSER of SVRCONN channel and and a user 'abc' trying to access this qmgr via SVRCONN channel, you will get 2035.
Thatswhat I was saying.
Thanks. |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Jun 17, 2009 5:57 am Post subject: Re: Not Authorised 2035 when trying to connect to SVRCONN |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Sam Uppu wrote: |
If the MCAUSER is blank, it will accept any of the user to access MQ objects. Lets say, if you have some user 'nobody' in the MCAUSER of SVRCONN channel and and a user 'abc' trying to access this qmgr via SVRCONN channel, you will get 2035.
Thatswhat I was saying. |
That's incorrect.
If you have a user 'nobody' in the MCAUSER of a SVRCONN, then EVERY CONNECTION to that SVRCONN will be authorized as the user 'nobody'. Regardless of what user is specified at the client end.
If the user 'nobody' is a member of MQM, then you will not get a 2035. |
|
Back to top |
|
 |
|