Re: authority issues with a QS36F file

Actually the CRTAUT() for the library, on the CRTLIB and CHGLIB, is more appropriate than the system value QCRTAUT; esp. if *ALL. There seems IMO, a big contradiction in having QCRTAUT=*ALL in combination with QSECURITY=40. Even CRTAUT(*ALL) on any shared library, like QS36F, seems suspect. If every user on the system can delete all of the files created into QS36F using AUT(*LIBCRTAUT), I would think that is generally undesirable on a system seemingly intent on having security implemented; seemingly, as inferred from the security level 40.

Regards, Chuck

Jerry Adams wrote:

I wondered about that, too, Booth. We run exclusively in the 36E and create files out the kazoo. The older sets use BLDFILE; the newer ones use CRTPF or SQL-DDL. Never had a problem with User_A not being able to use a file created by User_B.

I looked at the $FBLD program (BLDFILE), but didn't see anything perverse there.

We're at Level 40; we were at level 30 until about 3-4 years ago.
At Level 10 there is no security, but Level 30 includes object security. Security is not my forte, but you might look at the QCRTAUT system value. It controls *Public access when an object is created (read the Help). Ours is set to *All; someone may have
changed yours to *Exclude or *Use.

Booth Martin wrote:

That is a good question. Especially since this application has been running without trouble since the late 1970s. Recently we went from security level 10 to security level 30, and I suspect
there is the cause of this new behavior.

Willie J. Moore wrote:

Why can't other users use it? <<SNIP>>