Do API’s ‘QSYRUPWD’ and ‘QSYSUPWD’ work with QSECOFR user profile?
Our password maintenance programs, use API's 'QSYRUPWD' and 'QSYSUPWD'.
They work a traet with standard profiles, but don't seem to work for user profile QSECOFR. (we also have a copy of this profile called WSECOFR and this doesn't work either).
Is there a built-in 'block' on the QSECOFR profile within these API's?
Thanks for any help.
Software/Hardware used:
Software/Hardware used:
ASKED:
March 6, 2008 4:08 PM
UPDATED:
October 16, 2009 4:03 AM
Answer Wiki:
What type of error are you getting? QSECOFR, and WSECOFR, should work fine with the APIs. There is CPD2201 listed in QSYSUPWD as a possible error, but I just made a quick test case using QSECOFR and it ran fine.
Hi, Thanks for testing that out for me. I believe I've spotted my own deliberate mistake. It appears to be a timing issue on the system where the password is changed. My pgm actually puts the old password back, after retrieving the new one. When testing out QSECOFR password changes, it seems that I was actually retrieving the old password, not the new one. I have now added a delay into the 'put the old password back' routine and it now works fine. Thanks again.
To see all answers submitted to the Answer Wiki: View Answer History.
I’d be very interested in knowing what the purpose is. All you need is a program owned by a *SECOFR class user that can set QSECOFR to the default password. Anybody you choose can be authorized to it. You might use it as an initial program to some otherwise unused profile so that the program runs as soon as that profile logs on.
As long as the QSECOFR password can be set to a known value, there should be no problem — unless you’re actively using QSECOFR for some regular production function. And that probably shouldn’t be done.
Tom