Retiring greybeards force firms to retrain Java, .NET bods as mainframe sysadmins New IT grads and Java and .NET jockies are being re-trained to run mainframes by big companies desperate to replace a generation of IT staff giving up work. That’s according to Compuware, who has released a study that says CIOs are growing concerned about the looming skills shortage in their mainframe rooms. They are …
Of course the banks will be happy to pay £millions because 'you have to pay market price for talented people'.
In any event it doesn't matter. Crypto currencies are delivering distributed, decentralised and fair investment banking to the masses that will enable Joe Bloggs to compete with the likes of these City Spivs.
"Sixty six per cent fear that the impending retirement of the mainframe workforce after 30 years in the job will hurt their business."
Once, training one's employees was the norm. Then they decided it was better to replace the employees with someone already trained. Now the dance shifts back to the other foot.
How can I not smile?
Strange as it may seem, there is already at several dialects of COBOL that do handle GUI type code. they are mostly marketed by small firms trying to pick off some of the low hanging fruit on Windows & Linux systems.
They recognize that COBOL succeeded remarkably well in one of Grace Hopper's most important design criteria: COBOL code is Very Easy to read and understand and has one of the shortest learning periods of any computer language for native English speakers.
That's a large part of WHY most Univeersities don't want to teach it any more. Publish or Perish is the biggest culprit in the exile of COBOL from most college curriculum.
A) It's really tough to find anything "New & startling" to say about something that has been around ro 40 years.
B) If you DO manage to come up with something to say, it's really easy for people to spot any inadvertant errors in your source code examples. If your paper is composed around the C family of languages, OTOH, you can Bluff and insist that "it Works Fine on MY Compiler & My Computer so the problem is all in Your OS."
This becomes a serious problem for those corporations who DO attempt to get people trained in COBOL. The company I was at a few years back wanted several of their new hires (Recent Graduates) trained in COBOL. They approached the local University to set up a couple courses. The University demanded a Fee from the company equal to twice the normal tuition for a course at that University before they would offer the course and refused to Add the course as an option for their current IT Undergraduates even though the company projected that they would be in need of at least a Dozen new graduates with COBOL skills every semester for the forseeable future.
This was one of the Megabanks that has critical systems running a COBOL system that would cost $100s or Millions of dollars to replace.
The Bank Knows the problem.
They've already been severly burned by consulting firms that promised to "Rebuild" their systems in a "Modern" language and failed in spectacular fashion after spending enough Millions to make those failures "Career Ending" for the executives and managers who "Sold" the projects to upper management.
The problem with risk managers is that they only quantify one risk: The risk of doing something (in this case rewriting old programs). They never seem to want to quantify the less obvious thing, the risk of NOT doing something (in this case letting the older programs survive on tribal knowledge).
Some one needs a clue-by-four.
The root of the problem is the fact that too many of the Managers in these megacorporations came out of the MBA Programs at place like Harvard & Yale where they got taught that the only thing that mattered is Next Quarter and that Long Term (Ie, 10 Years) planning was unnecessary because lots of great "Quarterly Success" would somehow Magically guarantee Long Term success.
Oh, and besides, if you Job Hop every year, you can get Bigger Raises and Faster Promotions so it doesn't matter what sort of financial or technical damage you leave in your wake because you won't be there when the waste matter hits the rotary impeller anyway.
"where they got taught that the only thing that mattered is Next Quarter and that Long Term (Ie, 10 Years) planning was unnecessary because lots of great "Quarterly Success" would somehow Magically guarantee Long Term success."
One of the base rules of "Operations Research" was that optimized sub systems do not naturally lead to a system that is optimized overall.
I guess they don't teach much OR on MBA's.
Rings a bell. Making anything clunky, slow, and resource hungry with objects was a fad not long ago. Fujitsu put out Visual COBOL. Believe it is abandonware now. Pity, it looked like mainframe code so much, otherwise not bad. Might have had a use for retraining Delphi/Visual anything programmers to keep bank systems going. For those of a FOSS bent, OpenCobol is still going. Could the bankers in search of cheaper hardware wind up porting to OpenCobol on linux clusters in a decade or so? The irony
Document and hand over your job so some snot-nose .net dev or code-wallah from India can do it for less?? And, most likely, badly??
Stuff em. I hope the mainframe admins have the sense to make the banks squirm on the hook. You want advanced systems cared for and fed, you pay for it.
IMO, the CIO in the article is off by about two decades, maybe close to four ... Gut feeling is the numpty thinks corporate databases will somehow manage to move to iFads, despite the lack of I/O.
As a side-note: Is my Brother's Wife the only one who has noticed that Google Maps is dreadfully slow to render on any given query? Desktop PC architecture simply doesn't scale when it comes to massive I/O.
Want a job until you decide to retire? Learn COBOL and Fortran (and K&R C, if you're young enough to have more than a couple decades before retirement).
"Desktop PC architecture simply doesn't scale "
That is part of why IBM, a few years ago, was having a nice financial boom when they discovered that they could migrate Linux systems to Mainframe Iron running Linux images under VM. All those dedicated boxes (As many as 500 Very Expensive servers) could be imaged on the Mainframe and not only run Faster, but the AC Bill alone was $100,000 / Year cheaper.
Part of it was that, with Dedicated servers, any "Extra " cycles on an individual box were difficult, if not Impossible, to use. So, if you had a box that was only 65% busy, the other 35% was Idle and wasted.
On the Mainframe, the OS just handed those cycles to another job and kept on chugging because the Mainframe OS has 40 Years of MultiTaking, Multi Processor experience and has been Optimized up the wazoo to handle Massive processing loads.
I worked on DOS, then VS1, then MFT, then MVS, and lateley z/OS platforms. Totally scalable, very fast and very secure. Never hacked and never went down. Only down time was when we upgraded to a new model CPU. Even moving all data on dasd was done while system(s) kept running at full speed using TDMF or PPRC...etc. I had over 40 years in a single company thru buyouts and name iterations, going public, then back private and then some new tech managers got hired and 'my position was being eliminated', whatever that means. A measly 6 weeks severance and out the door. Amazing that I can not find another position in the Tampa, FL area that pays decently. I keep reading these news flashes that CIO's are worried about the retiring boomers that grew up supporting the IBM mainframes, are now retiring in droves and there might be a system support shortage. I think the issue is no company seems to want to pay what the position is worth, with 20, 30 or 40 years experience. I continue looking but I find it unreal that the technology sites show a job offer looking for many years experience with almost every mainframe acronym there is, for 40k or 50k per year.
Still looking !!!
"I find it unreal that the technology sites show a job offer looking for many years experience with almost every mainframe acronym there is, for 40k or 50k per year."
Hey, that's a great rate if you happened to live in Mumbai.
Thank Congress for the H1-B Visa.
Many banks’ mainframe systems run on applications that hold business logic captured in millions of lines of COBOL code. Irrespective of IT strategy, what most of those systems have in common is a heritage of providing immeasurable business value. Those systems and applications, in one sense, are the business.
While those who know how to code in COBOL are becoming far fewer and, as the article mentions, are already reaching retirement age, this doesn't equate to a skills gap. Recent incarnations of tooling for mainframe COBOL systems provide a much richer and more unified environment enabling a far broader pool of developers to tackle core system tasks. Using Eclipse or Visual Studio IDEs, COBOL application development, even for mainframe systems, can be streamlined to be as rapid and responsive as today’s organizations need.
It’s also great news that big companies are training Java and .NET graduates to build the next generation of developers, yet this education should start earlier. A recent Micro Focus survey found that a huge 73% of academics running IT courses at universities around the globe do not include COBOL programming as part of their curriculum. The industry as a whole needs to consider the continued demand for skills for the systems that continue to run organizations. A growing number in academia are recognizing this and putting COBOL back on the syllabus, but others need to follow suit.
Tackling broader concerns around IT complexity, slow delivery cycles and new architectural strategies need also to be addressed simultaneously, as issues surrounding perceived inflexibility, constraints on delivery speed and return all conspire to negatively impact the reputation of mainframe systems. Technology that de-mystifies complexity and accelerates the delivery cycle alleviates a number of concerns and will help salvage the reputation of those systems within the business.
Derek Britton (Micro Focus)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
