If you have never written a line of RPG, IBM i is one of the more fascinating platforms for production at scale. If you have written a few million lines of it, you already know where the day-to-day pain lives. This post covers both: a technical sketch of what makes IBM i unique, where modernization friction actually shows up, how IBM Bob fits into an IBM i workflow today, the setup steps to get started, and what's next on the roadmap for the platform.

What IBM i actually is

IBM i is not a legacy operating system in the "we should rewrite this" sense. It is an integrated platform — the OS, the database, the security model, and the runtime are designed and shipped as one thing — that has been earning revenue for banks, insurers, hospitals, manufacturers, and logistics shops for decades. So, we should call it legendary.

A few details that tend to surprise developers seeing it for the first time:

Single-level storage. RAM and disk share one virtual address space. Object pointers persist across reboots. The OS treats memory and storage as a single tier and pages between them transparently. Most modern systems are still catching up to this.
TIMI, the Technology Independent Machine Interface. RPG binaries compiled on hardware from the 1990s run unmodified on current POWER chips. The OS retranslates against the new instruction set under the hood. The closest modern analogue is WebAssembly, decades earlier.
Object-based OS. Programs, files, queues, and authorities are typed objects with attributes — not files with metadata bolted on. Security is enforced at the object level.
Db2 for i is integrated, not bolted on. SQL and native record-level I/O hit the same data. A 40-year-old physical file can be queried through a modern SQL view without a migration project.
Source can live on the system or in Git — your choice. Historically, IBM i source was stored as members inside source physical files (QSYS), compiled directly on the system. The platform originally positioned the LPAR as the source of truth. But IBM i has evolved: the compilers and OS now fully support modern Git-centric workflows, IFS stream files, and local development if you choose. Many shops still use QSYS libraries, but the platform gives you options

The platform also supports modern delivery patterns out of the box: native REST API engines as part of the OS, hybrid cloud through Power Virtual Server, and AI inference running on the same hardware as transactional workloads. RPG, COBOL, CL, and SQL coexist with the development practices the rest of your engineering org already uses.

The platform is not the problem. The friction is around it.

Where the friction shows up

Four patterns come up in nearly every IBM i shop. None of them are about RPG itself — the language is fine — but about the context around the code that was never written down, and the way the platform stores and shares that context.

Implicit context, by design. A working RPG program can span four language generations in one source — RPG II, RPG IV, /COPY copybooks (shared declarations pulled in at compile time), and free-format procedures — with column-sensitive syntax and numbered indicators (*IN01–*IN99) doing the job that structured control flow and named booleans do in most other languages. The syntax is learnable in a week; the conventions and business rules around it live in senior engineers' heads.
Change is never local. A field's type isn't declared in the program that uses it — it's declared in the database table itself, in a separate source file (a DDS member). Every program that reads or writes that table inherits those definitions just by referencing the file at the top. So lengthening one column from 10 to 12 digits is never a one-program edit: it ripples through every program that touches the file, and the list of those programs is rarely written down anywhere. Each change to a critical workload therefore carries continuity risk, and modernization stalls.
Source rarely lives where modern tooling expects it. The canonical copy of a program is on the system, not in a Git repo on a laptop. Reading code someone else wrote fifteen years ago starts with finding it on the LPAR, exporting it, and then deciding whether the export is the canonical copy — a workflow that any tool assuming a local working tree has to be adapted around before it earns its keep.
Fixed-form RPG looks nothing like modern code. Most production RPG was written in fixed-form: column-sensitive syntax where operation codes live in columns 26–35, Factor 1 in 12–25, and comments only fit past column 80. It reads like assembly language to anyone trained on Python or JavaScript. IBM reinvented the language with fully free-format RPG (RPG IV, later just "RPG"), which looks and feels like a modern procedural language — structured blocks, named variables, standard expressions. The syntax gap is real, but the language itself evolved. The friction is that decades of working code is still in fixed-form, and rewriting it carries risk most shops can't justify.

What Bob does on an RPG application for IBM i

Point Bob at an RPG program and start in Ask mode:

"Walk me through what this program does and which files it touches."
"Where is CUSTNO set, and which programs read it after that?"
"What would break if I changed the length of this field?"

Switch to Plan mode when you have a change in mind: a free-format conversion, an SQL migration off record-level I/O, or breaking a monolith into modules. Bob produces a plan, the dependencies it touched, and the steps it intends to take, before any file is modified.

