I saw only the one problem:
>>We have had many instances of wrong lpars being deactivated and then
>>ipled incorrectly, changes to ipl environments not being applied
>>correctly...
I've also seen that even with trained, experienced operators to include
myself. Training and experience go a long way, but what about when it is
not enough?
You rework the process. Tough love, some pain, whatever it takes.
To answer your question: yes. At least in our tiny shop, the sysprogs do
the rare IPL. YMMV
If you want to reduce the operator error potential/rate, reduce the
number of keystrokes/clicks. Whatever it takes to do that. Not reduce
responsibilities mind you, just keystrokes/clicks.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Tom Marchant
Sent: Wednesday, October 01, 2008 1:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: HMC Management Best Practices
On Wed, 1 Oct 2008 11:47:18 -0500, Hal Merritt wrote:
>But the OP is complaining that that strategy is not working. And that
>experience/observation is in line with my own.
The op listed two problems.
On Wed, 1 Oct 2008 09:11:17 -0400, Mark Jacobs wrote:
>>One of our recurring problems is with the management, i.e. proper use
of
>>the HMC by the operators when they perform their job responsibilities;
>>
>>1) IPL an lpar with a specific load address/load parm.
>>2) Change lpar settings, storage, cpu's, weights,...
>>
>>We have had many instances of wrong lpars being deactivated and then
>>ipled incorrectly, changes to ipl environments not being applied
>>correctly...
Number 1 is clearly operations responsibility. Surely you are not
suggesting that this should be done by a sysprog?
>
>That is, even trained, experienced operators are making an unacceptable
>number of mistakes. We have to drill down to find root causes.
Sure. Everyone makes mistakes. I've done it. Haven't you? In my last
week as the lead systems programmer at a previous job, I IPLed a
production
LPAR by mistake. I had 30 years experience at the time.
>
>Here I think the most reasonable attack is to simplify what the
>operators are expected to do. And that means shifting the
responsibility
>for making critical system changes to a sysprog.
>
>With a combination of locking most loved LPARS and reducing the
operator
>involvement to clicking on an 'activate' icon, I would daresay the
error
>rate would drop to near zero. No process is perfect, but this basic
>strategy has worked for me in the past.
>
>A key to success would be an unchanging operator script with absolute
>minimal use of the word 'if'.
It should be no surprise that with a philosophy of removing
responsibility
from operators that they would act irresponsibly. My experience is that
operators who are treated with respect and given responsibility do good
work. Attempts to make a shop "operator-proof" don't work as well, IMO.
-- Tom Marchant
NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
