I agree with you.. But if you can't wait for an "official" solution and need to resolve a problem today, then you end up with either home grown code, you find a vendor product that does what you want, or you implement operator procedures. When a better solution comes along, you decide if you can or want to migrate to it.
They don't do anything like this on internal IBM systems, they just shut them down. When Linux came along, we had to change the operator procedures to first shut down the Linux systems before the VM shutdown. Now, on some systems without many Linux servers, the CP SHUTDOWN process takes care of Linux, but on systems with many servers, the operators have to follow the Linux procedure so that the Linux servers have time to stop before VM is stopped. I'll just say that it works most of the time... On 11/8/07, Mark Post <[EMAIL PROTECTED]> wrote: > >>> On Thu, Nov 8, 2007 at 10:50 AM, in message > <[EMAIL PROTECTED]>, Bruce Hayden > <[EMAIL PROTECTED]> wrote: > > The solution to stopping all of the various SVMs before VM shutdown is > > to use yet another SVM. > > Bruce, > > I don't face the same raft of issues that most other people on this list do, > since I don't support z/VM on a daily basis. But, I have to say that my > first reaction to this was "lipstick on a pig." > > When you've got people (and lots of them) creating kludges like this, it's a > sign that something needs to be fixed. Taking that view in the past, and > doing something about it in the base code, is one reason why VM, and now z/VM > is as good as it is. (And yeah, trust me, I know all about finite developer > resources and setting priorities. Argh.) > > > Mark Post > -- Bruce Hayden Linux on System z Advanced Technical Support Endicott, NY