Switch to Code mode to apply the change. Bob:

Converts fixed-format RPG to free-format using repeatable patterns, file by file.
Migrates record-level I/O to embedded SQL where appropriate.
Generates RPGUnit test suites against existing procedures so the conversion is verifiable, not just compiled.
Produces plain-language documentation and Mermaid diagrams from the source — searchable, shareable artifacts that outlive any one engineer.

The same workflow handles RPG II/III/ILE, CL, DDS, SQL, and COBOL, so a new hire reading a program written before they were born is no longer blocked by the syntax.

Make your IBM i source Bob-ready

Bob today works against source on your local computer. The setup is short:

Pull your source down. Export your RPG, RPGLE, CL, DDS, and SQL members to a local folder. The Code for i project explorer documents the export from physical file members: migrate source
Open the folder in Bob. File → Open Folder on the source root. Bob indexes the codebase on first open.
Install the IBM i toolchain. From the Extensions panel, add the IBM i Development Pack (the Code for i bundle) and a Mermaid renderer for the diagrams Bob produces.
Start a session in Ask mode. Pick a single program — ideally one nobody on the team fully understands — and ask Bob to explain it. That is the fastest way to see whether Bob earns its place in your workflow.

If your team is coming from SEU or RDi, the migration is mostly the export step above plus the extension install. The editing surface is a modern VS Code-family environment with syntax highlighting, code completion, and the AI workflow described earlier; line numbers are still available for engineers who want them.

What's next for Bob on IBM i

Recently announced Premium Pacakge for i provides native & optimized experience for IBM i development team. Premium Package for i will become generally available on June 24th.

Premium Package for i. With the June 24th GA, Bob will connect directly to your IBM i. From a single session you read source members directly from QSYS, edit them with the same workflow above, and run compile and test cycles against the system directly. Alongside the connectivity, Bob picks up built-in skills and workflows tuned to IBM i development — fixed-to-free conversion, refactoring, document generation — so a starting prompt on an RPG codebase lands more directly on IBM i conventions out of the box. Concretely, that means:

One Bob session connected to a development LPAR; no separate export-edit-import loop.
Compile errors and test results from the IBM i surface back into the conversation Bob is already in.
Built-in skills & workflows for the refactoring, conversions, and test-generation patterns IBM i shops run repeatedly.

Further out — end-to-end SDLC. Three threads are in active design for future releases:

DevOps integration. Bob participating in build, deploy, monitor, and CI/CD for IBM i workloads — running a regression pass against a test LPAR, promoting a change through environments, and surfacing a runtime issue back into a session.
SQL performance. Data analysis and index optimization as a first-class capability, on top of the embedded-SQL migration patterns Bob already produces today.
IBM i knowledge assistant. Retrieval-grounded answers across the codebase, design documentation, and tickets — so context that lives outside the source is reachable from the same conversation.

For a team adopting Bob today, the local-file workflow above is the right starting point; the items in this section describe how that workflow shortens and extends as the IBM i offering matures.

Customer references

Teams in healthcare, agriculture, enterprise IT, and logistics are using Bob against production IBM i codebases today:

MEDHOST. Healthcare applications spanning multiple RPG generations across U.S. hospital deployments. The team uses Bob for impact analysis and fixed-to-free conversion, and for onboarding newer developers onto programs whose original authors are long gone.
NI+C. Japanese enterprise integrator with RPG programs that had been running unchanged for over a decade with no surviving design documentation. Bob produced design docs and Mermaid diagrams accurate enough that engineers who had previously bounced off AI assistants kept using it for real work.
Heartland Co-op. Iowa-based agricultural cooperative streaming real-time IoT sensor data into its IBM i environment for grain-quality and equipment monitoring. Bob helps developers reason across the interdependencies between the IoT pipeline, grain accounting, and core operational systems, and shortens ramp-up for new hires.
Carreras Grupo Logístico. One of the first enterprise Bob adopters in Spain, using it to explain legacy program logic, generate documentation, and refactor across modules of a logistics platform.

The common thread across all four is the same: the existing IBM i codebase stays in place, and the explanation, conversion, and documentation work runs alongside the production system rather than ahead of a replacement project.

Get started

Start a free trial
Pull one RPG program into a local folder and open it in Bob.
In Ask mode, request a walkthrough and a Mermaid diagram of its data flow.

That session — one program, one conversation — is the shortest path to a real answer about whether Bob fits the way your team works.