×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
GKern@xxxxxxxxxxxxxxxx wrote:
"Any user that has *USE access to these files and attempts to use an
existing program that opens one of these files with update, that program
will error out with invalid authority."
I need to avoid that (obviously).
"If any of these programs have adopted authority, bang goes you security."
I just tested using read only access, but adopted authority 'broke' that
theory. The next test was to issue OVRDBF to specify *INHWRT = YES and
that did seem to work. Since there will be less than 100 objects in the
Purge library, it might be practical to issue OVRDBF *INHWRT = YES
whenever they add the purge library to their library list (and then delete
the overrides when the remove the purge library). I'm not sure about SQL
updates... but we only have a few programs that do SQL updates and those
could be included in the purge library and compiled with commit = Yes to
prevent them from doing their updates.
Jerry:
The combination of requirements makes it tricky. You don't want to
change any programs, but you don't want authority errors interfering
with how things run. The *INHWRT gives the appearance of working, so
no program changes are needed -- but that doesn't relieve the actual
authority problem because the ability to update the files exists
whenever the override isn't in effect.
And you want the override in effect _only_ when the library target
is PURGELIB (or whatever its name is). When any other library is
being accessed, the override for those files should _not_ be in effect.
Two elements seem reasonable:
1. Control access to the *library* at the very least. Allow access
only through an option that sets overrides at entry and removes them
on exit. The option would also adopt authority for the library.
I have no idea what your application structure is nor what access is
granted to command-lines, <Attention> programs, etc.; but without
some general authority restriction, there seems no hope.
2. Also consider creating a journal just for the files in that
library and creating at least a generic trigger program for the
files. In the event that some update does happen, the journal can be
used to set everything back. If no updates happen, then there'll be
minimal impact, neither for performance nor space. No harm, no foul.
But if a change does get executed through some
unexpected/unprotected means, a generic trigger could send a signal
to a responsible administrator (or many of them). Send a message,
send an e-mail, send notices that changes need attention to be
backed out. You could also send (break?) messages out to the
workstation if it's interactive, saying "You're updating our
history! Stop it! Don't change the past."
A journal for recovery and trigger monitoring would both be useful
for *ALLOBJ or other accidents.
Tom Liotta
As an Amazon Associate we earn from qualifying purchases.