Author |
Message
|
Eric Koontz |
Posted: Mon Feb 07, 2005 1:36 pm Post subject: |
|
|
Newbie
Joined: 01 Mar 2004 Posts: 6
|
I am appreciating all of the discussion and help...
Not in the DLQ of either source or dest. |
|
Back to top |
|
 |
Eric Koontz |
Posted: Mon Feb 07, 2005 2:33 pm Post subject: |
|
|
Newbie
Joined: 01 Mar 2004 Posts: 6
|
I have the DLQ in the dest QMan configure properly now, and the messages are landing in there. A report is being generated in the Error Log:
2005/02/07 15.27.06
AMQ7310: Report message could not be put on a reply-to queue.
EXPLANATION:
The attempt to put a report message on queue A.LOG on queue manager UG0017100
failed with reason code 2087. The message will be put on the dead-letter queue.
ACTION:
Ensure that the reply-to queue is available and operational.
2087 is MQRC_UNKNOWN_REMOTE_Q_MGR - As far as I can tell, both the QMan and Q name listed in the error message are exactly where I want this reply message to go.
Any suggestions? |
|
Back to top |
|
 |
csmith28 |
Posted: Mon Feb 07, 2005 2:45 pm Post subject: |
|
|
 Grand Master
Joined: 15 Jul 2003 Posts: 1196 Location: Arizona
|
Are your Channels and XMITQ properly defined? _________________ Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
Back to top |
|
 |
EddieA |
Posted: Mon Feb 07, 2005 2:56 pm Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
You will need either an XMITQ named the same as the destination QM, or use the Default XMITQ. And, of course, a Channel that uses the XMITQ.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
Eric Koontz |
Posted: Tue Feb 08, 2005 7:39 am Post subject: and a couple of questions... |
|
|
Newbie
Joined: 01 Mar 2004 Posts: 6
|
I created an xmit Q w/ the same name as the source QMan and it now works.
Thanks for your help.
Is it common for MQ applications to require a COA/COD report?
Though this solution works, it fails to isolate the configuration and requirements of the source from the destination - I had to force an xmit queue name on the destination. Is there a solution that is completely unrelying on the destination QMan? |
|
Back to top |
|
 |
Nigelg |
Posted: Tue Feb 08, 2005 8:05 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
Not in normal distributed queuing. The destination qmgr has to find a route back to the source qmgr, and the only possible way is for an xmitq and channel to be defined to form that route.
In a cluster, the return route can be automatically found without any definitions on the destination qmgr, using the usual cluster queue name resolution techniques. |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Feb 08, 2005 12:52 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Read the intercommunication manual.
The default route to qmgr XYZ outside of a cluster is materialized by
a) xmitq XYZ that is used in a channel to qmgr XYZ or to a qmgr that knows the way to XYZ (multi hopping)
b) qmgr alias (rq) XYZ that can
A) instruct the local qmgr to consume the message
B) pass the message a different qmgr as target (RST) by specifying rqmname(RST) and xmitq(to.rst.xmitq)
C) specify the xmitq(channel) to be used: rqmname(XYZ) xmitq(TO.XYZ) ...
Time to hit the manuals again
 |
|
Back to top |
|
 |
mqdogsbody |
Posted: Thu Feb 02, 2012 5:24 am Post subject: |
|
|
 Acolyte
Joined: 01 Jun 2010 Posts: 71
|
csmith28 wrote: |
read up on Persistence in the WMQ Systems Administration Guide. |
So easy! Here's the haystack. Now where did they hide that needle? I tried searching for "persistence" in the WebSphere MQ System Administration Guide: the top topic said that persistance might hit performance because of logging. Next came DLQ rules, some utiity programs, more about logging. Intercommunication was no better. It doesn't help that the search context appears as:
Code: |
.runningfooter { font-family: Verdana, Arial, sans-serif; font-size: 0.7em; } .runningfooter a:link { font-weight: bold; color: #000000; text-decoration: none; } .runningfooter a:active { fo |
It would be nice to read it offically, but I think I have worked it out from messages in this thead:- DEFPSIST does matter for remote queuing, so the settings on your XMTIQ and QREMOTE matter
- The QREMOTE acts the same was as a QALIAS for the XMITQ as far as DEFPSIST is concerned.
_________________ -- mqDB -- |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Feb 02, 2012 5:55 am Post subject: Re: and a couple of questions... |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9472 Location: US: west coast, almost. Otherwise, enroute.
|
Eric Koontz wrote: |
Is it common for MQ applications to require a COA/COD report?? |
There have been a lot of discussion on the relative merit of COA and COD - what they tell you, and what they don't.
Search here for COA and COD. _________________ 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 |
|
 |
|