v7.3-2 restoring v6.2 system disk image ... breaks aliases

[Art Wiens]

I'm using Alpha VMS v7.3-2 to restore a VAX VMS v6.2 system disk in order to create a "container" that will subsequently be used to test CHARON-VAX. I am restoring it into an LD driver "disk".

I have tried restoring directly from tape to the LD drive, from the same saveset copied to disk to the LD drive and also onto a native vms disk. All three complete "successfully" ... no errors.

However, as noted in a previous thread, VMS$COMMON and it's SYSCOMMON aliases are "broken" - No such file when referenced, but they all have the same FID. And with my last test proved that LD driver has nothing to do with it.

Asking DFU to fix it doesn't, it just moves all the common directories to SYSLOST. I can "fix" it by creating a new VMS$COMMON and creating SYSCOMMON aliases and then moving the subdirectories back.

I did try playing with the /noALIAS switch on the restore(s), seemingly made no diff.

I listed the saveset and the common structure is shown as being backed up under [SYS0.SYSCOMMON...], in fact there is no mention of VMS$COMMON.DIR in the listing.

Is my source v6.2 disk "bad"?
Is my v6.2 version of BACKUP old/bad?
Do I need to use the /noALIAS switch on the backup?
Is it an unsupported action to use VMS v7 to restore a v6 disk with aliases?

Cheers,
Art

[Uwe Zessin · Accepted solution]

> Is my source v6.2 disk "bad"?

From your deskription, it sounds like that is one of the problems. Do a:

$ dump /header /blocks=count=0 disk:[000000]VMS$COMMON.DIR;1

and check the filename *in* the header. If it is SYSCOMMON.DIR;1, there is an easy fix:

$ set default disk:[000000]
$ rename VMS$COMMON.DIR;1 SYSCOMMON.DIR
$ rename SYSCOMMON.DIR;1 VMS$COMMON.DIR

That should put the correct filename into the file header.

But there might be another problem left, so please check the backlink and make sure it points to the MFD ( [000000]000000.DIR;1 ). If that is not the case, you need to move the primary entry to the MFD, e.g.:

$ rename [SYS0]SYSCOMMON.DIR;1 [000000]VMS$COMMON.DIR;1

It's possible that you cannot do that online. Can you boot from a CD-ROM? If I remember correctly, there is a mini-system available, when you boot [SYS2].


>Is my v6.2 version of BACKUP old/bad?
>Do I need to use the /noALIAS switch on the backup?

I thought I have read somewhere that the _workaround_ is to use /ALIAS .xor. /noALIAS (don't know which one) on a restore, but you said you had tried that already?

>Is it an unsupported action to use VMS v7 to restore a v6 disk with aliases?

That was a rethorical question, yes ;-)

[Jim_McKinney]

> Is my v6.2 version of BACKUP old/bad?

Maybe :) During the VMS 6.x timeframe the default behavior of BACKUP vis-a-vis /ALIAS was flip-flopped a couple of times. There were also numerous patches for bugfixes. Lots of folks had issues with restoring system disk images. If you have a 6.2 CD available you may be able to boot from it and restore successfully. (A google search of comp.os.vms for "backup 6.2 restore alias" should reveal the pain that others felt way back when.) Restoring completely from 7.x systems reportedly fails. All seem to have had to enter aliases by hand.

[Ian Miller.]

DFU will fix this after you have restored the image.

[John Gillings]

Art,

Very odd!

It should be OK to restore the V6 saveset with V7. I'm wondering about the exact command used to create the V6 saveset, and the state of the V6 disk (were its backliks correct?). Use BACKUP/LIST to determine the BACKUP command.

Please post the output of the DUMP/HEAD command suggested by Uwe:

$ dump/head/bl=c:0 disk:[000000]VMS$COMMON.DIR;1

I'm most interested in the fields File identification, Back link file identification, and File name

If there is no VMS$COMMON.DIR, then dump the header from any valid SYSCOMMON.DIR directory entry. If there aren't any valid entries, and you know the file ID of the "repaired" file, try:

$ dump/head/bl=c:0/id=fid disk:

(where fid is the first number in the FID triplet).

Worst case, dump the header after repairing the entries into SYSLOST (note that will force the back link to point to SYSLOST).

It may also be interesting to see

$ DIR/FILE disk:[000000]

[Art Wiens]

Multiple salutations:

I'm fairly certain the source disk is fine. I ran DFU against it several months ago, there was indeed a problem at the time (and probably for several years!) and DFU fixed it. I have attached the dumps for [000000]VMS$COMMON.DIR and [000000]000000.DIR ... the backlink pointers look ok. Check the create dates!! I can only take responsibility for the last 3 years ;-)

The version of BACKUP.EXE on this v6.2 system does seem a bit odd:

Image Identification Information
image name: "BACKUP"
image file identification: "T6.2-FT3"
link date/time: 5-DEC-1997 21:41:33.36
linker identification: "05-13"

Field Test?! I guess we're a little tardy on our 8 year old patches! Remember, I "inherited" this stuff.

From v7.3-2:

Trying to do the above dump command on the restored (native VMS) disk gives :

%DUMP-E-OPENIN, error opening DKB405:[000000]VMS$COMMON.DIR;1 as input
-RMS-E-FNF, file not found

Running DFU shows similar:

%DFU-W-OPENERR, Error accesing file DKB405:[000000]VMS$COMMON.DIR;1,
%SYSTEM-W-NOSUCHFILE, no such file

If I run DFU /FIX, it just puts all the subdirectories of the common structure in SYSLOST and I get to fix it by hand. Perhaps I should look into patching BACKUP on my v6.2 ;-)

Hoping very soon to have the "fastest VAX on the planet" ... I was gratiously granted the temporary use of a dual Xeon 3.6Ghz/4GB Blade to prove CHARON-VAX on.

WooHoo,
Art

[Wim Van den Wyngaert]

Just verified my 6.2 1h3 alpha system backup.
VMS$COMMON is not on it either. The syscommon is recorded on sys0. That's all.

Restore not yet tested.

Fwiw

Wim

[Wim Van den Wyngaert]

And in my case the file id and back link have the same values for both files.

The file name for VMS$COMMON is SYSCOMMON.
On my 7.3 alpha, this is not the case. It contains vms$common. 6.2 bug ?

Wim

[Wim Van den Wyngaert]

Check 4.12 in http://mvb.saic.com/disk$vmsdoc0731/000000/731final/6652/6652pro_004.html

It is a known bug.

Wim

[Wim Van den Wyngaert]

And the strange thing ... this cluster started as 6.1 in 1994, not 1.5 (or is that the same ?).

BTW : I inherited this system too.

Wim