Disabled DST password oncomplete system restore

485 pts.
Tags:
Backup
disabled DST password
DST
i515
iSeries backup
iSeries tape drives
Tape Drive
I have posted this question as part of an old discussion but have not seen an answer so please forgive the second posting but I can really use some help on this one. I am doing a complete restore to a I515 backup system which is identical to our main system. After finishing research I have attempted my first shot at a full restore. I obviously did not read enough because I managed to disable the DST user/password at the point I am ready to start the disk configuration. The licensed internal code has been loaded and the disk initialization is complete. I cannot get to the command line and cannot get into DST to reset the password. One screw up I was not prepared for. I am using a twinax console that is the only device besides a tape drive connected. Do I have to restart the whole procedure to recover? Any help?

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    IIRC, these were two systems that were obtained from IBM fairly recently. Isn't there a Support contract for these covering the first six months or more of use? This would be an excellent item to call over. I saw your other posting yesterday, but I don't have explicit information on your current problem. Technically, I have a system where I could replicate the problem... but somehow I haven't quite convinced myself to give it a try. I'm not quite prepared to erase everything and lock myself out! I'm a little surprised that you could disable DST/QSECOFR at this point in a full-system restore. It's not like there's a significant security concern at this stage since there's nothing actually to secure. You have physical access to the QCONSOLE device, and... hmmm... This is a load from another system, right? If so, how are the security profiles set up on the original? Are they allowed to reset their own passwords or did you have that locked down? I'm not asking because I know an answer, but to build a picture of what might be happening. Tom
    125,585 pointsBadges:
    report
  • JaneS
    [...] the original here: Disabled DST password oncomplete system restore AKPC_IDS += "12355,";Popularity: unranked [...]
    0 pointsBadges:
    report
  • JaneS
    Hi Tom. These systems are about 3 years old so the contract is over . I really don't recommend duplicating the situation as I have found it EXTREMELY annoying. I too found it utterly ridiculous that the password/user can be disabled so easily especially since they change to case sensitive at this point and there is as you mentioned nothing to secure. But such is IBM. The profiles cannot be reset except by QSECOFR and one other profile on our main system. Thanks for your input. Much appreciated.
    485 pointsBadges:
    report
  • TomLiotta
    First, starting over is a good option. That is, it should work and it shouldn't be that difficult. The first point to try starting over is back at loading the LIC. Do you know the QSECOFR DST password? The profiles cannot be reset except by QSECOFR and one other profile on our main system. I'm not clear what that means. Only QSECOFR should be able to reset the QSECOFR DST password. Unfortunately, CHGDSTPWD is an i5/OS command and that hasn't been installed yet. The point behind my question was that there are only two reasonable values for the password -- QSECOFR in the case of a default value, and the same password as it exists on the first system. If you don't know the QSECOFR DST password on the original system, then you might need to start over back at the point of creating the full-system save. (And that would be done after resetting QSECOFR back to the default or to a new known value.) Tom
    125,585 pointsBadges:
    report
  • JaneS
    Hi Tom Thanks for the info. Here is a tidbit of knowledge to add to what appears to be an impressive collection. I found out yesterday that our contract with IBM has been renewed so I was able to give them a call. The password was not disabled at that point. It says it's disabled but is NOT. How cute is that? It was I believe reset to the default QSECOFR DST password. When I tried QSECOFR it put me into the change password screen as if it was a first time load. IBM can be clear as mud sometimes. Thanks again for your input. I am back on track.
    485 pointsBadges:
    report
  • Cogit8
    Glad to hear all is going well. I think this is correct ... if you are performing a "system recovery" - i.e scratch installing from another system or the same system (which infers a Manual D IPL) from either a system save tape or the Licensed Internal Code CD I_BASE_01 until you can define an alternate IPL device, then the DST password will always be QSECOFR (uppercase). At this point you have loaded only a small portion of the LIC and any previous settings have not yet been loaded Note that a save storage is recomended to be used only if rebuilding the same system to where the save was performed and with no changes to the hardware.
    175 pointsBadges:
    report
  • TomLiotta
    It was I believe reset to the default QSECOFR DST password. THAT makes (some) sense at least. There are three general groups of "users" who might have the experience to know that detail --
    • IBMers who work in support of system installs/restores,
    • BPs who do it regularly for clients
    • and operations staff for organizations that have many AS/400s (perhaps thousands of the systems) and might go through the sequence often.
    Poor individuals, such as you, who rarely do this kind of work are stuck in a guessing game. But for the future, you're now one of the SMEs (Subject Matter Experts) who might be expected to answer questions from the next one who gets stuck! I would have avoided responding to your question at all except no one else seemed to know much more. Couldn't simply leave you hanging. Glad something is moving for you! Tom
    125,585 pointsBadges:
    report
  • JaneS
    Thanks guys. I realize this is a subject not usually discussed and appreciate ANY effort on your parts if only to not leave me hanging. Sometimes a little brainstorming from several heads can lead to unexpected results. Tom I appeciate the confidence. Thanks again.
    485 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following