We have a 'HELPDESK' menu for our developers on which we have menu options
for this purpose.
- One menu option calls a CL program (owned by and adopting QSECOFR
authority) which prompts for the user id and then executes CHGUSRPRF
USRPRF(<UserID>) STATUS(*ENABLE) to enable user profiles which have been
disabled.
_ Another menu option calls a CL program (owned by and adopting QSECOFR
authority) which prompts for the user id and executes CHGUSRPRF
PASSWORD(<UserID>) PWDEXP(*YES) to set the password equal to the user
profile nname and forces the password to be expired, thus requiring a
password change at the next signon.
-sjl
"Rob Berendt" wrote in message
news:OFDC775660.28BA2A5B-ON85257FA7.0049BB23-85257FA7.004AE5D5@xxxxxxxxx...
IBM Secure Identity Manager (ISIM) is a product which may assist with
this. It can be a web based thing where they go to it and respond to a
series of challenge questions and get their password reset.
If the user can run a CL then they should be able to change their
passwords.
Now, if you have some trusted expert users out there you could write a CL
program which would prompt them for a user profile and then run
CHGUSRPRF USRPRF(&USRPRF) PASSWORD(&USRPRF) PWDEXP(*YES)
This would set their password back to their user id and set it to expired
so they would have to change it upon first signon.
It's up to you if you want to modify the program so that if the target
user has certain special authority they can't reset that one.
Then you do a CHGPGM USRPRF(*OWNER)
and CHGOBJOWN OBJ(MYLIB/MYPGM) OBJTYPE(*PGM) NEWOWN(QSECOFR)
But
GRTOBJAUT OBJ(MYLIB/MYPGM) OBJTYPE(*PGM) USER(*PUBLIC) AUT(*EXCLUDE)
and
GRTOBJAUT OBJ(MYLIB/MYPGM) OBJTYPE(*PGM) USER(...) AUT(*USE)
for those trusted users.
You ever use the command CRTCMD? Writing a command is pretty simple to
front that program. Like this one:
RESETU USRPRF(&USRPRF)
Rob Berendt
midrange.com
