I'd be more inclined to accept that argument here if they hadn't added the shutdown support to SFS. 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.
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. In any case, it cost about 15 minutes to write the new requirement. If it's wasted effort, I'll live. Plenty of other windmills to tilt at. 8-) -- db
