Re: Message under cursor

[Sid . Young]

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 which scenario do I use ?


Sid






-Original Message-
From: Roger Lacroix [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 3 August 2004 3:42 PM
To: [EMAIL PROTECTED]
Subject: Re: Message under cursor


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 scenarios:
-  Originally, when I was doing my testing, I thought that the 'Get message
under cursor' call moved the Destructive Get cursor. I was wrong. It uses
the Browse cursor. Basically, I was wondering if anyone knew of a trick to
get it to move (except for specifying a search criteria). But it appears
there is none.

- Therefore, if I want to delete messages # 5,6 & 7 (not knowing the MsgId
or CorrelId) in a queue with 10 messages, I will have to browse one by one
until I get to # 5. Then use Get message under cursor, followed by Browse
Next then Get message under cursor, etc...

In a couple of weeks, I will be making an announcement and my questions and
test scenarios will become clear.  'Crack'  - there's the whip, now back to
coding and documentation. Oh god I hate writing documentation!!!  :))

Regards,
Roger Lacroix


At 04:06 PM 8/2/2004, you wrote:
>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

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

Re: Message under cursor

[Roger Lacroix]

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 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 scenarios:
-  Originally, when I was doing my testing, I thought that the 'Get message
under cursor' call moved the Destructive Get cursor. I was wrong. It uses
the Browse cursor. Basically, I was wondering if anyone knew of a trick to
get it to move (except for specifying a search criteria). But it appears
there is none.
- Therefore, if I want to delete messages # 5,6 & 7 (not knowing the MsgId
or CorrelId) in a queue with 10 messages, I will have to browse one by one
until I get to # 5. Then use Get message under cursor, followed by Browse
Next then Get message under cursor, etc...
In a couple of weeks, I will be making an announcement and my questions and
test scenarios will become clear.  'Crack'  - there's the whip, now back to
coding and documentation. Oh god I hate writing documentation!!!  :))
Regards,
Roger Lacroix
At 04:06 PM 8/2/2004, you wrote:
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


gmo.Options = MQGMO_WAIT   /* wait for new messages   */
   + MQGMO_BROWSE_FIRST
   + MQGMO_CONVERT; /* convert if necessary*/
gmo.WaitInterval = 15000;  /* 15 second limit for waiting */


