| Author |
Message
|
| c200chello |
 Posted: Tue Aug 21, 2007 7:36 am Post subject: Problem using MQCONNX to remote QueueManager |
 |
|
Newbie
Joined: 21 Aug 2007
Posts: 5
|
When I'm using the MQ API (mqm.dll / mqic32.dll) for accessing the local queuemanager everything works fine...
but..
when I try to connect a REMOTE queuemanager (using mqconnx) I ran into several problems. (I'm using mqic32.dll) I think that it has something todo with the proper use of the ConnectionOptions.
Does anayone has a sample of MQCONNX which connects to a remote QM, With te proper use of the connectoptions ? tHX.
Please provide me some example... !
 |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Aug 21, 2007 7:42 am Post subject: Re: Problem using MQCONNX to remote QueueManager |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| c200chello wrote: |
Does anayone has a sample of MQCONNX which connects to a remote QM, With te proper use of the connectoptions ? tHX.
|
There are samples on the install media & on the web. But conceptually there's no difference between a client onto a local queue manager & a remote one, provided both are properly configured to accept client connections.
What problems are you getting, specifically what reason code is being returned from the MQCONNX?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| c200chello |
| Posted: Tue Aug 21, 2007 7:55 am Post subject: |
|
|
Newbie
Joined: 21 Aug 2007
Posts: 5
|
But how on earth do you tell your client appl to connect to a remote QM instead of a local one?
Do I have to set some environment settings like MQSERVER=CLIENT.CHANNEL/TCP/10.20.30.101(1414) ??? or is there another way, because this won't work.
error : MQRC_Q_MGR_NOT_AVAILABLE... MQRC_CD_ERROR (probably channel errors) |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 21, 2007 8:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MQCONNX doesn't use the environment variables.
It expects you set all the necessary information for connecting to the qmgr in the parameters you pass to it.
So you have to give it the Channel name, the hostname/ip, the port number, and etc.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| c200chello |
| Posted: Tue Aug 21, 2007 8:19 am Post subject: |
|
|
Newbie
Joined: 21 Aug 2007
Posts: 5
|
b2w, thx for your reply's
of course I did set both the MQCD (channel) and ConnectOptions, and checked these as during debug, (everything was in it: ipadress(port) channelenames and the default other settings...
but even in the case of having some of the settings wrong or not exactly right, then still I had to see some tcp/ip traffic ... and this is the case: I don't see any attempt to set-up some kind of IP connection... Therefore I'm still thinking some ohter issue is totally wrong ... But I don't have a clue...
Thx for reading ! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 21, 2007 8:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You won't see any network traffic until you get the MQCONNX producting an MQRC that indicates it at least TRIED to talk to the remote qmgr.
That won't happen until you get the structures you're passing in complete enough and correct enough that it doesn't give you RCs complaining about the ConnectOptions.
And as Vitor said, there are examples that show MQCONNX usage.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Aug 21, 2007 12:33 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
On Windows, look in the {MQ_Install_Dir}\Tools\c\Samples\ directory for 'amqscnxc.c'.
It has sample of how to use MQCONNX. It is complex but very straight-forwared.
| Code: |
MQCNO Connect_options = {MQCNO_DEFAULT};
MQCD ClientConn = {MQCD_CLIENT_CONN_DEFAULT};
MQHCONN Hcon;
MQLONG CompCode;
MQLONG CReason;
char QMgrName[MQ_Q_MGR_NAME_LENGTH+1] = "MQA1";
char channelName[MQ_CHANNEL_NAME_LENGTH+1] = "SYSTEM.DEF.SVRCONN";
char hostname[1024] = "127.0.0.1(1414)";
strncpy(ClientConn.ConnectionName, hostname, MQ_CONN_NAME_LENGTH);
strncpy(ClientConn.ChannelName, channelName, MQ_CHANNEL_NAME_LENGTH);
Connect_options.ClientConnPtr = &ClientConn;
Connect_options.Version = MQCNO_VERSION_2;
MQCONNX(QMgrName,
&Connect_options,
&Hcon,
&CompCode,
&CReason); |
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 21, 2007 1:10 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Roger's solution may do the trick, but this thread reminded me of a problem we had with MQ and ActiveX.
This quote is from an email I had from 2002!
| Quote: |
| AccessQueueManager method
| Creates a new MQQueueManager object and connects it to a real queue manager
| by means of the MQSeries client or server. As well as performing a connect, this
| method also performs an open for the queue manager object.
| Note: When both the MQSeries server and client are installed on your system
| MQAX applications will always run against the server.
Basically, if an MQSeries Server IS installed on the same machine as the ActiveX program THEN that program will ONLY connect to the local queue manager (unless you tell it to do otherwise - read on).
If you had no local queue manager installed (i.e. using MQ client), it would base the connection on your environment variables (MQSERVER or MQCHLTAB and MQCHLLIB).
Now, you can get around this. If you set a system environment variable GMQ_MQ_LIB to the following, it will behave as a client:
GMQ_MQ_LIB=drive:\<insert path to mqic32>\mqic32.dll.
Hope this helps
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 21, 2007 1:52 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I won't go into the gorey details of getting a Perl program to connect as a client, on a machine with both client & server - but let's just say that something as *simple* as setting an environment variable sure would be nice.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| c200chello |
| Posted: Tue Aug 21, 2007 8:38 pm Post subject: |
|
|
Newbie
Joined: 21 Aug 2007
Posts: 5
|
Thanks for all your help!
I do now have several leads o solve my issue with MXCONNX.
After a lot of reading I figured out that you need to make use (client connect) of mqic32.dll for a remote connction instead of using mqm.dll for a local one.
But according this Forum if it is also possible to use MQCONN also for a remote connect but then you have to set a local Environmet variable like MQSERVER=channel-name/TCP/Hostname(por) to force it.
Today I'm going through on all these possibilities to find out....
Thx ! |
|
| Back to top |
|
|
| c200chello |
| Posted: Wed Aug 22, 2007 6:56 am Post subject: |
|
|
Newbie
Joined: 21 Aug 2007
Posts: 5
|
My problem is solved..!
I'm using the client libs of MQ v6.0
when I changed the following statement in my coding
Connect_options.Version = MQCNO_VERSION_2;
into Connect_options.Version = 7;
suddenly the MQCONNX works fine ...!
Thanks for helping and reading ! |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Aug 23, 2007 7:56 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| c200chello wrote: |
into Connect_options.Version = 7;
suddenly the MQCONNX works fine ...! |
Seven 
Where did you get seven from? You really should be using the IBM supplied constants of MQCNO_VERSION_*
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 23, 2007 12:24 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
|
|
