Re: authority issues with a QS36F file

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?