Mainframe staffing dilemma bedevils CIO dependents More than half a century after its birth, the mainframe poses conundrum for hundreds of CIOs. Mainframes are firmly ensconced as a critical piece of the IT infrastructure underpinning their business – just ask any of the traditional banks. The fear is that as those maintaining them retire or get outsourced, nobody will be left …
The anecdotes I've heard aren't encouraging. (Note that I'm not really in this particular field myself, though I occasionally write code that runs on zOS.) From what I've seen, some folks do find organizations that admit the problem and are willing to pay appropriately for the relevant skills, but other people only get offers with unreasonable terms, from organizations that think they can just outsource the work.
I suspect that attitude will gradually change, as the mainframe skilled-labor market continues to tighten and organizations want more new features for their mainframe applications. On the other hand, I'm also seeing - again, anecdotally - improvements in skill sets from the outsourcing firms working in this area. So competition won't disappear.
Compuware chief executive Chris O’Malley called the gap in skills and need for funding a problem on a par with the Millennium Bug around the turn of the century.
Quick - how can we make a bunch of bucks on this?
(Just for the record, I'm looking for work - have experience with GE/Honeywell/Bulle, CDC, 1401/7094/360 mainframes. I think $250/hour would work out nicely - lunch included.)
I work in an industry that is heavily dependent on mainframes. They're so embedded in the business processes that I doubt anything will ever replace at least the concepts involved. From friends I know who work at the big service providers, I've heard there's definitely a challenge getting new graduates interested in even learning about mainframes. It's seen as dead-end work by many, but I think people can definitely make some money off the skills shortage.
The problem is that companies are looking at this problem like they look at every IT problem -- "Oh, we don't have the skills and no one wants to learn. Let's send it all to India! They'll never complain!" I think that if companies invested in training for people, and found some way to ensure people don't get stuck in a career rut, they'd have the skills they need. It's just systems work after all -- but on systems that involve concepts that many younger people haven't even encountered. The problem is that whole "mainframe guy == untrainable curmudgeon" mindset that companies seem to have in regards to hiring. I don't know -- I'd rather have a greybeard who has had to keep systems going that you can't just reboot than a newbie with a Red Hat certification.
Whenever I hear employers wail, "There's a skills shortage" I mentally add the critical missing clause: "...at the rate we are willing to pay them".
Doesn't matter whether the industry is grape farmers in California, meat packing in Iowa or IT in Corporate America. If mainframe skills went from commanding, say, $200 an hour to $2000 an hour, you can be sure classes would be springing up and people would be off learning it. The market adjusts.
Mainframe systems are victims of their own success when it comes to long term skills planning. No-one could have forseen the longevity of core business applications, usually COBOL-based, when they were first devised decades ago. Now, that long-term success and value needs a longer-term resourcing model that - probably - outstrips any previous skills or people plans put in place.
We saw that concern with Y2K, but core IT skills supply and demand issues are no stranger to the public domain. Recent government initiatives to get kids coding and get more STEM graduates are all examples of a wider concern over future specialist technical skills in industry. Mainframe COBOL guys are just another incarnation of that. Compuware's O'Malley also knows that his organization, as well as IBM, Micro Focus and others are investing in both technology and academic partnerships to build a more robust longer-term supply of skilled coders who understand mainframes and COBOL systems alongside other technical abilities. Indeed, Micro Focus has recently launched a program all around the IT skills question but with a more upbeat perspective on how long term technical resource planning can be tackled. See www.microfocus.com for more information.
I agree with most that's been said. I would like to add though, where are the mainframe related job vacancies? I don't remember having ever really seen any. The mainframe field seems to be a rather closed one where it is quite hard to get into. I started in the mid 90s as an AS/400 developer, with the opportunity to branch into S/390, however I chose the linux way (at times I wish I hadn't). I sometimes entertain the idea to work with mainframes, but have no idea how or if it is even possible. So I be stuck with commodity hardware and linux distros...
DICE.com lists several Mainframe vacancies in my area.
I've been retired for a couple years now, so I haven't been paying a lot of attention, but almost ALL the Major Banks still own Multiple Mainframes.
And, if you are located near them, most Government agencies still own Theirs as well, in spite of all the ex-Used Car salesmen who keep trying to convince the Politicians that Windows can do anything a Mainframe can do.
(BTW, I understand Microsoft also still runs Their accounting on a Mainframe, too.)
For starters, look around, how many do you see?
Bugger all, compared to the numbers of "commodity" servers and desktop computers.
Why are there bugger all? Because they're hideously expensive and commodity hardware is "good enough" for most people, so big mainframes never get a look in. Therefore, what does your typical university graduate learn to program on these days? A mainframe? No, a personal computer.
Based on this, how is someone going to gain experience with a mainframe if they are unaffordable and generally unavailable?
The only way, is you have to take on untrained people and train them. You know, like the old days! You took on someone more or less as the apprentice, taught them the ways of the tools they were to use, and showed them how it was done. You don't achieve this by signing redundancy cheques!
Sorry managers, failing to plan is planning to fail. If you failed to plan for your future by failing to ensure you had people in place to replace those who are now retiring, then that is your problem, I don't see why the rest of us should come to your aid.
Because, for the Universities there are Two major obstacles:
1) Many professors don't Want to teach Mainframes in the "Publish or Perish" environment because there just really Isn't much to say about COBOL that wasn't said years ago.
It's a bit of a Career Killer.
2) The University's Bean Counters long ago embraced the idea that, if you require every student to purchase their Own Computers, the University doesn't need to purchase a dedicated computer for the Students to learn on.
Because only an Idiot would allow the Students to log on to the same computer used to perform the University's accounting or store student records.
But, at $1,000,000 each, teaching Mainframe programming courses is Huge expenditure.
Something IBM used to address by offering FREE Mainframe access to students and professors at universities which Did teach Mainframe courses.
Sadly, most of the Universities which Accepted IBMs offer were located in India.
US Universities were long ago taken over by people who went to the First Church of Microsoft or the Universal Church or Unix.
Religious Heretics are seldom welcome.
One place I worked at a few years ago actually went to the local University and offered a deal: We'll Hire several dozen of your graduates each year if you teach them COBOL.
The University accepted the offer on one condition: The company had to pay the University an extra $2000 per student, above the normal costs of Tuition and books.
Some days, you just can't win.
This is how I started in IT. Left school in 1969 with one O level (Eng Lit), tried civil engineering for a year then joined good old Marconi Co in their Data Processing dept, processing paper tape for accounts as input to the old KDF9. Soon got a job as a trainee op on their IBM 360/20 and that's where I started. I ran with mainframes as an operator, senior operator, shift leader, JCL guy, scheduler, ops support up until the mid 80's when I moved to data comms. During my time with mainframes training was mainly "on the job" but we did receive external training for writing COBOL and Assembler, which was very useful when batch runs crashed at 3 in the morning.
I don't know what it's like now but I suspect that degrees are now required and it's no longer the get down and dirty job it was in the seventies - I remember isolating duff I/O kit by removing the Bus/tag cables and butting them up, splicing tape, rekeying punch cards; fixing, recompliling and linking duff programs, using the printers for tables for a 2am chinese. It was had, it was fun and we all felt like we were achieving something, doing a useful job which very few people understood, least of all the management.
I doubt it's much fun now.
how is someone going to gain experience with a mainframe if they are unaffordable and generally unavailable?
Get a copy of Bob DuCharme's Fake Your Way Through MVS. Free as a PDF, or you can get a bound copy from Lulu (I think it's still available there).
Download and set up Hercules. Free.
Read the relevant IBM manuals. Free.
Want to learn COBOL too? There are free compilers, including the MF personal edition and OpenCOBOL. Used and remaindered copies of various textbooks can be had cheaply.
As Derek noted, there are also a number of colleges and universities offering relevant courses.
The only thing worse then special mailframe software to keep the big iron in place is special hardware. I used an IBM 3081 with custom hardware add ons. At the weekly status report meetings, the head sysadm used to report the uptime ($today - $install date) in some random time unit (like miliseconds, deca centuries, centi synodic months) which would be recorded and plotted by the manager who never questiioned or recored the units. The sysadm calimed it made the uptime graphs more interesting. Somehow I expect the old array of boxes are still converting power to heat and producing no useful results just like it was doing in the early 80s.
Apparently just training someone for the position is total rocket science for these companies.
It is a consistent thing with IT hiring. They think they can just hire someone out of a newspaper with a very specific skill set that is often unique to their company. I had one company baffled that they couldn't find anyone that didn't have 5 years experience with a proprietary bit of software the company uses. Finding someone outside of the company with that experience off the shelf is literally impossible.
I don't know what is going on here. I think the CIOs need to work with HR or something work out the depreciation of employees so that they can be replaced at a reasonable rate. Train up your low level techs to be mid level techs. Train your mid levels to be high levels. Train your high levels to be critical specialists. And offer a management track for your techs as well. You trap them in some little room with no way out and they're going to look for other jobs.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
