It’s no secret that the dreaded “skills gap” is affecting the mainframe market. It’s getting harder and harder to find people who know COBOL or Assembler, and organizations that rely on these systems often have open job postings because there’s no perfect match for the positions they’re trying to fill. So what can companies and government agencies that rely on Big Iron do to foster the next generation of mainframers?

They should do absolutely nothing.

I’m not saying that younger people shouldn’t be able to harness the power of mainframes, but turning millennials into mainframers is the equivalent of lowering the ceiling to change a light bulb rather than just getting a ladder. It’s impractical, difficult, and expensive. More to the point, my experience has shown that there aren’t a lot of 24-year-olds out there who are excited to learn COBOL. There are a lot of things from the late 1950s that are still cool, or at least back in style, but COBOL isn’t one of them.

But with all these discussions I’ve been having with the current crop of computer science graduates regarding the mainframe skills gap, an idea has slowly taken hold in me: Why not just get rid of the concept of a “mainframer” altogether?

After all, people who own Fords aren’t called “Ford drivers” – they’re called “drivers” because they can operate just about any car on the road. Today’s computer science majors and recent graduates are entering the workforce in an era of platform agnosticism, and forcing them to learn outdated languages is a losing proposition for mainframe admins and job candidates. That’s where apps that let anyone program in any language on any platform come into play.

It’s somewhat of a truism, no doubt, that each programmer possesses a unique set of skills, strengths, language/IDE preferences, experience, etc. But it’s a truism worth reminding ourselves of, because many companies have historically hired coders according to a system that essentially amounts to a checklist. If a programmer’s resume doesn’t check the proper programming language boxes, the assumption is that he/she doesn’t have the relevant skills to perform the job.

That approach, I argue, is misguided. For one, it ignores the fact that a coder with excellent general programming skills would more than likely outperform the mediocre coder who happens to have experience with the right language.

But the real problem with the checklist approach to hiring programming talent is that it doesn’t really reflect the software development ecosystem of today. As more and more people in the programming world have realized the benefits of letting coders work in whichever language they’re most comfortable, regardless of the platform, a kind of open source renaissance has blossomed. Individuals, foundations, and private companies have developed and released tools that are bringing the programming world ever-closer to that platform-neutral ideal. The consequence of this development has been that for many projects, anyone with strong coding chops can put their skills to work, while using whichever language they like or know best.

Given the increasingly dire situation of the mainframe skills gap, mainframe companies more than anyone should be investing in this platform-neutral movement. Thankfully, there’s signs that the industry is already moving in this direction. Despite some initial hesitance to embrace new programming languages and paradigms, today’s mainframe ecosystem is awash with applications, APIs, data virtualization solutions, and ported versions of popular programming languages that allow computer scientists to program the mainframe is if it were any other computer.

Because, when it comes down to it, programming the mainframe is just like programming any other computer. A really big, super reliable, extremely powerful computer. It’s the realization of this principle that will really help us bridge the mainframe skills gap. But more than that, it will help companies leverage their mainframe investment as we continue to push the limits of the mainframe’s potential. Already, solutions for using popular data science, machine learning, and cryptography tools on the mainframe are exciting the next generation of mainframe programmers with their speed and their power.

So, as we continue to push for the elimination of the idea of the “mainframer”, and as we continue to democratize mainframe development, stop thinking about how we’re going to make millennials become mainframers. Instead, start thinking about what kinds of advancements we might make, what problems we might solve, and what innovations we might accomplish, with the power of big iron on our side.

With over 25 years of software development experience, Bryan Smith manages all aspects of R&D organization and operations for Rocket Software. Prior to joining Rocket, Bryan was an IBM Distinguished Engineer in the Information Management division of the IBM Software Group, where he held various engineering, management, and customer-facing roles. Bryan has thirteen granted patents on software and holds B.S. and M.S. degrees in Computer Science with a minor in Mathematics from the California State University, at Pomona and Chico.

2 thoughts on “Making a Modern Mainframer”
  1. Bryan, the so-called ‘skills gap’ is becoming less of an issue for forward-looking organizations that embrace Linux on Z and Java. FYI, IDC recently conducted a study of what they refer to as the ‘connected mainframe’ phenomenon, where these developers are utilizing current DevOps practices with mainframe server platforms to create new applications. That talent pool is vast. Granted, there’s still a need for those familiar and skilled with zOS and COBOL, but access to that limited talent pool is no longer the primary gating factor to ongoing progress.

  2. The skills gap can be bridged with software. MANASYS Jazz ( will write COBOL for you with 1/20th (or fewer) of the lines of code, providing huge productivity leaps as you develop batch functions, web services, even classical CICS transactions. With a simple language and IDE that will attract modern programmers, COBOL becomes like Assembler, something that is there and occasionally useful but is largely ignored.

Leave a Reply

Your email address will not be published. Required fields are marked *