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" <[email protected]> 08/09/2006 01:14 PM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] 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.
