Re: RPG Service Program vs Include Source for Shared Subprocedures and SQL Calls

I have found myself spending a lot of time searching for variables that "sneak into" a program upon compilng. You can say "Big deal", and I have, but also, getting a lot more lines than you bargained for sometimes, like when you /COPY the SDS fields or other such. 

I prefer using subprocedures or other methods for using such entities. All your fields and variables "front and center".

--Alan Cassidy


> On 03/23/2026 5:29 PM EDT Marco Facchinetti <[email protected]> wrote:
> 
>  
> Thanks Charles, I know many consider the use of global variables to be
> wrong, and indeed, in a service program, this is absolutely true. But when
> it comes to programs, especially those types of programs, I find that using
> copy members makes general maintenance much easier.
> 
> Thanks for your time.
> 
> Best regards
> --
> Marco Facchinetti
> 
> Mr S.r.l.
> 
> Tel. 035 962885
> Cel. 393 9620498
> 
> Skype: facchinettimarco
> 
> 
> Il giorno lun 23 mar 2026 alle ore 15:27 Charles Wilt <
> [email protected]> ha scritto:
> 
> > I suspect procedure pointers could help with your use case, but would
> > likely be a significant refactor.
> >
> > If nothing else, you'd need to remove the use of global variables from your
> > procedures.  IMPORT / EXPORT exists, but you generally want to stay away
> > from them.
> >
> > Just to give you an idea..I've got a set of applications.  Most of the work
> > is done in a *SRVPGM.  The individual program objects contain the
> > procedures with unique functionality.  So each *PGM object has a small
> > mainline that sets up various variables and calls into the main *SRVPGM
> > procedure passing along the needed PROCPTRs to provide the service program
> > access to the needed unique functionality.
> >
> > HTH,
> > Charles
> >
> > On Sat, Mar 21, 2026 at 8:20 AM Marco Facchinetti <
> > [email protected]> wrote:
> >
> > > 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
> > >
> > > Best regards
> > > --
> > > Marco Facchinetti
> > >
> > > Mr S.r.l.
> > >
> > > Tel. 035 962885
> > > Cel. 393 9620498
> > >
> > > Skype: facchinettimarco
> > >
> > >
> > > Il giorno ven 20 mar 2026 alle ore 22:13 Richard Schoen <
> > > [email protected]> ha scritto:
> > >
> > > > Hi All,
> > > >
> > > > In the Python, Java and .Net world I usually create Python classes, jar
> > > > files or DLLs to contain shared functionality.
> > > >
> > > > Because most IBMi shops have an interesting mix of RPG code bases I'm
> > > > trying to determine whether I should create a service program or use
> > > > includes for shared functionality at a customer site.
> > > >
> > > > With service programs, write once, bind and use everywhere.
> > > >
> > > > With copy books, just include on-the-fly.
> > > >
> > > > In the past I've leaned towards copybooks, but I'm curious what others
> > > > think.  I'm a little cautious of burying SQL functionality into one or
> > > more
> > > > service programs.
> > > >
> > > > Real-world thoughts appreciated.
> > > >
> > > > Thanks
> > > >
> > > > Regards,
> > > > Richard Schoen
> > > > Web: http://www.richardschoen.net
> > > > Email: [email protected]<mailto:[email protected]>
> > > >
> > > > --
> > > > This is the RPG programming on IBM i (RPG400-L) mailing list
> > > > To post a message email: [email protected]
> > > > To subscribe, unsubscribe, or change list options,
> > > > visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> > > > or email: [email protected]
> > > > Before posting, please take a moment to review the archives
> > > > at https://archive.midrange.com/rpg400-l.
> > > >
> > > > Please contact [email protected] for any subscription
> > related
> > > > questions.
> > > >
> > > >
> > > --
> > > This is the RPG programming on IBM i (RPG400-L) mailing list
> > > To post a message email: [email protected]
> > > To subscribe, unsubscribe, or change list options,
> > > visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> > > or email: [email protected]
> > > Before posting, please take a moment to review the archives
> > > at https://archive.midrange.com/rpg400-l.
> > >
> > > Please contact [email protected] for any subscription related
> > > questions.
> > >
> > >
> > --
> > This is the RPG programming on IBM i (RPG400-L) mailing list
> > To post a message email: [email protected]
> > To subscribe, unsubscribe, or change list options,
> > visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: [email protected]
> > Before posting, please take a moment to review the archives
> > at https://archive.midrange.com/rpg400-l.
> >
> > Please contact [email protected] for any subscription related
> > questions.
> >
> >
> -- 
> This is the RPG programming on IBM i (RPG400-L) mailing list
> To post a message email: [email protected]
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: [email protected]
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/rpg400-l.
> 
> Please contact [email protected] for any subscription related questions.
-- 
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact [email protected] for any subscription related questions.