User profiles that were created for former employees should be immediately disabled upon their departure, or upon notification to you to remove their access to the system. Then, after a bit of research on your part, the user profile should be deleted.

Before a user profile can be deleted, you need to determine what should be done with the objects that the former user owns. It is often the case that a user profile only owns their message queue, in which case you can safely delete the profile and the message queue. But if the user owns other objects, there are some considerations before the profile is deleted. Every object needs an owner. If you want to retain some of the owned objects, you first need to assign the ownership of those objects to a different user.

One part of your pre-delete research needs to be 'Does the user own any programs, service programs or SQL packages?'. You can review the objects owned by the user using the command:

DSPUSRPRF USRPRF(User-Profile-Name) TYPE(*OBJOWN)

If you see any objects of type *PGM, *SRVPGM or *SQLPKG, you need to do a bit of digging before deleting the profile. If any of the owned objects adopt the authority of the owner, you will need to make sure to assign the ownership of the adopting objects to a user profile that has the same private authorities and the same special authorities as the user you need to delete.

For example, lets assume that we are deleting the user profile of a former programmer who happens to own a few production programs. One of these programs adopts the authority of the programmer, who has *JOBCTL special authority. If this program is assigned to a new owner that does not have *JOBCTL authority, there is the potential that the program will abnormally terminate with an error message "Not Authorized to Change Job". This would occur if the program was trying to change a job that is not the current job. Changing another job requires *JOBCTL special authority, which in this case needs to be adopted from the owner of the program.

In order to determine if a program or service program adopts the owner's authority, use the command DSPPGM or DSPSRVPGM. If the "User profile" value is *OWNER, the program is set to use the adopted authority of the owner. If the value is *USER, the object does not adopt authority. If you are changing the owner of an adopting object, you need to make sure that the new owner has at least the same capabilities as the old owner, otherwise, your program may not work.