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.'"

Comments

Do companies really use Big Iron anymore?

[Anonymous Coward]

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?

[tysonedwards]

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.

Re:Do companies really use Big Iron anymore?

[History's Coming To]

The reason big old fashioned mainframes are still in use in many places is simply the cost of moving away from them. They're generally running custom code, custom databases, custom hardware....the sheer cost of re-doing everything is the big problem, not the fact that modern hardware has any issues doing the job.

Clusters of PS3s make a perfectly serviceable supercomputer, but if your existing solution still works...

Re:Do companies really use Big Iron anymore?

[Shinobi]

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:Do companies really use Big Iron anymore?

[deoxyribonucleose]

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?

[bws111]

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?

[Anonymous Coward]

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...

We are talking about units of measurements that *only* have 2 decimal places after all, across likely hundreds of thousands of employees.
Is clustering even a requirement for this vertical?

I am not an accountant... I am however a theoretical physicist... Maybe I don't understand the eccentricities dealing with calculations with so few decimal places.

Re:Do companies really use Big Iron anymore?

[Junta]

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?

[bws111]

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:Do companies really use Big Iron anymore?

[Sarten-X]

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 capabilities of a mainframe is something of an open question. Sure, cloud systems can scale more easily, but the programs they run must also be scalable. Very often, the algorithm used on the mainframe won't port cleanly to a cloud system in a way that will offer reasonable performance. There's significant re-engineering involved, which drives conversion costs higher.

With so much new code being handed off to a nebulous cloud provider, often in another company, outside the control and oversight of the IT managers, there's reasonable concern for security. While there's few incidents of actual cloud-related security breaches, there are many stories about breaches on shared systems. IT managers know that most cloud systems are shared, and it's seen as only a matter of time before something bad happens.

Clouds are new. New things are scary to the steeped-in-history banks and insurance providers. Give them time, and they'll start using cloud solutions widely, but don't hold your breath waiting.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

They do.
They use mainframes to _power_ their cloud solutions.

The trend these days is for companies to have a few huge physical machines, and run VMs on top of that. That's what mainframes do best.

Re:Do companies really use Big Iron anymore?

[sjames]

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:Do companies really use Big Iron anymore?

[story645]

My mom keeps telling me that UPS is one of the world's largest users of DB2, a statement backed up in this article. 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?

[Samantha Wright]

You're probably aware of all this, but just to anyone who happens by and gets confused: these mainframes are not exactly dinosaurs; the z9 series was introduced seven years ago and uses totally custom 64-bit CISC silicon designed to give the top of the line performance for the day. The hardware is essentially optimized to run VM hypervisors, and one of the major guest OSes for it is Linux. Essentially what the price tag fetches you—very much unlike a pile of PS3s strung together—is ungodly amounts of vendor support. As documentation-fearing folk, we Slashdotters don't generally think about dependability on the scale that IBM does, but there's a very clear market for it, and that's really been the marketing point of Big Blue for at least the past twenty years or so, much moreso than legacy software lock-in.

Re:Do companies really use Big Iron anymore?

[jythie]

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.

Re:Do companies really use Big Iron anymore?

[jythie]

Not sure I would say the 'rest of the world'. Some companies seem to be playing with cloud computing and it is a popular buzz word, but most companies still choose between mainframe or a rack full of servers. Cloud stuff is not known for reliability or flexibility of application.

Re:Do companies really use Big Iron anymore?

[History's Coming To]

Agreed, I was referring to some of the excruciatingly old systems that are still running, some going back three decades or more.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

A PeopleSoft or SAP implementation isn't cheap even if you manage to run it in a distributed Windows and/or *NIX environment. At my last employer, the PeopleSoft IT team was larger than the rest of IT, who had to manage multiple locations, 1000+ phones and 200+ servers.

Re:Do companies really use Big Iron anymore?

[Glonoinha]

I'm guessing part of their security comes from not being connected to the 'net. Hell, DOS and Windows 3.1 machines were some of the most secure machines in the past 25 years history of computers, assuming you secured them physically - because by and large they didn't have dedicated connections to other (external) machines. I'm guessing if you didn't plug it in to an Ethernet connection and physically secured the machine, even an unpatched XP box is pretty secure.

Re:Do companies really use Big Iron anymore?

[Lumpy]

"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:Do companies really use Big Iron anymore?

[Anonymous Coward]

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?

[emt377]

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:Do companies really use Big Iron anymore?

[hairyfeet]

Are they renting the thing? Because I would think that big iron like that wouldn't be breaking down, hence why they were so popular. If its a support contract then obviously it would be cheaper to hire a couple of admins well versed in the Z-series and let them take care of the thing. But I looked that model up and it was released in 2005, that's barely broke in in mainframe terms. Now if they simply don't need that amount of power now that they've retired the shuttle that's understandable but I just hope it isn't an excuse to buy into some "cloud centric web 3.0 GPGPU blingapaloza" as lets face government agencies and blowing money go together like chocolate and peanut butter. I read TFA (I know I know, but I got bored) and there isn't a single word about what is gonna replace it, is it gonna be more costly? less? Are they simply not replacing it at all? A little more info would be nice.

Re:Do companies really use Big Iron anymore?

[AK Marc]

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.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

zOS is licensed such that you need a support contract to power the machine on. You own an enormous paperweight without a support contract.

Re:Do companies really use Big Iron anymore?

[Shinobi]

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:Do companies really use Big Iron anymore?

[bws111]

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?

[tysonedwards]

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:Do companies really use Big Iron anymore?

[Nerdfest]

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?

[Anonymous Coward]

Not to mention having to rewrite the damn code to work on the GPGPU, and having to re-architect all my programs to be used through OpenCL or CUDA... But in a few years they can buy Intel's Knight's corner CPUs, which do allow for standard programming languages to be used... so perhaps they are simply moving to that.

Re:Do companies really use Big Iron anymore?

[Nerdfest]

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:Do companies really use Big Iron anymore?

[Nerdfest]

You also pay to use the processors.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

You don't have to IPL every LPAR in the sysplex at the same time...

Re:Do companies really use Big Iron anymore?

[mikael]

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:Do companies really use Big Iron anymore?

[Gerzel]

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?

[Forever Wondering]

And backward compatibility and service. Write once, run forever. You can take a binary program compiled in 1975 and it will run unchanged on the latest mainframe.

---

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:Do companies really use Big Iron anymore?

[Lambeco]

If only there was a "...what?" mod option.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

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:Do companies really use Big Iron anymore?

[rotorbudd]

From TFA
" But it was time for a change, with the House spending $30,000 a year to power the mainframe and another $700,000 each year for maintenance and support."
  That's THE mainframe. As on one.

Re:Do companies really use Big Iron anymore?

[rtfa-troll]

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?

[symbolset]

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:Do companies really use Big Iron anymore?

[Anonymous Coward]

You can also get all of this with a p-Series, or even x84 and VMware.

I don't really see why anyone would chose z-series other than for legacy reasons.

Re:Do companies really use Big Iron anymore?

[compro01]

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:Do companies really use Big Iron anymore?

[Skuld-Chan]

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?

[Skuld-Chan]

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?

[Shinobi]

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?

[Shinobi]

As much as I use and abuse VMWare, it's not yet comparable to IBM Mainframe class virtualization.

Re:Do companies really use Big Iron anymore?

[arth1]

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:Do companies really use Big Iron anymore?

[webnut77]

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?

[RadioTV]

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?

[Forbman]

...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:Do companies really use Big Iron anymore?

[Forever Wondering]

You could literally step inside an IBM 3090.

The size changes kinda remind me of Christopher Reeve in his first Superman movie when he is looking for a phone booth to change his clothes ...

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

True. However, big vendors of big important (expensive) systems at big customers will typically have a cubicle farm on site occupied by their on-site reps -- sometimes 7x24 but that may be a bit rarer these days. Of course, this is the top tiers of support available. Actually, the first three steps you describe (<=2 hrs onsite, <=4 hours fix, escalate to regional support hotshot) was pretty standard for the top tiers of support even from DEC et al back in those days.

IBM was, indeed, really good at the MR (mechanically replace) guarantee and had enough iron flowing through the system they could defer/delay/reroute something to your site (at least in the U.S.) with awesome efficiency.

I know of one major site whose critical (not life saving, but probably many 10's of millions of dollars a day in opportunity loss, and perhaps actual loss, in the case of site disaster) big systems didn't have a backup site. They just kept track of where empty data centers were available for lease and planned on invoking the IBM replacement guarantee and start writing big checks to lease those offlline data centers for whatever it cost and have IBM ship and install the replacement equipment there. This company was big enough though that their contracts with IBM were almost certainly completely distinct from anything in the "product offering catalog". They were pretty convinced that they could get the critical systems back on line in (IIRC) three days (I think they were assuming the site disaster was not the result of a system wide problem like a full scale nuclear attack by the USSR). As far as I know they never had to play that card and I doubt they still use that strategy.

Re:Do companies really use Big Iron anymore?

[QuantumRiff]

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:Do companies really use Big Iron anymore?

[whatteaux]

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 clueless.

But mainframe financial applications do relatively little actual arithmetic. Most of their time is spent moving strings and structures around - something that C and its derivatives also just can't do efficiently, if at all, whereas COBOL and PL/I do it easily and quickly.

In mainframe software, anything that can be static is static; data is only dynamic if it absolutely has to be. This is the basis for the high efficiency of mainframe software. COBOL has no equivalent of C's 'new'; PL/I does (of course - 'ALLOCATE') but it's used relatively rarely. You therefore almost NEVER see memory leaks in mainframe software.

Re:Do companies really use Big Iron anymore?

[bill_mcgonigle]

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?

[Anonymous Coward]

If you are architecting a high performance transaction system where the internet packet originated by the user is touching your mainframe unmolested, you aren't doing it right.

The SQL query that hits the mainframe is likely front-ended by a load balancer otherwize your mainframe is likely going to spend most of it's time collecting and waiting for partial queries reducing the througput to what a cheaper multi-core x86 server will yield.

Today, that load balancer is likely a cloud of x86 servers to defend against DoS attacks that inevitably will occur with a site where you can book a hotel room, car rental or airline seat, or purchase things online.

Re:Do companies really use Big Iron anymore?

[Teancum]

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?

[tibit]

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). So then, with a million people you need say a gigabyte of RAM, and I'm sure you don't need more than one core to go through it and be done in a couple minutes. A modern 64 bit desktop machine with 64gb of RAM would probably be more than enough to do Comcast's payroll in a couple minutes, not hours. Of course you'd probably need a more state-of-the-art programming environment to code it up so that it'd be inherently safe (C is out) and productive (even a subset of C++ would be out).

Re:Do companies really use Big Iron anymore?

[VortexCortex]

You can take a binary program compiled in 1975 and it will run unchanged on the latest mainframe.
Even if it's on a punched card deck and you don't have card deck reader hardware anymore, IBM does.

Well, that's why Open Source software is better, you could just recompile the source code instead of paying for support to emulate or disassemble the proprietary program's punch...cards?-- Oh, wait... never mind.

Re:Do companies really use Big Iron anymore?

[berashith]

i worked on airline reservations, and the ticket purchase page went through typical web and app tiers, then to a translation service so the information could be sent through MQ and then processed on the mainframe. There was simply no way to keep up with the volume of data for all of the airline seats with the transaction rates and flexibility that the mainframe provided. Everything was being pulled out to the open systems and vmware bits, but the heart of the entire operation required the mainframe.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

It is MUCH, MUCH more expensive!

Re:Do companies really use Big Iron anymore?

[AK Marc]

And I've never seen a government RFQ/RFP ever properly written by IT. It's either by the purchasing department or an incompetent IT manager who should never have gone into IT, but thankfully got promoted to where they never have to know "how" or "why" ever again, so long as the budget balances. So requirements are never well documented. Sadly, SAP sitting in a box on a Dell server would meet many of the official RFPs I've seen. So who's to blame the companies for making a buck off the incompetent IT processes?

Re:Do companies really use Big Iron anymore?

[dissy]

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?

[Darinbob]

I don't know of any company that prefers "the cloud". The cloud is a disaster waiting to happen.

Re:Do companies really use Big Iron anymore?

[turbidostato]

"Mainframes serve special niches"

Yes. And now it seems it's not rocket science after all.

Re:Do companies really use Big Iron anymore?

[Darinbob]

That's not that much money, compared to how much you have to pay IT workers no matter what solution you use.

Re:Do companies really use Big Iron anymore?

[i]

Can You pull out a CPU from the Blade server without *any* interruption of any application ?

Re:Do companies really use Big Iron anymore?

[smash]

Neither is the price.

Re:Do companies really use Big Iron anymore?

[turbidostato]

"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?

[smash]

Given that he was talking 2006, you could probably do it on a laptop running a server in vmware workstation in a reasonable time-frame in 2012.

Re:Do companies really use Big Iron anymore?

[Darinbob]

The thing with mainframes was not the cpu speed. But that they could do all the database I/O without sucking up CPU. They were multiprocessing but not in the idiotic modern way of having "cores" sharing memory. Meanwhile it can handle your transactions at the same time, stuff that happens every hour of the day all year long not just during payroll times.

The real reasons they're going away is that the people these days prefer just buying Microsoft peddled wares or they don't want to to have to think outside the box and learn something.

Re:Do companies really use Big Iron anymore?

[Darinbob]

Ya but to program that you'd need someone smart. The current crop of MS lackies won't cut it.

Re:Do companies really use Big Iron anymore?

[Junta]

The key is that aggregate performance numbers are easy enough to get, but the ability to actually put those capabilities to effective use is something else. Either the metric is too segmented to easily put to use (e.g. 2 TB of ram in 64 GB chunks, 1M IOPs consisting of chunks of 50k IOPs), or some bottleneck gets in the way (e.g. storage subsystem has great numbers but only accessible by inadequate HCAs. Now a lot of HPC workloads and things like Hadoop manage to effectively use segmented resources, but my point was those numbers are a bit more accessible without thinking in a mainframe context.

Re:Do companies really use Big Iron anymore?

[WalkingBear]

As a developer of high frequency trading systems I call BS on this big time.

[citation needed]

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

You are a moron.

Re:Do companies really use Big Iron anymore?

[rubycodez]

I work at a VAR that sell HP blades, HP Itanium2 and IBM.....guess what, the IBM mainframe is far cheaper in cost / transaction (despite HPs B.S. ad compaign that deliberately compared wrong models). The only downside is that you must be running powerpc binaries (the x86 blade extensions to mainframes exist but not cost effective)

Re:Do companies really use Big Iron anymore?

[rubycodez]

has nothing based on performance either, the cost per db transaction is higher with HP blades.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

What real difference does it make how many decimal places there are? Wouldn't mathematical operations be the same for 1023.21 or 1.0231? It doesn't change the number of significant digits.

Re:Do companies really use Big Iron anymore?

[baegucb]

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?

[baegucb]

JES2 is part of the operating system (well, sorta). All it's console messages start with $HASP. That stands for Houston Automated Spool Priority or somesuch. It was developed for NASA for Apollo missions. So yes, rocket science was involved.

Re:Do companies really use Big Iron anymore?

[Shinobi]

True, especially when you factor in the ECC or other checksumming, as well as the transparent encryption at no performance cost that are available on the mainframes.

Re:Do companies really use Big Iron anymore?

[symbolset]

No, I do believe that's 2TB of directly addressable RAM as one contiguous chunk in one 4U server like the HP DL580 G7 for example, and 1M IOPS consisting of four devices in one server each capable of 250K 512 byte IOPS, and striping in software to deliver the full 1M IOPS in one server. Specifically for storage the IODrive Duo SLC. You can actually do 2M IOPS in that box with 8 devices, but that seems overkill for most things. There's esoteric stuff out there that uplifts this stuff to 20x even that, but uses flash storage as a sort-of second tier of RAM and it's too experimental to consider for enterprise use - and the box becomes a storage only node rather than a general purpose device. You can do some more traditional SFF SSD storage as well if you like, for a second tier of storage. They're doing memory mapping stuff with Infiniband too now I understand, but I didn't figure that either.

This is commercial, off-the-shelf stuff now. Clustering would give you multiples of this naturally, but not linearly and with the concerns that you mention. The next generation of servers is due out any day and will use Load Reduction DIMMs and PCIe 3 to double up both the installable memory and the storage I/O potentials. Industry standard servers are getting pretty hardcore.

Re:Do companies really use Big Iron anymore?

[baegucb]

They are connected to the net. But the parts that control the mainframe, in our case, are on a dedicated internal LAN. Only certain userids from certain IP addresses can issue commands, etc. But we have plenty of websites running on the internet through the mainframe. Just users of those websites can't get to the OS. And the websites do use JAVA, we do have SMTP and TCPIP running as well for example. Just most of the public never realizes it.

Re:Do companies really use Big Iron anymore?

[Junta]

You start dishing out the cash for E7 processor based systems and particularly signififcant FusionIO capacity you are getting pretty high into the stratosphere of cost (at some point 'industry standard' becomes a stretch...). I'm not so sure that would be appreciably cheaper than a system z of comparable capabilities. But that is a more competitive sort of strategy in raw performance. Often I hear people talking about inexpensive 2 socket servers with dirt cheap 7200 rpm high-capacity drives as the 'answer' to mainframes, with very very few of the critics even knowing what the word 'infiniband' means. It might also be why so many mainframe shops 'fail' in their x86 performance evaluation, they might not go high enough up the product line thinking that 'x86 is x86', and maybe that's unfair.

Re:Do companies really use Big Iron anymore?

[baegucb]

"Even if it's on a punched card deck and you don't have card deck reader hardware anymore, IBM does." ehhh..not so much. I know ten years ago they couldn't find a card punch machine for where I worked. (Don't ask lol). Anyways, cards are readable by looking at them.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

This is usually what happens when you go to large consulting companies.

They have hundreds of people that are SAP "programmers" on staff, so they push that. It's absurdly expensive, complicated, time consuming and requires lots of training.

So of course, they love it.

Re:Do companies really use Big Iron anymore?

[Shinobi]

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?

[Anonymous Coward]

Actually, scanning the cards and running a script would be no problem.

Re:Do companies really use Big Iron anymore?

[Forever Wondering]

"Even if it's on a punched card deck and you don't have card deck reader hardware anymore, IBM does." ehhh..not so much. I know ten years ago they couldn't find a card punch machine for where I worked. (Don't ask lol). Anyways, cards are readable by looking at them.

They may not have a punch card reader, but if you really had to get the data read in, and you had a lot of it, you could optically scan the cards with a flat bed scanner, and with some custom software, you could restore the data. IBM will do that sort of thing (if the price is right). It's all about service.

They probably do still have magtape. I took a look recently, and the zOS system load comes on magtape, or a special "tape file" disk file format. The latter was originally developed for OS2, so OS2 could simulate magtape. The format has little headers embedded within that demarcate tape records, tape marks, end-of-tape, etc.

So, even without a physical tape, they still rely on the concept of magtapes. And virtual card deck readers (in the latest incarnation of VM/CMS).

And JCL is still alive and well ... [Hmm ... I think that rhymes--I must be a poet]

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

Basically, I'm just going to help you and everyone you speak to:
Never use the word 'basically' ever again. Basically, you're a kind person that understands much, and you don't mind explaining complex things to people simply. But your overuse of the word makes it superfluous, messes with your cadence and it is distracting.

Re:Do companies really use Big Iron anymore?

[baegucb]

IPLs are only needed for certain changes or upgrades to the OS. Craploads of other changes are done all the time, during the change window.

Re:Do companies really use Big Iron anymore?

[baegucb]

We went to all virtual tape about a year ago (although there are tapes, it's all STK robots handling them). OS upgrades are probably FTP'd now (I'd have to ask to be sure). The JCL is unchanged since the OS thinks they are real tapes. But they are not the old round reels with 2400 feet of tape, they are cartridges. http://www.oracle.com/us/products/servers-storage/storage/tape-storage/029139.htm

Re:Do companies really use Big Iron anymore?

[bored]

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:Do companies really use Big Iron anymore?

[bored]

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:Do companies really use Big Iron anymore?

[Anonymous Coward]

Um, yes!

Re:Do companies really use Big Iron anymore?

[bored]

And they (modern x86 servers) have ECC on every bus from the registers to the disk, and cost about 1/10 (or better) than a similar zeries.

There is a reason IBM doesn't publish benchmarks and prices for these things. I recently got a machine from IBM, which costs more than my house, and is slower than a 486. IO rates? Same, its got 8GBit FICON, but doesn't seem to be able to drive more than a small fraction. I'm sure I could spend a few million to unlock the processors, and a few more IO boards, and more than 8GB of RAM. Then it might be fast enough to keep up with the DL580's in the rack next to it.

Plus, the DL580 can have linux installed and running in under an hour, the mainframe? If its running in under a few days its a small miracle. The management aspects, are a total joke. There is more processing power in PCs connected to the thing for management/translation/etc (5 of them!) than it has.

Re:Do companies really use Big Iron anymore?

[Eravnrekaree]

Per FLOP or whatever the modern mainframes actually are more cost efficient, as they reduce several inefficiences that exist with having banks of hundreds of individual units, and also, they still provide for redundancy, you can rebuilt an entire modern IBM mainframe without powering it down basically. Any older, aging computer is going cost than a more modern unit, that includes individual single CPU servers and mainframes, that an old mainframe is losing its cost value compared to newer stuff does not mean mainframes are no longer viable since modern mainframes are very competitive.

One thing that has been chaning that with the increasing power of individual chip CPUs, that these smaller systems can now handle all of the tasks a large mainframe used to. The mainframe market is shrinking but still can be competitve where hundreds of individual single CPU systems would still be the alternative.

Re:Do companies really use Big Iron anymore?

[bored]

The fusionIO disks, are expensive, so are the texas memory system ones, but they are still an order of magnitude cheaper than anything available for zseries. Oh, and putting a fusionIO PCI board in your server, will probably increase its transaction numbers beyond anything achievable for less than 9 figures in the mainframe space.

So, sure 1TB of memory, 64 processors, a couple 8/16Gb FC adapters/infiniband/etc, fusionIO boards, etc, your x86 might cost $100k, but its going stomp all over a mainframe that costs $1M.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

Have you ever used SMF/RMF for reporting performance problems? Distributed systems WISH they had that level of accounting?

Re:Do companies really use Big Iron anymore?

[funwithBSD]

Sadly, NASA is not doing rocket science anymore.

Muslim world out reach and other non-scientific endeavors have taken over.

NASA has been on a decaying orbit for some time now.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

HP's reply to Mainframe and z/OS is Non-Stop.

Non-Stop gets it's reliability from mirroring all it's work across multiple nodes. The nodes themselves are mostly standard Integrity (Itanium) nodes, the same as you run HPUX on. Midrange, essentially. Then they're surrounded with insane amounts of management, comms, highly reliable storage that gets mirrored anyway...

Point is, getting this sort of high grade reliability - never mind not going down, this is fact checking every bit your hardware crunches - is a huge deal. And it's hard. ESX doesn't cut it. Fault tolerance on ESX doesn't cut it, and it doesn't have the throughput either.

Mainframes, Non-Stop, they're incredibly arcane. And expensive. And yet they still sell, actually on their merits, to a few companies, because that''s what they need.

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

Hey, 2010 just called, it wants its mainframe computer back...

Re:Do companies really use Big Iron anymore?

[symbolset]

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 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 disclaimer and say that I don't work for HP, nor FusionIO, nor Intel, nor anybody else mentioned here. I work in this space as an enterprise architect, but that's not a claim to authority on the subject but a basis for the disclaimers that follow. I know some things about this stuff and am having a personal discussion about these issues unrelated to my work. HP, Dell, IBM, Fujitsu and others offer equivalent solutions to the specific industry standard server architectures mentioned here (or they wouldn't be Industry Standard) and HP systems are only referenced for convenience of the specification links I have to hand. AMD has impressive solutions in this space and I'm fond of those too. There are various available brands of PCIe attached Flash storage with varying performance and reliability metrics, and the referenced FusionIO devices are only specific examples with published performance that can be measured in the field - of many. In this discussion space my opinion is not my employer's opinion and they neither know I do nor encourage me to comment here. This is not a specific recommendation or solution to any specific need, which I would only do under contract with specific terms for performance and pay. I don't own any stock in any of these companies either. This is not a solicitation for employment - I'm good, thanks. Finally, I've taken careful measures to shield my real person from my /. persona these last 7 years for good reason, and this is one - though it's not so hard to find me if you try given the evolution of Google my efforts in this regard provide plausible deniability. I try to be an anonymous commenter and you should not trust me. Validate everything yourself if you've found what I've said interesting or promising enough to do so. End disclaimer. Whew.

You can get a dual socket X5690 box like the HP DL370 G6 and stuff up to eight of the FusionIO cards in it too if you want and maybe still get your 2M IOPS in 5U. Those only go up to 384GB of RAM each these days and 12 cores/24 threads at a nominal 3.4GHz of x64 performance. It depends on what you want to do, where your price/performance/reliability points are, whether the box is strictly a data cruncher or a VMHost too. The E7 box can be a much better deal if you calculate the cost of the rack space pretty high - especially if you only need 512GB of RAM because you can use the price sweet-spot 8GB DIMMS. If your RAM needs are even more modest then the 2 socket box becomes the better deal at 144GB RAM with the 8GB DIMMS. You can't go any lower than that and have a general-purpose data-crunching box, as those FusionIO card drivers require immense buffers. Just one of these least boxes would be more than adequate to handle, for example, peak Twitter at the current rate of growth including acceleration for the next three years including the storage requirements for every tweet ever (though of course, geographic redundancy, geographic latency, and so on...).

Price of the processors and RAM is a fairly big deal in the processing part. Those E7's and 32GB DIMMS are spendy parts. If you can crunch the problem down to chunks of 96-144GB and 512K IOPS you get the best deal - and you can move to 2U servers or blades and put a lot of them (64!) in one rack. That's great if your job requires a lot

Re:Do companies really use Big Iron anymore?

[Forever Wondering]

I hadn't used a mainframe (370/145) since 1977, but I was curious so I did some reading over the holidays. From IBM's doc pages, FTP is an option for the OS load. No wonder about 2400 tape. Circa 1995, I was using DDS/DAT (digital audio tape, which was helical scan). It was half the size of a pack of cigarettes and would hold several GB.

---

The legacy surrounding the IBM ecosystem is astonishing. Beyond raw [virtual] tape records/blocks, you still have things like: The raw block is 800 bytes with a blocking factor of 10 [or equiv]. A fancy way of saying card images (at 80 columns per).

I'm not even sure if hierarchical filesystems are supported. From what little I read, it seemed like things were still "volume" oriented, possibly with an OS partitioned dataset on top. That's what I imagine for the OS/VS1 OS/MVS descendents. For the VM/CMS, you can have your S (system) drive, and your A (personal) drive [and others]. I'm assuming that if VS1 is a guest OS of VM, its volumes are VM virtual drives.

No wonder the current/future emphasis on Linux--it's a clean slate. I don't know whether the preferred mode for Linux on zSeries is VM guest or native install, but the guest approach allows migration without disrupting the straggler VS1-like apps.

Re:Do companies really use Big Iron anymore?

[haruchai]

The healthcare outfit I'm currently working for is in the final stages of an SAP launch. We just came out of a 3-year hiring freeze; I'm guessing that, except for SAP drones, we're about to go back into another one.

Re:Do companies really use Big Iron anymore?

[symbolset]

It's not a high achievement for off-the-shelf industry standard stuff to beat the mainframe of seven years ago. Those mainframes have some serious reliability, availability and scalability features that your quad-core Android tablet doesn't have. Even though you've got it beat on raw compute, I/O and network performance in a device that fits in your pocket and runs all day without plugging in there are other factors to consider like TCO, ROI and who the hell am I kidding? This stuff is dead as Canasta.

Re:Do companies really use Big Iron anymore?

[haruchai]

Gosh, the financial outfits are sure really, really worried about losing money.

I guess that means they are naturally very, very careful

So explain to me just how the fucking financial crisis happened with all these cautious souls on constant watch.

Re:Do companies really use Big Iron anymore?

[AK Marc]

I can't say only bad things about SAP. I was involved in the first purchase in a new SAP system at Avaya. Lets just say that 6 months late (mainly because SAP kept shipping the wrong things and not scheduling people for the install) we got $120,000 of equipment and install for $40,000. SAP couldn't ship the right thing, schedule things, or bill things. At least some of the errors were in our favor. "SAP" is a product like SQL is a product. You might as well go to Home Depot and buy a pile of lumber and a toilet and call it a house. That's about the state of most SAP deployments I've seen.

Re:Do companies really use Big Iron anymore?

[JDG1980]

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)

Anything involving money shouldn't be using floating point anyway. If the language doesn't have a built-in currency data type, the best way to store amounts of money is as an integer quantity of cents. (Of course, if you need mill-level precision, then store an integer quantity of mills instead.)

Re:Do companies really use Big Iron anymore?

[jampola]

Can someone please explain to me what SAP does that a well coded PHP (or any language) application cannot do?? I worked for a company that used to use SAP and I really don't understand what is so special.

It's not a rehtorical question, I honestly want to know what the advantage is of paying an expensive SAP developer over a cheaper PHP, JAVA or Whatever developer? a lot of SAP applications I've seen in action, I can honestly say I could've created the same thing in PHP or Java quite easily.

Re:Do companies really use Big Iron anymore?

[baegucb]

VM guests for Linux are what we use, and presumable most shops. z/OS, with UNIX file services does the bulk of the work though. We do have the specialized DB2 and Linux engines as well. You can get a Linux instance up and running in minutes.
For disk drives we have 130 TB in raid 5+1 emulating about 7300 3390 volumes, all mirrored at a backup site. The disk drives are in the same SANs used by the server people.

Re:Do companies really use Big Iron anymore?

[AK Marc]

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.

Re:Do companies really use Big Iron anymore?

[Forever Wondering]

VM guests for Linux are what we use, and presumable most shops. z/OS, with UNIX file services does the bulk of the work though. We do have the specialized DB2 and Linux engines as well. You can get a Linux instance up and running in minutes. For disk drives we have 130 TB in raid 5+1 emulating about 7300 3390 volumes, all mirrored at a backup site. The disk drives are in the same SANs used by the server people.

Although I asked the question about native, I was assuming guest mode. It makes more sense, because VM already has the drivers for the hardware. Porting a native driver to Linux is just extra work, particularly for "big iron" hardware. If Linux is "hypervisor aware" it can issue "diagnose" instructions ("hypervisor syscalls"???) to VM to be much more efficient.

I've even worked on an OS (circa 1978) that made full use of guest mode. The equivalent is to imagine that each Linux user process/group gets its own VM. Each Linux process is not scheduled by Linux, but by the hypervisor. The process is unaware that it's in a separate VM (and can not do guest OS operations). It's equivalent to a multicore machine where each core is a VM

Thus, if you had say 20 CMS users, 24 OS/VS1 instances, and a Linux instance with 10 users, ordinarily, the Linux users would be dividing up 1/25th of the available time (e.g. 1/250th per Linux user). However, with the approach I just described, each Linux user would have parity, so each would get 1/34th of the time, a better result.

BTW, my home desktop is 6TB with 3 disks in a raid 0 and I'm having a hard time filling it. Just curious, what does one do with 130TB?

Re:Do companies really use Big Iron anymore?

[Anonymous Coward]

Back in those days, we had something called "floppy discs". While these had a way higher latency (and far lower bandwidth), they did carry a lot of viruses. Also, a lot of company information illegally left the company using these. Just because there was a wire missing doesn't mean it was all safe.

Re:Do companies really use Big Iron anymore?

[wideglide]

... more likely 45 years and more. Working on an airline passenger support system (reservations, schedule & check-in ...) where the oldest parts still in use date back to spring 1967 ... dealing with weight of cargo & passengers and its distribution on the plane. And 95 % of the code base is assembly language with the rest C, now that's what I'd call a lean and mean environment !

Re:Do companies really use Big Iron anymore?

[MrNemesis]

Working in a company that ditched the last of its mainframes just as I arrived (and was lucky enough to get to talk to some of the awesome IBM techs who were decommissioning the hardware), this lovely excerpt from The Cryptonomicon is just as apropos for mainframes as it is for bandsaws and Vickers machine guns:

Now when Bobby Shaftoe had gone through high school, heâ(TM)d been slotted into a vocational track and ended up taking a lot of shop classes. A certain amount of his time was therefore, naturally, devoted to sawing large pieces of wood or metal into smaller pieces. Numerous saws were available in the shop for that purpose, some better than others. A sawing job that would be just ridiculously hard and lengthy using a hand saw would be accomplished with a power saw. Likewise, certain cuts and materials would cause the smaller power saws to overheat or seize up altogether and therefore called for larger power saws. But even with the biggest power saw in the shop, Bobby Shaftoe always got the sense that he was imposing some kind of stress on the machine. It would slow down when the blade contacted the material, it would vibrate, it would heat up, and if you pushed the material through too fast it would threaten to jam. But then one summer he worked in a mill where they had a bandsaw. The bandsaw, its supply of blades, its spare parts, maintenance supplies, special tools and manuals occupied a whole room. It was the only tool he had ever seen with infrastructure. It was the size of a car. The two wheels that drove the blade were giant eight-spoked things that looked to have been salvaged from steam locomotives. Its blades had to be manufactured from long rolls of blade-stuff by unreeling about half a mile of toothed ribbon, cutting it off, and carefully welding the cut ends together into a loop. When you hit the power switch, nothing would happen for a little while except that a subsonic vibration would slowly rise up out of the earth, as if a freight train were approaching from far away, and finally the blade would begin to move, building speed slowly but inexorably until the teeth disappeared and it became a bolt of pure hellish energy stretched taut between the table and the machinery above it. Anecdotes about accidents involving the bandsaw were told in hushed voices and not usually commingled with other industrial-accident anecdotes. Anyway, the most noteworthy thing about the bandsaw was that you could cut anything with it and not only did it do the job quickly and coolly but it didnâ(TM)t seem to notice that it was doing anything. It wasnâ(TM)t even aware that a human being was sliding a great big chunk of stuff through it. It never slowed down. Never heated up.

In Shaftoeâ(TM)s post-high-school experience he had found that guns had much in common with saws. Guns could fire bullets all right, but they kicked back and heated up, got dirty, and jammed eventually. They could fire bullets in other words, but it was a big deal for them, it placed a certain amount of stress on them, and they could not take that stress forever. But the Vickers in the back of this truck was to other guns as the bandsaw was to other saws. The Vickers was water-cooled. It actually had a fucking radiator on it. It had infrastructure, just like the bandsaw, and a whole crew of technicians to fuss over it. But once the damn thing was up and running, it could fire continuously for days as long as people kept scurrying up to it with more belts of ammunition. After Private Mikulski opened fire with the Vickers, some of the other Detachment 2702 men, eager to pitch in and do their bit, took potshots at those Germans with their rifles, but doing so made them feel so small and pathetic that they soon gave up and just took cover in the ditch and lit up cigarettes and watched the slow progress of the Vickersâ(TM) bullet-stream across the roadblock. Mikulski hosed down all of the German vehicles for a while, yawing the Vickers back and forth like a man playing a fire extinguisher against the b

Re:Do companies really use Big Iron anymore?

[jellomizer]

I think the high IO throughput, is one of the few things the old Mainframe people hold onto as to not have to relearn a new system.
It is one of those trade offs from going from a Mainframe Mind Set to a Distributed Computing mind set. Having worked and still working on mainframes I find that they are a mixed blessing, even old ones can handle amazing load much better then a Distributed System can. However there are a lot more processes that need to be ran as batch processing and not as much real time (In the terms you request for a small/medium amount of data and you get a response back in a few seconds or less) information.
As we move to more distributed models we are getting better at making programs that work with the lower IO throughput by doing more processing per system and giving more discrete answers back.

Re:Do companies really use Big Iron anymore?

[Hognoxious]

The city here adopted SAP to "save costs" and now has a department of 10+ "SAP Programmers" just to keep basic functionality running.

If you're spending significant effort programming on an SAP implementation, you're doing it wrong. Having said that, it's a common mistake.

Re:Do companies really use Big Iron anymore?

[Hognoxious]

SAP's use (as it is) is a merging of the front end and back end

SAP has been around since the front end was a green screen monitor. Your integration is out by 90 degrees, the strength was that you didn't need overnight interfaces (& duplicated data) between your sales system (written in PL/1), your accounting system (written in COBOL) etc etc etc.

In addition, most of the functionality you need is already programmed, it just needs the blocks sticking together. To liken it to a programming language is just ignorant.

Re:Do companies really use Big Iron anymore?

[Bill, Shooter of Bul]

No, that's why you design redundancy into your app. Turns out having twice as many servers for high availability is cheaper than just buying a server with hot swappable cpu's.

Re:Do companies really use Big Iron anymore?

[TheMathemagician]

There is no advantage! But many people in decision-making positions in companies do not act rationally. It may be preferable for them to be able to say to their bosses "I paid $$$ for support for this server product" rather than say "In the very unlikely event of a problem occurring the online spacemonkey community will have a patch within hours".

Re:Do companies really use Big Iron anymore?

[Hognoxious]

Can someone please explain to me what SAP does that a well coded PHP (or any language) application cannot do??

Nothing. However the key words are "well coded". SAP doesn't need coding - or rather any additional coding - to do it.

I worked for a company that used to use SAP and I really don't understand what is so special.

That's probably because you're comparing a packaged application to programming languages.

I could equally ask what's so special about PHP - couldn't you create a better language using yacc, C++ and assembler?

Re:Do companies really use Big Iron anymore?

[mcgrew]

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.

Concurrent book replacement

The System z9 supports nondisruptive processor replacement. That means a technician can replace an entire processor book without ending any applications and without restarting any operating systems. In most configurations a System z9 can even manage this feat without any reduction in performance or capacity for the running applications.

The pictures don't show the whole computer. I haven't seen a mainframe installation since a class in the late '90s. It was Illinois' Secretary of State's mainframe, the instructor was in charge of it and took us on a field trip. The actual computer took a whole very large room. Each of its 4 CPUs were the size of a fridge, memory and drives were in separate enclosures. Impressive. They had two natural gas generators for backup power in case the electricity went down.

My jaw was hanging all afternoon.

Re:Do companies really use Big Iron anymore?

[bored]

Except that the HP Blade cluster has nothing on the mainframe in terms of reliability and data integrity.

Got any real numbers to back that up?

No? Maybe its because most of the failures, on both are due to software instead of hardware. There is nothing magical about the software on a zseries. If anything it seems more likely for a system programmer to screw up some JCL and destroy something important, than for the esx administrator to accidentally delete an image.

Re:Do companies really use Big Iron anymore?

[bored]

Yes, you can pull the whole blade, if the application is cluster aware. Just about any modern DB can be run like this, as can your favorite web server. Most "enterprise" applications are designed to run in a loosely coupled environment.

Re:Do companies really use Big Iron anymore?

[bored]

Outside of BCD mechanisms, I think what you are trying to describe is called "decimal floating point", and is an IEEE standard. IBM likes to talk about decimal floating point, because even lowly x86 had BCD hardware support since day one (think AAA). IBM even likes to show benchmarks where their hardware DFP is faster than DFP using the same formats on intel. The problem is that DFP has a couple different storage mechanisms, and naturally IBM has compared the one were they do best against the one intel does worst at. In the end, apples to apples, they come out about the same. Surely not worth a 10x price difference for a few percent in IBM's favor, which ends up being application specific anyway.

Re:Do companies really use Big Iron anymore?

[zig007]

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 because they stem from law. Law is an utter mess of compromise, shortcuts and exceptions and as such very, very badly suited to provide the logical framework for an application. Still, it has to be applied when it is supposed to. Or incarceration will ensue.

For example, writing large functions is a definite no-no everywhere in development. It reduces unit testability and so much more.
However, in a financial applications, there are so many parameters and exceptions for everything that code becomes completely impossible to follow if you break if up like that.
However, that doesn't matter anyway since the complexity and fantastic amount of exceptions makes unit testing, though used of course, somewhat less effective. Most testing instead happens in the integration level.
It is very hard to optimize, and writing it in machine language would be quite insanely difficult. And off-the-charts silly.
Especially considering the efficiency of compilators of today.

In the old days systems were way simpler, had way less features(more of calculator replacements than systems) and was allowed to cost fortunes.

And juggling critical data in RAM is not something I'd suggest doing, the system has to keed serving clients and you need transactional support.
Even though such database engines exists, they are not normally used for these kinds of applications.

And NOTHING is inherently safe and productive. I assure you.

Re:Do companies really use Big Iron anymore?

[Sarten-X]

How the financial crisis happened is pretty straightforward. Banks foreclosed on loans, some of which were loans made to other banks. Those other banks then foreclosed on their loans so they could have funds available to cover their debts. Once the trend of foreclosure was identified, banks became worried about having enough available funds, and they increased their own foreclosures. This continued going down the chain until the foreclosures reached individuals, who were often unable to pay back their loans immediately. Since the individuals didn't have money, the banks couldn't repay their loans, and the failures went back up the chain.

Issuing those loans out wasn't wholly irresponsible, despite what the pundits like to say, because there had been significant continuous growth in the housing market for years. That growth offsets the risk that the loans will default, because there's enough cash floating around in the market that debtors can repayloans as needed. Under normal circumstances, such risky loans are fine, because any single failure will have minimal effect on the economy as a whole. What happened was a huge number of defaulted loans all at once, which had a cumulative effect.

Banks are worried about losing money. In the case of IT changes, they can accurately predict how much will be lost, when, and how. While it is possible to say "we are in a housing bubble", it's not possible to say "the bubble will burst next month" with any degree of accuracy. All investment carries risk. IT management carries less risk.

Re:Do companies really use Big Iron anymore?

[haruchai]

You completely left out the the MOST signficant part - the repackaging of marginal mortgages as AAA securities - some of which were resold over and over. There was staggering greed and collusion among leaders in an industry that is supposed to be conservative about risk. Loan defaults were the trigger but without those toxic collateralized debt objects, many of which had been sold overseas - again as SAFE investments, there would have still been something of a housing bubble bursting but certainly not a near-GLOBAL meltdown.

Re:Do companies really use Big Iron anymore?

[bws111]

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 running mixed IMS/CICS/DB2 workload?

Nobody spends a few million dollars on a mainframe based on some 'industry standard' benchmarks. Instead, they take their actual workload to IBM and try it on different configurations. There is no reason at all for IBM to run those benchmarks.

Re:Do companies really use Big Iron anymore?

[tibit]

Transactional support for payroll? What do you mean by that? You of course store ongoing concerns, like time-worked tracking, in a database of some sort, but calculation during a payroll run can be done in complete isolation and you don't need to run it on a database itself.

As for parameters and whatnot: it's not exactly a problem only common to finance, you'll see the same thing in say specialized CAD systems that support validation of a design to engineering codes. 50-60 parameters, even if those parameters are per-person, per-payroll-run, we're still talking about a meager amount of data, even if those parameters need 64 bit binary representation: 60*8 = 480 bytes. Meh. The functions that calculate stuff based on the parameters are of course common across the system, so that also has an O(1) cost in terms of storage per person, run, etc.

I'm not claiming that using C, COBOL, C#, Java, or what have you is all that great for expressing legal requirements, but that's not how you do it. Dealing properly (vs. cowboyishly) with such a system requires some formalized abstractions -- this, unfortunately, requires some hard-core computer science knowledge. In a nutshell, you translate legalese into some kind of small-step semantics, and then those get automatically translated into code, practically in a couple of steps. Each intermediate language is formally specified, and the code generators are formally verified to preserve semantics at each step. So, the ultimate generated machine code, if your generator system is done right, can be formally proven to preserve the semantics all the way from the input semantics to machine code running on the target architecture. That's about as much of butt covering as anyone could ever do, and I've recently seen this very approach very successfully applied in an engineering system -- where you start with engineering codes (law!), full of exceptions and silliness.

Re:Do companies really use Big Iron anymore?

[Sarten-X]

Repacking mortgages as a low-risk security is reasonable when it's expected that a certain (low) percentage will default, and the rest will grow enough to repay the debts. Get enough marginal mortgages together, and the package as a whole has a very low risk of failure. The risk of default for each individual mortgage was believed to be a mostly-independent event, with a fixed probability of default. When the foreclosure chain reaction started, the defaults were no longer independent. Suddenly, that wonderfully-low probability of total failure became terribly high, turning a safe asset into a toxic liability.

To use a suitably nerdy example, consider a RAID 1 array of disk drives. Discounting excessive rebuild time (as we are seeing now with multi-terabyte disks), the chance of total failure decreases as more drives are added to the array. With enough drives, the chance of failure drops down to any reasonable definition of "safe". Now, without warning, we'll assume that when a drive fails, it explodes in a spectacular fireball. Of course, this increases the chance of neighboring drives failing, and they'll also explode. Our nice safe RAID array is now wholly unreliable, and it's also likely to take out other equipment in the same room. Once the fire suppression system goes off, there will also be water damage, short-circuited equipment, and probably a few physical security breaches, as well. A simple drive failure would cause a site-wide meltdown.

Re:Do companies really use Big Iron anymore?

[haruchai]

If there were a reasonable chance of a Quantum Fireball scenario, a conservative, reliability-conscious enterprise would have processes in place to mitigate the impact ( of course, nothing is foolproof) but certainly wouldn't be actively undermining their own safety so that some employees would get a bigger paycheck or bonuses.

The financial industry, at several levels, worked DILIGENTLY to undermine every thing they should have learned from a century of meltdowns with the collusion of banks, mortgage lenders, credit rating agencies, etc.

Going back to your scenario, imagine that a few decent sized shops had a drive-related, site-wide meltdown then EMC, Samsung, Seagate, Underwriters Labs and Tyco Fire Suppression got together to make a greater number of failure-prone drives, falsify reliability stats, reduce the effectiveness and visibility of the storage management products and install mitigation systems that would actually cause a chain reaction throughout any industry that used any of their products.

Re:Do companies really use Big Iron anymore?

[marcel]

The only companies using mainframes that I know of have been using them since 1960. Benchmarks are irrelevant, legacy software is the prevailing driver for keeping the mainframe in house.

Re:Do companies really use Big Iron anymore?

[marcel]

The main problem however is that all your transactions will started on a Web2.0 site written in PHP on some old x86 machine before it is shipped of to the highly reliable platform. So it's actually quite useless in practice to have this capability.

Re:Do companies really use Big Iron anymore?

[zig007]

Actually, the problem is not singularly the calculation of the payroll which usually is nothing more than some reports. Of course, they might be heavy and all but database engines nowadays can really push data. It is about the fact that there are lots of similar stuff. Like when someone changes something historically, handling "tainting" and generate new accounting instructions. There are soo many use cases.
And you will do most of it in the database. Why? Because to not use set-based logic a la SQL when you handle huge amounts of data is not very smart.
If you wouldn't, you would have to dump ALL the data to the business layer structure and do advanced data operations like joins and so forth there.
Which, while obviously being possible, sucks and kills your mind. Also database client libraries consume lots of memory, and usually they are not the smartest memory allocators(because they don't have to be).
You will probably want to store states during execution and do it in parts, a huge batch either locks up the entire system for an unacceptable duration or makes you end up with a possibly corrupt dataset. Or at least not one you can always trust. So you cannot really do it in total isolation.
It is all in the little horrible details. Details that dawn on you when a system grow. Because it is all about detail.

No, really, there is nowhere else there are as many parameters and settings as in those cases where law is the logic.
The problem is also not their number, but the fact that they cut through abstraction levels the way they do.
Therefore problems often occurs just because you accidentally tried to do good. :-)
You really have to work with this kind of development for a while to realize its specifik set of problems.
On the contrary, the CAD example is one where you kan make beautifully generic code.

With regards to O calculations, they are not very useful in larger systems, they are great for evaluate algorithms. Systems are systems, and delays are far less about optimizing algorithms but knowing how databases indexing, database queries and their client libraries work, how memory is managed and doing stuff in the right order. Normally there are actually very few places where you do anything very advanced, algorithmically or mathematically(if we are talking about accounting).

Believe it or not, I have actually studied computer science and sorry, there are so many times one has to sidestep design principles in these cases.

To translate a syntax into logical constructs is really easy(ANTLR kicks aass, yay) . And actually, the language itself could be considered a programming language.
The problem is that all that haven't gotten you *anywhere* because law is about interpretation and systems about customer demands.
At some point, the law is interpreted, applied to your customers and translated into if...then...else.. . And you and your system will usually not be the ones that interprets it.
The driver is regulations and customer demand, and that often that translates into designing the system in such a way that it, for example generates the least taxation within the applicable legal constraints.
And here you just can't go wild with Monte Carlo simulations, but have to follow the usually very specific methods the certified accountant has specified as being OK. Compliance issues. And every larger customer has their own model...it is really problematic sometimes to try and cram them into the same system.

Building business systems is less about programming and more about system design, designing a system that can survive and even thrive containing with the madness it contains. Because it is by law required to contain it.

Re:Do companies really use Big Iron anymore?

[zig007]

Hm.
I would like to apologize for really sloppy writing in the parent article..strange grammar all over, there was.
A bit tired there.

Re:Do companies really use Big Iron anymore?

[bored]

Exactly, the question long term becomes, at what cost/transaction does it make sense to throw all that legacy software away, and recreate it on a system where the cost/transaction is significantly less.

You can hire a lot of programmer/hours to rewrite a system, using the cost savings going from a $1.5M/year to $120K/year system, over a life span of multiple decades.

Re:Do companies really use Big Iron anymore?

[cusco]

Non-Stop? You mean the Tandem Non-Stop Kernel that they inherited from Compaq and then abandoned for most of a decade? I'm surprised that it didn't go the way of the Alpha chip, sacrificed in the name of higher executive bonuses.

Re:Do companies really use Big Iron anymore?

[tehcyder]

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.

I don't follow your argument. If the cost of the invonvenience is less, then that is the correct business decision, surely?

Re:Do companies really use Big Iron anymore?

[Finite9]

Hehehe... Im not nay saying that your words aren't the utter truth, but it sort of reminds me of a joke I heard about the AV cable industry, where a customer buys a ~$7000 HDMI cable (they do exist), and has it delivered by "a shining white van with trimmings made of sheer gold, that comes floating down from the heavens, and as the delivery guy approaches the door in his shining white garment he appears to be floating above the ground..."

Your account will become the stuff of Legends. Do you think these guys still exist in todays golbalised market? God I would love to be part of that world, because where im at, we are a loong way from that kind of reality (in the infrastructure hosting business).

Re:Do companies really use Big Iron anymore?

[AK Marc]

The correct business decision would have been to select a product that would have better uptime and features at a lower cost.

Re:Do companies really use Big Iron anymore?

[baegucb]

Databases and documents (MQ and millions of docs I think), I guess, based on change reports I see. DB2, IMS, and Oracle databases. We really now only have one mainframe storage guy, who is close to retirement. Legacy mainframe etc., and I expect management will soon realize that.

And of course, all backed up and mirrored, and restores of datasets and files occur all the time.

Re:Do companies really use Big Iron anymore?

[haruchai]

SHHHH!!! Don't destroy the dreams of the mainframe grandpas - that's just mean-spirited of you.

Looking forward to the Ebay auctions...

[Tastecicles]

...can I get a mainframe for $5 shipped on BuyItNow?

(I wish!)

Re:Looking forward to the Ebay auctions...

[Anonymous Coward]

Did NASA own it? I thought the really big Irons were leased?

Re:Looking forward to the Ebay auctions...

[baegucb]

http://en.wikipedia.org/wiki/Hercules_(emulator)
It won't have the IO speed or uptime though, but it'll save you $5.

Re:Looking forward to the Ebay auctions...

[Tastecicles]

nice! So really the only reason to have a NASA mainframe is to stop a door from swinging closed (and bragging rights, of course)...

I'm not that desperate, if I wanted a doorstop (that I wouldn't break my foot on if I tried kicking it out the way) I would just fuck off to Cornwall and buy a serpentinite one.

Obligatory power down sequence

[Anonymous Coward]

Daisy..., daisy... give me our answer, do,
I'm half crazy for the love of you ...
[sounds fades away]

Re:Obligatory power down sequence

[MRe_nl]

I'm afraid I can't do that Linda...

Re:Obligatory power down sequence

[History's Coming To]

Dave...my mind is going....I can feel it....

I use that as a low-power alert on my netbook, it still freaks me out a little.

Re:Obligatory power down sequence

[grumling]

...But I still have a lot of confidence in the mission.

Distributed servers

[Neil_Brown]

all about space saving?

Re:Distributed servers

[Anonymous Coward]

They just depend on The Cloud. What could possibly go wrong with that?

Re:Distributed servers

[Anonymous Coward]

Or saving space?

But they still have the data center

[Animats]

NASA still has a big data center in Slidell, Louisiana. They're hiring. With the mainframes gone, one would expect they'd close down Slidell, but no. Instead, they're building a big museum and PR center there.

NASA seems to spend money at a relatively constant rate, independent of whether they're flying anything.

Re:But they still have the data center

[DesScorp]

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.

Re:But they still have the data center

[Anonymous Coward]

I agree that a government agency or any organization can continue to spend it's budget without accomplishing a particular function. That is basic human nature, along with kingdom building. However, I'm very uncomfortable with the notion of handing space launches to the military. It's all well and good that they have space defense capability, but I prefer at least a pretense at civilian management for our general space program.

Re:But they still have the data center

[Anonymous Coward]

NASA is flying an awful lot, just no longer one particular vehicle. But I guess that's an idea too complex for the slashdot brain trust.

Re:But they still have the data center

[mx b]

NASA works in that area with the Navy/NOAA. It may not be a strictly NASA data center. I know they do a lot of hurricane research, plus the gulf oil spill, etc. I guess NASA provides the satellites etc for use in research.

Re:But they still have the data center

[Anonymous Coward]

They've been as much as told there goal is to inspire people not actually get things done. So fire off the computer guys and hire some pr people to run there museum.

Re:But they still have the data center

[Shadowmist]

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.

NASA was created separate from the Air Force to maintain a propagandist fiction that America's activities in the Space Race were non-military in nature as opposed to the Soviets who made no such pretense. As to the unplugging of Big Iron...All I would say is that it's about time that NASA entered the 21st century of computing and left the 1960's.

the shiping fees are very high

[Joe_Dragon]

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.

Re:the shiping fees are very high

[davester666]

And you definitely don't want to 'upgrade' to Fedex shipping.

I would suggest you drive out and pick it up yourself.

Re:the shiping fees are very high

[Marillion]

To say nothing of the electric bill.

Re:Why stop there???

[spire3661]

The worst thing about the Space Shuttle is that it exposed how NASA is funded. Its not pure science, its 'pass work out to my friends first, space second". Politicians shouldnt be in charge of how NASA operates. If we could change the way we allocate money to NASA by appointing SCIENTIST-SENATORS ( this is not a fully formed thought, merely a recognition that lawyers are not scientists), then we might make some progress.

TFA

[ldapboy]

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

Re:Why stop there???

[Sarten-X]

Shockingly enough, there's more to space exploration than just putting people in it. There's analysis of radio telescope data, probes leaving our solar system, theoretical physics, simulated microgravity experiments, and an enormous number of other fields of research I simply don't know enough about to even know what they are. Discounting NASA because it doesn't currently have an operational vehicle is like saying that when your car breaks down, the rest of the world doesn't matter.

Re:Why stop there???

[Sir_Sri]

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:Why stop there???

[Anonymous Coward]

NASA was derived as a program for basic engineering, and a political venture. Did anyone think that the moon program was really about science?

Makes sense...

[sirwired]

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:Makes sense...

[DerekLyons]

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.

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.

Re:Makes sense...

[j_sp_r]

Wouldn't part inventory be a critical process for them that might need the reliability of a mainframe?

Re:Makes sense...

[Anonymous Coward]

You might be suprised to learn than their needs for informatics (information collection, sorting, searching, aggregating, transformation) is extremely high. Their data requirements, have historically been 1~2 orders of magnitude above enterprise.

Re:Makes sense...

[Anonymous Coward]

No. One of the main challenges for mainframes is to balance Reliability and Availability. If you're willing to negotiate on Availability, Reliability becomes a lot easier. Take for instance a RAID-5 array. If you have a defective disk, maximum Availability requires that you continue to run without redundancy, while maximum Reliability requires you to take down the array until it's rebuilt.

Part inventory doesn't require Availability per se, unless the underlying process does. (E.g. medical supply inventories might). The part inventories at NASA are used pre-launch, which means that worst-case you have to postpone a launch. That's probably an acceptable risk.

Are there emulators for mainframe code?

[wisebabo]

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?

[raburton]

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:Are there emulators for mainframe code?

[azgard]

Yes: http://www.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?

[interval1066]

Yes; http://www.turbohercules.com/. Near and dear to my heart is the CDC Cyber series on which I had to run my COBOL assignments at uni; http://members.iinet.net.au/~tom-hunter/. Anyone also do assignments on PDP 11/70's as I did also? http://www.dbit.com/. Christ, I bet there's an emulator for any platform and architecture that's existed.

Re:Are there emulators for mainframe code?

[GerryHattrick]

Well I loved my mainframe in the '60s. On the nightshift you could keep your cocao hot on top of the CPU, and if things went wrong you could try your hand at 'core alters' from the console (quicker than repunching some cards).

Re:Are there emulators for mainframe code?

[ToasterMonkey]

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:Are there emulators for mainframe code?

[cyber-vandal]

And yet all the new tech seems determined to reimplement mainframe tech but not as well.

Re:Are there emulators for mainframe code?

[emt377]

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:Are there emulators for mainframe code?

[Anonymous Coward]

Basic+... yesss....that was a powerful Basic. Remeber how the rsts/e file system stored data in clusters? And the default cluster size was 8 (whatevers? 8 segments or 8 blocks or whatever those were? So your file, even if it was on character in size took up 8 of those blocks? I wrote a program using rsts/e basic+ to compact multiple files into one of those clusters. Kind of like tar I guess. I was in high school at the time. Fun times hanging around the uni c-sci lab.

Re:Are there emulators for mainframe code?

[BoogieChile]

Oh yes...yesss there is, precious...

http://www.virtualapple.org/epochdisk.html

Re:Are there emulators for mainframe code?

[Anonymous Coward]

Edit a few lines of jcl and restart the abend at home.
Oh what fun.

Sucks as a boring job.

Re:Are there emulators for mainframe code?

[haruchai]

Geeks can only know and learn what they can get access to. For all the reliability, power and throughput of mainframes, they're not what made the Web

Re:Are there emulators for mainframe code?

[tgd]

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.

I think its an age and exposure thing. When I was in school (before a lot of /.ers were born, sadly... ugh, old), a particularly powerful example of the difference in how mainframes are thought about was when I was being shown a large VAX cluster. There were probably 2000 active terminal sessions on each of 3-4 VAXen. To make a point about the difference between the mainframe hardware and the Sun servers/workstations we also were running, the sysadmin grabbed the 3-phase power cord going into one of the VAX servers, gave it a little twist and unplugged it.

Without a hiccup, 2000 user sessions were migrated to the other servers mid-keystroke and the users in question never knew anything happened. We'd swap out hardware all the time. CPU being flaky? Pull the board out and replace it.

This is hardware designed for massive throughput, not massive performance. And 5 9's reliability would be considered a failure by any of the people running the systems. Anything less than 100% would be considered a failure.

I hate to harp on the age thing (get off my lawn!) but I think a big part of it is that kids today (and ten years ago!) don't have the opportunity to be exposed to "real" enterprise computing. The sort of computing that can singularly keep a company with 150,000 people running. Today, its all about acceptable downtime, virtualization for high availability, etc. Its okay if you have to restart your outlook because a server glitched. Its okay if connectivity drops -- you're not actively using the corporate systems most of the time. They're just there as resources to your workstation. People don't get fired when e-mail goes down for five minutes.

Its just a very different world now, and the things that made mainframes important are just not seen as important anymore. (And, IMO, that isn't because the environment for corporate IT has changed, but the new-guard running it doesn't prioritize things the same way *and* there's a lot more IT around... a 3000 person company isn't likely to have that kind of infrastructure, even if it was necessary.)

Re:Are there emulators for mainframe code?

[Anonymous Coward]

Yeah, that's all we're trying to do. Computing was so much better in the 60s, it's not like we've advanced so many orders of magnitude beyond it or anything. It was all great back when you could still get laid! Just like music, TV, and how black people knew their place.

No mainframe = shuttered data center? Huh?

[sirwired]

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.

Ooooh!!

[Anonymous Coward]

Hand-me-down computers! Can I have it??

Could have just waited

[kefkahax]

If they just tried to leave it running it would've powered itself down eventually.

Re:Could have just waited

[Kittenman]

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

[gbjbaanb]

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:Could have just waited

[kefkahax]

It was just a generic anti-IBM comment.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:No mainframe = shuttered data center? Huh?

[NEDHead]

Perhaps it could fit in your living room, but I bet it would block the view of the stripper pole

FSW SPF Mainframe Shutdown was July 29th 2011

[Anonymous Coward]

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.

iPads

[Anonymous Coward]

The whole space agency is being run on iPads. I mean you haven't downloaded the NASA app yet?

Remember the Tao...

[Anonymous Coward]

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.

Re:Remember the Tao...

[Anonymous Coward]

Ohh... That was moving.

Re:No mainframe = shuttered data center? Huh?

[Spliffster]

just undoing misplaced mod points.

NASA ... WTF?

[Anonymous Coward]

What the fuck are they using then? An iPad?

Re:NASA ... WTF?

[sandytaru]

Blade clusters. Back when I did marketing for one of the other big companies, that's what we sold them. Racks and racks of blades, running virtual servers.

Re:Why stop there???

[0123456]

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.

These kids ...

[Grindalf]

I get the intuition that these kids don't know what one is, never mind how to use it.

Re:Why stop there???

[Deus.1.01]

Or you can just give them a constitutional standard which sets the course and prevent the politicians from making direct decisions.

yes

[nurb432]

Yes, mainframes are still used. They still have their place in the world.

Re:Why stop there???

[crankyspice]

a recognition that lawyers are not scientists

I may need to draw you a Venn diagram (and then, based on your 8-digit UID, explain, patiently, what a Venn diagram is ;)), but, this lawyer is a member of Tau Beta Pi and has personally helped design, assemble, and been a "core team" member on static engine tests and launches of, CALVEIN lifters...

Did you read either link?

[DerekLyons]

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.

Great....

[Anonymous Coward]

"[...]Marshall Space Flight Center powered down NASA's last mainframe, the IBM Z9 Mainframe."

  Great. Now the Cylons will be all over us.

Re:Why stop there???

[benthurston27]

no eight is the one that looks like a venn diagram on its side. he has seven digits in his uid which is like an L upside down and backwards and one less than eight.

decommissioned computers

[slick7]

Decommissioned computers for whom?

Re:No mainframe = shuttered data center? Huh?

[shiftless]

Not if the stripper pole is properly placed as the central attraction, with mainframe pieces and server hardware installed tastefully around the room perimeter.

I'm guessing they didn't cover this in your Living Room Datacenter Engineering (for Bachelors) 201 course?

Is a IBM 4Pi a mainframe?

[AbrasiveCat]

Well until the shuttle system went in to retirement the shuttles themselves were running IBM 4Pi computers (AP-101s I think). These are descendants of IBM System/360 computers. I wonder if these would count as mainframes. Actually I am not sure of the definition of a mainframe. Would a System/360-20 be a mainframe?

Re:Is a IBM 4Pi a mainframe?

[baegucb]

System 360 was a mainframe computer 40 years ago. I doubt the IBM 4Pi is related. Very very very doubtful. They have different purposes and sizes and likely OS's. It's funny to even think of it.

Re:Is a IBM 4Pi a mainframe?

[baegucb]

Actually, to reply to myself, I looked around a bit. NASA and wiki say the IBM 4Pi is a derivative of the 360. But without the capabilty of the mainframe. IBM is famous for salesmen. It was likely marketed as such to NASA. What they probably got was a 360 with the circruitry all replaced, anything to do with IO removed, and a panel of blinking lights and switches (which can do work just as the Altair).

Re:Is a IBM 4Pi a mainframe?

[kenaaker]

I worked in Houston on the Shuttle software verification simulator from 1982 to 1984. The simulator was about 4.5 million lines of 370 BAL and was connected to a redundant set of Shuttle flight computers (AP-101s) through 2 system 370 channels, one for inbound data and one for (mostly) outbound data. The IBM 3033 had been installed shortly before I started in Houston and was a replacement for the IBM System 360 Mod 75's that had run the Apollo missions. The mod 75s were serial numbers 1, 4, and 5 (if I remember correctly). The machine with serial number one was given to the Smithsonian, so you may be able to see it there.

The AP-101's were space qualified, radiation hardened, pieces of hardware with core memory that booted off a mag tape. It had 64K 32 bit words of main memory and 128K 32 bit words of instruction memory. The Primary Avionics Software System was written in a language called HAL/S (The reference book is sitting on my desk now). There was an Assembler kernel that supported the PASS. I wouldn't say the AP-101 was related to the System 360 except that it was register based.

The purpose of mainframes is...

[Anonymous Coward]

The purpose of mainframes is to sell expensive kit to managers who measure power by size of box. Big box, oooo must be powerful.

I am a geek, I programmed mainframes at Ford, they are not faster by a long chalk than PCs, they do not have more storage, they are definitely not more reliable. A lot of the tech in a mainframe is simply taken from the PC world! They don't make special drives for mainframes, or special ram for mainframes.

What they are is expensive, big, and sold as having some mystery properties which only 'true geeks' get. Do you believe in fairies? If you don't believe in fairies I can't sell you this box that's 100 times the price.

IBM told us the box has near as damn it 100% uptime. It doesn't, the software crashes a lot, but when the software crashes, another instance is started. Except it has goldfish memory, it crashes, the next instance has the data to the last checkpoint, so you can't rely on the instance you're talking to working as expected, it may suddenly drop back to a previous state.

Hey, but 100% uptime!

And it runs software, well sort of, it can run very slow Linux timeslices, but if you take too much processing, your process will be killed losing your data. The key point is to save everything and don't make the mainframe look underpowered or your process will be labelled a power hog and killed.

At Ford we were required to run our software on the mainframe in the data center for company political reasons. In reality we ran a fake shim on the mainframe and did the real crunching on the PC the mainframe was talking to. Simply because the PC could process the data for a days worth of orders in 30 minutes or so, and the Mainframe linux slice takes 2-3 days per days worth of orders and that's just not viable.

But hey, 'fairies', yeh I get it!

In ~1992...

[billybob_jcv]

...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:Why stop there???

[haruchai]

That didn't work so well for the Postal Service, did it. If you have fuckwads with clout and an agenda, except to finds their wads up in your business.

Dave?

[Sinn3d]

Just what do you think you're doing, Dave?

(sound of airlocks popping open on the ISS)

Repurposed

[ThatsNotPudding]

With the mainframes gone, one would expect they'd close down Slidell, but no. Instead, they're building a big museum and PR center there.

these mainframes will be repurposed for the advanced study of Porkbarrel politics.

IBM still there, moving to different iron

[Anonymous Coward]

They have moved a bunch of workload to POWER7 machines with AIX and/or Linux. Know that for fact.

The "mainframe" System z might not be needed but POWER7 machines and AIX very much are a part of the deal. The Big Iron has just moved to a different type of iron.

I'll bet whoever

[Anonymous Coward]

unplugged it is in deep shit