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 IndexGeneral IBM MQ SupportMessages consumed by the app, but are still in the queue

Post new topicReply to topic
Messages consumed by the app, but are still in the queue View previous topic :: View next topic
Author Message
MQMB&WAS
PostPosted: Mon May 15, 2017 3:00 pm Post subject: Messages consumed by the app, but are still in the queue Reply with quote

Apprentice

Joined: 12 Jun 2016
Posts: 46

Hello Friends,

we had this situation, there's a mainframe job that reads messages off of a queue, we noticed that the job abended for some reason, we tried to rerun it but it stops again without processing any messages from the queue. Later, it was found that the first 2 messages in the queue were actually consumed by the job but are still sitting in the queue and so the job kept failing. After deleting those first 2 messages from the queue, the job ran fine and processed all the remaining messages from the queue.
So, why would the messages sit in the queue even after the job consumed them? Any input is appreciated. Thanks.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon May 15, 2017 3:08 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7847
Location: US: west coast, almost. Otherwise, enroute.

App developers have choices when 'consuming' messages. Besides the usual destructive consume, there's a browse option, where the message remains in the queue. Some apps are written to browse, and if processing is successful, then destructively consume the message.

Why did the app abend?
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
MQMB&WAS
PostPosted: Mon May 15, 2017 3:18 pm Post subject: Reply with quote

Apprentice

Joined: 12 Jun 2016
Posts: 46

bruce2359 wrote:
App developers have choices when 'consuming' messages. Besides the usual destructive consume, there's a browse option, where the message remains in the queue. Some apps are written to browse, and if processing is successful, then destructively consume the message.

Why did the app abend?



They say it's because of the 2 duplicate messages(which were already processed).
so, if they chose the 'browse and then consume' option, is there a possibility the job didn't run the 2nd call(consume).?
Also, can we check if the sending application wrote the same messages twice to the queue? The messages are persistent, but are they still available in the MQ logs after the job consumed them(so we can check if they were actually written twice)?
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon May 15, 2017 3:47 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7847
Location: US: west coast, almost. Otherwise, enroute.

Who are 'they?'

Yes, I've seen badly-written apps MQPUT the same identical message multiple times.

The consuming app is responsible for detecting duplicate messages, and take appropriate action.

I asked you why the app abended. What abend code?
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Mon May 15, 2017 3:59 pm Post subject: Reply with quote

Sentinel

Joined: 17 Nov 2005
Posts: 861
Location: New Zealand

It seems more likely to me that the consuming application is using MQGMO_SYNCPOINT. This means that only if the application commits the transaction or the job ends normally on z/OS will the messages actually be removed from the queue. If the job abends then the messages will be rolled back and be available next time the application runs. This is correct behaviour for MQ.

However, just because messages are rolled back to the queue doesn't mean they weren't processed. It is up to the application to ensure than the transaction integrity is maintained if that is required.

Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
MQMB&WAS
PostPosted: Mon May 15, 2017 4:44 pm Post subject: Reply with quote

Apprentice

Joined: 12 Jun 2016
Posts: 46

bruce2359 wrote:
Who are 'they?'

Yes, I've seen badly-written apps MQPUT the same identical message multiple times.

The consuming app is responsible for detecting duplicate messages, and take appropriate action.

I asked you why the app abended. What abend code?


ABEND 0016 is the code, Bruce.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon May 15, 2017 6:39 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 7847
Location: US: west coast, almost. Otherwise, enroute.

MQMB&WAS wrote:
bruce2359 wrote:
Who are 'they?'

Yes, I've seen badly-written apps MQPUT the same identical message multiple times.

The consuming app is responsible for detecting duplicate messages, and take appropriate action.

I asked you why the app abended. What abend code?


ABEND 0016 is the code, Bruce.

Is this really an abend code? Or, is it a Condition Code/Return Code from a jobstep?

Abend codes come in two flavors, namely: Snnn and Unnn. Snnn are MVS System abend codes; Unnn are user application abend codes. S0c7, for example, is an MVS system abend code - indicating a decimal arithmetic failure.

If the abend is something else, it comes from an application.

Please post the complete abend error message, include the abend code and reason code.
_________________
I didn't know that Schrdinger had a cat.
Back to top
View user's profile Send private message
zpat
PostPosted: Mon May 15, 2017 10:33 pm Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5568
Location: UK

Worth remembering that MQGMO_SYNCPOINT is the default on z/OS (unlike the other platforms).

If you don't want to conditionally consume the messages, use MQMGO_NOSYNCPOINT.

Browsing messages is generally a bad idea for applications, unless you are an advanced MQ developer and really know what you are doing.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue May 16, 2017 3:51 pm Post subject: Re: Messages consumed by the app, but are still in the queue Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7379

MQMB&WAS wrote:
Hello Friends,

we had this situation, there's a mainframe job that reads messages off of a queue, we noticed that the job abended for some reason, we tried to rerun it but it stops again without processing any messages from the queue. Later, it was found that the first 2 messages in the queue were actually consumed by the job but are still sitting in the queue and so the job kept failing. After deleting those first 2 messages from the queue, the job ran fine and processed all the remaining messages from the queue.
So, why would the messages sit in the queue even after the job consumed them? Any input is appreciated. Thanks.

You've described a classic poisoned message loop.

1. Get message under syncpoint
2. Attempt to process message.
3. Fail because or problem in message or in app itself.
4. Message rolls back. MQ working as designed.
5. Try again, so back to Step 1. Repeat endlessly.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Tue May 16, 2017 6:28 pm Post subject: Re: Messages consumed by the app, but are still in the queue Reply with quote

Padawan

Joined: 25 Mar 2003
Posts: 1739
Location: Melbourne, Australia

PeterPotkay wrote:
You've described a classic poisoned message loop.

1. Get message under syncpoint
2. Attempt to process message.
3. Fail because or problem in message or in app itself.
4. Message rolls back. MQ working as designed.
5. Try again, so back to Step 1. Repeat endlessly.

Browse the msgs on the queue to check the Backout Count. If its greater than zero, its probably a poisoned msg. The usual action is to investigate why its UOW is being backed out (a failure in the consumer app -- check its logs), and fix it. The poisoned msgs should be moved to another queue for further investigation, so that normal queue processing can continue.
_________________
Glenn
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportMessages consumed by the app, but are still in the queue
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.