Ask someone outside the IBM i world to picture an RPG shop and you get a caricature almost immediately: a windowless server room, a black screen with green text, and one programmer who has been there since before the person asking was born. Ask someone who actually works inside an RPG shop and they will tell you the caricature is maybe a third true, and it is not the third an outsider would guess. This isn't another history of the language or a chart of installed-base numbers. It's a walk through five specific claims people make about what it's actually like to work in an RPG shop in 2026, checked one by one against what practitioners, IBM itself, and the industry's own survey data are saying right now.
Myth 1: It's all green screens, all the time
The green screen is real, and it isn't going anywhere overnight. Plenty of IBM i shops still run 5250 sessions for day-to-day order entry and warehouse work, and plenty of programmers genuinely prefer it once they know the function keys cold — it's fast, it doesn't wait on a browser to render, and it was designed for exactly the repetitive data-entry tasks it's still doing. But treating that as the whole picture misses where the industry's own attention is actually going. In Fortra's 2026 IBM i Marketplace Survey, application modernization climbed to 62% of respondents citing it as a top concern, up from 57% the year before.
What that concern is actually about matters more than the number itself. It's rarely "rewrite everything in a different language." It's closer to what IBM itself describes as RPG modernization: converting the interface, adding web and API access, and modularizing the code, while the RPG business logic underneath keeps running unchanged. Vendors like LANSA and Fresche Solutions sell products built specifically around that split, converting 5250 terminal screens into browser-based interfaces while preserving the underlying application logic and business rules rather than touching them. The stereotype assumes a green screen means an untouched, frozen application. In an increasing number of shops it actually means a front-end decision made independently of the backend, not a verdict on the code behind it.
There's also a market-facing angle to that 62% that shops don't always see from the inside. Green screens don't just shape how existing staff work, they're also a signal to everyone who isn't already inside the building: candidates deciding whether to take the job, customers judging whether the company they're dealing with looks current, and partners sizing up whether an integration is going to be painful. A shop can have flawless RPG underneath and still lose a hire or a deal because the screen a visitor sees first looks frozen in 1994. That's a separate reason modernization keeps climbing the concern list even in shops whose actual application logic isn't going anywhere.
See RPG modernization guides →Myth 2: There's a whole team behind it
“For many organizations, the most significant single point of failure is no longer the infrastructure. It is the people who support it.”
Ash Giddings, Product Manager at Maxava, IT Jungle
Picture "enterprise IT department" and you probably picture more than one person. A lot of IBM i shops don't have that. Industry reporting has long put the average IBM i shop somewhere around three programmer/analyst/administrator staff total — some shops run into the hundreds, and some genuinely run on one person. That one person is often responsible for the RPG applications, the database, the operating system, security patching, and whatever the label printer is doing that week, all at once. A trade-press piece published in late August 2026 put a specific name to what that risk actually is: not a headcount problem in the abstract, but a knowledge-concentration problem sitting in very few heads.
That framing changes what "RPG shop culture" actually means day to day. It's less about a specific coding style and more about how much institutional memory lives in how few people. When that person is out sick, on vacation, or retires, there frequently isn't a deep bench behind them the way there would be on a ten-person Java team down the road. That's also the real context behind the industry's repeated skills-shortage headlines: it isn't only "not enough RPG programmers exist," it's "not enough exist relative to how concentrated the knowledge already is inside the shops that have any at all."
Myth 3: The free-format fight is over; everyone moved on
IBM added free-form calculation syntax to RPG IV in 2001, and by 2013 a programmer could write an entire program with no fixed-column syntax left at all. On paper that settles the question. In practice, a Code400 forum thread specifically about free-format versus fixed-format RPG is still active with practitioners weighing in from both sides, and the reasons people give for staying with fixed format are rarely "I don't understand free format."
“Since I do 80% maintenance, and everything is already fixed, I won't change fixed to all-free very soon.”
Billw, on the FREE vs FIXED RPG thread, Code400 forum
“At first yes there is a time to acclimate yourself to the 'new' way of doing things...but it's well worth it.”
tomholden, same Code400 thread
Both of those are describing the same shop culture from different chairs, not disagreeing about the language. Billw's answer isn't resistance to change, it's a cost-benefit call: if 80% of a working week is maintaining code that already exists and already works, reformatting it for its own sake is time not spent on the actual backlog. tomholden's answer is the flip side of the same coin: once the adjustment period is past, the newer operations and the readability genuinely pay off, especially on anything new. RPG shops routinely end up running both styles side by side for exactly this reason — old programs stay fixed-format because rewriting working code for style is a hard sell, new programs get written free-format because there's no legacy pull holding them back. The one thing that same thread's participants actually agree on isn't which style wins, it's that mixing the two haphazardly inside a single program is the real mess to avoid.
Myth 4: Nobody wants an RPG job, so shops just can't hire
“It's relatively easy to take a computer professional and teach them how to do things on IBM i.”
Steve Will, IBM i Chief Architect, IT Jungle
That 69% sounds, on its face, like a story about nobody wanting to learn RPG. IBM's own chief architect for the platform argues the actual bottleneck sits upstream of that: it's less about whether the language itself can be taught, and more about whether a given shop is actually running a pipeline to teach it, versus sitting back and waiting for a fully-formed RPG hire to walk in the door. RPG's learning curve for someone who already has programming experience isn't especially steep once they get past the program cycle and the column-sensitive legacy syntax; the shortage looks a lot more like a training-investment gap at individual companies than a language people are actively refusing to touch.
Myth 5: If you're the RPG person, you're stuck babysitting old code forever
The daily reality for a lot of RPG developers in 2026 isn't purely maintenance. Embedded SQL inside RPG programs, calling and being called by web services, exposing RPG business logic through APIs, and working alongside a modernized front end built by a vendor tool while the RPG underneath stays exactly where it is — all of that is now a normal part of the job description at shops that are actively investing rather than just keeping the lights on. It's a genuinely different skill set from fixing a level-check error on a batch job, and it's a large part of why the free-format debate and the modernization numbers above matter in the first place: together they describe what the job increasingly looks like for someone who isn't only maintaining a twenty-year-old order-entry screen.
That doesn't erase the maintenance side of the job, and nobody in these shops is pretending otherwise. Old programs still break, batch jobs still fail at 2 a.m., and someone still has to know why a decades-old subroutine handles a particular customer's pricing rule the way it does. What's changed is that the maintenance work and the modernization work now sit on the same desk in a lot of shops, often the same day, rather than being two separate careers. The RPG person who only knows how to read a fixed-format program and the RPG person who only knows how to build a REST API on top of DB2 for i are both less useful, in practice, than the one who can move between the two as the ticket queue demands it.
See RPG modernization vendors →Where this leaves you
- Green screens still exist, but the industry's own concern is shifting toward modernizing the interface around RPG, not replacing RPG itself.
- Small teams, sometimes literally a team of one, are common enough that the real cultural risk in an RPG shop is concentrated knowledge, not raw headcount.
- Free-format versus fixed-format is a live, ongoing debate driven by real maintenance economics, not a settled question with one obviously correct answer.
- The skills-shortage headlines are less about RPG being hard to learn and more about whether individual shops actually invest in teaching it.
- The job itself increasingly includes SQL, APIs, and modern front ends layered on top of RPG logic, not just fixed-format maintenance work.
None of this is the dramatic public story COBOL gets when a state unemployment system melts down in the news. RPG's version of the same pressure plays out quietly, inside individual shops, one retirement or one hiring decision at a time. That's exactly why the myths above are worth checking against what practitioners are actually saying instead of the stereotype: the risk is real, but it looks like staffing and training decisions playing out inside small teams, not a language quietly on its way out.