RE: ALL I/O in single module was(ARGH!!! (was file open with LR))

[rob@xxxxxxxxx]

Joe,

I think you're method would be effective.  Can the before read trigger be 
done to actually enforce this?  If someone tries to read the file outside 
of the I/O module will the read be denied?  For example, *BEFORE cannot be 
associated with *READ.  Thus wouldn't the application already have the 
data on an *AFTER *READ?  And the best you could hope for is notifying the 
police that someone stole your horse instead of stopping the theft in the 
first place?

I bet this method, however, would make it extremely difficult for anyone 
to use any existing reporting tools, etc.  The problem I have with that 
is, once again, the iSeries will be seen as the culprit and not the 
methodology.  And again the corporate answer will be to either replicate 
all the data, or move the application entirely off of the iSeries, to 
facilitate the reporting tools.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 




"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces+rob=dekko.com@xxxxxxxxxxxx
11/17/2003 11:14 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: ALL I/O in single module was(ARGH!!! (was file open with LR))






> From: rob@xxxxxxxxx
> 
> I agree with validity checking in one place.  However I disagree about
an
> I/O module for it.  The validity checking could be in proper setup of
the
> database.

And I disagree that databases are designed to handle business rules.
You end up writing business logic in trigger programs, which is not what
they were intended to do.


> For instance with constraints and/or triggers then any updates
> done with any tool are checked.  And there is NO leak from someone who
> accessed the file without using the I/O module.

Personally, I've come to embrace the idea of using both.  Since triggers
and referential integrity really amount to writing business logic in
separate places, I prefer to combine all that logic in one I/O module
around each file (or group of related files), and then exclude all
access except through that module.

I only make files accessible as necessary, and for those files I do have
to leave open to the public, I can put a trigger on them.  If the
trigger senses an attempt to access the file OTHER than through the I/O
module, it denies the request.

Simple, clean, and all my business rules are in one piece of code.  This
is the best of both worlds.  This also allows the easy implementation of
things like row-level security and other features that DB2/400 doesn't
support natively.

Joe

_______________________________________________
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.