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.)
I think being a mainframe admin would be a blast (maybe I just don't know better), but in my eight years of sysadmin work, I've never touched a mainframe. Every job posting I recall coming across required previous experience.
How does linux freshen the mainframe labor pool, and not the Unix/Windows NT pool?
Linux ain't System/36 or MPE or any other mainframe OS. And show me one linux app that's written in COBOL. (The language exists, but I've never seen it put to use).
This is a self correcting problem. A good admin/coder can pick up mainframe stuff when he needs to. All the 50+ year olds are still working the jobs they got when they were 30. When they die off/retire, younger folks will pick it up.
I mean, hell, I picked up enough about MPE and FORTRAN and COBOL to do my job inside of a week. And I got competent with S/36 and RPG at my last job.
It aint rocket science. It's like a skilled machinist learning to shoe horses.
I don't need no instructions to know how to rock!!!!
What's the problem, here? If the 50-year-old programmer is the only one who knows jack about mainframes, hire the 50-year-old programmer. Don't whine about not having enough qualified programmers, when what you really want is just-out-of-college programmers that you can bully into working for you at half the salary of someone with real experience.
!#@%*)anks for hanging up the phone, dear.
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.
Mainframe Techies are a dime a dozen--the real challenge is finding competent PDP8/E techies these days!
Plunk your modern so-called "computer whiz" in front of one, and their first reaction is invariably one of the following:
Obliteracy: Words with explosions
As others have noted, the biggest hurdle is that there's no good way for an interested geek to learn firsthand about mainframe systems and OSes. While Hercules takes care of the hardware, at least enough for people to run something to learn on, the same isn't true for the operating system. Modern IBM OSes are hideously expensive, for an individual (unless you're Bill the Gates), and there's been some persistent comments that they won't license them on Hercules anyway (although I have no direct knowledge of this, either way).
I've been advocating a hobbyist license for IBM OSes for use by individuals with Hercules for some time now. There's a white paper at http://www.conmicro.cx/ibmhobbyistlic.html. Aside from a few curmudgeons, and aside from the folks at IBM who make the decisions, the reaction I've gotten to this paper has been uniformly positive. I believe that it would help slow the slide, at least.
In the meantime, the interested can get a running copy of the last public-domain version of MVS from the CBT Tape web page, which is a great resource for the mainframe community in general.
Disinfect the GNU General Public Virus!
mainframe n. An obsolete device still used by thousands of obsolete companies serving billions of obsolete customers and making huge obsolete profits for their obsolete shareholders. And this year's run twice as fast as last year's.
pretty accurate.For the most part most of the things you list are at best peripheral - they are now appearing but are not mainstream.
Learn z/OS (or os370, MVS etc) and or one of the VM family. Study Rexx, JCL and RACF/ACF2 and a few of the common utilities such as IEFBR14, IEHLIST, IEBGENR, IEBPTPCH (there are hundreds more). That lot may get you a junior post, unless a company is running a linux partition on their machine the linux skills will be next to useless. An old fashioned site (most, I suspect) will have no perl, vi, emacs or anything you'd expect on a nix box, and there is no gui, interaction is screen based, probably using ISPF under TSO. Connectivity is probably still using SNA although tcp/ip may be a possibility.
Some of the m/f software I mention may have been superceded, but the new versions build on the old. IBM are, deliberately, rarely revolutionary, evolution is their strong point. They do their best to ensure old programs run on new machines wherever possible.
I hereby inform you that I have NOT been required to provide any decryption keys.
Good Question. The mainframe where I work is the SMALLEST piece of equipment on the machine room floor. The most space is taken up by huge racks of NT servers. The next most by a huge RS6000 complex. The mainframe is dwarfed by comparision. The biggest difference between a mainframe and a midrange box is IO. The mainframe IO is much different from PCI or SCSI that midranges use. On current mainframes, you can move 24 gig into or out of central memory every second (this is doubling in the next generation mainframe - the Z990). Try that on a RS6000.
The mainframe I work on does not run under unix, it runs under a proprietary OS which originally predates unix by at least a decade. The only thing it has in common with unix is that it uses a command-line interface.
NFS, AFS, Apache, X11, sendmail/postfix, ssh/rsh have no counterparts on this mainframe - if we need something like that then we interface to a linux/NT machine.
Samba does have an equivalent, but it looks totally different.
The machine can act as a Telnet server, if you allow that.
The normal connection software is via software that emulates their old terminals, several companies sell different emulators.
Some of your TCP/IP knowledge could be of use, but that is all. You obviously have no idea how the thing works or what it can do (just as I have very little idea of kernel internals, for example) and an employer would see that immediately.
I worked on these beasts for almost 20 years before being confronted with linux. I can write primitive bash and perl scripts, and configure+administer a server. This makes me the only person in the group who can and makes me a 'linux expert' (!), they are that different.
Mielipiteet omiani - Opinions personal, facts suspect.
Locomotives / freight trains are still used regularly. They serve a need that cannot be met with automobiles or even 18-wheelers. For Joe Sixpack and his family, an automobile is definitely a more efficient way to cross the country. For ABC Florist who relies on fresh cuttings, locomotives take too long - trucks are better. But for XYZ Furniture ordering fifty sofas, twenty-five coffee tables, one thousand various lamps, etc., it would take a large number of trucks (each having a driver to pay) vs. twelve cars in a freight train (one driver to pay).
There is a use for mainframes in particular industries - personal computers and servers aren't the be-all end-all answer to every computing need.
I was taking one day at a time, but then several days got together and ambushed me. (from a Rhymes with Orange comic)
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."