Jack,
Your rant is not misdirected. I certainly can appreciate it. But, I think
it's well understood that when data traverses a network, such as the
internet, the packets can take a variable number of routes. But, I also
believe that the MCA's ensure each other, e.g. syncpoints, that what was
sent did in fact get there, in the order sent (again assuming the stated
reqm'ts in the doc were met). Otherwise, we would see time-outs, DLQ
messages, etc..
Jack Armstrong
<jackcarmstrong@MIND To: [EMAIL PROTECTED]
SPRING.COM> cc:
Sent by: MQSeries Subject: Re: retrieve order
List
<[EMAIL PROTECTED]
C.AT>
09/19/2002 12:51 PM
Please respond to
MQSeries List
We're hung up on the horns of semantics again....
IBM claims (and delivers) sequential retrieval of messages "from the queue,
in the
order in which they arrived...". (My words, not IBM legalese technical
writing). In
other words, by default it's a FIFO (first-in-first-out) queue. There are
NO
quarantees that multiple messages will arrive in the exact order in which
they were
sent except for very special conditions.
IF a large set of conditions (as included in a previous message on this
subject)
are met -- especially a SINGLE path from sender to receiver, THEN and only
then
will they be quarantined to arrive in the order as sent. TCP/IP does
assemble
multiple packets in order to enable single messages to arrive unmangled by
the
packetizing process, but this only applies to a single 'message'.
I agree that reading between the lines of the IBM fine print can be
difficult, but
this is a fundamental fact of life with any asynchronous messaging system
that
operates over any multi-route, variable latency transport (i.e., the
Internet).
We're talking Messaging 101 here, and IBM needs to look at the messages
posted here
by their paying customers who have not had these concepts adequately
explained - in
sales pitches, manuals, and/or training classes. Telling them to RTFM
doesn't cut
it anymore - these are bright people who are solving significant technical
issues
with a complex product, but all too often without a solid foundation in the
base
technology.
<RANT MODE=OFF>
Jack Armstrong
Rick Tsujimoto wrote:
> 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
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
