| Author |
Message
|
| mquser01 |
 Posted: Tue Nov 18, 2008 5:31 am Post subject: Unable to delete messages on remote queue on windows |
 |
|
Acolyte
Joined: 06 Mar 2008
Posts: 52
|
scenario:
I want to access local and remote queue at the same time. remote queue is on windows.
so i have created an so file which uses mqic.so to delete messages on remote queue(local on windows)
MQCONNX throws error 2058. i suppose it tries to search the QM on local machine(Linux).
making a dll on windows and accessing local(Windows) and remote queue(Windows) was successful but accessing remote queue (Windows) from Linux machine using so file gives problem.
i have given authority to the Linux user on the Windows machine using setmqaut to the QMgr and queue which i want to access.
MQ version 7 is being used.
Let me know in case MQ7 provides some API to access remote and local queue at the same time
or any solution to the method i am using. |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Nov 18, 2008 5:44 am Post subject: Re: Unable to delete messages on remote queue on windows |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mquser01 wrote: |
...I want to access local and remote queue at the same time. remote queue is on windows...
...Let me know in case MQ7 provides some API to access remote and local queue at the same time or any solution to the method i am using... |
MQExplorer?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mquser01 |
| Posted: Tue Nov 18, 2008 5:55 am Post subject: |
|
|
Acolyte
Joined: 06 Mar 2008
Posts: 52
|
| i want to purge the messages in queue on remote machine(windows)programatically. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Nov 18, 2008 6:07 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Why not use an 'adapted' version of amqsgetc and script its use?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Nov 18, 2008 6:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Put global; get local.
You can put a message to any queue anywhere in your network; but all gets (with the exception of an MQ client application) are local to the application.
_________________
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 |
|
|
| Vitor |
| Posted: Tue Nov 18, 2008 7:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mquser01 wrote: |
| i want to purge the messages in queue on remote machine(windows)programatically. |
You have to make a connection to the remote machine so your (get) opperation can be performed locally.
Remember in MQ terms "local" is "the queue manager you're connected to" and "remote" is "every other queue manager".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mquser01 |
| Posted: Tue Nov 18, 2008 8:28 pm Post subject: |
|
|
Acolyte
Joined: 06 Mar 2008
Posts: 52
|
we use mqic.lib/so to connect to queue on remote machine, mqm.lib/so to connect to queue on local machine but in my case i want to make these connections at the same time i.e. use functionality of mqic and mqm both at the same time. hence i wrote a dll that connected to the queue on remote machine using mqic.lib. then i wrote an application which connected to queue on local machine. Now to use both these functionalities at the same time i loaded the dll (connecting to queue on remote machine using mqic.lib) in the application. this methodolgy helped me achieve my target. with this application i could connect to queue on local (windows OS) machine and queue on remote (windows OS) machine.
Problem ::
implementing the same functionality between Linux local machine and Windows remote machine.
To incorporate this functionality i wrote an mqclient.so file in linux using libmqic.so and application using libmqm.so but when i run this application its able to connect to queue on local machine but some how mqclient.so's MQCONNX tries to search for the QMgr on local machine instead of connecting to the QMgr on remote(Windows) machine.
All the steps required for MQClient have been executed. i.e. creating a remote user, giving authority to the remote user(setmqaut), creating Server-Connection-Channel in MQExplorer, defining environment variable MQSERVER on Linux machine etc.
In case any other details are required pl let me know. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 18, 2008 9:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mquser01 wrote: |
we use mqic.lib/so to connect to queue on remote machine, mqm.lib/so to connect to queue on local machine but in my case i want to make these connections at the same time i.e. use functionality of mqic and mqm both at the same time. hence i wrote a dll that connected to the queue on remote machine using mqic.lib. then i wrote an application which connected to queue on local machine. Now to use both these functionalities at the same time i loaded the dll (connecting to queue on remote machine using mqic.lib) in the application. this methodolgy helped me achieve my target. with this application i could connect to queue on local (windows OS) machine and queue on remote (windows OS) machine.
Problem ::
implementing the same functionality between Linux local machine and Windows remote machine.
To incorporate this functionality i wrote an mqclient.so file in linux using libmqic.so and application using libmqm.so but when i run this application its able to connect to queue on local machine but some how mqclient.so's MQCONNX tries to search for the QMgr on local machine instead of connecting to the QMgr on remote(Windows) machine.
All the steps required for MQClient have been executed. i.e. creating a remote user, giving authority to the remote user(setmqaut), creating Server-Connection-Channel in MQExplorer, defining environment variable MQSERVER on Linux machine etc.
In case any other details are required pl let me know. |
There is a known limitation to mq. You cannot be connected in bindings mode to a qmgr and in any other mode to another qmgr at the same time... If you want to be connected to more than one qmgr at a time you have to choose a client connection even though you might be on the same box. 
The reason for that as I understand it is that MQ has the assumption that in bindings mode you will never need more than one qmgr to satisfy your messaging needs. All messages for you must then be delivered to that qmgr and you can send msgs to anywhere in the MQ network, so there is no reason to need to connect to another qmgr. It has also most probably everything to do with using the qmgr as an XA transaction coordinator...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mquser01 |
| Posted: Tue Nov 18, 2008 10:09 pm Post subject: |
|
|
Acolyte
Joined: 06 Mar 2008
Posts: 52
|
| As mentioned earlier i am already using client connection(MQClient feature of Websphere MQ) i.e. libmqic.so to connect to the queue on remote machine but still am not able to make connection |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 19, 2008 1:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mquser01 wrote: |
| As mentioned earlier i am already using client connection(MQClient feature of Websphere MQ) i.e. libmqic.so to connect to the queue on remote machine but still am not able to make connection |
You are now in a standard "my client connection doesn't work" situation, which is probably the most common problem in WMQ. In the "doesn't work" sense, does the MQCONN/X call return a reason code? Is it a 2059?
If it is, then you'll find a wealth of information on the forum about this most common reason code. If it's not, look it up and/or post the details and work through the problem.
I'll add my standard advisory that a 2059 code can be caused by a wide variety of things and you should not assume it's a problem with your application, which could be working perfectly.
Happy Hunting. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mquser01 |
| Posted: Wed Nov 19, 2008 3:09 am Post subject: |
|
|
Acolyte
Joined: 06 Mar 2008
Posts: 52
|
Sir
Its not an standard problem, i will explain why?
libmqcli.so that i have written lets my sample application to connect to the client machine and purges the queue on client machine as per my requirement at that time i don't get 2058 error . but when i add code to access (purge) the queue on local machine to this sample application MQCONNX in libmqcli.so throws 2058 error which i suppose means that it tries to find the QMgr on local machine instead of connecting to the queue on client machine.
Note:
Here i would again mention that libmqcli.so that i have written is created by linking libmqic.so and application is being complied using libmqm.so when accessing queue on local machine code was added. this application loads libmqcli.so using dlopen.
g++ -fPIC -shared -o libmqcli.so mqli.cpp -lmqic -L /opt/mqm/lib
when accessing only queue on client machine application compiled as
g++ -o mqclisamp mqclisamp.cpp -ldl
when accessing queue on local machine added to the application
g++ -o mqclisamp mqclisamp.cpp -ldl -lmqm
Let me know if any other details are required. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 19, 2008 3:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Tell me again why you're producing this new shared object and not using the standard client functionality?
In the meantime check your local queue manager is enabled for client connections. A 2058 means the connection doesn't know the name of the queue manager you're connecting to, though that shouldn't matter with a connx call.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mquser01 |
| Posted: Wed Nov 19, 2008 4:40 am Post subject: |
|
|
Acolyte
Joined: 06 Mar 2008
Posts: 52
|
As mentioned earlier i want to connect to local machine's queue and client machine's queue thru same application. if i write the code for it in same application and compile it using mqic.so and mqm.so it will link only mqm.so nad ignore mqic.so. so i thought of writing a separate so file to achieve my requirement.
| Quote: |
| In the meantime check your local queue manager is enabled for client connections |
could you please elaborate what exactly do you mean by "queue manager is enabled for client connections" |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 19, 2008 4:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can not establish both a bindings connection and a client connection from within the same application.
You've proved this yourself, you just didn't understand it.
You need to establish two different CLIENT connections, one to a queue manager that happens to be running on the same machine as your program, and one that happens to be running on some other machine. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 19, 2008 4:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mquser01 wrote: |
| As mentioned earlier i want to connect to local machine's queue and client machine's queue thru same application. |
Yes, but why are you trying to connect to the local machine with bindings and the remote with client in a single application? Why can you not use a client connection for both, as is standard practice? What is differrent (to you) about purging locallly against remotely?
That's the root of my question.
| mquser01 wrote: |
| could you please elaborate what exactly do you mean by "queue manager is enabled for client connections" |
That is has the relevant client connection objects defined. Like the remote queue manager you're using must have. I'd be surprised if it didn't have the default ones, but they may be secured against applications.
Something of a long shot that. I still think the problem is this odd double connection method you're using.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
