03-26-2013 06:26 AM
I have found the solution from an other source:
Title:How to let multiple users be able to ALTER SUPER.SUPER if it is FROZEN or its password has expired
Document Type:Support Information--Knowledge Centered Support
Original owner:NonStop Client Server
FACT:user to be able to manage the system
FACT:have multiple users be able to ALTER SUPER.SUPER
GOAL:How to let multiple users be able to ALTER SUPER.SUPER if it is FROZEN or its password has expired
GOAL:How to have the user to be able to manage the system instead of using SUPER.SUPER all the time
GOAL:How to make sure someone can thaw SUPER.SUPER if SUPER.SUPER becomes frozen
SYMPTOM:SUPER.SUPER password has expired
SYMPTOM:SUPER.SUPER is FROZEN
FIX:Some ways to have multiple users be able to ALTER SUPER.SUPER are: 1) Add aliases of SUPER.SUPER. Aliases can ALTER SUPER.SUPER 2) Create one id, say SEC.GODDESS, and give OWNERship of SUPER.SUPER to that id. 3) A combination of 1 & 2 would allow SEC.GODDESS or any ALIAS of SUPER.SUPER to alter SUPER.SUPER.
FIX:If SUPER.SUPER becomes frozen, there are no aliases available, and a separate userid does not own the SUPER.SUPER record, the SECURITY-ADMINISTRATOR user is authorized to issue a STOP SAFEGUARD command. Once Safeguard is stopped, SUPER.SUPER can log on and thaw himself. SAFECOM;INFO SECURITY-GROUP SECURITY-ADMINISTRATOR == logon as one of the users shown SAFECOM STOP SAFEGUARD == logon as super.super (password only frozen by safeguard) osmp /name $zsmp,nowait,cpu 0, term $zhome/1 == now safeguard is started again SAFECOM THAW USER SUPER.SUPER == now super.super can logon normally
08-29-2013 07:24 PM
Thats a useful recovery method, though usually it is best to setup sec.admin as the owner of super.super to avoid this type of problem happening in the first place (and viceversa).