| Author |
Message
|
| sebastia |
 Posted: Thu Oct 11, 2007 2:53 am Post subject: |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Vitor - you, and all the people in this forum ara always very respectful.
And I know sometimes I place questions "too fast", without spending enough time on the books. But my environment is not of an amateur who spends time learning new things, no.
I have quite a wide knowledge on MQ and MB, but when you go on the field and put your hands on a customer's project, things do change a lot.
I mean - I can do with MQ whatever I need with C, Delphi and/or Rexx.
What is the reality ? (new) Customer uses C# - and the MQ Client part is just a part of the project : we have to create a mixed cluster, support quite complex MB nodes and flows, etc. No time to learn C# !
And the C# code does not connect using tables and MQ Client.
So, I ask for a simple and fast support, not training.
I am sure you understand.
( )
Sebastian. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Oct 11, 2007 3:02 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
C# does use the client tables, if you're careful. This means, basically, set the environment variables, configure it to .NET to use a client connection, and don't call the MQQueueManager constructor in any form that takes a qmgr name.
If I recall from previous conversations.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 11, 2007 3:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| I am sure you understand. |
I understand your environment, like many others, is trying to cut costs and time by throwing people like yourself in at the deep end in the hope that by some miracle you'll work it out. I understand that reality, but repeat my point that this is not the ideal way to learn MQ and/or a programming language. Nor is an application pieced together from questions asked in a forum always the best, resilient, production strength code.
I accept the situation is not of your making and is a common one in the industry today. That doesn't make it right.
My personal view, other views may be equally valid, I'm not affiliated with any political party or movement, etc, etc. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Oct 11, 2007 3:35 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Vitor - all you say is correct.
Jeff - you touched the key point :
""" don't call the MQQueueManager constructor in any form that takes a qmgr name """
It looks we are not clever enough to do it in this way !!!!
 |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Oct 11, 2007 3:40 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| jefflowrey wrote: |
don't call the MQQueueManager constructor in any form that takes a qmgr name.
If I recall from previous conversations. |
Revealing my "C sharp newbie" staus here, but if you don't supply a qmgr name, how do you expect to find the right entry in AMQCLCHL.TAB ? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 11, 2007 3:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Isn't there a default constructor? MQQueueManager()?
You should be able to tell that I have neither dug into the .NET manual this morning, nor dug into the search to find the last time this question came up... two weeks ago, maybe?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Oct 11, 2007 4:18 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
mr MVIC - the Queue Manager has to be blank in order to connect to few queue managers from a MQ CLient. In AMQCLCHL.TAB you specify their IPs but no qmgr mane, so mq client does choose any one of them
Search this forum for this phrase - there is quite large discussion there
>>> In that table it will try connecting alphabetically by channel name assuming the channels and MQCONN call have a blank QM name specified.
This is not C-sharp related, but MQclient + AMQCLCHL.TAB related ...
() |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 11, 2007 4:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| mvic wrote: |
| jefflowrey wrote: |
don't call the MQQueueManager constructor in any form that takes a qmgr name.
If I recall from previous conversations. |
Revealing my "C sharp newbie" staus here, but if you don't supply a qmgr name, how do you expect to find the right entry in AMQCLCHL.TAB ? |
I'm much more awake this morning than I was at this time yesterday, but obviously I should stop posting to this thread.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Oct 11, 2007 5:44 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| sebastia wrote: |
| This is not C-sharp related, but MQclient + AMQCLCHL.TAB related ... |
Thanks, I know about the AMQCLCHL.TAB but not much about your app requirements. Does your app care what queue manager it connects to, or is it coded to allow the channel table's rules to make the decision? If it cares what queue manager it connects to, it has to supply a queue manager name in the MQCONNX. If it wants to leave the decision to the client channel table rules you have to supply a queue manager name that is empty or contains an asterisk. Read more here and in the surrounding pages : http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzaf.doc/csqzaf0859.htm#wq299 |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Oct 11, 2007 5:57 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
mr MVIC - sorry I misunderstood your question ...
We want to achieve High Availability from our MQ Clients,
so they enter the "Host site" thru a front end of 2 or 3 MQ Server
that are in MQ cluster, where they hold the queues
that the destination MQ "backend" servers offer to the cluster,
this is, to the MQ Clients.
So, Clients do not care on what QM name they connect, as they use the "data" queue that is in the backend server.
Thanks. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Oct 11, 2007 6:08 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| sebastia wrote: |
| mr MVIC - sorry I misunderstood your question ... |
No apology necessary. I understand now, I think - thanks for the explanation. |
|
| Back to top |
|
|
| rlagares |
| Posted: Mon Oct 15, 2007 1:13 am Post subject: Solution |
|
|
Newbie
Joined: 09 Oct 2007
Posts: 7
|
Hello,
I am waiting information in another sites, and finally I make the conection using the CCDT. It should be very easy, but there aren´t good information about.
The steps to the solution are:
-Firstly you need to put in the appsettings the key "<add key="NMQ_MQ_LIB" value="mqic32.dll" />"
-Put the conections table in a directory.
-Introduce the envioroment variables: MQCHLLIB -> Path to the directory of the table, and MQCHLTAB->Name of the file of the table
-In the C# code use the MQQueueManager constructor:
"MQQueueManager oQueueMng = new MQQueueManager();". that constructor find in the CCDT the server, channel, etc.
-In the C# code, when you need to open a queue to put messages,
open the queue whith the option MQOO_BIND_NOT_FIXED, I am opening with the options MQC.MQOO_OUTPUT + MQC.MQOO_BIND_NOT_FIXED + MQC.MQOO_FAIL_IF_QUIESCING.
oQueueMng.AccessQueue("name of the queue", "open options"); |
|
| Back to top |
|
|
|
|
