I don't really agree with this "we've always tolerated pulling the rug ou t from under us so we shouldn't change it now". The fact is, I've spent lot s of time in my professional life fixing things that happened because of a
shutdown. And we've written code to deal with this, or fix it afterwards. It seems to me that the SHUTDOWN signal is an opportunity to relace all these ad-hoc solutions with a more general one. You say it wasn't designe d for that, but in that case we need something else that IS. Do I have to write that requirement? What's wrong with extending the SHUTDOWN concept to further levels, now that we have a command to do it? I like the idea o f adding CMS (and GCS) nucleus services to implement SHUTTRAP. I'm not sure whether the TCP/IP stack maintains state or not, but some of the guests it supports do -- web servers, for example. I could write a requirement to the vendor of the web servers to support shutdown, of course. Again, this is more ad-hoc, one at a time activity. But I think there will always have to be a per-application part of the code. Just providing SHUTDOWN support for the TCP/IP stack isn't enough, either , it would have to pass this along to its guests. (What does TCP/IP do when it gets a CP EXT?) Maybe it's just simpler to have each guest register fo r the shutdown signal itself? On Wed, 9 Aug 2006 13:23:21 -0400, Alan Altmark <[EMAIL PROTECTED]> wrote: >The LPAR deactivation signal was designed to allow *operating systems* t o >flush cache, checkpoint and bring themselves down as quickly as possible . >We wanted to avoid Linux fsck's on their EXT2 filesystems. (Now folks ha ve >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. > >Alan Altmark >z/VM Development >IBM Endicott >======================== ========================= ========================
