A service program (*SRVPGM) is a bound collection of procedures and data that other ILE programs and service programs call. IBM compares it to a subroutine library. This page is the lookup for what a service program is, how it relates to modules and programs, how binding reaches it, and which commands work on it.
The page owns the lookup. Building one from scratch, with a worked date-utility example, is in Build an ILE RPG Service Program. Design advice for a whole application is in IBM i ILE Binding, Activation Groups, and Service Programs in 2026. Procedures and the reason to share them are in Subprocedures and Service Programs in RPGLE.
The four ILE objects
| Object | Type | Created by | Runs by itself | Entry point |
|---|---|---|---|---|
| Module | *MODULE | CRTRPGMOD | No | A program entry procedure only if the module has one |
| Program | *PGM | CRTPGM, or CRTBNDRPG from one source member | Yes | One program entry procedure, called by a dynamic program call |
| Service program | *SRVPGM | CRTSRVPGM | No | None |
| Binding directory | *BNDDIR | CRTBNDDIR | No | None. A list of names the binder searches |
IBM’s characteristics of a *SRVPGM:
- One or more modules from any ILE language are copied to make it.
- It has no program entry procedure. A module’s entry procedure is ignored, so a dynamic program call to a service program is not valid.
- Other programs and service programs use the exports that make up its public interface.
- Only items exported from its modules are eligible to be exported from it. Procedures and data you leave out stay private.
- Signatures are generated from the exported names. A service program can be replaced without affecting its users as long as the earlier signatures are still supported.
- Weak data can be exported only to an activation group, not as part of the public interface.
How a program reaches a service program
A service program is reached by a static procedure call (a bound call), never by a dynamic program call.
| Call | Target | RPGLE form |
|---|---|---|
| Dynamic program call | A *PGM, ILE or OPM. Never a service program | The call operation, or a prototype with extpgm |
| Static procedure call | A procedure in the same module, another module of the same program or service program, or a service program | A prototype with no extpgm, or with extproc |
IBM notes that the default call in RPG and COBOL is a dynamic program call, which is why a service program procedure needs a prototype.
Bind by copy and bind by reference
The binder uses two methods when it creates a program or service program.
| Bind by copy | Bind by reference | |
|---|---|---|
| What is bound | Modules, named on MODULE or picked from a binding directory to satisfy an import | Service programs that supply an export for an unresolved import |
| What is stored | The module code is copied into the new object | A symbolic link to the service program |
| When addresses are fixed | When the program or service program is created | When the program that is bound to the service program is activated |
| Effect of changing the source object | The copy does not change until you rebuild | The program sees the service program as it is at activation |
IBM says that once the links are physical, there is little performance difference between accessing a local procedure and one in another module or service program bound to the same program.
Compile and bind flow
source member --CRTRPGMOD--> *MODULE --CRTSRVPGM + binder source--> *SRVPGM
caller source --CRTRPGMOD--> *MODULE --CRTPGM or CRTBNDRPG--> *PGM (symbolic link to *SRVPGM)
^
*BNDDIR names the *SRVPGM
The caller needs a prototype for each procedure and a way for the binder to find the service program: BNDSRVPGM, a binding directory, or both.
Commands that work on a service program
| Task | Command | Notes |
|---|---|---|
| Create | CRTSRVPGM | Binds the named modules. The EXPORT parameter picks the public interface |
| Replace modules | UPDSRVPGM | Replaces modules in an existing service program |
| Change attributes | CHGSRVPGM | Changes attributes without rebuilding |
| List and work with | WRKSRVPGM, DSPSRVPGM | DSPSRVPGM takes DETAIL values, below |
| Generate binder source | RTVBNDSRC | Builds binder language from the exports of modules or service programs |
| Delete | DLTSRVPGM | |
| See what a program is bound to | DSPPGM, DSPSRVPGM | DETAIL(*SRVPGM) lists the bound service programs |
These are the commands that decide a service program’s interface and runtime. The full parameter list of CRTSRVPGM is in the CRTSRVPGM Command Reference, and UPDSRVPGM and DSPSRVPGM are both covered in the UPDSRVPGM and DSPSRVPGM Command Reference.
CRTSRVPGM parameters that matter here
| Parameter | Values | Default | What it decides |
|---|---|---|---|
EXPORT | *SRCFILE, *ALL | *SRCFILE | *SRCFILE reads the exports from binder source. *ALL exports everything the modules export |
SRCFILE, SRCMBR | Source file and member | QSRVSRC, *SRVPGM | Where the binder source is |
SRCSTMF | Path name | Binder source in a stream file | |
BNDSRVPGM | *NONE or service programs, each with *IMMED or *DEFER | *NONE | Service programs searched to resolve imports |
BNDDIR | *NONE or binding directories | *NONE | Binding directories searched to resolve imports |
ACTGRP | *CALLER or a name | *CALLER | The activation group it runs in. *NEW is not supported for a service program |
DETAIL | *NONE, *BASIC, *EXTENDED, *FULL | *NONE | How much binder listing you get |
Binder source and signatures are in the RPGLE Binder Language and Signatures Reference. Activation groups are in the RPGLE Activation Groups Reference.
DSPSRVPGM detail values
DETAIL | Shows |
|---|---|
*BASIC | General service program information |
*MODULE | The modules bound into it |
*SRVPGM | The service programs bound into it |
*PROCEXP | Exported procedures |
*DTAEXP | Exported data items |
*SIGNATURE | All signatures |
A minimal build and call
The module is the NOMAIN source from the RPGLE Modules and NOMAIN Reference. The binder source lists its two exports.
CRTRPGMOD MODULE(MYLIB/REFUTIL) SRCFILE(MYLIB/QRPGLESRC) SRCMBR(REFUTIL) DBGVIEW(*SOURCE)
CRTSRVPGM SRVPGM(MYLIB/REFUTIL) MODULE(MYLIB/REFUTIL) EXPORT(*SRCFILE) +
SRCFILE(MYLIB/QSRVSRC) SRCMBR(REFUTIL) ACTGRP(*CALLER)
CRTBNDDIR BNDDIR(MYLIB/REFBND)
ADDBNDDIRE BNDDIR(MYLIB/REFBND) OBJ((MYLIB/REFUTIL *SRVPGM))
The caller prototypes the procedures and names the binding directory. It uses DFTACTGRP(*NO), because static binding is not available with DFTACTGRP(*YES).
**free
ctl-opt dftactgrp(*no) actgrp('REFDEMO') bnddir('REFBND');
dcl-pr refDouble int(10);
inNumber int(10) const;
end-pr;
dcl-pr refLabel varchar(30);
inNumber int(10) const;
end-pr;
dsply ('Result: ' + refLabel(refDouble(21)));
*inlr = *on;
CRTBNDRPG PGM(MYLIB/REFUCALL) SRCFILE(MYLIB/QRPGLESRC) SRCMBR(REFUCALL) DBGVIEW(*SOURCE)
DSPPGM PGM(MYLIB/REFUCALL) DETAIL(*SRVPGM)
Replacing a service program safely
UPDSRVPGM replaces modules in an existing service program without recompiling the bound service program. Other jobs can keep running it while it updates: the running version is moved to library QRPLOBJ, the updated version is put in the service program’s library, and current activations continue on the old version. What it does to signatures depends on EXPORT:
UPDSRVPGM EXPORT | Effect |
|---|---|
*CURRENT | The variables, procedures and signatures already exported continue to be exported. No new signature is created |
*ALL | If the exported names or their number differ from before, a new signature is created and all clients must be bound again |
IBM states that a signature does not validate the interface of a single procedure. If you change a procedure’s parameter list in a way that breaks callers, recompile every module that calls it and re-create the programs that contain them.
Common mistakes
- Trying to
calla service program as if it were a program. - Creating the caller with
DFTACTGRP(*YES)and then expecting binding to work. - Naming
*NEWas the service program’s activation group. - Using
EXPORT(*ALL)on a service program with clients and then adding a procedure, which changes the signature. - Updating a module with
UPDSRVPGMand assuming callers were re-bound. They are not. - Rebuilding a program’s source and expecting an old copy of a module inside a program to change. Copied modules do not.
- Leaving
DETAIL(*NONE)and then having no binder listing when a bind fails.
FAQ
What is a service program in RPGLE?
An ILE object that holds compiled procedures and data for other programs to call. It has no entry point, so it is bound to rather than called.
What is the difference between a service program and a program?
A program has an entry procedure and is started by a dynamic program call. A service program has none and is used by static procedure calls from other objects.
Can I call a service program with CALL?
No. IBM says a dynamic program call to a service program is not valid. Code a prototype and call the procedure.
Do I need a binding directory for a service program?
No. It is optional. You can name the service program on BNDSRVPGM instead. A binding directory lets you name one list instead of each service program. See the RPGLE Binding Directories Reference.
Summary
- A service program is a
*SRVPGMof exported procedures and data with no entry point. - It is reached by static procedure calls through bind by reference. Modules are bound by copy.
CRTSRVPGMcreates it,UPDSRVPGMreplaces modules, andDSPSRVPGMshows its signatures, exports and bound objects.EXPORTdecides the public interface and therefore the signature.- Related: the RPGLE Modules and NOMAIN Reference, the RPGLE Binder Language and Signatures Reference, the RPGLE Binding Directories Reference and the RPGLE Activation Groups Reference.
Sources: IBM i 7.5 ILE Concepts (service programs, binding, the CL commands used with ILE objects), the IBM i 7.5 command pages for CRTSRVPGM, UPDSRVPGM and DSPSRVPGM, and the IBM i 7.5 ILE RPG Reference. The examples have been reviewed against that text. They have not been compiled or run.