MQSeries.net :: View topic - Should the DLQ on a Queue Manager *must* be a local queue on

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Should the DLQ on a Queue Manager *must* be a local queue on

Goto page Previous 1, 2, 3, 4, 5 Next

Should the DLQ on a Queue Manager *must* be a local queue on

« View previous topic :: View next topic »

Author

Message

mqdev

Posted: Wed Mar 14, 2012 7:05 am Post subject:

Centurion

Joined: 21 Jan 2003
Posts: 136

Yes.
mqrc 2082

2082 0x00000822 MQRC_UNKNOWN_ALIAS_BASE_Q

And in this case, it is misleading as the Base_Q is a Cluster Q which is "known" to the QM. I have seen this error before in similar situations.

Can you replicate my setup and prove that DLQ *can* be a non-local Q (say a Cluster Q or QRemote or a QAlias pointing to a Cluster Q)?

I am convinced that IBM designed the product to have DLQ to be a local Q and has said so in the manual.

bruce2359

Posted: Wed Mar 14, 2012 7:07 am Post subject:

Poobah

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

mqdev wrote:

bruce:

I changed deadq thrice
1. to point it to a Cluster Q (ENTERPRISE_DLQ) known to the QM
2. to point it to a local object - QAlias which points to the Cluster Q
3. to point it to a truely local Q - local_dlq

If you read through my last post - these are the tests I did to check if my setup "works" - again please read through my earlier posts as to what I precisely mean by "works".

If you read your own post, it reads that you altered the qmgr deadq attribute three times in a row, and not part of three test scenarios. I/we can only know what you tell us. We technical folks tend to take posts literally.

You might want to consider offering TEST1 SCENARIO, with the objects and values for that TEST1. Then, TEST2 SCENARIO, with only those objects and values for TEST2. And so on. This may entail a bit more clarity of thought on your part - along with a bit more typing.

Precision, please.
_________________
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.

mqjeff

Posted: Wed Mar 14, 2012 7:21 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

I think one of the difficulties that is being exposed here is that the current state of things represents a change in behavior.

It did not used to be a strict requirement that the Dead Letter Queue should be a QLOCAL.

However, as the documentation shows, this is now a firm and fixed requirement.

And, as discussed, there are many very good reasons for this to be an actual requirement. It does no good to try and send undeliverable messages through a network link to a queue manager that is unavailable.

mqdev

Posted: Wed Mar 14, 2012 7:25 am Post subject:

Centurion

Joined: 21 Jan 2003
Posts: 136

I can say this: This forum used to a body of knowledge helping folks get over their technical problems. Now it somehow morphed into a body of egoistic individuals who assume they know it all and the guys asking questions are idiots to be asking questions! I dont mean to start a flaming war.

So you want to take the challenge to prove that DLQ can be a non-local Q?

bruce2359

Posted: Wed Mar 14, 2012 7:50 am Post subject:

Poobah

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

mqdev wrote:

You are too charming. Please come back any time.
_________________
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.

bruce2359

Posted: Wed Mar 14, 2012 7:54 am Post subject:

Poobah

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

On second thought: when you next return, be precise.

Tell us that you don't want any input on your basic understanding of things WMQ. Tell us that you don't want any input of your basic design.

Tell us (me) that you don't want to take the time to carefully document what you've tried, and carefully document the results.

Tell us that we must re-read your post until we understand what you want. No questions.

Tell us, precisely, that all you want is your specific technical problem solved - no other BS.
_________________
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.

fjb_saper

Posted: Wed Mar 14, 2012 8:55 am Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

mqdev wrote:

It may be known to you the cluster admin... but is it know to the local qmgr? Using different tools, can you put a message to it? And if not why do you expect the qmgr to be able to do so (just because you named it DLQ)?

Until you have resolved all the problems and can put a message to the queue using any of the tools, it will not work as DLQ...

This is why I usually prefer a QRemote to a QAlias when looking at cluster queues.

Have fun

_________________
MQ & Broker admin

mqdev

