Re: user profile question

> 1.   regarding user profiles......who should own them?   The
administrator of
> our company or QSECOFR?

My vote is either for QSECOFR, or a special profile built specifically
for the purpose of owning profiles (and called "#AAA"... more on that
later).  Either way you'll probably have to do a change object
ownership (CHGOBJOWN) command after you create it so that the
ownership is set correctly.

The reasons: As others have mentioned, having a "user" profile own
these objects makes life difficult when that "user" leaves their post.
Another reason is that if you or your group profile has *USE rights to
another profile you can assume that user profile's identity without
knowing their password.

Yet another concern is disaster recovery.  If your name is Romeo Smith
and your profile is RSMITH, and you own all of the user profiles,
you'll have trouble during a full system restore.  You'll be signed on
as QSECOFR when you issue the RSTUSRPRF command and will be restoring
user profiles for Anna Brown (ABROWN) and Dan Bale (DBALE)  before you
restore user profile RSMITH.  OS/400 restore rules state that if an
object is restored to a system and the owner of that object is not
known to the system, then ownership of the object is set to user
profile QDFTOWN.  So after a restore all of the user profiles that
come before "RSMITH" will be owned by QDFTOWN and all of the profiles
that come after "RSMITH" will still be owned by "RSMITH".  Not a big
mess, but still not desireable.

If all profiles are owned by either QSECOFR or by a profile that is
guaranteed to come first in the sort order (#AAA should work), trhen
restoring should not be a problem.


> 2.  QSTRUP - who should own this?  and who is running it at IPL
time - QPGMR or
> QSECOFR?

Ownership of the QSTRUP program is less important than the object
rights (assuming that you hgave not set this program to adopt
authority).  Make sure that QPGMR has *USE rights to the program
because the QSTRUPJD job description specifies that this task will run
under QPGMR's authority.  Also make sure that no one has *OBJEXST or
*ALL authority to this program so that it cannot be deleted and
replaced with another version.

HTH,

jte

--
John Earl - VP & CTO
The Powertech Group
253-872-7788
johnearl@powertechgroup.com
www.powertechgroup.com