Two commands maintain a service program after it exists. UPDSRVPGM (Update Service Program) replaces modules in it. DSPSRVPGM (Display Service Program) shows what is in it: the modules, the exports and the signatures. They belong on one page because the working routine is to look, change, and look again: display the signatures, update, and confirm the signature did not change.
To create a service program, see CRTSRVPGM. For what a service program is, see the RPGLE Service Programs Reference, and for a build from scratch, Build an ILE RPG Service Program.
At a glance
| Question | UPDSRVPGM | DSPSRVPGM |
|---|---|---|
| What it does | Replaces modules in an existing service program with modules of the same name | Displays or prints information about a service program |
| Changes the object? | Yes | No |
| Needs | The service program, and the new modules already compiled with CRTRPGMOD | The service program and a DETAIL value |
| Use it to | Ship a fix without rebuilding the whole service program | Check exports and signatures before and after a change |
UPDSRVPGM
IBM says UPDSRVPGM replaces modules of an ILE bound service program with other modules on the system, without requiring you to change or recompile the bound service program, and that other jobs can keep running it during the update.
| Parameter | Default | What it decides |
|---|---|---|
SRVPGM | required | The service program to update |
MODULE | required | The modules that replace modules of the same name, up to 300. *ALL and generic names are allowed |
EXPORT | *CURRENT | *CURRENT keeps the existing exports and signatures and creates no new signature. *SRCFILE reads EXPORT statements from binder source. *ALL exports everything the modules export |
SRCFILE, SRCMBR, SRCSTMF | QSRVSRC, *SRVPGM | Where the binder source is, when EXPORT(*SRCFILE) is used |
RPLLIB | *ONLY | Which module is replaced when several modules in the service program have the same name. *ONLY needs exactly one match, *FIRST takes the first, *MODULE matches by original library, or you name a library |
BNDSRVPGM | *NONE | Service programs to examine to resolve imports |
BNDDIR | *NONE | Binding directories to search to resolve imports |
ACTGRP | *SAME | The activation group stays as it was |
DETAIL | *NONE | The binder listing: *BASIC, *EXTENDED or *FULL |
Example
UPDSRVPGM SRVPGM(MYLIB/REFUTIL) MODULE(MYLIB/REFUTIL) DETAIL(*EXTENDED)
This replaces the module REFUTIL in the service program REFUTIL with a freshly compiled module of that name. With the default EXPORT(*CURRENT), no new signature is made.
Result: the service program holds the new module. On the test system DSPSRVPGM DETAIL(*SIGNATURE) listed the same signature after the update as before it.
What to know
- You need the right authority. IBM says you must own the service program or have
*ALLOBJspecial authority. - Running jobs keep the old version. IBM says the running service program is moved to library
QRPLOBJ, the updated one is put in the original library, and current activations continue with the copy inQRPLOBJ. New activations use the updated service program. - The module must match what callers expect.
EXPORT(*CURRENT)keeps the signature, so the new module must still provide every procedure the signature exports. A change to the interface needs a rebuild with binder source and aPGMLVL(*PRV)block. See the RPGLE Binder Language and Signatures Reference. RPLLIB(*ONLY)fails on ambiguity. If the service program was built from two modules of the same name from different libraries, name the library.
DSPSRVPGM
DSPSRVPGM SRVPGM(MYLIB/REFUTIL) DETAIL(*SIGNATURE)
DETAIL is required. OUTPUT is * to display and *PRINT for a spooled listing. On a screen you page through the detail types. To keep a result, use OUTPUT(*PRINT).
DETAIL | Shows |
|---|---|
*BASIC | General service program information |
*SIZE | Sizes and size limits |
*MODULE | The modules bound in, with their original libraries |
*SRVPGM | The service programs bound in |
*PROCEXP | The procedures exported by the current signature |
*DTAEXP | The data items exported by the current signature |
*ACTGRPEXP | The data items exported to the activation group |
*ACTGRPIMP | The imports resolved by weak activation group exports |
*SIGNATURE | The service program’s signatures, the first being the current one |
*COPYRIGHT | The service program’s copyrights |
*ALL | Every detail type, in scrollable sections |
What the test system showed for the service program built in CRTSRVPGM:
| Command | Observed |
|---|---|
DETAIL(*SIGNATURE) | One signature. Binder source with SIGNATURE('REFUTIL_VERSION1') shows as the EBCDIC hex D9C5C6E4E3C9D36DE5C5D9E2C9D6D5F1 |
DETAIL(*PROCEXP) | Procedures REFDOUBLE and REFLABEL |
DETAIL(*MODULE) | The bound module REFUTIL |
After a rebuild with a PGMLVL(*PRV) block, *SIGNATURE listed two signatures, current first. To see which service programs a program is bound to, use DSPPGM with DETAIL(*SRVPGM) instead.
Common mistakes
- Using
UPDSRVPGMto change the interface. WithEXPORT(*CURRENT)the exports and signatures stay. To add a procedure, rebuild with binder source. - Not looking before and after. Run
DSPSRVPGM DETAIL(*SIGNATURE)before the update and after it, and compare. - Updating a service program that jobs are using and expecting them to switch. Current activations continue with the old copy.
- Forgetting
OUTPUT(*PRINT). The display does not keep the result. - Mixing up
DSPSRVPGMandDSPPGM.DSPSRVPGMdescribes the service program.DSPPGMwithDETAIL(*SRVPGM)lists the service programs a program uses. - Expecting
UPDSRVPGMto compile. It binds modules that already exist.
Related commands
| Command | Relation |
|---|---|
| CRTRPGMOD | Compiles the replacement module |
| CRTSRVPGM | Creates or rebuilds the service program |
| CRTPGM | Binds a program to the service program |
CHGSRVPGM, WRKSRVPGM, DLTSRVPGM | Change attributes, work with, and delete. Listed in the RPGLE Service Programs Reference |
FAQ
What does UPDSRVPGM do?
It replaces modules in an existing service program with same-named modules, without recompiling or rebuilding the service program from scratch.
Does UPDSRVPGM change the signature?
Not with the default EXPORT(*CURRENT). IBM says no new signatures are created. On the test system the signature was the same after the update.
How do I see a service program’s signature?
DSPSRVPGM SRVPGM(lib/name) DETAIL(*SIGNATURE). The first one listed is the current one.
How do I list the procedures a service program exports?
DSPSRVPGM SRVPGM(lib/name) DETAIL(*PROCEXP).
Summary
UPDSRVPGMreplaces modules in a service program. Its defaultEXPORT(*CURRENT)keeps the exports and signatures.- Running activations keep the old copy, which IBM moves to
QRPLOBJ. DSPSRVPGMneeds aDETAILvalue.*SIGNATURE,*PROCEXPand*MODULEanswer most questions.- Display the signatures before and after every update.
Sources: IBM i 7.5 UPDSRVPGM command, DSPSRVPGM command and IBM i 7.5 ILE Concepts. On IBM i V7R5M0 (PUB400, 2026-10-07) UPDSRVPGM with the default export ran and left the signature unchanged (steps U01 to U03), and DSPSRVPGM with *SIGNATURE, *PROCEXP and *MODULE gave the output above (B03 to B05, S06). The QRPLOBJ behaviour, the authority rule, RPLLIB, and every DETAIL value other than those three were checked against IBM documentation only and were not run.