ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Challenge Forum » Challenge Question - 12 / 2008

This forum is locked: you cannot post, reply to, or edit topics.  This topic is locked: you cannot edit posts or make replies. Goto page Previous  1, 2
 Challenge Question - 12 / 2008 « View previous topic :: View next topic » 
Author Message
Amazer
PostPosted: Tue Feb 10, 2009 4:06 am    Post subject: MQRC 2033 but queue has messages Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Tue Feb 10, 2009 5:39 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
gbaddeley
PostPosted: Tue Feb 10, 2009 6:58 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
Amazer
PostPosted: Tue Feb 10, 2009 9:58 pm    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Wed Feb 11, 2009 6:06 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Amazer
PostPosted: Wed Feb 11, 2009 9:45 pm    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Wed Feb 11, 2009 10:35 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.  This topic is locked: you cannot edit posts or make replies. Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » Challenge Forum » Challenge Question - 12 / 2008
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.