Custom Change password program
Hello,
We created custom change password program, which utilizing QSYCHGPW API. How to insure that this program will run insted of system CHGPWD when password expired attribute for a useris *yes.
The new program is called from routing program on subsystem level.
Thanks,
Igor
Software/Hardware used:
Software/Hardware used:
ASKED:
April 10, 2006 5:29 PM
UPDATED:
December 3, 2009 8:35 AM
RELATED QUESTIONS
- Implmenting Custom Password rules on Domino using Security Settings document
- How to change user profile passwords w/out having *SECADM
- Error: A person document for either the request's signer or the 'Name(s) acted upon' was not found in any local trusted directories for which this ser
- Ability to change a users password
- Autmaticly move from as400 sesion to a web search on pc connected to the web
Answer Wiki:
A couple of ideas that you may or may not find suitable:
a) Rename the CHGPWD command to IBMCHGPWD and then create your own command called CHGPWD that calls your own program as its CPP. Put your CHGPWD command in a user library that is part of the *SYSLIBL. If you ever need to run the original CHGPWD you simply use IBMCHGPWD instead.
b) Add a command validation program to the CHGPWD command that calls your own program. I'm not sure whether or not you can "cancel" out of the CHGPWD command after running your own program so that the CHGPWD processing program is not called.
Out of the two I'd go with the first suggestion.
Hope it helps
Jonathan
www.astradyne-uk.com
To see all answers submitted to the Answer Wiki: View Answer History.
Jonatan,
THank you for reply. However this is not exactly what I am looking for.
We have a separate RFINTER subsystem where all handheld devicess will be running. For only those devices I would like custom program to be run. I do not want to affect any other users o the system.
THanks,
Igor
Assuming that there is a unique initial program for hand-held devices, you can put your version of CHGPWD into a library, then use CHGSYSLIBL to put that library ahead of QSYS for that job.
When you start logging on and the profile’s password has expired, you are still in system mode whenCHGPWD is executed. A job has still not been put into QINTER and your initial program has not been called yet so I think doing a CHGSYSLIBL won’t help.
Since when a job starts the values in system value QSYSLIBL are added to the library list for the job, every user will grab the modified CHGPWD command if you put it into one of these libraries.
I think your best bet is to create a validity checking program to attach to the current CHGPWD command and see if you can control the code based on user, etc. I have never done one of these but if you check the online Information Center for your release, it should lead you to an example.
Hi Igor
You could still do it by making the new CHGPWD intelligent enough to know which command/program is to be run based on the device name.
For example, if you renamed CHGPWD to IBMCHGPWD and then created your own CHGPWD command, the new CPP would be something like this:
PGM
DCL &JOB *CHAR 10
/* Identify the device name */
RTVJOBA JOB(&JOB)
/* If it’s a Radio Data Terminal then use the new CHGPWD */
IF COND(%SST(&JOB 1 3) *EQ ‘RDT’) THEN(DO)
CALL new_chgpwd_pgm
ENDDO
ELSE DO
IBMCHPGPWD
ENDDO
ENDPGM
This works on the assumption that your RDT devices have a device name beginning with RDT – you can obviously change that to suit your needs.
In this example all the RDT devices would use your new password change routine, whilst “normal” devices would use the existing IBM supplied CHGPWD command.
Hope it helps
Jonathan
http://www.astradyne-uk.com
There is no need to rename the IBM-supplied CHGPWD command. Nor should you rename it. Leave it alone. Simply qualify it as QSYS/CHGPWD in your program.
That makes it available to IBM programming so those programs won’t error out, not to mention programs that you might write in the future that need QSYS/CHGPGM. It differentiates it from your version. A later upgrade to the OS won’t catch you by surprise by installing a new copy of CHGPWD after it’s been forgotten. And it protects from elements that might eventually be related to the new ‘proxy’ support that could interfere with renaming IBM commands.
Tom