I use the subprocedure method and keep those subprocedures in a service
program. That way, all applications use the same procedures for
retrieving, writing, or updating data. It makes it very easy to add
things such as logs and data validation to all programs at one time.
Externalizing your database I/O into a service program is the way to go
IMHO.
As for subroutines vs. subprocedures, I use subprocedures exclusively
(except for *INZSR). I like the benefit of local variables. that way, I
know I am not inadvertently affecting anything in my program unless I
explicitly use a global variable.
Brian May
Project Lead
Management Information Systems
Garan, Incorporated
Starkville, Mississippi
Young i Professionals
http://www.youngiprofessionals.com
Rob,
I like the procedure idea for your database IO. I am wondering if there
is a best use type of policy for using subroutines versus procedures?
Until now, I have always kept my procedures in service programs but I am
also in the process of rewriting some of the "shells" I use as base
routines to copy from. I am wondering since I am in the rewriting
phase, if it would be of benefit to make the subroutines into
procedures.
Sharon
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Monday, January 12, 2009 7:54 AM
To: RPG programming on the IBM i / System i
Subject: Re: e: Good places to use "The Cycle" in today's RPG was->Re:
Niftiestthing(s) you have done in RPG ILE or /FREE
I don't like the priming read of
read file;
dow not %eof(file);
process data;
read file;
enddo;
I like the subprocedure approach:
dow ReadFile();
if B_S;
iter;
EndIf;
// process data
EndDo;
Why I like the subprocedure:
1 - If someone does use iter then you don't get an infinite loop because
you skipped the read.
2 - If you want to add extensive error trapping on your read like:
2a - Some futuristic before read trigger error.
2b - Handling column level security violation.
2c - Some style preference such as converting data instead of raw
data.
2d - future intent to externalize I/O.
Then you can do that in your subprocedure and not uglify your main
body.
Rob Berendt
As an Amazon Associate we earn from qualifying purchases.