Your distributed guy is not necessarily correct regarding the ordering of messages. If messages go onto a dead-letter-queue due to some transient problem (e.g. queue full) then the order will be out when you increase the queue depth and retry the dlq messages with a dead-letter handler. Also messages going through a cluster may end up out of sequence (even if they end up at the same destination QMgr, they may take different routes through the network).
This all depends upon your physical intercommunication which the distributed guy should not depend upon really (I guess you realised this from your fragile solution comment). Also, if you have multiple reply messages to an original request, you could "chain" them together with the following: MQPUT Request MQGET 1st Reply CorrelId=Request MsgId MQGET 2nd Reply CorrelId=1st Reply MsgId MQGET ... MQGET nth Reply CorrelId=n-1th Reply MsgId You would need some mechanism to know when the last message in the reply chain is received. The "last message in group/segment" options are flags already available with grouping/segmentation so that won't be a problem when using the MQ supplied options. Regards John Scott IBM Certified Specialist - MQSeries ARG Infrastructure Services - Middleware -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Dockray Sent: 27 March 2006 17:26 To: [email protected] Subject: Re: Ordered messages ---- Original message ---- >Date: Fri, 24 Mar 2006 16:21:10 -0500 >From: "Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]> >Subject: Re: Ordered messages >To: [email protected] > >"why reinvent the wheel" >That's about all we can say without knowing specifically what he is coming up with to compare to what MQ already has built in. > >-----Original Message----- [snip] Well, basically, he is sending a large reply message from a z/OS application to a distributed platform application in a series of smaller messages. On the distributed platform, the messages will be retrieved using a CORRELID that has been set to the MSGID of the originating request message. He was concerned about the reassembly of the message. The developer on the distributed platform told him not to worry about it, the physical and logical order will be the same. It was also suggested that he could put a sequence number in the message data, if he wanted greater assurance that all messages had been received. This differs from the sample program I gave him that I had developed as an exercise but never implemented. That program used the logical ordering feature. Thus the question from him to me, what are the trade offs? I don't see the point in reinventing the wheel and depending on the environment to ensure order seem like a fragile solution. -- Tom Dockray Carnell 9-D 215-204-4931 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html - -------------------------------------------------------------- Check our latest prices and full range at http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and/or confidential, and is intended exclusively for the addressee. Unauthorised disclosure, copying or distribution of the contents is strictly prohibited. The views expressed may not be official policy, but the personal views of the originator. If you have received this message in error, please advise the sender by using the reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for viruses, high-risk file extensions, and inappropriate content. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
