Mainframe Programming to Make a Comeback? 262
ajw1976 writes to tell us that IBM has released a series of announcements today "introducing many new software tools, academic programs, and support for outside developers." The new releases are designed to help entice programmers and businesses back to the mainframe. From the article: "The announcements, according to analysts briefed on them in advance, signal a shift from defense to offense in the company's mainframe strategy. Last month, I.B.M. introduced a machine priced at $100,000, about half the previous starting price for its mainframes, which can run up to several million dollars. The announcement of the low-end mainframe was made in China, which I.B.M. regards as a promising market for the machines."
The value of the mainframe is in the hardware... (Score:5, Informative)
The same is true of their memory subsystems, their disk subsystems, etc., though their backplane performance tends to be second to none. Mainframes are designed for throughput.
Mainframes are capable of staying operational for decades at a time. If you don't want your computer to ever go down and can afford the price, a mainframe is what you want.
One other nice benefit: they've had virtualization figured out on mainframes since the 1960s, so allocating resources is a relatively easy thing to do.
If you're interested in finding out what the older mainframe OSes were like, check out the Hercules IBM mainframe emulator here [conmicro.cx].
Re:mainframes rock (Score:4, Informative)
Same with the big Unix servers. Unix was considered "ready" for Big Iron usage once machines started shipping with crossbars (for hotplugging CPU boards) and redundnat everything. If you open a Sun E10000, you'll find that it looks a lot like a mainframe on the inside.
The modern mainframe is, in general, vastly more reliable than even the best of the best of 'big servers.'
Right up until Unisys invented "Clearpath" technology. Blech. Leave it to Unisys to take great tech halfway to nowhere.
Re:But how can anyone learn to use mainframes? (Score:3, Informative)
That's how people learn, especially in the trendy world of Comp-Sci.
Geek1: "Have you tried [insert language du jour, such as Ruby on Rails]"
Geek2: (12 hours later) "Check out my new ap; it's in [language du jour]"
Don't have access to Z machine? Start with Hercules.
Here's a debug tip:
LGHI R1,X'DEADDEAD'
Re:But how can anyone learn to use mainframes? (Score:3, Informative)
From the "old farts", as you put it.
We've got a large mainframe contingent where I work - there are lots of critical legacy apps that nobody wants to pay to build replacements to - and I doubt any of them are under 40. But man, they all know their stuff. You could easily bring in one of them to train people if you needed to.
I'm do not belong to the set of "mainframe people" per se however I do sometimes have to use the mainframe on my job. When I need to do something new on the mainframe I first look for docs past team members might have written to tell me how, and if I find them then I don't need to bother anyone. However if there's nothing there, I go talk to someone, and they'll usually be able to tell me just what I need to do.
Probably the biggest problem they'll face when teaching is that the environment is totally different. I've been around desktop computers since I was 7 but even I get lost in the mainframe world. I still hesitate when told to "hit PF5" to do something. And I can't tell you the number of times that, by force of habit, I've hit Esc to get out of something on the mainframe and completely fucked up my terminal display. But like anything else, it gets easier with time.
So long as companies continue to look at IT systems like they would look at a piece of heavy machinery, they'll continue to pay to support legacy systems instead of paying to replace them. They'd rather pay a little over a long period of time, rather than pay a lot now and much less later. IBM, if they're serious, is just trying to cater to this mindset. After all, demand drives supply.
MF + Linux (Score:4, Informative)
Perhaps most interesting to this community is that Linux on the mainframe solves a major problem that all large institutions are dealing with: Power. Power density and consumption for intel/amd boxes is through the roof and is breaking most data centers. Exponential growth is not an understatement. Mainframes however, remain very predictable with a fairly flat and linear power curve. Porting quantitative trading and analysis applications to the mainframe would solve this problems and literally save 100's of millions of dollars.
Re:Cluster computing is better (Score:5, Informative)
Actually, no. The IBM 370 architecture is open, as a result of an antitrust decree decades ago. There are plug-compatible peripherals and software-compatible CPUs. There's even a good emulator for PCs. It's actually more open that x86 or PowerPC.
Re:What makes a mainframe a mainframe? (Score:5, Informative)
This beast can be physically partitioned into multiple domains. One OS runs on each domain. CPU/Memory boards and I/O boats can be dynamically moved from one domain to another. You can run Solaris 8 in one domain, Solaris10 in another, Linux in a third, and um...*BSD in a fourth. Any of them runs independently of the others. If a board dies, you can deallocate it from a domain, swap it out, and add it back in--all live.
Now multiply that by a LARGE number, add crazy amounts of fault tolerance, and you're getting into the world of mainframes.
Re:The value of the mainframe is in the hardware.. (Score:3, Informative)
It is worth adding that this emulator lets you run 31 (not a typo) and 64-bit zSeries Linux distributions as well. Very cool stuff.
Re:mainframes rock (Score:3, Informative)
Data General wasn't a Mainframe vendor. They produced Minicomputers, not mainframes.
Re:What makes a mainframe a mainframe? (Score:4, Informative)
It's not the fastest thing in the world, but would you want to haul a load of water main pipes with a Porche?
background.. I'm a mainframe systems programmer..
There are two major aspects of a mainframe. One is the physical hardware (and software), on how it is designed and the other how they are used. The hardware is designed from the ground up to be robust and redundant. Yes it costs thousands (millions?) of dollars for a mainframe system, but with that you get the assurance that the system *WILL NOT CRASH* when an error happens. Instead the system will perform a self diagnosis, make an automated phonecall back to support. Support will send out an engineer (CE) with the replacement parts, which will be replaced while the system is still running (note that there are some (very few) instances where the repair does require downtime to actually perform the repair).
A few years ago, one of our CE's informed me that one of our mainframes had called home with a CPU failure. I asked if he would need to schedule some downtime to replace the card(s). He said ".. No.. we would have to lose 5 more before they would get worried.." Now.. from my viewpoint, I did not see any error, I still see the same number of "Processors" as I did before. What happens is that the system has a bunch of spare CPUs that are kept online. Instructions are run in parallel across multiple CPUs and then the results are checked. If there is a failure (as in the results don't all agree) the system will determine which CPU "failed", perform a diagnosis on that CPU and if it's determined that there is a problem will fence the failed CPU off from use. Note that this is all done under the covers from the operating systems. There is nothing that I need to do to enable or disable this.
Mainframe operating systems behave very differently then the Windows/Unix world. -- Lets take a simple example. An application allocating memory. Under Windows/Unix what happens if the memory allocation fails? -- Answer, the program is handed back control with the hopes that it will test the returned value. On a mainframe by default if there is a memory allocation error, the application will be "abended". Now the program *can* request that if there is an error to allow it to continue by explicitly stating that it will handle the error. This concept is carried throughout the system API. By default the application will be halted if there is an error. Under Windows/Unix the default is to simply return some error flag and hope that the application will handle it.
The way mainframes are used and maintained is a little different. Things are usually not done on a whim. This really isn't due to anything physically different on a mainframe, but more of the "culture". Yes these are big expensive boxes, therefore the company that owns (rents) them wants to make sure they are maintained and running efficently. When changes are made, they are researched and documented with fallback plans. When even minutes of downtime could mean millions of dollars lost, it's well worth the investment in time to make sure that a change is correct. Going back to the 18-wheeler analogy, I suspect that when it's time to do a scheduled maintenance on the tractor there is a lot more testing/verification then you would have done on your family car.
Forget z/OS, try Linux under z/VM (Score:5, Informative)
Mainframes are Obsolete - The Law speaks (Score:2, Informative)
Re:But how can anyone learn to use mainframes? (Score:4, Informative)
I wish we could have more like him.
Mark Jacobs
Time Customer Service
Tampa, FL
Re:mainframes rock (Score:1, Informative)
It depends on what you consider a CPU. If you are referring to the main CPs, then you are dead wrong. Data integrity in the CPs is implemented in 2 basic ways:
* Duplicate an entire execution unit and protect it with parity, which actually provides a convoluted form of single error correction. Output from the units is then cross checked.
* Protect everything in the the execution unit with ECC.
When errors are detected, there is an escalation scheme to migrate to a spare processor. But the main CPs are never run as a pair!!!!! Note, in IBM speak 1 cpu = 1 processor = 1 core.
If you refer to a CPU more generally, then yes down in the channels, there are dual-core PowerPC processors with cross checking. But unlike the CPs, the channels do not have spares to migrate work to. If a channel encounters a cross check, it will checkstop. The SE will, depending on the situation, recycle the channel. Any multipathing is implemented by the upper level firmware and OSes (i.e. LVM in Linux), and relies on upfront planning by the administrator.
Re:mainframes rock (Score:3, Informative)
Re:mainframes rock (Score:3, Informative)
Re: Running CPUs in pairs on mainframes (Score:4, Informative)
I worked with Stratus machines running a version of UNIX in the 1980s.
The machine could have up to eight or sixteen CP cards in it, I forget which.
Each CP card had four CPUs on it, running as a pair of pairs, with each outer pair running a separate path to redundant memory modules on other cards in the computer cabinet (powered by redundant power supplies, UPSes, disks, etc., with redundant paths between components, and everything constantly checking its counterpart).
All four CPUs would execute the same instruction, and each pair would compare the results, first with each other, and then with the other pair.
If a pair of CPUs didn't agree with each other, that pair would take itself off-line, and the other pair would write any (presumably correct) results to both memory modules, then the entire card would go offline, and the machine would run with reduced performance until a new CP card could be hot-swapped in.
(The machine would "phone home" whenever a part failed, and Stratus would ship a replacement part immediately.)
I don't remember what would happen if each CPU pair thought that it was right, but the two pairs disagreed with each other.
Space-time paradox, maybe.
At any rate, everything in the computer was pairs or pairs of pairs, executing in parallel, comparing results, etc.
It was advertised as a "never-fail" machine, that could survive the failure of any one component.
Sometimes a FedEx guy would show up at the door with a CP card, memory card, disk unit, or whatever, and that would be my first indication that something had failed.
I'd take the new part back to the machine, open the cabinet, pull the card or disk unit with the red light lit, and replace it with the new one.
A few seconds later, it would green-light, and the machine would be back up to full steam.
The only time that the whole thing failed is when we had an ice storm that knocked out power to the building for nearly a week, and the UPSes couldn't hold out that long.
So, to make a short story long and boring, yes, there are times when CPUs run in pairs.
Re:But how can anyone learn to use mainframes? (Score:3, Informative)
Mainframes aren't going away. There's simply nothing else out there that can handle the amount of data that a mainframe can process. That's simply the way it was built. It doesn't matter if someone comes out with a 25ghz core cpu with fiber interconnects. That doesn't drive business. IBM's mainframes are built for business. Read up on GDPS, Parallel Sysplex, WLM and CICS. Comparing a "omg fast 15ghz dell server" or whatever to a mainframe is like comparing a Ferarri to a freight train. Sure, the Ferarri will smoke the train in the quarter mile, but there's no way you'd want to use one to move coal from one side of the country to the other.
If you're interested in learning the stuff, just ask around a company that uses them. While it is an entirely different world, it is fun to learn, and people are really trying to hire young mainframe system programmers now.