| Author |
Message
|
| chris boehnke |
 Posted: Mon Aug 18, 2008 11:10 am Post subject: putting a msg onto a cluster queue |
 |
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
Hi Guys,
I am on MQ v.6 and OS SunOS.
I have 2 QMgrs QM1 and QM2 in a cluster called CLUSTER1.
I have a cluster queue, CLUSTERQ1.QM1 on QM1.
I provided the permissions for the application team to put/get/browse/set id for this queue on QM1 queue manager.
When the application team is trying to put a msg onto CLUSTERQ1.QM1(defined on QM1) from QM2, its throwing 2085 error.
As it is a cluster queue, there should not a be a problem in putting the msg to CLUSTERQ1.QM1 from QMgr QM2, correct?.
I even provided the permissions(put/get/browse/setid) to the application user for teh queue CLUSTERQ1.QM1 on QM1.
Thanks for your suggestions. |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Mon Aug 18, 2008 12:10 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
A 2085 is an unknown object name. If you think everything is defined correctly, then double-check the name of the queue in your program for a typo.
If there is no typo, double-check the definition of the queue to make sure that it is correct. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Mon Aug 18, 2008 12:14 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
|
| Back to top |
|
|
| chris boehnke |
| Posted: Mon Aug 18, 2008 2:05 pm Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
we are getting 2085(unknown object name) error when the application is trying to put a msg to a cluster queue(defined on a remote QMgr, QM1 which is part of the cluster) from the QMgr QM2.
I tried with the amqsput and it works. The application is proving the QMgr name=QM2, queue name=CLUSTERQ1.QM1(cluster queue defined on QM1).
the application is throwing 2085 error.
Please let me know your thoughts on this.
thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Aug 18, 2008 2:13 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Object names in MQ are case-sensitive. Is your QRemote definition upper-case, mixed-case, lower-case?
Post the QR definition.
Post the portion of the application that does the MQOPEN or equivalent Java thing.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Mon Aug 18, 2008 2:18 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| chris boehnke wrote: |
The application is proving the QMgr name=QM2, queue name=CLUSTERQ1.QM1(cluster queue defined on QM1).
|
There's your problem. You are telling MQ to look for this queue only on QM2. It doesn't exist there, so QM2 gives you 2085.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Mon Aug 18, 2008 2:56 pm Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| PeterPotkay wrote: |
| chris boehnke wrote: |
The application is proving the QMgr name=QM2, queue name=CLUSTERQ1.QM1(cluster queue defined on QM1).
|
There's your problem. You are telling MQ to look for this queue only on QM2. It doesn't exist there, so QM2 gives you 2085. |
Hey Peter,
well, the ./amqsput CLUSTERQ1.QM1 QM2 works just fine. Moreover when the queue is a cluster queue, it should be visible/accessible from both the Queue managers(QM1 and QM2) which are part of the cluster to put the message, correct?.
Please suggest me in this regard.
Thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Aug 18, 2008 4:57 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| well, the ./amqsput CLUSTERQ1.QM1 QM2 works just fine |
The amqsput takes as the second parameter the qmgr that the amqsput application will MQCONNect to. Thus, amqsput will MQCONNect successfully to QM2, but not find a QLocal definition for CLUSTERQ1
So, I gather that both QM1 and QM2 are in the same o/s image.
| Quote: |
| ...when the queue is a cluster queue, it should be visible/accessible from both the Queue managers(QM1 and QM2 |
)
Did you specify in the local queue definition CLUSTER(CLUSTER1) ? If not, the queue is not in the cluster, even though you named it CLUSTERQ1.
_________________
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 |
|
|
| chris boehnke |
| Posted: Mon Aug 18, 2008 5:41 pm Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| bruce2359 wrote: |
| Quote: |
| well, the ./amqsput CLUSTERQ1.QM1 QM2 works just fine |
The amqsput takes as the second parameter the qmgr that the amqsput application will MQCONNect to. Thus, amqsput will MQCONNect successfully to QM2, but not find a QLocal definition for CLUSTERQ1
So, I gather that both QM1 and QM2 are in the same o/s image.
| Quote: |
| ...when the queue is a cluster queue, it should be visible/accessible from both the Queue managers(QM1 and QM2 |
)
Did you specify in the local queue definition CLUSTER(CLUSTER1) ? If not, the queue is not in the cluster, even though you named it CLUSTERQ1. |
Both the QMgrs, QM1 and QM2 are defined on the same server with OS Sun.
The queue, CLUSTERQ1.QM1 is a cluster queue and provided the CLUSTER attribute with the cluster info and I can see this cluster on both the QMgrs QM1 and QM2.
Any thoughts..thanks |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Aug 18, 2008 6:12 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
the 2nd parm for amqsput is the QM you connect to.. When you specify QM2 for amqsput, you are telling your app to connect to QM2, open the CLUSTERQ1.QM1 queue, and put it to any QM.
Your app is specifying QM2 in the MQOD on the MQOPEN call, saying you want to put to CLUSTERQ1.QM1 only if it exists on QM2.
you can make amqsput behave the same way:
| Code: |
| amqsput CLUSTERQ1.QM1 QM2 16 0 QM2 |
will fail, as you are saying connect to QM2, put to CLUSTERQ1.QM1 specifically on QM2, and use 16 for the open options and 0 for the close options.
change that to this:
| Code: |
| amqsput CLUSTERQ1.QM1 QM2 16 0 QM1 |
or this
| Code: |
| amqsput CLUSTERQ1.QM1 QM2 16 0 |
and it will work.
Assuming you have your cluster set up correctly, I'm willing to bet this is your issue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Mon Aug 18, 2008 6:36 pm Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| PeterPotkay wrote: |
the 2nd parm for amqsput is the QM you connect to.. When you specify QM2 for amqsput, you are telling your app to connect to QM2, open the CLUSTERQ1.QM1 queue, and put it to any QM.
Your app is specifying QM2 in the MQOD on the MQOPEN call, saying you want to put to CLUSTERQ1.QM1 only if it exists on QM2.
you can make amqsput behave the same way:
| Code: |
| amqsput CLUSTERQ1.QM1 QM2 16 0 QM2 |
will fail, as you are saying connect to QM2, put to CLUSTERQ1.QM1 specifically on QM2, and use 16 for the open options and 0 for the close options.
change that to this:
| Code: |
| amqsput CLUSTERQ1.QM1 QM2 16 0 QM1 |
or this
| Code: |
| amqsput CLUSTERQ1.QM1 QM2 16 0 |
and it will work.
Assuming you have your cluster set up correctly, I'm willing to bet this is your issue. |
Hi,
the ./amqsput is working just fine. my issue is when the application is trying to put a msg on the cluster queue, CLUSTERQ1.QM1(defined on remote QMgr-QM1). The application is connected to QM2.
The application is using the below properties to connect to MQ:
QMgr: QM2
queue: CLUSTERQ1.QM1
Let me know your thoughts on this.
I appreciate your suggestions ans help.
Thanks. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Aug 18, 2008 7:22 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
there are 2 places for an MQ app to specify a QM name when putting a message.
A. on the MQCONN
B. on the MQOPEN in the MQOD
If you connect to QM2 (A. above) and incorrectly specify QM2 for the MQOPEN (B. above), but your queue lives on QM1, you are going to get a 2085 error.
For the MQOPEN call make sure the app does not incorrectly specify QM2.
And you can test this using the amqsput examples I gave above.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Aug 19, 2008 4:54 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
.....or in other words.
Make sure you move spaces to the MQOD.Objectqmgrname field and all will be well. |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Tue Aug 19, 2008 6:06 am Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| kevinf2349 wrote: |
.....or in other words.
Make sure you move spaces to the MQOD.Objectqmgrname field and all will be well. |
Do you guys think whether this is an application issue or MQ issue as I am able to send msgs to the cluster queue, CLUSTERQ1.QM1 from QMgr QM2 by using sample binaries.../amqsput
Thanks for your thoughts in advance. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Aug 19, 2008 6:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Applications do not need to specify the qmgr name in an MQOPEN. Your QRemote definition will provide qmgr name.
In a non-clustered environment, an application specifying qmgr name in the MQOPEN will result in the qmgr not doing name resolution. This means that there must be a transmission queue with the exact name as the qmgr specified in the MQOPEN, or the qmgr name must be resolved by a qmgr alias to an xmit queue, or there must be a default xmit queue.
All this is working as designed, and is documented in the Intercommunications manual.
_________________
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 |
|
|
|
|
