Mainframe Techies Are A Dying Breed 566
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.)
No place to experience/learn (Score:5, Interesting)
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?)?
Legacy (Score:5, Interesting)
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 [berkeley.edu]'s paper on NoW is a classic.
Re:Employers' fault... (Score:5, Interesting)
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.
Or... (Score:4, Interesting)
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?
Memories (Score:2, Interesting)
When the WANG died (Y2K!), they moved the application over to the Win32 side of things, but I was transferred to work with the IBM MVS mainframe that was used for another portion of the business. I still understand very little about the job that I did (mainly due to the ease of use that the Beta42 scheduled provided!), but remember hearing of how people that knew or were willing to learn the ins and outs of the mainframe were so few and far between. Eventually, I moved on to bigger and better things, but the mainframe still lives to this day and I've heard that they're having trouble finding decent operators:)
Aerospace is seeing this... (Score:3, Interesting)
Re:Mainframe development work (Score:5, Interesting)
Also, the long lifetime of the mainframes means there's an abundance of various applications that depends on them in all departmens of an organisation that use mainframes. Changing, (heck, even finding those applications
Also, much of the infrastructure in the airline, train and other similar industries are based on mainframes, and they won't switch anytime soon, since it would require massive investments and many, many rounds trying to get all the involved partnes to agree on a common platform.
So, that there is money to earn on mainframe platform is not surprising, but, at least from my view, most of it will be maintainance/integration.
solution (Score:3, Interesting)
Re:Huh? Stuffing FUD in there or what? (Score:2, Interesting)
Just goes to show why Management, Marketing and HR go to make up the axis of idiocy.
An engineer sees the problem of "we can't find experienced candidates" and comes up with the solution of "well, let's find some smart people and train them up".
Re:Huh? Stuffing FUD in there or what? (Score:5, Interesting)
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 [itiwnet.com] 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.
Re:Employers' fault... (Score:4, Interesting)
The SA people at my new job are all around 60, but that is not an issue because they are aiming to finish migrating away from the platform - even if it bankrupts them, and it cost my previous employer zillions - in around 3 years.
What does that tell us?
Advising a High School Student (Score:4, Interesting)
What path would a kid take to get into real datacenter hardware?
Re:Huh? Stuffing FUD in there or what? (Score:3, Interesting)
Obviously, you've never worked on a mainframe. It's not like Java or UNIX, where you can google the web and come up with useful documentation. You have to be trained to use a mainframe in a college environment; you can't learn it by picking up an O'Reilly book and cramming over the weekend. Don't get me wrong - I'm not saying you're stupid; it's just that IBM has gone to great lengths to ensure that the only documentation for mainframes is available through them, and their writers aren't exactly pulitzer winners, if you know what I mean. You simply can't pick up a book on the subject, or google the web, because no one is enthusiastic enough about mainframe programming to write the stuff down and publish it (either hardcopy or web.) It's kind of hard to learn something when there isn't any documentation.
And if you think otherwise, here's a challenge: Reply to this post with the JCL necessary to compile and run a COBOL program which will print out "HELLO WORLD". And then give the URL or a link to a book title where you found this information.
Actually... (Score:2, Interesting)
Two out of five mainframe people are female while two out of eight open systems people are female.
statistics pulled out of thin air with cloud graphs from personal observation
I suppose this is because in the bad old days computers were considered the domain of secretaries.
You just hit on the problem. (Score:3, Interesting)
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?
Re:So, the admins are old. (Score:4, Interesting)
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.
Okay (Score:3, Interesting)
WE wll know they are bigger, mroe robust, fault tolerant, etc, and run weird operating systems, and people only use weird languages on them like rexx and cobol and fortran.
What is the gain? Why are these languages used? What is the real deal with mainframes, and why would anyone other than a legacy operation want one nowadays?
Words from a COBOL coder (Score:4, Interesting)
I just finished taking a Java course so I could have a way out of my COBOL-dreary job.
The grass is always greener...
Re:You don't know better... (Score:2, Interesting)
I didn't (and don't) think they were going away any time soon, but the mainframe jobs that were available at the time were being moved out of the area.
It's good to know I have those skills to fall back on if I need to. And, FWIW, Xedit is a much nicer editor than vi
Re:Yeah right ... (Score:5, Interesting)
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?"
instead of denigrating mainframes and COBOL (Score:2, Interesting)
Re:You just hit on the problem. (Score:3, Interesting)
I'd be interested in knowing that myself. I'm an ex MVS sys prog that jumped to Unix administration about 10 years ago because it was a lot more lucrative.
Dependending on what the money is these days, it may be a good time to jump back.
In 1992, mainframers were a dime a dozen, Unix admins were as rare as hen's teeth. Looks like that situation is quickly being reversed.
But no one wants to learn mainframes... (Score:2, Interesting)
I don't see this trend changing, no matter how many people post on
People avoid it like the plague, and I honestly think some of them go out of their way to avoid learning *anything* about the VM and MVS side of things so that they're not dubbed "a 390 person".
390 has definitely grown on me and I'm looking forward to growing old and becoming a white haired "390 guru"
Re:Or... (Score:3, Interesting)
It may be cultural (coming from an IBM mainframe background) but I tend to think of mainframes as from IBM, Hitachi, Amdahl, Honeywell, ICL, Fujitsu etc - basically designed for reliability, ridiculous levels of connectivity and huge data throughput. I know a big Sun box is at least as powerful as a small (older?) mainframe but there you go. I suppose it's more a matter ot role than power?
Some of the brands I list may no longer exist (or been taken over) but I bet they're all still in use!
Both 390 and Linux skills are needed (Score:2, Interesting)