Gregory Simmons
-
Guru: Putting Failure Handling In Its Place
August 24, 2026 Gregory Simmons
One of the things I enjoy most about procedure-driven RPG is that it encourages us to think about responsibility. Every procedure should have a clear purpose. It should perform one task well and leave unrelated concerns to other parts of the application.
That sounds straightforward enough, yet one responsibility often finds its way into nearly every procedure we write: failure handling.
If you have worked with RPG for any length of time, you have probably encountered applications where nearly every procedure begins with a MONITOR operation. The procedure performs its work, catches any exception that occurs, logs an error, returns …
Read more -
Guru: Beyond Three-Part Naming – Running SQL Across Remote IBM i Systems
August 3, 2026 Gregory Simmons
In my article Guru: Finding Data in The Forest – Exploring Three-Part Naming In SQL, I helped you to get started with three-part naming. If you have a network of IBM i systems and haven’t availed yourself of this capability, you may be surprised at just how powerful it can be. Instead of relying on data transfers, replication, or intermediate files, SQL can reach directly into remote systems as though the data were local.
That works well when you know exactly which remote system contains the data you need. But what happens when your network grows from a handful …
Read more -
Guru: Finding Data In The Forest – Exploring Three-Part Naming In SQL
June 22, 2026 Gregory Simmons
Anyone who has spent time foraging for mushrooms knows that location matters. A chanterelle found in the Pacific Northwest is not the same as one discovered in the hardwood forests of the Midwest. Experienced foragers do not simply note what they found. They record exactly where they found it: the region, the forest, and the specific location. Context matters.
The same is true in SQL. Most IBM i developers are comfortable with two-part naming. A reference like MUSHLIB.FORAGE_LOG identifies both the schema and the object. It tells SQL where to look within a single system, much like noting the forest …
Read more -
Guru: SQL Sequences In RPG Let Db2 Handle The Counting
June 1, 2026 Gregory Simmons
There is something deeply satisfying about letting the database do the counting for you. In a world where we have spent decades hand-rolling identifiers, guarding them with locks, and hoping no job collides with another, SQL sequences feel like discovering a patch of mushrooms that quietly regenerate overnight. You stop worrying about scarcity and start focusing on what matters.
In a procedure driven RPG system, this is exactly the kind of responsibility we want to isolate. Generating a new identifier is not business logic. It is not validation. It is not formatting. It is a single, well-defined action that deserves …
Read more -
Guru: Cohesion First – What A Procedure Should Be Responsible For
April 6, 2026 Gregory Simmons
One of the easiest mistakes to make in procedure-driven RPG is assuming that small procedures are automatically well-designed procedures. They are not. Size and cohesion are related, but they are not the same thing. A cohesive procedure has a single, clear responsibility. It exists to answer one business question or perform one business action. When a procedure tries to do more than that, it stops being a reusable building block and starts becoming a liability.
In procedural RPG, nothing enforces this discipline. There is no compiler warning when a procedure quietly takes on a second responsibility. There is no language …
Read more -
Guru: IBM i Job Log Detective Brings Structure To Job Log Analysis In VS Code
March 9, 2026 Gregory Simmons
Remain Software has released a new Visual Studio Code extension called IBM i Job Log Detective, and it targets a pain point every IBM i developer understands: reading job logs efficiently.
In addition to its marketplace availability, IBM i Job Log Detective is open source under the MIT license and can be found on GitHub at: https://github.com/RemainSoftware/jld
Read more
There has never been anything wrong with IBM i job logs themselves. They are exhaustive, consistent, and remarkably detailed. When something fails, the job log contains the truth. The issue has always been consumption. Large QPJOBLOG files can run thousands of lines (or … -
Guru: Managing The Lifecycle Of Your Service Programs – Updates Without Chaos
February 23, 2026 Gregory Simmons
You’ve written your service programs, organized your modules, picked your activation groups, and maybe even set up a tidy binding directory. Everything seems perfect – until someone needs to update a procedure that half the shop’s programs depend on. Suddenly, that tidy structure can feel like a trap. Welcome to the reality of service program lifecycle management.
The key principle here is simple: change with care. Any update to a service program can ripple across every program bound to it. Without a strategy, you’ll find yourself fielding calls about broken reports, failed jobs, or, worst of all, subtle logic errors …
Read more -
Guru: Are Binding Directories A Shortcut Or A Source Of Chaos?
February 16, 2026 Gregory Simmons
Ask any IBM i developer about binding directories, and you will usually get one of two reactions: A grateful nod or an eye roll. For some, binding directories are a lifesaver, making compile commands cleaner and projects easier to manage. For others, they are a ticking time bomb, introducing hidden dependencies that come back to haunt you months later.
I have seen both sides. In fact, one of the worst compile-day disasters I’ve witnessed started with a well-meaning developer adding a single service program to a global binding directory. Suddenly, half the shop’s programs were linking against the wrong version …
Read more -
Guru: Service Programs And Activation Groups – Design Decisions That Matter
February 9, 2026 Gregory Simmons
If you have been writing service programs for a while, you might treat binding like flipping a light switch: write some code, compile it, bind it, done. It works – until it doesn’t. Behind the scenes, IBM i is doing a lot more than just connecting your program to a library of procedures. And if you’re not paying attention to activation groups and how you structure your service programs, you might be setting yourself up for sluggish performance or debugging nightmares down the road.
Let’s demystify what is really happening when you bind and why activation groups deserve more of …
Read more -
Guru: Binder Source Is Your Service Program’s Owner’s Manual
February 2, 2026 Gregory Simmons
If service programs are the backbone of modular RPG development, then binder source is the owner’s manual you didn’t know you needed. It’s not glamorous, but it’s the piece that ties everything together: Controlling what you export, defining your public API, and managing change over time. Yet, far too many shops treat binder source as optional – if they use it at all. That’s a mistake.
Let’s start with what binder source actually does. When you create a service program, you need to tell the system which procedures should be visible to callers. You could just use EXPORT(*ALL) and call …
Read more