| Author |
Message
|
| jefflowrey |
 Posted: Mon Oct 01, 2007 2:33 pm Post subject: |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
 
All in good fun, I hope.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Oct 01, 2007 2:35 pm Post subject: |
|
|
Guest
|
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Oct 01, 2007 11:40 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Jeff and Bruce - having only one queue manager is not practical.
If you want the details, here they come.
Imagine we have 8 MQ Servers, and 8.000 MQ Clients.
We want to split the workload between 8 servers,
so we have to distribute 8 tables.
Having only one "test" or "generator" qmgr means to repeat 8 times :
1) delete queue manager (to delete old table)
2) create queue manager
3) create qmgr objects with selected SVRCONN and CLNTCONN
Practical (and I would say better - more "stable") approach is :
as we have to generate 8 qmgr definitions (for the 8 servers)
lets produce from qmgr-1 a table that gets 1/8 of the load,
from qmgr-2 a second table, ... and from 8-th qmgr the TBL_8.TAB
In this way, each qmgr has a "stable" definition, and generates a table that gives to him the preference of the client traffic.
Anyway, the environment changes and definitions have to be dealed with a lot of care .... And the testing has to be quite deteiled also ...
Cheers. |
|
| Back to top |
|
|
| belchman |
| Posted: Tue Oct 02, 2007 3:02 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Well,  , setting up a queue manager to manage only client channel tables might be sorta like "smashing a gnat with a sledge-hammer". But to each his own. They are free. 
However, using a queue manager that does not normally support client channel table connectivity to inspect the contents of distributed client channel table works for me.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 02, 2007 5:33 am Post subject: |
|
|
Guest
|
The concept of designating one qmgr for client table admin is more 'central site asset management' than sledge-hammer. Believe it or not, there are sites that have thousands of qmgrs.
It sounds like you misunderstood my and Jeff's suggestion, namely: you designate ONE qmgr where ALL possible clntconn channel definitions for all qmgrs and clients are made; then distribute the ONE client channel table to ALL the clients - not a unique channel table for each of your clients.
Sorry for not being clear. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 02, 2007 5:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think Belchman suggested it first in this thread...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 02, 2007 5:54 am Post subject: |
|
|
Guest
|
| Nothing repeats itself like redundancy, he reiterated. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 02, 2007 6:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Hey, I've got a great idea!
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 02, 2007 6:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
| Hey, I've got a great idea! |
Well it's been 30 seconds since your last one! 
(All Hail! All Hail!)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bbburson |
| Posted: Tue Oct 02, 2007 7:45 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
It appears to me that WMQv6 has thrown a contact admin wrinkle into the maintenance of channel table files. Here's what I've experienced, and if anybody has any suggestions for help they will be appreciated.
Under version 5.3 I had one queue manager that I used to manage two separate channel tables (one table for production systems and one for non-prod). The queue manager itself honored the MQCHLLIB and MQCHLTAB settings, so it was easy to switch between the two.
During the migration to version 6 the CLNTCONN channels became WMQ objects. Now it makes no difference how I have MQCHLLIB/MQCHLTAB defined, or what is in the AMQCHL.TAB file in @ipcc. I *ONLY* see the channels that were migrated with the queue manager.
I sure would like a way to get back to the old behavior if such is possible. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 02, 2007 2:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
use a test system.
Create a qmgr under 5.3
Give it the channel table you did not upgrade.
Migrate it to 6.0 ....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bbburson |
| Posted: Wed Oct 03, 2007 5:28 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| fjb_saper wrote: |
use a test system.
Create a qmgr under 5.3
Give it the channel table you did not upgrade.
Migrate it to 6.0 ....
|
Yes, that is basically what I have done to manage the separate tables. But now I have to have a queue manager PER TABLE to maintain updates, where in the past a single queue manager could handle multiple tables by simply redefining MQCHLLIB/MQCHLTAB. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 03, 2007 6:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
maintain a set of delete/define MQSC scripts for each of your tables.
Update the scripts, generate the table against a single queue manager, move the new table elsewhere.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| LouML |
| Posted: Wed Oct 03, 2007 8:38 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| fjb_saper wrote: |
use a test system.
Create a qmgr under 5.3
Give it the channel table you did not upgrade.
Migrate it to 6.0 ....
|
Does the AMQCLCHL.TAB file get created automatically when you do a crtmqm? Or only when you define the CLNTCONN channels? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 03, 2007 9:38 am Post subject: |
|
|
Guest
|
| Quote: |
| The queue manager itself honored the MQCHLLIB and MQCHLTAB settings |
Nope. These are environment variables used by the client. You can (at v5 and v6) (re)name the channel tables anything you want, and put them anywhere on the path. Then you can point to whichever table your application needs.
The client table is created/updated when you create clntconn channel definitions. |
|
| Back to top |
|
|
|
|
