Peter;
Bobbee is right in his response to your post. This is an issue that has
been discussed many times. Even though it is not explicitly stated
in any IBM documentation, if you ask the people who really know the internals of MQSeries, they will say:
" ... the order of the messages are not guaranteed, but the assurance of delivery of that message will occur once and only once. It is possible and reasonable to say that you can put messages to a queue that are in order, but there is no guarantees. You can set up your environment to reach 98+% message ordering, but you can not say 100% and I believe IBM and others would agree. .... "
To see other discussions on the same topic all you need to do is search
the archives for messages that have the word "order" in the subject line.
Bob Kasischke
Integration Products and Services - Enterprise Middleware Services
A.G. Edwards Information Technology Division
314-955-8989
-----Original Message-----
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002 12:23 PM
To: [EMAIL PROTECTED]
Subject: Re: retrieve order
I think it boils down to how you interpret the following line:
> 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.
One Path. If your set up is so that QM1 talks to QM2 (via channel QM1.QM2)
and then QM2 talks to QM3 (via channel QM2.QM3), and you start putting
messages onto QM1 destined for QueueC on QM3, they will get there in order
if you follow the rules listed below. TCP breaking up the message while it
flows between the QMs does not mean you don't have one path.
A channel between 2 QM2 is one path. If you can insure your messages get to
the XMIT queue in order, rest assured they will be on the destination queue
in order (assuming all the MQPUTS were done the same and in 1 UOW).
BUT, I have this question. If I get the messages to the XMITQ in the order
of 1,2,3,4, they will be put to the queue on the other side as 1,2,3,4. Can
my queue on the other side look like this: 1,2,A,3,B,C,4, where the letters
are messages put by another app from another QM, or even the local one?
Notice 1,2,3,4 are still in "order".
The rules say there can only be 1 getting app. Shouldn't there be a rule
also saying that there is only one app putting as well?
Peter Potkay
IBM MQSeries Certified Specialist, Developer
[EMAIL PROTECTED]
X 77906
-----Original Message-----
From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002 12:53 PM
To: [EMAIL PROTECTED]
Subject: Re: retrieve order
Rick, I think that the part below says that if they end up taking different
paths then the order can't be guaranteed:
> 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.
I think it's time for someone from IBM (Paul -- Are you out there?) to enter
into this fray and answer the question... Rebecca
-----Original Message-----
From: Rick Tsujimoto [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 19, 2002 12:41 PM
To: [EMAIL PROTECTED]
Subject: Re: retrieve order
Rebecca,
The assumption is that the requirements set by IBM are met. See extract
from IBM doc below.
"Bullock,
Rebecca (CSC)" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
G> Subject: Re: retrieve order
Sent by:
MQSeries List
<MQSERIES@AKH-Wi
en.AC.AT>
09/19/2002 12:23
PM
Please respond
to MQSeries List
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
**************************************************************************
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
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
***********************************************************************************
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
************************************************************************************
