T.rob,
The alternative I proposed is pretty much what you described in the second
method, e.g. the msgids would be well known, and therefore could be used to
remove a set of messages. I wholly agree with you that a generalized queue
program, e.g. utility, should not be reliant upon the "position" of
messages. But, as you well know, applications can be designed around some
pretty strange requirements, and it seems that what Roger wants could, in
fact, be contrived. Even though IBM advocates certain coding/design
practices, there are rare instances where a different approach may yield
something good, or useful. I don't know if this is one of those cases, or
not, but it does seem interesting.
"Wyatt, T.rob"
<[EMAIL PROTECTED]
OFAMERICA.COM> To
Sent by: MQSeries [EMAIL PROTECTED]
List cc
<[EMAIL PROTECTED]
n.AC.AT> Subject
Re: Message under cursor
08/02/2004 02:33
PM
Please respond to
MQSeries List
<[EMAIL PROTECTED]
n.AC.AT>
Rick,
The problem with this approach is that MQ gives you two types of GET and
neither involve a cursor that you control directly. The first type of GET
is that you take whatever the next message is that the QMgr gives you in
the current logical view of the queue. In this method, you GET messages
from the head of the queue and advance only by doing destructive GETs. The
other method is where you GET a message that you know for sure you want
because you already browsed to it or because you know the MsgID or
CorrellID. There is no option to browse to a certain position and then
destructively GET successive messages.
In your scenario where you get exclusive control of the queue, one way to
simulate what Roger wants to do would be to do GETs under syncpoint to lock
up the messages you want to keep, and then doing GETs outside of syncpoint
to delete the target messages. A BACKOUT then restores the unwanted
messages to the queue.
But the takeaway from this is that the concept of your "position" in a
queue is not generally valid. It may very well be valid in the context of
specific applications where the variables are well controlled (i.e. - you
know and control the readers and writers, the message flows are well
understood and everybody plays by the rules), but a generalized queue
program should not rely on position. This is especially true for a utility
program such as you might get from Capitalware or Reconda, for example. In
this case, the vendor does not know beforehand whether queues are FIFO or
Priority, whether logical or physical ordering is used, whether messages
will be segmented or grouped, how many readers and writers are active, and
so on. In this context it is difficult to infer anything about the "next"
messages, and cursor position is an abstract concept at best.
Messages, on the other hand, are concrete. So IBM gave us a way to process
all the messages (successive GETs) or to process only selected messages
that we already know something about (because we browsed them or know the
MsgID and/or CorrelID), but not the ability to select messages based solely
on position. The fact that IBM does not provide a cursor positioning
mechanism seems, IMHO, appropriate and the behavior Roger describes is what
I would expect.
-- T.Rob
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Rick
Tsujimoto
Sent: Monday, August 02, 2004 12:32 PM
To: [EMAIL PROTECTED]
Subject: Re: Message under cursor
T.rob,
If many ways a queue is similar to a random access file, where a message
can be read sequentially, or via a "key",deleted (destructive read) and
written by one or more apps. Normally, when a file is being updated,
exclusive control is established beforehand to ensure the integrity of the
operation. What if Roger did the following:
1. browse till he found the(starting) essage he wants
2. record the "key" (msgid) of the message
3. reopen the queue with exclusive control
4. perform the destructive gets, using the msgid he store earlier to
establish his position
This would effectively prevent new messages from being inserted in the
queue, which could effect his logical view of the message order. I haven't
tried it out, so it's simply a "what if" proposition. One drawback is the
small window that's opened between the close and re-open of the queue for
exclusive control, where messages could be inserted/gotten.
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
