NASA Unplugs Its Last Mainframe 230
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.'"
Do companies really use Big Iron anymore? (Score:2, Interesting)
Pardon my youth and naiveness.
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.
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
Re:Do companies really use Big Iron anymore? (Score:5, Insightful)
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.
Re: (Score:3)
Yeah but NASA generally is doing the kinds of apps that GPGU clusters excel at and not the types that mainframes excel at. Really they can rent one if they need it, but I don't see a real need at the current time for NASA to have one.
Re:Do companies really use Big Iron anymore? (Score:5, Insightful)
Re: (Score:3)
Over the last ten years or so the mainframe environment I worked with was IPLed (rebooted) every 2 or 3 months. Admittedly, most of these were because of human errors, but the cause doesn't really matter. The uptime is only there if you never let *anyone* touch it, or make *any* changes.
Re:Do companies really use Big Iron anymore? (Score:5, Insightful)
You don't have to IPL every LPAR in the sysplex at the same time...
Re:Do companies really use Big Iron anymore? (Score:5, Funny)
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
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...
Re: (Score:2)
If only there was a "...what?" mod option.
Presumably as a +1. As opposed to the "what the..." moderation.
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
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.
Re: (Score:2)
It's basically like having multiple independent servers for each thing, but more reliable and more flexible.
How does this compare with virtual machines with live migration that most virtualization systems support these days?
Re:Do companies really use Big Iron anymore? (Score:5, Interesting)
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.
Re: (Score:2)
Kinda like the HP Blade server we have running ESX here at work? It costs a lot less than a Z9 as well :).
Re:Do companies really use Big Iron anymore? (Score:5, Insightful)
Except that the HP Blade cluster has nothing on the mainframe in terms of reliability and data integrity.
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
Kinda like the HP Blade server we have running ESX here at work? It costs a lot less than a Z9 as well :).
Kinda, sorta, a lil :}
To be fair, there are many features in a mainframe that the HP blade server can't do.
Now don't get me wrong, I'm not saying the blade server is a pile of crap or anything. It's pretty damn awesome in fact.
But mainframes have some hardware redundancy features more geared towards assuring data gets from one place to another without error.
ECC if not CRC is used in nearly every path data can take through the system.
CPUs can be configured in a dual or tri-system state, where 3 procs do the same task, and at the end compare answers. Data can be redundant in memory too, which can do the same odd-man-out verifications on reads.
An HP blade server can emulate Some of this in software, but it is much slower than in hardware, and even that won't necessarily catch every data path.
The closest I think you can get is having 2 or 3 different instances of the same virtual machine processing the same data, using different CPU blades, memory, and ending up putting the results on different SANs each on their own unique bus.
Then you need at least two manager VMs to do the feeding of data and comparing the results, both of the instances below it, and with its partner manager.
Those two would also be responsible for figuring out which system below it is throwing disagreeing results, and ideally narrowing down from which piece of hardware, in order to raise an alert and hopefully disable the failed hardware at a higher level in ESX. As well as email you to buy it a replacement part of course.
If the two managers disagree with each other, all you can hope for then is a graceful termination of processing, hopefully with a detailed reason why.
You can get pretty close to a similar effect, in that you will not get bad data in the end due to some step in the processing chain going bad in hardware.
But you will likely have downtime of processing once something does go bad, depending on how many resources you are willing to throw at what amounts to the same work.
For the niche cases that need that level of data protection, mainframes pretty much do that all transparently, and as I mentioned a lot in hardware which speeds the over all jobs up.
Handling failed hardware transparently to the running job, and even the user, means the system disables the hardware flagged as bad, and continues on using other resources, all with no intervention on an admins part.
Of course most of what you are paying for is the IBM support, which is pretty much required to have. ;}
One can get such support from HP too of course, at a price. But being optional is nice for those of us that don't really need it.
Email alerts of failed hardware are plenty for me to work it into this or the next budget.
If I had an active HP rep, it isn't much to hit forward on an email after all
But on an IBM system like this, the mainframe sends IBM the message directly. 'When' depending on your support contract, an IBM rep shows up at your door either within a couple hours, or a day or two, replacement part in hand, and ready to do the swap under your supervision.
The price on the big iron is definitely about what you get. Thankfully for the wallet, many tasks don't need that level of redundancy, and so HP does quite well in the lower end market, which is of course larger too.
Mainframes serve special niches, and when those details become important for the task at hand, IBM has to make up on the low volume with higher prices. But it's not all for naught, you still get your moneys worth.
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
As much as I use and abuse VMWare, it's not yet comparable to IBM Mainframe class virtualization.
Re: (Score:3)
Re:Do companies really use Big Iron anymore? (Score:4, Interesting)
Having just got my first z114, I call BS. To me it seems that VMWare is actually more advanced. At least I can install an OS in under 30+ hours, and migrating an image around is as easy as a couple clicks. Plus, I don't have to work around the OS's inability to fully utilize disks >54GB.
The list goes on and on.
Re: (Score:3)
IBM mainframe is far cheaper in cost / transaction
Really? So that is why IBM published tpcc, spec-vm, spec-cpu, etc benchmarks for these machines? No, IBM doesn't publish these benchmarks because they would rather make up their own.
Frankly, I think its been a whispered secret for years that pseries machines best the zseries in every metric.
Re: (Score:3)
By your logic, the fact that GE does not publish City/Highway MPG ratings for it's locomotives can be taken as proof that it is cheaper to drive coal across the country in the back of a Prius. Instead of publishing 'standard' MPG benchmarks, they 'make up their own' benchmarks like cost/ton/mile.
Mainframes are designed to be very efficient at the workloads they actually run, not to look good on some benchmark that is not at all realistic for the workload it will be running. Where are HPs benchmarks on
Re:Do companies really use Big Iron anymore? (Score:5, Interesting)
Re: (Score:2)
I can attest to that. Any product that needs an entire floor of people to operate probably isn't worth much.
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
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.
Re:Do companies really use Big Iron anymore? (Score:5, Insightful)
But cmon, you gotta admit, that initial bid sure was cheap... before you city put in a bunch of change requests, new features, etc.. First hit is always free..
Re: (Score:3)
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
Re:Do companies really use Big Iron anymore? (Score:5, Interesting)
"Does payroll really require a Big Iron?"
No it does not. I managed the SQL databases for Comcast's company wide Accounting systems in 2006 it ran off of 4 MSSQL servers. They were monstrous servers, with 8 processors each, (you count the cores) screaming fast Raid 50 arrays with a buttload of ram to deal with the pivot tables. 99% of payroll speed is the DB read and write times not mathematic calculations.
But you certainly do NOT need Big Iron to do a few million payroll calculations for hourly, Executive and Sales people every 2 weeks. Running payroll took 6 hours on tuesday. If something went wrong we ran it later t hat night.
Re: (Score:2)
...but then add in financials - AP/AR, treasury, billingcstatements (but that is likely outsourced).
I'm going to guess that payroll done by ADP is donre on mainframe...
Re: (Score:3)
Re: (Score:3, Insightful)
This is silly. You do it all in RAM, and you don't even need that many gigabytes of it to do it. I think that if you look back at how one did programming on IBM's 360 (in assembly, for example), it was all pretty lean. I think that there are applications where even an SQL server is a bit much in the way of overhead. Just think of how much data per person you need to calculate everything that goes onto a payroll. I'm sure that 1kb per person would be enough for input and output (binary data with structure).
Re: (Score:3)
Ya but to program that you'd need someone smart. The current crop of MS lackies won't cut it.
Re: (Score:3)
Let me guess..you haven't done much in the way in developing of large financial/business applications, have you?
It is certainly more complex than you think, and likely in a different way from what you think.
The problem is that it has to apply an insane amount of rules and exceptions to all calculations, which make the programming quite difficult and unclean.
For example, a pretty simple calculation may have 50 or 60 parameters or more, most of which are completely illogical and difficult to understand becaus
Re:Do companies really use Big Iron anymore? (Score:5, Interesting)
Does payroll really require a Big Iron? I can't really imagine that keeping track of a company's financials (even measured in billions) requires $730,000 / year in number crunching ability...
It's not just payroll, but also tracking every expense, income, capital asset, depreciation, order placed, order received, services provided, goods shipped, customer phone call received, etc. For a large company it's an AMAZING amount of data. The "old way" of doing this was to dump all this into a set of tables, then run enormously complex recursively joined queries to restructure it and generate reports, billing reminders, etc. The new way is to dump it into mapreduce, scribe feeds, or equivalent and get cooked data out that can easily be tabulated in reports. The data out of the distributed computation gets fed into a relatively small db while all the raw data is just piped to some storage device for posterity. This computational model fits better with cloud provisioning. But you may find a room full of 20U blade chassis loaded up isn't exactly cheap either. But it's more flexible, and the mapreduce model of pre-cooking is more economic because it distributes the load over the quarter rather than over a few days following each quarter. Of course, horizontal scaling is vastly cheaper than vertical scaling, if the problem can be attacked that way. Even if the overhead approaches several hundred percent or you crunch numbers in php (heaven forbid) - it's still vastly cheaper.
But everyone knows the distributed model is cheaper. It's just that any business that's been around more than 10 years has a large body of legacy code to already implement all the custom payroll, auditing, tax code enforcement, tax optimization, reports, etc they need, which makes it's a huge project to move a system that's already in production. Moving it would probably cost in the millions and is very risky, so it's easy to just to pony up $700k annually and forget about it. It's also really difficult to migrate in steps.
Re: (Score:2, Troll)
People should keep this in mind when they decide to lock-in to a proprietary solution. Also $700K ... very low-ball from what I've seen.
Re: (Score:3)
"Moving it would probably cost in the millions and is very risky"
It could certainly cost millions but it is not risky. Done just semi-properly is one of the safest migration operations you can thing off: the service doesn't require real-time I/O so you just need to feed data in parallel to the old and new services and compare results: a zero risk operation.
Re:Do companies really use Big Iron anymore? (Score:5, Interesting)
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.
Re: (Score:2, Interesting)
It's not the number of decimal plaaces that's the issue. Mainframes can store and manipulate a number like 1.23 as EXACTLY 1.23, whereas a lesser machine would have to use some binary floating-point approximation (1.230000001234 or 1.229999999993241 for example) with rounding, etc. Even the programming languages used on mainframes (mainly COBOL and PL/I but also RPG) have specific provision for fixed-point decimal data types, whereas C and its derivatives (C++, C#, Java, Objective-C, D, etc) are utterly clu
Re:Do companies really use Big Iron anymore? (Score:5, Interesting)
It isn't that hard to implement "fixed decimal point" mathematical algorithms. It can be done on any computer which has integer opcodes... which is just about every computer ever built since ENIAC. The rounding you are referring to is due to floating point numbers where the numbers are rounded when they are put into the data format in the first place.
Making a "fixed point data type" in C++, C#, Java, or other more modern languages is simply creating that data type in the first place, and most of those languages have operator overloading for those data types that make the task trivial once you've implemented the type. I'm sure simply looking around can find find that already written as a library, but any programmer worthy of the title should be able to create these data types from scratch in those languages.
C and its derivatives also move strings around very efficiently, but I'll admit the programmer interface into accessing those functions is clunky and obfuscated, while COBOL does it as a designed behavior of the language.
As for static variables, the problems that come from the dynamic variables has more to do with how programmers using those languages have been taught to use them, where dynamic variables are considered ordinary and the developers insist upon pointer references in libraries and common interfaces. Again, it doesn't have to be done that way, but the API standards push it to be that way. COBOL comes from an earlier time when such techniques simply weren't taught.
Traditionally in Mainframes they had larger bus sizes and register sizes, which for fixed point calculations is critical. With most microcomputers having 64 bit registers as a common practice and even some low-end game consoles having 128 or even 256 bit registers, the real strengths of mainframes in terms of computing power is almost lost. About the only benefit to mainframes any more is strictly the uptime and circuit redundancy for hot-swapping components. For computing tasks that take hours or days to complete, that can be very important.
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
GPGPUs do not replace mainframes, unless the mainframe in question is being used for the wrong reasons.
GPGPUs excel at very fast computation and being cheap.
Mainframes excel at very high transaction rates (lots of I/O), incredible reliability (five 9s), and security.
GPGPUs are used in scientific (number-crunching) work, mainframes are used for business.
Re:Do companies really use Big Iron anymore? (Score:4, Insightful)
Not so much. The vast majority of mainframe systems are used with active network connections, and you probably use them without ever realizing that they are the back end to a variety of web engines you touch. Booked a hotel room, car rental, airline seat? Maybe you got money from an ATM? Bought something online? These are common modern uses of the mainframe's vast I/O capacity and reliability.
Re:Do companies really use Big Iron anymore? (Score:4, Insightful)
How do you think you can get your bank account balance if the machine storing that info is not connected to anything? The major use of mainframes is high-volume transaction processing, and those transactions come from somewhere (POS terminals, ATMs, reservation systems, web pages, etc).
No, mainframe security comes from the fact that every part of the mainframe - the architecture, the hardware, the OS, the middleware, the applications, the management is concerned with security from the very start.
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
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.
Re: (Score:2)
Re:Do companies really use Big Iron anymore? (Score:4, Informative)
In the article, they mentioned that 700k was for the maintenance contract, and 30k was for the power.
They also stated that thy were keeping it around for a few projects that were slated to be terminated, but hadn't yet been and they had no desire to migrate services to standard servers.
Re: (Score:2)
You also pay to use the processors.
Re: (Score:3)
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.
I saw a feature of the Z9 in wikipedia that intrigued me. I can't for the life of me figure out how they could accomplish it.
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
Clusters of PS3s make a perfectly serviceable supercomputer, but if your existing solution still works...
Re:Do companies really use Big Iron anymore? (Score:5, Insightful)
Mainframes are not supercomputers, and are not marketed as such. Not sure what you mean by 'modern hardware' - you don't think mainframes are modern hardware?
Mainframes are used for high-volume transaction systems, where uptime and data integrity is absolutely essential. Clusters of PS3's are not going to match that.
Re: (Score:3)
Re:Do companies really use Big Iron anymore? (Score:5, Insightful)
Re:Do companies really use Big Iron anymore? (Score:5, Interesting)
---
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
Re: (Score:3, Informative)
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
You could literally step inside an IBM 3090.
Re:Do companies really use Big Iron anymore? (Score:5, Interesting)
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.
Re:Do companies really use Big Iron anymore? (Score:4, Insightful)
Now now, not all of us slashdotters fear documentation, dependability etc :p
I don't work on mainframes, but I've worked in projects where mainframes have been involved as well as mainframe people, and in many ways it reminds me of my days in the military, the amount of dedication to logistics etc. Sure, to the run-of-the-mill "geek", it probably looks stifling, but for those of us who are used to teamwork etc, it's actually refreshing to have decent planning. Contrast that to working for academia... *shudders*
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
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.
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
I've heard mainframes have high IO thoroughput, but what about their equivalent Cloud solutions and scalability especially?
Depends on the problem.
For a relatively naively constructed algorithm, IO will be measurably worse in any 'cloud' platform popular today, and severely worse than mainframe. However, if you understand how to make your application scale (assuming it theoretically can), you can *in aggregate* match mainframe IO benefit at a much lower acquisition cost (though depending on who you talk to the more fudge-friendly 'TCO' metric may or may not follow). The trick is for many applications, the perceived risk and cost to reach that understanding is higher than just continuing to go with the flow of an IBM mainframe. Of course, some moderately broad areas of problems are getting tooling to more easily do that sort of scaling without too much extra thought. On the other hand, some problem areas no one has constructed a 'proper' approach that would negate the need for mainframe-like architecture.
With respect to the word 'cloud', the overwhelming majority of 'clouds' covered in tech news are EC2 and EC2-workalikes where IO is not particularly optimized. There are also various companies championing a departmental server or two with a few virtual machines on it as a 'cloud', further diluting the message and usually having terrible IO characteristics even with overpriced storage architectures. On the other hand, there are some projects claiming 'cloud' that include arbitration of bare-metal execution that can reasonably compare with a 'boring' scale-out private x86 scale-out solution, but very few people care.
Re:Do companies really use Big Iron anymore? (Score:4, Interesting)
It's really not hard to configure a single rack server with 1M IOPS, 1-2 TB RAM, 40-160Gbit aggregate networking and 40-48 cores these days. They fit 4-8 per rack, storage and switching included. They don't cost as much as you might think, even with the hand-holding support contract. And they run the OpenStack "cloud" platform quite well.
Re: (Score:3)
Yeah, the high-end E7's aren't cheap compared to an industry standard dual-socket box. Compared to a mainframe though - oh, yeah youbetcha. Industry Standard Servers go up to 8 sockets [hp.com] with 80 cores and 160 threads, but the 8-socket box is so rare that I don't recommend it without good reason. You can wind up being the beta tester for the OEM, it doesn't have a max RAM advantage, the CPUs are slow, it's huge and burns power, and so on. Maybe the next version will be more sexy.
Let me take a moment for di
Re: (Score:3)
Mainframes have legacy, locality, and privacy, which are particularly important qualities for banks and insurance companies.
The biggest problem is porting old programs to cloud systems. Sure, it can be done, but it's a million-dollar proposal, and if something goes wrong, it's potentially hundreds of millions of dollars in losses for a big bank. New systems will often use cloud solutions, but that requires convincing managers that they'll work just as well.
Whether a cloud solution will meet the throughput c
Re:Do companies really use Big Iron anymore? (Score:5, Informative)
My mom keeps telling me that UPS is one of the world's largest users of DB2, a statement backed up in this article [theregister.co.uk]. They're not switching off for the same reason financial institutions don't; After pouring lots of money into alternatives, they found that mainframes have better performance.
Re:Do companies really use Big Iron anymore? (Score:5, Insightful)
And if not always better performance, usually more predictable performance, which can be far more important.
For some apps, it is better to have a guaranteed transaction time of 10 ms than an average transaction time of 1 ms with no guarantees.
Linux RT and GRIO are getting better, but not quite there yet.
It's also easier to scale with big iron - you pay for more performance, Big Blue delivers it, and you won't have to go through painful migrations.
Re: (Score:2)
yes (Score:2)
Yes, mainframes are still used. They still have their place in the world.
Looking forward to the Ebay auctions... (Score:2)
...can I get a mainframe for $5 shipped on BuyItNow?
(I wish!)
the shiping fees are very high (Score:3)
and you want to pay more as the people at UPS will not be able to get you something like this with out dropping it.
Obligatory power down sequence (Score:3, Funny)
Daisy..., daisy... give me our answer, do, ...
I'm half crazy for the love of you
[sounds fades away]
Re: (Score:3)
I'm afraid I can't do that Linda...
Re: (Score:2)
I use that as a low-power alert on my netbook, it still freaks me out a little.
Re: (Score:2)
...But I still have a lot of confidence in the mission.
Distributed servers (Score:3)
But they still have the data center (Score:5, Interesting)
NASA still has a big data center in Slidell, Louisiana. They're hiring. [jobamatic.com] With the mainframes gone, one would expect they'd close down Slidell, but no. Instead, they're building a big museum and PR center [infinitysc...center.org] there.
NASA seems to spend money at a relatively constant rate, independent of whether they're flying anything.
Re: (Score:3)
NASA seems to spend money at a relatively constant rate, independent of whether they're flying anything.
Which makes them no different from any other government agency.
NASA should disestablished, and it's responsibilities farmed out to other agencies. Give space launch to the Air Force and Navy, and science functions to universities and other research agencies.
No mainframe = shuttered data center? Huh? (Score:5, Insightful)
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.
Re: (Score:2)
Perhaps it could fit in your living room, but I bet it would block the view of the stripper pole
Re: (Score:2)
just undoing misplaced mod points.
Did you read either link? (Score:2)
Did you bother to actually read the pages you link to?
In the first place the 'data center' in Slidell (if that's what it really is) seems to be part of the Stennis Space Center and have a lot more going on than just housing servers (if you bother to read the jobs listing you linked to).
Then, if you bother to read the other web page you linked to - NASA isn't building anything. Though NASA owns the land, they haven't paid a thin dime towards science center - it's run by a non profit.
TFA (Score:5, Informative)
Makes sense... (Score:5, Insightful)
For the workloads a mainframe is designed to perform, I can't imagine NASA would have much use for one. They are database and transaction processing monsters. NASA does not handle large volumes of either. I imagine their scientific computing needs are pretty fair-sized, but mainframes are indeed rather cost-ineffective for scientific workloads.
Re: (Score:3)
That's true today. But it hasn't always been true, especially back when NASA first got into mainframes. Nor are they limited to doing database and transaction processing.
Are there emulators for mainframe code? (Score:4, Interesting)
I mean it's possible to run your old Commodore 64 or TRS-80 (or even Apple II?) software in a software emulator of these machines. And it's (mostly?) legal to do so? (BTW, anyone know of an Apple II emulator which will run the game "Epoch"?)
So are there software emulators for an IBM 360 or VAX out there? Can I run them on my iPad? There might be some interesting software that you could play with, despite the primitive hardware they did send Man to the moon using these systems as well as defend the U.S. against nuclear attack and run the IRS. (Getting this code might be a bit of a problem!)
Even if there isn't a software emulator DIRECTLY for a mainframe to run on my iPad, what about one that'll run on a pentium class PC. Then is it practical to run THAT in emulation mode on my iPad?
Re:Are there emulators for mainframe code? (Score:5, Interesting)
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.
Re: (Score:3)
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.
So true.
I think most people have very limited knowledge of the real world. I'm not sure if the Internet works to improve that, or merely demonstrates it. :\
Re: (Score:3)
Re: (Score:2)
And yet all the new tech seems determined to reimplement mainframe tech but not as well.
Re:Are there emulators for mainframe code? (Score:5, Informative)
Yes: http://www.hercules-390.org/ [hercules-390.org]
But IBM won't allow to run z/OS (the operating system usually used) on it.
Re:Are there emulators for mainframe code? (Score:4, Interesting)
Re: (Score:3)
Anyone also do assignments on PDP 11/70's as I did also?
Yes, on RSTS/E using BASIC-PLUS (for lab work in high school) and Macro-11 (for personal fun stuff). Also, RSX-11M.
Re: (Score:3)
FSW SPF Mainframe Shutdown was July 29th 2011 (Score:2, Interesting)
The JSC mainframe system(s) used to build and support the shuttle flight software were shutdown on July 29 of 2011. DEVS, PRDS, PATS, SDFC, SDFA, and RTF1 systems.
These systems had been used since May 6, 1981 (no, not the same computers) under a NASA contract. Photos of the servers were taken. Yes, they are just as boring as they sound.
It was sad to see the tape silo nearly empty when it would normally hold hundreds or thousands of tapes.
We have a support group on LinkedIn.
Remember the Tao... (Score:5, Interesting)
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.
decommissioned computers (Score:2)
In ~1992... (Score:3)
...we had an IBM consultant who worked onsite doing the care & feeding of our IBM 390. He would spend most of his day running diagnostics and printing usage reports. I remember looking at some of his reports sitting next to the printer, and the vast majority of the time the only job running was his diagnostics program...
Re: (Score:2, Insightful)
Re:Why stop there??? (Score:5, Informative)
scientists aren't business people either. The intricacies of managing the main contractors, the infrastructure base and the diplomatic exchanges that go with all the other space programmes in the world are best left to people who aren't scientists.
NASA was always about more than just shuttles and manned spaceflight. Those are, generally, relatively poor investments for the science you get out of them. Great PR, and broadly inspirational, but relatively inefficient actual science. NASA does communications satellites, telescopes, materials sciences, weather, the weather of the sun, general satellite management from all of those things, fundamental aeronautics research, etc. There's a lot more to what goes on that just pure science, and than the trolls misguided view that it's all about manned spaceflight. And, like anything, there's a legitimate desire to use the progamme to showoff expertise and build relationships internationally.
Re: (Score:2)
Politicians shouldnt be in charge of how NASA operates.
Well, that's easy. Just eliminate all NASA funding from the taxpayer and then politicians won't feel such an urge to tell them what to do.
Re: (Score:3)
Re: (Score:3)
If they just tried to leave it running it would've powered itself down eventually.
Buddy, this is a mainframe. They don't fault. It would only power itself down when someone actually unplugged it. We're talking years/decades without a problem (well, we are with my Unisys mainframes...).
Re:Could have just waited (Score:5, Funny)
It would only power itself down when someone actually unplugged it.
and unplugged the backup generator, and siphoned off the diesel that powered it.
I'd like to think the OP meant "stayed online long enough to develop sentience and then powered itself down after noticing the futility of existence". But I rather think he's a Windows guy :)
Re: (Score:3)