| Author |
Message
|
| kailashbawane |
 Posted: Thu Jun 14, 2007 7:52 am Post subject: Where does the message go if there is no DLQ at rcvr side? |
 |
|
Acolyte
Joined: 13 Jun 2007
Posts: 51
Location: Pune,INDIA
|
Given that, SDR and RCVR channel is running on QM. At SDR side there is wrong local queue name in the definition of Remote queue, which is not exist at rcvr side. and DLQ is not present on RCVR side. so wher does the message go?
_________________
ITO- MQ ISE.
" Slow n steady always win the race. " |
|
| Back to top |
|
 |
| Toronto_MQ |
| Posted: Thu Jun 14, 2007 8:07 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
Try the Intercommunications guide, namely "Dead-letter queue considerations". It is documented quite clearly.
Steve |
|
| Back to top |
|
|
| tleichen |
| Posted: Fri Jun 15, 2007 5:37 am Post subject: Re: Where does the message go if there is no DLQ at rcvr sid |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| kailashbawane wrote: |
| ... DLQ is not present on RCVR side... |
My first question would be, "Why?" 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jun 15, 2007 5:41 am Post subject: Re: Where does the message go if there is no DLQ at rcvr sid |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| tleichen wrote: |
| kailashbawane wrote: |
| ... DLQ is not present on RCVR side... |
My first question would be, "Why?" |
Because it's not the default. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dgolding |
| Posted: Fri Jun 15, 2007 5:50 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
| I was at one site where DLQs where declared illegal because they can disrupt the serial delivery of messages (if a queue is temporarily full, for instance). I saw a situation like that described above where the messages seemed to disappear - couldn't find them on the transmit queue, and the remote target queue didn't exist. Months later we tried to delete the channel and found it still had uncommitted messages, we did a resolve channel and the messages popped back on the xmit queue, after living in some nether region for several months! |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Fri Jun 15, 2007 6:51 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
Our common practice is also not to define them. We'd rather get alerted of the channel being down and correct the issue at hand instead of having to deal with a bunch of messages on the DLQ.
That said, we do also have some queue managers that do use them. Depends on the requirements.
Steve |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jun 17, 2007 9:59 am Post subject: |
|
|
Guest
|
"...instead of having to deal with a bunch of messages on the DLQ."
You know, there's a dead-letter handler utility (runmqdlq) that will dispose of undeliverable messages based on a script that your system admin prepares. The dead-letter handler is described at length, with example scripts, in the MQ V6 System Admin Guide. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jun 17, 2007 12:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
"...instead of having to deal with a bunch of messages on the DLQ."
You know, there's a dead-letter handler utility (runmqdlq) that will dispose of undeliverable messages based on a script that your system admin prepares. The dead-letter handler is described at length, with example scripts, in the MQ V6 System Admin Guide. |
IIRC the DLQ Handler has been around since at least V 5.3 and the rules definition hasn't changed... The documentation in V6 looks more complete than V5 documentation though.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Tue Jun 19, 2007 8:35 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
Yes, I am aware of it. But why would I implement a DLQ handler when MQ does exactly what I want it to by default? 
As I stated above, that isn't to say we don't use a DLQ on some of our systems. Or a handler. But in most cases, I'd rather see messages get backed up on the xmitq until the problem at hand is resolved.
Like any other topic, this is a shop specific decision, and I'm sure not everyone runs the same way.
Steve |
|
| Back to top |
|
|
| Avikal Jain |
| Posted: Mon Jun 25, 2007 11:52 am Post subject: hi kailash atleast you should have asked me once |
|
|
Apprentice
Joined: 25 Jun 2007
Posts: 39
Location: Pune
|
hi i ve came to know this from intercommunication guide.........
and here it is
if your npmspeed is fast (wchich is default one) and your defpsist is nonpersistence then all such messages are discarded and your channel goes into retrying state
in any other case messages are in dlq at sender side or in xmitq
ba bye |
|
| Back to top |
|
|
| Avikal Jain |
| Posted: Mon Jun 25, 2007 12:01 pm Post subject: here it is as it is copied |
|
|
Apprentice
Joined: 25 Jun 2007
Posts: 39
Location: Pune
|
We recommend that you define a dead-letter queue for each queue manager. If you
do not, and the MCA is unable to put a message, it is left on the transmission
queue and the channel is stopped.
Also, if fast, non-persistent messages (see “Fast, nonpersistent messages” on
page 22) cannot be delivered and no DLQ exists on the target system, these
messages are discarded.
regards keep in touch |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jun 25, 2007 4:07 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Toronto_MQ wrote: |
Yes, I am aware of it. But why would I implement a DLQ handler when MQ does exactly what I want it to by default?
As I stated above, that isn't to say we don't use a DLQ on some of our systems. Or a handler. But in most cases, I'd rather see messages get backed up on the xmitq until the problem at hand is resolved.
|
If one q is full on the receiving QM, and 100 other queues are fine, you prefer to have the incoming channel stop and effectivly lock out the 100 other queues from getting new messages?
This default behaviour is not the same as using a DQL and a handler.
But I undertsand if your QM has only 1 queue and/or message sequence is vital....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jun 25, 2007 6:31 pm Post subject: |
|
|
Guest
|
Just because MQ objects have some attributes with default values, it is your responsibility to ensure that object attributes are set to meet your requirements.
This has been covered many times in these posts: message persistence is completely under the control of the application programmer. When populating the Message Descriptor prior to MQPUT, the programmer must pick one (and one only) of these persistence options:
1) this message is persistent; or
2) this message is non-persistent; or
3) take on the persistence attribute as defined at the queue (definition)
It seems to me that if a message has some importance to the business, it should be persistent (option 1 above). If the message is of no importance, it COULD be non-persistent (option 2 above). If the application wants persistence of the message to depend on a queue attribute that can be altered in real-time, then persistence-as-q-def (option 3).
Hold a gun to my head and I might specify option 3. Other than that, I (the programmer) should specify the persistence that meets business requirements. |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Wed Jun 27, 2007 10:41 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
| PeterPotkay wrote: |
But I undertsand if your QM has only 1 queue and/or message sequence is vital.... |
Bingo. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 27, 2007 2:39 pm Post subject: |
|
|
Guest
|
"...message sequence is vital...."
If message sequence is vital, then the programmer should use message groups with the message sequence number field in the MD.
"if your QM has only 1 queue..."
And, if one day, a new business requirement calls for another queue? Then what?
Nothing replaces good application design and architecture. Making an application depend on something outside the sphere of the application (something as simple as the presence or absence of another queue, or a queue attribute) ) is not good design.
Not understanding the effect the MQAPI calls have on messages, not understanding how the MCA manages its channel, how a queue manager handles undeliverable messages, can only lead to bad application architecture.
MQ manuals are free to download. IBM and others offer training on application design and coding, system administration, security, and more. |
|
| Back to top |
|
|
|
|
