|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Challenge Question - 12 / 2008 |
« View previous topic :: View next topic » |
Author |
Message
|
Amazer |
Posted: Tue Feb 10, 2009 4:06 am Post subject: MQRC 2033 but queue has messages |
|
|
Novice
Joined: 10 Feb 2009 Posts: 24
|
I faced a similar situation recently on z/OS but with a difference. The application code was properly written, and there were messages in the queue but mqrc=2033 was being received at intermittent intervals.
Can a queue object that is damaged give rise to this condition?
Re-creating the queue solved the issue!!
I would be interested to know your comments.
Thanks.
- Amazer |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Feb 10, 2009 5:39 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
Can a queue object that is damaged give rise to this condition? |
Unlikely. But I suppose anything is possible.
ReasonCode 2033 means no message available. One of the possible causes is that the queue is empty. The other, and more common reason, is that no message in the queue matched MsgID, CorrelId, GroupId. _________________ 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 |
|
 |
gbaddeley |
Posted: Tue Feb 10, 2009 6:58 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
bruce2359 wrote: |
...ReasonCode 2033 means no message available. One of the possible causes is that the queue is empty. The other, and more common reason, is that no message in the queue matched MsgID, CorrelId, GroupId. |
Or there are messages on the queue (curdepth > 0) but they are uncommited (putter has UOW still in progress) or expired (yet to cleaned up). _________________ Glenn |
|
Back to top |
|
 |
Amazer |
Posted: Tue Feb 10, 2009 9:58 pm Post subject: |
|
|
Novice
Joined: 10 Feb 2009 Posts: 24
|
Thanks for your prompt replies.
No, I was not reading for a specific msg-id or correl-id. Both were set to none since all messages were being read from the request queue. Also the uncommitted messages situation is unlikely since the program was encountering 2033 and was being triggered continuously in a loop. In fact it was using so much of CPU that it had to be disabled for other applications to get any response.
The problem initially occurred because a DB table had no space and that resulted in a rollback. After the table space had been increased, the queue object started behaving abnormally. There was one other transaction in a different CICS region which was processing 10000 to 15000 messages. I understand that was also looping and had been disabled.
I don't know whether that had any impact on this application, but I have my doubts.
Since we are using MQ ver 5.2 on z/OS, could that have caused this problem? I believe damaged queues have been caused even in ver 6.0.
- Amazer
 |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Feb 11, 2009 6:06 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
Also the uncommitted messages situation is unlikely since the program was encountering 2033 and was being triggered continuously in a loop. In fact it was using so much of CPU that it had to be disabled for other applications to get any response.
The problem initially occurred because a DB table had no space and that resulted in a rollback. After the table space had been increased, the queue object started behaving abnormally. |
If the DB update and MQGET were in the same UofW that was rolled back, then the message being restored to the queue would cause the trigger to fire, which would cause the program to be launched, and it would MQGET the same message, and encounter the same DB out of space condition again and again. This is 'poison message' behavior, although in this case it is the DB that caused the behavior.
Your application could have anticipated this 'poison message' type of problem. Refer to the WMQ APG and MQSC manuals. Look at these fields: backout_count, backout_threshold, backout_requeue_qname. _________________ 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 |
|
 |
Amazer |
Posted: Wed Feb 11, 2009 9:45 pm Post subject: |
|
|
Novice
Joined: 10 Feb 2009 Posts: 24
|
True. That is what I thought initially. But later, when the space of the table had been increased and this problem repeated (intermittently), I had second thoughts.
For a while I thought that the program was looping because of some code error until someone pointed out that it was actually trying to get a message, encountering 2033, closing queue and exiting (but repeating that in quick succession). All this was taking place with messages present in the queue (depth > 0). That led me to believe that the queue had been damaged which proved right subsequently. Since the moment we created the queue again, the program worked alright without any change.
The problem could recur though. But at least we have a workaround.
Thanks to you all for your valuable suggestions.
This proved to be a second challenger to the challenger query!! What say?!!
Query: How can we preserve the damaged queue for further testing? That is, can we rename a queue in z/OS?
- Amazer |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Feb 11, 2009 10:35 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
That led me to believe that the queue had been damaged which proved right subsequently. |
Sorry, but you didn't prove anything. You especially didn't prove that the queue was damaged.
Tonite I proved that my phone doesn't receive calls when it's on the kitchen table. How? It didn't ring until I moved it to a nearby chair, then it rang. _________________ 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 |
|
 |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|