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
] On Behalf Of R.S.
Sent: Monday, October 06, 2008 12:29 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: HMC Management Best Practices
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
The Chairbreaker! :-)
I'm trying to forget! grin
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Rick Fochtman
Sent: Wednesday, October 01, 2008 4:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: HMC Management Best Practices
That's true
Management Best Practices
No, I don't.
-
Robert B. Richards(Bob)
US Office of Personnel Management
1900 E Street NW Room: BH04L
Washington, D.C. 20415
Phone: (202) 606-1195
I know how to lock images, but I can't seem to figure out how to lock profiles.
Thanks.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
I don't know about best practices, but we:
- Make religious use of LPAR grouping - Test images in a test folder, Prod
images in a Prod folder. That at least keeps the Operators from activating a
Prod image when they meant to activate a test image. We still get the
occasional brain check
Management Best Practices
That's true, until you get an operator that's too lazy tocrack open a
manual, whether to look up a message or try and learn something new, and
he's also too gutless to accept any responsibilities. And a
management team that's too soft-hearted (or soft-headed) to do
Subject: Re: HMC Management Best Practices
That's true, until you get an operator that's too lazy tocrack open a
manual, whether to look up a message or try and learn something new, and
he's also too gutless to accept any responsibilities. And a
management team that's too soft-hearted (or soft
Howard,
The REJECT command only removes PTFs from the GLOBAL zone.
If you want to affect the TLIB/DLIB you would use RESTORE.
I use RESTORE/RECEIVE process when I am working with a usermod, it has not
touched the TLIB/DLIB when I do this.
Lizette
Upon second look SMP told me that the PTF
01, 2008 4:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: HMC Management Best Practices
That's true, until you get an operator that's too lazy tocrack open a
manual, whether to look up a message or try and learn something new, and
he's also too gutless to accept any responsibilities
, October 01, 2008 4:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: HMC Management Best Practices
That's true, until you get an operator that's too lazy tocrack open a
manual, whether to look up a message or try and learn something new,
and
he's also too gutless to accept any responsibilities
My apologies to the list for the private email to Rick.
Bob
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at
On Thu, 2 Oct 2008 11:25:14 -0400, Howard Rifkind [EMAIL PROTECTED] wrote:
Upon second look SMP told me that the PTF was accepted, it is in the TLIB
as well as in the DLIB.
So, it now is in all three zones.
I don't want to reject the PTF from TLIB/DLIB just from the global zone.
How would
-MAIN@BAMA.UA.EDU
Subject: Re: HMC Management Best Practices
On Thu, 2 Oct 2008 11:25:14 -0400, Howard Rifkind
[EMAIL PROTECTED] wrote:
Upon second look SMP told me that the PTF was accepted, it is in the
TLIB
as well as in the DLIB.
So, it now is in all three zones.
I don't want to reject
On Thu, 2 Oct 2008 11:55:49 -0400, Jousma, David [EMAIL PROTECTED] wrote:
In addition to what Mark mentions, also optionally setup your SMPE
options to include a RECEIVE ZONE GROUP, so that PTF's once applied and
accepted, don't get re-received again if you order bulk maintenance.
Good advise.
The Chairbreaker! :-)
I'm trying to forget! grin
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Rick Fochtman
Sent: Wednesday, October 01, 2008 4:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: HMC Management Best Practices
That's true
List [mailto:[EMAIL PROTECTED] On
Behalf Of Rick Fochtman
Sent: Wednesday, October 01, 2008 4:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: HMC Management Best Practices
That's true, until you get an operator that's too lazy tocrack open a
manual, whether to look up a message or try and learn
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
What are some best practices that you use to prevent these and other operator
errors while performing HMC tasks?
Education
Threat of termination
Use of staff more sophisticated than systems operators
Locking of HMC
Change control/auditing
-
Too busy driving to stop for gas!
Umm, train them? Then use test LPAR's to keep their skills fresh? And
operators should NOT be changing weights, storage, CPU's etc. without a
sysprog there. Define the CP's and use config to vary them on/off.
Just my $.02
Doug
Mark Jacobs wrote:
One of our recurring problems is with the
I tend to agree with Doug. The only thing our operators ever do is IPL. They
do have to select the correct LPAR and put in the correct load address and
loadparm if that changes. The loadparm rarely changes... usually when we
upgrade the OS it temporarily points to LOADx9 for example... for z/OS
Hi Mark,
In respect of your request for information on:
What are some best practices that you use to prevent these and other
operator errors while performing HMC tasks?
Having had some experience with a company managing 100+ z/OS Systems, across
7+ sites I think the two staple requirements to
snip
proper use of the HMC by the operators when they perform their job
responsibilities
unsnip
I tend to agree that 'their responsibility' appears to be more than
operators tend to have. Another option is to support remote HMC access,
inside a VPN(ish) environment, and let the sysprog(s) tend
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs
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.
Let the operator do the IPLs with only one Default LOAD profile that uses
dynamically changed address
for Load address and Use dynamically changed parameter for the load
parameters. The system programmers will then control everything via HCD.
Of course the operators still need to perform the
.
4. Allow changes of the LOAD ADDRESSES and LOAD PARMS only.
Kevin
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Jacobs
Sent: Wednesday, October 01, 2008 9:11 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: HMC Management Best Practices
One
Jihad K Kawkabani wrote:
Let the operator do the IPLs with only one Default LOAD profile that uses
dynamically changed address
for Load address and Use dynamically changed parameter for the load
parameters. The system programmers will then control everything via HCD.
Of course the operators
, October 01, 2008 8:11 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: HMC Management Best Practices
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
On Wed, 1 Oct 2008 09:25:56 -0500, Hal Merritt wrote:
First, I would respectfully submit that this not an operator problem.
Operators make mistakes and any dependence on operators accepts that as
a consequence.
People make mistakes. Operators certainly are in that category. Operators
can be
] On
Behalf Of Tom Marchant
Sent: Wednesday, October 01, 2008 10:57 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: HMC Management Best Practices
On Wed, 1 Oct 2008 09:25:56 -0500, Hal Merritt wrote:
..snip
You are right back where you started. People make mistakes. If
operators
are properly trained
cc
Discussion List
[EMAIL PROTECTED] Subject
.EDU 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
Tom Marchant wrote:
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
I came up as an Operator and I have been a sysprog for a number of years now.
All of my fellow sysprogs here were Operators at one time. I suspect that is
true for most of us.
I remember, when I started, that we were lucky if at least one of our systems
didn't turn toes up and crash at
That's true, until you get an operator that's too lazy tocrack open a
manual, whether to look up a message or try and learn something new, and
he's also too gutless to accept any responsibilities. And a
management team that's too soft-hearted (or soft-headed) to do anything
about it.
: 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
I'm a small shop (1 CEC, 4 LPARs + Sandbox) so life is a little easier.
Major changes a Sysprog is on site to (at least) verify the changes were
correct.
Sysprog handles all updates to the HMC (we don't use dynamic IPL parm
changes) we just update the LOAD profile as needed (maybe once a year).
37 matches
Mail list logo
