> [snip] > Reliability is only one part of the equation. > [snip] > Good points, however I was responding to the idea that > running a simple app on a single box somehow proves that > the server boxes are now on par with mainframe reliablility, > and that's not a logical comparison.
Sure its a valid comparison. The only thing a user cares about is the result. They might have a bit of tourist curiosity, but as long as they get their job done on time, they generally don't care HOW it gets done. So if it takes two or more redundant (but very cheap) boxes to do the job of a single (much more expensive) mainframe the user probably doesn't care. Moreover, the business may actually prefer the lower price, even if it comes at the cost of a bit more operational complexity. > [snip] > > I've yet to see unix or windows accomplish the same thing. > > See Ron Hawkins' last post on this. If you're running modern > disk hardware you're running a fault-tolerant unix application > [snip] > Again, you can't compare a single purpose application (such as > a disk array), with a mainframe. Sure, some subsystems are supported > by cheap chips or os/s, but they are doing a very simple job: > exactly what these things should be used for. Actually, I -can- compare these things quite usefully. You appear to have an inherent preference for running all of these things on the same box at the same time. That's ok, but you should recognize it as a preference only. If the same thing can be accomplished more cost effectively, or more reliably, by some other approach, then who's to say the other approach is wrong? > [snip] > Rubbish. Reliability is a "nice to have" feature that costs a ton of > engineering dollars. > [snip] > I'm not sure where you've been working, but if I told the company > president here that reliabliltiy was "nice to have" I'd be out on the > street before I could blink. IBM didn't invent RAS systems to keep > themselves amused, they did so because their customers demanded it, > and were willing to pay for it. Both IBM and their customers had > to invest heavily in this or they'd be out of business. You're missing the point entirely. High AVAILABILITY is a "gotta have it" business requirement (or not - see below) but there are many ways of accomplishing that. Availability is the probability that a system can do work when you want it to and that's MTBF/(MTBF+MTTR) It costs a lot to make MTBF LARGE for every last component. Depending on design, you might be more successful by simply making MTTR small. Then if you factor in the availability of redundant components, you find that you can get very high overall AVAILABILITY from very low RELIABILITY components. I'm not making this up, its just the way it is. You also should consider the origins of the drive for reliability. Back in the day, customers typically had just one system. And if it was down, so were they. Nobody in their right mind would pay the cost of duplicating the resources of that single system even if the software supported it, which it generally did not. So... the only choice was to make every element of the system as reliable as could be - and that's one of the reasons the platform has stayed as expensive (raw $$$, not cost/function) as it has. The engineering that goes into these systems is staggering. But while the engineering drive for ultimate reliability continues, the (mainframe) systems today are increasingly made up of cheap commodity parts. The memory subsystem has pipelined access and chip kill and multibit ECC, but its made of cheap and cheerful memory chips not unlike those in your own PC. Now in the brave new world where chips cost pennies, the most cost effective solution is usually to provide multiple levels of redundancy. That's entirely different in concept. Instead of having one big thumper sitting in the corner being a single point of failure, you have many equivalent servers and no single point of failure. That's the mantra for sysplex and for the distributed systems too. So in fact, as I said earlier. Reliability -is- nice to have. But you can have high business availability without it. Now to return to that issue, take a long hard look at the real numbers and the results are not pretty. z/OS availability, as experienced by most of our brethren, is nothing to write home about. See all of the past threads about IPL frequency for verification. Its not that the system isn't capable of continuous operation (IT IS!!!) but evidently a wide majority of customers don't actually trust it to be as reliable as it is. Getting the benefits of the latest technology takes a fundamental shift in mindset as well as a shift in configuration. If you keep running your mainframe systems and applications in towers the same as they were "back in the day" then frankly, they are considerably less reliable/available as off the shelf solutions with other platforms. Sorry if that is bursting some bubbles, but that's just the way it is. > The day that it becomes commonplace for, say, three unix servers > to be able to support the entire IT production environment > for a large company, and do so reliably, I'll concede the point. Already true today. If you are arguing capacity, then even today the P series stomps the Z series and it supports many of the same kind of virtualization and partitioning. It may not do it with the same raw efficiency, but if the price is right, who cares? Note also: I am not specifically advocating that people go out and replace mainframes with those other systems. I am merely pointing out that the other systems are entirely competitive and if we want to keep up, we have to embrace change. Widespread perceptions of mainframe superiority are long out of date. CC ---------------------------------------------------------------------- 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
