[EMAIL PROTECTED] (Rick Fochtman) writes:
No argument here. But the hardware evolution in terms of RAS has made the MF KING in this area. MF had a poor record to start, but it's improved immeasurably over the last 40+ years, with the evolution of microcode and things like automatic recovery and fail-over to unaffected components, sparing, etc. The "squatty boxen" will eventually arrive at the same point in their evolution, but they haven't got there yet. In my own experience, the hard drives in use today have a long way to go. They've come a long way, compared to their abysmal past, but there's still a lot of room for improvement. And I have a MAJOR problem with a software vendor who tells me to "Reboot and see if that fixes it" or "Re-install and see if that fixes it". Diagnostic tools and procedures are a world apart between z/OS and the various Intel-based systems.
cross-over from similar/related discussion in a.f.c http://www.garlic.com/~lynn/2007.html#36 How many 36-bit Unix ports in the old days? http://www.garlic.com/~lynn/2007.html#37 How many 36-bit Unix ports in the old days? http://www.garlic.com/~lynn/2007.html#39 How many 36-bit Unix ports in the old days? besides many of the 370 UNIX ports running under VM in virtual machines ... in large part because of the significant costs to add RAS/EREP support to Unix (significantly larger than cost of doing a unix port to 370) ... there was also periodic concern regarding just maintaining RAS/EREP support in the standard 370 operating systems ... one example http://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style" that includes this old email reference http://www.garlic.com/~lynn/2007.html#email801015 at one point there was a study of the "four" standard 370 operating systems and the corporation was going to cut back to fewer ... just based on the cost of maintaining the RAS/EREP software in all the different operating systems. I mentioned a 3090 RAS/EREP story here http://www.garlic.com/~lynn/2007.html#38 How many 36-bit Unix ports in the old days? and at this NASA sponsored working on dependable computing http://www.hdcc.cs.cmu.edu/may01/index.html and in this thread: http://www.garlic.com/~lynn/2006y.html#43 Remote Tape drives another is story about 3090 service processor. Field Service had a defined process for being able to diagnose and service customer machines in the field ... that started with being able to "scope" components to diagnose failed elements. the 3081 had lots of components which were no longer directly scopeable ... which gave rise to the "service processor". The service processor had extensive probes into the 3081 components for diagnosing errors and failed components. While the 3081 wasn't directly scopeable, there was a bootstrape "scope" diagnostic process that started with scoping the service processor ... and then using the service processor to diagnose the 3081. as refereneced in this recent posts, the 3090 had a vm370-based service processor http://www.garlic.com/~lynn/2007.html#18 IBM sues maker of Intel-based Mainframe clones http://www.garlic.com/~lynn/2007.html#24 How to write a full-screen Rexx debugger? which started out as a 4331 ... which was scopeable. Before the 3090 shipped, the service processor strategy was upgraded to a pair of (vm370-based) 4361s. Instead of having a bootstrapable scoping field service process ... 3090 went to a pair of redundant 4361s. part of mainframe availability strategy was based on loosedly-coupled configurations. long ago and far away ... my wife had been con'ed into going to POK to be responsible for loosely-coupled architecture. While she was there she developed "peer-coupled shared data" architecture http://www.garlic.com/~lynn/subtopic.html#shareddata however, except for IMS hot-standby, there wasn't a lot of uptake until sysplex (somewhat as a result, she didn't stay long in the job). however, we were also able to repeat some of the effort with ha/cmp product http://www.garlic.com/~lynn/subtopic.html#hacmp including work on "disaster survivability" and "geographic survivability" (two terms we coined when we were doing ha/cmp) http://www.garlic.com/~lynn/subtopic.html#available we also worked on scaleup for loosely-coupled configuration .. including some of the early work on high-density computer, floor-space efficient footprints ... recent posts referencing MEDUSA (cluster-in-a-rack): http://www.garlic.com/~lynn/2006w.html#13 IBM sues maker of Intel-based Mainframe clones http://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones http://www.garlic.com/~lynn/2006w.html#20 cluster-in-a-rack http://www.garlic.com/~lynn/2006w.html#40 Why so little parallelism? http://www.garlic.com/~lynn/2006w.html#41 Why so little parallelism? http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism? http://www.garlic.com/~lynn/2006x.html#11 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2006x.html#33 NSFNET (long post warning) http://www.garlic.com/~lynn/2007.html#31 V2X2 vs. Shark (SnapShot v. FlashCopy) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
