> 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
