[Info-vax] Newbie II: proper dismount

[John Santos]

In article <Xns9C74C9D893500emuslor at 69.16.185.252>, semaj at rols.ten 
says...> 
> Ok, one other question for the helpful souls here...  I have the symbol 
> "BOOT" defined as follows to be able to reboot from a telnet/ssh 
> terminal:
> 
> $ show sym boot
>   BOOT == "RUN /DETACHED /INPUT=SYS$APPS:[TOOLS]BOOT.COM /OUTPUT=NL: SYS
> $SYSTEM:LOGINOUT.EXE"
> 
> And the boot.com script is simply this single line:
> 
> $ type sys$apps:[tools]boot.com
> $ @SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN NO YES LATER YES NONE
> 
> Whenever I reboot my machine that way (or shut it down with the proper 
> argument change for SHUTDOWN and power back on), it comes back up with 
> this:
> 
> %MOUNT-I-MOUNTED, APPS mounted on _AS600$DKA100:
> %MOUNT-I-REBUILD, volume was improperly dismounted; rebuild in progress
> %MOUNT-I-MOUNTED, USER mounted on _AS600$DKA300:
> 
> I assume the improper dismount is the USER volume, since the message 
> comes before the mount message.  If I do the same reboot from the hard 
> console
> 
> $ show sym reboot
>   REBOOT == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN NO YES LATER YES NONE"
> 
> then I do NOT get the message.  Seems like something I read a while back 
> when I first noticed this led me to believe it _could_ just be due to a 
> bug in OpenVMS 8.3, but I'm inclined to think I have something setup 
> wrong.  So, is there a piece I don't have quite right for this to do a 
> clean shutdown?  Perhaps I'm missing something in part of the system 
> shutdown routine that actually does the dismounting?  If someone knows a 
> fix, I'd be glad to have it.

Where does BOOT.COM live?  Is it on USER?  If so, then due to the open
file, SHUTDOWN.COM can't cleanly dismount the disk, so you get the
rebuild message.  Try moving it to the system disk.  I think there is
special stuff in the shutdown code to dismount the system disk after
all processes (including the shutdown process) have been removed.

On the other hand rebuilds are fairly harmless.  This isn't like a
UNIX fsck.  VMS maintains caches of free blocks and free file headers
on each mounted disk.  It marks the free blocks and file headers in
the caches as temporarily in use, to prevent double allocation (which
would otherwise be a problem on a cluster where multiple systems have
write access to the disks.)  All a rebuild does is discover which
supposedly in-use blocks and headers were actually unused but cached
at the time the disk was dismounted, and restore them to the free pools.
(Normally, when a disk is dismounted, all the cached blocks and headers
are released, but because the dismount never completed due to the open
files, this didn't happen on USER...)  So all that's missing is a few
blocks and headers incorrectly marked as in use.  If you are right on
the edge of disk space or free headers, this is usually no big deal.

Also, you can defer the rebuild until after the system has finished
booted, to make it come up quicker.  I mount all my disks with
/norebuild, and submit a batch job to run in 10 minutes with a
$ set volume/rebuild for all my disks.  It doesn't take too long
on a modern fast system with modern fast disks (which are large
and therefore often fewer in number than old disks), but when I
first implemented this on a flaky 11/780, it cut the reboot time
from about 20 minutes to 15.  (Field Service spent a week trying
to figure out what was wrong with a Unibus DV-11...  They would
run some tests, swap some parts, and reboot.  When it came up,
I would run my application and prove it was still broken...  After
a few days of this, saving 5 minutes on each reboot was HUGE!)


> 
> thanks!
> James



-- 
John