We have a profile that the Help Desk uses. Their sign on takes them directly into the program. It prompts for userprofile name, and it both sets a new password and changes status to *ENABLED. Up to the Help Desk to verify they're who they say they are. The program has a table of prohibited user profiles; pretty much all Q*, plus a few local application object owner and interface-only profiles.

You could do something similar, but to make it self service you'd have to authenticate somehow. Maybe a combination of something from their employee record, like employee Id number and SSN, plus a passphrase, security question, or something like that which you'd have to store somewhere.

Use an easy to remember id, like ENABLE password ENABLE. The signon program would call the password reset program, and end with SIGNOFF. Limited capability *YES, of course.  Maybe initial menu *SIGNOFF. The program, btw, has to run with adopted authority of at least a *SECADM, maybe *ALLOBJ depending on who's password needs to be reset (our program is owned by QSECOFR).

I'm not sure I'd allow someone to reset someone else's password.

Another way to go is to train a backup security officer. Or you could put the QSECOFR password in a sealed envelope, in the hands of a trusted person, and they only open it if something comes up while you're away.

Thanks for your input Dale.

We currently have the HelpDesk profile in combination with the sealed envelope thingy but no dedicated program for resetting the password och enabling it, they have to do the whole CHGUSRPRF thing instead.

As you pointed out, there's a lot of extra validations to be done before you allow the end-users to do the job. So I'll settle for a new command just for profile enabling and password changing that the HelpDesk profil can use instead of what's there today. Just to make things simpler for them.

Regards,

Paulster