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 it a day, but that’s the fastest way to turn your service program into a public free-for-all. With binder source, you can be precise. You write a simple source member that lists only the procedures you want to expose, and that list becomes your service program’s official interface. Internal helpers and one-off routines stay private, safely tucked away where no one else can mess with them.

Now, there are two schools of thought on managing binder source changes. Many teams use signatures to version their interfaces. A signature acts like a stamp of authenticity: when a program binds to a service program, it binds to a specific signature. If you change a procedure, you create a new signature, and programs built against the old signature keep working. This is a strong approach for large shops or vendors shipping code to multiple customers, because it provides a bulletproof versioning system.

In my shop, we take a different tack: no signatures at all. That might sound reckless, but it works when the entire team follows two rules. First, we only add new procedure exports at the bottom of the binder source. Second, if a procedure is no longer needed, we don’t delete it – we rename it, for example, MSHRMUTILS_UNUSED_1. By never removing or rearranging procedure exports, we ensure that nothing breaks during binding, even as the service program evolves. This approach works beautifully in environments where you control the entire codebase and have tight process discipline.

A good rule of thumb is to keep binder source in QBNDSRC, and name the binder source member after the service program it defines. The syntax is simple enough: a STRPGMEXP block to start, a list of exported procedures, and an ENDPGMEXP block to finish. Here’s a clean example, signature-free:

STRPGMEXP  PGMLVL(*CURRENT)
  EXPORT SYMBOL('MSHRMUTILS_SAVE_NEW_SPECIES')  
  EXPORT SYMBOL('MSHRMUTILS_IS_EDIBLE')  
ENDPGMEXP

Three lines, and you’ve made your service program predictable, maintainable, and easy to extend. Whether you use signatures or follow a strict “add only, rename never delete” policy, binder source gives you the control you need to evolve your application safely.

Binder source doesn’t get a lot of love because it feels like one more thing to write. But when you think about it, this little file is your service program’s documentation, its roadmap, and its change history all in one. It gives your team confidence to evolve your codebase without fear of breaking everything downstream.

If your shop isn’t using binder source, start today. If you are, step back and evaluate your strategy. Signatures offer flexibility for teams supporting multiple versions. A signature-free approach, if enforced with discipline, is simpler and leaner for shops with tight internal control. Either way, your service programs are only as strong as the contracts they enforce, and binder source is how you write those contracts.

In the next installment, we will step away from binder source and talk about performance: What happens under the covers when you bind modules and service programs, and how you can make choices today that save you from performance bottlenecks tomorrow.

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