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:25:30 +0000
| Newsgroups | gmane.comp.lang.as400.rpg |
|---|---|
| Message-ID | <[email protected]> |
Good thoughts, My globals questions was more of a thought. I always think of a procedure as running relatively self-contained. Thanks Regards, Richard Schoen Web: http://www.richardschoen.net Email: richard-DiTrGpQEJGItADg8e/3/[email protected] ------------------------------ message: 2 date: Sat, 21 Mar 2026 19:02:28 -0400 from: Buck Calabro <[email protected]> subject: Re: RPG Service Program vs Include Source for Shared Subprocedures and SQL Calls Richard said: 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 ? Yes! You can do it as a result set with ASSOCIATE RESULT SET LOCATORS but it's sometimes convenient to use a callback; have the service program do the actual access and have the caller 'do something' with the records. Why a service program? Because you can do things like set the authority on the table/view to public(*EXCLUDE) and then have the service program apply whatever programmatic access, auditing, notifications the business wants. For example, Accounting can get an account balance but not the employee birth dates. What sort of 'do something?' Imagine that you want to give an identical result set to a DDS subfile, a JSON export for a web service, and an Excel file. With a callback, the three different UIs each present the data as needed, and none of them need to know anything about the actual structure of the database - the service program uses SQL, F-specs, or a combination to aggregate and return the data... Also does a named cursor open survive across calls ? It can, depending on activation group and cursor scope, but the caller needs to track state and signal when it's done with the I/O. That's kind of close coupling, but they pay us to make these decisions :-) --buck ------------------------------ message: 3 date: Sat, 21 Mar 2026 19:05:34 -0400 from: Buck Calabro <[email protected]> subject: Re: RPG Service Program vs Include Source for Shared Subprocedures and SQL Calls Richard said: So are you saying when you make a sub procedure call to a service program you can?t see globals from the main program ? You can, with EXPORT and IMPORT but oh please don't. On Sat, 21 Mar 2026 at 11:10, Marco Facchinetti <marco.facchinetti-kthxv0ud/[email protected]> wrote: My English has probably failed me again. The functions that access the main program's global variables are those in the copied members, not those residing in the service programs. Best regards -- Marco Facchinetti Mr S.r.l. Tel. 035 962885 Cel. 393 9620498 Skype: facchinettimarco -- 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.