The “should we leave IBM i?” conversation has been happening for twenty years. The shops that handled it well are running modern hybrid architectures in 2026 — IBM i at the transactional core, cloud services handling front ends, analytics, and integration. Here is what that actually looks like.
Most IBM i shops still manage source the same way they did in the 1990s — members in source physical files, no history, no easy rollback. Git changes that. This post covers RDi, VS Code + Code for IBM i, migrating source to the IFS, and a practical Git workflow for RPG and CL development.
IBM i batch jobs are the ones nobody watches — until one fails. This post covers SBMJOB, WRKJOBSCDE, job queues, completion monitoring, and the production patterns that keep overnight processing reliable.
Every RPG developer eventually writes a program that does something it should not. The calculation is wrong. The loop runs
Most RPG programs are written to handle the happy path. The file exists, the record is found, the calculation succeeds,
IBM i has a reputation for being secure. That reputation is earned — the security model is granular, well-designed, and
Performance problems on IBM i tend to fall into a small number of categories. A query that reads every record
Every IBM i developer eventually ends up doing some administration. A job gets stuck. The output queue fills up. A
IBM i has been talking to other systems for decades. EDI over AS/400 communications, FTP file drops, MQ message queues
Most IBM i developers spend their entire careers working with physical files and never touch the IFS. That is understandable