|
Buck The authority is checked on the "Update" operation. Not at open. If the program monitors for an error (specific CPF message) while doing the update, No problem. If the program does an update and doesn't monitor, You will get an CPF (etc) error message. Antecdote; A company had a program that read in a transaction file and then did some calc's and wrote out another file (Straight Output in the Fspec). When it did the Write, It deleted the Input transaction Record. Well one time a person ran it who didn't have authority to the Output File. The program DIDN'T bomb on the Write statement !, It waited till it wrote a Block of records (remember Straight Output, so blocking occured). Bottom line? Nothing outputed to file, HOWEVER the individual transaction records WERE deleted and were GONE. Neat Huh? (heard that at Sound-Off a few years ago). IBM said "Working as designed" John Carr ------------------------------------- Here's another shining chance to show off my ignorance. I don't use AS/400 security much at my current job. I don't understand how AS/400 security alone can properly handle security without application programming. Let's say that I have an "update customer master" application that allows access to name, address and telephone number. If I want to give a trainee Customer Service Rep "read-only" access to this application (look but don't touch) I can't simply restrict his authority to "read-only", because the program opens the file for update - with restricted authority, the open fails. Don't I really need to make the application "security aware" so that if the user has "read-only" on the customer master file, the application opens a read-only access path, protects the display fields from update, etc? I always thought that OS security had to be built into (or recognised by) the application. Buck Calabro Aptis; Albany, NY +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.