Re: MQGet Blocked Read
I think Steve is saying that he's stopping only his *application*, not MQ... -Will At 09:23 PM Sunday 8/3/2003, Tim Armstrong wrote: Sorry must be misinterpreting what your problem is. When you stop MQ via the SCM it stops your queue managers i.e. issues an internal endmqm MYQMGR if you have MQGMO_FAIL_IF_QUIESCING coded then you should not time out as your MQGET will fail with RC=2161 in your app which can then gracefully exit. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: Re: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 04/08/2003 14:00 Please respond to MQSeries List Tim, Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is shutting down. That's not the problem. The problem is terminating a WIN32 Client service gracefully when the service is in a blocked MQGET read. It appears there isn't any way except to wait or issue a ::TerminateThread which works but generates a ton of memory leaks. It would be nice if IBM would code an event handle that could be included as a parameter when issuing a MQGET. Then when signaled the MQGET would return out of the read. Another alternative is simply to PUT a message onto the GET queue prior to shutdown. This will break the blocked MQGET read as a message is readily available. I'm looking at that method as the best means of gracefully shutting down. However, I don't know how well that method will be received since I'm only supposed to be receiving messages from that queue. Therefore the hunt for an additional solution goes on Thanks for the reply! Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim Armstrong Sent: Sunday, August 03, 2003 8:47 PM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the MQOO_ equivalent etc. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 03/08/2003 08:41 Please respond to MQSeries List Hello, I have an application which one of the prerequisites is to call MQGET with a minimum 120 second WaitInterval! This application is using MQSeries 5.3 client on a WIN32 platform and runs as a service. The minimum 120 second interval is there to supposedly keep the bandwidth down to a minimum. However, the problem is with WIN32 the Service Control Manager times out and cannot shut down the service in a timely fashion. MQGET will only return if the WaitInterval has expired or a message is received. My only solution is to put a message onto the GET Queue prior to shutdown to force an exit out of the blocked read. I was hoping for a more elegant solution on WIN32. Are there any other ways to signal a blocked MQI MQGET on Win32 to exit? Thanks much! Steve Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
MQGet Blocked Read
Steve, Another option to end your program nicely is to set the queue to get disabled prior to shutdown. Arjan WebSphere MQ and EDI -- http://edi.services.ibm.com/mqseries/spec_sheets.shtml 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: MQGet Blocked Read
I'm sure that you can tell the Windows Service manager how long to wait when shutting down a particular service. If you could extend this time to 120 seconds would that fix your problem or is it the wait itself that you are trying to avoid? Cheers, Paul Steve D. Perkins [EMAIL PROTECTED] on 02/08/2003 23:41:34 Please respond to MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Paul Meekin) Subject: MQGet Blocked Read Hello, I have an application which one of the prerequisites is to call MQGET with a minimum 120 second WaitInterval! This application is using MQSeries 5.3 client on a WIN32 platform and runs as a service. The minimum 120 second interval is there to supposedly keep the bandwidth down to a minimum. However, the problem is with WIN32 the Service Control Manager times out and cannot shut down the service in a timely fashion. MQGET will only return if the WaitInterval has expired or a message is received. My only solution is to put a message onto the GET Queue prior to shutdown to force an exit out of the blocked read. I was hoping for a more elegant solution on WIN32. Are there any other ways to signal a blocked MQI MQGET on Win32 to exit? Thanks much! Steve This e-mail is from Energis Communications Ltd, 185 Park Street, London, SE1 9DY, United Kingdom, No: 2630471. This e-mail is confidential to the addressee and may be privileged. The views expressed are personal and do not necessarily reflect those of Energis. If you are not the intended recipient please notify the sender immediately by calling our switchboard on +44 (0) 20 7206 and do not disclose to another person or use, copy or forward all or any of it in any form. 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: MQGet Blocked Read
Yes, thanks Will, thought I had made that clear. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of WR Sent: Monday, August 04, 2003 2:30 AM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read I think Steve is saying that he's stopping only his *application*, not MQ... -Will At 09:23 PM Sunday 8/3/2003, Tim Armstrong wrote: Sorry must be misinterpreting what your problem is. When you stop MQ via the SCM it stops your queue managers i.e. issues an internal endmqm MYQMGR if you have MQGMO_FAIL_IF_QUIESCING coded then you should not time out as your MQGET will fail with RC=2161 in your app which can then gracefully exit. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: Re: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 04/08/2003 14:00 Please respond to MQSeries List Tim, Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is shutting down. That's not the problem. The problem is terminating a WIN32 Client service gracefully when the service is in a blocked MQGET read. It appears there isn't any way except to wait or issue a ::TerminateThread which works but generates a ton of memory leaks. It would be nice if IBM would code an event handle that could be included as a parameter when issuing a MQGET. Then when signaled the MQGET would return out of the read. Another alternative is simply to PUT a message onto the GET queue prior to shutdown. This will break the blocked MQGET read as a message is readily available. I'm looking at that method as the best means of gracefully shutting down. However, I don't know how well that method will be received since I'm only supposed to be receiving messages from that queue. Therefore the hunt for an additional solution goes on Thanks for the reply! Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim Armstrong Sent: Sunday, August 03, 2003 8:47 PM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the MQOO_ equivalent etc. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 03/08/2003 08:41 Please respond to MQSeries List Hello, I have an application which one of the prerequisites is to call MQGET with a minimum 120 second WaitInterval! This application is using MQSeries 5.3 client on a WIN32 platform and runs as a service. The minimum 120 second interval is there to supposedly keep the bandwidth down to a minimum. However, the problem is with WIN32 the Service Control Manager times out and cannot shut down the service in a timely fashion. MQGET will only return if the WaitInterval has expired or a message is received. My only solution is to put a message onto the GET Queue prior to shutdown to force an exit out of the blocked read. I was hoping for a more elegant solution on WIN32. Are there any other ways to signal a blocked MQI MQGET on Win32 to exit? Thanks much! Steve Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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: MQGet Blocked Read
Arjan, That would be great if I had access to the queue manager. This is a Client App running outside the four walls of the QMGR. Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Arjan M Van Vught Sent: Monday, August 04, 2003 3:04 AM To: [EMAIL PROTECTED] Subject: MQGet Blocked Read Steve, Another option to end your program nicely is to set the queue to get disabled prior to shutdown. Arjan WebSphere MQ and EDI -- http://edi.services.ibm.com/mqseries/spec_sheets.shtml 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: MQGet Blocked Read
Can you have a 'shutdown' command that runs a program to send a report message to the app? With a feedback code of MQFB_QUIT ? The app / service would have to be modified to look for this type of message and feedback code. Peter Heggie (315) 428 - 3193 -Original Message- From: Steve D. Perkins [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 12:00 AM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Tim, Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is shutting down. That's not the problem. The problem is terminating a WIN32 Client service gracefully when the service is in a blocked MQGET read. It appears there isn't any way except to wait or issue a ::TerminateThread which works but generates a ton of memory leaks. It would be nice if IBM would code an event handle that could be included as a parameter when issuing a MQGET. Then when signaled the MQGET would return out of the read. Another alternative is simply to PUT a message onto the GET queue prior to shutdown. This will break the blocked MQGET read as a message is readily available. I'm looking at that method as the best means of gracefully shutting down. However, I don't know how well that method will be received since I'm only supposed to be receiving messages from that queue. Therefore the hunt for an additional solution goes on Thanks for the reply! Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim Armstrong Sent: Sunday, August 03, 2003 8:47 PM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the MQOO_ equivalent etc. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 03/08/2003 08:41 Please respond to MQSeries List Hello, I have an application which one of the prerequisites is to call MQGET with a minimum 120 second WaitInterval! This application is using MQSeries 5.3 client on a WIN32 platform and runs as a service. The minimum 120 second interval is there to supposedly keep the bandwidth down to a minimum. However, the problem is with WIN32 the Service Control Manager times out and cannot shut down the service in a timely fashion. MQGET will only return if the WaitInterval has expired or a message is received. My only solution is to put a message onto the GET Queue prior to shutdown to force an exit out of the blocked read. I was hoping for a more elegant solution on WIN32. Are there any other ways to signal a blocked MQI MQGET on Win32 to exit? Thanks much! Steve Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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: MQGet Blocked Read
Nice Peter It cold use that feedback code of 65876 (Application Quit). bb From: Heggie, Peter [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Date: Mon, 4 Aug 2003 08:21:12 -0400 Can you have a 'shutdown' command that runs a program to send a report message to the app? With a feedback code of MQFB_QUIT ? The app / service would have to be modified to look for this type of message and feedback code. Peter Heggie (315) 428 - 3193 -Original Message- From: Steve D. Perkins [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 12:00 AM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Tim, Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is shutting down. That's not the problem. The problem is terminating a WIN32 Client service gracefully when the service is in a blocked MQGET read. It appears there isn't any way except to wait or issue a ::TerminateThread which works but generates a ton of memory leaks. It would be nice if IBM would code an event handle that could be included as a parameter when issuing a MQGET. Then when signaled the MQGET would return out of the read. Another alternative is simply to PUT a message onto the GET queue prior to shutdown. This will break the blocked MQGET read as a message is readily available. I'm looking at that method as the best means of gracefully shutting down. However, I don't know how well that method will be received since I'm only supposed to be receiving messages from that queue. Therefore the hunt for an additional solution goes on Thanks for the reply! Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim Armstrong Sent: Sunday, August 03, 2003 8:47 PM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the MQOO_ equivalent etc. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 03/08/2003 08:41 Please respond to MQSeries List Hello, I have an application which one of the prerequisites is to call MQGET with a minimum 120 second WaitInterval! This application is using MQSeries 5.3 client on a WIN32 platform and runs as a service. The minimum 120 second interval is there to supposedly keep the bandwidth down to a minimum. However, the problem is with WIN32 the Service Control Manager times out and cannot shut down the service in a timely fashion. MQGET will only return if the WaitInterval has expired or a message is received. My only solution is to put a message onto the GET Queue prior to shutdown to force an exit out of the blocked read. I was hoping for a more elegant solution on WIN32. Are there any other ways to signal a blocked MQI MQGET on Win32 to exit? Thanks much! Steve Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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 new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail 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
MQSI Configuration Managers
Hi, Is it possible to have 2 configuration managers on the same box ? I plan to have unique queue managers for these two but I'm wondering whether the database (config manager and message repositories) to be shared between these 2 config managers. Will this configuration work? Regards Sony. 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
Strange behaviour on channels with message exit
A customer is reporting a problem where a cryptographic check-sum failure is being reported by our channel message exit. Analysis of the traces shows that x'15' characters in the data leaving the 390 are being converted to x'25' characters on receipt on the AIX system. Interestingly x'15' is EBCDIC new line, while x'25 is the ANSI new line character. These appear to the only characters that are getting hit. The only thing I can think of that could possibly cause this is some code trying to do new-line conversion, but surely a sender channel with CONVERT(YES) would do its work before any message exits are called rather than after. Has anyone got any rational explanation for what is happening here? Regards, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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: MQSI Configuration Managers
If it is possible you will probably need tow set of Databases and two QMGRS. You just might get away with one dayabase but I'm pretty sure you will need two QMGRS. From: Sony Varghese [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MQSI Configuration Managers Date: Mon, 4 Aug 2003 14:19:59 +0100 Hi, Is it possible to have 2 configuration managers on the same box ? I plan to have unique queue managers for these two but I'm wondering whether the database (config manager and message repositories) to be shared between these 2 config managers. Will this configuration work? Regards Sony. 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 _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail 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
Conversion FAQ
The link to the MQ Conversion FAQ on page http://www-3.ibm.com/software/integration/mqfamily/support/faqs/all_ver.html #faqa7 Appears to be a broken link. Does anyone have a softcopy of this? Could one of the IBMers inform the MQ web site owner? Thanks, David C. Partridge Security and MQ Products Manager Primeur Group Tel: +44 (0)1926 511058 Mobile: +44 (0)7713 880197 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
Mickel E Thomas/Pittsburgh/IBM is out of the office.
I will be out of the office starting August 4, 2003 and will not return until August 11, 2003. I will be in class the entire week from August 4th to August 8th. Please contact my manager; Lorraine A Johnson/Atlanta/IBM or Dennis Perdue/Atlanta/IBM for assistance. Thank you! 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
JMS Dynamic Queue Names
Title: JMS Dynamic Queue Names I am not a JMS programmer, so I am going to hopefully ask a simple question to someone who is. Does anyone know if it is possible to pick your own dynamic queue name within JMS? I am being told by some developers they can't manage to create a dynamic queue using a pre-defined prefix. I did see the following within the JAVA manaual (http://publibfp.boulder.ibm.com/epubs/pdf/csqzaw08.pdf): MQQueue queue =queueManager.accessQueue(qName, MQC.MQOO_OUTPUT, qMgrName, dynamicQName, altUserId); I am thinking the qName is for the Model queue and the dynamciQName could be initialized to a high level prefix for the dynamic queue name creation. Am I correct? Thanks Frank Bright This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.
Re: MQGet Blocked Read
Peter, I'm looking at putting a message onto the get queue. The message would need to be generated from the client which is the identical app that's trying to shut down. Since it is multithreaded that wouldn't be a problem since the PUT thread would be active and when signal to quit could HELP the GET thread to shutdown by placing a message onto it's queue. I'll look at MQFB_QUIT. Thanks. Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Heggie, Peter Sent: Monday, August 04, 2003 7:21 AM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Can you have a 'shutdown' command that runs a program to send a report message to the app? With a feedback code of MQFB_QUIT ? The app / service would have to be modified to look for this type of message and feedback code. Peter Heggie (315) 428 - 3193 -Original Message- From: Steve D. Perkins [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 12:00 AM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Tim, Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is shutting down. That's not the problem. The problem is terminating a WIN32 Client service gracefully when the service is in a blocked MQGET read. It appears there isn't any way except to wait or issue a ::TerminateThread which works but generates a ton of memory leaks. It would be nice if IBM would code an event handle that could be included as a parameter when issuing a MQGET. Then when signaled the MQGET would return out of the read. Another alternative is simply to PUT a message onto the GET queue prior to shutdown. This will break the blocked MQGET read as a message is readily available. I'm looking at that method as the best means of gracefully shutting down. However, I don't know how well that method will be received since I'm only supposed to be receiving messages from that queue. Therefore the hunt for an additional solution goes on Thanks for the reply! Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim Armstrong Sent: Sunday, August 03, 2003 8:47 PM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the MQOO_ equivalent etc. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 03/08/2003 08:41 Please respond to MQSeries List Hello, I have an application which one of the prerequisites is to call MQGET with a minimum 120 second WaitInterval! This application is using MQSeries 5.3 client on a WIN32 platform and runs as a service. The minimum 120 second interval is there to supposedly keep the bandwidth down to a minimum. However, the problem is with WIN32 the Service Control Manager times out and cannot shut down the service in a timely fashion. MQGET will only return if the WaitInterval has expired or a message is received. My only solution is to put a message onto the GET Queue prior to shutdown to force an exit out of the blocked read. I was hoping for a more elegant solution on WIN32. Are there any other ways to signal a blocked MQI MQGET on Win32 to exit? Thanks much! Steve Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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: MQGet Blocked Read
I take absolutely no credit for this one.. I've seen this answer in here, a while back.. But its great to be useful! Peter Heggie (315) 428 - 3193 -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 9:20 AM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Nice Peter It cold use that feedback code of 65876 (Application Quit). bb From: Heggie, Peter [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Date: Mon, 4 Aug 2003 08:21:12 -0400 Can you have a 'shutdown' command that runs a program to send a report message to the app? With a feedback code of MQFB_QUIT ? The app / service would have to be modified to look for this type of message and feedback code. Peter Heggie (315) 428 - 3193 -Original Message- From: Steve D. Perkins [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 12:00 AM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Tim, Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is shutting down. That's not the problem. The problem is terminating a WIN32 Client service gracefully when the service is in a blocked MQGET read. It appears there isn't any way except to wait or issue a ::TerminateThread which works but generates a ton of memory leaks. It would be nice if IBM would code an event handle that could be included as a parameter when issuing a MQGET. Then when signaled the MQGET would return out of the read. Another alternative is simply to PUT a message onto the GET queue prior to shutdown. This will break the blocked MQGET read as a message is readily available. I'm looking at that method as the best means of gracefully shutting down. However, I don't know how well that method will be received since I'm only supposed to be receiving messages from that queue. Therefore the hunt for an additional solution goes on Thanks for the reply! Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim Armstrong Sent: Sunday, August 03, 2003 8:47 PM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the MQOO_ equivalent etc. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 03/08/2003 08:41 Please respond to MQSeries List Hello, I have an application which one of the prerequisites is to call MQGET with a minimum 120 second WaitInterval! This application is using MQSeries 5.3 client on a WIN32 platform and runs as a service. The minimum 120 second interval is there to supposedly keep the bandwidth down to a minimum. However, the problem is with WIN32 the Service Control Manager times out and cannot shut down the service in a timely fashion. MQGET will only return if the WaitInterval has expired or a message is received. My only solution is to put a message onto the GET Queue prior to shutdown to force an exit out of the blocked read. I was hoping for a more elegant solution on WIN32. Are there any other ways to signal a blocked MQI MQGET on Win32 to exit? Thanks much! Steve Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. 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 new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at
Re: MQSI Configuration Managers
Sony, Is it possible to have 2 configuration managers on the same box ? No, it is not possible to have more than one configuration manager on a machine. You can have more than one broker, but only one configuration manager. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] 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: MQGet Blocked Read
Hi, Ya, I don't get the comment of affects bandwidth either. Usually I hear this from a manager who thinks they are a developer. When a WMQ client program issues a MQGET, only a few bytes are sent across the network. The 2 major items that are sent are: Connection Handle (4 bytes) and Object Handle (4 bytes). In the past, I have used small WaitInterval of 3, 5 and 10 seconds with no noticeable network hit for a Windows based MQ client program running as a service. I mean seriously, if you changed your WaitInterval from 120 to 3 seconds (40 times smaller) then your program would be sending an extra 320 bytes (40 * 8). You are going to do all this extra work to save less than 1 KB of bandwidth per every 120 seconds. I think you should suggest to your manager(s) that they need re-evaluate if there is actually a problem with using a smaller WaitInterval value. Regards, Roger Lacroix Enterprise Architect Capitalware Inc. At 12:56 PM 8/4/2003, you wrote: Steve, I guess we come from different schools; sending a quit message seems quite elegant to me. Are you claiming the waitinterval affects bandwidth? I don't get it. -Original Message- From: Steve D. Perkins [SMTP:[EMAIL PROTECTED] Sent: Saturday, August 02, 2003 3:42 PM To: [EMAIL PROTECTED] Subject: MQGet Blocked Read Hello, I have an application which one of the prerequisites is to call MQGET with a minimum 120 second WaitInterval! This application is using MQSeries 5.3 client on a WIN32 platform and runs as a service. The minimum 120 second interval is there to supposedly keep the bandwidth down to a minimum. However, the problem is with WIN32 the Service Control Manager times out and cannot shut down the service in a timely fashion. MQGET will only return if the WaitInterval has expired or a message is received. My only solution is to put a message onto the GET Queue prior to shutdown to force an exit out of the blocked read. I was hoping for a more elegant solution on WIN32. Are there any other ways to signal a blocked MQI MQGET on Win32 to exit? Thanks much! Steve Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Java class hangs when using AIX Runmqtrm
I actually did this a couple of weeks ago and it worked, but just forgot to post it.
Do you know of any negative's to turning JIT (JAVA_COMPILER=none) off."Hossain, Lail {PBSG}" [EMAIL PROTECTED] wrote:
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!
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: JMS Dynamic Queue Names
Frank You are correct you can use the accessQueue method to accomplish this in the base Java classes. However your original issue is with JMS. If you take a look at the JMS portion of that same manual you will see that the createTemporyQueue method does not give you control over naming the temporary dynamic queue that is generated. As far as I know, there is not a way with just JMS to do this. Some of our developers, whose design used dynamic queues, have been forced to introduce some non-JMS code into their application to accomplish this. Rick |-+--- | | Bright, Frank | | | [EMAIL PROTECTED] | | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Monday August 4, 2003 11:19 AM | | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: JMS Dynamic Queue Names | | I am not a JMS programmer, so I am going to hopefully ask a simple question to someone who is. Does anyone know if it is possible to pick your own dynamic queue name within JMS? I am being told by some developers they can't manage to create a dynamic queue using a pre-defined prefix. I did see the following within the JAVA manaual (http://publibfp.boulder.ibm.com/epubs/pdf/csqzaw08.pdf http://publibfp.boulder.ibm.com/epubs/pdf/csqzaw08.pdf ): MQQueue queue =queueManager.accessQueue(qName, MQC.MQOO_OUTPUT, qMgrName, dynamicQName, altUserId); I am thinking the qName is for the Model queue and the dynamciQName could be initialized to a high level prefix for the dynamic queue name creation. Am I correct? Thanks Frank Bright This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. (See attached file: C.htm) Title: JMS Dynamic Queue Names I am not a JMS programmer, so I am going to hopefully ask a simple question to someone who is. Does anyone know if it is possible to pick your own dynamic queue name within JMS? I am being told by some developers they can't manage to create a dynamic queue using a pre-defined prefix. I did see the following within the JAVA manaual (http://publibfp.boulder.ibm.com/epubs/pdf/csqzaw08.pdf): MQQueue queue =queueManager.accessQueue(qName, MQC.MQOO_OUTPUT, qMgrName, dynamicQName, altUserId); I am thinking the qName is for the Model queue and the dynamciQName could be initialized to a high level prefix for the dynamic queue name creation. Am I correct? Thanks Frank Bright This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.
Re: JMS Dynamic Queue Names
Thanks Rick. Do you know if there is a sample of code mixing JMS with JAVA that I could pass along to our developers here? -Original Message- From: Richard Brunette [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 1:45 PM To: [EMAIL PROTECTED] Subject: Re: JMS Dynamic Queue Names Frank You are correct you can use the accessQueue method to accomplish this in the base Java classes. However your original issue is with JMS. If you take a look at the JMS portion of that same manual you will see that the createTemporyQueue method does not give you control over naming the temporary dynamic queue that is generated. As far as I know, there is not a way with just JMS to do this. Some of our developers, whose design used dynamic queues, have been forced to introduce some non-JMS code into their application to accomplish this. Rick |-+--- | | Bright, Frank | | | [EMAIL PROTECTED] | | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Monday August 4, 2003 11:19 AM | | | Please respond to MQSeries List | | | | |-+--- --- -| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: JMS Dynamic Queue Names | --- -| I am not a JMS programmer, so I am going to hopefully ask a simple question to someone who is. Does anyone know if it is possible to pick your own dynamic queue name within JMS? I am being told by some developers they can't manage to create a dynamic queue using a pre-defined prefix. I did see the following within the JAVA manaual (http://publibfp.boulder.ibm.com/epubs/pdf/csqzaw08.pdf http://publibfp.boulder.ibm.com/epubs/pdf/csqzaw08.pdf ): MQQueue queue =queueManager.accessQueue(qName, MQC.MQOO_OUTPUT, qMgrName, dynamicQName, altUserId); I am thinking the qName is for the Model queue and the dynamciQName could be initialized to a high level prefix for the dynamic queue name creation. Am I correct? Thanks Frank Bright This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. (See attached file: C.htm) This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. 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: JMS Dynamic Queue Names
Frank, I am not a JMS programmer, so I am going to hopefully ask a simple question to someone who is. Does anyone know if it is possible to pick your own dynamic queue name within JMS? I am being told by some developers they can't manage to create a dynamic queue using a pre-defined prefix. You might be able to use the following new property introduced in CSD4 of WMQ: TEMPQPREFIX --- The prefix to use when creating temporary/dynamic queues. If not specified defaults will be used Default AMQ.* (CSQ.* for 390). The prefix follows the same rules as WebSphere MQ queue names and must have an asterisk at the end of the prefix to enable the dynamic part of the name to be generated. The length of the prefix is 33 characters or less including the asterik. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] 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: MQGet Blocked Read
Roger I think your leaving out a few things, not the least of which are the Message Descriptor and Get Message Options structures. These are much larger than 8 bytes. In all your going to send more than 400 bytes (depending on version). Not to mention all the processing that goes with polling. As Peter and Dennis point out, the use of a quit message is a common solution for this type of service and is an elegant way to shut the application down while not forcing the application to waste both CPU and bandwidth with unnecessary polling. Rick |-+--- | | Roger Lacroix | | | [EMAIL PROTECTED] | | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Monday August 4, 2003 12:24 PM | | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQGet Blocked Read | | Hi, Ya, I don't get the comment of affects bandwidth either. Usually I hear this from a manager who thinks they are a developer. When a WMQ client program issues a MQGET, only a few bytes are sent across the network. The 2 major items that are sent are: Connection Handle (4 bytes) and Object Handle (4 bytes). In the past, I have used small WaitInterval of 3, 5 and 10 seconds with no noticeable network hit for a Windows based MQ client program running as a service. I mean seriously, if you changed your WaitInterval from 120 to 3 seconds (40 times smaller) then your program would be sending an extra 320 bytes (40 * 8). You are going to do all this extra work to save less than 1 KB of bandwidth per every 120 seconds. I think you should suggest to your manager(s) that they need re-evaluate if there is actually a problem with using a smaller WaitInterval value. Regards, Roger Lacroix Enterprise Architect Capitalware Inc. At 12:56 PM 8/4/2003, you wrote: Steve, I guess we come from different schools; sending a quit message seems quite elegant to me. Are you claiming the waitinterval affects bandwidth? I don't get it. -Original Message- From: Steve D. Perkins [SMTP:[EMAIL PROTECTED] Sent: Saturday, August 02, 2003 3:42 PM To: [EMAIL PROTECTED] Subject: MQGet Blocked Read Hello, I have an application which one of the prerequisites is to call MQGET with a minimum 120 second WaitInterval! This application is using MQSeries 5.3 client on a WIN32 platform and runs as a service. The minimum 120 second interval is there to supposedly keep the bandwidth down to a minimum. However, the problem is with WIN32 the Service Control Manager times out and cannot shut down the service in a timely fashion. MQGET will only return if the WaitInterval has expired or a message is received. My only solution is to put a message onto the GET Queue prior to shutdown to force an exit out of the blocked read. I was hoping for a more elegant solution on WIN32. Are there any other ways to signal a blocked MQI MQGET on Win32 to exit? Thanks much! Steve Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS Dynamic Queue Names
No, not that I know of. There isn't really anything to stop you from writing both in an application, but your not going to simply pass objects between them either. Each is going to try to manage its own object types. I believe the application I'm thinking of simply invokes a method to connect and create the queue dynamically and saves the name. Then while the queue is open it uses it as a predefined queue in JMS. When finished the JMS close is done then the base method is called to close (and by definition destroy) the temporary queue. Certainly two other options are to lose either JMS or the use of dynamic queues. Rick 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: JMS Dynamic Queue Names
Christopher, Good answer. I will pass this along. Thanks Frank -Original Message- From: Christopher Frank [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 2:13 PM To: [EMAIL PROTECTED] Subject: Re: JMS Dynamic Queue Names Frank, I am not a JMS programmer, so I am going to hopefully ask a simple question to someone who is. Does anyone know if it is possible to pick your own dynamic queue name within JMS? I am being told by some developers they can't manage to create a dynamic queue using a pre-defined prefix. You might be able to use the following new property introduced in CSD4 of WMQ: TEMPQPREFIX --- The prefix to use when creating temporary/dynamic queues. If not specified defaults will be used Default AMQ.* (CSQ.* for 390). The prefix follows the same rules as WebSphere MQ queue names and must have an asterisk at the end of the prefix to enable the dynamic part of the name to be generated. The length of the prefix is 33 characters or less including the asterik. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] 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 e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments. 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: JMS Dynamic Queue Names
Christopher Where did you find documentation on this? This sounds like this could have saved a lot of headaches if it had been available when this application rolled out back in 5.1. Rick |-+--- | | Christopher Frank | | | [EMAIL PROTECTED] | | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Monday August 4, 2003 01:13 PM | | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: JMS Dynamic Queue Names | | Frank, I am not a JMS programmer, so I am going to hopefully ask a simple question to someone who is. Does anyone know if it is possible to pick your own dynamic queue name within JMS? I am being told by some developers they can't manage to create a dynamic queue using a pre-defined prefix. You might be able to use the following new property introduced in CSD4 of WMQ: TEMPQPREFIX --- The prefix to use when creating temporary/dynamic queues. If not specified defaults will be used Default AMQ.* (CSQ.* for 390). The prefix follows the same rules as WebSphere MQ queue names and must have an asterisk at the end of the prefix to enable the dynamic part of the name to be generated. The length of the prefix is 33 characters or less including the asterik. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] 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: MQGet Blocked Read
It may be (although see below) .. if you have a luxury of changing the application. Otherwise, blitting with MQGET permission on the queue after starting a clean shutdown of the service may help (for example, with runmqsc response file). I would argue this is the cleanest solution in this case (although it sounds like a hack). The reason is that the active actor (the one who wants to shutdown the service) is working with the server and it seems to me consistent to perform all actions necessary to stop the applications also on the server if it is possible -- and it is. Someone here on the list suggested this way some year ago when I asked the similar questions. In my case, however, the MQGET termination must have been done in response to the application user's wish, so I selected to make a wait interval configurable (with 10 second default that gives almost reasonable reaction time on the user's action and does not create any notable additional CPU or network load (Steve's mileage can vary, of course)). So, for my situation I really do not have a really clean solution and consider it an API problem (the absense of possibility to cancel long lasting inquires on the application side). (No, I am not in the position to change the application level protocol by introducing QUIT type of message or similar). But in Steve's case the trick with GET permission could provide a clean solution, I beleive. There is of course a possibility that a QM goes down before the permissions could be restored :-). Not sure how to deal with that, but this sounds solvable to me... One way is just to restore all permissions after QM is restarted.. Pavel Richard Brunette [EMAIL PROTECTED]To: [EMAIL PROTECTED] ENTIAL.COM cc: Sent by: MQSeries ListSubject: Re: MQGet Blocked Read [EMAIL PROTECTED] AT 08/04/2003 02:10 PM Please respond to MQSeries List Roger I think your leaving out a few things, not the least of which are the Message Descriptor and Get Message Options structures. These are much larger than 8 bytes. In all your going to send more than 400 bytes (depending on version). Not to mention all the processing that goes with polling. As Peter and Dennis point out, the use of a quit message is a common solution for this type of service and is an elegant way to shut the application down while not forcing the application to waste both CPU and bandwidth with unnecessary polling. Rick |-+--- | | Roger Lacroix | | | [EMAIL PROTECTED] | | | | | | Sent by: MQSeries List | | | [EMAIL PROTECTED] | | | | | | | | | | | | Monday August 4, 2003 12:24 PM | | | Please respond to MQSeries List | | | | |-+--- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: MQGet Blocked Read | | Hi, Ya, I don't get the comment of affects bandwidth either. Usually I hear this from a manager who thinks they are a developer. When a WMQ client program issues a MQGET, only a few bytes are sent across the network. The 2 major items that are sent are: Connection Handle (4 bytes) and Object Handle (4 bytes). In the past, I have used small WaitInterval of 3, 5 and 10 seconds with no noticeable network hit for a Windows based MQ client program running as a service. I mean seriously, if you changed your WaitInterval from 120 to 3 seconds (40 times smaller) then your program would be sending an extra 320 bytes (40 * 8). You are going to do all this extra work to save less than 1 KB of bandwidth per every 120 seconds. I think you should suggest to your manager(s) that they need re-evaluate if there is actually a problem with using a smaller WaitInterval value. Regards, Roger Lacroix Enterprise Architect Capitalware Inc. At 12:56 PM 8/4/2003, you wrote: Steve, I guess we come from different schools; sending a quit
Re: JMS Dynamic Queue Names
Thanks, Christopher. We had not downloaded CSD4. I do see it ( and the setTempQPrefix() and getTempQPrefix() methods) in the memo.ptf. If this had been released sooner, I could have saved someone a lot of coding. They just did maintenance on this and released with 5.3 CSD3. Thanks again. This was news to me. Rick 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
[no subject]
Hello, We are trying to get to a parallel sysplex. We are running into issues on how to transition MQ Series. We do not have DB2, so we can not use the queue sharing. Are there any other solutions for a parallel sysplex with MQ Series? Thanks, Kris
MQ 5.3 with WMQI2.1
Hi, Is MQ 5.3 Officially supported for WMQI 2.1? We currently have WMQI 2.1 CSD4 with MQ 5.2 on Solaris 8. We are thinking of upgrading MQ to 5.3. Has anybody got any problems with MQ 5.3 and WMQI2.1 on Solaris? Is this combination officilally supported by IBM? Thanks Kiran Kanetkar 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: Really Big Pagesets
Well, the issue is that we need to get this data off of the mainframe ASAP. It's using up space in DB2 and using up tapes that we need (apparently there's a wroldwide shortage of tapes!). And from an application perspective, as soon as it's on a queue it's off the mainframe, since MQ guarantees delivery. Unloading the data from tape at the speed of the slowest link in the chain wouldn't be satisfactory. Tim Armstrong [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Really Big Pagesets List [EMAIL PROTECTED] N.AC.AT 08/03/2003 06:49 PM Please respond to MQSeries List Why queue it up in MQ? As I said in a previous reply its fairly simple to modify you app so the delivery is paced and continuous. Regards Tim A Jim Ford [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Really Big Pagesets List [EMAIL PROTECTED] N.AC.AT 02/08/2003 07:53 Please respond to MQSeries List In a previous thread, I mentioned that we are sending gobs of BLOBs from the mainframe to a Unix machine. The mainframe side will be putting the messages far faster than the Solaris side will be consuming them. So we want to queue up as much data in the xmitq as we can, and let MQSeries deliver it when it can. I've got the OS/390 disk available to me to do that (10 3390s), but I find that the maximum size of a pageset is 4GB, or a little less than 2 volumes. I assume that means that a queue cannot contain more than 4GB of data either. How can I handle this? I realize that the application could take on the burden of knowing when to stop, but we were all hoping to just dump the data to MQ and the product unload it over time. It's a rare thing here to have this much disk available and I'd like to use it. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Backout queue processing in JMS
Thanks, Dennis. I'll post back if we discover anything useful. -- T.Rob -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 7:03 PM To: [EMAIL PROTECTED] Subject: Re: Backout queue processing in JMS I don't know the innards of JMS, but conceptually I think you have a perceptive developer and technique with limited usefulness. Problem is, there is no way to issue a commit on just the exception messages. The MQGET/MQPUT of any exception messages and the MQGET of the first non-exception message that follow them all become part of the same UOW. If that's no acceptable, I'll bet your out of luck. I, too would appreciate any discussion of JMS backout/requeue. I think I finally appreciate the ultimate wisdom of MQ developers to leave that one alone! -Original Message- From: Wyatt, T. Rob [SMTP:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 12:40 PM To: [EMAIL PROTECTED] Subject: Backout queue processing in JMS Hi all, We recently discovered that JMS would honor the BOQUEUE and BOTHRESH parameters and set up an exception queue for one of our applications. Problem is that whenever messages are put to the exception queue, they remain uncommitted for long periods of time. Since the requeing takes place outside of application control, the developer doesn't know at what point, if at all, she can issue a commit on the exception messages. Does anyone know of a good doc that discusses backout queue processing in JMS? Or maybe you have some advice on the matter to pass along? Thanks in advance! -- T.Rob Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: channel synchronization file missing or damaged
You could try rcrmqobj -m whatever -t syncfile to recover it. I've seen this sort of damage before, and that command usually fixes the problem. Cheers... Greg Ross Websphere MQ support +61 3 9886 2376 Kearns, Emile E [EMAIL PROTECTED]To: [EMAIL PROTECTED] ZA cc: Sent by: MQSeriesSubject: channel synchronization file missing or damaged List [EMAIL PROTECTED] n.AC.AT 04/08/2003 15:56 Please respond to MQSeries List Hi, I have a few questions around the above; 1. How does this file get damaged? 2. If you are not using linear logging, how can you rebuild this file? 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 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: MQGet Blocked Read
Sorry had my blinkers on. As others have said one solution is to send a STOP message, I have done this using a different MsgType but the MQFB_QUIT is probably more valid. Arjan's idea of get disabling the queue is possible if you are prepared to permit +set access to clients and issue an MQSET API call from within a client program. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: Re: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 04/08/2003 18:23 Please respond to MQSeries List Yes, thanks Will, thought I had made that clear. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of WR Sent: Monday, August 04, 2003 2:30 AM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read I think Steve is saying that he's stopping only his *application*, not MQ... -Will At 09:23 PM Sunday 8/3/2003, Tim Armstrong wrote: Sorry must be misinterpreting what your problem is. When you stop MQ via the SCM it stops your queue managers i.e. issues an internal endmqm MYQMGR if you have MQGMO_FAIL_IF_QUIESCING coded then you should not time out as your MQGET will fail with RC=2161 in your app which can then gracefully exit. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: Re: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 04/08/2003 14:00 Please respond to MQSeries List Tim, Yep, sure did. MQGMO_FAIL_IF_QUIESCING happens when the queue manager is shutting down. That's not the problem. The problem is terminating a WIN32 Client service gracefully when the service is in a blocked MQGET read. It appears there isn't any way except to wait or issue a ::TerminateThread which works but generates a ton of memory leaks. It would be nice if IBM would code an event handle that could be included as a parameter when issuing a MQGET. Then when signaled the MQGET would return out of the read. Another alternative is simply to PUT a message onto the GET queue prior to shutdown. This will break the blocked MQGET read as a message is readily available. I'm looking at that method as the best means of gracefully shutting down. However, I don't know how well that method will be received since I'm only supposed to be receiving messages from that queue. Therefore the hunt for an additional solution goes on Thanks for the reply! Steve -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tim Armstrong Sent: Sunday, August 03, 2003 8:47 PM To: [EMAIL PROTECTED] Subject: Re: MQGet Blocked Read Did you code MQGMO_FAIL_IF_QUIESCING? Note you should also code the MQOO_ equivalent etc. Regards Tim A Steve D. Perkins To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: Sent by: MQSeriesSubject: MQGet Blocked Read List [EMAIL PROTECTED] N.AC.AT 03/08/2003 08:41 Please respond to MQSeries List Hello, I have an application which one of the prerequisites is to call MQGET with a minimum 120 second WaitInterval! This application is using MQSeries 5.3 client on a WIN32 platform and runs as a service. The minimum 120 second interval is there to supposedly keep the bandwidth down to a minimum. However, the problem is with WIN32 the Service Control Manager times out and cannot shut down the service in a timely fashion. MQGET will only return if the WaitInterval has expired or a message is received. My only solution is to put a message onto the GET Queue prior to shutdown to force an exit out of the blocked read. I was hoping for a more elegant solution on WIN32. Are there any other ways to signal a blocked MQI MQGET on Win32 to exit? Thanks much! Steve Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive:
Re: Really Big Pagesets
Ok getting the picture. What is slow about the processing on the Solaris end? Are you compressing the data before storing it? Problems storing it in a DB? Are you hitting a CPU limit? An I/O subsystem limit? Does running multiple processes against the queue help? Regards Tim A Jim Ford [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Re: Really Big Pagesets List [EMAIL PROTECTED] N.AC.AT 05/08/2003 07:02 Please respond to MQSeries List Well, the issue is that we need to get this data off of the mainframe ASAP. It's using up space in DB2 and using up tapes that we need (apparently there's a wroldwide shortage of tapes!). And from an application perspective, as soon as it's on a queue it's off the mainframe, since MQ guarantees delivery. Unloading the data from tape at the speed of the slowest link in the chain wouldn't be satisfactory. Tim Armstrong [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Really Big Pagesets List [EMAIL PROTECTED] N.AC.AT 08/03/2003 06:49 PM Please respond to MQSeries List Why queue it up in MQ? As I said in a previous reply its fairly simple to modify you app so the delivery is paced and continuous. Regards Tim A Jim Ford [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Really Big Pagesets List [EMAIL PROTECTED] N.AC.AT 02/08/2003 07:53 Please respond to MQSeries List In a previous thread, I mentioned that we are sending gobs of BLOBs from the mainframe to a Unix machine. The mainframe side will be putting the messages far faster than the Solaris side will be consuming them. So we want to queue up as much data in the xmitq as we can, and let MQSeries deliver it when it can. I've got the OS/390 disk available to me to do that (10 3390s), but I find that the maximum size of a pageset is 4GB, or a little less than 2 volumes. I assume that means that a queue cannot contain more than 4GB of data either. How can I handle this? I realize that the application could take on the burden of knowing when to stop, but we were all hoping to just dump the data to MQ and the product unload it over time. It's a rare thing here to have this much disk available and I'd like to use it. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Really Big Pagesets
It's mostly a bandwidth problem. The purpose of all this is to write the BLOB to an EMC Centera box, which is a network attached storage device. It's got massive capacity, but it's not especially fast. But the real problem is that the Solaris machine is bandwidth constrained. It's getting gigs of data from the mainframe, and sending the same amount of data out to Centera, plus our webserver logs are being directed to this machine. Its 100 megabit network interface can't keep up. If anyone from EMC is listening, how about porting your Centera API to OS/390? Tim Armstrong [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Really Big Pagesets List [EMAIL PROTECTED] N.AC.AT 08/04/03 07:21 PM Please respond to MQSeries List Ok getting the picture. What is slow about the processing on the Solaris end? Are you compressing the data before storing it? Problems storing it in a DB? Are you hitting a CPU limit? An I/O subsystem limit? Does running multiple processes against the queue help? Regards Tim A Jim Ford [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Re: Really Big Pagesets List [EMAIL PROTECTED] N.AC.AT 05/08/2003 07:02 Please respond to MQSeries List Well, the issue is that we need to get this data off of the mainframe ASAP. It's using up space in DB2 and using up tapes that we need (apparently there's a wroldwide shortage of tapes!). And from an application perspective, as soon as it's on a queue it's off the mainframe, since MQ guarantees delivery. Unloading the data from tape at the speed of the slowest link in the chain wouldn't be satisfactory. Tim Armstrong [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: Re: Really Big Pagesets List [EMAIL PROTECTED] N.AC.AT 08/03/2003 06:49 PM Please respond to MQSeries List Why queue it up in MQ? As I said in a previous reply its fairly simple to modify you app so the delivery is paced and continuous. Regards Tim A Jim Ford [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Really Big Pagesets List [EMAIL PROTECTED] N.AC.AT 02/08/2003 07:53 Please respond to MQSeries List In a previous thread, I mentioned that we are sending gobs of BLOBs from the mainframe to a Unix machine. The mainframe side will be putting the messages far faster than the Solaris side will be consuming them. So we want to queue up as much data in the xmitq as we can, and let MQSeries deliver it when it can. I've got the OS/390 disk available to me to do that (10 3390s), but I find that the maximum size of a pageset is 4GB, or a little less than 2 volumes. I assume that means that a queue cannot contain more than 4GB of data either. How can I handle this? I realize that the application could take on the burden of knowing when to stop, but we were all hoping to just dump the data to MQ and the product unload it over time. It's a rare thing here to have this much disk available and I'd like to use it. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive:
Brian E Wilson/Albany/IBM is out of the office.
I will be out of the office starting August 3, 2003 and will not return until August 11, 2003. I will be out of the office in training the week of August 4. During this time, I will have limited access to voice mail and e-mail. If you need technical assistance, please call IBM Support. If this is an emergency, please contact Ray Novak at 610-578-2153 or Pete Tyrpak at 610-865-7446 who are acting as my backups while I am out. 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
Local Queue Reaches Maximum Depth
Hi, I'm covering WebSphere MQ for z/OS 5.3 for a few weeks and MQ isn't exactly my speciality, so please be patient!! There was a problem yesterday with a local queue that reached maximum depth and overflowed to the dead letter queue. There was a bad message in the local queue and all subsequent messages stacked up behind it until maximum depth was reached and messages began overflowing into the dead letter queue. We would like to identify this type of problem much earlier in the future and are looking for some automation ideas? 1. The MQ API doesn't seem to return a maximum depth reached response for the MQPUT call, is that correct? 2. When the maximum depth for a local queue is reached MQ doesn't seem to write any sort of warning message to the system log, is that correct? 3. When messages start overflowing to the dead letter queue MQ doesn't seem to write any sort of message to the system log either, is that correct? My immediate idea was, that if the application performing the MQGET realises a message is bad it should move it off to an error queue or something rather than leaving it there to block the whole show, any comments? I would be grateful for any ideas or suggestions. I'm only providing emergency cover and the only manuals I could find were for MQS 2.1!!! Thanks, Carl 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
