NASA Unplugs Its Last Mainframe
coondoggie writes "It's somewhat hard to imagine that NASA doesn't need the computing power of an IBM mainframe any more, but NASA's CIO posted on her blog today that at the end of the month, the Big Iron will be no more at the space agency. NASA CIO Linda Cureton wrote: 'This month marks the end of an era in NASA computing. Marshall Space Flight Center powered down NASA's last mainframe, the IBM Z9 Mainframe.'"
It's also that $730,000 / year in ongoing maintenance for a Z9 is not really all that practical, especially considering that newer deployments based on GPGPUs have far lower operating costs, and provide higher performance than a 5 year old big iron.
Thirty four characters live here.
The cited page is a copy/paste of Linda Cureton's blog post. Lame and uncool to copy someone's article whole without a link, don't you think, even if they are paid with taxpayer $$? Here's the original article : http://blogs.nasa.gov/cm/blog/NASA-CIO-Blog/posts/post_1329017818806.html
Only in some aspects, and GPGPU clusters have a hard time matching the transaction rates and number of concurrent I/O's of a Z9. I wouldn't want to use a GPGPU cluster for financial/payrolls, just as an example.
I've seen mainframes used at Insurance companies and Banks, but the rest of the world seems to favour the the cloud ways of Elastic Cloud and what not.
I've heard mainframes have high IO thoroughput, but what about their equivalent Cloud solutions and scalability especially?
Thanks.
Latency. Confidentiality. Reliability. But most of all: sunk costs and proprietary software embodying key business knowledge. Replacing mainframes requires a large enterprise to start not only major software procurement or development (or both, as in ERP), but also business process reengineering... none of which is particularly fun, cheap or in themselves something that helps capture greater market share.
I don't follow why a data center would be kept open for one puny mainframe (or closed because it's gone.) I'm pretty sure there's other stuff there. A modern mainframe is about the size of three deep rack cabinets. Even with associated storage and support peripherals, I could fit a complete mainframe installation in my living room. I doubt the only thing in the data center was the mainframe.
Also, NASA stands for National Aeronautics and Space Administration, NOT National Manned Space Flight Agency. They DO accomplish lots of other stuff other than manned space flight.
Mainframes aren't about computational performance, they're about reliability and to a lesser degree (these days) I//O performance. If you want computational performance, you go with a cluster or perhaps a cluster of GPUs (depending on the nature of the problem).
Mainframes are about reliability. When your app absolutely positively must run 24/7, a mainframe is a reasonable consideration. We can get about 90% of that with multiple failover servers and other similar strategies. Where that's good enough, we go that way because of the vastly lower prices. However, if the 90% solution just isn't good enough, mainframe it is.
Yes, there are mainframe emulators. And if you compare processing power they come out quite well, but as others have pointed out mainframes aren't super computers and don't claim to be. If you just want something that can run your mainframe code that's great. What an emulator won't give you is any of the things that people actually want a mainframe for (see other posts for details).
It's a bit disappointing to see so many people on slashdot wondering what the purpose of a mainframe is. It shows so many "geeks" have a very limited knowledge of IT in the real world.
Yes: http://www.hercules-390.org/
But IBM won't allow to run z/OS (the operating system usually used) on it.
Few decimal places, but lots of rules and interactions with banking systems. Though the big element is reliability, mainframes are pretty unmatched in their ability to keep running. There are mainframes that literally go decades between reboots or other failures.
There was once a programmer who worked upon microprocessors. "Look at how well off I am here," he said to a mainframe programmer who came to visit, "I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self- consistent and easy-to-use. Why do you not quit your present job and join me here?"
The mainframe programmer then began to describe his system to his friend, saying "The mainframe sits like an ancient sage meditating in the midst of the data center. Its disk drives lie end-to-end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle. The programs, each unique, move through the system like a swift-flowing river. That is why I am happy where I am."
The microcomputer programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.
Maybe all payroll stuff requires suckage, but PeopleSoft and SAP are two of the worst products in existence. The city here adopted SAP to "save costs" and now has a department of 10+ "SAP Programmers" just to keep basic functionality running. And PeopleSoft where I used it last directly wasn't hard. It ran on a single low-spec server. You just couldn't use it for 5 days of the month (invoice generation, payroll, and 3 other such dedicated days). That was "acceptable" because the cost of a server that could generate those pieces in a few seconds would have cost more than the inconvenience of the application being unavailable.
Learn to love Alaska
It's not the decimal places as such. It's the fact that, if we step through the entire stack: Everything is rounded off properly(that means, no floating points math rounding errors), input from many concurrent sources without choking, reliability not just in terms of machine/OS/application uptime, but also in terms of data integrity(a modern mainframe does ECC, checksumming etc at every stage of data handling, even in transfers to and from RAM. With the proper configuration, you can also have it encrypted in transfer, at no cost in throughput or computational performance). The I/O also means it can crunch through all the conditionals listed in records much faster, including all banking and tax rules etc. In terms of physical hardware, everything is redundant, with the aforementioned ECC etc, and if you are serious, you sysplex it. And that's just for payroll/employee records. Virtualization is handled pretty much transparently, seeing as IBM has done it on mainframes since the 1960's. Security of the underlying system is excellent with superb compartmentalization and ACL's etc, such that the Linux images that you can run virtualized are less secure even in a hardened configuration.
For financials or insurance, it's everything mentioned above, and handling thousands of terminals/ATM's, handling transfers between accounts in real time etc. At a bank here in Sweden, the Unix/Linux crowd has been trying to move the bank away from mainframes for over 9 years now, but the mainframe division can show, year after year, that even with the support costs, it's cheaper to use the mainframe, because it's more reliable, and needs less infrastructure and manpower than the bundle-of-servers approach.
You don't have to IPL every LPAR in the sysplex at the same time...
Mainframes support virtualization, multiple versions of different operating systems running at the same time. One OS can be used for development, another for production. Hardware can be hot-plugged. You can pull out CPU's, disk drive, memory boards, all while the system is still running. The system will have it's own back-up power, it's own diesel generator, fuel-tanks and air-conditioning. Just as much if not more reliability and redundancy than a nuclear reactor.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
---
Even if it's on a punched card deck and you don't have card deck reader hardware anymore, IBM does. Its support group will transfer the card deck to whatever media your current hardware can handle.
Also, if a mainframe ever does go down, IBM's service escalation policy is unbelievable (e.g. that's what you pay for). I remember when my datacenter's mainframe went down [circa 1975]. The following numbers aren't exact, but similar.
The local rep must be onsite within a fixed period of time (e.g. 2 hours). He has [say] 4 hours to diagnose/fix the problem. If he is unable to do so, the regional hotshot is called in. If more time goes by, the national service rep and one or more of the system architects must arrive. After 24 hours, an executive vice president must be onsite and stay until the problem is resolved.
When we had our problem, the onsite VP had the entire mainframe replaced, by diverting a system scheduled to go to a new customer and airfreighting it up. Total round trip time [for complete replacement/install]: 72 hours
Also, the mainframes in those days were much bigger iron than the one pictured in the article. You could fit five z9's into the space of a single s/370
Like a good neighbor, fsck is there
If only there was a "...what?" mod option.
You don't have to IPL (Initial Program Load - reboot) every LPAR (Logical Partition - like a virtual machine) in the sysplex (cluster) at the same time...
LPAR is a Logical PARtition, a section of hardware in a mainframe dedicated to one operating system instance. Basically a form of visualization.
A sysplex is a SYStems comPLEX. Basically a cluster of mainframes.
Basically, you reboot a single LPAR containing one specific thing rather than the entire physical system or cluster.
It's basically like having multiple independent servers for each thing, but more reliable and more flexible.
upon the advice of my lawyer, i have no sig at this time
As much as I use and abuse VMWare, it's not yet comparable to IBM Mainframe class virtualization.
I watched an IBM mainframe service tech remove the jacket of his three piece suit, roll up his shirt sleeves, strike up a propane torch and re-sweat the solder joints on the copper pipe for the water cooling system of an ES/9000. I don't know what they are like these days, but 15 years ago those guys were amazing. They had to know how to repair every piece of hardware that IBM made, and how to troubleshoot every operating system.
I have great faith in fools - self confidence my friends call it. - Edgar Allan Poe
I just put our IT department into a spreadsheet, went through and counted the mainframe people. At a guess, there are 50,000 employed in our organization. In my IT department are about 325 people. Out of those 34 are dedicated to the mainframe 24x7x365. The other 300 are supporting mostly MS products and customers (public and internal). The network people are probably a couple of dozen, and maybe a dozen or so UNIX/Linux people. So no, mainframes are not over staffed. And we moved database clusters off servers and onto the mainframe Linux LPARs because of the huge increase of speed due to IO.
PHP + SQL beats SAP in almost all instances. SAP's use (as it is) is a merging of the front end and back end so that you don't need to know two separate programs to support it. It's instant integration. The front end and the database are inextricably linked. Someone thought it a good idea, but in practice, it makes things worse. Worse performance, worse security, harder support, more expensive.
Learn to love Alaska