Absolutely, Brian. And I am a total advocate of designing applications to be free of dependencies on physical aspects. I just wanted to point out that there is a guarantee of sequential delivery, which in many 'simple' MQ configurations (no clusters etc.) is all that you need. Anyway, I think that everything has been said... ;-) Cheers, Stefan
>From: "Brian S. Crabtree" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: retrieve order >Date: Thu, 19 Sep 2002 21:50:57 -0400 > >Stefan > >There are 2 aspects to this > >1. Design for the correct sequence >2. Expected behaviour of MQSeries > >If messages have to be processed in a particular sequence then coding has >to >be done to ensure this. Out of the box MQ will not guarantee this. The >previously documented behaviour and restrictions say that in these >circumstances then you should expect messages to arrive sequentially > >Given your scenario then messages should arrive sequentially. If the MQ >infrastructure is modified to allow multiple paths to the destination queue >then anything can happen > >Brian S. Crabtree >EAI Consultant > >----- Original Message ----- >From: "Stefan Sievert" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Thursday, September 19, 2002 7:07 PM >Subject: Re: retrieve order > > > > Rick, > > I don't know if I have put together all the pieces of this thread >correctly, > > but my idea after that (and before that) is still that the physical >network > > is no constraint at all. I look at it from the MCA perspective: the >sending > > MCA doesn't even send message 2 if the receiver has received message 1. >If > > the receiver sees message 3 before message 2, it will throw up and >produce > > message AMQ9526 Message sequence number error for channel '&3'. > > So how would you be able to get out of sequence messages in your >receiving > > application caused by the physical network layout? > > Stefan > > > > > > >From: Rick Tsujimoto <[EMAIL PROTECTED]> > > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: Re: retrieve order > > >Date: Thu, 19 Sep 2002 12:58:12 -0400 > > > > > >The issue is does IBM need to update their doc? It makes no mention of >the > > >physical network as a constraint in order to retrieve messages > > >sequentially. > > > > > > > > > > > > > > > RIBEIRO Paulo > > > Jorge To: > > >[EMAIL PROTECTED] > > > <pribeiro@ENABLE cc: > > > R.PT> Subject: Re: retrieve >order > > > Sent by: > > > MQSeries List > > > <MQSERIES@AKH-Wi > > > en.AC.AT> > > > > > > > > > 09/19/2002 12:31 > > > PM > > > Please respond > > > to MQSeries List > > > > > > > > > > > > > > > > > >Please don't forget that TCP/IP networks are based on dynamic paths. If >you > > >send msg-1,2,3, the message 1 and 3 can arrive in 10 seconds, and >message >2 > > >can take 10 hours to arrive. It is obvious that if MQ receives the >message > > >3 > > >before message 2, it will make it available. For the specific problems > > >where > > >you must assure the receiving order, MQ offers the grouping feature. > > >Therefore, you have both options available. > > > > > > > > >Paulo > > > > > > > > > > > >-----Original Message----- > > >From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]] > > >Sent: 19 September 2002 17:24 > > >To: [EMAIL PROTECTED] > > >Subject: Re: retrieve order > > > > > > > > >Not if they don't take the same path -- Rebecca > > > > > >-----Original Message----- > > >From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]] > > >Sent: Thursday, September 19, 2002 12:09 PM > > >To: [EMAIL PROTECTED] > > >Subject: Re: retrieve order > > > > > > > > >Brian, > > > > > >If the user sends msg-1, 2, 3 and gets 1, 3, 2 doesn't that conflict >with > > >the IBM doc's claim for sequential retrieval? > > > > > > > > > > > > > > > "Brian S. > > > Crabtree" To: > > >[EMAIL PROTECTED] > > > <ourtown@EARTHLI cc: > > > NK.NET> Subject: Re: retrieve >order > > > Sent by: > > > MQSeries List > > > <MQSERIES@AKH-Wi > > > en.AC.AT> > > > > > > > > > 09/19/2002 11:47 > > > AM > > > Please respond > > > to MQSeries List > > > > > > > > > > > > > > > > > >Rick > > > > > >What you quoted doesnt conflict with what Dave said > > > > > > > > >----- Original Message ----- > > >From: "Rick Tsujimoto" <[EMAIL PROTECTED]> > > >To: <[EMAIL PROTECTED]> > > >Sent: Thursday, September 19, 2002 9:59 AM > > >Subject: Re: retrieve order > > > > > > > > > > Dave, > > > > > > > > If what you say is true, then IBM has to update its claim about > > >sequential > > > > retrieval. No where in that claims does it make exceptions due to >the > > > > physical network. I would have thought that TCP/IP would reassemble >the > > > > packets in their proper order regardless how they traversed the >network. > > > > But, may IBM can clarify that. > > > > > > > > Here's the IBM claim: > > > > > > > > 2.1.14.1 | Sequential retrieval of messages > > > > > > > > | If an application puts a sequence of messages to the same > > >destination > > >| > > > > queue, those messages can be retrieved in sequence by a single > > >application > > > > | with a sequence of MQGET operations, if the following conditions >are > > >met: > > > > All of the put requests were done from the same application. > > > > All of the put requests were either from the same unit of work, or >all > > >the > > > > put requests were made outside of a unit of work. > > > > The messages all have the same priority. > > > > The messages all have the same persistence. > > > > For remote queuing, the configuration is such that there can only be >one > > > > path from the application making the put request, through its queue > > > > manager, through intercommunication, to the destination queue >manager > > >and > > > > the target queue. > > > > The messages are not put to a dead-letter queue (for example, if a >queue > > >is > > > > temporarily full). > > > > The application getting the message does not deliberately change the > > >order > > > > of retrieval, for example by specifying a particular MsgId or >CorrelId > > >or > > > > by using message priorities. > > > > Only one application is doing get operations to retrieve the >messages > > >from > > > > the destination queue. If this is not the case, these applications >must > > >be > > > > designed to get all the messages in each sequence put by a sending > > > > application. > > > > Note: Messages from other tasks and units of work may be >interspersed > > >with > > > > the sequence, even where the sequence was put from within a single >unit > > >of > > > > work. If these conditions cannot be met, and the order of messages >on > > >the > > > > target queue is important, then the application can be coded to use >its > > >own > > > > message sequence number as part of the message to assure the order >of > > >the > > > > messages. > > > > > > > > > > > > > > > > > > > > Thomas Dunlap > > > > <tsdunlap@WORLDN To: > > >[EMAIL PROTECTED] > > > > ET.ATT.NET> cc: > > > > Sent by: Subject: Re: retrieve > > >order > > > > MQSeries List > > > > <MQSERIES@AKH-Wi > > > > en.AC.AT> > > > > > > > > > > > > 09/19/2002 09:02 > > > > AM > > > > Please respond > > > > to MQSeries List > > > > > > > > > > > > > > > > > > > > > > > > Dave, > > > > > > > > This is an indication that you are sending across a "dynamically >routed" > > > > network, like the Internet. > > > > Since congestion may cause the messages to take different path >through > > >the > > > > network, they may > > > > arrive in the receiving system in a different order. > > > > > > > > This is the purpose of Messages Groups in WebSphere MQ (MQSeries) to > > > > resolve. Unfortunately > > > > this support was not introduced into WebSphere MQ for z/OS V5.3. >Unless > > > > you are at the latest > > > > and greatest WebSphere MQ has to offer your choices are limited. >You > > >can > > > > devise a way to handle it yourself or send a single message. > > > > > > > > I can not imagine why you receive duplicate data, unless it is sent > > >twice > > > > or possibly MS MSMQ may be utilized as the sender. Sometimes I have > > >seen > > > > MSMQ resend data. > > > > > > > > Dave Adam wrote: > > > > > > > > we have a system that sent a message > > > > > > > > header > > > > data > > > > data > > > > trailer > > > > > > > > and came into the mainframe program as > > > > > > > > header > > > > data > > > > trailer > > > > data > > > > > > > > is this a common thing, > > > > > > > > or should the receiving program be intelligent enough to >figure > > >out > > > > what should have been > > > > > > > > oh, by the way, some times they say they get duplicate info > > > > > > > > Dave Adam > > > > Supervalu Home Office > > > > Project Specialist > > > > (952) 828-4736 > > > > [EMAIL PROTECTED] > > > > > > > > Success is a Journey, not a Destination > > > > > > > > -- > > > > Regards, > > > > Thomas Dunlap Chief Technology Officer [EMAIL PROTECTED] > > > > Themis, Inc. http://www.themisinc.com 1 (800) 756-3000 > > > > > > > > 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 may contain privileged or > > >confidential information. It is solely for use by the individual for >whom > > >it is intended, even if addressed incorrectly. If you received this >e-mail > > >in error, please notify the sender; do not disclose, copy, distribute, >or > > >take any action in reliance on the contents of this information; and >delete > > >it from your system. Any other use of this e-mail is prohibited. Thank >you > > >for your compliance. > > > > > >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 > > > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > 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 _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
