RE: CHGDSTPWD function

["Urbanek, Marty" <Marty_Urbanek@xxxxxxxxxxxx>]

When this happened to me after I first installed V5R1, I called IBM Support
Line and was given the correct information immediately by the first person I
talked to. I was, needless to say, very relieved.

-Marty

--__--__--

From: Jeff Bull <Jeff.Bull@itm-group.co.uk>
To: "Midrange-L (E-mail)" <midrange-l@midrange.com>
Subject: CHGDSTPWD function
Date: Fri, 26 Jul 2002 13:59:20 +0100
Reply-To: midrange-l@midrange.com

Hi all,
        a few weeks ago I was told that if the DST  QSECOFR profile is
disabled, and that there were no other DST profiles with DST profile
administration rights, that a slip install of the os was the only way to
recover access to DST QSECOFR - and I specifically recall reading an article
on the subject written by someone in IBM Rochester.

        THIS IS NOT CORRECT, well certainly not at v5r1.

        I have a client who has just got himself into this particular
predicament.  The CHGDSTPWD  PASSWORD(*DEFAULT) command not only resets the
password back to the default, but also re-enables it; a slip install of the
os is NOT required.

        I have just confirmed this by forcing the DST menu to the console
(panel, B-manual, function 21), gone to the DST profiles menu and
intentionally disabled QSECOFR (I have my own DST administrator profile); I
then ran CHGDSTPWD and refreshed the DST profiles screen, sure enough the
profile had been re-enabled.

        How can this bad information get about ? I hope none of you people
have suffered a slip-install unnecessarily.

Kind Regards,

Jeffrey E. Bull
Software Support Consultant
IBM Certified AS/400 System Administrator