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

[Wim Van den Wyngaert]

I checked all 100 systems I have.

All 6.2 1h3 systems have the problem. Clustered or not.

Standalone systems running 7.3 received directly have the problem. Clusters do not have the problem.

Standalone systems running 7.3 but via upgrade of 7.2 do NOT have the problem.

Standalone systems running 7.2-1 received directly have the problem.

As John Gillings once wrote : backups must be tested. But I'm managed ...

Wim

[Wim Van den Wyngaert]

7.2-1 cluster seem to have the problem to.

Wim

[Wim Van den Wyngaert]

I also checked the back links on all systems like Uwe suggested. None has a problem.

Note also : backup date in the dump.

Wim

[Uwe Zessin]

> Note also : backup date in the dump.

Which means you did not run BACKUP /RECORD

[John Gillings]

Art,

The file header is shared, so there's no way the filename and backlinks can be different.

The correct filename in the header is VMS$COMMON.DIR, and the correct backlink is (4,4,0). Any other combinations is incorrect. It may or may not cause a problem. The directory entry that matches the filename/backlink in the file header is considered the "primary".

The problem stems from the design decision to call the "primary" directory entry VMS$COMMON and all the others SYSCOMMON. Choosing the same for all would have (almost) eliminated the possibility of errors. The other problem is that SYSCOMMON is alphabetically before VMS$COMMON, so in some versions of BACKUP, a restore would change the filename in the header.

Art's problem is new to me. I've never heard of an image backup being restored with no valid directory entries pointing to the file, but back in V6.2, it was fairly common to have an invalid backlink/filename pair (like SYSCOMMON/(4,4,0), or VMS$COMMON/[SYS0]).

DFU can correct the backlinks if they're wrong, but if the directory is "lost", all you can do is recover it to SYSLOST, then RENAME it to [000000]VMS$COMMON.DIR and link in all the SYSCOMMONs.

[Art Wiens]

Any comment on the version of BACKUP.EXE? I checked several other VAX v6.2 systems I have, they are all the same.

It doesn't sound right that a "released" version would have a FT designation.

Art

[Ian Miller.]

I checked VAX/VMS V6.2 systems and they have BACKUP.EXE "T6.2-FT3"

[Stanley F Quayle]

I don't know about aliases, but your CHARON-VAX system probably won't boot. In VMS V7.2, the behavior of BACKUP was changed -- the restore operation will create a disk with a more efficient cluster factor that VMS V6.2 won't understand.

Instead, you have to do this:

$ INIT LDA1:
$ MOUNT/FOR LDA1:
$ BACKUP/NOINIT/IMAGE /SAVE LDA1:

Do a HELP BACKUP /IMAGE for the following text:

Beginning in OpenVMS Version 7.2, when you use the BACKUP/IMAGE command to restore or copy a volume, the BACKUP utility preserves the cluster factor. Note that copying a volume with a bitmap smaller than 255 blocks to a significantly larger disk might result in a bitmap larger than 255 blocks on the destination disk. (You cannot mount such a disk on an OpenVMS Version 7.1 and earlier system.)

[Wim Van den Wyngaert]

I wonder if the bug is still present in higher versions on Alpha and Intel.
Could someone check 7.3-2 and 8.x ?

Wim

[Art Wiens]

Fortunately I'm trying to do an "apples to apples" comparison so I created the same /SIZE LD disk as the original system.

I repaired the broken VMS$COMMON/aliases in the LD disk, FTP'd it over to the blade and it did indeed boot on CHARON late yesterday afternoon!

VAX/VMS at 3.6GHz ... WooHoo!

Cheers,
Art