| Author |
Message
|
| kanwisch |
 Posted: Mon Sep 22, 2003 11:50 am Post subject: |
 |
|
Newbie
Joined: 16 Jul 2003
Posts: 2
|
Unlike you, we have NO tools that are not included with the "standard" IBM package. So, administration is more complex. Yes, affinity is key here too, and I suspect that will be the case for several other apps coming down the pipe.
Our pluses are that all messages are smallish, and persistent, so message loss would never be an issue.
I saw that several others had suggested the lack of DLQ be a decision of last resort, but I fail to see the reason still. It fits this sort of circumstance perfectly. The only downside is the increased quantity of administration necessary to monitor the channel. After all, that's the real issue: the channel stops and everything backs up. Essentially, in an sequentially-oriented design, that's really what you want to happen anyway, isn't it?
There, is, granted, the added overhead of dedicated channels, which I can see ballooning into a major issue, so I suppose for that reason alone, I'm happy the internal folks figured out a messenging method that solves the affinity issue internally, as opposed to "changing" the std MQ implmentation (using DLQs) to fit their need (a common problem in-house).
Thanks.
_________________
I can't wait until the meek inherit the earth. The stupid currently have it. |
|
| Back to top |
|
 |
| simon.starkie |
| Posted: Mon Sep 22, 2003 1:56 pm Post subject: |
|
|
Disciple
Joined: 24 Mar 2002
Posts: 180
|
A couple of personal opinions are in order:
1. Tivoli is, IMHO, only a marginal "tool". I'd much rather have contact admin. Regardless, you need some automation to keep an eye on the xmit queues, channels and DLQ's (if assigned) if you want to have a well run shop.
2. The default when you create a QMgr is for no DLQ to be associated. DLQ is not required.
3. It is a myth that runnning without a DLQ is a decision of last resort. I think what has happened over the years is that this myth has evolved which says your are only safe if you assign a DLQ and people have long since stopped challenging the reasons behind the myth. As I said, I got a good answer from the head of development for MQ at Hursley that it is perfectly safe to run without a DLQ. For over a year, we have run like this without any problems. Remember, DLQ's are for UNDELIVERABLE messages. The DLQ does not get "corrupted" messages. The DLQ is not a safty net which catches messages that would othewise be lost (what kind of "assured delivery" would that be if they were lost?). A DLQ is not a safety net for bad code (i.e. silent discard). With a DLQ, undeliverable messages, for example because the target queue is full or the rare case of EBCDIC to ASCII translation fails because of bad data (which is why it's a bad idea to translate on the channel...) are captured. Without a DLQ, the same situations cause everything to stop and this preserves message affinity, which is preferable to messages being processed out of sequence via a DLQ.
Thank your luck stars you are not dealing with MSMQ where the DLQ is not optional. Or the MSMQ Bridge which has several DLQ's.
HTH |
|
| Back to top |
|
|
| sanvaranasi |
| Posted: Mon Aug 30, 2004 5:16 am Post subject: Will the codes for put retrn a success if no dlq defined |
|
|
Novice
Joined: 24 Feb 2004
Posts: 10
Location: india
|
| Quote: |
| Basically, non-persistent messages were discarded if they could not be delivered and there was no DLQ available to the local Queue Manager. |
What i want to know is that if the message cannot be delivered and also there is no DLQ defined on the local queue manager then what is the reason and completion code that the applicaiton which trying to do a put will get. Will it still get a successful put reason and completion codes? [/quote] |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Aug 30, 2004 5:31 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
If the queue you are doing the MQPUT to is a remote or qmgr alias and the message is successfully placed on the xmitq defined in their definition then you will get a Successful completion and reason code.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| sanvaranasi |
| Posted: Mon Aug 30, 2004 5:47 am Post subject: will the appln doing the put still get a successful ret code |
|
|
Novice
Joined: 24 Feb 2004
Posts: 10
Location: india
|
Maybe i did not put it across correctly:
Q1) Even if you do not define a DLQ isn't there a default DLQ?
Q2) Yes i am trying to put to a remote queue on another machine.
All queues local and remote are non persistent. There is no explicit dlq defined. The channel is defined as FAST and messages are nonpersistent.
a) In this situation for some reason if the message cannot be delivered to the remote queue will the message get discarded or will it remain in the XMITQ.
b) if it gets discarded and does not land up in the XMITQ then will the application doing the put still get a successful return code.
What i am trying to understand is that if a message gets discarded because of the above reason then wont the applicaton that was doing the put get to know about it through a different reason and completion code? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 30, 2004 5:50 am Post subject: Re: will the appln doing the put still get a successful ret |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| contact admin wrote: |
Q1) Even if you do not define a DLQ isn't there a default DLQ? |
Not that I know of, no.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sanvaranasi |
| Posted: Mon Aug 30, 2004 5:55 am Post subject: |
|
|
Novice
Joined: 24 Feb 2004
Posts: 10
Location: india
|
| Quote: |
| Not that I know of, no. |
What is the SYSTEM.DEAD.LETTER.QUEUE then? |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Aug 30, 2004 5:58 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
The SYSTEM.DEAD.LETTER.QUEUE is created by default, however unless you specify it in the qmgr settings then it is not used.
Unless you do this under runmqsc or the windows gui equiv then it will not be used.
alt qmgr DEADQ("SYSTEM.DEAD.LETTER.QUEUE)
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 30, 2004 6:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Is S.D.L.Q created automatically?
I didn't think it was, unless you specified it when you were doing crtmqm or etc...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sanvaranasi |
| Posted: Mon Aug 30, 2004 6:05 am Post subject: |
|
|
Novice
Joined: 24 Feb 2004
Posts: 10
Location: india
|
| Yes the S.D.L.Q is created automatically and i did not have to specifically create it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Aug 30, 2004 11:48 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
Q2) Yes i am trying to put to a remote queue on another machine.
All queues local and remote are non persistent. There is no explicit dlq defined. The channel is defined as FAST and messages are nonpersistent.
a) In this situation for some reason if the message cannot be delivered to the remote queue will the message get discarded or will it remain in the XMITQ.
b) if it gets discarded and does not land up in the XMITQ then will the application doing the put still get a successful return code.
|
App1 connects to QM1 to put to a remote queue def that points at QM2. If the MQPUT can get the message succesfully to the XMITQ on QM1, the app is returned a good RC on its MQPUT.
The SNDR MCA on QM1 then MQGETs this NonPersistent message from the XMITQ and sends it -***outside of SYNCPOINT control***- to the RCVR MCA on QM2 over a FAST channel.
If the message is lost by the network in flight, the message is gone.
If the message arrives on QM2, but cannot be PUT to the destination queue, it is attempted to be put to the DLQ. But if the QM has no DLQ assigned to it (when the RCVR MCA starts up the 1st thing it does is MQINQ the QM to see what the DLQ is), the the RCVR MCA takes this NP message from this FAST channel and throws it away.
Consider making your channels NORMAL, instead of FAST. When you weigh all the PROS and CONS, NORMAL channels are almost always better. All our channels, except for one overlapping cluster, are NORMAL.
The default is FAST I assume because IBM likes MQ to look as fast as possible if comapnies are doing performance testing while comparing it to other products?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sanvaranasi |
| Posted: Mon Aug 30, 2004 7:00 pm Post subject: |
|
|
Novice
Joined: 24 Feb 2004
Posts: 10
Location: india
|
Thanks Peter.  Very well worded. The mechanism is very clear now. |
|
| Back to top |
|
|
|
|
