| Author |
Message
|
| artrangan |
 Posted: Sun Mar 18, 2007 4:33 pm Post subject: PCF exception when using WMQInitialContextFactory for JNDI |
 |
|
Novice
Joined: 18 Mar 2007
Posts: 13
|
I have a standalone JMS application that uses JNDI to get the ConnectionFactory & Queues. I use the WMQInitialContextFactory (support pac ME01) as the InitialContext. The PCF jar has been added to the classpath.
The channel that is used to connect to the QMgr has a non-mqm user as the MCAUSER. When I try to do a lookup a ConnectionFactory, I get a PCFException, reason code 2035.
What access do I need to give the group to which this non-mqm user belongs in order to be able to do a successful lookup ?
Thanks,
Art. |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Sun Mar 18, 2007 11:23 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
for qmgr at least connect and inquire authority,
for the queues inq and for the command queue atleast put...
look at the messages and see for which objects you get 2035 and then add the necessary authority.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 19, 2007 2:45 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Michael Dag wrote: |
for qmgr at least connect and inquire authority,
for the queues inq and for the command queue atleast put...
look at the messages and see for which objects you get 2035 and then add the necessary authority. |
And for the model queue: allmqi. This way pcf can get the reply messages from the command server. Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| artrangan |
| Posted: Mon Mar 19, 2007 8:18 am Post subject: |
|
|
Novice
Joined: 18 Mar 2007
Posts: 13
|
| fjb_saper wrote: |
| Michael Dag wrote: |
for qmgr at least connect and inquire authority,
for the queues inq and for the command queue atleast put...
look at the messages and see for which objects you get 2035 and then add the necessary authority. |
And for the model queue: allmqi. This way pcf can get the reply messages from the command server. Enjoy |
Thanks for the suggestions. Appreciate the help. However, I still have the 2035 errors. Here is the OAM for the user (user1) for the COMMAND & MODEL queues:
setmqaut -m <qmgr> -n SYSTEM.DEFAULT.MODEL.QUEUE -t queue -g user1 +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m <qmgr> -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -g user1 +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m <qmgr> -n SYSTEM.MQCONTEXT.ADMIN.QUEUE -t queue -g user1 +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
Any suggestions ?
Thanks,
Art. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Mon Mar 19, 2007 8:35 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
and what are the settings for the qmgr?
did you: setmqaut -m <qmgr> -t qmgr +connect +inq -g user1
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| artrangan |
| Posted: Mon Mar 19, 2007 8:43 am Post subject: |
|
|
Novice
Joined: 18 Mar 2007
Posts: 13
|
| Michael Dag wrote: |
and what are the settings for the qmgr?
did you: setmqaut -m <qmgr> -t qmgr +connect +inq -g user1 |
I have, for the qmgr,
setmqaut -m <qmgr> -t qmgr -g user1 +altusr +connect +inq +set +setall +setid +chg +dlt +dsp |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Mon Mar 19, 2007 8:57 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
ok, no need to start guessing again...
turn on AUTHOREV on the QMGR
when authorisation fails it should put an event message to: SYSTEM.ADMIN.QMGR.EVENT
get MO71 to browse the messages, it will show you what exactly went wrong...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| artrangan |
| Posted: Mon Mar 19, 2007 9:51 am Post subject: |
|
|
Novice
Joined: 18 Mar 2007
Posts: 13
|
| Michael Dag wrote: |
ok, no need to start guessing again...
turn on AUTHOREV on the QMGR
when authorisation fails it should put an event message to: SYSTEM.ADMIN.QMGR.EVENT
get MO71 to browse the messages, it will show you what exactly went wrong... |
Thanks for the tip. I did :
ALTER QMGR AUTHOREV (ENABLED) on this <qmgr> and do see a message on the SYSTEM.ADMIN.QMGR.EVENT queue every time the I get the PCFException.
The text of the message, which is in bytes reads:
|................|
|................|
|........D.......|
|....0...DMOMDAHL|
|QMGR02..........|
|................|
|................|
|................|
|................|
|............moma|
|dmin.... |
DMOMDAHLQMGR02 is the qmgr name & momadmin is the mcauser on the channel.
It does not appear to say what object was being accessed when it ran into an authority problem.
Any suggestions ? I really appreciate your help.
Thanks,
Arun. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Mon Mar 19, 2007 10:08 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| artrangan |
| Posted: Mon Mar 19, 2007 6:06 pm Post subject: |
|
|
Novice
Joined: 18 Mar 2007
Posts: 13
|
| Michael Dag wrote: |
| artrangan wrote: |
The text of the message, which is in bytes reads:
|
| Michael Dag wrote: |
get MO71 to browse the messages, it will show you what exactly went wrong... |
get MO71 from the supportpac site http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27007198
and browsing the message will format the byte structure |
Thanks. MO71 appears to require mqic32.dll (MQ client) on my PC. I was able to verify, using MQExplorer to look at the event queue, that the user did not have authority to access a temporary dynamic queue.
To double check that, I created a new QMgr on the server, and I am able to connect and do JNDI lookups with the access you had outlined earlier. There are no temp. dynamic queues on this QMgr.
The other QMgr (the one I was having 2035 issues with) has a temporary dynamic queue called (COM.IBM.MQ.PCF.PCFMESSAGEAGENT1173988540590...). Not sure when and how this was created.
During lookup, the MQContext sends a PCFMessage which results in a 2035 exception. I can extract the PCFMessage from the nested exception and it reads:
com.ibm.mq.pcf.PCFMessage:
com.ibm.mq.pcf.MQCFH:
- type: 1
- strucLength: 36
- version: 1
- command: 13
- msgSeqNumber: 1
- control: 1
- compCode: 0
- reason: 0
- parameterCount: 1
com.ibm.mq.pcf.MQCFST:
- type: 4
- strucLength: 68
- parameter: 2016
- codedCharSetId: 0
- stringLength: 48
- string: 'COM.IBM.MQ.PCF.PCFMESSAGEAGENT1173988540590... '
I also verified that if I opened up MQExplorer to connect to this QMgr, it creates a temporary dynamic queue (AMQ.MQEXPLORER....) and this also causes an error.
So I guess it boils down to, what kind of access should I grant to what objects so that it is possible to send PCF messages to temporary dynamic queues ?
Any suggestions would be most welcome.
Thanks,
Art. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Mon Mar 19, 2007 10:17 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
you can apply a generic profile for the dynamic PCF Queues:
setmqaut -m <qmgr> -n AMQ.MQEXPLORER.* -t queue -g user1 +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m <qmgr> -n COM.IBM.MQ.PCF.* -t queue -g user1 +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
see if that helps
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| artrangan |
| Posted: Tue Mar 20, 2007 5:46 am Post subject: |
|
|
Novice
Joined: 18 Mar 2007
Posts: 13
|
| Michael Dag wrote: |
you can apply a generic profile for the dynamic PCF Queues:
setmqaut -m <qmgr> -n AMQ.MQEXPLORER.* -t queue -g user1 +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m <qmgr> -n COM.IBM.MQ.PCF.* -t queue -g user1 +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
see if that helps |
I tried the access set above. Think I am having trouble with the generic profiles. Should I enclose the -n parameter within quotes ?
Reason I am asking is that when I tried QUEUE.* earlier (all user-defined queues start with QUEUE) it would not work, so I had to manually list out all the queue names. Of course, the dynamic queues have a randomly generated number at the end, so I cannot work around it that way!
Your input is very helpful.
Thanks,
Art. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Mar 20, 2007 6:15 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
what error do you get?
| Code: |
setmqaut -m QMGRA -n AMQ.MQEXPLORER.* -t queue -p mquser +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
The setmqaut command completed successfully. |
works fine on my machine...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| artrangan |
| Posted: Tue Mar 20, 2007 7:02 am Post subject: |
|
|
Novice
Joined: 18 Mar 2007
Posts: 13
|
| Michael Dag wrote: |
what error do you get?
| Code: |
setmqaut -m QMGRA -n AMQ.MQEXPLORER.* -t queue -p mquser +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
The setmqaut command completed successfully. |
works fine on my machine... |
The execution of the setmqaut works fine for me as well, as evidenced by:
...
setmqaut -m qmgr -n AMQ.** -t queue -g user1 +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
...
when I do a amqoamd -m qmgr -s
However, I get a 2035 on this object when a pcf message is sent to this queue. When I actually spell out the queue name instead of wildcarding it, like AMQ.MQEXPLORER.390207298, then it works fine, no 2035.
Kinda bizarre!
-Art. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Mar 20, 2007 7:07 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
|
|
