I must say we send 100's of 1000's of messages each day from an os/390 qmgr
to an RS6000 AIX qmgr and we have never experienced a message not arriving
in the 'sent sequence'. We have only have a single apps active and sending
to a queue. We never have multiple apps active and sending to the same
queue we of course could have multiple app active but they would have
different destination queues.
In CICS we do have multiple active programs but they are sending a single
message and retrieving a single message so potential sequencing problems
here.
We in batch are mainly sending files and the files are surrounded by a
header and trailer and the sequence has always been maintained.
So far so good in a simple MQ application like ours...
we do not use priority just basic vanilla mq gets and puts
Robert Broderick <[EMAIL PROTECTED]>@AKH-WIEN.AC.AT> on
09/19/2002 11:20:25 AM
Please respond to MQSeries List <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: retrieve order
I don't know.....but as long as I have been in MQ, there was always the
spoken rule that no matter what you did, don't rely on the order. If you
start with that premis, then you can architect/code effectively AND with
the
notion that some day some genious will come along and change your network
configuration and it will not break your application. Why code for
absolutes?
bobbee
>From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: retrieve order
>Date: Thu, 19 Sep 2002 13:22:51 -0400
>
>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
_________________________________________________________________
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
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
