Changing a Service Program

26 Views

Prev
Next

This is where binder source and service program signatures shine.
You can fix code inside a service program and avoid recompiling all dependent programs as long as you don’t change the service program’s signature.

How it works (one-minute version)

  • When you compile a program that uses a service program, the program gets bound to the service program’s signature (a kind of version ID).

  • If you later rebuild the service program with the same signature, existing programs keep running—no recompile needed.

  • You control the signature and exported procedures with binder source (QSRVSRC).

Setup: create SRVPGM with binder source

1) RPG module (example)

// MATHMOD.RPGLE
ctl-opt dftactgrp(*no) actgrp(*caller);

dcl-proc AddNums export;
  dcl-pi *n int(10); a int(10); b int(10); end-pi;
  return a + b;
end-proc;

CRTRPGMOD MODULE(MYLIB/MATHMOD) SRCFILE(MYLIB/QRPGLESRC)

2) Binder source (controls exports & signature)

Create MYLIB/QSRVSRC(MATHSRV) with:

STRPGMEXP  PGMLVL(*CURRENT)  SIGNATURE('MATHSRV 1.0')
  EXPORT SYMBOL('ADDNUMS')
ENDPGMEXP

3) Create the service program

CRTSRVPGM SRVPGM(MYLIB/MATHSRV)
          MODULE(MYLIB/MATHMOD)
          EXPORT(*SRCFILE) SRCFILE(MYLIB/QSRVSRC) SRCMBR(MATHSRV)

4) Program that calls it (bind once)

// MAINPGM.RPGLE
ctl-opt dftactgrp(*no) actgrp(*caller);

dcl-pr AddNums int(10) extproc(*dclcase);
  a int(10); b int(10);
end-pr;

dsply %char(AddNums(5:3));

CRTBNDRPG PGM(MYLIB/MAINPGM) SRCFILE(MYLIB/QRPGLESRC)
          BNDSRVPGM((MYLIB/MATHSRV))

Later: fix a bug or change logic—no recompile of callers

  1. Edit MATHMOD.RPGLE (fix bug in AddNums, optimize, etc.).

  2. Rebuild module:

CRTRPGMOD MODULE(MYLIB/MATHMOD)

  1. Rebuild the service program with the same binder source/signature:

UPDSRVPGM SRVPGM(MYLIB/MATHSRV)
          MODULE((MYLIB/MATHMOD))
          EXPORT(*SRCFILE) SRCFILE(MYLIB/QSRVSRC) SRCMBR(MATHSRV)

(or re-run CRTSRVPGM with the same binder source)

✅ All existing programs continue to run without recompilation because the signature stayed 'MATHSRV 1.0'.

Adding new procedures without breaking old programs

If you add a new exported proc (e.g., MulNums) and want old programs to keep working while new ones can use it, use signature levels:

Binder source:

STRPGMEXP  PGMLVL(*CURRENT) SIGNATURE('MATHSRV 2.0')
  EXPORT SYMBOL('ADDNUMS')
  EXPORT SYMBOL('MULNUMS')
ENDPGMEXP

STRPGMEXP  PGMLVL(*PRV)     SIGNATURE('MATHSRV 1.0')
  EXPORT SYMBOL('ADDNUMS')
ENDPGMEXP

  • Recreate/update the service program with this binder source.

  • Old programs remain bound to 'MATHSRV 1.0' (work unchanged).

  • New programs bind to 'MATHSRV 2.0' (can call MULNUMS).

Best practices you really want

  • Always use binder source (EXPORT(*SRCFILE)).
    Avoid EXPORT(*ALL) in production—adding/removing exports changes the signature unexpectedly and forces mass recompiles.

  • Keep the signature stable for bugfix-only updates.

  • Use signature levels when adding exports (backward compatibility).

  • Put service programs in actgrp(*CALLER) unless you have a reason not to.

  • If you’ve lost binder source, you can retrieve from an existing SRVPGM:

    RTVBNDSRC SRVPGM(MYLIB/MATHSRV) SRCFILE(MYLIB/QSRVSRC) SRCMBR(MATHSRV)

If you tell me your current SRVPGM name and whether you need to add or just fix procedures, I’ll sketch the exact QSRVSRC you should use and the commands to run, step by step.

Prev
Next
Save ()

Post Comments