Slashdot Mirror
Mainframe Techies Are A Dying Breed
dipfan writes "Great piece in today's Financial Times on the surprising survival of mainframes - but the problem in the US is finding experienced techies to run them: "55 per cent were over 50, compared with fewer than 10 per cent of those with Unix or Windows NT server skills." Cobol programers, still needed for legacy applications, are mostly in their 40s. Help is on the way, though, thanks to IBM's use of Linux, which "freshens the labor pool" according to the article." (See also this earlier post on the mainframe-operator labor pool.)
The word "legacy" keeps popping up in correlation with mainframes, and this is really why most of them are still around - legacy code that no one wants to re-do for other systems. However, new applications are typically being written for scalable, multi-component architectures, not mainframes.
The reasons for keeping the legacy systems are obvious: cost of conversion, proven correctness, etc. However, I still think the scalability and reliability (e.g.: redundancy, resource pooling, load balancing, etc.) of NoW (Networks of Workstations) will in time push both the mainframe and nearly anachronistic programming language Cobol out the door. It's a simple matter of economics: it costs less to design, construct, implement, maintain and re-tool the different components of a distributed system as opposed to that of a mainframe.
Culler's paper on NoW is a classic.
Exactly. It's also very much a chicken-and-egg problem to get into the mainframe world, becuase the barriers to entry are much higher from the standpoint of working on the technologies at home to get that all-important First Job. It's easy to build a $500 linux server or buy a $1000 used ultrasparc sun machine to learn some unix and unix coding on, but ... how are you going to learn mainframe stuff? Half of that stuff isn't even documented in the trade press (unless O'Reilly has come out with Mainframe Crap in a Nutshell or something and I just haven't noticed... heck, even the acronym set for that skill area is completely divergent from what most of the rest of the tech world uses. DASD anyone? IPL? MVS? JCL? RPG? OPA? XYZ?) The closest I've ever seen to being able to toy with that sort of thing at home would be something like Hercules or buying a used AS/400 off ebay for a few grand (which isn't a mainframe but a lot closer than a generibox linux server ;))
And even with trying to learn it at home, the production machines cost so much and are usually so business critical, you're going to have to really luck out to find a position where you'll ever even be allowed to touch the thing... On the flip side, I guess once you're in that world your job would be pretty stable, simply by virtue of the same barriers to entry in the field.
News for Geeks in Austin, TX
Now it's time to leave school and enter the real world...
.NET. So all the staff have to be retrained on .NET, at great expense and time. (But not us mainframe toads, of course, everybody KNOWS you can't teach a COBOL dog new tricks, just fire them when they've served their usefulness.)
I work for a financial institution. We run a fairly small IBM mainframe using OS/390. Our basic software for keeping up our loan accounts is 95% VS COBOL II and 5% Easytrieve Plus (a report writer language). Our files are straight VSAM--no databases to be found. Yes, it's antiquated, and yes, it works. We process information on about 150,000 loans nightly.
Several years ago, our CIO decided that mainframes are teh sux0r and that he wanted to replace it, and our COBOL loan systems, with "state-of-the-shelf" technology. He embarked on a four-year search to find a server-based system that could do what our users wanted and still process accruals, maintenance, and all the other assorted number-crunching on 150,000 loans, every night. Meanwhile, he decreed that all future development would be done using Microsoft technology--Windows NT/2000 as the platform, SQL Server as the database, Visual Basic 6.0 (!) as the language.
The first client/server development effort went twelve months over schedule and $2 million over budget. The second, in my programming group, only went in on time (but way overbudget) because we got some kick-ass VB6 programmers willing to work 75-hour weeks for 3 months. We quickly expanded to have a dizzying number of "data marts" and databases and report writers and little disconnected client/server apps...all of them fed by the mainframe. From nothing, we went to 300+ servers in 3 years at tremendous cost and tremendous headache.
Now, they are rewriting another bank system off COBOL--oh, but Microsoft no longer supports us using VB6/COM+, so now it's
Meanwhile, six of us keep those COBOL loan applications purring like an old Chrysler 225 slant six engine. It's not pretty, but by God, it works. Day after day after day, with no real drama, the numbers crunch and the money rolls in. They could be doing everything new still on the mainframe with some of the newer mainframe tools--but basically, our upper management has decided that Green Screens Are Evil. That's the only reason we're spending the money we're spending.
Oh yeah, that four-year journey for a replacement system? Ended in failure. No NT/W2000-based distributed system out there could even get close to the performance we required. Unix systems came closer, but Unix is a four-letter word around here--it's Microsoft or bust, baby, we ARE Bill Gates' bitch!
There's no substitute for a mainframe and COBOL when you've got to move huge amounts of data around on mission-critical financial systems, and do it with near-perfect reliability. Distributed systems don't have the rock-solid reliability, yet. They may someday, but not now.
So welcome to reality, Junior. COBOL isn't going anywhere anytime soon. Better pay attention in class! Either that, or learn to say, "Would you like a McTurnover with that?"
"Settle down, Beavis. We've got an experiment to do."