The manner on the S/36 to solve that issue was ported to the
AS/400 as the Authority Holder object type *AUTHLR; see the command
CRTAUTHLR. A deprecated manner to handle the issue [both for the
confusing visibility & potential security exposure], perhaps that is
the /solution/ that was found but deemed undesirable.?
Anyhow the best solution both for maintaining authority and for
performance, is to create the file once, assign its authority, then
change the code [the OCL] to only clear the data from the existing
member before adding new data, rather than delete and re-create the
file. Less desirable but similarly acceptable in case something
like CHKOBJ MBR() capability is desirable [versus open or RTVMBRD],
is to remove the member before adding a new member+data, rather than
delete and re-create the database *FILE object.
Booth Martin wrote:
authority issues with a QS36F file:
I have found a solution, but I do not like it. Probably others
here have a better way.
Each month a file in Q36F is deleted and rebuilt. The file is
owned by whomever last ran the OCL, and no one else can access
it. I have no desire to start a rewrite of the application but
I do have to allow others to use the file.
This mailing list archive is Copyright 1997-2020 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