|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
reason code: 2087 - enqueue a message on a remote queue. |
« View previous topic :: View next topic » |
Author |
Message
|
fall_of_icarus |
Posted: Wed Jun 10, 2009 3:54 am Post subject: reason code: 2087 - enqueue a message on a remote queue. |
|
|
Newbie
Joined: 10 Jun 2009 Posts: 3
|
Hi Gurus,
I have a scenario which goes as follows : (enqueue, dequeue and then enqueue)
i. seed a message through the first enqueue operation on QM1-A with msg.replyToQueueName as some queue name,
ii. The message is then dequeued from QM1-A and
iii. Finally an enqueue is performed on a queue and qmgr which is resolved through the msg.replyToQueueName.
The basic scenario works fine, but I am running into reason code 2087 if msg.replyToQueueName is specified as a remote queue, R.
On further investigation, I notice that after seeding the message on QM1-A, the replyToQueueManager and replyToQueueName is resolved to the destination queue QM2-B from remote message R.
I would like to know a couple of things:
a. Is it possible to somehow stop the auto-resolution of queue manager (QM2) and queue name (B) from remote queue (R) name once a message is seeded into a queue on some queue manager?
Since things work fine if I enqueue a message on a remote queue R where MQ takes care of transmission to destination queue QM2-B.
b. Is the following statement valid:
int opts = MQC.MQOO_OUTPUT;
fMQ = fQMGR.accessQueue("B", opts , "QM2", null, null);
* FQMGR.name = QM1 (results in 2087 for me.)
Really appreciate your help on this. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jun 10, 2009 3:59 am Post subject: Re: reason code: 2087 - enqueue a message on a remote queue. |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
fall_of_icarus wrote: |
a. Is it possible to somehow stop the auto-resolution of queue manager (QM2) and queue name (B) from remote queue (R) name once a message is seeded into a queue on some queue manager? |
No. You need a queue manager alias to resolve this kind of situation.
fall_of_icarus wrote: |
b. Is the following statement valid: |
Only if the qmgr name can be resolved, either directly or via an alias. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fall_of_icarus |
Posted: Wed Jun 10, 2009 9:43 pm Post subject: |
|
|
Newbie
Joined: 10 Jun 2009 Posts: 3
|
a. As I understand, if we specify a replyToQueueManagerName which is an alias or otherwise, then this auto-resolution doesn't happen.
b. what you said makes sense, but i have a question here... If QM1 could resolve MQ2-B as the destination queue manager and queue from remote queue R in the replyToQueueName, then why should it complain with 2087 in the accessQueue method?
QM1.accessQueue("B", opts , "QM2", null, null); [/quote] |
|
Back to top |
|
 |
fall_of_icarus |
Posted: Wed Jun 10, 2009 10:45 pm Post subject: |
|
|
Newbie
Joined: 10 Jun 2009 Posts: 3
|
|
Back to top |
|
 |
Vitor |
Posted: Wed Jun 10, 2009 11:56 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
fall_of_icarus wrote: |
I found some documentation which provides an explanation of reason code 2087. |
You'd find the same advice following the links at the top of this page.
For your benefit and the benefit of future posters, I will again point out that while this site comes out on the top of most Google searches, it's a mirror run by the Information Technology Services office of the State of North Carolina! The information shown is very old (check out the copyright dates!) and is for the old v5.2 version of WMQ.
On at least one occassion in my experience, a poster has got into trouble trying to use this because what this documentation described was not how their v6 was working because IBM had changed it!
Even more importantly this documentation doesn't describe any of the new features in v6 & v7. Use either the IBM site or the links on this page - do not use this old stuff
 _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Jun 10, 2009 11:59 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
fall_of_icarus wrote: |
Thanks Vitor for your prompt response and valuable pointers on solving this. |
You're quite welcome, and I'm glad you got it sorted.
The above rant was not directed at yourself, but a general warning. The ITS seem to be much better at The Google Dance than they are at updating web sites; that wretched site is nearly always top link on a WMQ Google search. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|