| Author |
Message
|
| Sue_2828 |
 Posted: Wed Apr 15, 2009 5:33 am Post subject: Not too clear about Channel Table |
 |
|
Apprentice
Joined: 14 Feb 2009
Posts: 37
|
Hello there,
I have MQClient on Windows,MQ Sever on two aix servers.
I created QM1 and QM2 on two of aix servers ,one on each.
Created Client Connection Channel Table for these queue managers. Now I know I need to place at Client connection Channel Table on Windows box and able to put the messages. My question is , what channel table do I copy to windows. If I have created client connection on both Servers then I end up with 2 CCDT. Am I doing something wrong or not clear about doing this. The Java client should point to 1 channel table but I have 2 of them one from each server. Can someone clear this to me.
Thanks |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Apr 15, 2009 5:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can use either of them, and you don't need to create the table on both queue managers anyway.
You do need the SVRCONN half on each qmgr, but not the CLNTCONN. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Apr 15, 2009 5:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
CLNTCONN definitions are only used to populate the client connection channel table. You export the table to the client platform.
You might want to consider creating a qmgr whose sole purpose in life is to create the client connection channel table.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Apr 15, 2009 5:49 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Sue_2828,
I believe you are going to connect to one QMgr on one AIX at a time and not at the same time(I think its not possible to connect to both AIX boxes at a time). If that is the case you can place your CHLTAB in different locations and point to that particular location whichever QMgr(whichever AIX box) you are trying to access.
Thanks. |
|
| Back to top |
|
|
| Sue_2828 |
| Posted: Wed Apr 15, 2009 5:52 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2009
Posts: 37
|
Thanks Jeff, so I just need to make sure SVRCONN created on each queue manager and one should have the clintconn channel created on it. Then I will just copy the channel table from the machine where both svrconn and clintconn is created.
One more question , what if both the client and server are on the same machine ? I mean if the application which tries to put into the queue manager runs on the same machine as the queue manager? Do I need to configure it same way?
Sue |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 15, 2009 5:54 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Sam Uppu wrote: |
Hi Sue_2828,
I believe you are going to connect to one QMgr on one AIX at a time and not at the same time(I think its not possible to connect to both AIX boxes at a time). If that is the case you can place your CHLTAB in different locations and point to that particular location whichever QMgr(whichever AIX box) you are trying to access.
Thanks. |
You only need one channel table to connect to QM1. Or to QM2. Or to QM1 and QM2 at the same time.
Sue, explain how you want your app to connect to these 2 QMs? load balanced? Always to 1 and only to 2 if 1 is N/A? To both concurrently (not a good idea usually)? Or your app decided which one at runtime?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Sue_2828 |
| Posted: Wed Apr 15, 2009 5:59 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2009
Posts: 37
|
Thanks Bruce,
To Sam,
No I am not trying to connect at the same time to both queue managers , , the application will be putting into one queue manager but if this queue manager is not available for any reason then we need application to start putting into the other one which is running on the other machine.
Again , the same question which I have posted above , what if the application which puts into the queue manager is on the same machine as the Queue Manager , then for some reason , the queue manager is down , can the application point to the other queue manager on a different server? does the same configuration apply here ?
I am learning a lot here so thank you  |
|
| Back to top |
|
|
| Sue_2828 |
| Posted: Wed Apr 15, 2009 6:04 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2009
Posts: 37
|
Hi Pete,
Sue, explain how you want your app to connect to these 2 QMs? load balanced? Always to 1 and only to 2 if 1 is N/A? To both concurrently (not a good idea usually)? Or your app decided which one at runtime?
Both Queue managers are running at the same time, however, we would be connecting to one at one time. If the queue manager is down , the app should point to Queue Manager 2 on Server 2. So if I copy channel table from server1 , how would the app learn about server2 ? I am going Banana here  |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Apr 15, 2009 6:11 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
So long as you don't specify localhost in the CLNTCONN/SVRCONN connection name, no problem. When you create the CLNTCONN channels (note the plural) on the queue manager you have decided to use, you use the SVRCONN details of each queue manager, i.e. QM1.SVRCONN has the connection name details for that queue manager, QM2.SVRCONN has the connection name details for that queue manager. Even though it is on another server, the details are populated into the CCDT, which is then exported. bruce2359's suggestion is not a bad one if you will be using WMQ Client a lot, and want a 'central repository' for your CCDT(s)
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Last edited by exerk on Wed Apr 15, 2009 6:13 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 15, 2009 6:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
When I first started with MQ, this caused me problems too. Do a search for some of my earliest posts here.
On QM1, create a SVRCONN called MY.CHANNEL.1
On QM2, create a SVRCONN called MY.CHANNEL.2
On some QM, any QM, create 2 CLNTCONN channels, called MY.CHANNEL.1 and MY.CHANNEL.2. Make sure the QM name parm is blank. Make sure the server name(port#) for QM1 is in the CLNTCONN channel MY.CHANNEL.1, and the server name(port#) for QM2 is in the CLNTCONN channel MY.CHANNEL.2.
Copy that one channel table to your MQClient server and set the variables correctly to reference it. When your client app issued an MQCONNX call with no QM name specified, the channel table will be searched alphabetically. It will always try MY.CHANNEL.1 first, and if that QM is N/A, it will go to MY.CHANNEL.2.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 15, 2009 6:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sue_2828 wrote: |
| So if I copy channel table from server1 , how would the app learn about server2 ? |
Because you'd have both queue managers (not servers just to be pedantic) in a single CCDT. The suggestion of bruce2359 is a common one; a queue manager who's job is to create such artifacts. If the CCDT contains details for 2 queue managers, or the app connects to a wildcard, then the first queue manager sequentially in the CCDT that responds will be connected to.
Hence if QMA goes down, the app gets a 2009, attempts to reconnect using the same table, but gets QMB even though it thinks it's remaking the connection. Note the app logic must handle the fact it's talking to a different queue manager.
Where using a seperate queue manager scores is if you have different configurations. Say App1 connects to QMA or QMB or QMC in that order. If you have another instance of the app, geographically separated that connects to QMB or QMA or QMC for network reasons you need 2 CCDTs to achieve this. Easier to manage on a separate qmgr.
Hope that helps.
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Wed Apr 15, 2009 6:34 am; edited 1 time in total |
|
| Back to top |
|
|
| Sue_2828 |
| Posted: Wed Apr 15, 2009 6:32 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2009
Posts: 37
|
| Thanks for all the input , I will try it out and let you know. |
|
| Back to top |
|
|
|
|
