My feeling is I have to trust the docs 100%, or not at all for anything. If something conflicts with what the docs say, I want to get to the bottom of it or get to the point where IBM concedes and changes the doc.
If I can't trust the doc on message order, why should I trust it on expiry, or persistence? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -----Original Message----- From: RIBEIRO Paulo Jorge [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 5:05 AM To: [EMAIL PROTECTED] Subject: Re: retrieve order In this particular problem, my advice to you all is: don't trust entirely in what the MQ docs or the MQ consultants say about the message order. Anyone who has huge message exchange between machines in different networks knows that sometimes (0.1% of the cases) the arriving order is not the correct. Protect yourself and use grouping (or some alternative method for message order). Paulo -----Original Message----- From: Stefan Sievert [mailto:[EMAIL PROTECTED]] Sent: 20 September 2002 08:24 To: [EMAIL PROTECTED] Subject: Re: retrieve order 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 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 communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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
