Slashdot Mirror
The Mainframe Still Lives!
coondoggie passed us a NetworkWorld blog post about the incredible rock-em-sock-em mainframe. Knocked frequently in recent years, the site notes that IBM's workhorse continues to do important work in a number of enterprise environments. "While there are some out there who'd like to see its demise, a true threat to the Big Iron has never really amounted to much. Even today, the proponents of commodity boxes offering less expensive x86/x64 or RISC technologies say the mainframe is doomed. But the facts say otherwise. For example, IBM recently said the mainframe has achieved three consecutive quarters of growth, marked by new customers choosing the platform for the first time and existing customers adding new workloads, such as Linux and Java applications."
My two AS/400s keep chugging along. They have never screwed up when they have been needed. With every other type of computer I've worked with, there has always been a case that I've gotten screwed by them. But those two old IBM mini-mainframes just do what they're told, so I'm happy.
Besides, I love the sounds of IPL'ing one of those monsters.
Hardware quality is the key here. It may not matter, if the application is even 30% faster on x86. But if the motherboard is buggy, or the parallel port is flaky, or cable can fluctuate, or the video card can get loose (early AGPs anyone?) — it is death. Even if the probability of it ever happening is very low, the costs will be devastating. Thus the expectation (probabilty times cost) of the loss is still lower than the cost.
I've heard of machines, where the CPUs or memory can be replaced without shutting down — 15 years ago (Sequoia)... Meanwhile, some controllers and OSes still don't fully support hard-disk replacement, or even network cable unplugging — today...
In Soviet Washington the swamp drains you.
Why would anyone want to see the demise of the mainframe, or any other particular technology?
Because they're a burden to maintain, but have developed "traction" because they've invaded every part of a business.
I don't do mainframe stuff (and hope I never will), but the little I've heard is ugly. Ancient COBOL (yick) code written 40 years ago running on a dinosaur OS.
AccountKiller
Seriously, at what point does a large, highly redundant server become a mainframe? (Yes, I've checked the Wikipedia article and somewhat out-of-date FOLDOC definition.
Or is the definition merely, "any large computer descended from one of the old-guard mainframes?"
The US free market: two halves of a government-granted duopoly are free to set the market price.
All that still exists for VMS, and it runs on Itanium. There is some serious work being done on getting it to run on Opertion as well.
What they have failed to do is avertize properly so people know what it can do and what it cannot.
Never answer an anonymous letter. - Yogi Berra
Mainframes have been running VMs for years.
Years? More like decades. IBM more or less invented virtualization back in the 60s for the System/390, and it lives on today as z/VM.
For the record, HP will still sell you OpenVMS systems. The OS runs on VAX, Alpha and Itanium, although I believe they only ship Itanium these days. They're still popular amongst banks, I'm told.
I am TheRaven on Soylent News
So why not upgrade the OS to a supported version? If your hardware is recently purchased/new, it probably cannot even run too many releases of unsupported operating systems anyway. And all the latest IBM operating system versions run on all the mainframe models stretching back to the end of 2000 (three generations). IBM always has a lot of overlap.
If you have z/OS V1.x, the upgrade to 1.8 or (soon) 1.9 is free. If you have OS/390 still -- hard to imagine on recently purchased/new hardware since it doesn't run on the z9 anyway -- the upgrade to z/OS is probably better than free (i.e. you typically save money), and you usually save money on the other software that runs on z/OS. (z/OS introduced subcapacity licensing.) And you have a full year when you can run both on the same system for no additional charge to get the migration done.
An OS upgrade is extremely unlikely to break any applications. There's 40+ year old code that's still running, right along with 64-bit Java code written an hour ago. Your 17 to 18 year old code should be perfectly happy on the new OS. And here's a radical notion: you can actually change your code if you wish. You know, add features and functions. You're allowed to do that. :-) You run code as long as it has value on the mainframe, for as long as you wish, without the vendor saying, "Sorry, that code must die this year." Just keep your OS and middleware on at least relatively recent releases, that's all -- it's backward compatible. Change your code and add code as you want, when you want.
We are one of the new mainframe customers out there. We are actually in transition. Running hundreds of Linux servers is less efficient for our workload and application type than a few large-scale 'big-iron' systems. Not that a cluster of Linux servers couldn't beat the big box, our engineers just can't hack it. It is HARD writing applications that scale well across hundreds of totally unique systems. More often than not our software boys have created islands or pockets of computing regions in the cluster - so it no longer is a cluster. It's just a bunch of stand-alone servers. In this scenario (bad programmers) we can mask a lot of the poor design by consolidating the workload up instead of scaling out. I would prefer they'd fix the code. However, you can't tell a software engineer he's wrong - it gets ugly fast. I admit that the process is 'broken' when compared to some ideal business standard. The truth is, it's like this at a lot of companies.
:)
As a system administrator, I wish I had a few big-iron boxes to babysit rather than hundreds of smaller ones. There are dozens of reasons why the mainframe is easier to manage and deal with. There has been years and years of engineering that has gone in to these things. They are on a different level.
The downside is that we will probably have to have a 'work-force reduction' due to the decreased demands of the hardware support team. It is an ugly but necessary part of a capitalist work force. I'm keeping my resume up to date - just incase.
It's true the AS/400 is an expensive platform. It's also true you save money every year because you don't need sysadmin's or DBA's (at all at the low to medium end and much less at the upper end). Additionally, in my experience with similar workloads between AS/400 and PC servers, you need lots of PC servers to match the throughput in OLTP applications.
I think when you balance these things, the AS/400 is much less expensive than it may seem when you are buying disk or memory at extremely high prices.
openVMS
+1 Mod parent up.
RAIS is great idea call me when they have invisible failover. The only company I know of doing this with PC hardware is Stratus. I'm talking about not losing any processing due to a machine or OS borking. I'm serious if you have this then the problem is solved.
Last time I looked the Linux/HA and all other projects had some serious issues with failover, there always seemed to be a single machine at some stage that could take the cluster away from the user.
The AS/400 like the mainframes has been built to be reliable. Hardware costs because it's specced not to fail, redundancy on everything is available. Not to sure about a processor failure on the As/400 though, might still be able to take the machine down. But everything else failsover cleanly.
So what have you?
The main reason companies have decided to move off mainframes has more to do with extravagant licensing fees than anything else. Well-written mainframe software (even old Fortran or COBOL stuff) is no harder to maintain than newer stuff, and it's often much less susceptable to things like memory overflows and the like.
That's one problem with hearsay -- it can sometimes be accurate, but sometimes wildly offbase. :-)
Almost all of our mainframe stuff is Fortran with some MASM and other languages thrown in, but we're not using IBM mainframe, either (our older stuff is all running on Unisys big iron).
I've played on mainframes professionally now for 18 years (19 years in August!), and I love the history of the platform as well as the relatively bulletproof application environment I get to work in. If only we had some of the same tools on Solaris!
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
And don't forget that Unisys still maintains and sells descendants of both the old Sperry UNIVAC 1100-series mainframe line and the Burroughs MCP-based A-series mainframe boxes (both are part of their Clearpath mainframe line). Both are quite dissimilar from IBM's in terms of architecture and software, but each is quite similar to IBM's big iron in terms of basic capablities.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Think again. I used to work on a large flight operations mainframe application that powers one of the largest US airlines (actually two, I think, if UAL is still running UNIMATIC), and while some of the code sucked, most of it was easy to maintain, and the application was (and is) both efficient and well-liked by the folks who use it.
The main issue with management wanting to leave the mainframe environment centers around licensing fees, not software quality, maintainability, or performance.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Itaniums have microcode? And it can be changed to run z/Architecture instructions rather than IA-64^WItanium instructions? That's news to me....
Or do they, instead, do binary-to-binary translation of z/Architecture instructions to Itanium instructions in software? The Information Week article on the IBM lawsuit quotes the IBM lawsuit as saying that's what they do:
I've always heard it referred to as a midrange system.
All modern mainframes (since at least 2000) can run the latest Java(TM): it's a standard, no extra charge feature in z/OS (the flagship operating system among the 5 available, Linux being another). So if you're running Java on the mainframe accessing DB2 on the mainframe you're going to see a much different number. (That's typically using something called JZOS, by the way, for Java batch programs. JZOS is free with z/OS, too.)
If it's J2EE (e.g. WebSphere Application Server for z/OS) then you'd typically be using the Type 2 JDBC driver to access DB2. As least as far as Java goes, that database access path is fast and tight.
In the modern mainframe (since 2004), your Java can run on a special Java accelerator called a zAAP. You turn on the zAAP on your z9 (latest model) or z890/z990 (prior generation model) and you pay zero extra (that'd be $0) for software but suddenly about 75% (give or take) of your WebSphere processing shifts over to the zAAP(s). The capacity you had been using on the main processors is now free for other work, or you can cap it and pay less for software, or buy less of it in the first place, or some combination.
So, yes, COBOL code accessing DB2 locally is fast, and Java code accessing DB2 over the network is slower. But Java code accessing DB2 locally is at least much closer to COBOL. You have choices.
considering the 24-way, 20tb disk, and 10g memory monster in the room next to me. Its got a cousin in another state as well.
AS/400s are essentially mainframes now. The next generation of iSeries will run the same processors as the zSeries. They already share a HMC and a lot of basic hardware.
We have a shop with multiple AS/400s, a zSeries, couple of xSeries, a Tandem, and a whole mess of PCs. The only systems we have downtime with are PCs. The network goes down, Notes server dies or locks up, etc. As such the Notes server is being moved to an AS/400 because we cannot afford downtime even for e-mail.
PCs look attractive because of their individual price. When setting up enough of them to do the same work they start getting expensive in base cost, power, and cooling. The other big factor in our use of AS/400s is that with over 80 of them we only have one primary Administrator and 3 back ups. Our Network support department (supports just managing the network servers and such) is larger and busier!
Mainframes (inc AS/400s) are here to stay because they just work. They nearly run themselves and that counts for a lot. You cannot underestimate the greatness of a system when people don't have to tweak or manage them daily - mostly because it seems to encourage some people to manage/tweak systems into downtime
* Winners compare their achievements to their goals, losers compare theirs to that of others.
To be more accurate (or rather complement the previous post), the first virtualization installment was probably CP67/CMS which ran on a S/360 Model 67... Which was a ca. 1967 machine (so we are talking 40 Years)..
The first implementation that went out to customers was VM/370 (which required an almost complete rewrite) on the DAT (Dynamic Address Translation) capable S/370 models (which means almost all S/370 models). This is ca. 1972 or 1973..
Note that not ALL mainframe require(d) raised floor and air conditioning.. The 9370 line of systems could run in office space (but does it qualify as a mainframe ?)..
And of course, some models (notably the 308x and 3090 systems) required water cooling and industrial power..
--Ivan
That's news to me, and it would surely surprise my current and multiple former employers (all of which still heavily use either current OS2200 or current MCP mainframes from Unisys).
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
The Alpha processors took things to the next level.
Q: Who made the first 1Ghz CPU? Intel?
A: Nope. It was DEC that made the first 1Ghz CPU. It was one of the early Alpha processors.
Some of the Alpha features live on in AMD processors and are designed by ex-DEC hardware engineers.
Having said that, DEC never produced a 'mainframe' system, not even the ill-fated 9000 series.
Without the 2nd Amendment, the others are just suggestions.
Multiple CPUs? Not traditionally. There were multiple processors, but usually one CPU and a bunch of I/O processors (also called channel processors.) The channel processors were similar to the kinds of RAID processors you'd plug into your PCI bus, or network cards (back when you used separate network cards that tried to be intelligent and off-load work from the CPU, as opposed to having them built into the motherboard.)
Multiple access mechanisms? Traditionally you had terminals controlled by a 3745 or similar front-end processor, which was channel-attached to the mainframe, and maybe a network protocol. SNA was ugly and hierarchical, basically letting each mainframe think that it was the only computer in the world and the computer at the other end was some peripheral device - and the protocols that preceded it, like bisync, were either uglier or dumber or both. (To give it some slack, it was made to run on terminal controllers that were about as bright as digital watches...)
Error detection and correction? Mostly that was a database function, and some of the database protocols gave you really good rewind capability, but traditionally you weren't rewinding the CPU, you were rolling back the database and restarting the batch process.
Multiprogramming and parallelism? Not particularly on a user level. The system did let you have multiple users running at the same time, and gave you some fairly fine-grained control over who got what fraction of the resources, but it was a lot clunkier than something like Unix timesharing.
These were some mean nasty ugly machines
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks