| Author |
Message
|
| Plissken |
 Posted: Wed Aug 25, 2010 7:53 am Post subject: Connet to MQMgr fine with Java but not with .NET - err 2059 |
 |
|
Newbie
Joined: 25 Aug 2010
Posts: 3
|
Hi. My MQ is on a separate server installed with a Server-connection channel.
I have been able to connect to my MQmgr (and am able to send, receive, etc.) using Java with basically this code
import com.ibm.mq.*;
...
MQEnvironment.hostname = fQueueHostName;
MQEnvironment.port = fQueuePort;
MQEnvironment.channel = fQueueChannel;
...
fQueueMgr = new MQQueueManager( fQueueMgrName );
where the hostname is an IP addr. I have added a series of .jar files that came with WebSphere MQ.
But with Visual Studio 2005 when I try to connect i get a 2059 error using basically the same code.
using IBM.WMQ;
...
MQEnvironment.Hostname = HostName;
MQEnvironment.Port = QueuePort;
MQEnvironment.Channel = ChannelName;
...
queueManager = new MQQueueManager(QueueManagerName);
Exact same params as the java code. I have added the following references (dlls) that came with WebSphere MQ:
amqmdnet
amqmdnm
amqmdxcs
what am i missing? Thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 25, 2010 7:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Slightly odd but check that the user id that the .NET runs under is authorised on the queue manager. I've heard that errors which I believe should be 2035 get reported via .NET as 2059.
Also VS2005 is fairly old. What version of .NET are you using? For that matter, what version of WMQ are you using? Does it have the inbuilt .NET support or are you using the XMS support pac? What Windows OS are involved.
More information, better advice.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Plissken |
| Posted: Wed Aug 25, 2010 8:16 am Post subject: |
|
|
Newbie
Joined: 25 Aug 2010
Posts: 3
|
Thanks Vitor. The user is a generic company user - not sure how to check if it is authorized on the qm but I will look around.
Version of .NET looks like 2.0.50727 SP2, MQ is 6.0 - the DLLs I am using came from the original installation (I am pretty sure). OS on my machine and the server are both same version of XP (v2002 sp3). |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 25, 2010 8:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Plissken wrote: |
| The user is a generic company user - not sure how to check if it is authorized on the qm but I will look around. |
Ask whoever administers the queue manager. Seriously. There's a command they can use.
| Plissken wrote: |
| Version of .NET looks like 2.0.50727 SP2, MQ is 6.0 - the DLLs I am using came from the original installation (I am pretty sure). |
You might also want to ask the administrator about the WMQ level. I'd be surprised & alarmed to discover you're using the original 6.0; there should have been some maintenance applied & if not this could be a cause of your woes. Likewise you need to be more than pretty sure where the DLLs came from & if they match. If you're using the original release DLL but the queue manager's had maintenance applied this won't be helping. Especially as .NET used to be supplied by the XMS support pac & was later rolled into the base code.
(I can't remember when & can't be asked to look it up - anyone?)
My point is if you've got the XMS dll & the queue manager has native support this isn't going to end well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Plissken |
| Posted: Fri Aug 27, 2010 8:26 am Post subject: |
|
|
Newbie
Joined: 25 Aug 2010
Posts: 3
|
I has been confirmed that the DLLs are native to the installation.
Further, I have been able to copy the .exe onto a network drive and run it from the server machine successfully.
Something else I noticed, when I run the .exe on the client, in the command prompt box that has popped up I get the message
"MQM could not display the text for error 536895891." |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 27, 2010 9:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can create a .NET program that will only need one MQ dll - it's called a "managed connection".
I don't believe you are creating such a program.
Perform a full install of the latest MQ v6 client on the machine trying to run this program.
Also, you probably don't want or need to specify the Qmgr name.
Thirdly, you should go look up NMQ_MQ_LIB. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 27, 2010 9:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Plissken wrote: |
| Further, I have been able to copy the .exe onto a network drive and run it from the server machine successfully. |
Then this points the finger fair & square at the configuration of the remote box. I would theorise that when the server install was done someone also installed the client so when run from there it establishes a client connection but there's no client on your remote machine so it tries, unsuccessfully, to establish a managed connection because your code's not set up for that.
If you do have a client on the remote machine, try forcing your code to use it with NMQ_MQ_LIB.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
