| Author |
Message
|
| bobbee |
 Posted: Thu Apr 18, 2013 1:29 am Post subject: 2035 errors not showing up in log/event queues |
 |
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
AS400 MQFTE Client v7.0.4 connecting to Windows v7.5 QMGR
When FTE connects as an example using fteListAgents, I am receiving a 2035 on the command line in AS400. On the Windows side I am not seeing any activity in the AMQERR01.LOG. I then turned on Auhorazation events, installed MS0P and we see no events being generated. Just to get around the issue I put the FTEAGTD01 user in a group in the 'mqm' group and got connected. I would like to fix this but cannot determine what MQ is complaining about. I ave set the atypicl setmqaut commands for the ID. In fact I have a script I use in this setup at customers to set the security profiles. There is something else going on. I also turned off CHLAUTH in case that was getting in the way.
My real issue is the lack of information messages, usually it is the reverse, wading through toooo much. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Apr 18, 2013 3:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The error will appear in the error logs on the platform where the 2035 occurred. So if you encountered the 2035 on the iSeries box, look in the error logs there.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Thu Apr 18, 2013 4:27 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I've not played with MQ 7.5 on Windows yet, but historically MQ on Windows would report the details of the QM rejecting an MQAPI call with a 2035 in the QM error logs, in the Event Viewer and if Auth Events were turned on, in the event queue.
I too would have expected some evidence of the 2035 on the Windows QM, regardless of where the MQ Client is, IF the MQ Client was getting a 2035.
Although.....what if the 2035 is occurring on the MQCONNX...I seem to remember if you get rejected on the initial connection the QM never accepted you (rejection hurts) and maybe in this case you don't see it on the QM side? Not sure. If a CHLAUTH is blocking you at the MQ Listener level (using TYPE(BLOCKADDR)), that is stopped before any data is sent at all...in this case nothing gets recorded on the QM side?
But you turned off CHLAUTH, so that shouldn't be the cause of the 2035.
I'm asking more questions that answering 
Can you connect to the QM via another MQ Client over this same client channel successfully?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bobbee |
| Posted: Thu Apr 18, 2013 4:41 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
I am glad that observation calugt up to you Peter, I was beside myself formulating answers. Yes, we configured MQExplorer to access through this channel. We got that working and then tried the FTE iSeries client after setting the authorities for MQExplorer, n/g
Your CONNX statement is interesting, will look on the iSeries for some type of error.
Mucho Gracias
In the end, I told the client to open a PMR |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 18, 2013 5:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm with Bruce, look for errors on the MQ client side on iseries.
I suspect it's something weird like the MQ client not being able to access the network statck because of iseries permissions and deciding that means that it should report a 2035. |
|
| Back to top |
|
|
| bobbee |
| Posted: Thu Apr 18, 2013 5:33 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
I am going to look for the logs on the client side, But on the windows side, once we put the FTEAGENTS group, which has the iSeries agent Id in it, into the mqm group, things worked. So it would seem my often used setmqauth script is missing something. hummmmm
REM Authorizations for fteagent
setmqaut -m <Agent QMGR> -t qmgr -g fteagent +connect +altusr +setid +inq +dsp +altusr
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.COMMAND.** -g fteagent +put +get +setid +inq
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.DATA.** -g fteagent +put +get
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.STATE.** -g fteagent +put +get +inq
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.EVENT.** -g fteagent +put +get
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.REPLY.** -g fteagent +put +get
setmqaut -m <Agent QMGR> -t q -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -g fteagent +put
setmqaut -m <Agent QMGR> -t q -n SYSTEM.DEFAULT.MODEL.QUEUE -g fteagent +put +get +dsp +browse +inq
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.AUTHSCH1.** -g fteagent +get
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.AUTHADM1.** -g fteagent +get +browse
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.AUTHAGT1.** -g fteagent +get +browse +put
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.AUTHOPS1.** -g fteagent +get
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.AUTHTRN1.** -g fteagent +get
setmqaut -m <Agent QMGR> -t q -n SYSTEM.FTE.AUTHMON1.** -g fteagent +get |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 18, 2013 6:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
usually I grant allmqi and remove from there what is not needed...
Is there a downside on granting systematically +dsp +inq?
Remember if you use a JMS connection you need +inq or you may get a 2035 that's related to your missing +inq.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 18, 2013 7:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bobbee wrote: |
| I am going to look for the logs on the client side, But on the windows side, once we put the FTEAGENTS group, which has the iSeries agent Id in it, into the mqm group, |
Windows authenticates principles, not groups... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 18, 2013 8:52 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
usually I grant allmqi and remove from there what is not needed...
Is there a downside on granting systematically +dsp +inq?
Remember if you use a JMS connection you need +inq or you may get a 2035 that's related to your missing +inq.
Have fun |
But he does have dsp and inq against the QM object along with the other necessary authorities, which would lead me to believe he could at least establish a connection to the QM to the point that the QM could spit out the appropriate event if a subsequent object didn't have enough authority granted.
The fact that it works when the ID is in the mqm group, but reports NO errors or events on the QM side when the ID is not in the mqm group is just plain weird.
Bobbee, do you have this iSeries agent ID hard coded on the MCASUER of the channel? And if yes, it works when in the mqm group but not otherwise? Or is the MCAUSER blank and you are relying on the iSeries client to flow the ID up to the Windows MQ server?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| warrenJ |
| Posted: Thu Apr 18, 2013 9:06 pm Post subject: |
|
|
Apprentice
Joined: 11 Jan 2004
Posts: 29
Location: AUSTRALIA
|
|
| Back to top |
|
|
|
|
