Try very very hard to get rid of message affinity wherever possible. Makes scaling up much easier.
If you can't then Dennis's method is as good as any. If using clustering your putting app will need to use MQOO_BIND_ON_OPEN to avoid messages in a given batch going to different queue managers. Also beware of Priority and MQGET's when using browsing. Regards Tim A -----Original Message----- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Thursday, 11 November 2004 10:40 AM To: [EMAIL PROTECTED] Subject: Re: Message Sequence Problem Message order can be preserved by following certain conditions, most which are detailed in the various programming guides. Any designs depending on those conditions, however, have potential to break if those conditions change, either within your enterprise or in a future product release. Down the road, who will remember that some application developed 5 years ago may go south if another channel is added between two qmgrs or workload increases and two programs are needed to send messages. On the otherhand, it's trivial to use logical message groups or a msgid/correlid mechanism to unconditionally preserve message order. Take the time now and save problems later. A simple and elegant method is: On put, let MQ generate unique msgid's On first message of sequence, put a special value in correlid On each message after the first, put msgid of the previous message in the correlid Send trailer message to indicate no more messages in the sequence. On first get, retrieve first message with special value in correlid On subsequent gets, use msgid from previous msg to selectively retrieve next message Continue until trailer message is encountered Regards, Dennis -----Original Message----- From: Wesley Shaw [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 10, 2004 12:38 PM To: [EMAIL PROTECTED] Subject: Message Sequence Problem The messages being processed are not in order when they are processed from the MVS local queue, but processing the same request through a local queue on the Unix box, the messages are processed in order. What are the rules for processing of message in order? Seems like all the same Priority would process FIFO. Can we guarentee the order of the message to be got same as they were put ? MVS view of 416345 Local Queue All 153 bytes except the * record which is 9 bytes, all messages Priority 1 with persistence Transmit queue MSGDLVSQ(PRIORITY), Local Unix queue MSGDLVSQ(PRIORITY) MVS Local queue Message delivery sequence FIFO The first list is a local queue on MVS which is remote to the putting application. 00416345RECC,CMPL000003CMPL 20041108115902200411081225512004 00416345RECC 000003CMPL 20041108115902200411081225512004 00416345RECC 000002ARRV 20041108115902200411081225512004 00416345RECC 000002ENRT 20041108115902200411081225512004 00416345RECC 000002DISP 2004110811590220041108122551 00416345RECC 000002ASSN 20041108115902 00416345* 00416345RECC 000001UNAS This second view is a local queue on Unix of the same put process as above. Unix view of 416345 9 00416345RECC CMPL000003CMPL ' 10 00416345RECC 000003CMPL 11 00416345RECC 000002ARRV 12 00416345RECC 000002ENRT 13 00416345RECC 000002DISP 14 00416345RECC 000002ASSN 15 00416345RECC 000001UNAS 16 00416345* 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 email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material. 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
