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

I hear you and understand where the comments come from. I can understand the
frustration of old rulz and old design techniques. 
 
Probably it isn't a good idea for me to mention that I find the idea of
unique primary keys to be a solution that has outlived its usefulness? 
 
*ALLOBJ authority has its place. Manipulating production data isn't one of
them. 
 
---------------------------------------------------------
Booth Martin http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: RPG programming on the AS400 / iSeries
Date: 11/17/03 12:15:22
To: RPG programming on the AS400 / iSeries
Subject: RE: ALL I/O in single module was(ARGH!!! (was file open with LR))
 
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