The IBM i And Its RPG Decade Of Crisis
September 29, 2021 Roger Pence
Your business desperately needs your IBM i RPG applications to deliver your unique business value to your customers and business partners. RPG programming is a disappearing skill; by 2030 the typical RPG programmer will be 80 years old. Your RPG-dependent business is at risk with the disappearance of RPG programming talent.
The IBM i runs many businesses today and its RPG applications perform unique and mission-critical processes. These businesses can’t get along without them. Alas, the teams that built these applications are rapidly nearing retirement. There aren’t younger RPG programmers in the pipeline. RPG programming is a disappearing skill. Despite IBM’s best efforts to extend the life and capabilities of the IBM i platform, the fact remains that RPG applications need RPG programmers to persist. The decade between 2020 and 2030 is the decade of crisis for many IBM i shops. Can your business survive without its RPG programmers?
RPG programming talent and the skills it takes to maintain and enhance RPG applications will be nearly obsolete in 2030. Don’t be mistaken: We are not saying the IBM i will be obsolete in 2030. We are saying that by 2030 programmers with RPG programming skills will be very hard to find. And without RPG programmers, businesses that depend on RPG applications will be in jeopardy. IBM i-based businesses that ignore or fail to understand the impact of losing their RPG programming teams put the business persistence in direct risk.
The Risk Is Real
Consider the plight of New Jersey and its recent search for COBOL programmers. A 1,600 percent increase in unemployment claims during the 2020 COVID-19 crisis overwhelmed New Jersey’s 40-year-old COBOL system. This caused New Jersey governor Phil Murphy to put out an urgent plea for COBOL programmers. Oklahoma also had a similar issue.
During a press conference (saying “COBALT” but meaning “COBOL”) Murphy said, “but given the legacy systems we should add a page [to the team’s planning] for COBALT (sic) computer skills, because that’s what we’re dealing with in these legacy [systems]. . . . But literally, we have systems that are 40-plus years old. There’ll be lots of post mortems and one of them on our list will be how the heck did we get here when we literally needed COBALT programmers.” (See him say this in the last minute of this video.)
It’s Not Just New Jersey
New Jersey’s COBOL shortage is solid evidence that dependence on legacy languages is a critical issue. It’s not just New Jersey, either. This June 2019 report from the United States Government Accountability Office shows that of the federal government’s $90 billion budget, about 80 percent of it is aimed at keeping its legacy systems running. The report concludes that the government’s legacy systems need substantial upgrades and replacements and until they do that they risk higher costs, delays, and project failure. The report cited five examples of successful federal modernization initiatives that included transforming legacy code into a modern programming language and moving that transformed code to the cloud.
This business challenge is not COBOL-specific. COBOL and RPG both appeared in their first rudimentary forms in 1959. In the coming years, many IBM i shops will be without RPG programmers. Don’t be in the same boat as New Jersey and the US federal government. The IBM i/RPG reckoning isn’t here yet, but it’s coming.
Several years ago, a forward-thinking customer of ours said it better than we can: “While our RPG application had served us well for more than 20 years, we realized that it represented a deep investment and dependency in an application that would be unmaintainable by next-generation programmers. We needed to take steps to ensure unimpeded business continuity.”
Delivering Core Business Value
Like the System/38, the AS/400 offered an operating system tightly integrated with its database and its computer languages. This made the AS/400 a good platform for creating business applications in the 1990s. Back then, business applications were relatively simple (especially when compared to today’s networked applications that need to offer deep integration with customers and business partners). Without much formal training, budding RPG programmers created very effective RPG applications. In those days, security, cross-platform integration, a sophisticated user interface, and many features so common and necessary today simply weren’t even on the nice-to-have list, let alone the need-to-have list.
Those were simple days. The core demand back then was to automate decades-old paper-driven systems. The imagination, the computer power, and the tools didn’t exist to design and develop the kinds of applications we needed today. The $230,000 top-end AS/400 in 1988 had 96 MB of memory (that’s not a typo – 96 megabytes of memory). An iPhone today has at least 1 GB of memory. Your phone has enough memory to power ten AS/400s from 1988! Who would have thought then that in 40 years we would all have more powerful computers in our pockets and purses than we had in our AS/400s?
In many cases, the applications RPG programmers built back then predated the AS/400 and started on IBM’s System/38. Upon its introduction, the AS/400 was just more scalable and slightly tweaked System/38. For most System/38 shops the upgrade path to the AS/400 was smooth and obvious. The old RPG needed only minor change to run just fine on the AS/400.
In many shops, these young, and mostly self-taught, RPG programming teams built what would ultimately become the core IT backbone of the business, and now 30 or 40 years later, these applications are still ensuring that your business is able to deliver its unique business value to its customers. These applications are critical and the business simply can’t get along without them. They are managing unique and business-specific complex processes and workflows.
There may indeed be some generic aspects of this RPG software that could be factored out. For example, some might include a general-purpose general ledger or accounts payable. However, even after factoring these more generic applications out, the remaining application is still huge by any measure and critical to business persistence.
Consider that 76 percent of the respondents to the 2021 IBM i Marketplace Survey said that their IBM i business applications are “homegrown applications.” In nearly every case, these are the bedrock applications created by RPG teams all those years ago. Most probably had their genesis in solving a couple of very simple business challenges and over the years the application grew into this pervasive monolith that governs most, if not all, aspects of the business. These RPG applications are critical and your business simply can’t get along without them managing your unique and business-specific complex processes and workflows.
Baby Boomer years are generally considered to have been from 1946 to 1964. Many, if not most, RPG programmers are baby boomers. At the end of the new decade, 2030, baby boomers will be from 66 to 84 years old! By the end of decade, even the youngest boomer will be 66 years old.
By 2030 nearly all available RPG talent will have retired. The RPG talent still available in 2030 will be very hard to find and expensive when you do find it.
The IBM i was introduced in 1988. There were probably some 20 year-olds (or so) new to RPG programming at that time, so not all RPG programmers are boomers. However, even an 18-year-old who came on board in 1988 will be 60 in 2030.
Let’s generalize a little and assume that today’s typical IBM i RPG programmer was born in 1950. That makes that typical RPG programmer 80 years old in 2030. Many boomers today are working beyond the traditional US retirement age of 65, but very few are working past 80. By 2030, nearly all available RPG talent will have retired. And for any IBM i-centric business deeply dependent on its RPG applications that is a huge problem.
That’s bad news but it gets worse. Not only is this generation of RPG programmers on the cusp of retirement, young programmers haven’t, and won’t, enter the RPG pipeline. Programming/IT college graduates today are highly unlikely to have encountered either the IBM i or RPG in any of their academic studies. The IBM i and its RPG programming language simply aren’t on young programmers’ radar today. Most IBM i shops with an RPG dependence have a crisis coming very soon.
Offshore outsourcing may offer some respite to the RPG programmer shortage. However, not only does using offshore outsourcing dramatically change your RPG maintenance/enhancement workflow, it imposes substantially communication challenges, cultural considerations, and a general imposition on your RPG programming comfort zone.
What’s A Business To Do?
Your RPG source is your business’s most important asset. Without that RPG source and the applications it creates, your business cannot deliver its unique value to your customers. At ASNA, we can show you how you can use that RPG source to transform your legacy RPG application into a modern, responsive alternative that a generation of younger programmers can maintain and enhance. Learn more about ASNA’s approach to avoiding your own crisis decade here.
Roger Pence has been a product specialist with ASNA for 20 years. He has been involved with the IBM i midrange community for many years. He has written many articles about the IBM i and RPG.
This content is sponsored by ASNA.