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. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Mar 14, 2012 7:07 am Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9401 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. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
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. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
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? |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Mar 14, 2012 7:50 am Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9401 Location: US: west coast, almost. Otherwise, enroute.
|
mqdev wrote: |
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? |
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. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Mar 14, 2012 7:54 am Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9401 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. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
fjb_saper |
Posted: Wed Mar 14, 2012 8:55 am Post subject: |
|
|
![](images/avatars/gallery/misc/2.gif) Grand High Poobah
Joined: 18 Nov 2003 Posts: 20696 Location: LI,NY
|
mqdev wrote: |
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.
|
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 ![](images/smiles/innocent.gif) _________________ MQ & Broker admin |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
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! |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Mar 14, 2012 9:48 am Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9401 Location: US: west coast, almost. Otherwise, enroute.
|
mqdev wrote: |
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! |
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. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
PeterPotkay |
Posted: Wed Mar 14, 2012 11:12 am Post subject: |
|
|
![](images/avatars/c7de043e3ce24eaa279a5.gif) Poobah
Joined: 15 May 2001 Posts: 7716
|
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 |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
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 ![](images/smiles/innocent.gif) |
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 |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
bruce2359 |
Posted: Wed Mar 14, 2012 11:35 am Post subject: |
|
|
![](images/avatars/58715422151eef88d5f6e3.jpg) Poobah
Joined: 05 Jan 2008 Posts: 9401 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. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
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! |
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 - 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). |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
Vitor |
Posted: Wed Mar 14, 2012 2:11 pm Post subject: |
|
|
![](images/avatars/905340816499abc1cdfb07.jpg) 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. |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
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
|
See also: http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.amqzag.doc/fa11240_.htm
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: |
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. |
This is not a recent change. It has been a documented requirement since at least MQSeries v5.1 (~2002). |
|
Back to top |
|
![](templates/DAJ_Glass/images/spacer.gif) |
|