| Author |
Message
|
| BBM |
 Posted: Fri Jan 06, 2012 9:10 am Post subject: 2035 accessing SYSTEM.MQCONTEXT.ADMIN.QUEUE |
 |
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi,
I have a developer trying to access a queue on our Test queue manager, but is getting a 2035 error for the queue SYSTEM.MQCONTEXT.ADMIN.QUEUE.
I've tried googling this queue and can find scant explanation for what it does. All our other developers have been using bindings files to lookup objects but I *believe* this is not the case here.
Does anyone have any pointers as to what the queue does - the right it needs is CHG which I am loathe to give unless there is a good reason.
I've tried searching the v7 docs for the queue name but it comes back with no results.
Any assistance as always gratefully received.
Thanks!
BBM |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Jan 06, 2012 9:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Is this running on z/OS by any chance?
That queue looks a lot like a slightly drunk RACF context security profile name.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jan 06, 2012 9:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I suspect your developer is trying to use the queue manager as a JNDI repository, rather than taking proper steps to configure a real JNDI that properly isolates application level objects from queue manager level objects.
That isolation being, of course, the entire point of using JNDI.
Use a file provider or a real JNDI lookup service, not the queue manager. Enforce this rigorously on your developers. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 06, 2012 11:49 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
I suspect your developer is trying to use the queue manager as a JNDI repository, rather than taking proper steps to configure a real JNDI that properly isolates application level objects from queue manager level objects.
That isolation being, of course, the entire point of using JNDI.
Use a file provider or a real JNDI lookup service, not the queue manager. Enforce this rigorously on your developers. |
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| BBM |
| Posted: Sun Jan 08, 2012 6:50 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Many thanks for the replies.
I agree it sounds like they are trying to use the queue manager as the repository.
Not being a jms expert by any stretch is there any JMS documentation either IBM or otherwise that describes best practice for this kind of thing?
I'd like something to back up my case when I refuse them access to the QM.
Many thanks,
BBM |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jan 08, 2012 9:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| BBM wrote: |
Many thanks for the replies.
I agree it sounds like they are trying to use the queue manager as the repository.
Not being a jms expert by any stretch is there any JMS documentation either IBM or otherwise that describes best practice for this kind of thing?
I'd like something to back up my case when I refuse them access to the QM.
Many thanks,
BBM |
Just stay firm and say just because IBM uses that method in demos does not mean it is best practice. Introduce them to the file based JNDI setup using the .bindings file. Tell them using the file based JNDI is closer to the true J2EE experience and allows for better indirection. Tell them that the QMGR based JNDI that they are using has a number of restrictions that they are not likely to be aware of... and does not do much for JNDI indirection... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
