Teriffic thread... The two-queue approach is a good way to assure you don't start processing a group of messages until all the messages in the group have been SENT. But it does not assure that all have arrived. It assures that headers can be processed before data. But it does not assure that headers will be processed in the order sent or that data will be processed in the order sent.
I side with bobbee, but go one step further. If possible, design apps so that arrival order does not matter. If not, design so that arrival order does not affect the outcome. To those ends, standardize on some best practices early-on and minimize surprises after you're in production. > -----Original Message----- > From: Dave Adam [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, September 19, 2002 11:42 AM > To: [EMAIL PROTECTED] > Subject: Re: retrieve order > > > Paul Clarke, since you are less than 100 miles away, how would you like to > drop by when you have some spare time, there are great eating places at > the Mall of America, and if you can bring Chris Frank and Bob Tilton with > you > > this thread has been right on, even with the excerpts from the manuals > > I have already been able to go to other sources and try to build a diagram > of what we have > > history: > > we had 2 sources of input to a message queue and both were IP based on NT > > the receiving end had a trigger queue, but it triggered too many jobs so > they eliminated it and went with a single started task that monitors the > queue all the time > > they still had the out of sequence problem, so they created 2 receiving > queues and load the data to DB2 > > this environment uses our own network, but by the IP address scheme, route > 1 only has T1 paths > > route 2 is a fair distance away and has redundancy and backup (from T1 > right down to dialup) built in > > route 1 does not seem to be having any problems, even with the multiple > paths > > route 2 does experience problems, and MQ is not the only piece that gets > caught in this > > end of history > > the worst part is that I think we are shooting ourselves in the foot > > the contractor that maintains the program said it is set up to only handle > it one way HEADER - DATA - TRAILER - HEADER - DATA - TRAILER - etc... > > anything out of sequence is thrown away ( now there is a new and > innovative approach to the client server world) > > thanks to those on the list, I was given many more questions to ask and > have pinpointed it to the application program > > I especially like the concept of 2 queues, one with control records and > the other with data records and only process the data records when > everything is there > > something about nondestructive reads > > who knows, we may move on to a second MQ application some day > > > Dave Adam > Supervalu Home Office > Project Specialist > (952) 828-4736 > [EMAIL PROTECTED] > > Success is a Journey, not a Destination > > > > > "DeBlassio, Joe" <[EMAIL PROTECTED]> > Sent by: MQSeries List <[EMAIL PROTECTED]> > > 09/19/2002 01:04 PM > Please respond to MQSeries List > > To: [EMAIL PROTECTED] > cc: > Subject: Re: retrieve order > > > > Is Message Grouping available on MQSeries Version 5.3 platform z/OS? > > Thanks. > > -----Original Message----- > From: Paul Clarke [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 19, 2002 6:58 AM > To: [EMAIL PROTECTED] > Subject: Re: retrieve order > > > > Cheers, > P. > > Paul G Clarke > WebSphere MQ Development > IBM Hursley (although currently in Rochester,MN,USA) > > > 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
