Re: MQ JMS questions
HI Vitaliy The answer to question 2 is that you *must* use the Java/JMS stuff that comes as part of 5.3. MA88 isn't appropriate to 5.3. Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Vitaliy Ilyin Sent: 31 July 2003 04:20 To: [EMAIL PROTECTED] Subject: MQ JMS questions Hi everyone, I'd like to find if anybody had any problems with IBM's jms implementation on top of MQSeries. Environment: let's say we have the latest version of ma88 running on Wintel running against Sun Solaris 8 with MQ 5.3 on it. Specific questions are: 1) some of our (jms MQ ) application sporadically experience 2195 return code. Despite numerous attempts to figure out the reasons for these rcs, it is still unclear as to what causes these rcs to occasionally appear w/out leaving any FDC files. 2) What is IBM's advised official direction for java/jms clients using both MQ v5.2 and 5.3 QMgrs? Is it to use java/jms classes that come on 5.3 CD or use the latests MA88 sp release. It would be nice to hear official IBM's response or have a pointer to a person who can provide one. 3) It looks like if JMS session to the QMgr is broken and this fact is discovered by the listener, the call to terminate this session hangs indefinitely. So this condition needs to be checked explicitly and the thread found to be in violation needs to be killed. True/false/why/fixes??? Thanks, Vitaliy __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com 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
Re: inet2 vs MQ listener (UNIX) - Answered
Justin, thanks for the background! my biggest concern with listeners has always been that they seem to 'die' at some point in time... (probably because of all the reasons listed below) and there is nothing that automatically restarts them, unlike inetd... Is there something like LISTENER KEEPALIVE(30sec or so...) in the pipeline (so the MQ checks if the listener is still alive or something. I know monitoring tools can do this too, but this is one of the basics in MQ and should be dealt with by the software itself IMHO Michael -Original Message-From: Justin Fries [mailto:[EMAIL PROTECTED]Sent: Wednesday, July 30, 2003 9:38 PMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX) - AnsweredHello, In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources--memory, threads, file descriptors--then it would not accept any new connections. This "massively threaded" approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them. On the other hand, the inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this "massively unthreaded" approach means that busy systems may have hundreds of amqcrstas, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrstas even when the queue manager is shut down. Some people work around this by disabling the MQ service(s) in inetd; Others simply turn off the execute bits on amqcrsta to avoid the need for root authority. Anybody using inetd might take a look at the script ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for a limited time only) which tries to solve this problem in a slightly more elegant way. Despite the limitations of inetd, the fact that it has no limit on the number of simultaneous connections is crucial. This is the single mark against runmqlsr, and on very busy systems it is enough to prevent people from using the listener. WebSphere MQ 5.3 removes the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa "channel pooling" processes. These amqrmppa's are threaded, but not massively so; This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa's as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager's status at all times, so it is also very quick to deny connections when the queue manager is down. The channel initiator in 5.3 also uses the amqrmppa processes, so it is now less likely to exhaust its own resources. Since runmqchi never had to contend with client connections, I think this kind of failure is relatively unheard of compared to runmqlsr running out of resources. Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] Robert Broderick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/30/2003 02:04 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX)The basics sound the same as it did in 5.2. What I recall is that around 500and above connections, for some reason, the runmqlsr's knees started to getwobbely.I am interested in this as there are discussions going on here to move torunmqlsr after upgrading to 5.3. I just wanted to know if there was somefactual data behind the recomondation. They were having the QMGR down, badapp keeps connecting and the strmqm comand cannot catch a breath problem.just want to make sure that it was a god move except for the fact that IBMinvested some money in desktime to do a little improvement.bobbeeFrom: Tom Schneider [EMAIL PROTECTED]Reply-To: MQSeries List [EMAIL PROTECTED]To: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX)Date: Wed, 30 Jul 2003 11:53:43 -0400Bobbee,The MP61 support pack has a pdf "WebSphere MQ for AIX - PerformanceEvaluations" which has some explanation. It includes a number ofcomparisons of inetd and runmqlsr performance, and compares both methodsbetween 5.2 and 5.3 as well. Section 2.2.3 of MP61 contains this text:"the 'runmqlsr' has a reduced resource utilisation (one thread perconnection vs. a process per connection for the 'inetd' listener and asmaller memory
Re: MQ JMS questions
If there are no FDC's then maybe Trace or use an API-exits logger utility (which would have to be written) to try and find out what is happening. Obviously disc will be consumed by both techniques which would need to be offset against the level of detail required. -Original Message- From: Vitaliy Ilyin [mailto:[EMAIL PROTECTED] Sent: 31 July 2003 04:20 To: [EMAIL PROTECTED] Subject: MQ JMS questions Hi everyone, I'd like to find if anybody had any problems with IBM's jms implementation on top of MQSeries. Environment: let's say we have the latest version of ma88 running on Wintel running against Sun Solaris 8 with MQ 5.3 on it. Specific questions are: 1) some of our (jms MQ ) application sporadically experience 2195 return code. Despite numerous attempts to figure out the reasons for these rcs, it is still unclear as to what causes these rcs to occasionally appear w/out leaving any FDC files. 2) What is IBM's advised official direction for java/jms clients using both MQ v5.2 and 5.3 QMgrs? Is it to use java/jms classes that come on 5.3 CD or use the latests MA88 sp release. It would be nice to hear official IBM's response or have a pointer to a person who can provide one. 3) It looks like if JMS session to the QMgr is broken and this fact is discovered by the listener, the call to terminate this session hangs indefinitely. So this condition needs to be checked explicitly and the thread found to be in violation needs to be killed. True/false/why/fixes??? Thanks, Vitaliy __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com 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
Missing Messages..
Any thoughts would be appreciated. We have a situation where MQ/ESA V1.2 on system BSYS is communicating with MQ for z/OS V5.3 on ESYS. A program was run to get about 1000 messages from BSYS and send them to a shared queue on ESYS. After the program ran, there were 994 records in the ESYS queue, and 6 messages in the BSYS queue. But when we run a program to get those records on BSYS, it indicates that there are no records in the queue on BSYS. I don't have the MQRC yet. But I wonder if there could be a unit of work problem (or other problems) because we are running such an old version of MQ on BSYS and we are using shared queues on ESYS. If so, are there any compatibility APARs that could fix this? Stewart Stewart Herd Senior Software Engineer Systems Engineering Services ACS NSC Campus Loughmahon Technology Park Cork Ireland 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
Re: inet2 vs MQ listener (UNIX) - Answered
What is needed is an automation package that can monitor the listener, and a package to monitor the monitor, and then a person to watch a screen to call the help desk when the monitor's monitor stops, and a backup for that person. Who said computers weren't labor intensive? IBM's original intention with MQ (before WMQ) was to create a robust framework with sufficient interfaces for Third Party Vendors, not to be confused with Third World Vendors, to provide the bells and whistles. Has that philosophy changed? [EMAIL PROTECTED] NK.COM To: [EMAIL PROTECTED] Sent by: cc: MQSeries List Subject: Re: inet2 vs MQ listener (UNIX) - Answered [EMAIL PROTECTED] n.AC.AT 07/31/2003 04:23 AM Please respond to MQSeries List Justin, thanks for the background! my biggest concern with listeners has always been that they seem to 'die' at some point in time... (probably because of all the reasons listed below) and there is nothing that automatically restarts them, unlike inetd... Is there something like LISTENER KEEPALIVE(30sec or so...) in the pipeline (so the MQ checks if the listener is still alive or something. I know monitoring tools can do this too, but this is one of the basics in MQ and should be dealt with by the software itself IMHO Michael -Original Message- From: Justin Fries [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 9:38 PM To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Hello, In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources--memory, threads, file descriptors--then it would not accept any new connections. This massively threaded approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them. On the other hand, the inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this massively unthreaded approach means that busy systems may have hundreds of amqcrstas, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrstas even when the queue manager is shut down. Some people work around this by disabling the MQ service(s) in inetd; Others simply turn off the execute bits on amqcrsta to avoid the need for root authority. Anybody using inetd might take a look at the script ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for a limited time only) which tries to solve this problem in a slightly more elegant way. Despite the limitations of inetd, the fact that it has no limit on the number of simultaneous connections is crucial. This is the single mark against runmqlsr, and on very busy systems it is enough to prevent people from using the listener. WebSphere MQ 5.3 removes the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa channel pooling processes. These amqrmppa's are threaded, but not massively so; This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa's as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager's status at all times, so it is also very quick to deny connections when the queue manager is down. The channel initiator in 5.3 also uses the amqrmppa processes, so it is now less likely to exhaust its own resources. Since runmqchi never had to contend with client connections, I think this kind of failure is relatively unheard of compared to runmqlsr running out of resources. Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] Robert Broderick [EMAIL PROTECTED] To: Sent by: MQSeries List [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Subject:Re:
Re: Any of you , WMQI folks checked out Crossworlds?IBM's thought???
For very little bit of transformation and if there is not much business logice and if you are looking for more poerformance then i would go for MQSI. If there needs to be hub kind of functionality and lot of business logic, much mapping needs to be done and not bothered for performance then crossworlds is the best tool.eai grp [EMAIL PROTECTED] wrote: But how do you think IBM wants to place the two products? Is CW mainly a B2B tool? Can'ntcrossworlds be used for transformation , it has a Map that does the same function?But ,Is there alimitation on the MQ Connector ,how manyqueues can a single connector poll.That is probably better with WMQI, if my application is already MQ enabled, I dont need a MQ connector in the first place! Robert Broderick [EMAIL PROTECTED] wrote: We are doing that at my current client. Crossworlds doesn't come into thepicture as the applications have a detailed business laot for timed outmessages from the branch. Crossworlds, and someone can correct me as I havenot gone down that path as of yet, offers adapters both in the physicalsense and metaphysical sense. It can give you SAP adapters and other thingsthat allow you to plug other vendor pacages into you messaging network(physical). It also, from the last time I seen the dog-and-pony show, offersa business continuity schema that allows you to coordinate a "BUSINESS"transaction. Business transaction, as we all know, can go from the simple(send a messge and get an imediate reply) or to the complicated where B2Band B2C colaborations come into effect and the transaction can span time aswell as physical locations, Meta-Physical!! So in your case you would useWMQI to transform your branch messages to something the legacy systems canunderstand and visa-versa. t can also be used to coordinate responsesbetween different backend systems. Crossworlds can be used to tie into yourCRM (SEIBEL), SAP or ACTA within your infrastructure. Crossworld couldpossibly be used to handle the situation where the messag did not get to thebranch in a respectable amount of time and the financial had to be backedout.These things are tools. Like a hammer..one day it hits a nail in, anotherday it breaks a window cause your locked out and another day you can use itto smash you neighbors head in because you caught him fooling around withyou wife. You bend and use it for want you want.bobbeeFrom: eai grp <[EMAIL PROTECTED]>Reply-To: MQSeries List <[EMAIL PROTECTED]>To: [EMAIL PROTECTED]Subject: Any of you , WMQI folks checked out Crossworlds?Date: Wed, 2 Jul 2003 12:10:30 -0700Hi All,Iam looking for a best fit product for an integration which is more likemultiple branches sending information to a central processingapplications.All branches run the same software package , differentinstances at each location ,though.And they are MQ Enabled.No process automation required , mainlytransformation.Does WMQI score well or Crossworlds??What about Scalability?Please RespondThank You-Do you Yahoo!?SBC Yahoo! DSL - Now only $29.95 per month!_Tired of spam? Get advanced junk mail protection with MSN 8.http://join.msn.com/?page=features/junkmailInstructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive Do you Yahoo!?SBC Yahoo! DSL - Now only $29.95 per month! Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Recall: Missing Messages..
The sender would like to recall the message, Missing Messages... 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
Re: MQ Process List - New Version 1.3
Dave, my notes say that amqmsrvn.exe is DCOM objects launched by amqsvc.exe amqsvc.exe is MQ Services process I have noticed that sometimes it takes a minute for this process to drop out of Task Manager once you stop the IBM MQ service. -Original Message- From: McCarty, Brian [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 4:08 PM To: [EMAIL PROTECTED] Subject: Re: MQ Process List - New Version 1.3 I am pretty sure that's the Windows Services instance of IBM MQSeries. Just issue net stop IBM MQSeries from a command line or stop the service from the GUI. I have seen it not come down if you stop all the queue managers manually first. In that case go start - run - kill pid of service. Hope that helps. B -Original Message- From: David Awerbuch [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 2:50 PM To: [EMAIL PROTECTED] Subject: Re: MQ Process List - New Version 1.3 Hello, Does anyone know what the program AMQMSRVN.EXE does on Webspehere MQ for Windows 5.3 CSD01? There is one of them running on my system right now. Thanks, Dave A. = David A. Awerbuch, IBM Certified MQSeries Specialist APC Consulting Services, Inc. Providing Automated Solutions to Business Challenges West Hempstead, NY(516) 481-6440 [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com 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
Re: inet2 vs MQ listener (UNIX)
Thank, As soon as the 13 managers I report to here go on vacation, or take a stree related holiday at the hospital I will read it. Actually, as soon as I deplete my inbox here I will download it and place it high in my to Do list. Thanks a lot for your input. It is much appreciated!! bobbee From: Tom Schneider [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) Date: Wed, 30 Jul 2003 14:57:43 -0400 Bobbee, I believe the issue with runmqlsr breaking around 500 connections was resolved in 5.3, and that this is why the recommendation about which listener to use has changed for 5.3. The MP61.pdf has quite a bit more in it about the Inetd vs. runmqlsr question than what I pasted into the previous note. -Tom == Tom Schneider / IBM Global Services (513) 274-4034 [EMAIL PROTECTED] == Robert Broderick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/30/2003 02:04 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX) The basics sound the same as it did in 5.2. What I recall is that around 500 and above connections, for some reason, the runmqlsr's knees started to get wobbely. I am interested in this as there are discussions going on here to move to runmqlsr after upgrading to 5.3. I just wanted to know if there was some factual data behind the recomondation. They were having the QMGR down, bad app keeps connecting and the strmqm comand cannot catch a breath problem. just want to make sure that it was a god move except for the fact that IBM invested some money in desktime to do a little improvement. bobbee From: Tom Schneider [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) Date: Wed, 30 Jul 2003 11:53:43 -0400 Bobbee, The MP61 support pack has a pdf WebSphere MQ for AIX - Performance Evaluations which has some explanation.It includes a number of comparisons of inetd and runmqlsr performance, and compares both methods between 5.2 and 5.3 as well. Section 2.2.3 of MP61 contains this text: the 'runmqlsr' has a reduced resource utilisation (one thread per connection vs. a process per connection for the 'inetd' listener and a smaller memory footprint), so is now the preferred method of running client channels and server channels. -Tom == Tom Schneider / IBM Global Services (513) 274-4034 [EMAIL PROTECTED] == Robert Broderick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/30/2003 09:53 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX) It lacks a reasonable explanation as to Why. bobbee From: Voges, P. (Pieter) [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) Date: Wed, 30 Jul 2003 15:18:07 +0200 http://www.developer.ibm.com/tech/faq/individual/0,,2:28060,00.html Thank you Pieter Voges MQ Support Nedcor Limited Tel: (011) 881 4410 Sel: 083 6455 300 E-mail: [EMAIL PROTECTED] http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter -Original Message- From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED] Sent: 30 July 2003 01:48 To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) Whould you mind pointing me to where I can get this link. Thanks Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert Developer IBM, Cape Town, South Africa +27 (0)82 556 9467 / +27 (0)21 402 5597 [EMAIL PROTECTED] Voges, P. (Pieter)To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: COM Subject: Re: inet2 vs MQ listener (UNIX) Sent by: MQSeries List [EMAIL PROTECTED] N.AC.AT 30/07/2003 12:30 Please respond to MQSeries List According to a link from IBM I found on their web page - Inetd is better prior to 5.3 and MQ listener is better from 5.3 Thank you Pieter Voges MQ Support Nedcor Limited Tel: (011) 881 4410 Sel: 083 6455 300 E-mail: [EMAIL PROTECTED] http://dotweb.it.nednet.co.za/link.asp?names=Voges,%20Pieter -Original Message- From: Francois Van der Merwe1 [mailto:[EMAIL PROTECTED] Sent: 30 July 2003 11:15 To: [EMAIL PROTECTED] Subject: inet2 vs MQ listener (UNIX) Is the one better than the other? Francois
Re: MQ Process List - New Version 1.3
To configure the MQSeries services to run under a different user ID, you use the AMQMSRVN command -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 31 July 2003 02:36 To: [EMAIL PROTECTED] Subject: Re: MQ Process List - New Version 1.3 Dave, my notes say that amqmsrvn.exe is DCOM objects launched by amqsvc.exe amqsvc.exe is MQ Services process I have noticed that sometimes it takes a minute for this process to drop out of Task Manager once you stop the IBM MQ service. -Original Message- From: McCarty, Brian [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 4:08 PM To: [EMAIL PROTECTED] Subject: Re: MQ Process List - New Version 1.3 I am pretty sure that's the Windows Services instance of IBM MQSeries. Just issue net stop IBM MQSeries from a command line or stop the service from the GUI. I have seen it not come down if you stop all the queue managers manually first. In that case go start - run - kill pid of service. Hope that helps. B -Original Message- From: David Awerbuch [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 2:50 PM To: [EMAIL PROTECTED] Subject: Re: MQ Process List - New Version 1.3 Hello, Does anyone know what the program AMQMSRVN.EXE does on Webspehere MQ for Windows 5.3 CSD01? There is one of them running on my system right now. Thanks, Dave A. = David A. Awerbuch, IBM Certified MQSeries Specialist APC Consulting Services, Inc. Providing Automated Solutions to Business Challenges West Hempstead, NY(516) 481-6440 [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com 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 For information about the Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. I 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
Re: inet2 vs MQ listener (UNIX) - Answered
Michael, The listener shouldn't die, period. I don't think MQ should restart dead processes in the way you suggest since that just papers over a larger problem. (One exception is amqzlwa0 which runs the optional custom-written cluster workload exit--because it runs untrusted code, MQ wll restart it if necessary.) If you do see your listener dying, call it in. Regards, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/31/2003 04:23 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: inet2 vs MQ listener (UNIX) - Answered Justin, thanks for the background! my biggest concern with listeners has always been that they seem to 'die' at some point in time... (probably because of all the reasons listed below) and there is nothing that automatically restarts them, unlike inetd... Is there something like LISTENER KEEPALIVE(30sec or so...) in the pipeline (so the MQ checks if the listener is still alive or something. I know monitoring tools can do this too, but this is one of the basics in MQ and should be dealt with by the software itself IMHO Michael -Original Message- From: Justin Fries [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 9:38 PM To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Hello, In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources--memory, threads, file descriptors--then it would not accept any new connections. This massively threaded approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them. On the other hand, the inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this massively unthreaded approach means that busy systems may have hundreds of amqcrstas, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrstas even when the queue manager is shut down. Some people work around this by disabling the MQ service(s) in inetd; Others simply turn off the execute bits on amqcrsta to avoid the need for root authority. Anybody using inetd might take a look at the script ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for a limited time only) which tries to solve this problem in a slightly more elegant way. Despite the limitations of inetd, the fact that it has no limit on the number of simultaneous connections is crucial. This is the single mark against runmqlsr, and on very busy systems it is enough to prevent people from using the listener. WebSphere MQ 5.3 removes the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa channel pooling processes. These amqrmppa's are threaded, but not massively so; This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa's as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager's status at all times, so it is also very quick to deny connections when the queue manager is down. The channel initiator in 5.3 also uses the amqrmppa processes, so it is now less likely to exhaust its own resources. Since runmqchi never had to contend with client connections, I think this kind of failure is relatively unheard of compared to runmqlsr running out of resources. Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] Robert Broderick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/30/2003 02:04 PM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX) The basics sound the same as it did in 5.2. What I recall is that around 500 and above connections, for some reason, the runmqlsr's knees started to get wobbely. I am interested in this as there are discussions going on here to move to runmqlsr after upgrading to 5.3. I just wanted to know if there was some factual data behind the recomondation. They were having the QMGR down, bad app keeps connecting and the strmqm comand cannot catch a breath problem. just want to make sure that it was a god move except for the fact that IBM invested some money in desktime to do a little improvement. bobbee From: Tom Schneider [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To:
Missing Messages
Updated , disregard previous question due to incorrect information Any thoughts would be appreciated. We have a situation where WSMQ 5.3 on system BSYS is communicating with WSMQ 5.3 on ESYS. A program was run to get about 1000 messages from BSYS and send them to a shared queue on ESYS. After the program ran, there were 994 records in the ESYS queue, and 6 messages in the BSYS queue. But when we run a program to get those records on BSYS, it indicates that there are no records in the queue on BSYS. I don't have the MQRC yet. Details to bear in mind; 1. Message flow between BSYS and ESYS does not use WebsphereMQ channels to transfer messages. 2. All messages were put with Expiry Time = Unlimited 3. WSMQ on BSYS and ESYS are at the same level of 5.3 4. After the test, inquiry of the status of the source and destination queues showed no uncommitted unit of work Stewart Stewart Herd Senior Software Engineer Systems Engineering Services ACS NSC Campus Loughmahon Technology Park Cork Ireland
Re: inet2 vs MQ listener (UNIX) - Answered
Justin, I agree and we do call IBM and we did, unfortunately one problem fixed, 10 lurking around waiting to pop-up, inetd has proven to be more stable for us. Same goes for channels (which I consider oneof the key things of MQ) problems, why have things like DISCINT,HBINT or KAINT, when everything works as it is supposed to? Michael -Original Message-From: Justin Fries [mailto:[EMAIL PROTECTED]Sent: Thursday, July 31, 2003 2:49 PMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX) - AnsweredMichael, The listener shouldn't die, period. I don't think MQ should restart dead processes in the way you suggest since that just papers over a larger problem. (One exception is amqzlwa0 which runs the optional custom-written cluster workload exit--because it runs untrusted code, MQ wll restart it if necessary.) If you do see your listener dying, call it in. Regards, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/31/2003 04:23 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX) - AnsweredJustin,thanks for the background!my biggest concern with listeners has always been that they seem to 'die' atsome point in time... (probably because of all the reasons listed below) andthere is nothing that automatically restarts them, unlike inetd...Is there something like LISTENER KEEPALIVE(30sec or so...) in the pipeline(so the MQ checks if the listener is still alive or something.I know monitoring tools can do this too, but this is one of the basics in MQand should be dealt with by the software itself IMHOMichael-Original Message-From: Justin Fries [mailto:[EMAIL PROTECTED]Sent: Wednesday, July 30, 2003 9:38 PMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX) - AnsweredHello, In MQSeries 5.2 and previous releases, runmqlsr ran each inboundconnection as a new thread within itself. If runmqlsr ran out ofresources--memory, threads, file descriptors--then it would not accept anynew connections. This "massively threaded" approach worked well on systemswith a limited number of channels, but on very busy systems it was necessaryto set up multiple listeners and balance connections across them. On the other hand, the inetd daemon starts a new amqcrsta processfor each inbound connection. There is no chance an amqcrsta responsible foronly one channel will run out of resources, so even the busiest of queuemanagers requires only a single port in inetd. However, this "massivelyunthreaded" approach means that busy systems may have hundreds of amqcrstas,forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it willstart amqcrstas even when the queue manager is shut down. Some people workaround this by disabling the MQ service(s) in inetd; Others simply turn offthe execute bits on amqcrsta to avoid the need for root authority. Anybodyusing inetd might take a look at the scriptftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for alimited time only) which tries to solve this problem in a slightly moreelegant way. Despite the limitations of inetd, the fact that it has no limit onthe number of simultaneous connections is crucial. This is the single markagainst runmqlsr, and on very busy systems it is enough to prevent peoplefrom using the listener. WebSphere MQ 5.3 removes the listener scalability problem once andfor all. Rather than running each inbound connection as a thread withinitself, runmqlsr now passes connections to one of the amqrmppa "channelpooling" processes. These amqrmppa's are threaded, but not massively so;This means they do not exhaust per-process resources or force administratorsto increase maxuproc. The listener will start new amqrmppa's as needed, soa single listener can now handle an unbounded number of connections. Thelistener is aware of the queue manager's status at all times, so it is alsovery quick to deny connections when the queue manager is down. The channel initiator in 5.3 also uses the amqrmppa processes, so itis now less likely to exhaust its own resources. Since runmqchi never hadto contend with client connections, I think this kind of failure isrelatively unheard of compared to runmqlsr running out of resources. Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] Robert Broderick [EMAIL PROTECTED]Sent by: MQSeries List [EMAIL PROTECTED]07/30/2003 02:04 PMPlease respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: inet2 vs MQ listener (UNIX)The basics sound the same as it did in 5.2. What I
Re: Missing Messages
Sounds Like you still have an active resource connected to that queue. I have seen this in the windows world but not on the 390 world. Worth a shot though. Dave -Original Message- From: Herd, Stewart [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 8:51 AM To: [EMAIL PROTECTED] Subject: Missing Messages Updated , disregard previous question due to incorrect information Any thoughts would be appreciated. We have a situation where WSMQ 5.3 on system BSYS is communicating with WSMQ 5.3 on ESYS. A program was run to get about 1000 messages from BSYS and send them to a shared queue on ESYS. After the program ran, there were 994 records in the ESYS queue, and 6 messages in the BSYS queue. But when we run a program to get those records on BSYS, it indicates that there are no records in the queue on BSYS. I don't have the MQRC yet. Details to bear in mind; 1. Message flow between BSYS and ESYS does not use WebsphereMQ channels to transfer messages. 2. All messages were put with Expiry Time = Unlimited 3. WSMQ on BSYS and ESYS are at the same level of 5.3 4. After the test, inquiry of the status of the source and destination queues showed no uncommitted unit of work Stewart Stewart Herd Senior Software Engineer Systems Engineering Services ACS NSC Campus Loughmahon Technology Park Cork Ireland 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
Re: inet2 vs MQ listener (UNIX) - Answered
Michael, Channel parameters like DISCINT, HBINT, KAINT, etc. are intended to work around problems with networks, which will always be with us (unless someone invents a perfect network that never fails--if so, let me in on your IPO). If you're running MQ 5.2, you should find the 5.3 listener more stable since it has much less work to do--just listen() on a socket, accept() a connection, and give it to amqrmppa to handle. Which version of MQ are you running? You can set up runmqlsr to run out of inittab with the 'respawn' option. This would restart it in the way you desire (although I would still call service if you find it terminating for any reason). Just edit /etc/inittab and run 'telinit q' to force init to reread the file. One downside is that you will need root authority to stop the listener, unless you just turn off its execute bits (although I'm not sure how init will react to that). Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/31/2003 09:23 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: inet2 vs MQ listener (UNIX) - Answered Justin, I agree and we do call IBM and we did, unfortunately one problem fixed, 10 lurking around waiting to pop-up, inetd has proven to be more stable for us. Same goes for channels (which I consider one of the key things of MQ) problems, why have things like DISCINT, HBINT or KAINT, when everything works as it is supposed to? Michael -Original Message- From: Justin Fries [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 2:49 PM To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Michael, The listener shouldn't die, period. I don't think MQ should restart dead processes in the way you suggest since that just papers over a larger problem. (One exception is amqzlwa0 which runs the optional custom-written cluster workload exit--because it runs untrusted code, MQ wll restart it if necessary.) If you do see your listener dying, call it in. Regards, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED]
Re: MQ 5.3 on Sun Solaris 9
Ian, Yes, Solaris 9 is a certified platform by IBM for WebSphere MQ 5.3 -Original Message- From: Chan, Ian M [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 9:49 PM To: [EMAIL PROTECTED] Subject: MQ 5.3 on Sun Solaris 9 Hi all, I remembered someone asked that before but there was no answer. Does anyone know whether MQ 5.3 can run under Solaris 9? The latest quick beginning guide is still mentioning Solaris 7 and 8 only. Or does anyone tested such combination? Thanks, Ian 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 * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 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
Re: Design Review - custom trigger monitor vs triggered program
Pavel Maybe I'm just being a little think here, but I'm not understanding how removing our dead letter queues would help these situations that you mention. First of I'm leaving message order out of the picture because that agreed is a holy war I don't want to get into. Secondly I agree that you certainly have issues to deal with managing the dead queue and the messages that land there. However it seems to me that you have far more issues to deal with if you do not allow the queue manager to use a dead queue. If you are referring to application writing to the dead queue, I agree I would not endorse using a dead queue as an applications poison/retry queue. That would be best for that business logic to deal with on their own queues. But the queue manage is a nother story. I would never run a queue manager without a dead queue. I have no desire to be called at all hours because one application messed up the whole channel. Without a dead queue for the queue manager to route undeliverable messages, what processes are you going to need in place to keep your channels and XMIT queues healthy and functioning? I certainly don't want business logic messing with my XMIT queues. I also would be no more pleased to go searching all the XMIT queues (talk about security policies) for a particular messaging problem, than I would be to have to find it in the dead queues. I know I'd rather have the errant message dumped into the dead queue and the rest of the good messages be transmitted. (I know of no business unit that will accept the other guys program has a problem as an excuse for why their production applications can't run.) At least there are plenty of usable dead letter handlers out there that can be configured to resolve or route messages off the dead queue. If messages are stuck in the XMIT queue on the other hand, then you've got real problems and I know of no automated process that is going to save you. As for other asynchronous message systems, I'm curious how they assure message delivery and keep the channels between servers open and flowing freely without something similar on one end or the other. Rick |-+--- | | Pavel Tolkachev | | | [EMAIL PROTECTED]| | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Wednesday July 30, 2003 10:46 AM| | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Design Review - custom trigger monitor vs triggered program | | Hello Dave, Well, it is almost religious thing, so I was hesitant to touch the theme. But if you ask :-): 1. It breaks the default message order guarantees MQ series normally provides. 2. It requires handling, and because, after the close look, each application has slightly different requirements to handle it, it turns our that 2 must be developed instead of one for each task: one to process the normal flow and another to process messages from dead letter. And handlers must be worked out in terms of security and other application management issues. Considering the policy for actioning on nondeliverable messages a part of business logic seems more appropriate to me. 3. When using distributed messaging, you may have a nice encounter every time a user compains his/her application did not receive some particular message you may have to search for it in dead letter queues (read trush cans :-) ) across the globe -- breaking all security policies on your way etc.. 4. DLQ does not have analogs in other messaging systems I have to use, so using it reduces interoperability and portability of the software and (business) processes -- if you use it. Hopefully, this won't start another holy war.. This is just my opinion, very humble, and I am in no way MQ expert. Just take it as another weird thing I heard if you feel strongly disagree. Pavel David C. PartridgeTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc:
Re: MQ 5.3 on Sun Solaris 9 - Link to Supported Software Web Page
Hello, This web page contains the latest details on support software for MQ (and related products). When in doubt, check here for updates that have not yet made it into the MQ manuals: http://www-3.ibm.com/software/integration/websphere/mqplatforms/supported.html Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] Zovko, Tom [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/31/2003 10:10 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: MQ 5.3 on Sun Solaris 9 Ian, Yes, Solaris 9 is a certified platform by IBM for WebSphere MQ 5.3 -Original Message- From: Chan, Ian M [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 9:49 PM To: [EMAIL PROTECTED] Subject: MQ 5.3 on Sun Solaris 9 Hi all, I remembered someone asked that before but there was no answer. Does anyone know whether MQ 5.3 can run under Solaris 9? The latest quick beginning guide is still mentioning Solaris 7 and 8 only. Or does anyone tested such combination? Thanks, Ian 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 * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 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
Re: inet2 vs MQ listener (UNIX) - Answered
Does anyone have the EMAIL with the boulder link for the INETD amqcrsta alternate approach. I mistakenly deleted it befor capturing it. Could you repost it. thnaks bobbee From: [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Date: Thu, 31 Jul 2003 15:23:53 +0200 Justin, I agree and we do call IBM and we did, unfortunately one problem fixed, 10 lurking around waiting to pop-up, inetd has proven to be more stable for us. Same goes for channels (which I consider one of the key things of MQ) problems, why have things like DISCINT, HBINT or KAINT, when everything works as it is supposed to? Michael -Original Message- From: Justin Fries [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 2:49 PM To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Michael, The listener shouldn't die, period. I don't think MQ should restart dead processes in the way you suggest since that just papers over a larger problem. (One exception is amqzlwa0 which runs the optional custom-written cluster workload exit--because it runs untrusted code, MQ wll restart it if necessary.) If you do see your listener dying, call it in. Regards, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/31/2003 04:23 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX) - Answered Justin, thanks for the background! my biggest concern with listeners has always been that they seem to 'die' at some point in time... (probably because of all the reasons listed below) and there is nothing that automatically restarts them, unlike inetd... Is there something like LISTENER KEEPALIVE(30sec or so...) in the pipeline (so the MQ checks if the listener is still alive or something. I know monitoring tools can do this too, but this is one of the basics in MQ and should be dealt with by the software itself IMHO Michael -Original Message- From: Justin Fries [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 9:38 PM To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Hello, In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources--memory, threads, file descriptors--then it would not accept any new connections. This massively threaded approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them. On the other hand, the inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this massively unthreaded approach means that busy systems may have hundreds of amqcrstas, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrstas even when the queue manager is shut down. Some people work around this by disabling the MQ service(s) in inetd; Others simply turn off the execute bits on amqcrsta to avoid the need for root authority. Anybody using inetd might take a look at the script ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for a limited time only) which tries to solve this problem in a slightly more elegant way. Despite the limitations of inetd, the fact that it has no limit on the number of simultaneous connections is crucial. This is the single mark against runmqlsr, and on very busy systems it is enough to prevent people from using the listener. WebSphere MQ 5.3 removes the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa channel pooling processes. These amqrmppa's are threaded, but not massively so; This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa's as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager's status at all times, so it is also very quick to deny connections when the queue manager is down. The channel initiator in 5.3 also uses the amqrmppa processes, so it is now less likely to exhaust its own resources. Since runmqchi never had to contend with client connections, I think this kind of failure is relatively unheard of compared to runmqlsr running out of resources.
Re: inet2 vs MQ listener (UNIX) - Answered
For B oh double-b egh... -Original Message-From: Justin Fries [mailto:[EMAIL PROTECTED]Sent: Wednesday, July 30, 2003 3:38 PMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX) - AnsweredHello, In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources--memory, threads, file descriptors--then it would not accept any new connections. This "massively threaded" approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them. On the other hand, the inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this "massively unthreaded" approach means that busy systems may have hundreds of amqcrstas, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrstas even when the queue manager is shut down. Some people work around this by disabling the MQ service(s) in inetd; Others simply turn off the execute bits on amqcrsta to avoid the need for root authority. Anybody using inetd might take a look at the script ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for a limited time only) which tries to solve this problem in a slightly more elegant way. Despite the limitations of inetd, the fact that it has no limit on the number of simultaneous connections is crucial. This is the single mark against runmqlsr, and on very busy systems it is enough to prevent people from using the listener. WebSphere MQ 5.3 removes the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa "channel pooling" processes. These amqrmppa's are threaded, but not massively so; This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa's as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager's status at all times, so it is also very quick to deny connections when the queue manager is down. The channel initiator in 5.3 also uses the amqrmppa processes, so it is now less likely to exhaust its own resources. Since runmqchi never had to contend with client connections, I think this kind of failure is relatively unheard of compared to runmqlsr running out of resources. Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] Robert Broderick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/30/2003 02:04 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX)The basics sound the same as it did in 5.2. What I recall is that around 500and above connections, for some reason, the runmqlsr's knees started to getwobbely.I am interested in this as there are discussions going on here to move torunmqlsr after upgrading to 5.3. I just wanted to know if there was somefactual data behind the recomondation. They were having the QMGR down, badapp keeps connecting and the strmqm comand cannot catch a breath problem.just want to make sure that it was a god move except for the fact that IBMinvested some money in desktime to do a little improvement.bobbeeFrom: Tom Schneider [EMAIL PROTECTED]Reply-To: MQSeries List [EMAIL PROTECTED]To: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX)Date: Wed, 30 Jul 2003 11:53:43 -0400Bobbee,The MP61 support pack has a pdf "WebSphere MQ for AIX - PerformanceEvaluations" which has some explanation. It includes a number ofcomparisons of inetd and runmqlsr performance, and compares both methodsbetween 5.2 and 5.3 as well. Section 2.2.3 of MP61 contains this text:"the 'runmqlsr' has a reduced resource utilisation (one thread perconnection vs. a process per connection for the 'inetd' listener and asmaller memory footprint), so is now the preferred method of runningclient channels and server channels."-Tom==Tom Schneider / IBM Global Services(513) 274-4034[EMAIL PROTECTED]==Robert Broderick [EMAIL PROTECTED]Sent by: MQSeries List [EMAIL PROTECTED]07/30/2003 09:53 AMPlease respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: inet2 vs MQ listener (UNIX)It lacks a
Re: inet2 vs MQ listener (UNIX) - Answered
ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 11:36 AM To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Does anyone have the EMAIL with the boulder link for the INETD amqcrsta alternate approach. I mistakenly deleted it befor capturing it. Could you repost it. thnaks bobbee From: [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Date: Thu, 31 Jul 2003 15:23:53 +0200 Justin, I agree and we do call IBM and we did, unfortunately one problem fixed, 10 lurking around waiting to pop-up, inetd has proven to be more stable for us. Same goes for channels (which I consider one of the key things of MQ) problems, why have things like DISCINT, HBINT or KAINT, when everything works as it is supposed to? Michael -Original Message- From: Justin Fries [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 2:49 PM To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Michael, The listener shouldn't die, period. I don't think MQ should restart dead processes in the way you suggest since that just papers over a larger problem. (One exception is amqzlwa0 which runs the optional custom-written cluster workload exit--because it runs untrusted code, MQ wll restart it if necessary.) If you do see your listener dying, call it in. Regards, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/31/2003 04:23 AM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX) - Answered Justin, thanks for the background! my biggest concern with listeners has always been that they seem to 'die' at some point in time... (probably because of all the reasons listed below) and there is nothing that automatically restarts them, unlike inetd... Is there something like LISTENER KEEPALIVE(30sec or so...) in the pipeline (so the MQ checks if the listener is still alive or something. I know monitoring tools can do this too, but this is one of the basics in MQ and should be dealt with by the software itself IMHO Michael -Original Message- From: Justin Fries [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 9:38 PM To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Hello, In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources--memory, threads, file descriptors--then it would not accept any new connections. This massively threaded approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them. On the other hand, the inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this massively unthreaded approach means that busy systems may have hundreds of amqcrstas, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrstas even when the queue manager is shut down. Some people work around this by disabling the MQ service(s) in inetd; Others simply turn off the execute bits on amqcrsta to avoid the need for root authority. Anybody using inetd might take a look at the script ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for a limited time only) which tries to solve this problem in a slightly more elegant way. Despite the limitations of inetd, the fact that it has no limit on the number of simultaneous connections is crucial. This is the single mark against runmqlsr, and on very busy systems it is enough to prevent people from using the listener. WebSphere MQ 5.3 removes the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa channel pooling processes. These amqrmppa's are threaded, but not massively so; This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa's as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager's status at all times, so it is also very quick to deny connections when the queue manager is
Re: inet2 vs MQ listener (UNIX) - Answered
Justin: Nice input... However, has there been any thought to using both inetd and runmqlsr.Maybe keep the inetd for channels between QMgrs and runmqlsr for client connections. I liked an earlier comment by "separating your eggs from 1 basket". There was once a support pack -- I've lost the reference andbelieve IBM has pulled it -- using the AgentClassMap and AgentClassLimitTuningParameter stanza parameters that addressedseparation of connections. -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -Original Message-From: Justin Fries [mailto:[EMAIL PROTECTED]Sent: Wednesday, July 30, 2003 3:38 PMTo: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX) - AnsweredHello, In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources--memory, threads, file descriptors--then it would not accept any new connections. This "massively threaded" approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them. On the other hand, the inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this "massively unthreaded" approach means that busy systems may have hundreds of amqcrstas, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrstas even when the queue manager is shut down. Some people work around this by disabling the MQ service(s) in inetd; Others simply turn off the execute bits on amqcrsta to avoid the need for root authority. Anybody using inetd might take a look at the script ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for a limited time only) which tries to solve this problem in a slightly more elegant way. Despite the limitations of inetd, the fact that it has no limit on the number of simultaneous connections is crucial. This is the single mark against runmqlsr, and on very busy systems it is enough to prevent people from using the listener. WebSphere MQ 5.3 removes the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa "channel pooling" processes. These amqrmppa's are threaded, but not massively so; This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa's as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager's status at all times, so it is also very quick to deny connections when the queue manager is down. The channel initiator in 5.3 also uses the amqrmppa processes, so it is now less likely to exhaust its own resources. Since runmqchi never had to contend with client connections, I think this kind of failure is relatively unheard of compared to runmqlsr running out of resources. Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] Robert Broderick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/30/2003 02:04 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX)The basics sound the same as it did in 5.2. What I recall is that around 500and above connections, for some reason, the runmqlsr's knees started to getwobbely.I am interested in this as there are discussions going on here to move torunmqlsr after upgrading to 5.3. I just wanted to know if there was somefactual data behind the recomondation. They were having the QMGR down, badapp keeps connecting and the strmqm comand cannot catch a breath problem.just want to make sure that it was a god move except for the fact that IBMinvested some money in desktime to do a little improvement.bobbeeFrom: Tom Schneider [EMAIL PROTECTED]Reply-To: MQSeries List [EMAIL PROTECTED]To: [EMAIL PROTECTED]Subject: Re: inet2 vs MQ listener (UNIX)Date: Wed, 30 Jul 2003 11:53:43 -0400Bobbee,The MP61 support pack has a pdf "WebSphere MQ for AIX - PerformanceEvaluations" which has some explanation. It includes a number ofcomparisons of inetd and runmqlsr performance, and compares both methodsbetween 5.2 and 5.3 as well. Section 2.2.3 of MP61 contains this text:"the 'runmqlsr' has a reduced resource utilisation (one thread perconnection vs. a process per connection for the
MQ Oracle Support
Hi!, some applications wrote with Oracle Developer 6 needs to be connected to MQSeries 5.3. This aplications are on AIX 4.3.3, 5.1.L and Windows 2000 Server. I need to know what are the possibilities to do that? MA0I SupportPac, JAVA or VB modules called by procedures calls, etc. We appreciate all your help! Thanks and regards, Luis Garro Muñoz Soluciones y Servicios GBM de Costa Rica e-mail: [EMAIL PROTECTED] Tel: (506)2843999 ext 6216 Cel: (506)8343647 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
Issue with JMS on AS400
Hi All, We are trying to execute JMS programs in AS400 QShell. We are facing the following issue, any help or leads will be helpful. MQSeries 5.2 is installed. JDK 1.3.1 JMS(ma88) is applied We have to execute java program for MQ from QShell few times. we are getting error. we have doubted some environment problems. So we have executed the installation verification program. We are executing verification test for MQ installation from QShell. We are excecuting the MQIVP program supplied with MA88. (/qibm/proddata/mqm/java/samples/base) $ java MQIVP The program completes successfully. Again we are trying to execute the same program in the same Q Shell. we are getting the following error. java MQIVP -trace 5 04:33:41 [1059669221454] Thread: Thread-0, Object: com.ibm.mq.MQQueueManager@ beb982d5 == MQManagedObject constructor() entry 04:33:41 [1059669221587] Thread: Thread-0, Object: com.ibm.mq.MQQueueManage [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] @(#) common/javabase/com/ibm/mq/MQManagedObject.java, java, j520, j520-L010613 01/04/26 10:28:31 04:33:41 [1059669221591] Thread: Thread-0, Object: com.ibm.mq.MQQueueManager@ beb982d5 == MQManagedObject constructor() exit 04:33:41 [1059669221592] Thread: Thread-0, Object: com.ibm.mq.MQQueueManager@ beb982d5 == MQQueueManager constructor (String,Hashtable)() entry 04:33:41 [1059669221592] Thread: Thread-0, Object: com.ibm.mq.MQQueueManage [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] common/javabase/com/ibm/mq/MQQueueManager.java, java, j520, j520-L 010720 01/07/20 16:27:50 @(#) 1.41.1.7 04:33:41 [1059669221597] Thread: Thread-0, Object: com.ibm.mq.MQQueueManage [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == construct() entry 04:33:41 [1059669221605] Thread: Thread-0 == MQQueueManager::obtainBaseM QQueueManager (Java 1.1 version() entry 04:33:41 [1059669221625] Thread: Thread-0, Object: com.ibm.mq.MQBinding [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == MQBindingsManagedConnectionFactoryJ 11 constructor() entry 04:33:41 [1059669221629] Thread: Thread-0, Object: com.ibm.mq.MQBinding [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == MQBindingsManagedConnectionFactoryJ 11 constructor() exit 04:33:41 [1059669221635] Thread: Thread-0 == Uninitialized object::Bin dingsConnectionRequestInfo constructor() entry 04:33:41 [1059669221651] Thread: Thread-0, Object: com.ibm.mq.BindingsC [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == BindingsConnectionRequestInfo constructor() exit 04:33:41 [1059669221665] Thread: Thread-0, Object: com.ibm.mq.MQSimpleC [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == allocateConnection() entry 04:33:41 [1059669221674] Thread: Thread-0, Object: com.ibm.mq.Managed [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == chooseOne() entry 04:33:41 [1059669221676] Thread: Thread-0, Object: com.ibm.mq.Managed [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == chooseOne() exit 04:33:41 [1059669221681] Thread: Thread-0, Object: com.ibm.mq.StoredM [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == StoredManagedConnection constructor() entry 04:33:41 [1059669221697] Thread: Thread-0, Object: com.ibm.mq.MQBin [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == _createManagedConnection() entr y 04:33:41 [1059669221719] Thread: Thread-0, Object: com.ibm.mq.MQM [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == MQManagedConnection constructor() entry 04:33:41 [1059669221750] Thread: Thread-0 Class: MQSESSIONServe r getMQSESSION() - retrieving MQSESSION... 04:33:41 [1059669221758] Thread: Thread-0 == MQSESSION::getLib raryName() entry 04:33:41 [1059669221758] Thread: Thread-0 == MQSESSION::getLib raryName() exit 04:33:41 [1059669221782] Thread: Thread-0, Object: com.ibm.mq.s [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == setThreadAccess() entry 04:33:41 [1059669221782] Thread: Thread-0 == MQSESSION::getL ibraryName() entry 04:33:41 [1059669221782] Thread: Thread-0 == MQSESSION::getL ibraryName() exit 04:33:41 [1059669221782] Thread: Thread-0, Object: com.ibm.mq [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Thread switch enabled 04:33:41 [1059669221782] Thread: Thread-0, Object: com.ibm.mq.s [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == setThreadAccess() exit 04:33:41 [1059669221817] Thread: Thread-0, Object: com.ibm.mq.s [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] == MQCONN() entry 04:33:41 [1059669221817] Thread: Thread-0, Object: com.ibm.mq [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] common/javabase/com/ibm/mq/server/MQSESSION.java, java, j520, j520-L010802.1 01/07/30 16:27:40 @(#) 1.29.1.4 04:33:41 [1059669221817] Thread: Thread-0, Object: com.ibm.mq [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Queue Manager = '' FATAL ERROR in native method: Try to invoke an instance method as a static me thod com/ibm/mq/server/MQThread.run()V+0 (MQThread.java:981) Thanks Gaurav Mittal ___ EAI Consultant Wipro Technologies (612)-291-4551 (W) Instructions for managing your mailing list subscription are provided in
Re: inet2 vs MQ listener (UNIX) - Answered
OK this is s.h.i.t-4.brains bobbee. I had that EMAIL. Like ALL good EMAILs I save them to a document called MQSERIES_Discussions.doc. This document has gotten me outta a lot of problems. As I said I save it and scanned it quickly and didn't see that info. So I greatly appreciate the reply. Which made me reflect on the brain matter composition! bobbee From: Wyatt, T. Rob [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Date: Thu, 31 Jul 2003 08:50:19 -0700 For B oh double-b egh... -Original Message- From: Justin Fries [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 3:38 PM To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) - Answered Hello, In MQSeries 5.2 and previous releases, runmqlsr ran each inbound connection as a new thread within itself. If runmqlsr ran out of resources--memory, threads, file descriptors--then it would not accept any new connections. This massively threaded approach worked well on systems with a limited number of channels, but on very busy systems it was necessary to set up multiple listeners and balance connections across them. On the other hand, the inetd daemon starts a new amqcrsta process for each inbound connection. There is no chance an amqcrsta responsible for only one channel will run out of resources, so even the busiest of queue managers requires only a single port in inetd. However, this massively unthreaded approach means that busy systems may have hundreds of amqcrstas, forcing administrators to increase maxuproc. Inetd has no idea when the queue manager is inactive, so it will start amqcrstas even when the queue manager is shut down. Some people work around this by disabling the MQ service(s) in inetd; Others simply turn off the execute bits on amqcrsta to avoid the need for root authority. Anybody using inetd might take a look at the script ftp://testcase.boulder.ibm.com/ts/fromibm/mqseries/amqcrsta.ksh (there for a limited time only) which tries to solve this problem in a slightly more elegant way. Despite the limitations of inetd, the fact that it has no limit on the number of simultaneous connections is crucial. This is the single mark against runmqlsr, and on very busy systems it is enough to prevent people from using the listener. WebSphere MQ 5.3 removes the listener scalability problem once and for all. Rather than running each inbound connection as a thread within itself, runmqlsr now passes connections to one of the amqrmppa channel pooling processes. These amqrmppa's are threaded, but not massively so; This means they do not exhaust per-process resources or force administrators to increase maxuproc. The listener will start new amqrmppa's as needed, so a single listener can now handle an unbounded number of connections. The listener is aware of the queue manager's status at all times, so it is also very quick to deny connections when the queue manager is down. The channel initiator in 5.3 also uses the amqrmppa processes, so it is now less likely to exhaust its own resources. Since runmqchi never had to contend with client connections, I think this kind of failure is relatively unheard of compared to runmqlsr running out of resources. Cheers, Justin T. Fries WebSphere MQ Support Raleigh, North Carolina Email: [EMAIL PROTECTED] Robert Broderick [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/30/2003 02:04 PM Please respond to MQSeries List To:[EMAIL PROTECTED] cc: Subject:Re: inet2 vs MQ listener (UNIX) The basics sound the same as it did in 5.2. What I recall is that around 500 and above connections, for some reason, the runmqlsr's knees started to get wobbely. I am interested in this as there are discussions going on here to move to runmqlsr after upgrading to 5.3. I just wanted to know if there was some factual data behind the recomondation. They were having the QMGR down, bad app keeps connecting and the strmqm comand cannot catch a breath problem. just want to make sure that it was a god move except for the fact that IBM invested some money in desktime to do a little improvement. bobbee From: Tom Schneider [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: inet2 vs MQ listener (UNIX) Date: Wed, 30 Jul 2003 11:53:43 -0400 Bobbee, The MP61 support pack has a pdf WebSphere MQ for AIX - Performance Evaluations which has some explanation.It includes a number of comparisons of inetd and runmqlsr performance, and compares both methods between 5.2 and 5.3 as well. Section 2.2.3 of MP61 contains this text: the 'runmqlsr' has a reduced resource utilisation (one thread per connection vs. a process per connection for the 'inetd' listener and a smaller memory
Re: Java class hangs when using AIX Runmqtrm
We had similar problem. Add the following line to your script just before you call your java app. JAVA_COMPILER=NONE Thank You Lail S. Hossain-Original Message-From: Troy Wells [mailto:[EMAIL PROTECTED]Sent: Monday, June 30, 2003 6:51 PMTo: [EMAIL PROTECTED]Subject: Java class hangs when using AIX Runmqtrm Hi all. We currently have MQSeries 5.3 installed on an AIX 5.2 box. Wehave developed a Java class that reads a message (which is in XML format)and parses the message (using xmlj4) for inserting into an Oracle database.On the AIX system, we have created a process definition with anapplicationid of a unix ksh script that sets up all classpaths, etc and thenstarts the java class. What we have found is that when we run the scriptmanually (logged on as mqm), the java application works correctly; however,when we allow the trigger monitor to start the script/java class, the classhangs at the program line that creates the DOMParser object (DOMParserparser = new DOMParser()). In addition, the class is not throwing any sortof exception. Also the trigger monitor stops processing any initq messagesunless will kill the java process. We have compared the environments (using'env') in both cases (manual vs triggered) and both are exacly the same.In addition, the same java class runs correctly when triggered in a Windows2000 environment. Appears to be something specific when triggering on theAIX environment.Does anyone have any suggestions? Regards, Troy Wells Do you Yahoo!?SBC Yahoo! DSL - Now only $29.95 per month!
HP-UX 64 bit and WebSphere MQ 5.3
We are working on a HP-UX system running 64 bit. The WMQ documentation mentions it is a 32 bit version but there is a support pac that updates it to 64 bit version of WMQ v5.3. Has anyone experimented with this before? Will WMQ 32 bit work well with the 64 bit version of HP-UX? Is one 32/64 bit preferred with respect to the 64 bit version of the OS? We have also heard that after 2004, IBM will no longer support AIX and HP-UX, is this true? Jeff Tressler 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
Re: HP-UX 64 bit and WebSphere MQ 5.3
Jeff, I just installed MQ V5.3 on HP-UX running in 64 bit mode. MQ will run in 32 bit mode even though the OS is in 64 bit mode. As for IBM no longer supporting HP-UX and AIX after 2004, it's news to me. What's your source? Jeff A Tressler [EMAIL PROTECTED] To: [EMAIL PROTECTED] M cc: Sent by: Subject: HP-UX 64 bit and WebSphere MQ 5.3 MQSeries List [EMAIL PROTECTED] en.AC.AT 07/31/2003 03:21 PM Please respond to MQSeries List We are working on a HP-UX system running 64 bit. The WMQ documentation mentions it is a 32 bit version but there is a support pac that updates it to 64 bit version of WMQ v5.3. Has anyone experimented with this before? Will WMQ 32 bit work well with the 64 bit version of HP-UX? Is one 32/64 bit preferred with respect to the 64 bit version of the OS? We have also heard that after 2004, IBM will no longer support AIX and HP-UX, is this true? Jeff Tressler 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
Re: Design Review - custom trigger monitor vs triggered program
I agree. Without a DLQ, you risk channels shutting down, trigger monitors stopping, and other undesireable side-effects in the event of mis-behaving applications, networks, and opertors. Now I would not recommend designing an application around the DLQ, but it's good to have it there as a last-gasp safeguard to keep messages flowing when something goes south. The goal would be to make appearances in the DLQ a rarity. When a message shows up there, the alerts go out as it signals a problem that needs to be fixed. Better to have the DLQ as a cushion so messages can keep flowing while the problem is being chased. The notion of poking around in DLQ's for lost messages is backwards. A message in the DLQ should be regarded as a found problem not a lost message. -Original Message- From: Richard Brunette [SMTP:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 7:31 AM To: [EMAIL PROTECTED] Subject: Re: Design Review - custom trigger monitor vs triggered program Pavel Maybe I'm just being a little think here, but I'm not understanding how removing our dead letter queues would help these situations that you mention. First of I'm leaving message order out of the picture because that agreed is a holy war I don't want to get into. Secondly I agree that you certainly have issues to deal with managing the dead queue and the messages that land there. However it seems to me that you have far more issues to deal with if you do not allow the queue manager to use a dead queue. If you are referring to application writing to the dead queue, I agree I would not endorse using a dead queue as an applications poison/retry queue. That would be best for that business logic to deal with on their own queues. But the queue manage is a nother story. I would never run a queue manager without a dead queue. I have no desire to be called at all hours because one application messed up the whole channel. Without a dead queue for the queue manager to route undeliverable messages, what processes are you going to need in place to keep your channels and XMIT queues healthy and functioning? I certainly don't want business logic messing with my XMIT queues. I also would be no more pleased to go searching all the XMIT queues (talk about security policies) for a particular messaging problem, than I would be to have to find it in the dead queues. I know I'd rather have the errant message dumped into the dead queue and the rest of the good messages be transmitted. (I know of no business unit that will accept the other guys program has a problem as an excuse for why their production applications can't run.) At least there are plenty of usable dead letter handlers out there that can be configured to resolve or route messages off the dead queue. If messages are stuck in the XMIT queue on the other hand, then you've got real problems and I know of no automated process that is going to save you. As for other asynchronous message systems, I'm curious how they assure message delivery and keep the channels between servers open and flowing freely without something similar on one end or the other. Rick |-+--- | | Pavel Tolkachev | | | [EMAIL PROTECTED]| | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Wednesday July 30, 2003 10:46 AM| | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Design Review - custom trigger monitor vs triggered program | | Hello Dave, Well, it is almost religious thing, so I was hesitant to touch the theme. But if you ask :-): 1. It breaks the default message order guarantees MQ series normally provides. 2. It requires handling, and because, after the close look, each application has slightly different requirements to handle it, it turns our that 2 must be developed instead of one for each task: one to process the normal flow and another to process messages from dead letter. And handlers must
