RE: Externalizing I/O was RPG read loops

Don,

I am currently working on a project that could use the approach you have
mentioned. I was wondering if you would be willing to share some of the
code with me. If you can't, I certainly understand.

TIA.

James


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Fisher, Don
Sent: Wednesday, February 02, 2005 10:54 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Externalizing I/O was RPG read loops

Both.  We're a small shop with only six developers.  I admit to being
the
one pushing this architecture, though.

As I understand it, another benefit is these access programs could
eventually be tweaked to support browser based applications and "green
screen" applications simultaneously.  Tough to do that with triggers. 

Another problem with triggers is recursion.  If I need to update a
related
record in the same file, I'd need to have my trigger program in a *NEW
activation group, which creates a lot of overhead.  Using access
procedures
in service programs eliminates that problem.

As for stopping errant developers, a trigger could be used for that,
though
we don't here. 

Just my current opinion, which, of course, may change later. 

Donald R. Fisher, III
Project Manager
Roomstore Furniture Company
(804) 784-7600 extension 2124
DFisher@xxxxxxxxxxxxx

<clip>
I get my enforcement of business rules with triggers and constraints. 
Stops even the errant developer who updates a file directly with any
utilities.  Again, only one place to maintain the logic.  Don, are you
the
developer of these functions, or only a user?
<clip>
-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.