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

The rule is simple: if you have the same code in two programs, then it's
better to have one function in a service program. With the exception of
database I/O functions.

Personally, I'm against externalizing I/O in service programs for two main
reasons:
- Managing shared COMMIT between multiple programs or service programs can
be a nightmare and limit or affect the way you write service programs. It
usually forces you to write two service programs, one for non-I/O functions
and one for I/O functions.
- The same thing but with triggers added is simply unmanageable. And even
if it could be managed, it exposes you to unpredictable runtime errors.

Best regards
--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco


Il giorno sab 21 mar 2026 alle ore 15:40 Richard Schoen <
[email protected]> ha scritto:

> Thanks for all the input.
>
> Service Programs seem to make sense.
>
> You’ll have to forgive my relative ignorance on this specific topic.
>
> RPG hasn’t been a primary use language for me in several years so I’m
> trying to use all the modern goodness.
>
> Now the question is what types of things do you put in your sub procedures
> and service programs ?  In other languages I usually create re-usable
> functions for things such as:
> string handling, file handling, inserting, querying recordsets, updating
> or deleting records and other small units of work. I guess that’s how I’ve
> used sub procedures in RPG before as well to date but have used includes
> mainly.
>
> What about core recordset processing ? Should that specialized logic stay
> in each individual program or in a sub procedure.
>
> Ex: Create cursor and open it in a sub procedure.  Then iterate in the
> mainline.  Then call a sub procedure to close the cursor.  Seems a bit
> overkill. But maybe not if you want to encapsulate all your DB access logic
> into a single service program for Open, Query, Iterate Next Row, Insert,
> Update, Delete and Close Cursor.
>
> I suppose it really depends on how many places that logic will be re-used.
>
> There are two examples I can thing of where I might not want to
> encapsulate logic into a service program.
>
> -When I am processing table a record at a time using record level IO it
> may not seem to make sense because the open file is in the main module. Or
> do the service program modules see the open file pointers as well ?  In
> other words does the file open file cross program and procedure boundaries
> and make it accessible on the inner sub procedure calls ? When a subproc is
> embedded in an RPG program I believe it can still see the record level
> opens that are program scoped. Is that the same with service programs ?  I
> guess the summary here is would record level access be appropriate in a
> service program for chain, read, update, delete.
>
> -Recordset processing with SQL. I can definitely see putting INSERT,
> UPDATE and DELETE logic in a sub procedure and a DB access service program
> perhaps, but what about queries that select resulting recordsets. Can I run
> an SQL from a sub procedure and return the resultset or cursor to the main
> program like I would in other languages ?  I’m guessing I can but most of
> my embedded SQL has been in single mainline programs and not buried in sub
> procedures thus far. Also does a named cursor open survive across calls ?
> I’m starting to visualize it does because you have the CLOSQLSR parm on
> CRTSQLRPGI which can tell you when to close the cursor.
>
> As with all things software development I’m sure you all have your own
> patterns that you use.  I’m just trying to establish my new ILE  pattern
> thought process since some current projects require a bunch of new RPG
> coding which will include embedded SQL.
>
> Hope this makes sense :-)
>
> 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.