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
