Benjamin, Attached is a JNDI bindings file which was created without the channel option. You can look at it with a text editor and see that it put in a default entry for SYSTEM.DEF.SVRCONN. If you use the channel option this entry is replaced by your channel. You can also run your appl and see that you are really running on the default channel. I don't think the qmgr really has any special processing for either JMS and Java when the client is running the Java. It's all just basic MQ from the server's point of view so there has to be a svrconn channel.
Nick -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin F. Zhou Sent: Thursday, January 08, 2004 8:07 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Rob, thanks for the insight. However, a JMS application accesses a qmgr via a connection factory object defined in the JNDI namespace, NOT through a svrconn channel on the server, i,e. it's actually not using the MQI channel. It can be seen from the following entry in my definition script, that it actually creates a direct socket connection to the host and port: def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415) So such a definition makes it even more dangerous since there is no more MQ level security can be activated. While writing this, it became clear to me that the above is provided as an alternative to using MQI channel to access a remote qmgr in order to avoid having to define a client channel on the client side. Certainly, the above definition can be altered to use MQI channel instead of the host propery: def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client) However, the first is a dangerous alternative. Any comment? regards, Ben "Wyatt, T. Rob" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] C.AT> 01/05/2004 10:50 AM Please respond to MQSeries List Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob -----Original Message----- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COM> cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] .AC.AT> 01/02/2004 03:39 PM Please respond to MQSeries List Still....the unanswered question Why the 2102???? Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users >Date: Fri, 2 Jan 2004 13:40:13 -0600 > >When this happened to us, my developers were not printing the linked JMS >exception so I did not have a reason code to look at. If I had been given >a >2102, it sure would have thrown me off! I like to keep the events turned >on >so when I was presented with the problem I very quickly found an event >message showing the UserID, the QMgr INQ call and a 2035. Discussion with >the user revealed that any QMgr inquiry calls were happening inside the >Java >classes and not in his code. We have since learned that Java will inquire >on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it >has to back out a GET. > >-- T.Rob > >-----Original Message----- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 2:24 PM >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi Rob, > >Great ! Your tip on adding inq right to non-mqm users did the trick. Here >is the setmqaut command: > > setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq > >But how did you know that a JMS appl needs inq right to the qmgr to >establish connection? I didn't find such information on the JMS manual. > >thanks a lot for the insight ! > >Ben > > > > > > > > "Wyatt, T. Rob" > <[EMAIL PROTECTED] To: >[EMAIL PROTECTED] > MERICA.COM> cc: > Sent by: MQSeries Subject: Re: Puzzled: >MQJE001, MQRC 2102 for non-mqm users > List > <[EMAIL PROTECTED] > C.AT> > > > 01/02/2004 12:44 PM > Please respond to > MQSeries List > > > > > > >Benjamin, > >Are the classpaths the same between the two UserIDs? If you are on Unix, >try > >echo $CLASSPATH | tr ":" "\n" > >...from each user's command line and compare. There are generally two >types >of problems that manifest themselves differently under different users - >security, which you covered, and environment. > >Incidentally, you did not mention whether you gave the user Inquire on the >QMgr and queues. JMS will inquire the QMgr right after connecting. This >usually generates 2035's though. > >-- T.Rob > >-----Original Message----- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 11:48 AM >To: [EMAIL PROTECTED] >Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi, > >first, happy new year to everyone. > >while trouble-shooting a WAS application's MQRC2102 problem, I wrote a >simple jms program to put msg to a queue. > >The program runs without problem if I start it as "mqm", but if I logon as >a different user than mqm, got the same MQJE001, MQRC 2102 exception. >I explicitely allowed that user the right to connect to the same qmgr and >put/get to the queues, and run the sample executible amqsput, amqsget >without any problem. > >MQRC 2102 is resource problem, but I don't understand why it happen to WAS >users, but not to mqm, and only happens to jms applications. > >Any idea would be greatly appreciated. > >Benjamin F. Zhou >Messaging & Integration >Research & Technology, ITM >Mercedes-Benz USA >x.2474 > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _________________________________________________________________ Get reliable dial-up Internet access now with our limited-time introductory offer. http://join.msn.com/?page=dept/dialup Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
