| Author |
Message
|
| belchman |
 Posted: Mon Jul 26, 2010 4:55 am Post subject: Best Practice for Managing ZPARMS |
 |
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
We had an incident over the weekend where a couple of qmgrs (non-prod thankfully) would not come up after upgrading to MQ for z/OS v.7.0.1.
The reason they would not come up was because their zParms were v2.1 
Now I need to come up with a process by which we mitigate the chances of this occurring again.
I am soliciting you, ol' wise ones, for your ideas. What would you do to fix this? Do you compile your zParms at each upgrade?
Thank you for your input!
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Jul 26, 2010 5:09 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
My thoughts:
1) delete (or rename) the default zparm member so it can never be used by omission
2) create a meaningful (and unique) zparm name that describes LPAR, mq version/release, prod/qa/test, etc..
3) use a checklist for deploying a new qmgr
4) follow the instructions in the WMQ for z/OS System Setup manual. Step n has you tailor the zparm member
_________________
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 |
|
|
| Vitor |
| Posted: Mon Jul 26, 2010 5:14 am Post subject: Re: Best Practice for Managing ZPARMS |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| belchman wrote: |
| Do you compile your zParms at each upgrade? |
More importanly, by following the documented steps for customizing a queue manager except those which say "you do not need to perform this step when migrating from a previous version". This includes the tailoring of the system parameters.
My reasoning for this pedantic method? Someone has had to read & evaluate the step. Depending on site naming standards it's most likely you don't need to take any action for Task 6 (JCL procedures). But someone has still had to look & say positively "yes, we don't have version numbers in DSNs so we don't need to change the procedures" rather than relying on folk knowledge & tales of the Old Wise Ones who step up the system that you don't need to do that. Also it provokes the thought "so if we don't pick up the new version with DSNs how do we do it?". I also have the unchanged procedures (in this example) copied to a new lib so come the migration to a new version there is a step to copy the "new" proc in to the PROCLIB. With the comment line at the top "Reviewed by G. Baconburger 26th July 2010 as part of v7 migration & left unchanged".
(I'm a firm believer of the focusing power of having your name prominently & accountably in your work. Focuses the mind of your minions.)
From this slow grind through the instructions you end up with a positive list of tasks & confidence that all the i's have been dotted & t's have been crossed. Also when you raise the PMR you can say with confidence "yes, we followed the instructions".
My 2 cents, other methods may be equally valid, etc, etc.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| belchman |
| Posted: Mon Jul 26, 2010 5:15 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Good ideas Bruce. I will consider those.
The big problem RE this Sunday's issue was that apparently the 2 offending queue managers were first put into operations when MQ v2.1 was the current version here. The migration guide says 'If you do not need to use these parameters, you do not need to relinkedit your system parameter module".
I think we carried that a little too far.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 26, 2010 5:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| belchman wrote: |
| I think we carried that a little too far. |
I've always been amused by that line; who doesn't use those parameters? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 26, 2010 5:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The migration guide says 'If you do not need to use these parameters, you do not need to relinkedit your system parameter module" |
Please post the url or doc number for migration from 2.1 to 7.x.
When you encounter conflicting documentation, do more research, then follow the instruction(s) that are most conservative (least risky). A choice between following setup instructions - assembling and linking ZPARM (2 seconds of cpu?) vs potential for a qmgr failing - seems like an obvious choice - best-practice-wise.
_________________
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 |
|
|
| bruce2359 |
| Posted: Mon Jul 26, 2010 5:27 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| who doesn't use those parameters? |
And who doesn't follow carefully crafted installation and setup instructions.
Enter this under the self-inflicted-wound category.
_________________
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 |
|
|
| belchman |
| Posted: Mon Jul 26, 2010 5:43 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 26, 2010 6:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
"The reason they would not come up was because their zParms were v2.1"
So, your startup proc for a 7.x qmgr had 2.1 loadlibs in it?
Call me anal, but for every qmgr deployment, I go back to the System Setup manual instructions. I follow each step. It's a habit that I learned early on; and it has never failed me.
_________________
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 |
|
|
| Vitor |
| Posted: Mon Jul 26, 2010 7:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| "all me anal, but for every qmgr deployment, I go back to the System Setup manual instructions. |
This is kinda the point I was making, but I prefer "detail-orientated". 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 26, 2010 7:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| but I prefer "detail-orientated" |
A good euphemism.
_________________
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 |
|
|
| belchman |
| Posted: Mon Jul 26, 2010 9:51 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Thx all. I am putting together my plan.
Vitor, your tag says you are in Ohio. What city are you in? I am in Columbus.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 26, 2010 10:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| belchman wrote: |
| Vitor, your tag says you are in Ohio. What city are you in? I am in Columbus. |
I'm an hour or so north of you. Probably a safe distance. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ctefehinoz |
| Posted: Mon Jul 26, 2010 4:10 pm Post subject: |
|
|
Apprentice
Joined: 27 Oct 2003
Posts: 29
Location: Australia
|
Hi,
Our shop essentially did what Bruce suggested after one of my bods got the upgrade sequence incorrect years ago on a 2.1 to 5.3 upgrade. We developed and applied a USERMOD to rename the ZPRM (CSQZPRM) to IBMZPARM and we now compile a "qmgr"ZPRM module for every queue manager. The start of course needs a START QMGR PARM(qmgrZPRM) but I sleep easier at night knowing our Queue managers can't come up off the supplied defaults or a CSQZPRM from who-knows-where.
HTH
Ctefehinoz |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 26, 2010 4:37 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
As you roll your qmgrs from one release to the next, you might want to name the zparm something that includes versioning - to prevent a v53 zparm in a v70 qmgr.
MQxxV70P would indicate:
MQxx = qmgr name
V70 = version 7.0
P = production vs. Test vs. Qa
_________________
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 |
|
|
|
|
