Title: Message
Well
put. I would just argue that the incremental cost of programming
a reliable message sequence is usually too small to worry about. The
biggest expense is the time wasted trying to convince someone it's
important. So, if you're in a position to introduce best
practices when nobody's looking, I'd go
for it.
The list
of the requirements for sequential processing does exist and is the final
word. If any of the restrictions are not met then IBM does not guarantee
(assure?) that messages will be received in the same sequence as they were
sent. In general, if a network is involved, the requirements are not met
(though there are special circumstances when, even with a network, they are
met). There is anecdotal evidence out there that, when in that unguaranteed
state, the likelihood of having the sequence changed is definitely nonzero
(people have demonstrated that it does happen) but is very small. The
rule of thumb I use is that if the sequence of the messages is crucial to the
business application then the application must incorporate code to ensure the
messages are ordered appropriately. It is an appropriate topic for
discussing cost/benefit: just how critical is having one message out of
sequence out of 'n' messages? More than one design team has concluded
that a rare error, probably corrected manually, was more acceptable than the
cost and processing overhead of ensuring every message was in order.
Wes Poteet -- IBM Global Services -- WMQ
Support
IBM Certified Specialist - MQSeries; Solutions Expert - MQSeries;
Developer - MQSeries
Wes Poteet/Boulder/IBM 877-513-1981 (t/l 273-1135)
Bassett, NE [[Central Time]]
"Wesiderata" on BlueNet --
see w3.irc.ibm.com -- rooms #MQSeries and #WesPoteet
"[EMAIL PROTECTED]"
for e-mail and SameTime "WesPoteet" on AOL IM, Yahoo IM, or MSN
IM
Moral certainty is always a sign of cultural inferiority. The more
uncivilized the man, the surer he is that he knows precisely what is right and
what is wrong. All human progress, even in morals, has been the work of
men who have doubted the current moral values, not of men who have whooped
them up and tried to enforce them. The truly civilized man is always skeptical
and tolerant, in this field as in all others. His culture is based on "I am
not too sure."
-- H. L.
Mencken
-----
Forwarded by Wes Poteet/Boulder/IBM on 2004-11-10 05:08 PM -----
Rick Tsujimoto
<[EMAIL PROTECTED]>
Sent by: MQSeries List
<[EMAIL PROTECTED]>
2004-11-10 03:17 PM
|
Please respond
to
MQSeries List |
|
|
To
| [EMAIL PROTECTED]
|
|
cc
|
|
|
Subject
| Re: Message Sequence
Problem |
|
The DQM has a small list of requirements that
pertain to sequential retrieval of messages. If you followed them, you
should have no problems. I have an ftp-like application and never had an
issue with message order. Of course, there are those who advocate using
msgid/correlid, but that shouldn't be necessary as long as the requirements
stated in the DQM are met.
Wesley Shaw
<[EMAIL PROTECTED]>
Sent by: MQSeries List
<[EMAIL PROTECTED]>
11/10/2004 03:37 PM
|
Please respond
to
MQSeries List
<[EMAIL PROTECTED]> |
|
|
To
| [EMAIL PROTECTED]
|
|
cc
|
|
|
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
