| Author |
Message
|
| ruturaj |
 Posted: Thu Feb 23, 2006 10:24 pm Post subject: 2035 error on MQOPEN |
 |
|
Newbie
Joined: 23 Feb 2006
Posts: 5
|
I am facing a strange problem. I work on AS400 MQ-Series with a cluster set up. Till yesterday I was able to open a cluster queue on the remote queue manager and put messages on it. There has been no chenge in the user authorities over the past several months. But today when I try to open the cluster queue, I get a 2035 error. However, if I logon to the AS400 session using another user profile with similar authorities on MQ objects and perform an MQOPEN, I do not get this error. Can somebody advice what can be the problem?
_________________
Ruturaj Khairatkar |
|
| Back to top |
|
 |
| mvic |
| Posted: Fri Feb 24, 2006 1:26 am Post subject: Re: 2035 error on MQOPEN |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| ruturaj wrote: |
| Till yesterday I was able to open a cluster queue on the remote queue manager and put messages on it. There has been no chenge in the user authorities over the past several months. But today when I try to open the cluster queue, I get a 2035 error. |
Evidently something changed between yesterday and today. If you can find out who was administering the system in that time, and find out what they did, this will hold the key to understanding why things have changed. I see 2 options: 1. someone changed the authorization information in the queue manager, or 2. someone changed the OS user/group information for the user running your program. |
|
| Back to top |
|
|
| ruturaj |
| Posted: Fri Feb 24, 2006 1:43 am Post subject: |
|
|
Newbie
Joined: 23 Feb 2006
Posts: 5
|
Can you advice what all checks I should do at my end? I obviously don't have any control over the authorisations on the remote queue manager and the administrators on that side claim that there has not been any change in authority settings. The reason for asking this is that I set some parameters and directly call the API MQOPEN, the source code of which i don't know at all. As such I don't have any idea what user id MQ uses to to execute this operation. so i don't know which user should I check the settings for.
_________________
Ruturaj Khairatkar |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Feb 24, 2006 1:55 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
I suggest running the app after MQ trace has been turned on. Use the MQ trace options "all" and "detail" if these exist on the 400. (Sorry this is not my expert platform).
Review the trace files to see what information was sent up to the queue manager - do they contain the userId in use, and the resultant 2035 error?
This is information to pass to the administrators of the queue manager that is refusing your MQOPEN call. I expect they are responsible for ensuring the queue manager services its apps correctly...?
EDIT: correct typo in 1st paragraph
Last edited by mvic on Mon Feb 27, 2006 2:29 am; edited 1 time in total |
|
| Back to top |
|
|
| ruturaj |
| Posted: Fri Feb 24, 2006 2:12 am Post subject: |
|
|
Newbie
Joined: 23 Feb 2006
Posts: 5
|
I had actually done the same thing before posting a query on this forum. But after going through the trace, the administrators said there wasn't much useful info in that. They have been insisting on checking whether the user id belongs to mqm group on our side. But i don't get this exactly. Shouldn't authority be provided to *public on their end for the specific queue? what can i change on our side? 'twould be great if u can suggest what i should check on our side of the MQ set up.
_________________
Ruturaj Khairatkar |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Feb 24, 2006 3:26 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| ruturaj wrote: |
| I had actually done the same thing before posting a query on this forum. But after going through the trace, the administrators said there wasn't much useful info in that. They have been insisting on checking whether the user id belongs to mqm group on our side. But i don't get this exactly. Shouldn't authority be provided to *public on their end for the specific queue? what can i change on our side? 'twould be great if u can suggest what i should check on our side of the MQ set up. |
I'm not sure of your topology, but mqm group membership is only ever relevant on the machine where the qmgr is running.
mqm group membership should be reserved for MQ administrators. It's not generally good to use this group for apps.
Some questions to ponder and discuss with the admins: Why has the 2035 occurred? Why is it happening for the first time today, where it didn't happen yesterday? What authorization was missing from the user that attempted the MQOPEN?
In order to find the reason for the authorization failure (if it isn't obvious after doing the initial analysis above), it may be necessary to trace the queue manager during your MQOPEN attempt. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Feb 24, 2006 3:48 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
you could also turn on authority events for the qmgr, that will tell you what userid and open options were specified on the MQOPEN call (as well as the qname), and then check that against dspmqaut output for that queue / profile. (okay, maybe you need to get your mqadmins to do that)
_________________
-wayne |
|
| Back to top |
|
|
| ruturaj |
| Posted: Mon Feb 27, 2006 12:24 am Post subject: |
|
|
Newbie
Joined: 23 Feb 2006
Posts: 5
|
Thank you all for your help. I just tried out a simple thing & it resolved the issue. After restarting the queue manager the problem does not exist any more. Although I cannot figure out the logic behind such a behaviour, on several occasions I have noticed that restarting the queue manager resolves many ad hoc issues. But while discussing this matter with you people, I certainly gained more insight into MQ. Thanks once again.
_________________
Ruturaj Khairatkar |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Feb 27, 2006 2:41 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
If there is a future occurrence of such problems as this I would encourage you and the admin staff to consider running an MQ trace during the API failure, and/or look at authorization events, per the suggestions above. It should be possible to understand the real reasons for the failure, and fix the real problem. Then it should not be necessary to restart the qmgr - if indeed it is difficult for you to find a window in which to do this.
Regards |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 27, 2006 8:59 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
@ruturaj
Did you ever run the mqsc command REFRESH SECURITY? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ruturaj |
| Posted: Mon Feb 27, 2006 8:26 pm Post subject: |
|
|
Newbie
Joined: 23 Feb 2006
Posts: 5
|
@mvic
Ya, sure. Even I would have liked to enable the authority events & go to the crucks of the problem. But unfortunately I read this suggestion after I had tried out restarting MQM. I would definitely try it out in future if I am confronted with a similar situation.
@ fjb_saper
No, I haven't refreshed security.
_________________
Ruturaj Khairatkar |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 28, 2006 8:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Read up in the manual about REFRESH SECURITY so the next time you will know when you need to use. It avoids having to restart the qmgr for security.
In our scripts we run it after each set of setmqauts
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Mar 01, 2006 9:14 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| fjb_saper wrote: |
Read up in the manual about REFRESH SECURITY so the next time you will know when you need to use. It avoids having to restart the qmgr for security.
In our scripts we run it after each set of setmqauts
Enjoy |
When MQ starts up, it caches the user and group structure of the OS (e. G. Unix). When users have been added to or removed from a group, MQ does not care about. Since version 5.3 the REFRESH SECURITY command refreshes these cache (before 5.3 you had to restart the QMgr).
But, the command setmqaut sets or removes permissions immediately. You do not need to run the REFRESH SECURITY command.
One hint: Once I had the problem, that neither the REFRESH SECURITY nor a QMgr restart were successful. Only the command REFRESH SECURITY(*) did refresh the cache (although both commands should be equivalent). Maybe a bug - not a feature  .
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
