Slashdot Mirror
Mainframe Programming to Make a Comeback?
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."
Cool, I can dust off my old bell bottom pants and platform shoes. I knew they would come back!
All seriousness aside, I started out coding for mainframes, mostly assembly. To this day some of the most screaming and cool programs I ever wrote were on mainframes (wrote (in assembly) an on-line trouble logging system to replace a paper system back in '76).
I did lots of COBOL programming and maintenance for a major, now absorbed by increasingly corrupt larger pseudo-telcos, telco. COBOL, not the most exciting language, but the throughput and data integrity of those days I've not seen matched since (and I still love Unix as my first choice for environment).
Which brings me (and us) to what I think works in favor of mainframes having a chance at a major comeback:
This is a partial list. I've long lusted for the raw power of mainframes with the standard support and the nimble Unix utilities.
In my field (bioinformatics) data generation is far outpacing desktop computer power. I work with microarrays and in the last 5 years feature sets have increased over 1000 times with the prices moving almost as quickly in the opposite direction. We've been struggling for a while. It will soon take mainframes to process this sort of data.
I don't think Mainframes will come back in a big way. I forsee virtual servers becoming much bigger, as RDP and VNC protocols get more handy too.
Plus, just imagine a Beowulf cluster of virtual servers!
Oh You POS
The market for big computing is increasing. It's just that most tasks can now be done on small machines. One of my buddies was a numerical modeller in the '70s. In 1975 they put on a night shift in the computer center to run his jobs. By 1985 he could run the same model on his desktop in less time.
It makes sense for IBM to make less expensive mainframes. The jobs will expand to fit the computers available. If you build it they will come, etc. etc.
I recently met another co-irker who used to program mini-computers. He said his students were calling him the old fart. I pointed out that he could be right up-to-date if he just prefaced all his comments with the word 'embedded'. There are modern chips that have exactly the same architecture and instruction set that the old minis he worked on had.
There is a market for what IBM is doing and it isn't going away any time soon. It will just be done on cheaper machines.
""Imagine what a beowulf cluster of these things could do?""
Probably not a whole lot.
High performance computing is not a Mainframe's purpose. A typical personal computer is going to have a much more powerfull proccessor then what you'd find in your average mainframe.. Of course if you have a few million dollars laying around you can find all sorts of stuff that is blazing fast.
The thing that Mainframes are good at are I/O. That is sorting and managing massive amounts of information. You'll have transactions and records being sorted that are numbered not in the thousands, but in the tens or hundreds of millions.
Also you have all these intellegent peripherals.
For instance in PC-land typically scsi drives are faster then SATA drives.
This isn't because SCSI is so much faster or using space age materials. (although they tend to last longer because they are simply better built to higher tolerances and also this allows them to spin faster.)
SCSI and SATA use pretty much the same technologies to do the same stuff. Same materials, same most anything. What makes them faster is the intellegent controllers and I/O bandwidth (although not so much anymore).
Mainframes are like that. Everything has a built in proccessor that does it's share of the workloads. All these intellegent controllers for all I/O. network offload. Disk activity offload. All this stuff.
Like a big brachiosaurus vs a monkey.
The dinosaur is the mainframe, the cat is the monkey.
So a beowolf cluster is like a thousand monkeys on a thousand typewriters.
A brachiosaurus supposadly had multiple special brains or nerve clusters around it's body. That way you have a controller in it's ass to control the back legs and the tail. A controller to control the multiple stomachs. etc etc.
That way it could live with a brain the size of a walnut.
So if you want to decode the genome, use the monkeys. If you want to move mountains, use the dinosaur.
I do not understand how IBM expects to sell mainframes when nobody knows how to use them. If I wanted to get out of the Unix/Linux biz and get into mainframes or even recommend a mainframe for use at my employer I would have to know something about using one. But I would not have any clue as to where I could go to get that kind of information or training. I have only met two mainframe knowledgable people in my whole life (among zillions of un*x people) and they are both old farts. Finding good Linux/perl/whatever people is hard enough. I can't even imagine having to recruit a mainframe person.
So where are you young mainframe people learning how to use mainframes?
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.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
It turns out to be a lot like mainframe computing in terms of physical infrastructure and administration, and in fact often takes over disused mainframe computing centres, at least in the university space.
Unlike the mainframe environment, anyone with Unix/Linux experience is already equipped to take full advantage of cluster and grid computing. Either enviroment provides specialized resources that you have to learn how to access, but to me, the advantage goes to whichever environment provides the most universal expression of those resources, and is least likely to lock my efforts into one particular architecture.
A mainframe is an especially proprietary architecture. Portability has never been its strong point. Conversely, most cluster computations that I've seen have been quite trivially ported from one cluster environment to another. And to some degree it's in every vendor's interest to make it so.
The exceptions are interesting but, at this point, surprisingly rare. Relatively few researchers are decomposing problems in a way which requires either MPI or shared memory. Perhaps the field is not mature enough for that yet, much less for the sorts of computation envisioned by the Grid community, though that day will eventually arrive.
What I mean is, the biggest market for massive computation is always going to be driven by ordinary computation which happens to operate at a massive scale. And for that, the plainer, more symmetric, and more standardized the architecture, the better, because development and testing costs are not going to go down in the face of massive computing resources, they're going to go up.
The perfect mainframe, in other words, is one node in a Beowulf cluster. And that's fine. Just don't go running MQ Series on it, okay?
Parity: What to do when the weekend comes.
John
For the past year or so. The environment has potential. But the CPU speed is horribly slow. I would have really loved a cross compiler that could offload CPU intensive C++ compilation off onto some other box that wasn't so CPU limited.
It's really interesting the things that take no time at all on the mainframe (grepping the source tree) and the things that take forever (compiling it). It's an odd architecture. There are definitely things you should not use it for, but it would likely make an excellent web server.
Need a Python, C++, Unix, Linux develop
Asking most programmers to appreciate mainframes must be like asking most drivers to appreciate 18-wheel big rigs -- you know they exist, and large companies rely on them, but you never really have a *need* to know what it's like to operate one.
I've always believed that mainframes have their place in the world, even when the world was announcing the era of the personal computers and the death of mainframes. But while I understood them to be highly specialized high-throughput high-reliability machines, I never had a personal experience with a mainframe operating environment. So I never truly understood what a mainframe is...
I've worked on (relatively) bigger Unix systems (8 processor SPARCservers, 4-rack Sequent NUMA-Q's, and others), but at the end of the day, they seemed no different from a single desktop Unix machine -- just faster and with more memory and storage. I've also used a VAX, briefly, during my freshman year in college. I've always imagined that VMS was closest to what a mainframe environment must be like.
So, to the folks that understand the mainframe -- what is it about them that makes them more than just faster versions of desktop machines, or even server systems that us non-mainframes are used to?
Both of these are huge. I don't know of a single major financial firm that is shrinking their mainframe footprint. Also, most of the talent is retirement age - so their is a promising future for those entering now.
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.
ALC ...and any other A-list languages as I think of them.
Algol
Ada
If your going to do the joke, at least do it correctly, with valid syntax.
ADD 1 TO COBOL GIVING COBOLI just hope Gibsons make a comeback. They never recovered after the movie 'Hackers' came out and every kiddie on the block was brute forcing their way in.
For any organization that may contemplate getting into mainframes -- skip z/OS (MVS). MVS is what most folks dread when they think about mainframes (JCL, pre-allocate datasets, etc.). A modern mainframe (z/990 or z9) running z/VM (5.1 or 5.2) and a bunch of linux guests is *COOL STUFF*. What's really cool is when you need to setup a temporary testing environment -- no problem, just add a half-dozen configuration statements to your "USER DIRECT" and clone an existing guest image to the new machine's disk volumes. Done! Need more memory in that virtual Linux server? No problem, bring up USER DIRECT in XEDIT and edit a single line of text and issue DIRECTXA. Restart the linux guest and now is has more memory. Disk space (volumes) can be added while the Linux systems are running (add as many as you need).
I, for one, welcome our old COBOL overlords.
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.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana