|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.