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
