Re: System startup porgram and adopted authority

People often confuse two different options as related. They are not.
User profile . . . . . . . . . . USRPRF
Use adopted authority . . . . . USEADPAUT
These are independent items and need to be treated as such.
Using USRPRF(*OWNER) USEADPAUT(*YES) is setting yourself up for a battle
royale. Either pick
- USRPRF(*OWNER) USEADPAUT(*NO)
or
- USRPRF(*USER) USEADPAUT(*YES)

This is what USEADPAUT does:
Let's say you have an initial program. Let's call it BPCSMENU. On
BPCSMENU you ran two commands:
CHGOBJOWN OBJ(BPCSUSRO/BPCSMENU) OBJTYPE(*PGM) NEWOWN(SSA)
CHGPGM PGM(BPCSUSRO/BPCSMENU) USRPRF(*OWNER) USEADPAUT(*NO)
Then in all the rest of your programs you've ran
CHGPGM PGM(...) USRPRF(*USER) USEADPAUT(*YES)

So now BPCSMENU calls PGM1, which calls PGM2, which calls PGM3.
I do not care less who owns PGM1, PGM2 or PGM3. Since they were all set
to USRPRF(*USER) USEADPAUT(*YES)
USEADPAUT tells it to respect the ownership of the call stack all the way
back to the first program which doesn't say USEAPDAUT(*YES). In our case
this would be BPCSMENU. So therefore all these programs would run under
the authority of SSA. You could lock all your users out of the data files
themselves and they would still be able to run these programs and update
the data. They just wouldn't be able to modify the data outside of the
programs, such as via FTP, ODBC, etc.

Quiz: Now ask yourself this:
If BPCSMENU is set to USRPRF(*OWNER) USEADPAUT(*NO) and owned by SSA,
PGM1 is set to USRPRF(*USER) USEADPAUT(*YES),
PGM2 is set to USRPRF(*OWNER) USEADPAUT(*YES) and is owned by QPGMR, does
it run under the authority of SSA or QPGMR?

So many people just set USRPRF(*OWNER) USEADPAUT(*YES) not knowing what
they are doing. I understand. In Word I still do not understand what the
difference is between "keep with next" and "keep lines together" is.


Rob Berendt