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?
Mainframes are very good at reliably performing batch and OLTP workloads, they're hopeless at HPC - inadequate performance (even latest models) with *way* too much admin and maintenance/software cost overhead. Wrong tool for the job.
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 you're interested in finding out what the older mainframe OSes were like, check out the Hercules IBM mainframe emulator here. (http://www.conmicro.cx/hercules/)
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.
+++ UGUCAUCGUAUUUCU
I've been gainfully employed on Mainframes (mainly) for about 25 years now. I wrote yet another ALGOL program this morning. I've done UNIX and some Windows on the way down the road, and am still waiting for the college graduates who know my job backwards to come in and put me out to stud. Hasn't happened yet.
Mainframes are industrial strength. Full stop.
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
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).
Check out the definition of Mainframe at the NY State Law Library http://www.courts.state.ny.us/ad4/lib/gloss.html#M
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
I worked on Big Iron back in the seventies. Even then, the reliability of those old monsters made the present-day, top-of-the-line Wintel box look utterly pathetic. (I'm still amazed at how thoroughly the PHBs were hoodwinked.)
The problem with mainframes, however, is that they're not exactly user-friendly. The AS400 class over at the local community college still deals with the hardware via the classic text interface; fast as hell, but very limited. Users (and PHBs) would scream like banshees if they had to go back to such an interface after years of Wintel's eye-candy, and that's the simple truth.
So; envision this: When the time comes that Wintel says to you 'upgrade your workstations to Vista or DIE,' strip-out the M$ on those old boxes and install just enough of Linux and X to launch a nice, solid remote X-Windows session. Next, set-up virtualized Linux partitions on a nice hunk of Big Iron and plug the thing into your IP backbone. Have the users login via their lovely new X-Terminals into a screamingly-fast Linux session on that mainframe. Cancel the Wintel upgrade budget.
Kick the idea around; come up with other stuff, like moving your DBMS to a virtual partition on that same mainframe and have it communicate to the other sessions via a private network that never leaves the machine. Stuff like that. Sound like fun?
];)
Regards;
One big difference between mainframes and UNIX or Windulls boxes is the way that resources were allocated.
IBM allowed fine-grained control of CPU time, IO bandwidth, RAM, and disk storage. And this control was not a weighted-selection algorithm, it was WYSIWYG deteministic control.
In mainframe shops, there were well defined workloads, often represented by a batch of transactions needing to be run against a database. These "batch jobs" would run on predictable intervals, daily, weekly, monthly. They could be scheduled to run at fixed times for known durations.
This made the whole mainframe environment very easy to manage. Instead of having to guesstimate workloads, and install CPU and I/O capacity to match unexpected peak demands ruled by chaos theory, mainframes were safe and predictable. The need for CPU MIPS and RAM was clearly visible and easily monitored and planned.
So when people say that mainframes were "more reliable", they don't just mean the MTBF numbers of the hardware.
They mean that when you ran work on a mainframe, you knew exactly what programs were using what resources at what times. And when something screwed up, you could very simply back up to the previous version of the affected files and re-run the batch job.
Life with mainframes was safe, logical, and predictable.
Introducing some of that into UNIX or Linux would not be a bad thing. Not every problem has to run in real-time with dynamic adjustment of resources. Deterministic, static allocations of memory, CPU, and I/O can work very well for predicatable workloads.
Linux needs a good Batch Spooling manager system.
"Sic Semper Path of Least Resistance"