This use case definitely makes sense to me.
So are you saying when you make a sub procedure call to a service program you can’t see globals from the main program ?
I think that was one of the curiosity questions I had outstanding.
Regards,
Richard Schoen
Web:
http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
-----------------------
message: 4
date: Sat, 21 Mar 2026 15:20:27 +0100
from: Marco Facchinetti <marco.facchinetti@xxxxxxxxx>
subject: Re: RPG Service Program vs Include Source for Shared
Subprocedures and SQL Calls
Most of the time the correct solution is *Srvpgm, but there are rare
exceptions where it may be preferable to use the copy version.
An example in (our) real life is the invoice printing program: since we
serve multiple customers and each has a specific version that shares 90% of
the code with the others, the use of copies solved the problem of
maintaining a common structure and having specific functionality.
Each shared routine or function contained in the copied members makes one
or more calls to custom routines/functions at fixed points (start, body,
and end). The return code of these calls determines whether or not to
execute the corresponding code in the standard function. This allows custom
code to replace or supplement the shared code.
I haven't found a simple way to do this using service programs, especially
since functions and routines in copied members make perfectly legitimate
use of the main program's "global" variables.
The problem with this kind of management where 90% of the code of a program
is not in the main source is that RDi cannot handle it, this is the reason
why I uploaded this idea:
https://ideas.ibm.com/ideas/IBMI-I-4740
midrange.com
