| Author |
Message
|
| hklbj |
 Posted: Tue Dec 13, 2011 9:22 pm Post subject: MQ client dotnet application connect remote MQ server fail |
 |
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
We have plan to upgrad the MQ client from ver. 6 to ver. 7 due to ver.6 not support Windows 2008 (64 bit). However we have some issue to connect the remote MQ server with strange Nmqi exception. Pls help.
Error log:
| Quote: |
IBM.WMQ.Nmqi.NmqiException: Exception of type 'IBM.WMQ.Nmqi.NmqiException' was thrown.
at IBM.WMQ.Nmqi.NmqiTools.GetQueueManagerInfo(NmqiEnvironment env, NmqiMQ mq, Hconn hconn)
at IBM.WMQ.Nmqi.UnmanagedHconn.UpdateHconn(NmqiMQ mqInstance, Phconn phconn)
at IBM.WMQ.Nmqi.UnmanagedNmqiMQ.MQCONNX(String pQMgrName, MQCNO& pConnectOpts, Hconn parentHconn, Phconn phconn, Int32& pCompCode, Int32& pReason)
at IBM.WMQ.Nmqi.UnmanagedNmqiMQ.MQCONNX(String pQMgrName, MQConnectOptions pConnectOpts, Phconn phconn, Int32& pCompCode, Int32& pReason)
at IBM.WMQ.MQQueueManager.Connect(String queueManagerName)
at IBM.WMQ.MQQueueManager..ctor(String queueManagerName, String Channel, String ConnName)
at XonWinAppUtilLibrary.MQGet.InitQueue() in C:\project\dotNet\XonFramework\WinAppFramework\2.0\XonWinAppUtilLibrary\MQGet.vb:line 276
|
Remote MQ server:
Ver 6.0.2.6 on Win 2003 (32 bit)
MQ client:
Ver 7.0.1.7 on Win XP sp3
| Code: |
| mqQMgr = New MQQueueManager(mConfig.QueueManager, channelName, connectionName) |
|
|
| Back to top |
|
 |
| hklbj |
| Posted: Tue Dec 13, 2011 9:24 pm Post subject: |
|
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 14, 2011 5:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hklbj wrote: |
| However, we have no idea on setting the CCSID of MQQueueManager constructor. |
You have no idea how to set it, or no idea what to set it to?
Also (and perhaps not directly related to your problem) why are you using the latest v7 client with a back level v6 queue manager? While in theory at least it should work, as you're having problems why not at least consider applying maintenance to the queue manager or accelerating the upgrade to v7?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JasonE |
| Posted: Wed Dec 14, 2011 5:28 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| Does the userid this is running under have INQ rights at the queue manager level? Its thrown from code which opens, inquires and then closes the queue manager object, driven straight after the connect. |
|
| Back to top |
|
|
| hklbj |
| Posted: Wed Dec 14, 2011 6:16 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
Vitor:
In dotnet version MQ client, it only required to pass the remote qmgr name, channel name & connection name. (we did it with MQ client ver. 6.0). We use the latest ver because we just want to upgrade our application using MQ client ver 7.
JasonE:
the channel has set with MAC user ID already, so no user id pass to constructor. Exception thrown from creating the Qmgr instance. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 14, 2011 6:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hklbj wrote: |
Vitor:
In dotnet version MQ client, it only required to pass the remote qmgr name, channel name & connection name. (we did it with MQ client ver. 6.0). |
But you're not using v6 now, you're using v7.
And you're the one who brought up CCSID.
| hklbj wrote: |
| We use the latest ver because we just want to upgrade our application using MQ client ver 7. |
I repeat - why are you using a v7 client on a v6 queue manager? What advantage do you perceive? Why is the v6 queue manager not on the latest maintenance, i.e. on a level of v6 that pre-dates the v7 client?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hklbj |
| Posted: Wed Dec 14, 2011 7:01 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
Vitor,
upgrade because "ver.6 not support Windows 2008 (64 bit)", our client machine would like to upgrade from win 2003 to win 2008 |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 14, 2011 7:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JasonE |
| Posted: Thu Dec 15, 2011 1:37 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Oh for PM on these forums...
Can you take a trace on the client, zip it up and make it downloadable from somewhere and I'll take a quick look. I'd PM you my email address but PM is disabled  |
|
| Back to top |
|
|
| hklbj |
| Posted: Thu Dec 15, 2011 1:40 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
Hi Jason,
Actually I can run the amqsputc with MQ clietn 7 without any issue. but the dotnet application have been thrown out the exception which I have no idea how to fix it.
 |
|
| Back to top |
|
|
| JasonE |
| Posted: Thu Dec 15, 2011 1:51 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| Trace will trace .net, and as you are unmanaged (ie going via the C layer) it will also catch that (in theory)... just strmqtrc -t detail -t all -d -1, run .net app which throws exception, endmqtrc, wait 30 secs, zip up the TRC files and shove somewhere I can get to and I'll have a quick look. |
|
| Back to top |
|
|
| hklbj |
| Posted: Thu Dec 15, 2011 2:40 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
Jason
Thanks for your advise, I will try it and let you know the result. Where should i put the zipped trace file for your reference? |
|
| Back to top |
|
|
| hklbj |
| Posted: Thu Dec 15, 2011 2:43 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
|
| Back to top |
|
|
| JasonE |
| Posted: Thu Dec 15, 2011 4:15 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
I was almost right, wrong API call 
The problem occurs because the .NET app, after connecting, issues an MQOPEN on the qmgr object. This is rejected with a 2035 (not authorized).
The app is running under the userid 'SYSTEM'. What o/s is the server? What does "dspmqaut -m QM -t qmgr -p SYSTEM" show on the server?
<edit>Just reread - you said you use MCAUSER on the channel - what does dspmqaut on that userid show on the server? |
|
| Back to top |
|
|
| hklbj |
| Posted: Thu Dec 15, 2011 4:26 am Post subject: |
|
|
Apprentice
Joined: 20 Jun 2007
Posts: 34
Location: HK
|
Server OS is Win 2003
user "SYSTEM" has no access right on the qmgrs
the MACUser is "mqapps"
the user can connect qmgr and also get/put/inq about the q objects.
For wrong API call, so what is the correct API to be used instead, we keep the code for MQ client ver 6 but it works without issue? Thanks. 
Do you mean the dotnet app already connect the qmgr successful? |
|
| Back to top |
|
|
|
|
