Ronald Weinger/Bsg/MetLife/US is out of the office.
I will be out of the office starting 11/10/2003 and will not return until 11/12/2003. I will respond to your message when I return. The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. 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: Triggering across New Cluster not working - Design Suggestion
Whew! Ok, the holiday to AU is back on. We have a terrible time getting application folks to program around the 2009 problem. Glad you already had this in place. By the way, I found that million I lost earlier. I've been meaning to return it but something always comes up. ;-) -- T.Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 4:47 PM To: [EMAIL PROTECTED] Subject: Re: Triggering across New Cluster not working - Design Suggestion G'Day T. Rob, A sequence number is encoded in the data file, when the client sends back an application level ack we get the sequence number so we know if one went astray after delivery. We never loose anything (unlike some backs ;). This sequencing was encoded in the data files before we started to move everything to MQ as the transport, prior to that it was z-modem and direct dial systems. Duplication causes problems with some of the recieving application in so much as warnings are generated that results may have changed. Most third party apps are not smart enough to actually work out what is different from the previous copy of the results as everything is human interpretted except for some ICU systems where a machine decides if it is cost effective to keep you in an ICU ward or automatically move you out to a ward to die. I don't want to be in a situation where multiple copies of the data cause an automatted system to think to much is being spent on diagnostics and then that triggers some poor bugger being wheeled out of intensive care. Ohh...and yes everything is under syncpoint. I think I have now worked out a solution to the affinity problem, and it's scalable to n number of clustered hosts Nick from national.com.au gave me a few suggestions and it kind of fitted to what I was thinking might work, I'll be documenting something this week and designing a few test cases to prove the concept first. I am still interested to here what others come up with as there are so many clever people on this list. Sid -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Tuesday, 11 November 2003 4:54 AM To: [EMAIL PROTECTED] Subject: Re: Triggering across New Cluster not working - Design Suggestion You are using a client in an environment where dupe messages can cause a fatality? You are braver than I am, that's for sure. We won't use a client here at the bank and all we have at risk is a few million dollars give or take. You are doing all PUT/GET activity under syncpoint, right? What do you plan to do when you get a 2009 after a COMMIT? When you get a 2009, it indicates that the connection was lost before your client could get a return code from the SVRCONN agent at the QMgr. You have no way of knowing whether the COMMIT was successful and your GETs/PUTs were committed, or if it failed and your GETs/PUTs were backed out. -- T.Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 5:47 PM To: [EMAIL PROTECTED] Subject: Triggering across New Cluster not working - Design Suggestion Yep, everyone's comments are valid... I re-read the Queue Manger Cluster manual again last night and found a one liner on the limitation of MQGET just a single line ( and not a mention in any of the other manuals as far as I can see so far). I find this a serious limitation for my design. The queue needs some kind of flag that says it's available for GETing across the cluster, otherwise you need to re-design your applications to hunt down the queue. I can solve the triggering problem, just trigger locally and have my apps connect to each server, the real issue is the clients connecting in. It does not make sense to me that you can PUT accross the cluster but must attach locally to the QM to get the data. I now need to do a re-design of my client application to obtain it's data. I'm trying to send sensitive medical data where a duplication of data could be fatal and with 1000's of multi-threaded clients coming online in the next 12 months a single server will not cut it. My best solution so far is to have clients connect, discover their queue is not present (CC=2085), build a Permanent Dynamic queue (or something similar) and PUT to a Dist list of queues serviced by a data move app to move the data to the temporary queue. Any other design suggestions are more than welcome. Sid Young Brisbane Australia -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Saturday, 8 November 2003 4:38 AM To: [EMAIL PROTECTED] Subject: Re: Triggering across New Cluster not working [Deutsche Boerse Systems: Virus ch Picking up on what Stefan is indicating. one of the requirements for triggering is that the INIT Q is available and opened for input by some process (hopefully the Trigger monitor) from the LINUX side can the QMGR verify this through the cluster if those attributes are true or false???
Mike Clark/HO/Australia/Zurich is out of the office.
I will be out of the office from 11/11/2003 until 12/11/2003. I will respond to your message when I return. If it is urgent please contact Krume Spirofski on (02) 9995 1478 This email is intended for the named recipient only. The information contained in this message may be confidential, or commercially sensitive. If you are not the intended recipient you must not reproduce or distribute any part of the email, disclose its contents to any other party, or take any action in reliance on it. If you have received this email in error, please contact the sender immediately. Please delete this message from your computer.
Re: Triggering across New Cluster not working - Design Suggestion
G'Day T. Rob, A sequence number is encoded in the data file, when the client sends back an application level ack we get the sequence number so we know if one went astray after delivery. We never loose anything (unlike some backs ;). This sequencing was encoded in the data files before we started to move everything to MQ as the transport, prior to that it was z-modem and direct dial systems. Duplication causes problems with some of the recieving application in so much as warnings are generated that results may have changed. Most third party apps are not smart enough to actually work out what is different from the previous copy of the results as everything is human interpretted except for some ICU systems where a machine decides if it is cost effective to keep you in an ICU ward or automatically move you out to a ward to die. I don't want to be in a situation where multiple copies of the data cause an automatted system to think to much is being spent on diagnostics and then that triggers some poor bugger being wheeled out of intensive care. Ohh...and yes everything is under syncpoint. I think I have now worked out a solution to the affinity problem, and it's scalable to n number of clustered hosts Nick from national.com.au gave me a few suggestions and it kind of fitted to what I was thinking might work, I'll be documenting something this week and designing a few test cases to prove the concept first. I am still interested to here what others come up with as there are so many clever people on this list. Sid -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Tuesday, 11 November 2003 4:54 AM To: [EMAIL PROTECTED] Subject: Re: Triggering across New Cluster not working - Design Suggestion You are using a client in an environment where dupe messages can cause a fatality? You are braver than I am, that's for sure. We won't use a client here at the bank and all we have at risk is a few million dollars give or take. You are doing all PUT/GET activity under syncpoint, right? What do you plan to do when you get a 2009 after a COMMIT? When you get a 2009, it indicates that the connection was lost before your client could get a return code from the SVRCONN agent at the QMgr. You have no way of knowing whether the COMMIT was successful and your GETs/PUTs were committed, or if it failed and your GETs/PUTs were backed out. -- T.Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 5:47 PM To: [EMAIL PROTECTED] Subject: Triggering across New Cluster not working - Design Suggestion Yep, everyone's comments are valid... I re-read the Queue Manger Cluster manual again last night and found a one liner on the limitation of MQGET just a single line ( and not a mention in any of the other manuals as far as I can see so far). I find this a serious limitation for my design. The queue needs some kind of flag that says it's available for GETing across the cluster, otherwise you need to re-design your applications to hunt down the queue. I can solve the triggering problem, just trigger locally and have my apps connect to each server, the real issue is the clients connecting in. It does not make sense to me that you can PUT accross the cluster but must attach locally to the QM to get the data. I now need to do a re-design of my client application to obtain it's data. I'm trying to send sensitive medical data where a duplication of data could be fatal and with 1000's of multi-threaded clients coming online in the next 12 months a single server will not cut it. My best solution so far is to have clients connect, discover their queue is not present (CC=2085), build a Permanent Dynamic queue (or something similar) and PUT to a Dist list of queues serviced by a data move app to move the data to the temporary queue. Any other design suggestions are more than welcome. Sid Young Brisbane Australia -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Saturday, 8 November 2003 4:38 AM To: [EMAIL PROTECTED] Subject: Re: Triggering across New Cluster not working [Deutsche Boerse Systems: Virus ch Picking up on what Stefan is indicating. one of the requirements for triggering is that the INIT Q is available and opened for input by some process (hopefully the Trigger monitor) from the LINUX side can the QMGR verify this through the cluster if those attributes are true or false??? bobbee I will say this is an interesting twist to triggering. MAybe you need a process on LINUX that starts the NT process like secured shell. >From: Stefan Raabe <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Triggering across New Cluster not working [Deutsche Boerse > Systems: Virus checked] >Date: Fri, 7 Nov 2003 11:40:55 +0100 > >Sid, > >i hope i understood your environment right: unix and nt in an mqseries >clu
Supportpac MA19:Rexx Interface to Issue Commands to MQSeries for MVS/ESA V2.0
Title: Message I have been using the MA19 support with some good results, however, after a recent test, I have been getting a 2033 for the command responses. The responses wind up in the DEAD.LETTER for dynamic queue RXMQVC.* for reason code 2085. I don't understand what may be wrong since I am passing in the timeout value of 15 seconds. The time it takes to get a 2033 is around 2 seconds. The trace for CMD shows using this interface using the .TO variable is set to 15 with a length of 2. Can anyone offer a suggestion on how to debug this? Thanks Frank 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: Triggering across New Cluster not working - Design Suggestion
You are using a client in an environment where dupe messages can cause a fatality? You are braver than I am, that's for sure. We won't use a client here at the bank and all we have at risk is a few million dollars give or take. You are doing all PUT/GET activity under syncpoint, right? What do you plan to do when you get a 2009 after a COMMIT? When you get a 2009, it indicates that the connection was lost before your client could get a return code from the SVRCONN agent at the QMgr. You have no way of knowing whether the COMMIT was successful and your GETs/PUTs were committed, or if it failed and your GETs/PUTs were backed out. -- T.Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 5:47 PM To: [EMAIL PROTECTED] Subject: Triggering across New Cluster not working - Design Suggestion Yep, everyone's comments are valid... I re-read the Queue Manger Cluster manual again last night and found a one liner on the limitation of MQGET just a single line ( and not a mention in any of the other manuals as far as I can see so far). I find this a serious limitation for my design. The queue needs some kind of flag that says it's available for GETing across the cluster, otherwise you need to re-design your applications to hunt down the queue. I can solve the triggering problem, just trigger locally and have my apps connect to each server, the real issue is the clients connecting in. It does not make sense to me that you can PUT accross the cluster but must attach locally to the QM to get the data. I now need to do a re-design of my client application to obtain it's data. I'm trying to send sensitive medical data where a duplication of data could be fatal and with 1000's of multi-threaded clients coming online in the next 12 months a single server will not cut it. My best solution so far is to have clients connect, discover their queue is not present (CC=2085), build a Permanent Dynamic queue (or something similar) and PUT to a Dist list of queues serviced by a data move app to move the data to the temporary queue. Any other design suggestions are more than welcome. Sid Young Brisbane Australia -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Saturday, 8 November 2003 4:38 AM To: [EMAIL PROTECTED] Subject: Re: Triggering across New Cluster not working [Deutsche Boerse Systems: Virus ch Picking up on what Stefan is indicating. one of the requirements for triggering is that the INIT Q is available and opened for input by some process (hopefully the Trigger monitor) from the LINUX side can the QMGR verify this through the cluster if those attributes are true or false??? bobbee I will say this is an interesting twist to triggering. MAybe you need a process on LINUX that starts the NT process like secured shell. >From: Stefan Raabe <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Triggering across New Cluster not working [Deutsche Boerse > Systems: Virus checked] >Date: Fri, 7 Nov 2003 11:40:55 +0100 > >Sid, > >i hope i understood your environment right: unix and nt in an mqseries >cluster, >local >queue on unix should be triggerd, initqueue is a cluster queue that is >local on >the >nt system. > >triggering is a "local" kind of processing, which means that the initiation >queue has to >be a local queue. triggering will not work when you specify a cluster queue >(which is on a different queuemanager in your case) as initiation queue. > >as others already stated, there may be a missunderstanding of the cluster >functionality >making a queue a cluster queue will make it known within the cluster, but >it is >not >the same as if it is defined in every cluster queuemanager. > >these 600 other queues are local on the nt system? if yes, thats why the >triggering on nt works >for them. if not, please ignore this mail :-) > >regards, stefan >|+++--- ---| >|| [EMAIL PROTECTED]|| >. | >|| .COM.AU | To:[EMAIL PROTECTED] | > | >||| cc:(bcc: Stefan Raabe/DBS/GDB) | > | >|| 07.11.2003 | Subject:Triggering across New| > | >|| 02:26| Cluster not working [Deutsche Boerse Systems:| > | >|| Please | Virus checked] | > | >|| respond to || > | >|| MQSeries List|| > | >|||| > | >|+++--- ---| > > > > > > > > >Howdy all, > >I have just put together a new cluster between two machine (NT4 and Linux) > >The
Peter Gersak/Slovenia/IBM is out of the office.
I will be out of the office starting November 10, 2003 and will not return until November 11, 2003. 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
Triggering query
We have an application that runs on an NT box. Incoming messages sequentially trigger instance of an .EXE to run the app. We periodically see where triggering services just seems to stop (starting the service corrects the problem) and the messages obviously build up in the queue. The application programmer says that they believe the problem occurs when one message starts 2 instances of the .EXE. Has anyone seen or heard of this? Thanks, Dave 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
