Author |
Message
|
SAFraser |
Posted: Fri Oct 16, 2009 10:41 am Post subject: Queue Manager Scripting for New Data Center |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
How would you do this?
Our entire development environment is being replaced with new hardware in a new data center. (That sounds like a lot more fun than it actually is.)
We have about 30 dev queue managers. They all have basically the same queues and channels - basically, but not entirely - so while most objects are common to all 30 queue managers, a few are not.
Examples of objects that are not common are: server connection channels with unique channel exit config files, sender/receiver pairs, remote queues that have real destinations vs. fake xmitqs, remote queues with unique destinations, and so forth.
To make things even more interesting, the new queue managers will not have the same names as the old queue managers as there will not be a one-to-one relationship between old and new.
So - how would you go about making a master script for this? I thought of several alternatives and this is the one I am currently doing:
I chose an existing queue manager that is relatively "clean" in terms of it being current with its objects.
I exported the objects using a QPasa tool that is like saveqmgr. (I used QPasa because it puts both the objects and the OAM authorizations into the same handy file.)
I created a clean queue manager and imported the file.
I will use MQExplorer or QPasa to alter objects with 'dummy' parameters where needed. Exported, this will be the master script.
Then I will use the master script to create a unique script for each queue manager, altering the 'dummy' parameters as needed.
Seems like a lot of manual work, but I can't come up with anything better. Ideas?
Thanks. |
|
Back to top |
|
 |
Vitor |
Posted: Fri Oct 16, 2009 6:20 pm Post subject: Re: Queue Manager Scripting for New Data Center |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
SAFraser wrote: |
Seems like a lot of manual work, but I can't come up with anything better. Ideas? |
You could take some of the sting out of this by using your "master" script with dummy parameters as you suggest, but wrapping this in another script to generate 30 versions for the individual queue managers. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
smdavies99 |
Posted: Fri Oct 16, 2009 11:10 pm Post subject: Re: Queue Manager Scripting for New Data Center |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Vitor wrote: |
You could take some of the sting out of this by using your "master" script with dummy parameters as you suggest, but wrapping this in another script to generate 30 versions for the individual queue managers. |
I did this some years ago (circa V5.2 days). i generated a master script (on Solaris) that did the whole works. It is indeed a lot of effort and I don't have the scripts as it was done on a secure site...
I use a simpler method now. I'm guessing that a lot of stuff will be common (Queues Mainly) between the QMGRS, so put all the 'non changeable' bits into one set of definitions into one file and then generate on the fly, the bits that are QMGR Name dependent. For example Channel Name pairs. If you have a decent object naming standard in place then this is quite straightforward.
As a tip, move as much common Queue Definition setup into the Default Q definition. This way when you specify the App queues you only need to define things like DESCR, MAXDEPTH & Persitence on individual queues. This makes for a much more maintainable set of definitions. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
SAFraser |
Posted: Mon Oct 19, 2009 9:59 am Post subject: |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
Good ideas from both of you, and I thank you.
I like the idea of two scripts per queue manager. I wonder if I can read some variables into the 'unique' script -- as you say, if I have naming conventions, the object names should be predictable.
Naming conventions. I actually did not laugh out loud when I typed that. |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Oct 19, 2009 10:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You can use variables, but you end up needing, basically, a third script that does the replacements on the second script.
So you have one script that just gets piped into runmqsc, and then another script that gets piped through something that does variable substitution and the output of that gets piped to runmqsc. |
|
Back to top |
|
 |
smdavies99 |
Posted: Mon Oct 19, 2009 11:48 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Quote: |
Naming conventions. I actually did not laugh out loud when I typed that.
|
You are not alone in that reaction.
Quite often when I show an example of a Channel name I get puzzled looks.
For example
SYSTEM1.T1.SERVER2
From System1 to Server2. Channel Number 1
A Second channel between the two would be
SYSTEM1.T2.SERVER2
Then when I try to explain Queue Manager Aliases the puzzlement changes to bewilderment.
I had to review one system a couple of years ago. The complaint was that it was difficult to see what went where. After my examination I had to conclude that it was a dogs breakfast.
 _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
Michael Dag |
Posted: Mon Oct 19, 2009 12:42 pm Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
I hate to point out the obvious...
MQArchitect gives you the full visual topology view you will ever need, plus all the variable/template tricks in the book you can think of and a complete set of tools to do "blind horse" deploys...
 _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
Vitor |
Posted: Mon Oct 19, 2009 1:19 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
smdavies99 wrote: |
The complaint was that it was difficult to see what went where. After my examination I had to conclude that it was a dogs breakfast.
 |
I never cease to be amazed how many sites complain they can't trace message flow (i.e. what message goes where) and have things like FINANCE.OUTBOUND as the xmitq name....  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|