I may be wrong, but the following def: "def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415)"
will cause your QCF to default to the SYSTEM.DEF.SVRCONN channel.I have never heard of an MQClient connecting to a QM and not using a SVRCONN channel, regardless of what interface was on top of that MQClient (like JMS). "def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)" Would default the QCF to the localhost, since you did not specify the hostname. An MQClient will always use a hostname and will come in through a SVRCONN channel. The building of the QCF just happens to let you leave these 2 fields blank and then gives you the default values. -----Original Message----- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 11: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 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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
