Good angle, but the applications would need to be modified to process
the signal (or whatever it gets morphed in to once CMS or GCS get it).
Maybe command can be added to PROFILE EXEC and/or PROFILE GCS that tells
the virtual machine how to handle the signal (stack a command, logoff,
whatever).
Huegel, Thomas wrote:
That is correct, so put it in GCS too, my point was that putting it in
the 'nucleus' would be better than adding it to every application that
is served by said nucleus.
-----Original Message-----
*From:* The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of *Schuh, Richard
*Sent:* Wednesday, August 09, 2006 1:35 PM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: Signal support
RSCS is in the GCS group, not a CMS application.
Regards,
Richard Schuh
-----Original Message-----
*From:* The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of *Huegel, Thomas
*Sent:* Wednesday, August 09, 2006 11:28 AM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: Signal support
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:[EMAIL PROTECTED]
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
------------------------------------------------------------------------
<<* ella for Spam Control *>> has removed *6193* VSE-List messages and
set aside *4148* VM-List for me
You can use it too - and it's FREE! www.ellaforspam.com
<http://www.ellaforspam.com>
--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service: 360-715-2467
rich.smrcina at vmassist.com
Catch the WAVV! http://www.wavv.org
WAVV 2007 - Green Bay, WI - May 18-22, 2007
