For a long time now, the still young at heart mainframers have been making plans. Unfortunately, it’s not plans for how to improve mainframe performance or reduce costs, it’s what to do once they retire. And the bad news is that more and more mainframers are retiring. What can those organizations that are still running their main business applications on mainframes do?
The first solution that some companies are looking at is to do nothing. Of course, doing nothing is a choice. In this case, it means they hope that nothing much changes and everything will continue to work as it always has. After all, mainframes were claiming five nines reliability years ago. That means 99.999% uptime for any non-mainframers reading this.
The second solution is to try to coax your trusted systems programmer out of retirement with a few days of consultancy every now and again, just to keep things ticking over.
Or there’s the option to buy in external consultants to keep things going. This will be a more expensive option and will also be risker. They don’t know your applications. They don’t have 40 years of experience at your site. They don’t understand the symbiotic relationship between the applications, and an inappropriate change to one thing can have a devastating effect on another. And then you’ll be paying more consultancy fees while they fix their own mistake (not that they’d ever refer to it that way!).
If this were an old cowboy film, the wagons are circled and waiting for another attack. And people in the wagon train are hoping to catch site of the cavalry coming over the hill. In mainframe terms, is there a cavalry?
The most positive answer is that there very well could be! The solution to the problem can be found in those youngsters who are coming out of University with seemingly non-mainframe skills like Java. All that’s needed is to find some way to sell mainframes to youngsters whose only interaction with a mainframe so far in their life has been when they take money from an ATM.
So, if I were standing in front of a group of 20 year olds, how could I sell them highly complicated and arcanely connected systems that are managed on green screens using technology that (in Internet years) is positively ancient?
Firstly, I could promise them paid employment. Once they’re inducted into the mainframe world, they pretty much have a choice of jobs. If they want to travel, they can work abroad. If they want to stay at home, the organization that has employed them won’t want to let them go. They have job security for the foreseeable future. How many other 20 year olds can say that?
The second big selling point is that they won’t have to retrain, they can use their existing skills on the mainframe. Sites running Linux partitions on the mainframe (or even a LinuxONE mainframe) will be glad to have their Linux skills. If they can program in Java, then there are definitely opportunities for them in the mainframe world. If they’re a bit of a whiz in Python or C, it’s OK, they can work on a mainframe.
With all the talk about DevOps and mobile apps plugging into a mainframe backend, it makes sense for organizations to employ mainframers that have grown up with apps that update regularly and frequently. They ‘get it’. They understand the future of computing (well, certainly for the next five years or so).
What about COBOL, PL/I, and Assembler? That is an issue, but it’s not as big an issue as you might think. The answer to the problem comes in software – software that can investigate the relationships between old COBOL programs and display what’s going on in ways that are understandable by these youngsters. I’m talking about interfaces that use colour and graphics. Interfaces that allow new code to be written in modern coding languages and then have that code added to what’s already in existence.
If I were a 20-something year old programmer, I wouldn’t be getting a job with a Web design company or some bright hopeful start-up hoping to be the next Google or Facebook. I would be writing to mainframe-using organizations and offering my services to them. And I’d be looking forward to the interesting future that lies ahead of me.
- Moving mission-critical mainframe workloads to the cloud - Sep 30, 2020
- Tell me about COBOL - Jul 22, 2020
- Fear the Mainframe - Dec 11, 2019