This link from IBM’s knowledgebase may help you:
hi, Mr bmangan,
Thanks for your support, I knw this answer but my question is if DST&QSECOFR both password will be disabled what will be Do. and i dont have the Qsecofr equal rights authority user. at the same time i cant go to os installation way also. pls help any other way is there.
The document from DanTheDane contains instructions to go to this document in your case — Resetting QSECOFR Password Using DST – Version 5.
If you can’t use that procedure, IBM is probably the only direction for you to go.
Create a program to change the QSECOFR password and enable it. Change the owner of the program to be QSECOFR and have the authority to just a couple of users to run it. This way only a known list of users have access to a program which can reset QSECOFR. You can also make a user which will call that program and sign off.
Change the owner of the program to be QSECOFR and have the authority to just a couple of users to run it.
This is a good suggestion for a way to help avoid the problem in the future. But note that it won’t help with the current problem. If no profile exists that has the authority to re-enable QSECOFR, then there is similarly no current profile with the authority to assign ownership of a USER(*OWNER) program to QSECOFR.
But for the current problem, is it clear to kingston that a disabled QSECOFR can always sign on to the system console as long as the password is known? Physical access to the console provides “physical” security. Once signed on at the console with QSECOFR, the CHGUSRPRF command can re-enable QSECOFR.