June 1, 2026
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 a single, well-defined home.
Let’s build that home.
We will start in the database, where the responsibility truly belongs. A mushroom catalog needs a unique identifier for each specimen we record. Rather than storing and incrementing a value manually, we create a sequence object that guarantees uniqueness and concurrency safety.
Here is a simple example of creating a sequence named Msh_Cat_Id in your library:
CREATE SEQUENCE MYLIB.Msh_Cat_Id AS BIGINT START WITH 1 INCREMENT BY 1 NO MAXVALUE NO CYCLE CACHE 20;
This definition tells Db2 to generate a never-ending stream of numbers, starting at one and increasing by one each time it is requested. The cache improves performance by reducing trips to disk, which matters when your application grows and many jobs are harvesting identifiers at the same time.
Now that the database owns the responsibility of generating identifiers, we turn to RPG. Our goal is not to embed this logic everywhere it is needed. That would scatter responsibility and make future change painful. Instead, we wrap access to the sequence in a single procedure whose only job is to retrieve the next value.
This is where procedure driven RPG shines. The procedure does one thing. Its name makes that thing obvious. And every caller benefits from the same consistent behavior.
Below is a minimal SQLRPGLE example of such a procedure:
dcl-proc Get_Next_Mushroom_Catalog_Id export; dcl-pi Get_Next_Mushroom_Catalog_Id packed(15:0); end-pi; dcl-s next_Id packed(15:0); Exec sql VALUES NEXT VALUE FOR MYLIB.Msh_Cat_Id INTO :next_Id; return next_Id; end-proc Get_Next_Mushroom_Catalog_Id;
There is no extra logic here because none is needed. The procedure is a thin, intentional wrapper over the sequence. It does not validate, transform, or interpret. It simply retrieves. This simplicity is not a lack of design. It is the result of good design. By resisting the urge to do more, we preserve clarity. If requirements change tomorrow, perhaps the identifier needs a prefix or comes from a different source, we know exactly where to go. One procedure. One responsibility.
Using the procedure is equally straightforward.
dcl-s catalogId packed(15:0); catalogId = GetNextMshCatId();
That single line replaces what used to require a data area, a lock, error handling, and a quiet sense of unease about concurrency. Now the database guarantees correctness, and the procedure guarantees consistency of access.
This pairing of SQL sequences with small, focused RPG procedures is a perfect example of how modern capabilities fit naturally into a procedure driven approach. The database handles what it is best at. RPG orchestrates through clear, intention revealing procedures.
Much like a healthy mushroom network beneath the forest floor, the strength of the system is not in any one piece, but in how cleanly each piece connects to the next.
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.
RELATED STORIES
Guru: IBM i Job Log Detective Brings Structure To Job Log Analysis In VS Code
Guru: Managing The Lifecycle Of Your Service Programs – Updates Without Chaos
Guru: Are Binding Directories A Shortcut Or A Source Of Chaos?
Guru: Service Programs And Activation Groups – Design Decisions That Matter
Guru: Binder Source Is Your Service Program’s Owner’s Manual
Guru: Access Client Solutions 1.1.9.11 – Security First, With Continued Investment In SQL Tooling
Guru: Taming The CRTSRVPGM Command – Options That Can Save Your Sanity
Guru: CRTSRVPGM Parameters That Can Save or Sink You
Guru: A First Look at Bob, The IBM i Assistant That’s Closer Than You Think
Bob More Than Just A Code Assistant, IBM i Chief Architect Will Says
IBM Pulls The Curtain Back A Smidge On Project Bob
Big Blue Converges IBM i RPG And System Z COBOL Code Assistants Into “Project Bob”
Guru: When Attention Turns To You – Writing Your Own ATTN Program
Guru: WCA4i And Granite – Because You’ve Got Bigger Things To Build
Guru: When Procedure Driven RPG Really Works
Guru: Unlocking The Power Of %CONCAT And %CONCATARR In RPG
Guru: AI Pair Programming In RPG With Continue
Guru: AI Pair Programming In RPG With GitHub Copilot
Guru: RPG Receives Enumerator Operator
Guru: RPG Select Operation Gets Some Sweet Upgrades
Guru: Growing A More Productive Team With Procedure Driven RPG
Guru: With Procedure Driven RPG, Be Precise With Options(*Exact)
Guru: Testing URLs With HTTP_GET_VERBOSE
Guru: Fooling Around With SQL And RPG
Guru: Procedure Driven RPG And Adopting The Pillars Of Object-Oriented Programming
Guru: Getting Started With The Code 4 i Extension Within VS Code
Guru: Procedure Driven RPG Means Keeping Your Variables Local
Guru: Procedure Driven RPG With Linear-Main Programs
Guru: Speeding Up RPG By Reducing I/O Operations, Part 2
Guru: Speeding Up RPG By Reducing I/O Operations, Part 1
Guru: Watch Out For This Pitfall When Working With Integer Columns























