| Author |
Message
|
| themqstudent |
 Posted: Thu Sep 15, 2011 12:23 pm Post subject: Return Code when attempting PUT on a full queue |
 |
|
Novice
Joined: 26 May 2011
Posts: 22
|
Hello Team,
Is there anyway to get a return code from WMQ when a PUT operation is attempted and the queue is full?
We have a program that GETs messages of a queue and propagates (replicates) them to other queues. However, when one of the queues is full, the replicator C program does not get a non NULL retcode. It looks like the PUT was successful when it really failed. Inspecting the queue does not show the message.
One more thing, we also observed the same behavior when a message is too long for the queue. There is no indication of failure when it really failed since the target queue shows as been empty.
Where do those messages go? Anyway to obtain a return code?
Thank you |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Sep 15, 2011 12:38 pm Post subject: Re: Return Code when attempting PUT on a full queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| themqstudent wrote: |
| However, when one of the queues is full, the replicator C program does not get a non NULL retcode. It looks like the PUT was successful when it really failed. |
There's a bug in your code. WMQ never returns a NULL, always a numeric return code (0 indicating success).
If the queue in question is not hosted by the queue manager accepting the PUT then it's perfectly possible that the queue being put it is not full hence the put will succeed. It's only when the message arrives at the target queue manager that it will determine that the queue is full / message is too long /etc.
| themqstudent wrote: |
| Where do those messages go? |
Wherever your design tells them to go in this circumstance. There are a number of options, including the message being discarded, and all are under your control.
| themqstudent wrote: |
| Anyway to obtain a return code? |
The point of WMQ & decoupling is the putting application should neither know nor care if the message being put has arrived but be confident that it has. It's the responsbility of the WMQ layer to deliver it, and your WMQ design & configuration should assure that messages are handled appropriately no matter the situation (like the target queue being full).
(It's also highly unlikely you'd really want a return code from the put that reflected the situation at the target. Imagine if there's a network delay or heavy traffic and it took the message an extended period to reach it's destination; would you seriously want your application to hang? Or would you want to take advantage of WMQ's queuing and have your application get on with the next message?)
There is a way to achieve what you're talking about but it's not a return code. Look up COA/COD in the documentation, then look up the many postings in this forum from people who have tried to use it and got in a serious tangle. With replies from people like me along the lines of "yes, that happens a lot, it's not the best way. Fix your design & leverage WMQ's assured delivery".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| themqstudent |
| Posted: Fri Sep 16, 2011 8:00 am Post subject: |
|
|
Novice
Joined: 26 May 2011
Posts: 22
|
I'm sorry guys, I confused the issue. I spoke to the programmer and he told me that he IS getting a MQRC_NONE, which I guess translate to 0.
But the point is, if the PUT failed, and I can see that, why is he getting the MQRC_NONE retcode?
I made the queue depth very small, 13. I then proceeded to fill it up.
He then fired-up his program and attempted the PUT. Inspecting the queue I can see that the only messages are my 13 messages and I GET them to ensure that none of these messages have been replaced by the program which is attempting the PUT of totally different messages.
Another test I tried:
Made the message length very small, 6. Then tried PUTting large messages, that failed. However, the program got, again, MQRC_NONE, which tells the program that everything is happiness. However, inspecting the queue no message is found.
We then tried small messages and, as expected, that worked, and the retcode was MQRC_NONE.
So we are getting the same MQRC_NONE when the PUT works and when it fails.
I am running WMQ 7.0.1 under AIX, although I don't think this matter.
Thank you |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 16, 2011 8:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| themqstudent wrote: |
| So we are getting the same MQRC_NONE when the PUT works and when it fails. |
And the queue being put to is on the same queue manager as the application is connected to?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Sep 16, 2011 9:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Or, in other words, is the queue name that the application opens a QLocal or a Qremote?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| themqstudent |
| Posted: Fri Sep 16, 2011 10:33 am Post subject: |
|
|
Novice
Joined: 26 May 2011
Posts: 22
|
Both queues are local queues, under the realm of the same queue manager.
And the C program is running also locally on the same server.
So, everything is local on same server.
Thank you |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 16, 2011 10:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| themqstudent wrote: |
| So, everything is local on same server. |
Make sure you're on the latest maintenance, then raise a PMR. Once you've made absolutely certain the C application is not ignoring any return code due to programming issues.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 16, 2011 11:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
How, exactly, are you issuing the PUT?
Are you doing two separate MQPUT calls, one to each queue?
Or are you doing one MQPUT to a destination list? If so, then your application is not properly handling the MQRC that is coming back, as there will be a set of them - one for each entry in the distribution list.
Can you see the depth of *any* queue increase after the MQPUT that theoretically succeeds?
Are you sure that both of your "local queues under the realm of the same queue manager" are actually QLOCALS? Are you sure the application isn't specifying an Object Qmgr when it does the PUT? |
|
| Back to top |
|
|
| themqstudent |
| Posted: Fri Sep 16, 2011 11:17 am Post subject: |
|
|
Novice
Joined: 26 May 2011
Posts: 22
|
One separate MQPUT is done for each queue.
Yes, we can see the depth of the queue increase as we PUT msgs in it. We can also consume (GET) those mesgs.
100% sure both queues are local and so is displayed by the "dis ql(name)" command.
Furthermore, we don't have any non local queue.
Here is the MQ Version:
Name: WebSphere MQ
Version: 7.0.1.3
CMVC level: p701-103-100813
BuildType: IKAP - (Production)
Thank you all |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 16, 2011 4:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
you might want to upgrade to V7.0.1.6 and see if this still happens. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 16, 2011 4:57 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| you might want to upgrade to V7.0.1.6 and see if this still happens. |
C'mon FJ!  You think this guy is the first one to discover that the q full MQ Reason Code is not working in an MQ version that's been out for over a year? Not that its a good idea to upgrade anyway, but I doubt something this basic is defective in MQ 7.0.1.3 and this is the first time we are hearing of it.
Odds are the program is not coded they way it should be. If you put to a queue and its a local queue on the QM you are connected to, you WILL get a reason code saying the put failed! If you are doing multiple puts, are you keeping a separate area in working storage (agh! my COBOL roots show!) for each Reason Code for each MQPUT? Or are you overwriting the same buffer space for each MQPUT, so if the first one fails and the second one works, the second MQPUT's 0000 Reason Code overwrites the first one's Q_FULL reason code?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 16, 2011 8:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| fjb_saper wrote: |
| you might want to upgrade to V7.0.1.6 and see if this still happens. |
C'mon FJ! You think this guy is the first one to discover that the q full MQ Reason Code is not working in an MQ version that's been out for over a year? Not that its a good idea to upgrade anyway, but I doubt something this basic is defective in MQ 7.0.1.3 and this is the first time we are hearing of it.
Odds are the program is not coded they way it should be. If you put to a queue and its a local queue on the QM you are connected to, you WILL get a reason code saying the put failed! If you are doing multiple puts, are you keeping a separate area in working storage (agh! my COBOL roots show!) for each Reason Code for each MQPUT? Or are you overwriting the same buffer space for each MQPUT, so if the first one fails and the second one works, the second MQPUT's 0000 Reason Code overwrites the first one's Q_FULL reason code? |
Unlikely to happen. In your case you should get a pointer to an array.
On the other hand I don't know how many people actually used 7.0.1.3... from the posts here I believe actual widespread usage started with 7.0.1.4....
However I agree with you. It is more likely that the OP has something wrong in his / her code.
Upgrading never hurts here as there are multiple fixes all over the place, and especially where share conversation is concerned...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Sep 16, 2011 9:01 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I've seen more than one app that counted the MQPUTs just before the MQPUT call was issued, and didn't evaluate the RC at all. I suspect badly coded application.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| themqstudent |
| Posted: Mon Sep 26, 2011 7:15 am Post subject: |
|
|
Novice
Joined: 26 May 2011
Posts: 22
|
OK Team, problem Solved!
We tested the program on other queues under the same conditions/constrains of the queues in questions here. The outcome was good. The program worked.
I then proceeded to compare the queues from which a return code was not been returned and the one that did (worked).
I found the problem was on the non-working queues the DEFPSIST was set to NO. So I changed the field to DEFPSIST(YES), making the queues persistent and it is working fine now. I guess for non persistent queues messages MQ does not return a bad return code, if the queue is full or the message is too long.
I just wanted to let everyone know what happened and thanks everyone. Also, someone might benefit from this thread.
Thanks again |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Sep 26, 2011 7:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| themqstudent wrote: |
I found the problem was on the non-working queues the DEFPSIST was set to NO. So I changed the field to DEFPSIST(YES), making the queues persistent and it is working fine now. I guess for non persistent queues messages MQ does not return a bad return code, if the queue is full or the message is too long.
I just wanted to let everyone know what happened and thanks everyone. Also, someone might benefit from this thread.
Thanks again |
Queues are neither persistent nor non-persistent. Changing the queue attribute did NOT make the queue persistent. This attribute only makes a single message persistent IF the application specified PERSISTENCE_AS_Q_DEF option. The application should pick one of the other options to make a message persistent or non-persistent.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
