Re: authority issues with a QS36F file

[CRPence <CRPbottle@xxxxxxxxx>]

  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>>