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 that no one can reproduce in development.

We also have strict rules for procedure exports. New procedures always go at the bottom of the list. If a procedure is no longer needed, we don’t delete it, we rename it with an _UNUSED_1 suffix (or _UNUSED_2, etc.) and leave it in the service program. This might feel odd at first, but it prevents downstream programs from breaking unexpectedly. By keeping unused procedures in place, bound programs still find the procedure entry point, even if it no longer performs useful work.

When updating procedures that are already in use in production, it’s important to be careful with the interface. A good rule of thumb is to add any new parameters at the bottom of the parameter list and make them Options(*NoPass). This ensures that existing calls continue to work without modification, while new programs can take advantage of the additional functionality.

For example, suppose we want to add a p_checkSeason parameter to MSHRMUTILS_IS_EDIBLE. The parameters are optional for existing programs:

Dcl-Pi MSHRMUTILS_IS_EDIBLE Ind;
    p_species Char(50) Const;
    p_checkSeason Char(10) Options(*NoPass) Const;
End-Pi;

Inside the procedure, you can code defensively by checking both the number of parameters passed and whether the parameter address is non-null:

If %Parms >= 2 and %Addr(p_checkSeason) <> *Null;
    // Parameter was passed
    If p_checkSeason = 'SUMMER';
        // Special handling
    EndIf;
Else;
    // Parameter not passed, default behavior
EndIf;

As a bonus tip, I always prefix my procedure parameters with p_. It’s a small convention, but it makes reading and maintaining code much easier. When you see p_species or p_checkSeason in the procedure, you immediately know it’s a parameter that was passed in, rather than a local variable or a global. Little habits like this save a lot of mental overhead when working with long-lived service programs.

A quick example: suppose you need to add a procedure to check whether a mushroom species is edible. You’d compile your development version of MSHRMUTILS with the new procedure MSHRMUTILS_IS_EDIBLE at the bottom of the export list, run your tests, and then promote to QA. Old programs that depend on MSHRMUTILS continue to function, while new programs can use the updated service program with confidence.

This approach has another advantage: It makes rollbacks simple. If a promoted update introduces unexpected behavior, you don’t scramble to restore a previous version from backup. You just point dependent programs back to the last known-good version of the service program. No downtime, no emergency rebuilds, no panicked emails.

In short, managing service programs is as much about process as it is about code. With versioning, careful export management, and disciplined naming conventions, you can update your libraries safely and confidently. You maintain stability while still allowing the shop to evolve and grow.

When you combine lifecycle management with thoughtful activation group choices and well-organized binding directories, you end up with a system that’s robust, maintainable, and predictable – something every RPG developer dreams about but few achieve without a plan.

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.

Content archive

Recent Posts

Subscribe

Pages

Search