Author |
Message
|
Vitor |
Posted: Wed Dec 01, 2010 3:10 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
pnicolay wrote: |
or is he making the assumption based on the fact that I use MQEnvironment settings for host, port and channel) ? |
No, he's using the method documented at the bottom of the link you posted to determine connection type based on what you've set or not set. There's no assumption. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
RogerLacroix |
Posted: Wed Dec 01, 2010 9:37 am Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
mqjeff wrote: |
You always want to make it significantly more complicated that it should be.
Why can't we just leave it at SET? |
Jeff, were you having a bad day yesterday? Complicated? I think you meant Explicit.
This is an English language description of the solution:
RogerLacroix wrote: |
Or did you set the NMQ_MQ_LIB to mqic.dll |
This is an explicit sample of the solution:
RogerLacroix wrote: |
Or did you set the NMQ_MQ_LIB to mqic.dll
Code: |
<configuration>
<appSettings>
<add key="NMQ_MQ_LIB" value="mqic.dll"/>
</appSettings>
</configuration> |
|
I gave the explicit sample because a lot of people have problems reading / understanding the English language.
Regards,
Roger Lacroix _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Dec 01, 2010 10:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
It's more complicated to adjust the .NET assembly than it is to issue the windows command line SET command in the runtime environment.
It may be *better* to adjust the .NET assembly, but it is still more COMPLICATED.
SET NMQ_MQ_LIB=mqic.dll is a simpler invocation, if only because it is fewer characters.
I realize that you frequently have to deal with people who speak Quebecois, but I didn't expect that this usage of 'complicated' required much explanation. |
|
Back to top |
|
 |
RogerLacroix |
Posted: Wed Dec 01, 2010 10:41 am Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
pnicolay wrote: |
I do wonder however why I would need to set it since not using a channel definition table works fine (or is he making the assumption based on the fact that I use MQEnvironment settings for host, port and channel) ? |
No, I am not making any assumptions.
1) If you want to use "managed" mode with your .NET application then set it up and it will work.
2) If you want to use a CCDT with your .NET application then you CANNOT use "managed" mode, you need to use "client" mode.
Regards,
Roger Lacroix _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
RogerLacroix |
Posted: Wed Dec 01, 2010 10:45 am Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
mqjeff wrote: |
SET NMQ_MQ_LIB=mqic.dll is a simpler invocation, if only because it is fewer characters. |
That doesn't work.
Setting an environment variable is not the same as setting application configuration information.
I have not tested WMQ v7.0.1.3 with a .NET application, so WMQ may now check both but previously WMQ only checked application configuration information.
Regards,
Roger Lacroix _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Dec 01, 2010 10:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
RogerLacroix wrote: |
mqjeff wrote: |
SET NMQ_MQ_LIB=mqic.dll is a simpler invocation, if only because it is fewer characters. |
That doesn't work.  |
It certainly used to, at least for VB6 stuff....
It's worth testing. But I'm not gonna bother. |
|
Back to top |
|
 |
RogerLacroix |
Posted: Wed Dec 01, 2010 10:56 am Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
mqjeff wrote: |
It certainly used to, at least for VB6 stuff....
It's worth testing. But I'm not gonna bother. |
Ah ha. You made the assumption that VB6 == .NET, it is not.
VB6 uses the native WMQ framework which means you can use bindings or client mode.
Regards,
Roger Lacroix _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Dec 01, 2010 10:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
RogerLacroix wrote: |
mqjeff wrote: |
It certainly used to, at least for VB6 stuff....
It's worth testing. But I'm not gonna bother. |
Ah ha. You made the assumption that VB6 == .NET, it is not. |
No... I merely assumed that the .NET framework would read the same environment variables that the VB framework did....
 |
|
Back to top |
|
 |
pnicolay |
Posted: Thu Dec 02, 2010 2:09 am Post subject: |
|
|
Apprentice
Joined: 29 Nov 2010 Posts: 26
|
I changed my test program from...
Code: |
MQManager = new MQQueueManager("MYQM"); |
to...
Code: |
Hashtable connProps = new Hashtable();
connProps.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
MQManager = new MQQueueManager("MYQM", connProps); |
... but now the .Net program waits forever on the new MQQueueManager (and takes 50% CPU) ? |
|
Back to top |
|
 |
pnicolay |
Posted: Thu Dec 02, 2010 2:16 am Post subject: |
|
|
Apprentice
Joined: 29 Nov 2010 Posts: 26
|
And changing my app.config file to (removing again the hash table)...
Code: |
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
</configSections>
<appSettings>
<add key="NMQ_MQ_LIB" value="mqic.dll"/>
</appSettings>
</configuration> |
... results in the same issue on the new MQQueueManager. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Dec 02, 2010 5:47 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
I may be missing a post in this growing thread, but have you confirmed the correct installation of the client on the machine you're running on, and the correct client configuration on the queue manager, using one of the samples?
I accept unreservedly that, if there was a problem with either of those things the .NET should has got a 2059. But it can't hurt to check. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
pnicolay |
Posted: Thu Dec 02, 2010 11:42 pm Post subject: |
|
|
Apprentice
Joined: 29 Nov 2010 Posts: 26
|
The installation is a Websphere MQ Server 7.0.1.3 on my PC (of which I don't use the server part, it itsn't active). I presume this is a valid client as well, I doubt if I can install a seperate client on top of it.
The MYQM to which I'm connecting is running on an iSeries, and works fine from C# without a channel definition table, as well as from Java (so the server configuration should be fine). |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Dec 03, 2010 1:34 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Remember when you create the qmgr with name QMGR in your program that if that is not the actual name of the qmgr (see qmgr name and corresponding entry in channel table mismatching) you need to use *QMGR as the qmgr name to create your qmgr object...
ex
actual qmgr name QMGR1
qmgr name on channel definition in table is MYQMGR
you build the object using "*MYQMGR"
 _________________ MQ & Broker admin |
|
Back to top |
|
 |
pnicolay |
Posted: Fri Dec 03, 2010 1:51 am Post subject: |
|
|
Apprentice
Joined: 29 Nov 2010 Posts: 26
|
I can confirm that following names all match;
- name of the actual queuemanager on iSeries
- name of the queuemanager in the client connection channel
- name of the queuemanager on the new statement in C# |
|
Back to top |
|
 |
ramires |
Posted: Fri Dec 03, 2010 2:02 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001 Posts: 523 Location: Portugal - Lisboa
|
|
Back to top |
|
 |
|