Hi Pavel, I think I have to address these in context to see below...
> Well, although this is true that there is no direct controls > of the cursor, the documentation is specific enough about the > behavior of the cursor. It calls it "browse cursor" and > explains how exactly the behavior of MQGET with > MQGMO_MSG_UNDER_CURSOR, MQGMO_BROWSE_MSG_UNDER_CURSOR > etc.depends on this cursor's position. Ok, with you so far... > What it does not > explain is what happens to the cursor after getting a message > with MQGMO_MSG_UNDER_CURSOR The manual lists only two ways to move the cursor: "The message pointed to by the browse cursor is the one that was last retrieved using either the MQGMO_BROWSE_FIRST or the MQGMO_BROWSE_NEXT option." Since the cursor is moved only by a browse, a successful destructive GET points to a non-retrievable message. The manual says that "If the browse cursor is not currently pointing to a retrievable message, an error is returned by the MQGET call." So after getting a message with MQGMO_MSG_UNDER_CURSOR, the cursor does not move nor does it point to a retrievable message. > -- and Roger's experiments seem > to show some contradictory behavior -- although he has not > confirmed all the MQGMO options he used in every scenario yet. When he browsed to a message and then issued non-browse GET calls, the messages were delivered from the head of the queue. When he used MQGMO_BROWSE_NEXT followed by MQGMO_MSG_UNDER_CURSOR he got the target messages. The only contradiction I saw was an expectation that a non-browse GET would honor the browse cursor and that doing a non-browse GET would advance the browse cursor. But the manual contains a paragraph that says "Note that the browse cursor is not moved by nonbrowse MQGET calls using the same Hobj handle." This is why I thought Roger was seeing the correct and expected behavior all along. > BTW, you mentioned that using priorities may make the cursor > concept 'abstract' but priorities are almost ignored when you > use MQGMO_BROWSE_NEXT; basically, you will never get a higher > priority message until you reset the cursor, say, with > MQGMO_BROWSE_FIRST. This is the documented behavior but I > learned this hard way.. So, I would say, using the cursor may > make priority concept abstract, not other way around :-) Small clarification here but I mentioned priority along with logical/physical ordering, message grouping, message segmentation and concurrent usage as a few of the factors contributing to the dynamic nature of the browse cursor. The premise was that position (as opposed to message content) is a poor way to select messages for deletion from the queue. If you throw away all the factors *except* priority, it's a completely different illustration. -- T.Rob 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
