Source control for IBM i: managing your RPG and CL source with Git and RDi

By /

Most IBM i shops still manage source the same way they did in the 1990s. Source members live in source physical files in a library. Changes are made directly in the member. There is no history of what changed, when it changed, or why. Recovering a previous version means hoping someone made a backup. Comparing two versions of a program means printing both and reading them side by side.

This works until it does not — until a bad change goes to production and nobody can remember what was there before, until two developers edit the same member and one overwrites the other, until a compliance audit asks you to prove who changed what and when.

Version control solves all of this. Git is the industry standard, and IBM i tooling has matured to the point where using Git for your RPG and CL source is practical and well-supported. This post covers the options, the setup, and the workflow that actually works.

The core problem: source in a database

On IBM i, source code lives in source physical files — database objects, not stream files. A source physical file like QRPGLESRC contains members, each member being one source object. Git expects files in a directory structure on a standard filesystem.

The bridge is the IFS. You move your source members out of the source physical files and into the IFS as proper text files. Git then manages those text files exactly as it manages any other project. The two main approaches to this are RDi (Rational Developer for i) and the open-source toolchain built around VS Code.

Option 1: RDi — IBM’s Eclipse-based IDE

RDi (Rational Developer for i) is IBM’s official IDE for IBM i development. It runs on your PC, connects to the IBM i system, and provides source editing, compilation, debugging, and Git integration in one package.

RDi handles the source-in-database problem by working with source members directly over the connection — you edit in RDi, it saves to the source physical file, and the Git integration works on a local copy of the source that RDi manages.

Strengths of RDi:

  • Deep IBM i integration — compile, debug, and check object attributes without leaving the IDE
  • Understands RPG and CL syntax — syntax highlighting, content assist, error markers
  • EGL and COBOL support alongside RPG
  • Git integration via EGit (Eclipse’s Git plugin)

Weaknesses:

  • Expensive — requires a licence per developer
  • Heavy Eclipse-based application — slower than modern editors
  • Setup and configuration can be complex

RDi is the right choice for shops with budget and developers who want everything in one IBM-supported product.

Option 2: VS Code + IBM i open-source toolchain

The IBM i open-source community has built a first-class VS Code extension called Code for IBM i (formerly known as IBMioss). This is now the most popular development setup for modern IBM i shops.

The stack:

  • VS Code — the editor (free, fast, cross-platform)
  • Code for IBM i extension — connects VS Code to your IBM i system over SSH, lets you browse objects, edit source members and IFS files, compile, and run commands directly
  • Git — standard Git on your PC (or on the IBM i via PASE)

Install the extension from the VS Code marketplace: search for “IBM i” and install the one published by Halcyon Tech. Connect it to your system with your hostname, username, and password. From that point, you can browse your libraries and source files in a side panel, open source members directly for editing, and compile with a right-click.

Setting up Git on IBM i (PASE)

For server-side Git operations — automated builds, CI/CD pipelines, or keeping a Git repository directly on the IBM i — you can install Git in PASE (the UNIX-compatible environment on IBM i).

IBM i ships with a package manager called yum (via the 5733-OPS open-source package). Install Git:

/* From an SSH session or PASE shell */
yum install git

Once installed, Git commands work exactly as they do on Linux:

cd /home/myuser/projects
git init
git add .
git commit -m "Initial commit of ORDERPGM source"
git remote add origin https://github.com/myorg/myrepo.git
git push -u origin main

The source migration: from source members to IFS files

Before you can use Git properly, you need to get your source out of source physical files and into IFS directories. The standard tool for this is CPYTOSTMF:

/* Copy one source member to the IFS */
CPYTOSTMF FROMMBR('/QSYS.LIB/MYLIB.LIB/QRPGLESRC.FILE/ORDERPGM.MBR') +
           TOSTMF('/home/myuser/projects/src/ORDERPGM.rpgle') +
           STMFOPT(*REPLACE) +
           STMFCCSID(1208) +
           CVTDTA(*AUTO)

STMFCCSID(1208) writes the file as UTF-8 — essential for Git to handle it correctly. CVTDTA(*AUTO) handles the EBCDIC-to-ASCII conversion.

For migrating an entire source file, write a CL loop or use a SQL-driven approach:

/* SQL to generate CPYTOSTMF commands for every member in a source file */
SELECT 'CPYTOSTMF FROMMBR(''/QSYS.LIB/MYLIB.LIB/QRPGLESRC.FILE/' +
       TRIM(SYSTEM_TABLE_MEMBER) + '.MBR'') ' +
       'TOSTMF(''/home/myuser/projects/src/' +
       LOWER(TRIM(SYSTEM_TABLE_MEMBER)) + '.rpgle'') ' +
       'STMFOPT(*REPLACE) STMFCCSID(1208) CVTDTA(*AUTO)'
  FROM QSYS2.SYSPARTITIONSTAT
  WHERE SYSTEM_TABLE_SCHEMA = 'MYLIB'
    AND SYSTEM_TABLE_NAME   = 'QRPGLESRC'

