Re: our "not so" dearly departed...

[PaulMmn <PaulMmn@xxxxxxxxxxxxx>]

Rick--

We have a TRMUSR command that does a number of things:  Changes the
user profile to PASSWORD(*NONE) STATUS(*DISABLED), rips the user out
of Office/400 (for the very few still enrolled), removes them from
the System Directory, copies authority for several applications to
backup files and deletes the records from the live applications,
renames their personal library with a "Z" in front of it, then,
finally, deletes the system user profile (choosing the "Give all
objects owned to profile xxxxxxxxxx' option).

We've found that renaming a library-to-be-deleted for at least a
month lets us process through both week- and month-ending, to detect
any links to the soon-to-be-deleted library.  Once through a month
ending without glitches, we save the library to tape, then delete it.
This procedure has saved our rear ends several times!

The part of our routine that copies application authority is another
trick that saves wear and tear on the support desk staff.  We've
cloned the security files for many applications under assumed names.
We read the live security files, looking for records for the user
profile we're deleting.  We copy these records to backup files, while
deleting the records from the live application.  This can only be
done if you understand the application's security system thoroughly!

A matching utility lets us copy authority from the backup files to
the live file, for when we get the request that says, "Make Sam's new
profile just like Sally's (who left 2 weeks ago)."

Another benefit of the remove/restore authority routines is apparent
when a user changes department-- we can rip out application authority
for applications they are no longer supposed to use.  Our routines
are more convenient to use (ie AS/400 commands) than most
applications-- no need to wander through a maze of screens, checking
and unchecking boxes.

--Paul E Musselman
PaulMmn@Ix.netcom.nospam.com



>Before removing user profiles, we have to re-assign object ownerships. I
>assume this is handled through "wrkobjown" and then by changing the objects
>to an owner that has commensurate authorities. Anything to watch out for
>with that process? All of the users will be off the system and no programs
>will be operating.
>
>Deleting objects in their personal libraries...gotta makes sure things like
>jobd's and outq's are not attached to production objects...gotta make sure
>their libraries are not embedded in some other jobd's...anything else?
>
>Thanks for your assistance everyone.
>
>Rick Rayburn