All of these statements are true enough. But the one that makes the day is the one that says 'but I was able to show management ... and save'. Performance issues, of course, serve a good supporting role.
A boss somewhere was recently heard saying of a proposed penalty box 2nd mainframe: 'And what is it going to cost me in people to maintain this new box?' 'Nothing except the twice-a-year time change IPL.' 'No, that can't be, I know how much extra it costs in people, backups, etc. when the other folks add just one new server.' It was very valuable for the presenter to remind him that this was not Toyland with its 'we all use the single SAN but have to have separate allocations, cannot share data'. We mainframers have a SAN (but we did not know we could call it that until the 1990s, give-or-take), and we have SHARED SAN! NO additional people or backups, or costs. If we back up one SAN with one LPAR, we have backed up all of it. Then there is the cost of sw licensing, sight of which is often lost in favor of haggling over the hw pricing. Lots of these sw products are licensed by CPs, making it even more expensive "out there". How many "instances" can you run on a single VM-Linux mf, and how many boxes (times that many licenses) does it take "them"? What if you could run a room's worth of Oracle on a single mainframe? Could save millions. I had a chat with my old boss from a decade ago. Software, not hardware, is the real issue. His current place was spooked when one of their senior mf guys retired. 'What ever shall we do?' So they went to China for PC coders. Obviously PC expertise is cheaply available. Aside from the fact that they can never have a phone call due to the time zone differences and no one there (yet) carries cell phones or takes home their PC (current lack of infrastructure), the folks there are just out of school (so they are basically apprentices) and will move on for a pay hike before the code hits a major enhancement (so that no one then working on it knows anything of the original design philosophy from experience; so now they have new apprentices). But the biggest thing that stuck him was that Visual Basic 1.0 no longer runs on any supported m$ OS. VB 1.0 is not all that old. What if the mf had run that way? I suppose that by the time of Y2K, no old programs with date issues would have existed and be in need of fixing. But only on a mainframe can you actually run 20-30-35- maybe even 40-year-old programs. In the existing 64-bit boxes we all routinely run 31-bit code side-by-side with 24-bit code. The Toyland folks have to keep on reinventing their stuff over and over again because it does not migrate forward. Try running the 16-bit windows stuff on a 32-bit box and hope it runs. Would it even try to run on a 64-bit processor? And the number of sustainable users is pitiably low. Why, even my PC upgrade just cost me all of my customizations, another chink in their armor, and both were Intel 32-bit processors. Would anyone allow a mainframe upgrade that "changed everything"? There is one particular caveat, though: there is a threshold of sorts below which IBM MVS software "really costs" and above which the quantity discounts (from IBM, at least) start to make a difference. This is somewhere around the 400-600 MIP range, by which area the general cost of the software comes down, per MSU. Increase your computing power (box size) and usage (VWLC), increase your sw cost by comparison only a little, and cost per MIP drops. Divide that by the number of users and the cost of computing becomes quite cheap. How many of those users have a PC so as to use the mainframe, and how many more times than the mainframe resources did that individual PC and its software cost, times sometimes thousands of PCs? The trick is to not drop below this threshold. It is "easy" to take off a single application, even two or three, and run them on a cheaper platform. But there are fundamental systems that essentially only run on the mainframe because they cannot be cost-effectively developed again elsewhere. By the time folks get to the point of realizing it, the mainframe looks incredibly expensive (and has perhaps dropped below that critical MIPS point) AND they are dragging around all those other boxes (and people), which also is expensive. If the person in the right place can then present a cost comparison, the mainframe can be the preferred platform for new development, even based on cost alone. Don't forget either that the newer "open" features, such as IFL engines and linux offer MIPS for an even lower price than MVS, and this too can be merged into the real mainframe per-MIP cost. Granted, the price of a mf is high, and in a given circumstance, it looks, smells and feels like gouging. But the business that already runs with a mf will usually find that converting to mainframe wanna-bees ultimately costs more and does less. What we promoters need is a sufficiently ready bag of facts similar to those we already have on the technical side. And to not hesitate to be an advocate if possible to penetrate the inner circle of decision makers. RR -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of various To: [email protected] Subject: Re: Just another example of mainframe costs. You are not doing an apples-to-apples comparison. ... However, I will agree that Enterprise zSeries DASD is still more expensive that the corresponding Enterprise "Open" Systems (Windows and UNIX) DASD. ... I, too, disconnected an old RVA - about 8 months ago. I was able to show management that they could buy ... [cost] savings - and get much better performance to boot. ... There is some uniqueness in the mf solution, but the raw hardware cost doesn't go close to explaining the price customers pay. Can you say gouging boys and girls? ... And when they stop laughing at that, tell them how much throughput and multi-tasking a mainframe can do compared to their wimpy Windows boxes. How many servers it takes to match even ONE z/OS system, and how much floor space, electricity, and software maintenance that takes by comparison. How you live in a world where there is NO "blue screen of death." How your systems can handle thousands of transactions per second, when theirs clog up with only dozens. How your DASD can beat up their DASD. How you can't infect a mainframe with a virus. Confidentiality Notice: This email is intended for the sole use of the intended recipient(s) and may contain confidential, proprietary or privileged information. If you are not the intended recipient, you are notified that any use, review, dissemination, copying or action taken based on this message or its attachments, if any, is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy or delete all copies of the original message and any attachments. Thank you. ---------------------------------------------------------------------- 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
