Do API’s ‘QSYRUPWD’ and ‘QSYSUPWD’ work with QSECOFR user profile?
20 pts.
0
Q:
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.
ASKED: Mar 6 2008  4:08 PM GMT
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
0
20 pts.
0
A:
 RATE THIS ANSWER
0
Click to Vote:
  •   0
  •  0
  • AddThis Social Bookmark Button
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.
Last Answered: Mar 11 2008  10:02 AM GMT by Rpm   20 pts.
Latest Contributors: Bvining   4885 pts.
0
0
Discuss This Answer:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

TomLiotta   7590 pts.  |   Oct 16 2009  4:03AM GMT

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

 
0