On Friday, 02/11/2011 at 04:24 EST, Mike Walter <mike.wal...@aonhewitt.com> wrote: > See? Alan's reply is precisely why I thought "it seemed prudent to run it > past others for wider consideration." > > I suspect that there will be many new LoZ (a new "Linux on System Z" > acronym seen recently, and MUCH less to type) customers who will not > purchase IBM OM, or CA VM:Operator, but whom would benefit from this > capability right out of the box (i.e. sample directory entries). > Automation products can't be justified for something this small - for many > other reasons, absolutely YES -- but not this.
Think about that some more, Mike. Few clients have a single point of interest in automation. They want: - Monitoring and Alerting - Recovery - Provisioning - Remote operations - Housekeeping - Archiving / Backups - Compliance checking They may only implement them one at a time, but they want it all. It is the new LoZ customers who are most likely to buy complete solutions. After all, they are not steeped in the arcana and lore of z/VM, and they aren't particularly interested in delaying deployment while they learn it. Too, if they build it themselves, they have to support it themselves. The only "throat to choke" is their own. > > potentially decrease the revenue from OM > Really? _Really_!!?? If the purchase of OM or any automation product was > based on this feature, the case for OM must have been pretty weak in the > first place. It's not, of course. It's just ONE of the features of such products. But at some point you cut too deeply and you lose the sale. It's all risk management. Sometimes you win, sometimes you lose. You just want to win as often as possible and avoid cutting your own throat. > > CP's role is to provide hooks and assists to authorized virtual > machines, but he's not going to do it himself. > Hmmm... adding a time-based CLOSE sounds like an "assist" to me. That's not an assist to another virtual machine; that's CP doing the heavy lifting. As Tom pointed out, an appropriately authorized virtual machine can sweep the system and close the consoles. > But I'm not gonna invest my limited time fighting for this small > improvement to benefit new LoZ customers. I thought it was pretty small, > and I thought that such enhancements were part of IBM's customer > satisfaction job. (Feel the knife twist right there at the end?) ;-) I will leave the chum in the water undisturbed, saying only that I believe a good implementation of what you ask for is not as simple as it seems. And your desire for this function has good side effects! It lets us bring things into the light that otherwise remain hidden. I think those new LoZ customers want a comprehensive system log management solution. Let's say you DO have some console logs you need. As soon as you close those consoles, you need to do something with them. What? Put them on disk? Compressed? In an organized way? What happens when that disk fills up? Erase the oldest stuff? Whine and complain, asking for assistance from the omnipresent wetware? Dump to tape? How to get the tape mounted? Is there a nice way to look at the logs? Do they need to be pulled from the archive? How are they made available to the Linux admins? What if I want the console activity forwarded to syslogd somewhere instead of recorded locally? What is deserving of an alert? Is that a Tivoli alert? An SNMP trap? What? And did I mention that I want to manage data in the accounting stream. And symptom records. And EREP records. And RACF SMF data. And.... and.... Getting all the console logs to close at 11:59 PM is easy. Keeping the system responsive during that time, maybe not quite so easy. Managing the system log streams, of which console logs are just one part, and managing them well, is even more difficult, yet has a much higher value proposition. And THAT isn't going to be done inside CP. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
