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.
Nobody in their right mind is going to mess with them until they absolutely can't get strung along anymore, because they know that crashing, say, a HMO's appointment handling system would be what we call a "career limiting" move.
If it ain't broke, don't fix it. If it ain't broke and it's mission critical to the tune of millions of dollars an hour, avoid it like someone carrying the plague, ebola, leprosy, herpes and a bad hangnail.
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
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.
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!
...with the rotational energy of Douglas Adam's coffin. That was the most painful and continuous referencing-HHGTG-for-referencing's-sake I've read in a long time.
...the dinosaurs were already extinct.
Imagine...
:)
You're a big organisation thats been in business for 50+ years. You are in the biz of manufacturing Weezops (or whatever) for the various Gazaah(wtf?!) industries.
10-20 years ago you paid a big buttload of cash for a mainframe.
Today this main frame is chugging away. Occasionaly you need to screw in the vaccum tube, or maybe fill up the cooling liquid and in winter its a little noisy.
However, your little dino is happily chugging away, calculating whatever you want it and doing whatever it was that you got it for.
Its working. Its doing that you paid big cash for. You dont need it to make coffe, play videos, particpate in distributed.net or send spam. You want it to chug along. And its doign it.
Why change? Why pay another buttload of cash because someone is telling you "whoa, what you got here? an oversized heater?! pay another buttload of cash for this new machine that will do everything its doing PLUS play mp3s for you, make coffe, crack encryptions, search for ufos and connect your grandma to the net!"
I dont think so.
If a machine, no matter how old, is working, and you paid a lot of cash for it, no business will get rid of it to get something new just because its new/flashy.
Just like banks and credit card companies who still use systems like GlobeStar, 8 colors text based account management software written over 10 years ago. Why? because it does the job. Pull down menus, icons, angry slad shooting out of cdrom drives, live video straming, its all nice and cute, but if you have somethign that works, does the job the way you want it and how you want it, there's no need to change.
Sorry its so drawn out and long, but thats the way i see it. Plus I am sure you enjoyed the sleep
In words of a famous comedian, "Those are my ideals, if you dont like them, I have others"
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. Now, the software isn't the funnest thing to work with and you don't get pretty graphics (for the most part) but nothing can compare to its rock solid reliability. Another reason is that the hardware itself runs forever. Most of the older stuff still running was built to last. Unlike alot of today's hardware that is only built to last until it's obsolete.
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.
MAINFRAME repairs you!
I'm sure the humblest x86 can now run rings around old PDP 11 and IBM 360 systems, but it's still amazing how fast some parts of those old machines were, including core memory swap disks.
A feeling of having made the same mistake before: Deja Foobar
The commercial was actually of a room full of machines being replaced by a single mainframe, which from what I can tell was a zSeries 800 running Linux, which makes me wonder what the point of your post was.
The terminal interface is the most efficent human interface designed to date for data entry. I have never seen a GUI app that can come close to the user efficency of the ole mainframe terminal interfaces. That combined with the scalability, reliablity and ease of maintenence will insure that the mainframe will be around for yet a very long time.
Got Code?
Just post a link to one of those suckers on /. we'll see who won't die in a minute!!
I stole this Sig
Four decades of years ago a group of hyperjobless pantemporal employees at IBM got so fed up with the constant calls for tech support from moronic users... that they decided to sit down and solve their problems once and for all.
And to this end they built themselves and the world a stupendous supercomputer encased in a very large steel framed box the size of a small city. It was so amazingly intelligent that as soon as its DSADs had been connected up it started from I think therefore I am and managed to deduce the existence of P2P and the great wiki before anyone managed to turn it off.
On the day of the great turning-on, it said: "What is this great task for which I, the Mainframe, the second greatest computer in the Universe of Time and Space, have been called into existence?"
"The second ? There must be some mistake," said the programmer. "are you not a greater computer than the great Echelon at NSA which can predict acts of terrorism a year ahead in a picosecond?".
"The Echelon" said the Mainframe with unconcealed contempt. "A mere abacus - mention it not."
"What computer is this of which you speak?" he asked.
"The greatest computer in the universe", answered the mainframe after seven and a half years of comtemplation, "is the Beowulf ".
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.
My state library system still has it's database running off an old mainframe from the late 80's. The card catalog search terminals are these funky old greenscreens.
So a couple months ago I went to apply for a new library card (haven't used the system in like 10 years). When I turned in my application, the Librarian ran my info through the system and informed me that I had an eight dollar overdue book fine outstanding from 1987. Ouch. Place was pretty crowded, too, she could've said it in a quieter tone of voice...
Perhaps a punch card virus... Then again, perhaps it will be when the smartest people in the world succumb to the growing ideal of technology for technology's sake.
--"It's Bradford Company, slash your last name, dot your first name"
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.
So you need to tag every transaction with a unique sequence number. This is really, really difficult when you don't have a single system with an amazing I/O throughput to assign those numbers.
A Google type solution uses a lot of execution units each with limited I/O capability. Queries may be parallelised without much interaction. In my example, every transaction must be synchronised. It doesn't matter if the application is spread over a cluster, the nodes must still coordinate to assign the sequnce number.
I agree though with your point about adding better cluster management though to open source operating systems. However, this is much more difficult than improvements to a standalone system because how many people can afford to run a cluster of say 4 or more systems for playing around.
The argument for what I call economic inertia is a good one, especially with corporate shareholders these days demanding that management squeeze everything they can out of every dollar and stretch every last penny as far as it will go.
A mainframe that does everything that you need it to do (and more) and works well with your company processes is worth far more to you than the investment of time and resources in an untested, unknown system that may or may not work. Remember that new systems don't go online until after extensive use and testing in parallel with the current one (if it's done correctly). That means duplication of efforts and resources.
Anyone who has worked at a company that builds enterprise-scale applications or mission-critical solutions knows that when the customer has an XYZ mainframe, you'd better have applications that support XYZ or you'll find the contract goes to your competitor who does. It's not an option not to support it.
Unless there is a strong business case for moving to a newer technology, mainframes will be with us for quite a long time.
A hint to the coders out there: the number of people who know and understand these systems is declining. There's a mint to be made if you can deliver services to support them.
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.
I remember it used to be a cliche that "No-one ever got fired for buying IBM". Trouble is, I knew one IT manager in London who did get fired for doing just that at a Burroughs site.
...that point being that big iron is not about processing at all, but rather about manipulation of huge quantities of data that would choke even a beowulf of beowulf clusters in a matter of seconds.
But for those of you that still don't get it, here is a guide for the layperson:
It might be a mainframe if...
If you could kill someone by tipping it over on them, it might be a mainframe.
If the only "mouse" it has is the one living inside it, it might be a mainframe.
If you need earth-moving equipment to relocate it, it might be a mainframe.
If you've ever lost an oscilloscope inside of it, it might be a mainframe.
If it's big enough to be used as an apartment, it might be a mainframe.
If it has ever had a card-punch designed for it, it might be a mainframe.
If it weighs more than an RV, it might be a mainframe.
If lights in the neighborhood dim when it's powered up, it might be a mainframe.
If it arrived in its own moving van, it might be a mainframe.
If its disk platters are big enough to cook pizzas on, it might be a mainframe.
If Michael Jordan would need his entire annual salary to buy one, it might be a mainframe.
If keeping all of the manuals together creates a fire hazard, it might be a mainframe.
If it's so large that a dropped pen will slowly orbit it, it might be a mainframe.
If it's ever been mistaken for a refrigerator, (or if the disk drive
has ever been mistaken for a washing machine), it might be a mainframe.
If anyone has ever frozen to death in the room where it's kept, it might be a mainframe.
If it has a power supply that's bigger than your car, it might be a mainframe.
If it has its own postal code, it might be a mainframe.
If the operators considered the addition of COBOL to be an upgrade, it
might be a mainframe.
If it was designed before you were born, it might be a mainframe.
If its main power cable is thicker than your neck, it might be a mainframe.
If the designers have since died from old age, it might be a mainframe.
I keep hearing this, and it keeps making no sense.
If the application deployment guy and the firewall guy can't agree on whether to open the firewall port, the company has bigger problems. Somebody needs to be in charge.
In summary, using HTTP for the sole purpose of defeating firewalls is an arms race between two branches of IT. Now, arms races between competitors is what capitalism is all about ... but arms races within a company are pointless. You're supposed to be on the same team here! Instead you set up a situation where the app developers and the firewall admins both have to use increasingly sophisticated measures to do their jobs.
And don't give me that "but the firewall guy doesn't know how / can't be bothered to open up ports when we ask for them". That's his job. If nobody at the company has the time or skill to operate a firewall, you may as well not even have one.
I have to conclude that the real purpose of this whole fad of overloading HTTP with things that have nothing to do with HTTP is for deploy unauthorised applications - things the company doesn't know about and hasn't approved.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
The etymology of mainframe is incorrect in the article. While nowadays "mainframe" is indeed used to distinguish big lumps of computers from smaller ones, back in the day the "box" or "chassis" of even a microcomputer was originally called the "mainframe".
I have documentary evidence from the dawn of microcomputing to prove it. It was the Main Frame of the computer, to which one attached Peripherals. Microcomputers just had very small Main Frames.
Database design theory comes to mind.
The goal is to pick fields & tables such that:
1) Locking is minimal
2) Dependencies are minimal
3) Storage size is minimal
4) Records are meaningful
The main technique involves decomposing a database to a minimal architecture based upon all possible elements in the database, and then building it back from the basis to the desired state.
It gives you specific knowledge of the conditions by which transactions may require waiting and a way to characterize that waiting, as well as how to reduce the number of transactions you need for a given task.
Of course, that's just the database design theory that one can apply. There's also the distributed information theories that can be applied. The most primitive approach to this is to use time stamp semaphores, but it can be extended beyond that. There is actually an area of database dependency resolution devoted to making locks. I imagine the "distributed lock manager" you spoke of uses it to minimize the amount of information needed to be locked at any given node.
In both of these cases (distributed info theory and database design theory), the formalism sprang from necessity - people invented creative ways to improve how their mainframe worked, and they used the formalism to describe it. I think it might even be right to say that without using the CompSci theory, you probably won't get a terribly reliable system. You'll get a kludge - it'll work, if you're lucky.
Mod me down and I will become more powerful than you can possibly imagine!
I just got laid off from an operator position at a large, old company that has invested a lot of time and money into their IBM AS/400's. Not exactly mainframes, but it's the same idea. They have been there forever, they're doing their job, etc. No problems with the machines at all. The only problem is that the developers are nearly all in their 60's and will probably retire soon. And most of this generation (and probably the last one) don't even want to look at anything in COBOL, RPG, CL, or whatever the system's applications are developed with, much less make it a career. Eventually these things will die because nobody will know what to do with them. In 10 years it will be damn near impossible to find people who will work with anything that isn't GUI-based. Chris
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
... when the applications designs are flawed, turgid chunks of garbage that poorly attempt to mimic a bizarre corporate organizational structure that is changing next week.
Hardware design always has been (and probably always will be) WAY out in front of software design, and yet people are all too willing to spend the odd extra million on hardware while putting as little effort into software as possible.
In most companies they are clutching obsolete applications like life preservers, when in reality they are anchors.
The April 1998 Byte cover story has a graphic Why PCs Crash, and Mainframes Don't. It's interesting to see how little has changed in almost 5 years.
Best Slashdot Co
First, let me say you are being misled.
MIPS doesn't stand for million instructions per second. It stands for Meaningless Indicator of Processor Speed. IBM never liked publishing benchmarks for mainframes because they don't say the whole story.
Mainframes don't run one application. They run thousands at the same time. I/O requests, CPU, and device contention are just a few of the many factors in a machine's speed. Just look at your PC. If you get the fastest dual Pentium, that just tells CPU spped. Put a slow hard drive and a 2MB video card, and any PC will seem faster. Mainframes are the same way so IBM has always been reluctant to publish numbers because businesses scream.
As for the software being buggy you are exactly right. The difference is that some of that software has had 20-30 years to work out the bugs.
And finally, yes, you are correct in saying that computationally demanding tasks using floating point multiplication and division don't perform well on the mainframe. Most businesses don't need to compute PI, so it was never a priority to IBM. Floating point addition & subtraction are very very fast if you write your application correctly.
The really sad thing that holds processor speed back on the mainframes is the software licenses. On a mainframe, the faster the machine, the more your software costs. This made it possible for smaller companies to buy a little mainframe. The big customers pay the most. This means you never buy a bigger machine than you need, because the software license costs get more expensive and no business wasts money.
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
And how much I/O can your PC do? Or a cluster of PCs? Nowhere even close to what mainframes can handle... 24 GB/s -- take 96 Gigabit ethernet cards, stick them all in your PC (oh... you can't...), and then blast them at absolute maximum theoretical bandwidth.
Of course, if you want to be "realistic" you'll have to use 128 Gb ethernet interfaces, since the maximum realized bandwidth on a full duplex circuit is around 1.5 Gbps.
Oh... what's that? Your bus can't even handle the full bandwidth of a single Gigabit ethernet interface? Well, then I suppose your I/O is going to royally suck in comparison.
Oh, and let's not even get on the topic of reliability... PCs just aren't. I'm a PC guy (I shudder at the thought of having to deal with mainframes), but I know their limitations. And while you're dead wrong about travel reservation systems running on PC clusters (they don't - the entire backend system is still on mainframes), whoop de doo if it was run on PCs. This isn't something where a node going down would cause major problems.
If a node goes down on the air traffic control system, however, you can damn well bet there's problems. Big ones. Weighing several hundred tons, moving at a few hundred miles an hour, and disinclined to stay aloft while you take a few hours to get the system back up.
maybe live with a little data incoherency
Yes... a little data incoherency is no big deal. I'm sure the power grid will work just fine with a "little" incoherency. You don't mind a power plant (be it coal, nuke, whatever) having a massive cascade failure every couple years, right?
I have absolutely no desire to ever work on mainframes -- the software in place is largely old and crufty, but by god it works. The hardware isn't old crap either -- you can buy new machines that will run the old software perfectly. And have capabilities that us PC weenies can't even comprehend. You realize that virtually every advance in the PC industry was tested and proven in the mainframe world first, right?
In most companies they are clutching obsolete applications like life preservers, when in reality they are anchors.
God knows you're right! When I worked at very-large-retailer-to-be-unnamed in the IT department I was floored by how much crappy software they had built on top of their hardware. I can't remember how many times I thought, "Why not just use CVS?" or "Why do we have to use this thing?"
First, if you replace something that's working, even if it's working extremely ineffeciently, it might break. The perception of something breaking is about one trillion times worse to the PHBs and the execs than the perception of something working extremely ineffeciently, especially in a retail management mindset.
Second, especially if you have legions of data-entry people trained to use the extremely ineffecient software, then the cost to replace and retrain is higher in the short-term than to stay with the extremely inefficient system. PHBs and execs, especially in a retail mindset, can't thing about long-term cost savings in IT becuase IT is already a "cost center," not a "profit center."
In short, two reasons for bone-headed software in the enterprise: perception and cost. Mainly perception.
I don't make the rules. I just make fun of them.
Recently we added the ability for the students to pay their bills online via the web, taking a bold step into 1998, albeit four years late. In fact, we mainly only did it because another university in this state (the bigger one) did it, and we didn't want to look like we were behind. The software to do this literally just adds more layers to the mainframe process. That was easier than moving to a new system. While the seasoned web pro got to use ASP.NET and C#, I'm sitting here at the age of 25 writing COBOL from scratch to be able to post transactions he captures. That the process is disconnected and difficult to keep in sync no one seems to mind.
They say that we're getting a new, web-based system, "in about six months". I'm still not sure if this means no more mainframe, but apparently the project has been six months away for about two years now.
My coworkers fall into three categories - people younger than me who are still in school and are getting the heck out of here when they graduate, people my age who are married (like me) but they have kids and are completely stuck here, and people who are much older than me. One of my coworkers is literally a grandmother who codes COBOL and hates computers.
And that's really the big problem. I'm sure COBOL and Natural (a pseudo-scripting language for the ADABAS databases we use) are fine languages but you'd never know it by the way they're used here. I recieved no training once I got here - I was literally thrown in with a vague premise of further training, only to have the promiser go on to a better job. I was able to swim and get promoted within fifteen months.
People here aren't concerned with keeping their skillset up to date, they're more concerned with getting their kids to little league practice. The guy across the room from me is trying like hell to get a better job, but he's 56, divorced, in hellacious debt, he knows one thing (COBOL), and he steadfastly refuses to learn anything else. He's like the guy with a hammer who sees everything as a nail. He regularly gets turned down for jobs he's perfect for in favor of young, know nothing punks (like me).
A few months back (for some reason) they gave us VB.net training. While everyone in the room looked terrified of object oriented programming, I was making shit dance across the screen and rewriting everything in C# for kicks. That we're a 80% conservative university that's terrified of change doesn't help things either. My coworkers are mostly more concerned with keeping the new stuff out so that they don't have to learn anything new before they retire.
Now, I'm not saying that Mainframes are evil or that people's natural desire to stay the same is dragging anything down, but part of the reason Mainframes are still around is due to a complete reluctance to upgrade. Sure, at some point it will become inevitable, but most of my co-workers are ready and willing to put that off until after they retire.
And I'm not saying that everything should always be re-written in "flavor of the month" language to run on "hardware platform of the moment", that's not practical either. I mainly think we're seeing the results of a generation and a mentality that started at the low end of the Moore's Law curve and attacked it like any other job. People here don't see programming as a passion, but that thing they do until they go home (not unlike people who sell radio air time or something trivial like that).
As for me, I'm getting out of here as soon as I can.
Schnapple