while (CompCode != MQCC_FAILED)
{
buflen = sizeof(buffer) - 1; /* buffer size available for GET   */

memcpy(md.MsgId, MQMI_NONE, sizeof(md.MsgId));
memcpy(md.CorrelId, MQCI_NONE, sizeof(md.CorrelId));

md.Encoding   = MQENC_NATIVE;
md.CodedCharSetId = MQCCSI_Q_MGR;

MQGET(Hcon,/* connection handle */
  Hobj,/* object handle   

Re: Message under cursor

[Roger Lacroix]

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 scenarios:
-  Originally, when I was doing my testing, I thought that the 'Get message
under cursor' call moved the Destructive Get cursor. I was wrong. It uses
the Browse cursor. Basically, I was wondering if anyone knew of a trick to
get it to move (except for specifying a search criteria). But it appears
there is none.
- Therefore, if I want to delete messages # 5,6 & 7 (not knowing the MsgId
or CorrelId) in a queue with 10 messages, I will have to browse one by one
until I get to # 5. Then use Get message under cursor, followed by Browse
Next then Get message under cursor, etc...
In a couple of weeks, I will be making an announcement and my questions and
test scenarios will become clear.  'Crack'  - there's the whip, now back to
coding and documentation. Oh god I hate writing documentation!!!  :))
Regards,
Roger Lacroix
At 04:06 PM 8/2/2004, you wrote:
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
gmo.Options = MQGMO_WAIT   /* wait for new messages   */
   + MQGMO_BROWSE_FIRST
   + MQGMO_CONVERT; /* convert if necessary*/
gmo.WaitInterval = 15000;  /* 15 second limit for waiting */


while (CompCode != MQCC_FAILED)
{
buflen = sizeof(buffer) - 1; /* buffer size available for GET   */

memcpy(md.MsgId, MQMI_NONE, sizeof(md.MsgId));
memcpy(md.CorrelId, MQCI_NONE, sizeof(md.CorrelId));

md.Encoding   = MQENC_NATIVE;
md.CodedCharSetId = MQCCSI_Q_MGR;

MQGET(Hcon,/* connection handle */
  Hobj,/* object handle */
  &md, /* message descriptor*/
  &gmo,/* get message options   */
  buflen,  /* buffer lengt

Re: Message under cursor

[Wyatt, T.rob]

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

Re: Message under cursor

[Pavel Tolkachev]

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 etc.depends on this cursor's position. What it does not 
explain is what happens to the cursor after getting a message with 
MQGMO_MSG_UNDER_CURSOR -- 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.

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 
:-)

Pavel







  "Wyatt, T.rob"
  <[EMAIL PROTECTED]To:   [EMAIL PROTECTED]
  MERICA.COM> cc:
  Sent by: MQSeries   Subject:  Re: Message under cursor
  List
  <[EMAIL PROTECTED]
  C.AT>


  08/02/2004 02:33 PM
  Please respond to
  MQSeries List






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 lis

Re: Message under cursor

[Rick Tsujimoto]

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

Re: problem in reading messages

[Ruzi R]

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 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 get message.
MQQueue aMQLocalQueue   =null;
  int iOpenOptionsLocal;
  
  public MQReaderThread()
  {
    iOpenOptionsLocal =   MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_INQUIRE ;
  }
  
  public void _openConnection()
  {
    try
    {
    System.out.println("Connecting...");
    MQEnvironment.hostname=strHostname;
    MQEnvironment.port=1414;
    MQEnvironment.channel=strChannel;
    MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY,MQC.TRANSPORT_MQSERIES);
    aMQManager=new MQQueueManager(strQManager);
    aMQLocalQueue=aMQManager.accessQueue(strLocalQueue,  iOpenOptionsLocal,null,null,null);  
    System.out.println("Connection Opened.");
    
    }
    catch (Exception e)
    {
  e.printStackTrace();
    }
    
  }
#2
While running the first program I am executing the second program which put the messages on the same queue.
Here is the code to put the message.
int iOpenOptionsLocal;
  public MYMQTest()
  {
   iOpenOptionsLocal= MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_OUTPUT ;
  }
  public void openConnection()
  {
 
  try{
    MQEnvironment.hostname  =strHostname;
    MQEnvironment.port  =1414;
    MQEnvironment.channel   =strChannel;
    MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY,MQC.TRANSPORT_MQSERIES);
    aMqm=new MQQueueManager(strQManager);
 
    System.out.println("Inside Connection Opened.");
    aMqlqueue=aMqm.accessQueue(strLocalQueue,iOpenOptionsLocal,null,null,null);
   // aMqlqueue=aMqm.accessQueue("SYSTEM.DEFAULT.LOCAL.QUEUE",iOpenOptionsLocal,null,null,null);
    System.out.println("Connection Opened.");
    }
    catch(Exception e)
    {
  e.printStackTrace();
    }
  }
 
I tried with different open options, but I couldn't get the solutions.
I am getting a MQException with the id 2039.
 
Can any one clearly explain what could be the problem? 
 
 
Thanks and regards
 
M.Srinivas Amarnadh
iflex Solutions Ltd.,
Millenium Towers,
Kundalahalli Main Road,
Bangalore - 560 037.
Phone : 57596000 , 22086000
Extn - 6616
 

Re: Message under cursor

[Wyatt, T.rob]

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

Re: AMI

[Heinz Klein]

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
-
After June 2003, IBM has no plans to enhance the AMI with any new functions or
platforms. IBM will however continue to support the AMI as described in the
Technical Support sectioin below.
We would recommend that customers do not use the AMI for any new projects and do
not extend usage in existing projects. This recommendation does not apply to
functions shipped by other IBM products, such as DB2, that have made use of the
AMI. IBM is working to ensure that these products are able to provide the same
functionality as today without the AMI.
Govender Magendran wrote:
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 any pitfalls if AMI was used ?
Your input would invaluable.
Thanks, in advance.
Magendran Govender
Please click on the following link to read the Old Mutual legal notice:

Alternatively, send a "blank" e-mail to


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

Re: Message under cursor

[Rick Tsujimoto]

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.




 "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 11:37
 AM


 Please respond to
   MQSeries List
 <[EMAIL PROTECTED]
 n.AC.AT>






> 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 the queue.  Intuitively one would suppose no cursor would be
necessary for this operation.  The fact that one exists and the discussion
in the APR suggest there would be an operation to move it but this is not
the case.

The non-browse cursor (and the lack of an operation to position it) make
more sense in the context of multiple concurrent users, logical ordering
and/or priority delivery.  When you do a GET, the cursor works it's way
down the queue skipping any messages under synchpoint, deleting any expired
messages and, when logical ordering is used, skipping otherwise eligible
messages looking for the first message in a group.  On top of all that, the
QMgr needs too be able to insert messages into the queue that are of a
higher priority than the message under the GET cursor.  This creates a case
where inserts cause the GET cursor position to change relative to the
*start* of the queue but not to the end.

So the non-browse cursor is really there for the QMgr to manage internal
structures and make them appear (possibly to many simultaneous threads) as
a sequential queue of messages when in fact they are not.  There is no
concept of a "next message" as in a sequential file because the cursor
position changes relative to both the beginning and end of the queue at any
given moment and even iterates backwards to traverse an out-of-order
logical group.

If you think about it, you don't *really* even get to position the browse
cursor.  When the GET occurs - whether it's in a browse context or not -
the QMgr decides what the next message is and that's where your cursor is
set.  Depending on your options, the cursor may have advanced or retreated
in the queue, you don't really know and it's not decided until the call is
executed.

So you don't really have a user-managed cursor in this system, ever.  You
have only a message that was retrieved via a (possibly destructive) GET.
The "cursor" is only your ability to decide whether you will accept a newer
or higher priority messages on the next GET.

-- 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

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

Re: Message under cursor

[Wyatt, T.rob]

> 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 the queue.  Intuitively one would suppose no cursor would be necessary for this 
operation.  The fact that one exists and the discussion in the APR suggest there would 
be an operation to move it but this is not the case.

The non-browse cursor (and the lack of an operation to position it) make more sense in 
the context of multiple concurrent users, logical ordering and/or priority delivery.  
When you do a GET, the cursor works it's way down the queue skipping any messages 
under synchpoint, deleting any expired messages and, when logical ordering is used, 
skipping otherwise eligible messages looking for the first message in a group.  On top 
of all that, the QMgr needs too be able to insert messages into the queue that are of 
a higher priority than the message under the GET cursor.  This creates a case where 
inserts cause the GET cursor position to change relative to the *start* of the queue 
but not to the end.

So the non-browse cursor is really there for the QMgr to manage internal structures 
and make them appear (possibly to many simultaneous threads) as a sequential queue of 
messages when in fact they are not.  There is no concept of a "next message" as in a 
sequential file because the cursor position changes relative to both the beginning and 
end of the queue at any given moment and even iterates backwards to traverse an 
out-of-order logical group.

If you think about it, you don't *really* even get to position the browse cursor.  
When the GET occurs - whether it's in a browse context or not - the QMgr decides what 
the next message is and that's where your cursor is set.  Depending on your options, 
the cursor may have advanced or retreated in the queue, you don't really know and it's 
not decided until the call is executed.

So you don't really have a user-managed cursor in this system, ever.  You have only a 
message that was retrieved via a (possibly destructive) GET.  The "cursor" is only 
your ability to decide whether you will accept a newer or higher priority messages on 
the next GET.

-- 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

Brian E Wilson/Albany/IBM is out of the office.

[Brian E Wilson]

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-487-6221.

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

Re: AMI

[Govender Magendran]

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 any pitfalls if AMI was used ?


Your input would invaluable.


Thanks, in advance.


Magendran Govender



Please click on the following link to read the Old 
Mutual legal notice:  
Alternatively, send a "blank" e-mail to  

 

problem in reading messages

[Srinivas Amarnadh]

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 get message.

MQQueue aMQLocalQueue  
=null;

  int iOpenOptionsLocal;

  

  public
MQReaderThread()

  {

    iOpenOptionsLocal
=   MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_INQUIRE ;

  }

  

  public void
_openConnection()

  {

    try

    {

    System.out.println("Connecting...");

    MQEnvironment.hostname=strHostname;

    MQEnvironment.port=1414;

    MQEnvironment.channel=strChannel;

    MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY,MQC.TRANSPORT_MQSERIES);

    aMQManager=new
MQQueueManager(strQManager);

    aMQLocalQueue=aMQManager.accessQueue(strLocalQueue,  iOpenOptionsLocal,null,null,null);  

    System.out.println("Connection
Opened.");

    

    }

    catch (Exception
e)

    {

  e.printStackTrace();

    }

    

  }

#2

While running the first
program I am executing the second program which put the messages on the same
queue.

Here is the code to put the
message.

int iOpenOptionsLocal;

  public MYMQTest()

  {

   iOpenOptionsLocal=
MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_OUTPUT ;

  }

  public void
openConnection()

  {

 

  try{

   
MQEnvironment.hostname  =strHostname;

   
MQEnvironment.port  =1414;

   
MQEnvironment.channel   =strChannel;

   
MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY,MQC.TRANSPORT_MQSERIES);

    aMqm=new
MQQueueManager(strQManager);

 

   
System.out.println("Inside Connection Opened.");

   
aMqlqueue=aMqm.accessQueue(strLocalQueue,iOpenOptionsLocal,null,null,null);

   //
aMqlqueue=aMqm.accessQueue("SYSTEM.DEFAULT.LOCAL.QUEUE",iOpenOptionsLocal,null,null,null);

   
System.out.println("Connection Opened.");

    }

    catch(Exception e)

    {

 
e.printStackTrace();

    }

  }

 

I tried with different open
options, but I couldn't get the solutions.

I am getting a MQException
with the id 2039.

 

Can any one clearly explain
what could be the problem? 

 

 

Thanks and regards

 

M.Srinivas
Amarnadh

iflex
Solutions Ltd.,

Millenium Towers,

Kundalahalli
  Main Road,

Bangalore - 560 037.

Phone :
57596000 , 22086000

Extn - 6616