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: richard@xxxxxxxxxxxxxxxxx<mailto:richard@xxxxxxxxxxxxxxxxx>
midrange.com
