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."
I knew those IBM assembler skills would come in handy again some day. Ah, back to the days of xedit, and Rexx as well.
""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.
"The announcement of the low-end mainframe was made in China, which I.B.M. regards as a promising market for the machines."
Way to go IBM, supplying fresh "bricks" for the Great Firewall. I mean, I'm not trying to start a China-bashing-fest, but I can think of quite a few applications China might have for mainframe computers that a Westerner might find... a little unnerving.
In communist China, the mainframe schedules time with YOU!
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.
Exactly - this is the wrong tool for the job. The hardware is fantastic - and yes, I've never seen a hardware problem, though crappy code (waves hand) can hork an instance. One of the machines I use is a eServer zSeries 900. Max of 16 CPU's, and this one has less than that - think it has 6, but not sure. Not that they would ever *allocate* all the MIPS my direction.
But lets say I had some stupid money. From the website, the latest greatest box...
If you need to crunch hard numbers - especially in parallel - there are much better options out there for the money. The folks a few miles down the road from me do a fantastic job with large Opteron clusters (waves to Malice). The mainframe is not the hardware you want when it comes to getting the math on.
IO and uptime... that is another story...
+++ 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 you open a Sun E10000, you'll find that it looks a lot like a mainframe on the inside.
Yeah, I've seen 'em. Sun E10Ks are practically mainframes. And they cost about as much, too.
Of course, when it comes to raw transactional throughput, your average E10K running Solaris and Oracle just doesn't hold a candle to, say, an IBM z9 Enterprise Class running z/OS and DB2.
My blog
Just FYI, the Sun E10K is an old system--it was released in 1997. I wouldn't expect it to hold a candle to a recent IBM enterprise machine (I assume an IBM z9 is pretty recent).
It's pretty interesting how Sun ended up delivering the E10K to market. Especially considering how SGI fared in the end. The San Diego based team that developed the machine was originally bought by Cray, who were later bought by SGI. SGI, at the time, didn't have a place for the project and felt it competed with their own products. They sold the team to Sun for supposedly ~ $50 million who finished up the development and productized the machine.
Check out this site... http://www.filibeto.org/~aduritz/truetrue/e10000/h ow-e10k-wasborn.html -
These days, Sun's top mainframe like throughput servers would be the highend E25Ks and midrange E6900s.
I work with AS/400's -- have been on IBM hardware since the system 3.
With an AS/400, you are talking about 2 hours of unscheduled downtime per year.
Windows computers win because they are cheap- not because they are fast or reliable.
Also mainframes are typically built to deal with phenominal amounts of data in ways that intel architecture PC's just can't handle.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
People have already mentioned stuff like tons of memory, redundancy up the wazoo, etc. And those that have said it are correct; mainframes are not good at CPU intensive work (they aren't really designed to be). They're incredible at I/O-bound workloads, hence their popularity with financial institutions, airlines, retailers, etc.
:-)
For me, the real killer app is Linux under z/VM on a mainframe. I work for IBM testing enterprise Linux distributions on our mainframes, so my job involves a lot of Linux installs, quite a bit of administration (I currently have 8 Linux guests I use for installs and tests but would ideally have about 20), and a bunch of debugging, scripting, etc.
I can dynamically create or attach devices to my systems. Want another network adaptor? Poof! Want another chunk of disk space? Voila! More CPUs? No problem! I can install RHEL or SLES, copy it to a spare block of space, and then copy that install as many times as I want and then customize it. With a mainframe and today's storage systems, I can flashcopy a full Linux image in a few seconds and have it up and running in another 15 - 30 seconds.
The absolute worst thing about having experience with Linux on a mainframe? Being spoiled by it. Now whenever there is trouble with any of my personal machines I cringe and wish I could just bring up another guest or flashcopy another install and bring it up. Trying to debug bootloader issues with my ThinkPad stunk and made me wish I could just enable tracing or get a dump from an underlying hypervisor.
I will freely admit that mainframes can be expensive and may require a fair amount of work to get set up, but man, once they're up and configured, it's absolutely amazing how easy and powerful they can be. And it can be quite a feeling to have a system with 32 GB or more of RAM and a couple dozen CPUs running Linux.
Are you saying coconuts migrate?
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"