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.)
You know, I personally wouldn't mind learning Cobol, but I've got no place to "use" it on and develop anything that I'd find useful and therefore no way to both really "learn" it (gotta do an actual non-trivial project to really learn a language, no?) nor any reason to learn it "for" ("to possibly get a job" is no good).
And I personally wouldn't mind learning how to use a mainframe-type thing, but where am I going to find my own mainframe to muck about with? Everybody's got (or can get access to) a linux box to "learn Unix" on. Where on earth am I going to find an S/390? Try and get ahold of an Itanium with OpenVMS (which isn't really "mainframe" mainframe, is it?)?
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
maybe we can learn it on our own!
Yeah, thats it! I'll just buy myself a mainframe and...oh wait.
The problem is that the only way to get mainframe experience today is to have access to one.
Who does?
Still, I think the closest thing we can get is playing with Linux from the ground up. As a Solaris user, I can say that a lot of the internals are the same. Except, of course, that all the non-gnu versions of software suck compared to their Linux equivalents.
In fact, when I think about it, the biggest problem is employer disbelief. Can you admin Mainframes if you can admin Linux boxes? Pretty close:
-You can know NFS,AFS, and Samba
-You can know Apache
-You can know X11
-You can know sendmail/postfix
-You can know telnet/ssh/rsh
-You can know how to install security updates
I could be wrong, but I think the stuff that you don't know beyond this boils down to quirks that are dependent upon the specific mainframe.
Unless, of course, you're talking about those really old mainframes that do less than my computers do (though they're more reliable), and serve only one very, very specific purpose. For those I should think it would be obvious why there aren't more people working on it. It's way too specialized. You want somebody that knows the accounting system for one bank on a VAX that was put there in 1975 and hasn't been changed since? Talk to the guy that wrote it. How will anyone else know?
Mod me down and I will become more powerful than you can possibly imagine!
And show me one linux app that's written in COBOL. (The language exists, but I've never seen it put to use).
I've worked in banks/credit unions my entire career, and this is my take.
In my experience, a LOT of financial software is written in COBOL.
I'm not talking about Quicken, I'm talking about the applications which take in hundreds of thousands of transactions in databases which boggle the mind.
I know for a fact that the core processing portion of ITI Software is written mainly in COBOL, as I ran the server there for over 4 years. I won't call it a mainframe (even though the superiors did) because the software package ran in Win2k Server using some really odd "MCP" (Master Control Program) stuff that is by far the most picky, strangely configured software I've ever come across. These "mainframes" were sold and configured by Unisys, who are definitely in bed with ITI as far as hardware/software support is concerned.
Most of the database per se is large "Flat Files", just a long stream of 0's and 1's and other data, seperated by special characters. During the daily processing of checks and various transactions, these files are updated, and it is these files which are utilized during daily operation.
It's a terribly arcane way of doing things, but if it ain't broke...
You'd also be surprised at the amount of robust win32 software that is written to interact with such dinosaur programming.
When I first encountered this system (where you have to enter process numbers and "AX" to send commands: for example "1234AX Y" to answer a y or n question a cobol program asks for) I thought they were kidding. Nope, this is how some banks actually process work, transactions, and reports/statements.
Also, any COBOL programmer made a FORTUNE with the whole Y2K thing. I know I specifically lost many days of my life in testing, especially with the federal government in utilizing their old DOS software (FEDLINE) and testing for year 2000 compliance.
I was sitting with an 11th grader yesterday looking through the catalogs of some nearby technical colleges. I think the kid would be a really good sys admin for some serious hardware, but the tech schools seem to be focusing on PC stuff. The only thing I could figure out was that you'd have to start with the generic training in school and then go to Sun or IBM for more specific sysadmin training (in addition to the learning on the job track).
What path would a kid take to get into real datacenter hardware?
Look how many geeks out there are *INTERESTED* in the idea, and would like to learn about it...
But as you said, we "obviously have no idea how it works" because it's hard to find out! The mainframe world is a separate place, secret, etc.
So how do we change that?
And is mainframe admin worth it financially?
In another 20-30 years, they will be saying this about Java and C++ programmers. Sometimes I feel like putting down money on which 20-something pierced and tattoo'd open systems nut is going to become the 50-year old curmudgeon.
"dope will get you through times of no money better than money will get you through times of no dope"
I find it funny that all you Java/C++ coders are upset about not being able to learn COBOL to land mainframe jobs.
I just finished taking a Java course so I could have a way out of my COBOL-dreary job.
The grass is always greener...
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."