| Author |
Message
|
| kd |
 Posted: Thu Aug 10, 2006 2:05 am Post subject: 2035 with MCAUSER and OAM set correctly |
 |
|
Novice
Joined: 10 Aug 2006
Posts: 19
|
Help!
I've been searching this forum for similar issues but nothing seems to help me. Here's my problem:
I have MQ5.3.11 on Solaris 9, I have a RCVR channel with the MCAUSER set as test1, I also have a local solaris user of the same name, not in the mqm group. I have a local queue called QUEUE1. I have used OAM to set up the necessary permissions - the output of dspmqaut for that user and queue is as follows:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr
The output of dspmqaut for the user and queue manager is:
inq
connect
Whenever I change the OAM permissions I always run refresh security. Sending a message from a remote QM down that channel results in the following on my local QM logs:
----- amqrccca.c : 883 --------------------------------------------------------
08/10/06 09:40:28
AMQ9002: Channel 'MYRCVR' is starting.
EXPLANATION:
Channel 'MYRCVR' is starting.
ACTION:
None.
-------------------------------------------------------------------------------
08/10/06 09:40:28
AMQ9565: No dead-letter queue defined.
EXPLANATION:
The queue manager 'MYQMGR' does not have a defined dead-letter queue.
ACTION:
Either correct the problem that caused the program to try and write a message
to the dead-letter queue or create a dead-letter queue for the queue manager.
----- amqrmmqa.c : 334 --------------------------------------------------------
08/10/06 09:40:28
AMQ9599: Program could not open queue manager object.
EXPLANATION:
The attempt to open either the queue or queue manager object
'QUEUE1' on queue manager 'MYQMGR' by user 'test1'
failed with reason code 2035.
ACTION:
Ensure that the queue is available and retry the operation. If the message is
from a remote Queue Manager, check the Message Channel Agent User Identifier
has the correct authority.
----- amqrmmqa.c : 780 --------------------------------------------------------
08/10/06 09:40:28
AMQ9999: Channel program ended abnormally.
EXPLANATION:
Channel program 'MYRCVR' ended abnormally.
ACTION:
Look at previous error messages for channel program 'MYRCVR' in
the error files to determine the cause of the failure.
-------------------------------------------------------------------------------------
I don't have a DEADQ, but I don't want one either....
On the sender side, the AMQ9506 error just says the remote QM did not accept last batch of msgs....
What am I doing wrong? I can't think of anything else - I've even restarted the QM to no avail...
Thanks in advance! |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Thu Aug 10, 2006 2:20 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Enable qmgr authority events, and inspect the msgs written to the auth event queue.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 10, 2006 2:22 am Post subject: Re: 2035 with MCAUSER and OAM set correctly |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kd wrote: |
I don't have a DEADQ, but I don't want one either....
|
Why on Earth not? 
Also, what's the design rational for setting MCAUSER in the RCVR (just for my interest)?
You might want to consider turning security tracing on to get more details of exactly what check is being made.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kd |
| Posted: Thu Aug 10, 2006 2:42 am Post subject: |
|
|
Novice
Joined: 10 Aug 2006
Posts: 19
|
| Nigelg wrote: |
| Enable qmgr authority events, and inspect the msgs written to the auth event queue. |
Authority events were off, I switched them on and get the same after running setmqaut again and refreshing security. QMGR details:
1 : dis qmgr all
AMQ8408: Display Queue Manager details.
DESCR( ) DEADQ( )
DEFXMITQ( ) CHADEXIT( )
CLWLEXIT( ) CLWLDATA( )
REPOS( ) REPOSNL( )
SSLKEYR()
SSLCRLNL( ) SSLCRYP( )
COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE) QMNAME(MYQMGR)
CRDATE(2003-08-05) CRTIME(11.01.09)
ALTDATE(2006-08-10) ALTTIME(10.29.44)
QMID(MYQMGR_2003-08-05_11.01.09)
TRIGINT(999999999) MAXHANDS(256)
MAXUMSGS(10000) AUTHOREV(ENABLED)
INHIBTEV(DISABLED) LOCALEV(DISABLED)
REMOTEEV(DISABLED) PERFMEV(DISABLED)
STRSTPEV(ENABLED) CHAD(DISABLED)
CHADEV(DISABLED) CLWLLEN(100)
MAXMSGL(4194304) CCSID(819)
MAXPRTY(9) CMDLEVEL(530)
PLATFORM(UNIX) SYNCPT
DISTL(YES)
Any more params needing enabling?
A bit more info on what happens: when the message is placed on the channel at the other end, it goes into retrying state and I get UNCOMMITTED messages, I resolve the channel (backout) and start again after making changes again.
Also, my SYSTEM.AUTH.DATA.QUEUE has 233 messages on it since day one, nothing new on it today though...
Thanks again... |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 10, 2006 2:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
So what's on the event queue after enabling events? 
The reason your channel is going into retry is because the message can't be delivered to the remote queue manager. If you define a dead letter queue to which these can be delivered then this will fix your channel issue. Again I ask why you don't want a DLQ when it is intended to prevent exactly this issue?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kd |
| Posted: Thu Aug 10, 2006 3:00 am Post subject: |
|
|
Novice
Joined: 10 Aug 2006
Posts: 19
|
| Vitor wrote: |
| Again I ask why you don't want a DLQ when it is intended to prevent exactly this issue? |
Having a DEADQ doesn't prevent the issue, it just hides it. I'll still have a problem with not being able to write to the correct queue. Rather than having a DEADQ I want to be able to fix the original problem.
Contents of event queue are from yesterday, nothing new. However from my testing yesterday, the newest item on the queue contains a list of users/groups that have been given permission to my queue, or in mqm's group...
Thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 10, 2006 3:11 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you checked whether the target queue is full or the target queue manager just too busy with some batch to accept another UOW ?
Have you checked there is no seqnum mismatch on the channel?
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 10, 2006 3:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kd wrote: |
Having a DEADQ doesn't prevent the issue, it just hides it. I'll still have a problem with not being able to write to the correct queue. Rather than having a DEADQ I want to be able to fix the original problem.
|
And I'm not saying that the problem doesn't need to be fixed, or that having a DLQ will fix it. What I'm trying to understand is why you don't want have a DLQ as a general principle. It's common practice to have one as it prevents things like having to manually resolve channels. Also IMHO the DLQ doesn't hide issues, it highlights them. Because nothing should ever go there if you set it up with a TRIGGER(FIRST) it can provide an immediate alert of a problem.
Moving back to your problem (rather than this abstract design issue - hey, it's your queue manager, you don't want a DLQ don't have one  ), there's no authority event for the 2035 or even the channel starting? Do you get an event if you connect locally with a client (or similar)?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kd |
| Posted: Thu Aug 10, 2006 3:29 am Post subject: |
|
|
Novice
Joined: 10 Aug 2006
Posts: 19
|
| Vitor wrote: |
| there's no authority event for the 2035 or even the channel starting? Do you get an event if you connect locally with a client (or similar)? |
I'm not sure I'm looking at the right queue, if I look at the SYSTEM.ADMIN.QMGR.EVENT queue instead, I do see events every time I try to receive.
Return code I'm not sure of either - the message on the event queue contains the name of my local queue, plus the name of queue manager, plus username, then a bunch of weird characters that don't tell me anything
Unfortunately I can't connect locally as the user in my MCAUSER field as it's a 'dummy' account (no passwd, default shell is /bin/true), I don't think this will effect MQ though...
Also, target queue queue is empty, and channel seqnum is fine, not much else is going on in the QMGR.... |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Aug 10, 2006 3:37 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 10, 2006 3:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kd wrote: |
I'm not sure I'm looking at the right queue, if I look at the SYSTEM.ADMIN.QMGR.EVENT queue instead, I do see events every time I try to receive. |
The QMGR.EVENT queue is, logically enough, where the events go
| kd wrote: |
Return code I'm not sure of either - the message on the event queue contains the name of my local queue, plus the name of queue manager, plus username, then a bunch of weird characters that don't tell me anything |
The weird characters are the packed decimal format numbers. You'll find the format in the documentation.
| kd wrote: |
Unfortunately I can't connect locally as the user in my MCAUSER field as it's a 'dummy' account (no passwd, default shell is /bin/true), I don't think this will effect MQ though...
|
What about connecting as another user (like mqm)? It should still trigger an event. Also try defing and authorising another user id and use that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Aug 10, 2006 3:39 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Enabling the AUTHOREV attribute will not fix the issue, it will provide diagnostic information about the insufficient authority.
Inspect the auth event queue before and after a test, and post a browse (amqsbcg output) of any msgs added to the queue during the test.
The queue to look at is SYSTEM.ADMIN.QMGR.EVENT.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| kd |
| Posted: Thu Aug 10, 2006 3:48 am Post subject: |
|
|
Novice
Joined: 10 Aug 2006
Posts: 19
|
| Nigelg wrote: |
Inspect the auth event queue before and after a test, and post a browse (amqsbcg output) of any msgs added to the queue during the test.
The queue to look at is SYSTEM.ADMIN.QMGR.EVENT. |
Here it is, to confirm, GMAUK.QILNESP1.RCV.MINT is my local queue, mqgas is the local user that's in my MCAUSER, and qmgr is QM.GMAUKT00001 (I hobbled them before first post for clarity):
| Code: |
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 819
Format : 'MQEVENT '
Priority : 0 Persistence : 0
MsgId : X'414D5120514D2E474D41554B5430303044DA184820051302'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'QM.GMAUKT00001 '
** Identity Context
UserIdentifier : ' '
AccountingToken :
X'0000000000000000000000000000000000000000000000000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '7'
PutApplName : 'QM.GMAUKT00001 '
PutDate : '20060810' PutTime : '11454043'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 300 bytes
00000000: 0000 0007 0000 0024 0000 0001 0000 002C '.......$.......,'
00000010: 0000 0001 0000 0001 0000 0001 0000 07F3 '...............ó'
00000020: 0000 0007 0000 0004 0000 0044 0000 07DF '...........D...ß'
00000030: 0000 0000 0000 0030 514D 2E47 4D41 554B '.......0QM.GMAUK'
00000040: 5430 3030 3031 2020 2020 2020 2020 2020 'T00001 '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 0000 0003 0000 0010 ' ........'
00000070: 0000 03FC 0000 0002 0000 0004 0000 0044 '...ü...........D'
00000080: 0000 07E0 0000 0000 0000 0030 474D 4155 '...à.......0GMAU'
00000090: 4B2E 5149 4C4E 4553 5031 2E52 4356 2E4D 'K.QILNESP1.RCV.M'
000000A0: 494E 5420 2020 2020 2020 2020 2020 2020 'INT '
000000B0: 2020 2020 2020 2020 2020 2020 0000 0003 ' ....'
000000C0: 0000 0010 0000 03FE 0000 A810 0000 0004 '.......þ..¨.....'
000000D0: 0000 0020 0000 0BD1 0000 0000 0000 000C '... ...Ñ........'
000000E0: 6D71 6761 7320 2020 2020 2020 0000 0003 'mqgas ....'
000000F0: 0000 0010 0000 0001 0000 0006 0000 0004 '................'
00000100: 0000 0030 0000 0BD0 0000 0000 0000 001C '...0...Ð........'
00000110: 616D 7172 6D70 7061 2020 2020 2020 2020 'amqrmppa '
00000120: 2020 2020 2020 2020 2020 2020 ' '
|
Thanks again! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 10, 2006 4:04 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| Having a DEADQ doesn't prevent the issue, it just hides it. I'll still have a problem with not being able to write to the correct queue. Rather than having a DEADQ I want to be able to fix the original problem. |
Having a DLQ will allow you to see the reason code: 2035 authorization error or 2085 typo in the queue name? 2087 typo in the rqmname on the remote queue or no default path on a multihop... etc... and all this is in the DLQ on the target / hop qmgr... Not on the sending one where the error might be (wrong qmgr /qname in remote queue...)
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Aug 10, 2006 5:44 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The event msg shows that the user does not have authority to open the queue with the supplied options, xA810.
This is equivalent to:
FAIL_IF_QUIESCING
BIND_NOT_FIXED
SET_ALL_CONTEXT
OUTPUT
When a queue is opened with the open option MQOO_SET_IDENTITY_CONTEXT (SET_ALL_CONTEXT above)
the set authority on the qmgr is syntactically required.
The solution is to grant +setall authority on the qmgr to the user:
setmqaut -m QMGR -t qmgr -p user +setall
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
|
|
