We too placed SHUTDOWN in a class of its own: S, and only VMOPER has it.  If
I really want to do a shutdown, I can: SET PRIVCLASS * +S.
We also have a SHUTDOWN EXEC that shows a selection panel, brings down DB2
servers gracefully, ... The code also includes SET PRIVCLASS * +S, so the
class change is almost transparent.

My second-level test system is active all the time, it is even the "home" of
all sysprogs; "home" means that we code our execs etc there.  All SW is
installed and maintained there, promotion to production systems is by
SENDFILE, remote SFS, or even DDR (after doing a DEFINE MDISK to get access
to the minidisk of the test system).  The advantage is that any installed
maintenance is a bit tested by everyone. For automated operation & backups,
this test system is like any other VM we've got; we keep the backup even
longer.  We work like this since day 1 (VM/SP R6 days).  Disadvantage: I
have to ask the collegues if I can re-IPL it.

2007/8/23, Ivica Brodaric <[EMAIL PROTECTED]>:
>
> We have SHUTDOWN command in a privilege class of its own and only one ops
> userid has that class. That user has a SHUTDOWN EXEC on its A disk. Not to
> prevent the shutdown but to actually do it. It first checks that it's being
> run from that particular user and then asks a are-you-shure-type question.
> That pretty much eliminates the possibility of an accidental shutdown of
> the first level. I mean, you can still add that shutdown-only privilege
> class to your user and and then have an "oops!" moment, but then it's not an
> _accident_. It's not a death wish either. It's an intention to kill.
>


-- 
Kris Buelens,
IBM Belgium, VM customer support

Reply via email to