Roger,
The point I was trying to make is you can quite easily protect yourself
from an inadvertently successful get however unlikely by working under
synpoint and backing out. Also people tend to have a habit of running
things just when you dont want them to be hence dropping the put.
Neither of my comments were meant to be unpleasant criticism just
observations on ways to make the utility even more generic.
Regards
Tim A
Roger Lacroix
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
ALWARE.BIZ> cc:
Sent by: MQSeries Subject: Re: Expiration Question
List
<[EMAIL PROTECTED]
C.AT>
12/03/2003 12:38
Please respond to
MQSeries List
Guys,
The original question made no mention of the application running while
Jim's 'reaper' program ran (maintenance mode). The solution I gave was
based on the mainframe application being stopped.
Also, my solution has been tested on mainframe queues with indexing both on
and off (and it works just fine).
Neil, I don't know what you mean by this comment:
>> You should consider doing the GET with both the correlid and msgid
>> set to special values, rather than just the correlid, so that the
>> index cannot be used. Alternatively, you could perform the GET
>> twice, once with correlid set and once with msgid set.
As I said in my original post, the CorrelID MUST BE unique. Putting
phrases like "King of the world", "I drive 65", "Rock & Roll", will most
certainly be unique from a business point of view that is. <grin>
There is no real need to do a search by MsgID and CorrelID but if you
really want to then specify both MatchOptions (and issue only one MQGET).
i.e.
MatchOptions = MQMO_MATCH_MSG_ID + MQMO_MATCH_CORREL_ID;
One more thing, queues on the mainframe can ONLY be index by MsgID or
CorrelID but not both.
later
Roger...
At 07:14 PM 3/11/2003, you wrote:
>And one further point:
>
>The destructive GET (on a mainframe) would actually have had to read the
>message in order for it to be removed.
>
>This means that on the mainframe, you may need to be careful of queue
>indexing.
>
>You should consider doing the GET with both the correlid and msgid set to
>special values, rather than just the correlid, so that the index cannot be
>used. Alternatively, you could perform the GET twice, once with correlid
>set and once with msgid set.
>
>As Tim says, you need to operate explicitly under syncpoint control and
>check for a message, then backout if a message was retrieved.
>
>Regards... Neil Casey.
>
>
>
> Tim Armstrong
> <[EMAIL PROTECTED] To:
> [EMAIL PROTECTED]
> OM> cc:
> Sent by: MQSeries Subject: Re: Expiration
> Question
> List
> <[EMAIL PROTECTED]
> n.AC.AT>
>
>
> 12/03/2003 10:03
> Please respond to
> MQSeries List
>
>
>
>
>
>
>Actually the MQPUT may be dangerous if an application doing generic MQGETS
>is running against the queue. Getting a specific message with a
>non-existent MsgId and CorrelId should work, but to make it safer it needs
>to do an MQBACK if a message is actually retrieved.
>
>Regards
>Tim A
>
>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
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
