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

[rob@xxxxxxxxx]

Booth,

To truly lock a file you also need to lock it from someone with *ALLOBJ. 
Using data authority on the file to secure it and then assuming that all 
i/o will only be done from an I/O module with adopted authority will not 
slow down certain people from violating data integrity.  And thus you'll 
end up with files with duplicate primary keys and other oddities.  Let me 
explain further.  Providing you only update BPCS item master via their 
5250 maintenance program you will not have duplicate keys.  However there 
is nothing in the file itself stopping you.  Now come's the programmer who 
has *ALLOBJ, (and try to convince management that they don't need it) and 
they update the file with some utility and 'trash' happens.

Granted, given enough authority, the programmer could easily defeat the 
trigger by removing it or disabling it.  But that takes a conscientious 
thought.  At least the trigger might slow them down enough to make them 
ask why.

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




"Booth Martin" <Booth@xxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
11/17/2003 12:19 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
<rpg400-l@xxxxxxxxxxxx>
cc

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






Why wouldn't one use security provisions to deny access to the file
excepting from the module/program/whatever that is defined as the file
handler(s)? So far as the ability to write reports is concerned, one could
decide to allow read access, or one could write an access progam that
provides the fields & rows as appropriate? 
 
So far as the concern that management will just bypass it all by 
replicating
the data, etc... well... it is their data afterall. If thats their 
decision
then probably the files should have been left open in the first place. If
your data integrity decisions are not reflecting management's desires then
you have really dropped your drawers, anyway, haven't you? 
 
---------------------------------------------------------
Booth Martin http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: RPG programming on the AS400 / iSeries
Date: 11/17/03 10:46:54
To: RPG programming on the AS400 / iSeries
Subject: RE: ALL I/O in single module was(ARGH!!! (was file open with LR))
 
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
 
_______________________________________________
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.