Run the generated commands to export all members. After migration, the IFS directory is your source of truth — the source physical file becomes a compilation target, not a storage location.

A practical Git workflow for IBM i

Once your source is in the IFS and under Git, the workflow mirrors what developers use everywhere:

Starting a new piece of work:

git checkout -b feature/order-validation-fix

Make changes, compile, test:

Edit the source file in VS Code. Compile from VS Code using the Code for IBM i extension (right-click the file, select compile action). Test in your development library.

Commit when the change works:

git add src/ORDERPGM.rpgle
git commit -m "Fix: order validation now rejects zero-quantity lines

Previously the validation loop skipped lines where qty was not
populated, allowing zero-quantity orders to proceed to fulfilment.
Now explicitly checks qty > 0 on each line."

Commit messages matter. A one-line message is fine for trivial changes. For anything substantive, the second paragraph explains why — this is what you will thank yourself for when reading history six months later.

Push and raise a pull request:

git push origin feature/order-validation-fix

On GitHub, GitLab, or Bitbucket, open a pull request from your branch to main. A second developer reviews the change. When approved, merge.

Deploy to production:

After merging to main, compile the updated source against the production library. Some shops automate this — a CI/CD pipeline watches the main branch and triggers a compilation job on IBM i when changes are merged.

Handling compiled objects vs source

One important rule: Git tracks source, not compiled objects. Do not commit .pgm, .srvpgm, or other compiled IBM i objects to Git — they are binary, platform-specific, and large. Add a .gitignore file to your repository:

# .gitignore for IBM i projects
*.pgm
*.srvpgm
*.module
*.bnddir
*.sqlpkg
*.savf
obj/
output/

The compiled objects are always reproducible from source. What Git tracks is the source that produces them.

Naming conventions for IFS source files

Standard file extensions used in the IBM i community:

  • .rpgle — free-format RPGLE source
  • .sqlrpgle — RPGLE with embedded SQL
  • .clle — CL source
  • .dspf — display file (DDS)
  • .pf — physical file (DDS)
  • .lf — logical file (DDS)
  • .bnd — binding source
  • .cmd — command source

Using these extensions allows VS Code’s Code for IBM i extension to apply the correct syntax highlighting and compile actions automatically.

Compiling from IFS source

Once source lives in the IFS, you compile directly from the IFS path rather than from a source physical file:

CRTBNDRPG PGM(MYLIB/ORDERPGM) +
           SRCSTMF('/home/myuser/projects/src/ORDERPGM.rpgle') +
           DBGVIEW(*SOURCE) OPTIMIZE(*NONE)

CRTSQLRPGI OBJ(MYLIB/ORDERPGM) +
            SRCSTMF('/home/myuser/projects/src/ORDERPGM.sqlrpgle') +
            COMMIT(*NONE) DBGVIEW(*SOURCE)

The SRCSTMF parameter accepts an IFS path. The Code for IBM i extension uses this internally when you compile from VS Code.

CI/CD: automating builds with Git hooks or pipelines

With Git on IBM i and source in the IFS, you can automate compilation. The simplest approach is a Git post-receive hook on a bare repository on the IBM i:

#!/QOpenSys/usr/bin/sh
# /home/git/repos/myproject.git/hooks/post-receive

while read oldrev newrev refname; do
  if [ "$refname" = "refs/heads/main" ]; then
    cd /home/myuser/projects
    git pull origin main
    # Compile changed programs
    system "CRTBNDRPG PGM(PRODLIB/ORDERPGM) SRCSTMF('/home/myuser/projects/src/ORDERPGM.rpgle')"
  fi
done

When someone pushes to main, the hook runs automatically, pulls the latest source, and compiles. More sophisticated pipelines use GitHub Actions or Jenkins with an IBM i agent — these are increasingly common in larger shops.

The migration reality

Moving from source physical files to IFS-based Git is not something most shops do all at once. The practical approach:

  1. Start with new development — any new program or significant rewrite goes into Git from the start
  2. Migrate active source — programs that are being worked on regularly are worth migrating individually as they come up for changes
  3. Leave legacy source in place — stable programs that have not changed in years can stay in source physical files until they need modification

The goal is not to migrate everything immediately — it is to stop the bleeding, so that new work is under version control from day one.

Next post: IBM i and the cloud — modernisation strategies, hybrid architectures, and what staying on IBM i actually means in 2025.

Leave a Comment

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

Scroll to Top