Rob, RPG? upstart? stay away? that IS funny! on several levels. How does field level security work now, using say, interactive SQL or QRY400? does it exclude the field from the list of available field names? does it hard error out there too, if someone tries to use it without auth? how would I have field level security behave? I hadn't really thought about it, but if the object is to hide and protect a particular field from non-authorized users, maybe a better solution would be have the db return null, blank or zero (you pick) on a read, and not allow update of the field. a message written to the joblog (and/or qsysopr msgq) to inform those who care about such things that access to the field was attempted and denied, giving the user, job, program, line number. I realize that this behaviour would have it's own problems and unintended results, but so would a hard error. If you're brave enough to implement the feature, you should be smart enough to test it as well. maybe I'm being dense here, but we already could "roll our own" field level security by creative use of logical files and library lists. what good is the db2 version if we still have to create the same logicals, etc. so we can use it in strait RPG? rick --- original message --- It depends on how you define traditional. Logical files have been around for a long time. SQL has been around for a long time. And I have a Systems Analyst text book from college that recommended staying away from upstart languages like RPG. How would you have had them handle it? Rob Berendt
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.