From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Problem in system recovery after fatal failure of VAX3800, help!
Date: 30 Dec 1992 11:36:56 GMT
Organization: HST Wide Field/Planetary Camera
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Dec29.205455.23119@proton.llumc.edu>, lin@primus.llumc.edu (P. James Lin) writes:
>
>I confront a problem after a fatal fault of a VAX3800 ( power supply failed).
>The whole backplane unit has been replaced. When I try to boot the system,
>the audit server is started, all other third party softwares' license
>are successfully load, the last message on the console shows the VAX-VMS 
>license has been successfully loaded, and then the system hangs forever. 
>No activity is found in the disk i/o. 
>But I can boot the system into single user mode or "mini" mode.
>
>Problem 1: What is the next step which hangs the system?

Well, we don't know that.  *YET*.  Back in the days of 780s, your next step
would be obvious (given that you'd rooted around in the HELP file on the
console floppy;  everybody involved in this newsgroup would have the right
mindset to've done that, right?).  These days, DEC doesn't tell you as much
(they're trying to emulate the brain-dead documentation that comes with IBM
PC's, I suppose).  Anyway, the answer is:
	>>>BOOT/R5:1
	SYSBOOT> SET STARTUP_P2 "TRUE"
	SYSBOOT> CONTINUE
Make sure you've got *LOTS* of paper in your system console.  (You don't have a
hard-copy console?  Shame on you!  I know, DEC doesn't tell you that having a
hard-copy console is a MUST, but it really is, if ever your system starts to
have problems.  The list of loaded images you'll get in some system crashes
will inevitibly overflow the screen of a CRT).  Anyway, setting STARTUP_P2 to
"TRUE" turns on verification during the boot procedure.  This means that every
command the system tries to execute in the Startup process is echoed on the
console before it's executed.  The last command you see on the console is the
one that hangs the VAX (usually;  there's always the dreaded possibility that
something some detached process does hangs the processor;  let's hope that's
*NOT* your problem).

>I suspect the license database was corrupted during the power supply failure,
>so I rename the LMF$LICENSE.LDB to another name and them try to boot the 
>system, the message shows the license management facility is not started,
>login is allowed in OPA0. Then I rename the LMF$LICENSE.LDB back to the
>original name. After this step, I can not get the license management facility
>to be started any more. It always goes to the single user mode no matter how
>I specify the boot flag.

Well, single-user mode is invoked anytime the SYSGEN parameter STARTUP_P1 is
set to "MINI."  One of he first things VMS does in an interactive boot (i.e.,
when you B/R5:1 or B/1) is to copy any SYSGEN parameters you modified in
SYSBOOT to your disk.  That means that once you've:
	SYSBOOT> SET STARTUP_P1 "MINI"
you're going to have a minimum system boot until you do another interactive
bood and:
	SYSBOOT> SET STARTUP_P1 DEFAULT
Or, you *COULD*, after a minimum boot (by the way, under VMS it's called a
"Minimum Boot," *NOT* "single-user-mode."  The latter is a UNIXism):
	$ MCR SYSGEN
	SYSGEN>USE CURRENT
	SYSGEN>SET STARTUP_P1 DEFAULT
	SYSGEN>EXIT
	$ @SYS$SYSTEM:SHUTDOWN 0 1 0 1 0 1 NONE
to arrange for a normal boot.

>Problem 2: What's wrong? Does re-installing the auth-pak be the only solution
>	   to recover to the previous state? 

Time for a micro-flame here:  You don't know what's wrong (otherwise, why did
you post the question?).  Just because having a license loaded was the last
thing that *WORKED*, there's no reason to suppose that that's what's causing
the problem.  Your *FIRST* step should be to figure out what the problem is, by
using STARTUP_P2 to force verification during the boot process.

Fortunately, before going off into your uninformed (I mean that literally, not
pejoratively) speculations as to the problem, you gave enough information about
the problem that a course of action could be recommended.

--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.