Programs, Modules, and Service Programs: Making Sense of the ILE Object Model

The Integrated Language Environment, or ILE, object model is the structural backbone of nearly everything built on IBM i today, and understanding how its core object types relate to one another is essential before writing modern ILE RPG.

A *MODULE object is the first stop in the ILE build process: source code that has been compiled but not yet bound into anything executable. Modules are, in effect, self-contained building blocks — units of compiled logic that don't run on their own but are combined with other modules to produce something that does.

That combination happens through binding, which produces either a *PGM object or a *SRVPGM object. A *PGM is a standalone, executable program — the object that actually runs when a user, job, or another program calls it. A *SRVPGM, or service program, is different in an important way: rather than being a single executable entry point, it's a shared collection of procedures that multiple programs can call without each one carrying its own private copy of that logic. Developers familiar with DLLs on Windows or shared objects on Linux will recognize the concept immediately.

This separation matters enormously for how well-structured applications are built. Common business logic — validation routines, calculation procedures, reusable data access logic — belongs in service programs, where it can be maintained in one place and consumed consistently by every program that needs it. Applications built without this separation tend to accumulate duplicated logic scattered across dozens of programs, each one a separate opportunity for inconsistency and bugs.

The fourth core object type, *FILE, covers a broader category: database tables, display files, printer files, and more all share this type, though their specific attributes and uses differ substantially. A *FILE object is what programs read from, write to, and display through, and it's the object type most directly tied to the data and interaction layer of an application.

Recognizing these object types on sight — and understanding the module-to-program-or-service-program relationship in particular — makes it far easier to read an unfamiliar application's structure. Commands like DSPPGM, DSPSRVPGM, and DSPMOD let a developer inspect exactly how a given object was built and what it depends on, turning what might otherwise be a black box into something legible.

This lesson is Lesson 7 of IBM i Platform Foundations in IBM i ILE RPG Mastery, laying the object-model groundwork that later lessons on service program design build directly on top of.