Ron Hawkins writes: >Oh come on Richard. There are Banks all around the world that >have never possessed a MF, and get along quite nicely with five >nines availability on Unix clustered solutions.
Last I checked (which was very recently), exactly none of the top 50+ banks are without mainframes, nearly all IBM mainframes. (There might be an exception or two in Japan where there are Fujitsu, Hitachi, and NEC mainframes running operating systems like MSP, XSP, VOS3, and ACOS.) It has also been the trend that the mainframe banks have bought out the smaller non-mainframe banks. I don't think that's coincidence -- the modern mainframe is a fantastic vehicle to support rapid business acquisition. But I have a second point to make below.... >We should not fool ourselves into thinking that Parallel >Sysplex and GDPS are the only HA clustered solutions in the >market place, whether local, metro or geographically dispersed. >I had UNIX customers doing multi-site RAID-1 over RAID-5 before >Hiperswap was a twinkle in IBM's eye! Damn site easier to >operate too. Nobody said Parallel Sysplex and GDPS are the only high availability clustered solutions in the market. But this whole thread got started because of a complaint about *planned* outages. One must not be sloppy here: "five nines" should have a business definition, and that definition does not typically distinguish between planned and unplanned outages. (Or at least people should say something like "five nines, excluding planned outages of up to [X] duration [Y] times per year.") If you're down, you're down. Note also that "down" in business terms means both completely down and "not responding fast enough, predictably enough." For a credit card company it's that wallet-share question: whether the customer reaches for their Visa or their American Express card. (And there's "stickiness" to that decision: credit card users tend to reach back for the same card.) That's another level of rigor that the "five nines" shorthand often does not capture. Last I checked (again very recently), it still wasn't possible to upgrade your major database version and keep the business running while you do it, even if you have the fanciest and most expensive distributed UNIX cluster in the world. That run-while-upgrading process is routine on z/OS with Parallel Sysplex and DB2 data sharing. And I'm sure z/TPF enthusiasts could point to some really interesting things they can do, to pick another example. There are many others pervasive throughout the hardware, operating system, and middleware. Does it matter? Not to everyone, but of course it matters to many businesses and for many services. The need to avoid planned outages seems to be increasing over time actually, so there's a lot of demand here. J R writes: >The "front ends" need to be bulletproof because "back ends" are >not always available. This has nothing to do with whether the >front and back ends are Tandem or IBM. The front end and back >ends may even be on the same box. It's not necessarily that the >box becomes unavailable but, more likely, that the back end >application does -- sometimes intentionally, sometimes not. >The important thing is that the front end can continue to service >transactions, stand in for the back end and SAF the results. Very good point. Basically an organization introduces front-end receive-and-store queuing systems if they have unreliable backends. And sometimes that's "good enough," but it's always a second-best service level. For example, the ATMs might offer lower limit cash withdrawals (and hold those withdrawal records for later reconciliation), but they won't provide an up-to-date account balance if the backend is offline. >Back in the day, Tandem was the dominant fault-tolerant platform. >However, for almost two decades, sysplex technology has given >mainframes fault tolerance that Tandem can only dream of. >So, it's not that Tandem's front end value is lessening but that >they are no longer the only game in town. I do think Tandem (HP NonStop) front-end value is lessening because of decisions HP and especially software vendors have made recently. But I think you're exactly right about the fact that, if you have a highly available IBM mainframe backend, why do you still need a special queuing front-end? Quite simply you don't, and that's been the trend, to edit and to simplify for several reasons. [De-tiering is good in HA engineering, actually, so if you can eliminate a tier or two "ceteris paribus" you'll improve your statistical predicted availability. Said another way, a pair of "five nines" clusters lashed in sequence together does not quite result in "five nines" end-to-end. (Get out your calculator and give it a try.)] It shouldn't be surprising. In any business, if a middleman no longer offers a unique benefit, why deal with the middleman? Why not just go direct? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- 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
