Hi, Good stuff.
Client channel or MQCHLIB (or MQSERVER) environment variable is ONLY used by C/C++/COBOL/VB type programs. IBM decided, for good or bad, that when coding for MQ base Java or Java MQ JMS programs, the MQ connection framework would not use either Client channel or MQCHLIB. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Benjamin Zhou <[EMAIL PROTECTED]>: > > Hi Roger, > > great insight ! > > Following your suggestion, I let my jms program on NT send 1000 msg, now I > can see the SYSTEM.DEF.SVRCONN in running state for a few seconds. > > Just one more question, why does client connection channel definition or > MQCHLIB variable has no effect on JMS program? > > best regards, > Ben > x.2474 > > > > > > > > > Roger Lacroix > > <[EMAIL PROTECTED] To: MQSeries List > <[EMAIL PROTECTED]> > alware.biz> cc: "Benjamin F. > Zhou" <[EMAIL PROTECTED]> > Subject: Re: Puzzled: > MQJE001, MQRC 2102 for non-mqm users > 01/08/2004 03:22 PM > > > > > > > > > > Hi, > > Those client channels or MQCHLLIB environment variable will have NO effect > on > your JMS program. > > (1) Normal. > (2) Channel deletion has no effect. Same as (1). > (3) Normal. > (4) It will use the default SVRCONN channel of 'SYSTEM.DEF.SVRCONN'. Again > normal. > (5) Normal. You may not be fast enough to see it be running. > (6) Normal. > > The one thing that I have noticed with version 5.3 of WMQ is that if an > application behaves well (i.e. properly closes queues and disconnects) then > > within a second or two, the SVRCONN channel goes to inactive (assuming all > 1 > connection). > > Therefore, to properly see a running SVRCONN channels, you will need to > send a > few hundred messages or put a 100ms sleep between puts. > > Hope that helps. > > Regards, > Roger Lacroix > Capitalware Inc. > http://www.captialware.biz > > > Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>: > > > Thanks everyone for trying to clariy this for me. > > > > Actually, it was also my conviction that an MQI channel would be used for > > ANY client application to talk to a remote qmgr. I came to the last > > conclusion through a series of tests. > > > > my JMS program is on a local NT PC. it sends msg to MYQM on an AIX > server, > > websvr1. > > > > As I did usual with MQclient applications , I defined a svrconn channel > > SVRC.MYQM on MYQM on websvr and defined a client connection channel on > the > > NT PC, beside several other client channels to qmgrs on other servers. > The > > environment variable MQCHLLIB has been defined to point to the file > > mqchltab's location. I defined all these clients channels under a single > > queue manager, which has nothing to do with any other queue manager, > except > > to define all the client channels. > > > > 1. I defined a qcf this way: > > del qcf(qCF) > > def qcf(qCF) qmgr(MYQM) host(websvr1) channel(SVRC.MYQM) > > transport(client) port(1414) > > del q(reqQ) > > def q(reqQ) qmgr(MYQM) qu(TESTQ) > > end > > I run my jms program to put msg to the queue TESTQ on the remote > > MYQM, successful. > > > > 2. I removed the client channel definition on NT; run the jms program, > msg > > successfully gets on the TESTQ on MYQM. I noticed the channel SVRC.MYQM > is > > always inactive. > > > > 3. on websvr1's MYQM, I remove the svrconn channel SVRC.MYQM; run the > > program, it failed with msg: "... failed to create MQQueueManager ..." > > > > 4. on MYQM, I recreated the svrconn channel SVRC.MYQM. However, I > removed > > the property channel(SVRC.MYQM); run the program, successful. Here is the > > jndi setup script: > > del qcf(qCF) > > def qcf(qCF) qmgr(MYQM) host(websvr1) transport(client) > > port(1414) > > del q(reqQ) > > def q(reqQ) qmgr(MYQM) qu(TESTQ) > > end > > > > 5. on MYQM, I again removed svrconn channel SVRC.MYQM, run the program, > > successful. again. I checked, no svrconn channel is running, not even > > SYSTEM.DEF.SVRCONN . > > > > 6. on NT, I added back the property channel(SVRC.MYQM) in my jndi script, > > but removed host(websvr1), run the program, as Peter anticipated, I got > the > > error message: "... failed to create MQQueueManager for 'localhost:MYQM' > > ..." > > > > Under no circumstance did I see a svrconn channel became running except > > SYSTEM.ADMIN.SVRCONN, which is always running since I use remote admin. > > > > It is after all these tests did I arrive at the conclusion that JMS > client > > doesn't use MQI channel unless we explicitly require that it use one. > Even > > then, it is just referenced, not really used. > > > > Any IBMer out there can confirm or dis-confirm my argument? or further > > clarify it? > > > > best regards. > > Ben > > x.2474 > > > > > > > > > > > > Roger Lacroix > > <[EMAIL PROTECTED] To: > > [EMAIL PROTECTED] > > ALWARE.BIZ> cc: > > Sent by: MQSeries Subject: Re: Puzzled: > > MQJE001, MQRC 2102 for non-mqm users > > List > > <[EMAIL PROTECTED] > > C.AT> > > > > > > 01/08/2004 12:26 PM > > Please respond to > > MQSeries List > > > > > > > > > > > > > > Hi Ben, > > > > I believe you have some misconceptions about your JMS / JNDI values. > > > > First off, if you are using 'transport(client)' then you WILL be using a > > SVRCONN channel - hence a MQI channel. Just because you did not specify > > it, > > does NOT mean you are not using one. I believe the default SVRCONN > channel > > used (when none is specified) is 'SYSTEM.DEF.SVRCONN'. > > > > Under normal circumstances, the 'MCA USER ID' field of the > > 'SYSTEM.DEF.SVRCONN' > > is blank. This generally means that you will be connecting / opening / > > getting / putting messages under the UserId of 'mqm'. > > > > Secondly, you can implement a reasonable amount of MQ security in this > > scenario > > (of course, client & server security exits would be better). > > > > At my current client, developers do not have access to the JMS / JNDI > tree > > in > > UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). > Therefore, > > we > > code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps: > > > > def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415) > > transport(client) ClientId(FRED) > > > > An alternate approach that is sometimes done (not strongly recommended) > is > > to > > allow the developer to code the UserId in their application. > > i.e. > > ((Message)outMessage).setStringProperty("JMSXUserID", "FRED"); > > > > In either case, we apply the necessary security to the UserId 'FRED' for > > the > > queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use > > the 'mqm' UserId (it is monitored). > > > > We have standards that state that developers, QA people, etc are not > > allowed > > access to the PROD queue managers unless approved but never with the > 'mqm' > > UserId. We assign the appropriate authority to THEIR UserId. > > > > Since my client is a bank / brokage-house, it is a fire-able offense to > > access > > PROD data if you have not been approved. Hence, generally speaking, > people > > do > > not risk it. > > > > Hope that helps. > > > > Regards, > > Roger Lacroix > > Capitalware Inc. > > http://www.capitalware.biz > > > > > > Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>: > > > > > 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
