| Author |
Message
|
| ms_mq |
 Posted: Thu Aug 30, 2007 8:45 am Post subject: MQ client connection issue |
 |
|
Acolyte
Joined: 23 Feb 2007
Posts: 69
|
Hi,
Need your help on this .
I have MQ client installed on one server and the Queue manager on other server. What is the best way to test if the Client connection is working fine ?
amsputc from the client server is giving error code 2059 although the QM and the listner/ SVR CON channels are running fine. Does 2059 essentially means there is some problem in the client connection?
Please advise.
Both the server and client are MQ 6 and both are windows.
_________________
Regards,
MS |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Aug 30, 2007 8:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Did you follow the procedure outlined in the installation sections of the documentation?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Thu Aug 30, 2007 10:57 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
| Please document exactly what you issued from the command line to test this, including your environment variables - if any were set. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 30, 2007 11:07 am Post subject: Re: MQ client connection issue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ms_mq wrote: |
Does 2059 essentially means there is some problem in the client connection?
|
Oh yes. It means exactly that.
Aside from the excellent advice already offered, you might want to search the forum. A 2059 is a very common code, has been the subject of much discussion & you may find some of the experiences useful.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ms_mq |
| Posted: Fri Aug 31, 2007 3:03 am Post subject: |
|
|
Acolyte
Joined: 23 Feb 2007
Posts: 69
|
Hi All,
Thanks for your reply .This setup is in production and was running fine for a long time. months back we had upgraded the MQ version to 6.
Now the application is not able to post messages into the queue .I think there is some application problem .
But, i wanted to check if everything is ok from MQ perspective. I went through some of the previous posts in the forum reg. 2059. The SET MQSERVER on the MQ client machine is showing a different port number than where i tried sending a message.This might be the problem.
But before that i have a doubt. If i change the MQ server variables (IP/port no) , will this affect the MQ settings permanently ? ie if the application uses some other IP/port nos during MQ connection later, will that work fine or will it cause issues ? Please advise.
_________________
Regards,
MS |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 31, 2007 3:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ms_mq wrote: |
| Now the application is not able to post messages into the queue .I think there is some application problem . |
Not impossible, but unlikely. I'd not expect a 2059 from an application problem unless it's managing the connection itself (not typical).
| ms_mq wrote: |
But, i wanted to check if everything is ok from MQ perspective. I went through some of the previous posts in the forum reg. 2059. The SET MQSERVER on the MQ client machine is showing a different port number than where i tried sending a message.This might be the problem. |
Could be.
| ms_mq wrote: |
But before that i have a doubt. If i change the MQ server variables (IP/port no) , will this affect the MQ settings permanently ? ie if the application uses some other IP/port nos during MQ connection later, will that work fine or will it cause issues ? Please advise. |
MQSERVER is an environment variable; changes to it obey the normal rules associated with such variables. As I said above, it's not typical for applications to use their own values for connection. It inhibits portability for one thing!
Certainly changing the environment variable won't affect the queue manager for obvious reasons. You might want to spend some time with the Clients manual, which describes these connection methods (including application driven connections) in some detail.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ms_mq |
| Posted: Fri Aug 31, 2007 4:46 am Post subject: |
|
|
Acolyte
Joined: 23 Feb 2007
Posts: 69
|
Because there are different applications running on the client machine and they connect to different QMs on 2 diff servers. So i thought the applications can specify varois MQ server parameters . Is this not right?
_________________
Regards,
MS |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 31, 2007 4:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ms_mq wrote: |
| Because there are different applications running on the client machine and they connect to different QMs on 2 diff servers. So i thought the applications can specify varois MQ server parameters . Is this not right? |
It certainly is correct, and there are 2 broad methods by which you can achieve this. 3 if the applications are running in their own shells and hence have their own set of environment variables. Personally I wouldn't do it that way; rather cumbersome and inelegant.
But check out the manual and see what you think. Don't let my opinions put you off - it's your system and you know your requirements best.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Aug 31, 2007 12:19 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I would use the amqscnxc sample app instead of amqsputc.
All amqscnxc does is connect to the QM, return the QM name and end. It has 2 flags useful to you. -x is the hostname and -c is the channel name. If you use these you do not have to rely on MQSERVER or channel tables.
Get this to work first and then verify your MQSERVER variable agrees. -x and -c for amqscnxc trump MQSERVER to MQCHLLIB / MQCHLTAB so you can play with it without having to muck with variables.
c:\ amqsputc -x YourHostname(port#) -c YourSVRCONNchannelName
Post the results of this and the QM error log as well.
If that doesn't show anything on the QM side you may not be getting to the QM server at all (firewall?)
To prove this try telnet. If that doesn't work network is your issue.
c:\telnet YourHostName MQPort#
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
