| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| PCF exception when using WMQInitialContextFactory for JNDI |
« View previous topic :: View next topic » |
| Author |
Message
|
| jefflowrey |
 Posted: Tue Mar 20, 2007 7:12 am Post subject: |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Refresh security should never be necessary after setmqaut commands.
It's only necessary if OS groups change membership.
See if Michael missed a useful/needed permission by changing the setmqaut to +mqiall or +all.
Also remember that your working with dynamic queues, that are built off of model queues, and you may need to give permissions to the model queue instead of the dynamic queue... In the case of PCF replies, this is usually actually SYSTEM.ADMIN.COMMAND.QUEUE.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| artrangan |
| Posted: Tue Mar 20, 2007 3:17 pm Post subject: |
|
|
Novice
Joined: 18 Mar 2007
Posts: 13
|
| jefflowrey wrote: |
Refresh security should never be necessary after setmqaut commands.
It's only necessary if OS groups change membership.
See if Michael missed a useful/needed permission by changing the setmqaut to +mqiall or +all.
Also remember that your working with dynamic queues, that are built off of model queues, and you may need to give permissions to the model queue instead of the dynamic queue... In the case of PCF replies, this is usually actually SYSTEM.ADMIN.COMMAND.QUEUE. |
Thanks Michael & Jeff, for your tips.
By giving +allmqi +alladm access to the SYSTEM.ADMIN.COMMAND.QUEUE, I was able to get over the issue of access to temporary dynamic queues, like AMQ.<number>
That has resolved all my problems, save one. I have 2 QMgrs, the access rights to which are identical. I use MQExplorer to connect to both of them. They each create an AMQ.MQEXPLORER.<number> queue, which is a temporary dynamic queue.
With my JMS application, it is possible to connect to the 1 QMgr, but not to the other. The error I get is a 2035, generated as a PCFException when the a message is sent to the AMQ.MQEXPLORER.<number> queue.
So I tried to setmqaut with the exact queue name, like AMQ.MQEXPLORER.1530944320, and it works ! It is almost as if there was something funky with my wildcarding. Any suggestions ?
The OAM for the system & amq queues are as follows:
setmqaut -m qmgr -n SYSTEM.DEFAULT.MODEL.QUEUE -t queue -g user +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m qmgr -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -g user +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m qmgr -n SYSTEM.MQCONTEXT.ADMIN.QUEUE -t queue -g user +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m qmgr -n AMQ.** -t queue -g user +browse +inq +dsp
Once again, thanks for all the help,
Art. |
|
| Back to top |
|
|
| artrangan |
| Posted: Thu Mar 22, 2007 5:28 am Post subject: |
|
|
Novice
Joined: 18 Mar 2007
Posts: 13
|
I had to restart my QMgr to make that bizarre (imo) behavior go away.
Also I had to give +dsp access to SYSTEM.MQEXPLORER.REPLY.MODEL and not bother with any of the AMQ.** queues.
With these authorities, it is now possible for me to connect to a QMgr via a channel that has a non-mqm user as its MCAUSER.
Thanks Michael and Jeff for your input. It was all extremely helpful.
-Art. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
