That is indeed an excellent record of reliability. If you change your criteria slightly, change "ABEND" to "defect", you eliminate the need for the exemption. At USAir (before the name was changed to US Airways), we had a VM/ESA system run for 10 months without any outage, scheduled or not. An outage was scheduled for some hardware work. When it was brought back up, it ran for another uninterrupted 6 months, when there was another scheduled hardware outage. This system ran a very busy CMS load with up to 3100 concurrent users, 20% doing real work instead of just OfficeVision. It was rare for the system to run at less than 80%; most often, it was above 95%. The system, while considered a test system because it was VM, ran a few mission-critical processes, some mandated by the FAA. Then there was OV, which many of the executives considered mission-critical when it was down. Prior to the start of the 10 month period, there was a cpu failure that had the system down - a TMC infant death on a new cpu - for several hours. . We had a company VP call from London every 15-20 minutes during the outage, asking when OV would be back up. Indeed, many (if not most) of the 8100 registered OV users were dependent on OV, and by extension, the system being up.
Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Friday, December 21, 2007 8:28 AM To: [email protected] Subject: 10 years without an unscheduled VM system outage! Just sharing what I believe should be a reason for the IBM VM Development Lab in Endicott to celebrate. At 14:10:02 on 05 December 2007 our z/VM system running a CMS workload reached 10 years without a single unscheduled system outage due to a CP ABEND. Eight of those years were on VM/ESA (VM/ESA 121, 230, and 240) until December 31, 2005 when we belatedly upgraded to z/VM 5.1. With VM/ESA so utterly stable and reliable we had no reason to "hurry" through multiple z/VM upgrades. :-) We did experience a self-inflicted wound which I deeply regret since it creates an "exemption" on an otherwise untarnished record. On December 30, 2005 while preparing for the upcoming weekend migration from ESA 240 to z/VM 510, I accidentally caused the production ESA 240 spool volume to be mounted read-write on the z/VM 510 test system. Multiple production NSSes were written over (including CMS). We quickly shut down the z/VM 510 test system, restored the NSSes, and scheduled an emergency IPL (note: "**scheduled**"). During that scheduled emergency outage window, we took that single ABEND, a FRE016. But... the ABEND occurred during the **scheduled** emergency outage window (the "exemption" mentioned above), and most importantly, it was not due to an IBM error. Ten years faithful service, uninterrupted by a single unscheduled CP ABEND is worthy of note in my book! (Having the luxury to do so, we do schedule a weekly Sunday-evening IPL on that system). Looking back on the year, and through history, does anyone else have great experiences to share (or "SHARE")? For that matter, does anyone know of z/OS sysplexes which have managed to avoid an unscheduled complete sysplex outage for anywhere near 10 years? Merry Christmas, and a very prosperous, and **stable** Happy New Year to all of you, too! Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. ________________________________ The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email.
