On Wednesday, 08/09/2006 at 11:09 AST, David Boyes <[EMAIL PROTECTED]> wrote: > I'd be more inclined to accept that argument here if they hadn't added > the shutdown support to SFS.
We didn't do it for esthetic reasons, but on the assertion that SFS has state information that it needs to save to avoid corrupted disks. We subsequently decided that SFS is, in fact, NOT in any danger when taken down hard, but that doesn't affect the original rationale. > To some extent, that argues (at least to > me) that use of SIGNAL SHUTDOWN is the desired/preferred method for > signaling termination of major subsystems. VM TCPIP is (IMHO) one of the > few IBM-supported non-Linux-based hypervisor support subsystem left on > VM ( in my mind, the majors are TCP/IP, SFS, RACF/clones and RSCS). > There is a way to implement a clean shutdown for TCPIP, but it's fairly > arcane (see below). I know if I were a newbie, #CP EXT wouldn't be > something I'd ever figure out on my own. But why should you have to shutdown your security and communications subsystems separately? Or at all? "No worries, mate. Just shutdown your system. Everything will be ok. Sleep tight." (Note to self: see if that gecko is looking to make a change. He would be good at this.) > There's also an operational consistency perception issue here to combat. > In VM's new (old) role as a hypervisor-only environment, the amount of > CMS knowledge assumed to be available to an admin is minimal. All the > other elements of the base system shut down when presented with a SIGNAL > SHUTDOWN or have a clearly defined shutdown capability -- Linux guests, > RSCS, RACF, SFS, etc. Why is TCP/IP different? And, moreover, why is it > a particularly arcane version of different? It seems a rather glaring > inconsistency. We get dinged majorly for that in the outside world, > where even the Linux cowboys have finally gotten the point that > Consistent Behavior Is Good if you want to survive in the big leagues. Consistency? WDNNSC. NJE signon/signoff has been tolerating the unexpected loss and reappearance of the remote host for decades. RACF, RSCS, SFS, and TCP/IP don't *need* shutdown. 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.) The LPAR deactivation signal was designed to allow *operating systems* to flush cache, checkpoint and bring themselves down as quickly as possible. We wanted to avoid Linux fsck's on their EXT2 filesystems. (Now folks have moved to ext3. Harrumph.) 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. > Plenty of other windmills to tilt at. 8-) There is never a lack of windmills, Sr. Quixote. :-) Alan Altmark z/VM Development IBM Endicott
