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.
Imagine what a beowulf cluster of these things could do?
I knew those IBM assembler skills would come in handy again some day. Ah, back to the days of xedit, and Rexx as well.
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
Maybe it's just IBM realizing that their goose isn't laying as many golden eggs as it used to?
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.
No.
I hope this saved everyone a few minutes. Now get back to your 3270 terminal and XEDIT that REXX script to help you manage DASD on your VM/370.
--Pat
"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!
Only 70 years ago they were selling to Nazis to track people for "processing".
Today the Nazis could make some spiffy looking spreadsheets with bar charts showing throughput and other cool things.
They really were ahead of their time.
Trolling is a art,
IBM will happily sell to any customer as long as the said customer can pay IBM. They don't discriminate! ;-)
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?
Anything but mainframes. Not even the big bucks they were offering for Y2K mainframe programming was enough to get me to go back. I only keep my yellow card (System 370 Reference Summary) out of nostalgia.
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.
I've wanted to get into mainframe programming for years, it interests me in a very major way. (On the unix machines I actually DO make use of the 'batch' utility)
Not the sort of thing you can just pick up to play around on though (unless you happen to be extremely wealthy)
The cost is the biggest factor, they're just not accessible to most of us, that is why it won't come-around any time soon. Shame really, I'd love to play with one!
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.
"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."
But, according to slashdot "The money's not in hardware anymore" and "Big hardware companies need to seriously change their outlook" Plus "it will eventually be done with a PC cheaply" anyway.
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
Do you also blame the paperclip and staple manufacturers for aiding the Nazis in managing their documents in the death camps? The pipe makers for helping to build the gas chambers?
The problem is that any tool has both good and bad uses. The fault does not lie with people who make and sell tools, but with those who directly harm others, and those who stand by and let it happen. If the German people had started a mass revolt over being tracked and catalogued like farm animals by the government, it wouldn't have mattered which company's logo was on the computer.
Obfuscating moral issues by displacing blame onto inanimate objects is stupid. It may comfort you to think that by banning or controlling things you can also control people and make them stop doing evil, but it doesn't work.
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.
I'm one of them. Granted, there aren't many of us, but that's the whole point of IBM's announcement. They have realized that there is a skills deficit in good mainframe programmers, and they are taking steps to address that.
Of course, I owe my mainframe skills to the fact that I work for IBM.
"I disapprove of what you say, but I will defend to the death your right to say it."
- Evelyn Beatrice Hall
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.
What I liked best about m/f is they were never down while I worked. The o/s is in a separate partition from the users and nothing can stop that train. Furthermore, the packed decimal arithmetic is best for business and financial apps.
With the big push towards web-deliverable apps, and thin-clients, the processing power has to come from somewhere. If its not going to be the end user, the logical place is a step back towards mainfraims.
Hurray web 2.0!
ALC ...and any other A-list languages as I think of them.
Algol
Ada
IBM's party line has always been that high performance, ultra-reliable machines are "mainframes" regardless of if they are running 370 code or a bunch of LPARs with Linux in them or if its a bunch of UNIX machines in a redundant cluster or a massivley parallel machine. There is a class of computing where reliaibilty and uptime are key, that's mainframe computing.
I'd argue that this is often a bit different than many cluster architectures. If google hiccups and doesn't return a result for one in 100,000 pages and you just hit reload and see your page, not too many people will complain. If it takes a few weeks to index a web site, the world will somehow continue. If the machine that is processing your backrecords "loses" a couple transactions, it's a really big deal. That's a cluster vs. a mainframe.
Will IBM's mainframes become more popular? I expect so. The cheaper, faster, throw away cluster idea is nice and it works for a lot of things but as it grows the costs of administrating and dealing with it grow too. As does the power consumption and space requirements. Having one $200k computer with 20 LPARs running different servers and services all in one place has some nice aspects to it.
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
Is that spelling intentional, or did you mean "insightful"?
Next we have the come back of the Mini??, Maybe I better incorporate and name my new company Digital Equipment or Data General?
Maybe the world get tired of Window infamous blue screen?
I 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.
If it doesn't run Windows, most companies won't want it. They spent all their money migrating away from Unix big iron, because Gartner showed them a study saying it was cheaper, and now they're too broke to do another switch. All they can afford are high school dropouts with an MCSE, and they're they last people who want near a mainframe.
Don't blame me, I didn't vote for either of them!
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.
Yes, of cource IBM will be happy to provide you with training, programmers, analysts, whatever - after all, this can be one of their secondary interests on this "mainframe revival": the perenial support costs. (one should't turn down mainframes or IBM's offers based on that, it's not supposed to be a troll - but it *is* a fact that the happiest entity in mainframe culture is always the mainframe seller, because they seem to have *huge* profits doing business related to keep the mainframe up and running - who knows if they don't make more money on that than by selling or renting the mainframe itself?)
I believe he meant in the sense of "incite". As in: "That man was inciting a riot". (I think this spelling is correct?)
...I'm seeing that even Unisys is providing a native JVM for its Unisys Clearpath IX/Dorado line (2200-series), which means if one is willing to spend the money on licensing fees then one can run Java code natively on their big iron.
I'd love to be able to do that. Sadly, I suspect the licensing costs are far too expensive for my employer to seriously consider.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
"Some IBM mainframes have CPUs that do every instruction twice in parallel (different cores on the chip)......That kind of thing just doesn't exist in traditional architectures."
???? Umm... which traditional architectures are you referring to?
From the '60s? The 70s?
Gosh! Those newfangled mainframes!
Yep, just sad but true.
When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
Thank you for posting this. This was actually very concise and informative, at least for me (I'm a dev with no mainframe experience).
I do not have any mod points now, but I really hope someone mods this as Informative.
It is certainly more useful than the 'mainframes are awesome' vs 'cluster are th3 rock' posts that pop up all over the place.
Freedom is the freedom to say 2+2=4, everything else follows...
Of course there are still a few hurdles; it's not the amount of CPU's that set a mainframe apart from clustered UNIX nodes; it's throughput and reliability; your bus and your backup, in other words. In commodity hardware-land, and in open-source software-land we're on the verge of getting all that goodness, though.
It never went away. We're currently working on a big project with over 100 people using Cool:Gen (i think its called Allfusion:Gen nowadays). Its a 4th generation language that doesnt require much knowledge of mainframes or any knowledge of cobol. Most of our programmers (im not a programmer though) dont know a line of cobol yet they do code for mainframe. Debugging and tracing can be done without cobol knowledge too. See http://www3.ca.com/solutions/Product.aspx?ID=256 (disclaimer: i do not work for Computer Associates)
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
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
There's one aspect of mainframes that, as of 2003 at my old company, was still in place: charge by the *cycle*. IBM mainframes have done this for years (I believe the 360 had an actual odometer, and an IBM rep would come in and read the number and preparae the invoice based on that).
It may not be every application, but I know that IBM's MQSeries product (now called WebsphereMQ, I believe) had a per-cycle cost on big iron (on top of some huge monthly maintenance fee). I know this because I wrote some middleware to go between MQ and a webserver, and for a week I was testing it and we got hit with a $10k bill.
I think mainframes are amazing machines, but they're also the gift that keeps on giving...to IBM. It's my understanding that a certain amount of backlash against mainframes in general (besides punch cards) was that you were charged to use the machine, regardless of whether or not your program compiled, ran, etc....every pass through the compiler, every load, every output, was $$$.
If they were aware of what their products were being used for and could have stopped their supply, then yes. The only difference is that I suspect the holocaust would not have ground to a halt for lack of paperclips, so their non co-operation would have been nothing more than symbolic, whereas IBM's (or more precisely Dehomag's - they kept the pretense of being a true Germanic company to please the Nazis and to keep IBM's involement out of the public eye) equipment and staff were absolutely crucial in the analysing and tracking of undesirables within the state. Without IBM's help, the persecution of the Jews and others would still have gone ahead, but it would almost certainly not have been at anywhere near the same scale as it was.
This is not a case of Germany having bought some IBM kit and people then blaming the inventors for this. It was Dehomag staff that designed and carried out large parts of the various censuses that were done in Germany during that period, and IBM management that took the money, knowing full well that the information was being used to round people up.
Recently I heard about a bank in China whose on-line system grew (or is growing -- don't remember which) from zero to 340 million user accounts in three years. This was from a technical guy who consulted on the project. One weekend they added 24 million accounts, no problem. Mainframes make a lot of sense at this scale for many reasons: low cost-per-transaction, great security, hardware and software scalability, data security, low latency with data and application program proximity, and a much lower growth curve of administration cost and effort as systems grow compared to other HW/SW platforms.
As Chinese companies create world-class IT infrastructure, the size and scale is mind-boggling. And this is before considering web commerce, which is still largely undeveloped.
This is where a discipline came from -- long since forgotten by most of the Windoze crowd -- called "light and tight". Code was written for efficiency ... a seemingly long-lost art. This discipline's antithesis is called "bloatware".
C++ apps -- yes, they run on the m/f -- tend towards the bloatware side.
To those who say the CPU clocks aren't fast enough: hold on. It's coming. The mainframe CPU will always lose the clock war to microprocessor units (their manufacturers care about clock wars, IBM doesn't); but the latest & greatest (z9-109) has a clock speed in excess of 1 GHz. As good as or better than what a lot of Windoze boxen are running these days.
If you're a Linux programmer (or Java programmer, for that matter) you're already a mainframe programmer.
My boss is an AS/400 bigot for good reasons - it just works. We have a main Windows Server 2003 server that most users connect to via thin clients. It and our other servers have problems regularly. Our AS/400 (or iSeries or System i) has not gone down unless we brought it down since we got it in 1993!
How about licensing z/OS? Thousands do. Or you can run Linux on the P390.
High priced analysts keep pointing out the absurdity of how companies levy chargebacks. I think Meta Group estimated that mainframe chargebacks are about triple what they really should be, on average. (In your case you could be way above the average. Test work, particularly at a low service class, shouldn't really get charged much at all.)
One interesting side effect for companies that can't come up with rational chargebacks (or get rid of them entirely if they have other, better cost accounting) is that the worst of them tend to sign outsourcing contracts. Eventually CEO-types say, "Enough" with an IT organization that has no clue what its own true costs are, and she/he outsources the whole rancid bunch.
By the way, I'm frankly puzzled by the reputation of mainframes as only being able to run old technology. The only thing that distinguishes a mainframe (in terms of modern code compatibility) from any other server is that the old code doesn't break, by design. If you've got a piece of 40 year old code (literally) that you still like, that's still useful, you can still run it. But you can run it alongside 64-bit Java or Linux code that you wrote 5 minutes ago. And the old code and new code can interact in lots of different ways, all with careful protections of course so that everything runs smoothly. Mainframes are as old or as new as you want them to be -- it's entirely, completely your operational choice. If something is old, no longer useful, and your company is still running it, no problem -- get something new. The mainframe will run it.
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;
...We have been here for years...
Seriously IBM has been insiting the mainframe has been the only platform for business computing. The eb and flow of the industry has agreed and disagreed. (Thin Client of the late 90's) This isn't news, the tide is just returning, it will go back out soon enough.
"Tempt not a desperate man" - Willy S.
That is entirely your company's decision. There is absolutely no technical reason why a weekly -- or any -- reboot is required, especially one triggering any sort of service interruption. Somebody decided about 30 years ago to implement that operational policy, and no one in your operations center has ever bothered to update the procedure manual. It's probably that simple.
I met with a construction equipment manufacturer that did the same thing. Somebody in another department asked, "Why are we doing this? We need the Web site to be up all the time. Mainframe is down every week. Maybe we should move this to a PC...." And the operations people replied, in about 2 seconds, "No problem. You now have continuous service." They just stopped rebooting each weekend. Now they never do.
Indeed there are some application designs that require an outage because of a coding decision somebody made, usually long ago. These are called "batch windows" on mainframes, when a particular application or part of a system is "down" (unavailable to a user) because a batch process is updating some of that application's files. But again, there's nothing requiring perpetuation of that sort of application design. Everything supports fully continuous online access...and has for at least 20 years. Even the "classic" environments like IMS (with online reorg and HALDB) support 24x7 online.
Mainframe sales for IBM have grown consistently over the years. They still are growing, year-to-year, when you smooth out the random ups and downs caused by a smaller customer base.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
It's even better than that, actually. Since one does pay for z/OS that might ordinarily be an issue, but Java on IBM z/OS has its own accelerator called zAAP. The zAAPs are dedicated Java processors, and there is no software license charge for any zAAP processors. Roughly speaking it brings the actual, full cost of running Java rather close to optimized COBOL. Cheap, in other words.
Not really. On Linux it's the same as any other Linux -- cron or whatever. On z/OS it's the same as z/OS, particularly when you use JZOS. On WebSphere Application Server it's the same as WebSphere Application Server. What would be really weird is if scheduling was different than scheduling anything else in your chosen runtime environment.
Of course scheduling on z/OS is different than scheduling on, say, Microsoft Windows. For one thing it actually works. :-) But I wouldn't call it weird.
Well, for z/VSE it is. But that's the fun part, that there are at least five operating systems available for IBM mainframes, and if you want one where TCP/IP is optional you can get one that way. The whole reason it's optional is that you can choose from among at least two different TCP/IP stacks for z/VSE. Choice is good.
As with hundreds of foreign-owned companies that did business in Germany at that time, Dehomag came under the control of Nazi authorities prior to and during World War II.
The same is true of, say, Ford. Did Ford also have a role in the Holocaust because its (seized by the Nazis) German subsidiary produced vehicles which probably transported SS officers to/from death camps? I'd say not, but perhaps you have another opinion.
Ever priced support costs for anything else? Mainframes are cheap. Really cheap. And you actually get real support.
First of all, a single System z9 mainframe has up to 54 main processors, not 32. And you can buy more than one of them. There's no rule that says you can't. If you want 108, buy two mainframes, and two costs much less than 2X one.
Those 54 main processors actually have a couple hundred or so secondary processors in support for I/O, cryptography, network, service assist, spares, etc. The 54 number is pretty deceptive, actually -- there's a lot of other silicon executing instructions, too.
And now here's the interesting bit: those 54 processors typically run 90+ percent busy 24x7x365. And about all they do is real work (business logic), not stupid stuff like loading bytes from a disk or pushing bytes onto a network. And it's a super-CISC design -- there are some monster instructions on those processors which aren't just adding two numbers together.
Another interesting fact is that all your applications and data are co-resident. You don't have to take network hops from your application to your database cluster. This means incredible efficiency, so those 54 mains get an awful lot of work done with your typical applications.
Then there's cache. Gobs and gobs of it. It hits a LOT on mainframes, and it's available to all 54 processors. Does no good to one distributed processor if the instruction is over on another processor's cache. Mainframe processors rarely ever wait -- the philosophy is to keep them well fed at all times.
So, yeah, absolutely, those relatively few processors tear through a bunch of work and are real world competitive with the work that thousands of distributed processors can do with a typical, real world mix of business applications. If you're doing weather modeling or digital film rendering, no, but that's not what most businesses do.
Google also does not perform the same work as the original poster's example. The original poster assumed a query that was not pre-indexed. Roughly speaking this would be equivalent to asking Google to go crawl every Web site, live, on demand, at the instant you issue your request, then return an answer to you with current results. If the New York Times Web site posted a news story with the final score of a World Series baseball game one nanosecond before you pressed Enter to issue your query, that Web story would be in your search results.
Right now Google is running weeks behind in many cases, and that's with the planet's biggest computing electric and cooling bill. That level of performance may or may not be acceptable for Web searching, but it is definitely not acceptable for a whole class of business questions mainframes answer every day.
If it's Linux you can cross-compile quite easily with gcc.
Yet another relatively cheap option is to get one of those baby mainframes starting at $100,000 (a System z9 BC), run z/OS.e (which does everything you need for C/C++ development and is much, much less expensive), and hand that over to all your developers as reserved compile capacity. I'm assuming you're not already a z/OS.e shop and that it's cheaper to take this approach versus adding capacity to your existing mainframe (and service classing appropriately).
This is one area where Java is really nice.
Whatever, soon all your old mainframers will be retiring, then there WILL be a huge surge in demand for mainframe programming skills, only the newer generations of coders have no experience with it. All the companies that depend on big iron will be outsourcing their coding and support for mainframes.
Prior to late 2004 I'd agree with you re: Java piggishness, but IBM's zAAPs really changed Java on the mainframe quite radically. (In simple terms, zAAPs are Java accelerators.)
In all fairness, IBM does make supercomputers/HPC kit, but they're not the same as their mainframes. Probably a whole different internal division makes them; they're designed entirely differently.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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"
That's just not historically accurate. Remington Rand manufactured and sold punched card tabulating equipment in direct competition with IBM prior to (and after) World War II. (James Powers beat Hollerith to win most of the 1910 U.S. Census business, and the Powers Accounting Machine Corporation became part of Remington Rand in 1927.) Remington Rand equipment was available to the Nazis over the same period. The British Tabulating Machine Company's products were also available at the time. While it is true that BTM paid IBM royalties for patent rights, Remington Rand did not since they used a 45/90-column round hole card format instead of IBM's 80-column rectangular hole format. Remington Rand's format actually held more data per card and, although it's pure speculation, it's possible Remington Rand's format would have helped the Nazis more efficiently pursue their atrocities.
Germany also lead the world in computing technology before the war and well into it and thus had plenty of domestic capability (on top of Dehomag and any German Remington Rand and BTM assets). Konrad Zuse finished the Z1 by 1938, in particular. Fortunately the Nazis were slow to understand what they had in Zuse's work.
It's also worth nothing that the lawyers who filed against IBM in U.S. court, alleging that IBM had responsibility for Dehomag's assistance to the Nazis during World War II, dropped their own lawsuit two months after filing it. There is another lawsuit still pending in Swiss courts, filed by lawyers representing five gypsies. IBM says the case is without merit.
Many mainframe systems can process orders of magnitude more transactions than your typical *nix system running Oracle
The key word is 'typical'. One of the reasons the mainframe excels is twofold: higher-performing, tighter-coupled databases (VSAM or IMS) and the long standing discipline of true performance analysis and capacity planning that barely exists in the open systems / distributed world.
If looking at the merits and capabilities of the software itself, a well designed SMP or clustered *nix envrionment with Oracle can run rings around mainframes. The reliability of a store like Amazon is worth millions a second. Google too. Likely their financial (perhaps not liability) exposure is similar to those that traditionally use mainframes. The issue tends to be that most admins and architects thrown at these things are have very compartmentalized specialities (OS guys don't talk to Oracle guys don't talk to sw guys don't talk to network guys), so you get a culture of finger pointing.
Of course, bad planning hit mainframe environments too -- I've heard a story of one environment whose multiple regions were polluted by a shared SAN between dev and production. A dev Linux blade cluster started pumping WebSphere MQ messages into the dev mainframe LPAR with a bad format, which was generating log messages at the rate of 5 MB/second, frantically requiring the mainframe admins to delete logs every few seconds to hopefully not overwhelm production with a disk full error.
-Stu