wow! Am I glad I asked.
Thanks Chuck, Scott, Rob, Jeff, Charles, and MKirkpatrick.

CRPence wrote:
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.

Regards, Chuck

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.

Any ideas?

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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 [javascript protected email address].