RE: RPG Service Program vs Include Source for Shared Subprocedures and SQL Calls
Richard Schoen <richard-DiTrGpQEJGItADg8e/3/[email protected]> Sun, 22 Mar 2026 15:23:40 +0000
| Newsgroups | gmane.comp.lang.as400.rpg |
|---|---|
| Message-ID | <[email protected]> |
Sound advice. Thanks you. Regards, Richard Schoen Web: http://www.richardschoen.net Email: richard-DiTrGpQEJGItADg8e/3/[email protected] ---------------------------------------------------------------------- message: 1 date: Sat, 21 Mar 2026 18:05:55 +0100 from: "Birgitta Hauser" <Hauser-bRAHsVz2yv4TVIZRl6KS/[email protected]> subject: RE: RPG Service Program vs Include Source for Shared Subprocedures and SQL Calls Service Programs are the way to go! I use them intensively since around 20 years without any problems. Currently I have more than 120 service programs and within these service programs around 8000 exported procedures. For our service programs we used a few rules: 1. There are almost no internal procedures. Exported procedures must be encapsulated, i.e. parameter in, parameter out and only local variables. 2. One source = one object (program or service program) 3. New procedures must be added at the end of the source Based on these rules I wrote a small compile command which will automatically generate the binder language, the module, bind the module in the service program, add the service program to the binding directory, delete the module. In this way generating a service program is as simple as compiling a program. Due to this compile command everybody in my team could add new procedures to service programs and compile them without any problems. The first version of this compile command was generated in the early 2000s. Until now I have rewritten at least 4 different versions of these commands running on multiple customer machines. ... and we have almost no problems with generating and compiling. Just in case a service program cannot be bound because a function in another service program is not available (and vice versa). We generate the service programs twice, first time with OPTION(*UNRSLVREF) so the procedures are not resolved. And the second time with OPTION(*RSLVREF) = Default, so the procedures are resolved. ... and I worked with both, i.e. Generated signatures and fixed signatures (and had no problems with none of them). ... and embedded SQL never caused any problems (and I use it intensively) Mit freundlichen Gr??en / Best regards Birgitta Hauser Modernization ? Education ? Consulting on IBM i Database and Software Architect IBM Champion since 2020 "Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown) "If you think education is expensive, try ignorance." (Derek Bok) "What is worse than training your staff and losing them? Not training them and keeping them!" "Train people well enough so they can leave, treat them well enough so they don't want to. " (Richard Branson) "Learning is experience ? everything else is only information!" (Albert Einstein) -- 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: RPG400-L-request-+hD5IHI5Xscn3HwCXmMcX9BPR1lH4CV8@public.gmane.org Before posting, please take a moment to review the archives at https://archive.midrange.com/rpg400-l. Please contact support-FMtJrHiV//lnDLsaKlm4mFaTQe2KTcn/@public.gmane.org for any subscription related questions.