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 >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 process to run is on the NT machine as well as the trigger monitor and >the >initiation queue that it monitors. I have place a copy of the process >definition on both machine and the queue with triggering turned on is >located on >the linux box. All queues have the cluster defined. > >I can see the required queues in the cluster using display qc(*) but when >I put >stuff into that queue (on the linux box) the triggering does not appear to >work. > >I have 600 other queues still on the NT box which are triggering fine > >Any Ideas...Please!!!! > > >Sid Young >Brisbane >Australia > > >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 _________________________________________________________________ Frustrated with dial-up? Get high-speed for as low as $26.95. https://broadband.msn.com (Prices may vary by service area.) 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
