Guru: When Procedure Driven RPG Really Works

July 14, 2025 Gregory Simmons

In the vast and varied ecosystems of Earth, few interactions between species have captured the imagination of scientists and casual observers alike as much as the relationship between bottlenose dolphins and puffer fish. This curious dance, often involving the deliberate provocation of the puffer fish to trigger its natural defense mechanism, has led to many interpretations – from simple play to speculative pharmacological experimentation. I submit to you today, that in the digital ocean of RPG development, developers should interact with their procedures in ways that, to the outside eye, might seem equally cryptic, yet are deeply intentional, meticulously orchestrated, and profoundly significant to the one crafting the code.

Imagine a bottlenose dolphin gliding through the warm waters of a coastal bay. It zeroes in on a puffer fish, nudging it, provoking it until the fish inflates, its body ballooning with a defensive cocktail of toxins. The dolphin then passes the fish to another member of its pod, who does the same. This isn’t a haphazard skirmish; it is a controlled ritual. The dolphins are careful, calculated in their interactions. Many observers believe the dolphins are experiencing a form of intoxication from the puffer fish’s tetrodotoxin. Regardless of whether the motivation is play, altered consciousness, or something else entirely, the behavior is unmistakably deliberate.

Recently, I came across an unfortunate situation which I suspect happens all too often in my shop and yours a like. A developer (no names here, I’ll keep it friendly just in case he reads this someday), while working on an enhancement, had created a procedure to wrap the logic of calling another series of programs. He did a fabulous job on the enhancement. The unfortunate part was that there were two problems with the procedure he wrote to wrap the other logic. The first concern was that while the logic is something that a lot of our programs and service programs need to perform, his procedure was not exported. So, others couldn’t benefit from using his new procedure. The second, and bigger, concern was that there was already a procedure someone had written a few years before.

RPG developers need to interact with their creations in ways that mimic the dolphin and the puffer fish. A finely crafted RPG procedure is not just a bundle of logic and operations; it’s a carefully tuned mechanism that controls the flow of data, integrity of transactions, and the very heartbeat of business processes. When a developer has written a procedure, they shouldn’t just run it and see that it gets the job done. They should test its boundaries, take a step back and envision how other developers could also use their creation. Then, most importantly, they should pass it around like a dolphin passing a puffer fish, sharing it with others. Ask another developer to do a code review with you. Show it off in your next team or department meeting!

I once had someone ask me, “Aren’t procedures just a different way of coding a subroutine?” I sighed, and thought, well you do have the ability to treat procedures as just another subroutine. At its root, a procedure can be nearly identical to a subroutine:

Dcl-Proc is_valid_invoice;
  Dcl-Pi is_valid_invoice Ind;
  End-Pi;
  Dcl-s result Ind Inz(*Off);
  // Perform necessary logic using GLOBAL variables only.
  Return result; 
End-Proc is_valid_invoice;

The above procedure, when running would perform almost identical to a subroutine. The only noticeable difference is when you stopped it in debug and examined the call stack of that job, you would see that it’s processing ‘is_valid_invoice’, whereas if that was a subroutine, you would just see that you are running that program; not the subroutine. Now, when embedded within a 20,000-line program, I’m sure you would agree that knowing the more accurate location is valuable.

As a quick example, perhaps the above procedure could accept some optional parameters:

Dcl-Proc is_valid_invoice;
  Dcl-Pi is_valid_invoice Ind;
    *n Uint(5) Options(*Nopass:*Omit);
    *n Ind Options(*Nopass:*Omit);
	  *n Char(30) Const Options(*Convert);
	  *n Char(50) Options(*Varsize);
  *n Date Options(*Exact);
  End-Pi;
  Dcl-s result Ind Inz(*Off);
  Return result; 
End-Proc is_valid_invoice;

Again, the above is just a brief sampling of the many ways the RPG language allows developers to create procedures which can be useful to a wider audience. Not just the original author.

It is important to invest a little time to conduct periodic code reviews and share your final procedure with your fellow dolphins developers. Over time, you will find that your team benefits from your new procedure. The advantages include reduced duplication of business logic, elimination of ‘Reinventing the Wheel’, and less maintenance when that piece of business logic needs to be updated. Most importantly, these benefits, while perhaps not as potent as the mind-altering state of the dolphin with the puffer fish, lead to happier developers and perhaps more importantly; less technical debt!

Just as the dolphin shares the puffer fish with its fellow dolphins, RPG developers must also learn to share their finely crafted procedures. It’s not enough to create elegant code in isolation. The true power of a procedure driven RPG is realized when new procedures are passed around, explored, and understood by others. Sharing code, explaining its design, and inviting feedback are not acts of vulnerability – they are acts of strength. They ensure that knowledge is not siloed, that value multiplies across a team or an organization, and that the artistry of one developer can inspire and elevate the work of others.

In the end, both the dolphin and the developer are explorers. The dolphin explores the boundaries of biological interaction, perhaps even consciousness. The developer explores the boundaries of logical systems, bending rules to optimize performance, to refine understanding, to express a kind of digital artistry. Both engage with their chosen companions not out of necessity alone, but out of a compulsion to understand, to refine, to elevate.

But unlike the solitary dolphin, the wise developer will extend the metaphor one step further: they will pass the puffer fish along. They will share their work, enriching the pod, building not just great code, but a great culture.

Until next time, happy coding.

Gregory Simmons is a Project Manager with PC Richard & Son. He started on the IBM i platform in 1994, graduated with a degree in Computer Information Systems in 1997 and has been working on the OS/400 and IBM i platform ever since. He has been a registered instructor with the IBM Academic Initiative since 2007, an IBM Champion and holds a COMMON Application Developer certification. When he’s not trying to figure out how to speed up legacy programs, he enjoys speaking at technical conferences, running, backpacking, hunting, and fishing.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search