Howdy all,
I am about to change the way I collect messages in all my major processing
applications where message loss is not acceptable (I am using c++), I want
to change to the "browse", "process" and if successful, then delete the
currently "browsed" message, then move to the next
So whic
Oops, scenario2.txt was missing the 'get message under cursor' option and
scenario3.txt was the wrong code. I have corrected them (see attached).
Regards,
Roger Lacroix
At 01:41 AM 8/3/2004, you wrote:
T.Rob,
Excellent. Very well said. I hope Bank of America pays you well. :))
For those that wer
T.Rob,
Excellent. Very well said. I hope Bank of America pays you well. :))
For those that were interested in the GMO settings, I have attached 3 code
C snippets that will demonstrate the 3 scenarios that I listed in my
previous email.
Just to summarize what I have learned from these 3 test scen
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 MQGE
Hello T.Rob,
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 e
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"
RC 2039 means you are trying to do a PUT but to a queue that you have not opened for output. So, remove MQC.MQOO_INPUT_AS_Q_DEF from your #2 program and give it a try again.
Regards,
RuziSrinivas Amarnadh <[EMAIL PROTECTED]> wrote:
Hi
I am trying to do two thing
#1
One thread is read
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 mess
Hello.
The text below can be found in the AMI support pack (MA0F) page. Based on that
and on another reply I had from Hursley we are recommending our customers to
move away from the AMI.
Heinz Klein
OLTP Tecnologia & Solucoes Ltda.
Sao Paulo/SP - Brasil
-
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
o
> What I am trying to figure out is: How do you move
> the destructive get cursor?
> i.e.
> How do I position the destructive get cursor at
> message #5 without first deleting messages #1,2,3
> and 4?
Roger,
Short answer - you don't. The type of GET you are using always operates at the head
of
I will be out of the office starting 08/02/2004 and will not return until
08/04/2004.
I will be out of the office visiting customer sites on 8/2 and 8/3. I will
not have access to e-mail during this period. I will respond when I
return. If the matter is urgent, call and leave a message at 518-
Title: RE: AMI
Hi all
Can anybody tell me if AMI is still supported by IBM ? Last I heard that IBM have stopped development on it (therefore no new releases or CSDs) or have I heard wrong.
And would it be a good decision to go the AMI route due to all the benefits it provides ?
Are there an
Hi
I am trying to do two thing
#1
One thread is reading a
Queue continuously. I am checking whether the messages are available in the
queue or not by using a method currentDepth(). If messages are available reading
the messages else do nothing.
Here is the code used to
open queue and ge
14 matches
Mail list logo