| Author |
Message
|
| jenchao |
 Posted: Fri Oct 10, 2008 12:05 am Post subject: Client connect to 2 MQ Servers |
 |
|
Newbie
Joined: 09 Oct 2008
Posts: 2
|
Anyone please 
I have 2 separate MQ Server machine (MQ Server 5.3 and MQ Server 6) and a MQ Client 6.
May I know if it's possible for the Client to connect to both MQ Server machine at the same time?
How do I configure the MQSERVER environment variable to connect to 2 MQ Server? |
|
| Back to top |
|
 |
| zpat |
| Posted: Fri Oct 10, 2008 12:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It's better to connect to one QM and arrange message routing between QMs using remote queues.
MQSERVER is not the correct way to define client connections data, use the Client Channel Definition Table.
Using CCDT you can connect to any number of queue managers at the same time, but again - this is not usually desirable. |
|
| Back to top |
|
|
| jenchao |
| Posted: Fri Oct 10, 2008 12:55 am Post subject: |
|
|
Newbie
Joined: 09 Oct 2008
Posts: 2
|
Thanks!
Understand that CCDT can be use to connect to a list of queue managers in the same MQServer but can it be use to connect to queue managers that locate on different server machine? |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Fri Oct 10, 2008 1:36 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
| jenchao wrote: |
Thanks!
Understand that CCDT can be use to connect to a list of queue managers in the same MQServer but can it be use to connect to queue managers that locate on different server machine? |
sure, use CCDT for the same, read MQ Client for more information
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| ranganathan |
| Posted: Fri Oct 10, 2008 1:37 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2008
Posts: 104
|
| jenchao wrote: |
Thanks!
Understand that CCDT can be use to connect to a list of queue managers in the same MQServer but can it be use to connect to queue managers that locate on different server machine? |
Yes.. it is possible to connect to the QM on the different machine using CCDT.
Instead of using CCDT, you can also use MQSERVER to connect to the first QM and route the message to the second QM using remote queue definitions. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 10, 2008 2:18 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
MQSERVER is essentially an override of the normal client connection definition table.
I consider it bad practice to use MQSERVER instead of maintaining a CCDT. Especially if you have large number of client machines |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 10, 2008 1:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
| I consider it bad practice to use MQSERVER instead of maintaining a CCDT. Especially if you have large number of client machines |
How come? I'm asking in the case where the CCDT would have only a single entry in it. Obviously CCDT's make more sense when you have secondary and tertiary servers to go to.
I understand that MQSERVER doesn't allow things like SSL and limits you to 4MB. Is there anything else? I ask because a new project is coming and this was a consideration. If no SSL and no messages bigger than 4 MB, MQSERVER is a lot clearer and explicit, versus opening a binary .TAB file and trying to determine where you environment is pointing you at. Sure you cna name the channel table file descriptively, but that could be renamed.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Oct 12, 2008 6:02 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| PeterPotkay wrote: |
| I understand that MQSERVER doesn't allow things like SSL and limits you to 4MB. Is there anything else? I ask because a new project is coming and this was a consideration. If no SSL and no messages bigger than 4 MB, MQSERVER is a lot clearer and explicit, versus opening a binary .TAB file and trying to determine where you environment is pointing you at. Sure you cna name the channel table file descriptively, but that could be renamed. |
MQ Client v7.0 increases the maximum message length (MAXMSGLN) to 100MB on CLNTCONN channels defined using MQSERVER.
Its quite OK to use MQSERVER if your client app only needs to use one channel to one queue manager, and SSL and exits are not required.
_________________
Glenn |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Oct 13, 2008 12:30 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The reasons I consider MQSERVER bad practice are many fold.
1. It prevents the central maintenance and distribution of a "master" client channel table.
2. It prevents use of advanced client connection features such as SSL.
3. It presumes that all MQ client applications on that platform will use the same queue manager.
4. Too easy to make local modification causing support issues.
5. You can use the CCDT for load-balancing and failover selection of queue managers in certain ways.
When you have thousands of desktops each with several MQ client based applications - it's more important perhaps than the odd application server with only one MQ application on.
Updating a file (held on a LAN drive) is somewhat easier than trying to arrange the updating of an environment variable on every desktop. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Oct 13, 2008 3:01 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
As regards the setting of the MQSERVER variable, I have (in the past) been on a site where the applications set the variable 'locally', i.e. within a discrete environment session, before invoking; the rationale behind this was to prevent load on any one server, and maintenance and deployment of a CCDT by the WMQ Team was next to impossible.
I'm a little torn between zpat and PeterPotkay as both make valid arguments for and against, however I suppose it depends on best fit for the requirements, and what is achievable in regards to management.
_________________
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. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 13, 2008 5:09 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
When you have thousands of desktops each with several MQ client based applications - it's more important perhaps than the odd application server with only one MQ application on.
|
We live in entirely different MQ worlds! 
I do not disagree with anything you say, especially given your topology compared to mine.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Oct 13, 2008 3:35 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
| ...Updating a file (held on a LAN drive) is somewhat easier than trying to arrange the updating of an environment variable on every desktop. |
Setting the MQSERVER environment variable can be done in a batch/shell file that starts the client app, and that file can live on a LAN drive. Also, the application can set its own MQSERVER environment variable. So, there is no real difficulty in managing MQSERVER compared with CCDT.
_________________
Glenn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Oct 13, 2008 5:31 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You'd really like a batch/shell file that set MQCHLTAB and MQCHLLIB anyway. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Oct 14, 2008 4:27 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| mqjeff wrote: |
| You'd really like a batch/shell file that set MQCHLTAB and MQCHLLIB anyway. |
Yes, indeed. The default MQCHLTAB value of AMQCLCHL.TAB should not be used, it should have an application or system specific name, eg. MYAPP.tab.
It can be useful to have a version number in there too, so that multiple files can be updated and deployed under change management, and the app just switches between them by changing the setting of MQCHLTAB, eg. MYAPP1.tab, MYAPP2.tab.
_________________
Glenn |
|
| Back to top |
|
|
| dkeister |
| Posted: Wed Oct 15, 2008 8:20 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
I realize the jenchao is a first time poster so hope this won't confuse the issue.
I have the scenario where I want to be able to connect to a queue manager without having defined either entries in the AMQCLCHL.TAB or supplied MQSERVER settings.
I use MQCONNX call and specify the relevant information in the MQCNO structure. That way, my application prompts the user for:
- Server Channel Connection Name (SYSTEM.AUTO.SVRCONN is a convenient default but may require a specific, named SVRCONN)
- Connection Name which takes the format
{server machine name or IP address}(Port#) with localhost often a good default.
I can prompt for these parameters and establish a client connection to any host that will allow it without needing to have to predefine settings.
As I said, this is probably not what you would want for the average user, but might be useful for cases where you never know who you may need to connect to.
Also, this allows simultaneous connection to multiple queue managers if you are careful.
_________________
Dean Keister |
|
| Back to top |
|
|
|
|
