| Author |
Message
|
| Esa |
 Posted: Mon Feb 28, 2011 3:01 am Post subject: MQGET node, programatically set GMO and open options |
 |
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Hello,
I am propagating a message from a java compute node to an MQGet node.
The idea is to browse messages, test them and then delete the messages that passed the test.
To be able to do it, I set up GMO programatically. The first message has this GMO:
MQGMO_FAIL_IF_QUIESCING + MQGMO_WAIT + MQGMO_BROWSE_FIRST
Everything goes OK, I get the message, and because it is a match I propagate the message again with this GMO:
MQGMO_FAIL_IF_QUIESCING + MQGMO_WAIT + MQGMO_SYNCPOINT + MQGMO_MSG_UNDER_CURSOR
Now I get an exception with MQRC 2036 NOT_OPEN_FOR_BROWSE.
I debugged the flow and checked the queue atatus with MQ Explorer as I proceeded. Just before entering the MQGet node for the second time the queue had only one open input handle with open options that match my GMO:
Inquire
Browse
Fail if quiescing
After passing the node the queue has two open handles, the new one with these open options:
Save all context
Inquire
Fail if quiescing
Input shared
It seems to me that when an MQGet is entered for the first time (after flow restart), it opens the queue using the options it has been given. If a message is propagated with different GMO, the node opens another handle, but this time with the default options.
Broker version 7.0.0.1
Last edited by Esa on Mon Feb 28, 2011 4:12 am; edited 1 time in total |
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Feb 28, 2011 3:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I would add MQGMO_CONVERT for best practice.
Anyway, I would suggest getting the message by matching the msgid rather than trying to get under the browse cursor. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 28, 2011 3:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The behavior you have claimed here should not be the observed behavior. I suggest you run more tests, collect more traces, and then apply FP2 and open a PMR if the behavior still persists.
You will also need to set the appropriate BROWSE_FIRST/BROWSE_NEXT options. |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Feb 28, 2011 4:06 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| zpat wrote: |
I would add MQGMO_CONVERT for best practice.
|
On Message Broker? I have been under the impression that you need to do it only if you want the broker to run a conversion exit. Which would mean that the broker gets the message without convert option and then convert the message to unicode as a separate step.
| zpat wrote: |
Anyway, I would suggest getting the message by matching the msgid rather than trying to get under the browse cursor. |
That would be less elegant, but in this case it might work because getting by msgid should work with the default open options. I guess I will end up doing it in this way.
| mqjeff wrote: |
You will also need to set the appropriate BROWSE_FIRST/BROWSE_NEXT options.
|
Yes, i have done it, but I left it out of the example as irrelevant. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 28, 2011 4:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
| mqjeff wrote: |
You will also need to set the appropriate BROWSE_FIRST/BROWSE_NEXT options.
|
Yes, i have done it, but I left it out of the example as irrelevant. |
I agree that it's irrelevant to the issue you're discussing. It's not irrelevant to the less skilled poster three years from now who reads this and thinks they don't need to set these, and then runs into issues and reopens this thread asking you how you fixed it.
Like I said - product shouldn't be behaving the way you say it does. Double-check your results, apply FP 2 (or at least review the APARs in FP2) and then open a PMR if it still occurs. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 28, 2011 9:13 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
I would add MQGMO_CONVERT for best practice.
Anyway, I would suggest getting the message by matching the msgid rather than trying to get under the browse cursor. |
Broker best practice says to not have MQ use the convert flag... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Mar 01, 2011 5:08 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Another option to your equation is to use the Filter node to an intermediate queue. For those messages you want to keep, you put them to the queue. For those messages you want to discard, place them in the bit bucket.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Mar 01, 2011 6:54 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| lancelotlinc wrote: |
| Another option to your equation is to use the Filter node to an intermediate queue. For those messages you want to keep, you put them to the queue. For those messages you want to discard, place them in the bit bucket. |
The problem is that I want the destructive get to be backed out in case of an exception so that the matching messages are still available if the flow does a retry. (The flow starts with a FileInput node.)
I have opened a PMR. Until there is a fix available I just skip the MQGMO_MSG_UNDER_CURSOR operation and let all the messages stay in the queue untill they expire. Better do a lot of extra browsing than a lot of extra putting. |
|
| Back to top |
|
|
|
|
