On Wednesday, 08/09/2006 at 02:14 AST, David Boyes <[EMAIL PROTECTED]> wrote: > 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?
In a perfect world with infinite resources, I would propose that we add real shutdown support to all the subsystems. Just because it *might* prevent a problem. But we don't have infinite resources, so we pick and choose. This doesn't make the cut. Sorry. > ??? 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...". If a CP SHUTDOWN hangs while a bunch of servers are doing unneeded activity, it's a waste of our time and yours. > 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. LOL! You made my day. Sure, they're both single-user operating systems, but neither exhibits properties that require shutdown. This *must* be true because there is no CMS or GCS shutdown command! :-) The applications, OTOH, *may* have those properties. Alan Altmark z/VM Development IBM Endicott