On 07/23/2012 12:58 AM, David Boyes wrote:
From: Mary Anne Matyaz <maryanne4...@gmail.com>
[snip]
David, the best way to submit a requirement is through Share. Anyone can submit
a requirement.
Share has a new website that you'll need to sign up for, but you don't have to
be a Share member.
http://reqs4.share.org/Reqs4Who.jsp is the link to the requirements system.
I was hoping for an alternative to that route. Been there, done that, wasted a
lot of time. That site is *awful*.
The only thing positive I can say about it is that it's (slightly) better than
the previous one.
Really, I'm not really interested in totally rearchitecting the way
applications die -- I can cope with there being different ways to deal with
that. I just want z/OS to let me know that it got the shutdown initiated signal
from the hardware and I should start whatever I need to do to take down the
system gracefully. I know the steps -- now all I need is the match to light
off the process. Right now, z/OS is fat, dumb, and happy all the way to the
firing squad wall of data corruption because it can't see the firing squad
coming.
Historically, the z/OS folks have fought implementing anything that would play
nice with VM for various reasons, but this is hardware originated stuff. No
excuses, political or otherwise. At least raise a flag, or something...
printing a console message can't be THAT hard.
I haven't used the SHARE site for over a year, so can't speak about its
current user interface; but don't equate/confuse the SHARE Requirements
web interface with the SHARE Requirements process. The user interface
used to be extremely primitive in the years before the web, but the
process was still highly useful. And remember, part of the requirement
is directed at convincing IBM, not just other users, that implementation
is in their best interest.
The SHARE Requirements route is important because requirements are
evaluated by and voted on by other SHARE member installations - in
effect vetted by the SHARE community. If you can state a requirement
that is of such obvious usefulness that your requirement gets strong
positive votes from multiple SHARE member sites, then when that
requirement goes to IBM it is clear it is perceived of general benefit
and is more likely to be taken seriously. Unless you represent a major,
major purchaser of IBM hardware/software, a requirement requested by
only one installation will be given less consideration than the many
other requirements competing for IBM's resources that affect multiple
installations and have a clearer positive impact for many users and IBM.
If there is not already some interface that z/VM can use to communicate
with an underlying z/OS system that a graceful shut down is advisable,
this sounds very useful, since there might be an Operational need to
terminate z/VM and that could affect many dependent systems.
In the case of z/OS (and its predecessors) running native in an LPAR, I
am less sure about the utility of an LPAR termination message to z/OS.
In 25 years on MVS, in all the cases where a hardware issue that MVS
couldn't handle would have made a controlled shut down advisable, either
there was time for a manual decision to do an automation-assisted shut
down (some times deferred after evaluation), or the failure was of a
nature that orderly shut down was simply impossible. We saw a number of
cases over the years where it was useful to continue operation in a
degraded mode. In other cases when it was necessary to initiate shut
down, doing this directly on MVS using MVS automation tools actually
required fewer actions by the Operator than doing an LPAR shut down, and
having that somehow trigger MVS shut down indirectly. No matter how
initiated, even with automation an orderly shut down of a complex z/OS
system always took us 5-10 minutes, and when other "strange" things were
happening frequently required some Operator judgement and active
intervention at some point during the process. So, I'm just saying an
LPAR shut down message to z/OS would have been of marginal use to our
installation, and you certainly don't want LPAR shut down to be
dependent on an "OK" from the Operating System, as that might be the
part of the OS that is "broken".
I have seen cases in the past where it would make sense to have z/OS
better communicate to the hardware that z/OS is quiesced and that the
HMC should allow LPAR deactivate without the usual warning about a
disruptive action. When you always get the warning even after z/OS is
effectively stopped, it ceases to be a useful warning.
The ability to "lock" an image is supposed to provide the protection
against accidental deactivation of the wrong LPAR, but this requires
documented installation procedures and training of concerned personnel
to always "lock" important images after IPL, and to not just do "unlock"
and "deactivate" as a single process, but to actively verify at both
steps that the correct LPAR is specified. As another approach, extra
protection could be provided by setting up special HMC logons that only
have access to specific LPAR images to enforce what images an individual
may activate/deactivate in the context of that logon. Or at a minimum,
separate HMC groups should set up for Production versus Test Images and
these used exclusively when activating/deactivating LPARS, so there is
no way a production image could be selected for deactivation or IPL when
a test image is intended.
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
