It does not matter whether you use SQL or native I/O
Put the whole Loop (F-Specs, (open) SETLL, LOOP READ, READE (close)) in a (exported) procedure.
Within this procedure in the loop you can call other procedures.
If you have the same loop, but do different things, you may write different procedures.
Or you write a single procedure and pass either a label which tells you which procedures to call or if the parameters are identical pass the procedure pointer for the procedures to be called
(I prefer this "Label" solution)
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)
-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Richard Schoen
Sent: Sunday, 22 March 2026 17:02
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: RPG Service Program vs Include Source for Shared Subprocedures and SQL Calls
I know we're all moving towards SQL, but in the odd scenario you want to modularize record level access, would you write a subprocedure and have it open the file, do the read/write/update and then close the file as part of its process.
Or open the file in main program but just do the chain, read, write, update in the subprocedure.
Just trying to think of those scenarios where I want to modularize standard record level IO as well. Or is that over kill 😊
Regards,
Richard Schoen
Web:
http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
------------------------------
message: 2
date: Sun, 22 Mar 2026 11:08:48 +0100
from: "Birgitta Hauser" <Hauser@xxxxxxxxxxxxxxx>
subject: c
Subprocedures and SQL Calls
-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.
You have to learn to think differently (not in "Programs") but in "reusable code".
CRUD Functions are good candidates for (exported) sub-procedures. Finally you should have only a single procedure on your system which will write a new record to a file and a single one which will do the update and a single one which will do the delete.
Within these function you may call other functions, for examples for to check or set default values or check dependencies between two columns (in for a INSERT or UPDATE Statement) and to check if there are dependent rows for deletes (sure it would be better if the tables would be secured with Check Constraints, Referential Integrities and Triggers ... but most databases/tables are NOT).
... and if you want to do an update from outside, just wrap the function as a Web Service.
Instead of returning RESULT SETS, I'd suggest to write a procedure that defines the Cursor and loops through the cursor ... and calls from there additional procedures.
Mit freundlichen Gr??en / Best regards
Birgitta Hauser
Modernization ? Education ? Consulting on IBM i Database and Software Architect IBM Champion since 2020
--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
midrange.com
