JARRELLRA@VTCS1.BITNET.UUCP (01/15/87)
I used have problems like that on occasion, especially since we had a
mixed cluster with one node having a seperate dcltable. I just developed
a habit of doing things this way:
Load the kit onto disk with:
@vmsinstal "" "" OPTIONS G
(G= Get (at least that's how I remember it..))
Install it from disk (it's a LOT faster, and if you ever have to do
it again, it's already there. Plus you can prepare weeks ahead
of time by loading it, then installing it at some later date)
Use backup to grab the new cld out of the kit's saveset. (It's
not always in the .a if there are more than one.. )
Manually install the .clds in the other nodes dcltables.
(set command/table=wherever:dcltables.exe -
/out=wherever:dcltables.exe/replace foo.cld)
Go around node to node and use install to
replace sys$library:dcltables.exe
If you find that something moved a dcltable, which is easy to do
by simply using SYS$LIBRARY instead of SYS$SPECIFIC or SYS$COMMON
in the above commands (all references to SYS$LIBRARY for output
might as well be to SYS$SPECIFIC because of the way searchlists work)
You can recover with the following:
Create a "good" one and put it where it belongs.
Use install to explicitly REPLACE with THAT one.
Rename the old one to something else entirely. DONT DELETE IT.
It's open, and while it will dissappear, it will NOT be deleted.
Just unlinked. You'll have to run analyze to delete it in that
case. Send a message out for everyone to log on again if they
want the new table.
Next time you reboot, delete the file.
(if you think you'll forget, you can try what I do sometimes..
add a line in systartup that calls @sys$manager:doitonce.com
This com does a bunch of things for you, and as the last line add:
$create sys$manager:doitonce.com
$exit
It'll create a new blank file on top of itself and never run again
until you edit in new commands.)
-Ron Jarrell
Va Tech Computer Science Department
Jarrellr@vtcs1.bitnet
Jarrellra@vtcs1.cs.vt.edu