Here's what the MQ Intercommunication Guide has to say: [quote] 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:
(1) All of the put requests were done from the same application. (2) 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. (3) The messages all have the same priority. (4) The messages all have the same persistence. (5) 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. (6) The messages are not put to a dead-letter queue (for example, if a queue is temporarily full). (7) 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. (8) 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. [/quote] Now, I think the term 'path' in number (5) is referring to MQ configuration, not the physical network path. As the MCA's perform handshaking and the sender does not start to send the next message before it received an acknoledgement from the receiver, sequence will be maintained, even if the packets take different routes. If you think about processing in a MQ cluster, for example, messages may very well be load balanced and - based on machine utilization - be delayed and delivered out of sequence. I might be wrong, but that's my understanding of 'path' in that context. What really puzzles me is the comment: "oh, by the way, some times they say they get duplicate info". Now that shouldn't happen under any circumstances, I think. At least not caused by queue manager or channel processing. Sounds more like an application issue. Stefan >From: "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: retrieve order >Date: Thu, 19 Sep 2002 12:23:36 -0400 > >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 _________________________________________________________________ Join the world s largest e-mail service with MSN Hotmail. http://www.hotmail.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
