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 » General IBM MQ Support » DLQ reasons for Solaris, MQRC 0x000000bc

Post new topic  Reply to topic Goto page Previous  1, 2
 DLQ reasons for Solaris, MQRC 0x000000bc « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Thu Apr 23, 2015 7:06 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

fjb_saper wrote:
So you prefer preventing access to the DLQ than having programs written the correct way? Because we all know once developers can get away with it, there is no turning back...


I prefer preventing access to the DLQ AND having programs written the correct way.

Apps, including WMB and JMS based ones, don't need access to the DLQ, if their backout queues are set up correctly.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Thu Apr 23, 2015 7:15 am    Post subject: Reply with quote

Grand Master

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

I'm not sure there is any right answer and it's probably up to the installation to make their own mind up about what the rules are. Personally I don't really see a big problem with applications putting messages to the DLQ but I agree that there is the potential for a badly written application to cause problems. However, a badly written application can cause problems in all sorts of ways without going near the DLQ.

To me the backout queue and DLQ should be used for two distinct purposes. The backout queue is, as it's name suggests, the place where poisoned mesages or messages which can't yet be processed should be put. The DLQ should be used if an application gets a message on its input queue that it thinks has been routed to it incorrectly and doesn't even know how to process, much as the sender channel or trigger monitor does.

Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
exerk
PostPosted: Thu Apr 23, 2015 7:23 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

PaulClarke wrote:
...The DLQ should be used if an application gets a message on its input queue that it thinks has been routed to it incorrectly and doesn't even know how to process, much as the sender channel or trigger monitor does.

In which instance a back-out queue is surely more appropriate, even if that application is coded to ensure it puts a DLH on the message, which then begs the question, which Reason Code to use?

I'm with PetePotkay on this one, I don't want anything going to the DLQs I control unless it's an MQFB message from a triggered application failure etc. I want the DLQ handler to be process anything that drops there and not have 'clutter' on the DLQ.

But the right answer I suppose is whatever the site standard says it is...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » General IBM MQ Support » DLQ reasons for Solaris, MQRC 0x000000bc
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.