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

Joe

You are probably right on some of your more secure files, (but isn't that 
what you said?).  And granted some data relationships need to be fully 
understood to make sound business decisions.

I think that several of the new tools to replace Query/400 aren't all that 
better.  What they try to do is what programmers should have done with 
good logical files, or views, in the first place.  For example, instead of 
knowing that on hand equals opening balance plus receipts plus adjustments 
minus issues, and the effect of allocated, then a view that figures this 
out should be done.  More in this vein.  Using Reeve's recent SQL dilemma 
(or was that on the midrange-l list?) I even have views set up to do 
pretty much the exact thing he is trying to do.  It's actually a rather 
intense join logical file.  And the number of files joined approaches the 
max.  However, the queries are really easy to set up.

However quoting HIPPA, Sarbanes-Oxley, etc can grind management.  After 
all, most of them remember Y2K and having to spend tons of money for 
something that really didn't help their competitive edge.

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@xxxxxxxxxxxx
11/17/2003 12:46 PM
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 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 haven't tried the READ trigger, that's a fairly new option.  My guess
is that the program is still going to blow up if you send an exception,
so while they may be able to read one record, they're not going to be
able to do anything with it.

But it's still better than unfettered ODBC access, right?  And if it's
REALLY sensitive data, you just don't allow access except through the
I/O module.


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

The concept that all data in the system be available to everybody is
indefensible from a data security standpoint (not to mention a data
management standpoint).  It means that somebody has to understand the
relationships between files, the contents of fields, and how various
business quantities are derived from those fields.

By allowing access at this level, you make security an issue, and you
also lock your database down to where you can no longer make changes to
the underlying database for fear of breaking user queries.

While I understand the utility of such queries, in many cases they can
be made from cached data - mirroring data to an offline server in
nightly batches, for example.

But if you assume corporate requirements to be able to access secure
mission critical data without security, then by definition you're
defeating anything I'm trying to put in place.  If you cannot convince
management that unrestricted data access is inherently insecure (and
unlikely to pass HIPAA regulations) then I guess you have a bigger
problem than system architecture.

But at the very least I would make sure that such access goes through a
user profile that has only READ access.  There is absolutely NO valid
business requirement for users to make ad hoc updates to the database.
And once again, by encapsulating the files within servers, this can be
achieved easily without causing security leaks.

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.