The Mainframe World Is Alive, Even For Those Under 40 361
willdavid writes with a link to a report by Jeff Gould at Interop Systems, about the definitely-still-around world of mainframe computing, from which he extracts:
"Last week I had the occasion to visit SHARE, the premier mainframe conference, which was held in San Jose just down the road from where I live.
Based on what I saw, there is one thing I can tell you for sure, and that is that Cobol is not dead. And neither is the mainframe.
When I mentioned to one of my friends that I had been to SHARE, he joked that it must have looked like an AARP convention. But this turned out not to be so. While there were certainly a few 60-somethings strolling around the halls, the under 40 generation was also well represented. What struck me the most was not the advanced age of the people but the relative youth of a lot of the software being discussed."
However, it's not all fountain of youth there, either. (Thanks, BDPrime.)
The good ole days (Score:3, Interesting)
Re: (Score:3, Informative)
Man would I love to install Linux in a virtual machine. I'll bet it could fly.
Google for "penguin farm ibm".
-1 Recursive citation (Score:5, Funny)
Has anyone actually done this? For me, Google returns exactly one hit -- your comment [google.co.uk]. Nice googlewhack, but not exactly a valid citation.
(ooohh, you mean without the quotes!)
Re:The good ole days (Score:4, Informative)
Are you aware that Linux competes with z/OS among IBM Mainframe products? IBM will happily deliver a system z with Linux.
z/OS as a dinosaur (Score:5, Informative)
z/OS is an upgrade of OS390, but yes - it has something called UNIX System Services, which is POSIX compliant but not as friendly as LINUX.
It's not that z/OS fights changes, exactly. Windows is crufty because it has to run MS-DOS programs from the eighties. z/OS has to run programs from the sixties, and do it with a high degree of reliability.
Disclosure: I am an IBM employee and the author of a mainframe book [amazon.com].
Mod parent up (Score:3, Interesting)
Mod parent up - he's on the mark. There's a lot of stuff out there for which the source is gone, but it still does the job. Witness the State of California's payroll system we were discussing a bit back.
z/OS ISN'T a dinosaur (Score:5, Insightful)
Dinosaurs are extinct. IBM mainframes are more like alligators or crocodiles or sharks... mostly unchanged from, and still closely related to, it's dinosaur-era ancestors, but still alive because it's so effective at what it does. Like those animals, mainframes still are the undisputed ruler of their part of the kingdom.
When we're old... hell, when we're dead... we'll likely still have something like Slashdot, with people saying "the mainframe will die any day now".
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It can be interesting, but I found all kinds of performance oddities when we had a Linux slice on a mainframe. It certainly didn't help that they initially set it up with only 64MB of RAM!
What with problems getting modules installed, we eventually decided it would be easier on ourselves to go back to a gray box under a desk. We may go with a VMWare based linux install to get proper internal corporate support, since nobody wants to put in a simple server anymore.
Re: (Score:2)
Not surprising.... (Score:5, Insightful)
The ol' yellow number 2 pencil is still around as well, as is shoe-making, wine-barrel repair, and of course the oldest tool in the book ... the tool.
Like humans all technologies find their place in the universe. Mainframes have their advantages, just would not want one sitting on my lap.
Re: (Score:2)
Mainframes have their advantages, just would not want one sitting on my lap.
Somewhere in there is a joke about fembots and the Crushinator, but I'm too lazy to find it.
Re: (Score:2, Funny)
I think you'll find the tool is a class, not an object.
Re:Not surprising.... (Score:4, Funny)
I think you'll find that tool is slang for penis.
Re:Not surprising.... (Score:4, Interesting)
Perhaps you are not familiar with what a modern day large server is capable of. The cost/benefit of larger systems doesn't work in every case, but in many cases it does. Not every application is suited to run on a cluster of low cost x86 systems.
My favorite large server is the HP superdome. Check out some of the specs:
- Up to 128 core.
- Up to 2TB of RAM, usually you'd mirror this, so 1TB usable realistically.
- Up to 192 PCI-X slots.
- 12 power supplies.
- 18 fans.
- Partition the system up to 16 different ways.
- Up to 32 GB/s IO bandwidth.
- 273.1 GB/s memory bandwidth.
- Cost, starts around $1,000,000 (last I asked).
- Jump the CPU/RAM/IO around to different partitions as needed, without rebooting anything.
The thing about this that is unlike your typical entry level x86 Enterprise server - EVERYTHING is hot swap. And I mean everything. CPUs, RAM, IO. Very few pieces require a complete shutdown to service.
My favorite mainframe story: "A guy called to ask what procedure he should follow to reboot his mainframe. Tech support told him to just follow the same procedure he did last time. The guy responded, "but only knows how to do that." And so, tech support said "well, get him to do it." At which point the guy remarked: "Well, the problem is he quit 6 years ago."
Yeah. When you need _UPTIME_ it is hard to do better.
Re:Not surprising.... (Score:5, Funny)
Yeah, but look at the spec that counts.
HP's top of the line barely weighs over a ton, whereas IBM's top Z box weighs a little over two!
Not so smart now, huh, HP?
Re: (Score:3, Interesting)
It's very impressive that all the hardware is hot-swappable. Unfortunately, that doesn't mean you will never have downtime. You need the right software for that, too. It either needs to be hot-updatable, or you need redundancy. Redundancy is the more realistic...and if you have that, anyway, why do you still need 99.999999% uptime hardware? In the end, your uptime is determined by the weakest link.
Re:Not surprising.... (Score:5, Insightful)
As far as the general principle of operation is concerned, your average nuclear (or coal/natural gas/oil, for that matter) power plant is a huge steam engine attached to a generator. Sure, it uses a turbine instead of a piston, but there AFAIK were some attempts at a turbine-based steam engine of a more typical size and use, they just came too late for the techology to be used for transportation. So it got to be used for generating electricity on a massive scale.
Re:Not surprising.... (Score:5, Insightful)
It is amazing how few people realize how much of our society still uses steam. You forgot geothermal, and some forms of solar plants.
Dont forget how pretty much any dense urban area is heated by a very large steam boiler and a large network of steam pipes. It isn't just a special effect in movies... those rising steam clouds from manholes really do come from buried steam pipes (though they really shouldn't be leaking steam).
Steam is where it is at baby! It came before computers and will probably outlast them in the future.
Nuclear and Steam (Score:5, Insightful)
"It is amazing how few people realize how much of our society still uses steam. You forgot geothermal, and some forms of solar plants."
Yup. Back when I was in the Navy, and I got to my first ship, a nuclear carrier, I thought nuclear power was this gee-whiz technology; if you don't know any better, you'd be inclined to think that "nuclear power" is turning those propellers... via protons, electrons, ray-guns, something sci-fi like that. When a nuke machinist mate explained how it really worked, I was kind of shocked. Basically, all we had was a steam engine, where the heat came from a reactor instead of coal. Same process, just a different heating fuel. Since those days two decades ago, I've become fascinated by just how much "advanced technology" that we use is really nothing more than barely improved methods our ancestors used. Jet engines? Nothing more than prop engines with the fans on the inside and some ignited fuel in the exhaust. Ultra-modern rifles like M-16A4's and AUG and the L86? Working from the same priciples as rifles hundreds of years old. Hell, car engines are noting but a hunk of iron with a series of explosions in them.
Technology most of the time is really nothing more than a machine that takes advantage of some principle of nature, and is often very, very simple at it's core.
Re:Nuclear and Steam (Score:4, Interesting)
http://www.kirsner.org/pages/jackSteam/jackSteamTextAlt.html [kirsner.org]
Re: (Score:3, Insightful)
Well, an old prop and a jet engine are quite fundamentally different, as piston engines are still quite different to turbines. Of course, all turboprops, jets, and turbofans are based on the same turbine principals.
Re: (Score:2, Interesting)
There are some things COBOL will do better than any other language.
First, it can run through millions and millions of records very quickly. I expect that most payroll systems are done in COBOL. I can't imagine anyone doing it one in C or Java.
The language may be simple but I have not seen any other language that can slice and dice data as easily. But you have to be careful because the type checking is done at 3am when they are running production jobs!
Re:Not surprising.... (Score:5, Informative)
Re:BCD? (Score:4, Informative)
Re: (Score:3, Informative)
Steam engine? Why yes, but now they call them 'Power Plants'. Most still use coal, but there are a lot of natural gas powered ones, and a few nuclear powered ones.
Re:Not surprising.... (Score:5, Informative)
Not really. Seen any steam engines lately?
Yes, I have. 80% of the electrity generated in the United States is done by steam engine. Coal and nuclear power both use steam engines.
Just because YOU are unfamiliar with a technology, that doesn't mean it isn't being used. And thank you for clearly demonstrating that point.
Re: (Score:3, Informative)
Mainframes are far more fault tolerant than any server. A cluster of servers has fault tolerance, yes, but it a bit harder to manage. Mainframes Just Work for the most part...oh and yes you can run Linux on them.
Re: (Score:3, Insightful)
How about a design where you have three CPUs, each running the same software on the same data, and if one gives a different answer, that CPU gets taken offline and support paged automatically to replace it?
Build it at a higher level. Three separate PCs, each running the same software on the same data, and if one gives a different answer, the entire machine gets taken offline and support paged.
The difference is, three PCs can be had for less than three thousand dollars, new, even with monitors and such. How much will one mainframe cost you?
How about a design that lets you run applications 24 hours a day, 7 days a week, with no downtime required for system upgrades?
Does Google qualify? How about Amazon?
There are areas where mainframes eat Unix systems for lunch.
Only if there's an irrational need for it to be exactly one machine.
Which, if it is, what happens if, say, that building explodes?
Disclaimer: I work for IBM
I'll
Re:Not surprising.... (Score:5, Insightful)
The difference is, three PCs can be had for less than three thousand dollars, new, even with monitors and such. How much will one mainframe cost you?
Are we counting the effort your team put into making these PCs work reliably in parallel, and the orders of magnitude more complex a cluster of discrete PC's is? Are we counting all the communications and storage networking infrastructure, and staff to support a cluster of PC's?
Only if there's an irrational need for it to be exactly one machine.
Obviously, where there is a single point of failure, you get a backup. ;)
Mainframes are no different. A DR plan for a mainframe doesn't say "move the smoldering remains of our only mainframe to the alternate site and call tech support." That's a silly notion, that mainframes repel each other somehow, or cut the heads off other mainframes so there can be only one.
Cluster of PC's > Mainframe is a flawed argument.
You might as well say buying a couple quarts of oil is better than going to Jiffy Lube.
You're shifting the integration work onto yourself. Even if someday you can just roll a giant PC cluster out the box, fully integrated, with the same features a mainframe provides, I think you'll find that the overall cost differential will not be very high. Then you have to figure out how to make them do work.
I'll add a disclaimer, too: I work on a project which is currently deployed via Amazon EC2.
So now you're talking about leasing time/resources on someone else's cluster environment, skipping the infrastructure ENTIRELY, so we're left with the "make it do work" part.
Now, I'm not trying to tell you a mainframe is cheaper than just three PC's, even after all is said and done, it'll probably cost more. If you look at the resources a mainframe or large integrated system provides, it would take more than a few PC's to match though. Back to DR for a sec, considering the infrastructure to support a good sized PC cluster, how would that affect your DR planning?
See, there are times when buying a couple quarts of oil is more appropriate, and times when going to Jiffy Lube are more appropriate ;)
Wiki was obviously wrong... (Score:5, Interesting)
Can somebody please explain to me what the hell a "mainframe" is/was for and why it might be dead?
According to Wikipedia [wikipedia.org], Mainframes are a bit like supercomputers but better suited to tasks where there's a LOT of input/output data, but not a lot of calculation involved. Payrolls and such.
As far as I'm aware, those tasks still exist today, probably moreso than in the 1970's and 1980's, so why would the Mainframe be dying out? Have regular desktop/server processors advanced faster than demand for this data calculation and thus are now simply adequate or is this article just a bit of FUD to make 'ol timmy look like he's doing his job?
FYI: I'm most certainly under 40. In fact, I'm barely more than half that age, so excuse my ignorance on the subject; the only times I've really heard the term "mainframe" used is in Films, Games and cheap 80's TV shows. And slashdot.
Re: (Score:2)
Main Frame means a IBM System 360 370 3033 3081 3084 3090 or whatever the heck they use now and comparables like the CDC 6600 or 7600, the Sperry Univac, the Burroughs and a few others.
I know the Itty Bitty Machine Company's products best though I have worked everythign from Amydal to PRIME to WANG.
antecdote. 1st chat I ever did was via a master operator console to a RJE (Remote Job Entry) it started out: $DMR1,'HOW BOUT LUNCH?',LOG=N and ended with some well remembered pleasure.
Re: (Score:2)
I started in this industry as an operator on a IBM OS/360 model 67 thats a 65 with a DAT box (digital analog converter. It ran OS/360 in MFT Multiprocessing Fixed Task, with HASP Houston Automatic Spoolong Program. From there I went to dual 65s runnoing shared DASD (disks) Shared SPOOL runing MVT with HIH HASP which was a varriant that allowed the world's first multiCPU archetecture. It required two operators who were tuned like identical twins to run without issue.
no, I did NOT make it up
Re:Wiki was obviously wrong... (Score:4, Funny)
I'm feeling very old, because I know you didn't make this up.
My dad once almost lost his job because he and his co-worker blew a year's computing budget on an infinite loop one night. It was on a Boeing computer services machine in about 1972, IIRC.
Re: (Score:3, Informative)
Re: (Score:2)
As far as I'm aware, those tasks still exist today, probably moreso than in the 1970's and 1980's, so why would the Mainframe be dying out? Have regular desktop/server processors advanced faster than demand for this data calculation
Pretty much.
Additionally, we've figured out how to network a bunch of regular desktop/server machines to do the job of a mainframe -- and to partition our data among a bunch of smaller machines.
After all...
Mainframes are a bit like supercomputers but better suited to tasks where there's a LOT of input/output data, but not a lot of calculation involved. Payrolls and such.
Is there ever a time when you actually need to look at the payroll at once?
And if you said "yes", there's a fair chance you're wrong -- there's very likely some small subset of the payroll, that just happens to be spread across all records (for example, the sum of all values in a particular column) -- so
Re:Wiki was obviously wrong... (Score:4, Insightful)
The Google model is not applicable for the tasks where mainframes are used. Mainframes are used for high-throughput/high availability/high RELIABILITY as well as high-INTEGRITY operations. In contrast, with Google, if a server dies, leaving 50 queries in Limbo, well, the internet users will just have to try their luck again, and hope for the best.
Re:Wiki was obviously wrong... (Score:4, Insightful)
I find it charmingly cute how so many people think how google does it's servers is the end-all-be-all of technology design.
Re: (Score:2)
You have to think back to old style computing. If you wanted a peripheral, you need a controller card. Then some place to plug it into (bus). Mainframes had enormous expansion capabilities, if you needed another item and it wouldn't fit, you could get expansion cabinets with additional buses which would hold additional controllers.
Typical mainframes would have a couple of dozen hard drives, of which a 14" multi-platter drive would have 300 Mb or so. A dozen tape drives or so, a couple of line printers, IO
Re: (Score:2)
On a raw price per processor basis, commodity hardware is several orders of magnitude cheaper than mainframes.
Say you have a million dollar budget. You can buy 1 low end mainframe, or 50-100 high-end commodity servers at $10-20k each. The commodity servers will have far more number crunching power, as a whole. Your average novice engineer is more familiar with the software and hardware, since it's not much d
Poor Understanding of Costs (Score:5, Insightful)
And scaling up a single mainframe gets exponentially more expensive; the price buying more commodity servers stays constant, meaning a linear cost of scaling.
Why do IT people (I'm assuming) make such lousy economists?
Think about it for just half a second. If you want to double the transactional capacity ("throughput") of your mainframe, you turn on more processor(s) inside the same box. (It's almost always inside the same box. A single mainframe can have massive capacity.) And you only do so when the mainframe is 100% busy for sustained periods, which it gracefully handles by the way without choking. You have zero reconfiguration to do to hardware, software, or applications: it's "on tap." (In fact, the machine itself can provision itself nowadays.) This is very cheap: doubling costs way, way less than the initial allocation. Also, up to 32 machines can share memory and operate as one, so if you are unusual and hit a single machine limit, no problem. It's only past 32 that you resort to partioning, traditional clustering, etc. -- and you've still got a lot more weapons at your disposal.
If you want to double your actual transactional capacity with highly distributed servers, you...well, it may be impossible. You better hope you have highly segmented and partitioned work for those servers to do, and that it is extremely well balanced so that it fits into little server buckets. The burden is mostly or entirely on you, the application developer, to figure that out -- and that's horribly expensive. (Because the work never is balanced, you have to install a bunch of servers that don't run continuously at near 100% busy, so you get less real-world performance out of each processor anyway.) But at the very least you have to more than double the number of boxes. And you have a lot of knobs to twist and turn to get your work settled into its new, large number of machines, so you better hope you don't need that extra capacity NOW. (Can't process those credit card transactions during a spike in demand? Sorry about that -- I guess your credit card company will just have skip collecting those millions of dollars.) And you get to hire and pay some more people to install, configure, and maintain those extra boxes. You also get to find more space in your data center (if you have it), consume more than double the power (if you have it), and run the air conditioning more than twice as hard (if you can). You pay Oracle, Microsoft, et. al. at least double, too. (That's not how mainframe softwre works: there are strong price curves, not lines.)
Fortunately there are some IT-economists in the world who understand this stuff.
Re: (Score:3, Funny)
Re: (Score:3, Interesting)
Actually, a modern mainframe CPU has about the MIPS of a PII. Their strength is in reliability and I/O capacity. They use (very expensive) accelerators for CPU-intensive tasks. If you want to run Vista on one of these things, you'd need to spend a quarter million dollars on a video card.
Of course, that video card would be able to render 64 desktops simultaneously, and if it started to overheat, it would email the vendor, who would send you a replacement overnight, and you could replace it without downtim
Re: (Score:3, Interesting)
Not all clock cycles are created equal. The z10 burns an awful lot of them doing various mainframey things behind the scenes. I've built kernels on a 2-cpu z9 guest, and it crawls compared to my dual-core desktop, but that's not what you buy a mainframe for. You buy it for all those things it does behind the scenes without you ever having to think about them, so your mission-critical database never goes down and never flips a single bit, even if CPUs, DIMMs, or whole logic boards fail.
Re: (Score:3, Informative)
but better suited to tasks where there's a LOT of input/output data,
They're still in heavy use, for just such jobs. Your phone and power bills are probably mainframe generated, but your stock brokerage statement probably isn't. Your credit card bill probably is run on a MF (my company probably does it), but most of the transactions on it probably came from Unix/Windows sources. The MF rules in sequential processing, though mostly from inertia, while Unix/Linux/Windows Server is taking over the DB side.
Re: (Score:2, Insightful)
For many people, the image of a mainframe computer is a complex of dozens of refrigerator-sized cabinets containing tape drives, disks, processors, and communications hardware located in a freezing room, consuming enough electricity to power a small city.
And is that image mistaken?
Re: (Score:3, Interesting)
Re:Wiki was obviously wrong... (Score:5, Funny)
The "under 40 generation"? (Score:2, Funny)
Re: (Score:2)
I'm almost 40, and several of my sock puppets have 7 digit UIDs.
Need... (Score:2)
Re:Need... (Score:5, Insightful)
99.999 Up time, speed, number of transactions, precision, hot swapping, 64 CPUs, lower cost to maintain, longer life time.
Hell, I can get a mainframe and put 30,000 Linux instance on it and use it as a cluster, or rollover servers.
PC Servers still aren't as capable as a mainframe, not even clusters.
Re:Need... (Score:5, Informative)
1) Reliability: 5 9's (99.999%)
2) Backward compatibility, there are people still running applications written 40 years ago
3) Security: Physical (hard to move a refrigerator), Network (no external network when applications working internally), RACF, Highest level of security rating of ANY server, ever.
4) Architecture: Redundant everything: Spare processors, spare power, spare, everything. Predictive failure/automatic fail over for individual components. Memory Bus greater than anything out there. Pipes to Storage extreme. Cryptographic processors to do SSL, etc.
5) Scale up: 64 processors (4.4GHz), 1.5 TB of Memory, etc.
6) Scale out: GDPS (Geographically Disperse Parallel Sysplex) up to 32 boxes?
7) Hipervisor: Its a network in a box. Applications talking to each other use IP, not TCP/IP, so you aren't sending 35% data, 65% header when applications talk. Network is at the speed of memory. zVM has been developed for over 20 years.
8) Power Efficiency: Compared to a server cluster + cooling + redundant power, etc.
9) Network Simplicity: No need for a rats nest for your rack, cable simplicity in some cases from over 1000 cables down to 12. From 14 switches (which are very expensive) to 4.
10) Management simplicity: Less staff needed to keep it up and running. Instead they are focused on adding business value
11) Running Legacy (aka Business Critical) applications, your web presence, your portal, and a myriad of other disparate applications in one place.
12) Create new servers in minutes without needing hardware "on standby."
13) Compartmentalization in a single box
14) Shared everything while still fully separate
15) Workload manager: able to on the fly change how much resources are allocated to images AND (this is the cool thing, cause other VMs do that) give it goal times for operations. As in: Complete this task in 1/100th of a second, and it will allocate, on the fly, for that to happen, and it will guarantee it.
I think that's enough...I'm sure I'm missing some stuff, but that should be a good compilation.
One thing to note: I'm under 30, and didn't know that mainframes existed 5 years ago.
Mainframes are NOT the answer to all questions. Intel is NOT the answer to all questions. Itanium, Solaris, Power, etc...none are the answer to all questions.
Buy the right tool for the right purpose.
About Those "Slow" Mainframe CPUs (Score:3, Informative)
Actually, IBM has been putting a lot of POWER inspiration into its z10 processors, although they are not at all the same. That means a z10 core is clocked at 4.4 GHz. It also has hardware decimal floating point, something nothing else has (except POWER6), which speeds floating point calculations by about 3 orders of magnitude versus software.
These processors are state-of-the-art, even in raw computational performance terms.
Re: (Score:3, Informative)
IBM is in the process of unifying its processor designs to keep costs down. The CPUs you find in their high-end POWER boxes and the mainframe systems are almost the same, but with different instruction decoders. The POWER 6 has a relatively modern instruction set (a superset of the PowerPC instruction set from the '90s), while the z10 is binary-compatible with the OS/360 machines from the early '60s. The POWER6 is currently the fastest CPU on the market for raw number crunching and a z-series mainframe c
Re:Need... (Score:5, Informative)
Raw IO power, in our case. With the number of transactions we process per day (financial services - clearing, trade matching, reconciliation, etc) nothing beats the System-i in terms of raw IO in getting the data in, massaging it and spitting it out...and far easier to manage than a server farm, at least for our use. The same vendor that provides our software also provides a JAVA version, but it's not going to handle the 2 billion+ transactions we do in a quarter.
And this software isn't legacy - it's relatively new and updated on a regular basis to take into account developments in the kinds of products offered.
"Horses for courses" as my British friends like to say./p?
Re:Need... (Score:5, Insightful)
That's correct. Also, look at the retail business. Merchandise management, loss prevention, warehousing and distribution... And we're not talking arcane software packages.
Here's an example: A retail chain has payroll, merchandising, and warehousing/distribution systems, all on the mainframe. The point of sale interfaces with the mainframe as well. A store starts to run low on an item? The mainframe knows because the POS sends its inventory data constantly. The MMS then tells the warehousing system that that store needs more. A pick list is automatically printed by the warehousing system. The warehouse worker picks the item off the shelf, puts it on a conveyor belt which runs through an RFID portal, linked to the mainframe, that then routes the item to the proper truck in the dock so it gets to the correct store - automatically. The truck delivers the item to the store, and the driver enters that into a wireless device which (you guessed it!) tells the warehousing system and merchandise management system that the item has been received by the store, so the MMS always knows the inventory levels in the store. The associate sells that item, and the MMS sees that from the POS data... it also knows that this particular item pays out a spiff to the associate and sends the information directly to the payroll system, which interfaces with a company who handles payroll (like ADP), and automatically adds the spiff to their next paycheck.
Uh oh - the chain is growing and adding new stores, with increasing volumes of data to process, and the nightly batch processing is taking too long... what to do? Call IBM, license another processor... They activate it immediately for you.
But oh no! A disk is failing... no need to worry, because IBM already knows about it and has dispatched a technician to diagnose and replace the faulty hardware.
New versions of this software are being released all the time, and just about every retailer with more than a few stores uses them. These systems are modern. Don't think a big room full of giant cabinets, reel-to-reel tapes and punch cards. Some of the current IBM iSeries (AS/400) models have a form factor that looks more like a PC than a mainframe.
Show me a Windows or Linux system that can do all that, 24x7, for hundreds or thousands of stores.
Re:Need... (Score:4, Informative)
None of the business needs you described sound like something that couldn't be done by just about any UNIX-like OS with appropriate applications (Oracle Financials, JD Edwards OneWorld, SAP). Even the hardware failures you mentioned can be handled with clustering and having cold, warm, and hot spares on hand. And just about any enterprise SAN or NAS has a phone-home feature.
So again, what's so special about mainframes? You guys talk about the bandwidth, what kind of throughput do you get? How many megs per second? Let's put this in raw numbers, I'm honestly curious about why those systems are supposed to be so special.
Re: (Score:3, Informative)
A z10 has 336 I/O controllers. Each one is a ppc processor. You do the math.
The last time I saw a zSeries tape drive, the tape controller was a pSeries.
Re: (Score:2)
That's about 250 txns/sec. There are Java
Re: (Score:2)
If you average it out ... I bet the peak rate is much higher.
Re: (Score:3, Informative)
Exactly. I believe the last reported peak was in the 2200/sec range. And we expect our volumes to double. Fortunately, our System-i (AS/400) team can simply license additional processors 'on the fly' to improve performance. My team even has some of our Unix stuff (I'm the Unix Manager) running in a logical partition on the System-I. And it's freaking fast.
Re: (Score:3, Interesting)
The last UNIX system I built was handling over 130,000 transactions PER SECOND.
HP Superdome + Itanium = incredibly fast.
Payroll? (Score:2, Funny)
I question the need of mainframes today. Now, they are great for running legacy programs (such as payroll, etc) but other than for backwards-compatibly, what advantage does a mainframe have compared to say, a server?
Send me your Resume... if getting payed is something you consider "legacy" then I'd be happy to negotiate some legacy pay terms.
LoL: captch is "weekend"
Re: (Score:2)
Re:Need... (Score:4, Informative)
Quality control, quality control, quality control, quality control
Redundancy, Redundancy, Redundancy, Redundancy, Redundancy
Reliability, lots of it.
LOTS of I/O.
Solid VM technologies that makes VMWare appear like the software equivalent of a toddler still in diapers.
Hardware-accelerated crypto, integrated into the overall system design, and not just an add-on card, at least on fairly modern mainframes.
Some mainframes also run dedicated hardware for CRC on data being churned through.
Designing all that into a cluster leads to something that is just as expensive to operate, and still won't have the same reliability as a mainframe environment.
And no, Google's model does not apply here. Google aren't working with data that must approach 100% reliability to the extent that it's possible for humans and technology to make it.
Re: (Score:3, Insightful)
Re:Need... (Score:5, Informative)
Now, they are great for running legacy programs (such as payroll, etc)
Payroll is not a legacy application. You still get paid don't you? :)
My point is, even if payroll were 'rewritten' it would still be a suitable mainframe application.
what advantage does a mainframe have compared to say, a server?
They are bigger.
A mainframe more comparable to a server cluster or server farm than a single server.
They feature processors dedicated to IO tasks. They are the kings of data throughput.
They are also big on reliability. Everything is hot-swappable. Everything is redundant. Failover is automatic and processes are rarely even aware its even happened. They have stuff like io multipathing (multiple redundant buses, controllers, etc) and execution integrity -- multiple processors do the same work, the results are compared, and only if they all agree is the computation accepted, errors are thus averted and defective processors and memory can be detected (and hot-swapped), transparent to the running programs and users.
Because they are basically an entire 'server farm' in a dedicated optimized box they also can require less space and power than a server farm of equivalent capability, which is one of their selling points.
I doubt there are any features of a mainframe that can't be obtained by building a suitable server farm, but at some point in some cases the mainframe is markedly more cost effective.
Re: (Score:2)
21 Years Old and Just starting out (Score:5, Informative)
I actually just took a job in software development on z/OS (the new hip, backwards-hat wearing mainframe operating system). Aside from the impressive clustering capabilities, we've got a lot of new and exciting stuff. (I personally am a big fan of AT-TLS) It's true that the systems are old and the interfaces archaic and painful to use, but the level of configurability and reliability these things offer is staggering. We have a few customers with 100% uptimes in the 20-year range.
My school (Northern Illinois University) actually is one of the few left offering full mainframe tracks in their computer science department, although COBOL was the most painful programming experience of my life.
I'd bet that my meta-group of 50 or so people has a median age of about 33, and while it is still the old dinosaurs who know the most, the definition of "dinosaur" in my personal, 15 person group is around 50 years old.
MILF (Score:2, Funny)
I went to SHARE in February (Score:4, Insightful)
I was at the last winter conference in Orlando. I would guess the median age of the attendees was somewhere around 40. There's a LOT of Linux going on in the mainframe world (and COBOL has nothing to do with it). The biggest mistake IBM is currently making IMO is they've gotten into bed with Suse. There was a large group from Suse (Germany) in Orlando last February. Again IMO, Suse is an awful Linux distro. Yast is an abomination to work with on a daily basis. I think Redhat missed the boat there even though their Enterprise Linux distribution has support for System 390 hardware. Anyway, the point is that Linux is alive and well and thriving on big iron.
In addition, one of the primary draws of Orlando is Disney World and the other nearby theme parks. The (oops, almost wrote "Teh" there) February conference was held IN Disney at the Coronado Springs (stay in the Cabanas section if you ever go there, for any reason). SHARE members vote on where to hold their meetings. If a majority of those folks were over 60 I doubt they'd continue returning to Orlando every few years.
If you're not familiar with where and how mainframes are being used today then I suggest that YOU are the one who's out of touch with a significant sector of the computing world. Business' needs don't all revolve around iphones, ajax and youtube. Or payroll and accounting, for that matter.
Re: (Score:2)
pc's as good as a mainframe? (Score:2)
Back in the day, it seems to me that Sperry or Boughs (sp?) mainframes used their own communications system, which would drive N terminals off of one wire.
In those days, PC's could emulate several terminals, one at a time. I was with a company that did just that. But the PC's of the day would be hard pressed to handle the incoming traffic from multiple terminals.
These days with TCP/IP as the protocal to rule them all, I expect decent server would handle the same traffic as a mainframe of 20 years ago. I do
Why Mainframes exist in my organization (Score:3, Insightful)
Re: (Score:3, Insightful)
And it'll run under Vista to guarantee 24-7 reliability!
There's a lot more to a mainframe than just software apps — reliability and massive I/O being the most obvious. Remember, this is a world where down-time is measured in millions of dollars per hour. Mainfr
Re: (Score:3, Insightful)
how many PCs though.
how much space do those PC's take up? How much power do they consume?
Back in the day you had room sized mainframes, sucking up loads of power, sat in big expensive air conditioned data centres. Now you've got room sized server racks, sucking up loads of power, sat in big expensive data centres.
I can guarantee that whoever it is you bank with runs all of their mission critical stuff on a mainframe (and you should be glad that they do). My company are spending over $0.6 billion over the ne
Re: (Score:3, Insightful)
Re:Why Mainframes exist in my organization (Score:4, Informative)
I am planning their destruction, a VM that runs on Intel hardware but responds just like a mainframe,
Good luck.
I used to work in a mainframe shop, and while the latest Intel hardware can run circles around one of the processors on a mainframe, it can't beat all 16 of them by any standard:
I'm not really a big mainframe fan, but they do have their place in the business world. Businesses don't care about MIPS or running the latest games; they want a system that works reliably with a predictable cost structure. IBM mainframes provide that.
Hardly news, really ... (Score:2)
Why is this a surprise? (Score:2)
Re: (Score:2)
I guess an XML schema is too daunting to those who see the answer to everything in a table.
So you are the guy who tries to use XML for a database. I thought you people were myth only found on DailyWTF. ;-)
All the memcache in the world wouldn't help either.
Not gonna argue with that, but I'll toss some logs in the fire and posit that there is a strong correlation between one "database with a dolphin in its logo" system and memcached.
Mainframes? OK. But COBOL??? (Score:2)
There are still places for mainframes. With virtualization, that Linux server you think you are leasing space on may actually be a slice of a mainframe.
But COBOL? Sure, there's legacy COBOL code that needs to be maintained. But answer this question: Given a clean slate and a proposal to build a new application, how many people would choose COBOL? Anybody?
[Sound of crickets]
The main reason COBOL is still around, a perverse reason at that, is that it is more expensive to port an app. than it is to patch it
Re: (Score:3, Insightful)
Serious question - I am long out of touch with language design and practice - which currently used and popular language/compiler/optimizers have solid support for BCD and financial arithmetic?
sPh
Re:Mainframes? OK. But COBOL??? (Score:4, Informative)
Cobol is still around because it's an extremely verbose language that is easy to understand (I never said "write into"), so managers can understand what their programmers are doing.
Re: (Score:2)
They are the money making engines (Score:3, Interesting)
Basically the mainframe and the software it hosts really make the cash for most enterprises - and as a consequence any sensible management are loathe to replace it with something "newer", even if the systems in question are horrible spaghetti nightmares that no-one really understands, and maintaining them is a process of trial and error. Replacement would simply be "cleaning the inside of a tin can", no obvious shareholder value at all in change for changes sake.
Also technology vendors have finally woken up to the fact that the mainframe isnt a dinosaur on the verge of extinction - for example making CICS transactions web-service enabled has made COBOL code just as capable of participating in a service-oriented architecture as a set of AXIS hosted java classes.
I worked at IBM Boulder (Score:2, Informative)
Cobol (Score:2)
Cobol is not dead
Can someone please have mercy and put it down for good? On the list of programming languages that really, really deserve to die, Cobol is way up top, even above visual basic.
But where do you start? (Score:4, Insightful)
My Dad was a mainframe operator when I was a kid. We're talking early 70's here, but he actually went all the way back to the IBM 1401. I've always had a fondness for the beasts, but no experience with them. Therein lie the problem. They're not at all commodity iron. Linux came into existence because commodity equipment became powerful enough to host such an OS. That cannot be said of z/OS. It simply doesn't run on anything I'm likely to find on sale at Fry's.
How does one gain employable skills with untouchable hardware? (Note: I don't consider Hercules to be a solution. Where's the software?)
Re:But where do you start? (Score:5, Informative)
There are no Linux-equivalent options for the non-student hobbyist wanting to cut their teeth on the latest generation zSeries software. You simply cannot rent cheap mainframe time with the IBM ADCD [ibm.com] (though you could still learn a lot with just a raw z/OS subscription, there would be no compilers, no databases, no middleware, etc.). I'm not kidding or exaggerating; we just looked into this earlier this year (and if any experienced zSeries folks know differently, please post a correction here). IBM prohibits anyone from buying an ADCD subscription, then renting out time on their zSeries, at any price, with access to the ADCD. Your only option if you don't outright own a z/OS license is to pay for the IBM Remote Development Program [ibm.com] (RDP). And no, you cannot buy an RDP subscription then resell slices of it. So you can see why the minimum entry fee of more then $4,000 USD per year for RDP would put off most non-student hobbyists.
If you are a student, you can see if your school offers zSeries courses, or look into getting a faculty sponsor for such a course in higher education campuses. IBM has programs for encouraging the training of students in zSeries technologies.
And before anyone pipes up with "Use FLEX-ES!", the commercial x86 zSeries emulator, let me disabuse you of that notion: it is dead in the water at the moment, due to legal fallout from IBM's suit with PSI that is too convoluted to get into here. Only grandfathered commercial licenses are kept on support; no new commercial or development licenses are granted by IBM, and all old development licenses were forcibly terminated as they came up for renewal. We know this because we were one of the developer licensees.
And before anyone else pipes up with "Just buy a used/cheap z/OS box!", let me set you straight on that notion: IBM has cracked down on z/OS licenses to refurbished hardware, to the point where we couldn't find anyone who would sell us old generation hardware with a new license of z/OS because they couldn't promise they could secure said license. And even if you could find some available hardware, the cheapest z/OS license quote we could find for the smallest old mainframe that we could locate was around $150K. At that price, you might as well go all-in for a brand-new "baby mainframe" for $250K.
The zSeries tech is undeniably cool and fun to play with but definitely not for non-students with a beer budget, even just to learn. The Linux world could learn a heck of a lot from the mainframe world, though. My dream platform would probably be a Lisp Machine with its data management and security facilities (amongst others) leavened and matured from mainframe tech. The zSeries folks take for granted solutions that the Linux world doesn't even realize are problems to begin with, and the zSeries guys aren't ashamed to swipe tech they like from other platforms so they aren't standing still, either; it is a pretty nifty learning experience if you are willing to dispense with any preconceived notions of "obsolete mainframes".
Re: (Score:3, Funny)
Mmmm with an ID under 18000 you should have a mainframe to heat your basement, no?
Young mainframes (Score:2, Insightful)
Backwards Compatibility (Score:5, Informative)
Disclaimer: I manage the DASD (disk based storage) for a mainframe (z10) environment.
We used to run a System 390 (think watercooled and took up 1/4 of our datacenter floorspace)
We then migrated to a S390 (aircooled, the first big black box) in about 1995
We then migrated to a z900 in 2002.
We've just completed migrating to a z10.
The applications continue to run on our brand new mainframe unmodified since the early 90s. Sure we've gone from Bus and Tag to ESCON to FICON (1Gb, 2Gb and now 4Gb). But the same applications are taking up significantly less power and a percentage of the mainframe than previously did.
In the early 90s, 486dx was king. How many applications that ran on 486dx DOS systems are currently running in a VMware VM that is running MSDOS 6.22?
Next time you swipe a credit card, and within a few seconds you're approved for your transaction, including determining if you're purchasing something within a common pattern of recent purchases. How many x86 boxes would you need to manage this?
Thank us mainframers.
Btw: I'm 36, run linux at home and on the mainframe.
No low-end mainframes. (Score:4, Insightful)
IBM once made a desktop mainframe, the PC/370. You could run VM on it. But that was in 1985. Since then, they've avoided offering low-end mainframe compatible machines. There's no reason IBM couldn't offer a 1U server that runs zOS for $2000 or so, but they don't. Remember, most of the software was designed to run on machines well under 100 MIPS.
As other people have pointed out, IBM-type mainframes do virtualization right. Virtualization on x86 is a hack and an afterthought, even with the newer hardware support. x86 virtualization with VT hardware creates a virtual machine that doesn't look like a bare machine with VT hardware; the virtual machine has no "ring -1". VMware actually patches code on the fly to work on older x86 hardware, which makes VMware very complex and vulnerable to bugs. The mainframe people don't have do that. On IBM-compatible mainframes, the virtual machine can look just like a real machine; you can run VM under VM under VM, and it works fine. About ten deep, it's too slow to be useful, but it works. This is good for stability.
For historical reasons, PCs have a primitive I/O architecture. The "bus" concept came from the days when the peripherals and the memory were really on the same bus. That hasn't been true for decades now, but the architecture is still set up as if it was, with peripherals seeing physical, rather than logical addresses. In mainframes, there's an I/O MMU, memory protection between the peripherals and memory, and there's a channel architecture which standardizes how peripherals talk to the computer. PCs are still stuck in the "each peripheral has its own device register layout" era, which is why we have so much trouble with drivers. The "device register" and "bus" concepts are so deeply embedded in PC thinking that FireWire, which is really a local area network, was designed to emulate a bus with device registers.
Comment removed (Score:3, Funny)
Mainframes won't go away because... (Score:3, Interesting)
I still miss having my Unix command line thought!
And I'm 34.
Re: (Score:3, Informative)
In the 90's, the AS/400 went from a 32-bit CISC processor to a 64-bit RISC processor.
If this were Intel, we would have had to go through the code looking for bustage (like we did when Windows' wParam went from 16 to 32 bits). This being an AS/400, we didn't even have to recompile! Just copy everything to the new system; on first execution, programs are converted to 64-bit opcodes.
ALL AS/400 (iSeries, System i) programs have been 64-bit since the mid-90s; no programmer intervention required.
Re: (Score:3, Insightful)
In the 90's, the AS/400 went from a 32-bit CISC processor to a 64-bit RISC processor.
If this were Intel, we would have had to go through the code looking for bustage (like we did when Windows' wParam went from 16 to 32 bits). This being an AS/400, we didn't even have to recompile! Just copy everything to the new system; on first execution, programs are converted to 64-bit opcodes.
ALL AS/400 (iSeries, System i) programs have been 64-bit since the mid-90s; no programmer intervention required.
...because the compilers available to application developers generated code in a very high-level pseudo instruction set that the low-level system code translated to native code on first execution. The high-level code was (usually) kept around, so that on the first execution on a RISC system it could be translated to the (extended) PowerPC code the RISC processors run.
The System/360-to-z/Architecture machines didn't do that. 32-bit data/24-bit address programs stay 32-bit data/24-bit address programs even