Maybe the requirement should to put the Signal Support directly into the CMS Nucleus, that way applications that run under CMS wouldn't need to be changed.. or something like that.
-----Original Message-----
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On
Behalf Of Mike Walter
Sent: Wednesday, August 09, 2006 1:22 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Signal support
I'm typing the following in my best Southern accent... All y'all type
faster then I ken read! :-)
It's been a fascinating discussion and a credit to the members of the list
that such discussions can be had without a single flame or negative
personal comment.
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
"David Boyes" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
08/09/2006 01:14 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Signal support
> Or at all? "No worries, mate. Just shutdown your
> system. Everything will be ok. Sleep tight."
Ah, but how does the system guarantee this to be the case without a
consistently applied methodology of how things start and terminate? In
the current setup, you can *guess* that it happened OK, but can you
provide a contractual guarantee that the system will be OK? I don't
think so.
Consider the difference between "kill -HUP" and "kill -TERM".
> (Note to self: see if
> that gecko is looking to make a change. He would be good at this.)
Check out the new Novell partner ad cards. The ninja gecko card is
pretty cool. 8-)
> Consistency? WDNNSC. NJE signon/signoff has been tolerating the
> unexpected loss and reappearance of the remote host for decades.
Link setup and connection, yes. The RSCS supervisor itself always had a
clean initiation and termination process (I no longer have a RSCS v1
instance, but RSCS v2 certainly did anyway).
Note that RSCS is also responsible for cleanly shutting down whatever
tasks it started to avoid making GCS sick...8-) It may not matter in the
context of a entire system shutdown, but it's still illustrative of good
behavior.
> RACF,
> RSCS, SFS, and TCP/IP don't *need* shutdown.
I guess I've repaired one too many corrupted RACF databases to buy that
RACF doesn't need a clean shutdown to reliably operate, especially in
shared database mode. And had one too many hung I/Os on TCPIP userids.
And one too many corrupted SFS catalogs.
I'll give you the benefit of the doubt that this may have all been fixed
in new releases, but every one of those things is a guaranteed level 3
support call that'll haul you (or someone you have to face every day)
out of bed at 2 AM. Wouldn't it be simpler to just prevent them in a way
that would avoid the problem entirely?
> Dave was right, IMO: It
> would be nice, but there's no technical requirement for it. I'd
rather
> not introduce complexity and delay without benefit. (Believe me, I
like
> the symmetry of a system shutting down the opposite way it came up.
> Therapy is helping.)
??? How does this *increase* complexity, and for whom? If CP SEND TCPIP
#CP EXT does what we want it to do, how does causing SIGNAL TCPIP
SHUTDOWN to do the same thing make that any worse? It certainly
*decreases* complexity for the user -- no "use SIGNAL xxxx SHUTDOWN to
stop everything, except for these things which use XXXXX, and these
which use YYYYY, and these ones over here which don't have any shutdown
command...".
> The LPAR deactivation signal was designed to allow *operating systems*
to
> flush cache, checkpoint and bring themselves down as quickly as
possible.
Isn't that what we're doing here? RSCS is a task running in a GCS-based
OS. CMS MT is arguably a single user OS. Etc.
> It really wasn't meant to be a leisurely
> stroll so that all the apps that haven't needed it in the prior
century
> can all of a sudden wave Goodbye.
So make the SIGNAL handler do the equivalent of Z NET,QUICK, and put in
a regular STOP or SHUTDOWN command for the graceful shutdown. I could
agree on that.
Oh, well. I've written the requirement, so I feel better. You can rank
the giants as you see them, Pancho. 8-)
-- db
The information contained in this e-mail and any accompanying documents
may contain information that is confidential or otherwise protected
from disclosure. If you are not the intended recipient of this message,
or if this message has been addressed to you in error, please
immediately alert the sender by reply e-mail and then delete this message,
including any attachments. Any dissemination, distribution or other use of
the contents of this message by anyone other than the intended recipient
is strictly prohibited.
__________________________________________________________________
<< ella for Spam Control >> has removed VSE-List messages and set aside VM-List for me
You can use it too - and it's FREE! http://www.ellaforspam.com