Posted: Wed Mar 14, 2012 9:19 am Post subject:

Centurion

Joined: 21 Jan 2003
Posts: 136

dis qa(loca*) all
1 : dis qa(loca*) all
AMQ8409: Display Queue details.
QUEUE(LOCAL.QA.TO.CLDQ) TYPE(QALIAS)
ALTDATE(2012-03-12) ALTTIME(11.35.26)
TARGET(ENTERPRISE_DLQ) CLUSNL( )
CLUSTER( ) CLWLPRTY(0)
CLWLRANK(0) DEFBIND(OPEN)
DEFPRTY(0) DEFPSIST(NO)
DEFPRESP(SYNC) DEFREADA(NO)
DESCR( ) GET(ENABLED)
PUT(ENABLED) PROPCTL(COMPAT)
SCOPE(QMGR) TARGTYPE(QUEUE)

dis qc(ENTERPRISE_DLQ)
2 : dis qc(ENTERPRISE_DLQ)
AMQ8409: Display Queue details.
QUEUE(ENTERPRISE_DLQ) TYPE(QCLUSTER)
ALTDATE(2012-03-12) ALTTIME(10.29.16)
CLUSDATE(2012-03-12) CLUSTER(POC)
CLUSQMGR(QM_FR) CLUSQT(QLOCAL)
CLUSTIME(10.35.3

CLWLPRTY(0)
CLWLRANK(0) DEFBIND(OPEN)
DEFPRTY(0) DEFPSIST(NO)
DEFPRESP(SYNC) DESCR( )
PUT(ENABLED) QMID(QM_FR_2012-03-12_10.18.16)

Does this prove that the QM is aware of the Cluster Q? I did verify this by putting a msg using amqsput.

The ENTERPRISE_DLQ is just a ordinary queue which aggregates all the DLQ messages across the board. Specifically it is not a Dead-Letter-Queue on the QM it is hosted. The design was to make the DLQs on each QM point to a Central Clustered Q (ENTERPRISE_DLQ) so all msgs get to a central point.

I did hear all your well meaning criticisms of this approach but like I already mentioned, the train has left the station!

bruce2359

Posted: Wed Mar 14, 2012 9:48 am Post subject:

Poobah

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

mqdev wrote:

Your demonstration of putting a message to an alias that resolves to a cluster object (where the real queue lives on another qmgr) merely demonstrates how the qmgr deals with application-level objects.

Keep in mind that a DLQ is a special-purpose object, with specific use for by and for the qmgr and MCAs on this qmgr. The qmgr expects its DLQ to be a real local queue on this qmgr.

LOCAL.QA.TO.CLDQ is a local alias object definition on this qmgr, but it does NOT have as its target a real local queue on this qmgr.

ENTERPRISE_DLQ is a not a QLocal object on this qmgr. Rather, it is a cluster object definition - held in the PR - and does NOT resolve to a real local queue object on this qmgr. On this qmgr, this cluster definition merely advertises the existence of a the object on some other qmgr; and the cluster definition is NOT a real local queue on this qmgr.
_________________
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.

PeterPotkay

Posted: Wed Mar 14, 2012 11:12 am Post subject:

Poobah

Joined: 15 May 2001
Posts: 7722

mqdev wrote:

I did hear all your well meaning criticisms of this approach but like I already mentioned, the train has left the station!

That train (your global DLQ solution) is on a collision course with another train (problems that my occur in a design that relies on a solution that conflicts with the manuals).

If the manuals say it has to be a local queue, if there are reasons articulated why it should be a local queue, it doesn't really matter if you do get it working somehow. The next fix pack may close the hole that you exploited that allowed it to work not being a local queue.

We're just a bunch of whack jobs on the internet. Your bosses couldn't care less what we say. Open a PMR with IBM, reference this thread, and see what the official response from IBM is. Let us know.

The train may have left the station. Better to save the day now, before that train derails later.
_________________
Peter Potkay
Keep Calm and MQ On

mqdev

Posted: Wed Mar 14, 2012 11:18 am Post subject:

Centurion

Joined: 21 Jan 2003
Posts: 136

fjb_saper wrote:

This is why I usually prefer a QRemote to a QAlias when looking at cluster queues.

Have fun

All right gentlemen. It is solved!

I did replace the QAlias with a QRemote as follows:

alter qr(LOCAL.QR.TO.CDLQ) rqmname(qm_fr) rname(ENTERPRISE_DLQ)

And it works!

So to summarize here is the setup on QM1:

dis qmgr deadq
8 : dis qmgr deadq
AMQ8408: Display Queue Manager details.
QMNAME(QM1) DEADQ(LOCAL.QR.TO.CDLQ)

dis qr(LOCAL.QR.TO.CDLQ)
9 : dis qr(LOCAL.QR.TO.CDLQ)
AMQ8409: Display Queue details.
QUEUE(LOCAL.QR.TO.CDLQ) TYPE(QREMOTE)
ALTDATE(2012-03-14) ALTTIME(13.40.0

CLUSNL( ) CLUSTER( )
CLWLPRTY(0) CLWLRANK(0)
DEFBIND(OPEN) DEFPRTY(0)
DEFPSIST(NO) DEFPRESP(SYNC)
DESCR( ) PUT(ENABLED)
RQMNAME(QM_FR) RNAME(ENTERPRISE_DLQ)
SCOPE(QMGR) XMITQ( )

xmitq on qr(LOCAL.QR.TO.CDLQ) is blank so I can use S.C.T.Q.

So gentlemen - the DLQ on a QM need not be a local Q. It can also be a QRemote defined with all attendant artifacts.

It has been a pleasure exchanging information here - and I do respect all you folks for your technical know-how and willingness to spend time to resolve others problems.

God bless!
-mqdev

bruce2359

Posted: Wed Mar 14, 2012 11:35 am Post subject:

Poobah

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

mqdev wrote:

xmitq on qr(LOCAL.QR.TO.CDLQ) is blank so I can use S.C.T.Q.

So gentlemen - the DLQ on a QM need not be a local Q. It can also be a QRemote defined with all attendant artifacts.

You have defined a QR that resolves to a local transmission queue.
_________________
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.

mqdev

Posted: Wed Mar 14, 2012 11:38 am Post subject:

Centurion

Joined: 21 Jan 2003
Posts: 136

PeterPotkay wrote:

mqdev wrote:

I did hear all your well meaning criticisms of this approach but like I already mentioned, the train has left the station!

Peter - well said.
I will pursue this with IBM and try to get a definite answer. We will be in touch folks - I will keep you posted (maybe a few days before I resurface on this topic).

Vitor

Posted: Wed Mar 14, 2012 2:11 pm Post subject:

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

mqdev wrote:

So gentlemen - the DLQ on a QM need not be a local Q. It can also be a QRemote defined with all attendant artifacts.

I said that several posts back.

It still doesn't mean it should be.

I concur that it will be interesting to see a response from IBM on the subject.
_________________
Honesty is the best policy.
Insanity is the best defence.

rekarm01

Posted: Wed Mar 14, 2012 3:11 pm Post subject: Re: *Must* the DLQ on a Queue Manager be a local queue?

Grand Master

Joined: 25 Jun 2008
Posts: 1415

PeterPotkay wrote:

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaj.doc/sc10620_.htm

Quote:

DEADQ(string)
The local name of a dead-letter queue (or undelivered-message queue) on which messages that cannot be routed to their correct destination are put.
The queue named must be a local queue.

Quote:

A dead-letter queue has no special requirements except that:

It must be a local queue
...

Merely resolving to a local queue does not meet this requirement -- even if it seems to work in some cases.

mqjeff wrote:

This is not a recent change. It has been a documented requirement since at least MQSeries v5.1 (~2002).

Display posts from previous:

Goto page Previous 1, 2, 3, 4, 5 Next

Page 3 of 5

MQSeries.net Forum Index » Clustering » Should the DLQ on a Queue Manager *must* be a local queue on

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