Slashdot Mirror
Why The Dinosaurs Won't Die
DaveAtFraud writes "Ace's Hardware has a nice introductory article to the animal that will not die: The Mainframe. Ever wonder why these things are still around and what makes them different from a PC or UNIX box? The article is IBM-centric so there's no discussion of say the CDC Cyber series but when most people don't even believe that mainframes exist anymore, what the hay, let's disabuse them of that notion first. Hopefully, the author will follow up with the additional promised articles that go into more technical detail but this is a good place to start. I wonder if they still make card readers, too?" This guide came out last month, but it's worth looking through, even just for the pictures.
A beowulf cluster of mainframes
I wonder if there is a Moore's law equivalent for computer shrinkage rates. Would miniaturization be a good measure for progress?
But there is an interesting possibility arriving from the PC world: clusters. PC hardware is so staggeringly cheap that it's becomming viable to run enterprise applications accross clusters of PC's, viewing each PC as un-reliable and likely to fail.
:P.
Take google for example. Their software flags failed units, brings them offline, and once a week they go pull them out of the racks and replace them. I believe google builds their own, but for less agressive businesses you could just buy enough dell to tolerate as many failures as needed, boxing them up and shipping them back to dell when they go south. Heck, dell will likely send you back an upgraded unit anyhow, so you get a rolling upgrade
Just like the network guys learned the lesson of ensuring end to end reliability accross an unreliable network using TCP/IP, some companies are realizing that reliable computing can be enabled by clusters of pc's. It's a shame the free software/open source crowd hasn't rallied around this more... supporting this at the OS level could prove very powerful.
For a good example of what I mean, compare Traakan's SAN systems to more traditional products, like from EMC.
The theory of relativity doesn't work right in Arkansas.
Remember that IBM commercial showing the whole server room with mainframs and all being replaced by one small IBM linux box? Sounds like that is IBMs dream, not reality.
I talk to people all the time who can't believe that mainframes are still essential to our info infrastructure. I'm going to start sending them to this site. Any other suggestions for good primers, especially ones this short and sweet?
I really liked this line in the section about modern IBM mainframe reliability:
Each CPU die contains two complete execution pipelines that execute each instruction simultaneously. If the results of the two pipelines are not identical, the CPU state is regressed, and the instruction retried. If the retry again fails, the original CPU state is saved, and a spare CPU is activated and loaded with the saved state data. This CPU now resumes the work that was being performed by the failed chip.
Try that with your dual-Xeon server!
Ever wonder why these things are still around
Mainframes aren't dinosaurs, and never were. They are the most advanced, most capable hardware available, and the proving ground for architectural innovations that eventually filter their way down into workstations (like using a crossbar switch instead of a primitive bus). Sun's dynamic systems domains, considered very advanced by the Unix world are still many years behind the mainframe LPARs, and Sysplex makes SunCluster look like a silly toy. User-mode Linux and Beowulf don't even come close.
Really, you should be asking why obsolete technologies such as the bus are still used in PCs, and why PC technology lags so far behind "real" computers.
how many of us have walked into a bank, an insurance company, telco, a large parts wholesaler (any industry) or any other heavy user of 'serious IT' hand seen the clerk using either an original green screen IBM 3270 terminal or a PC running a terminal emulator?
The IT industry has moved on, but these sorts of comapnies are very stuck in a 'if it aint broke, don't fix it' attitude (especially banks).
Whatever the reason (technically valid or not) the managers of these dinosaurs can't see that their 100,000 sessions or whatever it is running at all - even if their hugely custom software ran at all - using a huge cluster of cheap PC servers (oh look, we're back to a mainframe again!)
I think I'll be getting my power, insurance, phone bill, bank statements, car registration bills generated with one these old machines for a very, very long time to come.
Can you say "banks"?
When an hour of downtime would cost you millions of dollars, no question about it: you get a mainframe.
For the ones who don't read the article, a quick excerpt so you know what kind of availability we are talking about:
"[...] today's [mainframe] systems [are] so reliable that it is extremely rare to hear of any hardware related system outage. There is such an extremely high level of redundancy and error checking in these systems that there are very few scenarios, short of a Vogon Constructor fleet flying through your datacenter, which can cause a system outage. Each CPU die contains two complete execution pipelines that execute each instruction simultaneously. If the results of the two pipelines are not identical, the CPU state is regressed, and the instruction retried. If the retry again fails, the original CPU state is saved, and a spare CPU is activated and loaded with the saved state data. This CPU now resumes the work that was being performed by the failed chip. Memory chips, memory busses, I/O channels, power supplies, etc. all are either redundant in design, or have corresponding spares which can be can be put into use dynamically. Some of these failures may cause some marginal loss in performance, but they will not cause the failure of any unit of work in the system."
I code, therefore I am.
the reason they won't yet die is that they are incredibly reliable. If you need a computer that has to work all the time you need a mainframe.
I agree with your first statement. I strongly disagree with your second. It doesn't follow from the first, logically speaking, and evidence proves you wrong anyways. I administer 8 Linux boxes in a rack at my hosting center. They are made by HP. They each cost less than $2k. As of yesterday, their uptimes vary from 382 days to 651 days. As an example, one of them hasn't been touched since it was turned on and put into full production service 651 days ago. It runs an Oracle database that serves 400+ staff in two offices. No hiccups. Linux is rock solid even if you only half know what you're doing. (I'm no wizard, I assure you.) As for the hardware itself, well, the disks are hot-swappable and mirrored. The machines have two power supplies each. One of the boxes will serve as a temporary hot failover if any one of the other machines experiences disk or power supply problems. This process has been tested, and works magically well.
Welcome to 2002, my old operator friend. As you said, you're a "former" computer operator. Mainframes are great and maybe a few applications need them. But if you need a computer today that has to work all the time, you better open your eyes to the other options because they work for the vast majority of 24/7 requirements that I've seen.
IBM and others have demonstrated the ability of mainframes to act as virtual machines, using hardware monitor techniques a la VMWare, to simultaneously run thousands of copies of Linux, AIX, or other OSes. Because each OS is running ON TOP of virtualized hardware, the security is pretty much airtight, and it's just like having thousands of actual machines without dealing with the space, etc. issues.
This technology seems quite promising for data centers, etc, and will probably ensure the mainframe stays around for a long time to come.
There's 10 types of people in this world, those who understand binary and those who don't.
working, stable and extremely mission-critical apps for very large and established corporations...That are oftimes bloody expensive to have any downtown in, let alone enough to verify a changover to a new system.
Locally, one of the larger local businesses has an old beastie made of wires and PCB that can not be shut down? Reason, to turn off the apparatus it's connected to would require a lot of work to get it warmed up again, and having that particular apparatus off would probably mean shutting the entire plant for a certain period of time...
a.k.a, not something you want to mess with unless you've tested, and tested, and tested, and scenarioed, and prayed a few times before frantically moving things over to whatever the new configuration is.
And in such times, isn't it murphey's law that you end up with an event like "what do you mean you forgot the power cable at the office?!!!" just before/when going live.
Really.
Have a cluster run 100,000 transactions at the same time as well as batch jobs and 1000 JCL scripts. Plus 10,000 concurrent users.
Oopps, was that the cluster melting down?
Mainframes have their purposes and these are
- Ultimate in reliabilty
- Ultimate in I/O operations.
Horses for course ye of short sight. Work ith a Mainframe for it's intended purpose and you will realise why PC based just do not cut it.
In 1998 I had the opportunity to take a tour of six hockey-rink sized rooms of mainframes and tape drives used by one of the main US travel reservation systems. In reality there weren't that many actual mainframes - most of the space was taken up by tape drives. Above every machine was a sign specifying the machine's MIPS rating.
The signs had numbers like 20, 43, sometimes as high as 60. The employees were especially proud of the 60s, explaining that each one cost more than 1 million dollars.
At first I assumed I must not have understood. I asked whether MIPS really stood for millions of instructions per second. They said yes. Then I asked what kind of instructions they meant: things like add, load, etc? Yes.
Finally I pointed out that my (at that time) $4000 dual 200 mhz Pentium Pro was rated at much more than 60 MIPS. I don't think they quite comprehended this.
By now every travel reservation system is ditching mainframes as fast as they possibly can and replacing them with racks of PCs or medium-end Unix workstations. By spending 1/50th as much money they get orders of magnitude more useful computation: those nice low-fare-searches you see on Orbitz and Expedia run on PCs, not mainframes. I've been in all the other travel reservation systems complexes since my 1998 visit and more and more you find little stacks of cheap "low end" machines doing the heavy lifting.
The reliabilty claims for mainframes are very deceptive. Yes, the computers stay up. But the software has bugs just like any software and data lines go down and the mainframes start dropping transactions left and right when they're overloaded. DASD's are multiported but top out at some low number just as any multiported device does, so mainframe-based databases often can't be extended beyond some point because the database drives simply can't be connected to any more machines. In the PC world we'd buy more machines and drives and maybe live with a little data incoherency but in the mainframe world eventually things just die because the hardware was built for everything but cheapness and power.
The general mainframe design is essentially targeted at the application profile of a static-page webserver. Simple programs, quick data access and throughput, no computation. They are utterly unsuitable for any computationally demanding task.
I used to do client/server programming at a health care provider that employed over 20,000 people. The few apps that used Oracle were completely insigificant - EVERYTHING was on the AS/400. And they had a lot of AS/400's. In fact, they were buying MORE AS/400's. They were even planning on spending millions of dollars on a few very large AS/400's to replace several of the smaller AS/400's.
Why in the world would they still be using something so ancient? Legacy, man. "Back in the day", they started using AS/400's, and since everything was running on them, they just kept getting more and more of them. I'm sure that they're not the only ones that keep pumping millions of dollars per year into "Big Blue"'s coffers just because the idea of switching over is too daunting.
Of course, at the company I presently work for, we've done all of our CGI programming in Perl. We haven't found any reason to switch to anything else, and likely never will - but even if we did, we still probably wouldn't. It's taken YEARS of our entire programming team working like feral weasels to produce the programming we have. Just picking it up and migrating would take at least as long. If you look at the number of programmers, taking 4 years of their time to reprogram everything would cost them nearly a million dollars. The scary part? A million bucks is NOTHING compared to the market share we'd lose if we just took 4 years off from improving our product.
Yeah, legacy has a lot more power than most people realize.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
And from the article:
The total I/O throughput capacity of the current z900 mainframes is no less than 24GB (that's bytes, not bits) per second. I have not personally had the opportunity to benchmark the performance on these latest systems, but while theoretical numbers can sometimes be misleading, I wouldn't be at all surprised to see a z900 performing as many as 100,000 I/O operations per second.
Immovable object, irresistable force, anyone?
dominionrd.blogspot.com - Restaurants on
Your idea is right, but your conclusion isn't. A mainframe is stable as hell... The application (a HMO's appointment handling system)running on it, will crash and burn like any other application.
So it doesn't answer really why mainframes are still around.
If anything could be said in detriment to mainframes, it could only be at the hardware level (like hotswapping CPUs, and IO devices), but Sun machines can already do that sort of stuff...
You've hit the nail on the head in your first line: "Huge quantities of data". A modern, bog-standard mainframe has 24 GigaBytes per second throughput, between CPU(s) and persistent storage
That's a lot.
Your CPU-RAM bus on your PC has less throughput (DDR-SDRAM 266 is CA. 2.1 GB/Sec), and your CPU-HD path (via DMA to RAM) is a not-very-funny-joke compared to it.
A cluster for similar throughput would hit the lightbulb problem (admin-monkeys running round swapping out burnt out PeeCees left-right-and-centre).
MAINFRAMES SHOVEL SO MUCH DATA IT'S NOT FUNNY.
And now Linux can run on them.
Be afraid.
Productivity went right in the toilet. The users, some of whom had only been in the department, and others who had been there from years could not use the new GUI with any degree of efficiency. Long-time coders and CLI users know how important it is to keep the hands on the keyboard. Data Entry people, and others have the same requirements.
Several versions of the new software have gone by, and the GUI has been modified over and over, each time becoming more keyboard friendly. But in the meantime, the department has wasted many dollars in training, re-training, development, and paying overtime on the weekends to catch up on the data entry tasks.
A good terminal application, with well-designed screens and a key-oriented approach was thrown out for the latest, lickable interface. Just because it's old, or ugly, or doesn't drag-n-drop, doesn't make it obsolete.
People are still buying the new mainframes and AS/400s (which should be lobbed in) especially now they run Java and new technologies.
Why ? Because of the support staff you require to run one. Is Unix harder than Windows 2000 are the people cheaper ? With these beasts its a mute question because YOU WON'T EMPLOY A SYSTEMS ADMIN for your server. You will outsource all of that to IBM, and they will make sure it works.
My favourite on this is being in a place with around 20 mainframes and AS/400s who had been asked to consider standardising on Windows going forwards. The IT manager's challenge to the sales guy was "How often does your stuff fail?" to which the sales guys asked "well when was the last time you had an expensive maintaince job on these servers".
The reply was that 4 years previously an IBM engineer had called to arrange a time to visit to replace a disk from the server which might fail soon. 2 years before that one had phoned to arrange a time to replace a processor board which was not performing correctly.
2 incidents on 20 machines in 10 years.
They elected not to move to Windows for infrastructure.
Then along came Java and suddenly you can buy these ultra-reliable boxes to run all of your newest and brightest applications.
Unix might whup windows, but OS/390 is Lennox Lewis standing at the back of the room with Ali smiling while they watch the little boys fight.
An Eye for an Eye will make the whole world blind - Gandhi
Not true. It's been a few years, but when I was using COBOL/CICS, I remember that we could use getmain/freemain to allocate/deallocate storage. COBOL II also had pointer datatypes.
You could also declare arrays using OCCURS DEPENDING ON. This would let you dynamically
set the size of an array. This also was usefull with variable length records being read
from files. Of course, if you needed to do something really tricky, it was very simple to
call a subroutine written in BAL (assembly), C, or any other language that was available.
The only problem with that approach - thousands of virtual Linuxes require hardware that costs much more than thousand PCs with Linuxes.
Well, maybe, but probably not as much as you think. And in the end, if you have thousands of little headaches. With the mainframe you have one big headache, which you pay somebody else to have.
Consier the following scenarios:
Scenario 1: User needs upgrade to memory and disk space.
PC solution: Order new disk and memory. Dispatch trained monkey to install them and hope he dosn't screw up.
Mainframe solution: enter a few commands telling the mainframe to grant more resources to the virtual server.
Sceanrio 2: Group needs a new server.
PC solution: Order new server. Unpack and install. Dispatch trained monkey to install and/or configure OS. Figure out the best way to patch it into your network and dispatch trained monkey to do so. Integrate it with your network backup scheme and test it to make sure it's working
Mainframe solution: Select one of several preconfigured disk images (will you need postres or mysql? Apache? SMB?) and tell the mainframe to create a new virtual server using that image.
Scenario 3: Computer user reports hardware failure on his server
PC solution: Dispatch trained hardware monkey to swap parts. Dispatch trained sysadmin monkey to make sure everything is OK.
Mainframe solution: none needed. The hardware doesn't fail. You made provision for power backup, lightning, earthquake and flood protection, backups for your datacenter, and you don't have to keep revisiting the problem.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
A comfort zone is important to large, monolithic organizations. What works, works. Why change the old and reliable for something new and untried?
Some of my best friends make their living writing COBOL for mainframes; attempts by their agencies or companies to move to "new" technologies have been costly in both time and resources. If a green bar report provides all the information an accountant needs, why rewrite the system to use fancy HTML output that adds nothing but pretty colors? If anything, many web based systems reduce the amount of information available to make room for lots of unproductive frippery.
I spent the first 10 years of my professional career in COBOL on mainframes and minis -- CDC Cybers, VAX clusters, Honeywells -- doing some pretty boring stuff. I moved into PC programming 15 years ago, and I prefer it for a number of reasons -- but I'm not blind to the realities of the bleeding edge and the stupidity of modern PC software design.
Mainframe applications tend to accomplish very basic tasks in a simple way; even 10 million line COBOL apps are pretty straight-forward. The focus is on reliability and accuracy, not buzzwords. PC developers have an alomost pathological lust for the bleeding edge -- which gives us pretty but buggy applications.
On the PC, amid an embarrassment of riches, with more languages and tools than we can enumerate, we constantly throw out the old to chase the new. Windows would be as reliable as a mainframe OS if Microsoft spent more time on QA and less on figuring out how to make curved corners on plastic-looking window borders.
All about me
Strings in C can be deadly things.
This should segfault nicely, without using any dynamic memory allocation (that I am aware of).
#include
#include
int main(void) {
char src[10];
char dest[5];
strcpy(src, "FooBar");
strcpy(dest,src);
printf("You'll never see this line.\n");
return 0;
}
I haven't done any COBOL development for the last 4 or 5 years, but I did a quick search and found the following 2 links. xml4cobol.com and xmlbooster.com. These are both commercial products. You might be able to link to a parser written in C, but I'm not sure if you'd want to go through the trouble. If you're a masochist, you could always write it yourself in COBOL. This would give you an opportunity to learn all of the string handling features that are available in the language. Of course it would probably also drive you insane by the time you finished!!
While COBOL is still the dominant language on the mainframe, keep in mind it's not the only language available. Last I knew, IBM had a C++ compiler for OS390 (VisualAge?), a java VM, even a J2EE application server(WebSphere). You can quite easily find XML parsers for C++ or Java. Of course, I know it's hard to obtain additional software licenses and get stuff installed on the mainframe in most companies...
This means that it isn't possible to split the option over several systems, it must match on one system in case of combination trades. If it happens to be a big day for that product (say Annual Report Time), then volume will be very high. If it is an interesting day for the economy, say election time, then whoops, there goes our performance across all products.
Now if a transaction should fail, it becomes very important (legally so) that all transactions are unwound in the order that they were made.
The distributed lock manager was rather a neat piece of technology that Digital came up with for clustering VMS. It is sufficiently neat that there is a project to try and emulate it for Linux, interestingly enough one project from IBM. It allows for five different levels of lock to be held on a resource and each lock to be associated with a value. VMS uses it extensively for their clustered file system (one of the better ones). We use it for hierarchical locking of the order books (each product, CALL/PUT and strike for options and expiry/delivery date combination). The order books are sorted in price/time priority.
I have built smaller/simpler systems for other markets using databases and PC servers, using modern techniques. However looking at the monstrosity that I started working on about 12 years ago, I can't think of radical improvements without changing the exchange regulations, particularly with regards to those pesky regulations. I guess the best would be to convert it to Linuz but run it in multiple VMs on a Z-series mainframe.
Your observations are very true about a lot of old text-based applications -- they may not be "intuitive" and will require some rote learning (a skill unfortunately no longer taught by our educational system) but once learned, they STAY learned, and nothing unpredictable ever happens. And with the better-designed apps, a particular key is ALWAYS the same function no matter where you are in the program. No rude suprises to disrupt your workflow.
BTW, the keystrokes for WordPerfect for DOS were taken partly from old mainframe conventions (I've been told that's why F7 is "Exit" in WP and many other apps).
~REZ~ #43301. Who'd fake being me anyway?
People who write mission critical apps for mainframes program differently. They wear both belts and suspenders in their code. They do precise error condition tracking and recording and when the app does crash, they make sure that the data was not corrupted so it can restart. They test for months (hell, years) before putting new versions into production. They basically program as if reliability is their number 1 priority - because it is - forsaking speed, code cleverness, memory space, anything that would get in the way of targeting less than 30 s. of downtime per year or better. Oh yeah, it makes development slower, too. That's the hardest thing about developing reliable software - the pace is different. Shipping tomorrow, but sacrificing reliability, will kill you in this market. A lot of PC folk don't understand that. Software written for these environments are built like tanks. They may not be pretty and they may not get you there as fast, but the will get you there come Hell or high water. And that's why people still use these systems - not hardware, not software - but combined systems of the two.
That is all.