topic Re: VMS 8.3 Backup Command... in Operating System - OpenVMS

VMS 8.3 Backup Command...

MJ26 — Mon, 27 Jun 2011 19:38:16 GMT

I need some guidence from the Forum here. I have an OpenVMS 8.3 AlphaServer and am trying to "restore" an image of a VAX 6.2 to a local disk. This used to be a common action we did when we were using AXP VMS Version 6.2. Never had any issues restoring a VAX system disk. However when we migrated to 8.3 we could restore files, but when it came to the VAX system disk, when we would take that disk to another VAX it would not boot and stated there was no valid boot block. Upon further investigation, I noticed that the VMS$COMMON directory was not getting restored to the disk. Has anyone seen this before? If so, I'll take any advice at this point. Thanks in advance.

Re: VMS 8.3 Backup Command...

RBrown_1 — Mon, 27 Jun 2011 19:41:24 GMT

Are you using /IMAGE on your backup command line? If not, then try it. If you are using /IMAGE, then show us the command line you are using.

Re: VMS 8.3 Backup Command...

MJ26 — Mon, 27 Jun 2011 20:04:42 GMT

We use a utility named SLS for our backups. The qualifiers that we are passing in are:

$ qualifiers :== /IMAGE/RECORD/IGNORE=INTERLOCK/BLOCK=32256

I am trying to hunt through the log files to see if I can come up with the exact command that is used for the full disk backups.

Re: VMS 8.3 Backup Command...

Duncan Morris — Tue, 28 Jun 2011 08:37:20 GMT

For a restore of such an ancient image you probably need to use the /ALIAS option of BACKUP.

There were a number of changes in backup behaviour in that era!

Use the /ALIAS qualifier only when you are restoring very
        old save sets (from OpenVMS Version 6.2 or earlier). The
        current default behavior is correct in nearly every other
        situation. If you are in doubt about using this qualifier,
        contact your HP support representative.

Duncan

Re: VMS 8.3 Backup Command...

MJ26 — Tue, 28 Jun 2011 13:53:04 GMT

Here is an example output. I only included 1 file out of many.

SYSTST$ mount/for/noassist lma3:
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, VR0001 mounted on _$1$LMA3: (SYSTST)
SYSTST$ mount/for dkb500:
%MOUNT-I-MOUNTED, VAXVMS062 mounted on _$1$DKB500: (SYSTST)
SYSTST$ backup/image/noinit/alias lma3:0022C940624.FUL dkb500:/log

....

%BACKUP-S-CREATED, created DKB500:[SYS0.SYSCOMMON.VUE$LIBRARY.SYSTEM]VUE$NOTEPAD.COM;1

....

After restore was completed:

SYSTST$ dir DKB500:[SYS0.SYSCOMMON.VUE$LIBRARY.SYSTEM]VUE$NOTEPAD.COM;1
%DIRECT-E-OPENIN, error opening DKB500:[SYS0.SYSCOMMON.VUE$LIBRARY.SYSTEM]VUE$NOTEPAD.COM;1 as input
-RMS-E-DNF, directory not found

Re: VMS 8.3 Backup Command...

Duncan Morris — Tue, 28 Jun 2011 14:27:58 GMT

It looks as though the structure of the system root aliases is incorrect.

I see that you are using /NOINIT on the restore, which may not be helping.

There is a good discussion of the VMS$COMMON alias issues in the thread

"Backup /image does not backup VMS$COMMON"

http://h30499.www3.hp.com/t5/System-Management/Backup-image-does-not-backup-VMS-COMMON/m-p/4044140/highlight/true#M18178

Duncan

Re: VMS 8.3 Backup Command...

MJ26 — Tue, 28 Jun 2011 15:13:56 GMT

I'll read through the link you posted. Just passing an "FYI" along, but I am getting the same results with /init or /noinit. So i didn't think the /noinit was causing the issue. Again, thanks for the link and I'll post any results for any testing I do.

Re: VMS 8.3 Backup Command...

MJ26 — Tue, 28 Jun 2011 15:21:55 GMT

SYSTST$ dir/file dkb500:[000000]*common.dir,dkb500:[sys0]*common.dir

Directory DKB500:[000000]

VMS$COMMON.DIR;1 (12,1,0)

Total of 1 file.

Directory DKB500:[SYS0]

SYSCOMMON.DIR;1 (12,1,0)

Total of 1 file.

Grand total of 2 directories, 2 files.

SYSTST$ dump/head/block=count:0 dkb500:[000000]vms$common.dir
%DUMP-E-OPENIN, error opening DKB500:[000000]VMS$COMMON.DIR;1 as input
-RMS-E-FNF, file not found

Re: VMS 8.3 Backup Command...

RBrown_1 — Tue, 28 Jun 2011 20:39:46 GMT

@MJ26 wrote:
SYSTST$ dir/file dkb500:[000000]*common.dir,dkb500:[sys0]*common.dir
Directory DKB500:[000000]
VMS$COMMON.DIR;1 (12,1,0)
Total of 1 file.

SYSTST$ dump/head/block=count:0 dkb500:[000000]vms$common.dir
%DUMP-E-OPENIN, error opening DKB500:[000000]VMS$COMMON.DIR;1 as input
-RMS-E-FNF, file not found

How about DUMP/HEADER/BLOCK=COUNT=0 DKB500:[000000]000000.DIR

After that, I would DUMP DKB500:[000000]INDEXF.SYS/FILE_HEADER/BLOCK=(START=n,COUNT=1), choosing "n" to display the file header for VMS$COMMON.DIR.

Re: VMS 8.3 Backup Command...

GuentherF — Fri, 08 Jul 2011 20:41:18 GMT

I bet it's his old BACKUP bug where BACKUP saved filename SYSCOMMON.DIR in the file header (12,1,1).

The DUMP command does a reverse lookup using the directory back link which - when looking for VMS$COMMON.DIR - finds the filename as SYSCOMMON.DIR. Hence 'no such file'.

If this works:

$ DUMP/BLOCK=COUNT:0/HEADER DKB500:[SYS0]SYSCOMMON.DIR

...and show SYSCOMMON.DIR as the filename in the header then it is this twisted situation.

Here's how to fix it:

$ SET FILE/REMOVE DBK500:[000000]VMS$COMMON.DIR

$ RENAME DBK500:[SYS0]SYSCOMMON.DIR [000000]VMS$COMMON.DIR

$ SET FILE/ENTER=[SYS0]SYSCOMMON.DIR DKB500:[000000]VMS$COMMON.DIR

This is from memory so I hope it works.

/Guenther

Re: VMS 8.3 Backup Command...

MJ26 — Thu, 21 Jul 2011 09:46:22 GMT

Ok, so since my last postings, the disk that I am using has changed locations. But we get the idea here.

MDRCA1$ DUMP/BLOCK=COUNT:0/HEADER DKB600:[SYS0]SYSCOMMON.DIR
%DUMP-E-OPENIN, error opening DKB600:[SYS0]SYSCOMMON.DIR;1 as input
-RMS-E-FNF, file not found
MDRCA1$ DUMP/BLOCK=COUNT:0/HEADER DKB600:[000000]VMS$COMMON.DIR
%DUMP-E-OPENIN, error opening DKB600:[000000]VMS$COMMON.DIR;1 as input
-RMS-E-FNF, file not found

But.....i know during the restore that the following files were created.......

%BACKUP-S-CREATED, created DKB600:[SYS0.SYSCOMMON]CDA$LIBRARY.DIR;1

However after looking at the output, it appears that the restore never creates the SYSCOMMON.DIR directory. So then after the restore is completed, if i run ANALY/DISK/NOREPAIR I get the following messages (along with many more)

%ANALDISK-W-BADDIRENT, invalid file identification in directory entry
[SYS0]SYSCOMMON.DIR;1
-ANALDISK-I-BAD_DIRHEADER, no valid file header for directory
%ANALDISK-W-BADDIRENT, invalid file identification in directory entry
[000000]VMS$COMMON.DIR;1

I have recently installed the latest UPDATE patch hoping this would help, but no luck. I'm open to any suggestions at this point. Thanks everyone for the feedback.

Re: VMS 8.3 Backup Command...

MJ26 — Thu, 21 Jul 2011 09:47:19 GMT

MDRCA1$ DUMP/HEADER/BLOCK=COUNT=0 DKB600:[000000]000000.DIR

Dump of file DKB600:[000000]000000.DIR;1 on 21-JUL-2011 05:47:01.37
File ID (4,4,0) End of file block 4 / Allocated 4

File Header

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (4,4,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Variable
        File organization:                Sequential
        Record attributes:                Non-spanned
        Record size:                      512
        Highest block:                    4
        End of file block:                5
        End of file byte:                 0
        Bucket size:                      0
        Fixed control area size:          0
        Maximum record size:              512
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 Contiguous, Directory,
                                          MoveFile disabled
    Caching attribute:                    Writethrough
    Map area words in use:                2
    Access mode:                          0
    File owner UIC:                       [1,1]
    File protection:                      S:RWED, O:RWED, G:RE, W:E
    Back link file identification:        (4,4,0)
    Journal control flags:                <none specified>
    Active recovery units:                None
    File entry linkcount:                 0
    Highest block written:                4
    Client attributes:                    None

Identification area
    File name:                            000000.DIR;1
    Revision number:                      7
    Creation date:                        19-SEP-1995 09:55:12.97
    Revision date:                        23-FEB-1998 16:02:45.84
    Expiration date:                      <none specified>
    Backup date:                          20-JUL-2011 15:17:49.51

Map area
Retrieval pointers
Count: 4 LBN: 12

Checksum: 29534

Re: VMS 8.3 Backup Command...

Duncan Morris — Thu, 21 Jul 2011 10:06:34 GMT

Although you cannot find the file by name, you should be able to dump the file header by using the file ID.

My example uses $1$DGA132, but you should use DKB600:

du/bl=end:0/head/id=(12,1,0) $1$DGA132:

Dump of file _$1$DGA132:[000000]VMS$COMMON.DIR;1 on 21-JUL-2011 11:03:47.66
File ID (12,1,0) End of file block 6 / Allocated 64

File Header

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (12,1,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Variable
        File organization:                Sequential
        Record attributes:                Non-spanned
        Record size:                      512
        Highest block:                    64
        End of file block:                7
        End of file byte:                 0
        Bucket size:                      0
        Fixed control area size:          0
        Maximum record size:              512
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 Contiguous, Directory, MoveFile disabled
    Caching attribute:                    Writethrough
    Map area words in use:                3
    Access mode:                          0
    File owner UIC:                       [1,1]
    File protection:                      S:RWE, O:RWE, G:RE, W:E
    Back link file identification:        (4,4,0)
    Journal control flags:                <none specified>
    Active recovery units:                None
    File entry linkcount:                 5
    Highest block written:                64
    Client attributes:                    None

Identification area
    File name:                            VMS$COMMON.DIR;1
    Revision number:                      14
    Creation date:                        26-MAY-2009 18:13:19.86
    Revision date:                        23-DEC-2010 10:38:07.77
    Expiration date:                      <none specified>
    Backup date:                          <none specified>

Map area
Retrieval pointers
Count: 64 LBN: 199813952

Checksum: 31298

Re: VMS 8.3 Backup Command...

Hein van den Heuvel — Thu, 21 Jul 2011 12:53:36 GMT

>> SYSTST$ dir/file dkb500:[000000]*common.dir,dkb500:[sys0]*common.dir

Directory DKB500:[000000] VMS$COMMON.DIR;1 (12,1,0)

DIRECTORY/FILE_ID only reads the directory file that holds the requested name entry.

The file ID can be garbage and it would still be displayed without warning/error.

Here, the file id actually looks reasonable (see below)

>> %DUMP-E-OPENIN, error opening DKB500:[000000]VMS$COMMON.DIR;1 as input

>> -RMS-E-FNF, file not found

A directory with any other option (date, size,...), or any attempt to open the file like that DUMP command will actually use the file-id to find the primary file header in indexf.sys.

That's when the file-id might be found to be bad, which typically means the that ID is fine, because that's just an offset into INDEXF.SYS, so likely to be used, but that the SEQuence does not match between INDEXF and the directory entry.

So there are 2 things to check now

1) Out of curiosity... what is the file with ID=12.

Use DUMP/HEAD/ID=xx as described before for that.

2) Where is the real VMS$COMMON.DIR

Use

$ DFU SEARCH/FILE for that.

Or in a pinch, use

$ PIPE DUMP/NUMBER/form=non [000000]INDEXF.SYS | SEARCH SYS$PIPE VMS$COMMON

Below some example commands and outputs.

hth,

Hein

$ dir/file/nohead/wid=file=40/notrail sys$sysdevice:[000000]VMS$COMMON
SYS$SYSDEVICE:[000000]VMS$COMMON.DIR;1    (15,1,0)

$ dir/file/nohead/wid=file=40/notrail sys$sysdevice:[SYS0]SYSCOMMON
SYS$SYSDEVICE:[SYS0]SYSCOMMON.DIR;1       (15,1,0)

$ write sys$output f$fid_to_name("SYS$SYSDEVICE:","(15,1,0)")
DISK$ALPHASYS:[000000]VMS$COMMON.DIR;1

$ PIPE DUMP /HEAD/BLOCK=COUNT=0 /ID=15  sys$sysdevice: | search sys$pipe identification:,name
    File identification:                  (15,1,0)
    Extension file identification:        (0,0,0)
    Back link file identification:        (4,4,0)
    File name:                            VMS$COMMON.DIR;1


$ dfu searc/file=VMS$COMMON.DIR  sys$sysdevice:
:
$1$DGA1:[000000]VMS$COMMON.DIR;1

Re: VMS 8.3 Backup Command...

Bob Blunt — Thu, 21 Jul 2011 20:03:08 GMT

The BACKUP saveset that you're using as the source for this restore? Could you please:

$ BACKUP/LIST=SAVESET.TXT <saveset name>/save ... You can stop listing the saveset after the header information, it shouldn't need to run for long to get that data. We need to see the exact contents of the first TWO blocks, groups or "paragraphs" of data from the listing only. Please post/attach that data for our review as a reply to your thread...

Thanks

bob

Re: VMS 8.3 Backup Command...

Bob Blunt — Thu, 21 Jul 2011 20:05:17 GMT

Forgot to mention... SLS writes standard OpenVMS BACKUP format tapes so they can be read using the standard utility for things like listing the saveset contents.

Re: VMS 8.3 Backup Command...

MJ26 — Fri, 22 Jul 2011 17:55:45 GMT

backup/list lma3:0022D190721.FUL/rewind

Listing of save set(s)

Save set: 0022D190721.FUL

Written by: SLS

UIC: [000001,000020]

Date: 21-JUL-2011 18:49:55.51

Command: BACK/STOR=V2SLS/RELEASE_TAPE/LIST=_MBA4230:/FULL DISK$AXPVMSS

YS:/IMAGE/RECORD/IGNORE=(LABE,INTERLOCK)/BLOCK=32256 _GLP4A1$RDEVA0:0022D190721.

FUL/PROT=(S:RW,O:RW,G:R,W:R)/NOASSI

Operating system: OpenVMS Alpha version V6.2

BACKUP version: V6.2

CPU ID register: 80000000

Node name: _GLP4A1::

Written on: _GLP4A1$RDEVA0:

Block size: 32256

Group size: 10

Buffer count: 242

Image save of volume set

Number of volumes: 1

Volume attributes

Structure level: 2

Label: AXPVMSSYS

Owner:

Owner UIC: [000001,000001]

Creation date: 19-SEP-1995 09:55:12.97

Total blocks: 4110480

Access count: 3

Cluster size: 4

Data check: No Read, No Write

Extension size: 5

File protection: System:RWED, Owner:RWED, Group:RE, World:

Maximum files: 411048

Volume protection: System:RWCD, Owner:RWCD, Group:RWCD, World:RWCD

Windows: 7

[000000]000000.DIR;1 4 19-SEP-1995 09:55

[000000]ADAMTOOL033.DIR;1 8 20-JAN-1998 15:54

Re: VMS 8.3 Backup Command...

GuentherF — Mon, 25 Jul 2011 15:25:41 GMT

All we need to see is the output from:

$ DUMP/HEADER/BLOCK=COUNT:0/ID=12 DKB600:

...as has been suggested in an earlier reply.

Here's what happened with that old long standing bug in BACKUP:

BACKUP/IMAGE save scans the input disk in alphabetical order following the directory tree. So it finds [SYS0]SYSCOMMON.DIR before [000000]VMS$COMMON.DIR. Errouneously BACKUP saved the SYSCOMMON.DIR entry - an alias entry - but marked that it had saved a file with that file ID (12,1,0 typically in those days). When it finally reached VMS$COMMON.DIR it found that a file with this ID had been saved already (assuming THIS is the alias entry) and skips the whole [000000.VMS$COMMON...] branch of the directory tree.

On a restore BACKUP always creates INDEXF.SYS which contains the file headers. It creates SYSCOMMON.DIR at file header index 12 (in older typical saves). But from file attributes stored with the file entry in the save set it restores SYSCOMMON.DIR's directory backlink as (4,4,0) (=000000.DIR) which is wrong. BACKUP/IMAGE restores all directory files as they had been saved in the save set from the original input disk byte-by-byte. So now we get [000000]VMS$COMMON.DIR (12.1.0). Following the back to the file header it contains SYSCOMMON.DIR with a directory backlink of (4.4.0) which would make it [000000]SYSCOMMON.DIR which does not exist. And here is where the boot code would fail to find the the correct directories.

The fix:

First identify that the DUMP command above does indeed list SYSCOMMON.DIR as the filename in file header (12,1,0). If so - as expected - proceed...

$ SET FILE/REMOVE [000000]VMS$COMMON.DIR

$ RENAME [SYS0]SYSCOMMON.DIR [SYS0]VMS$COMMON.DIR ! get that entry set correctly

$ SPAWN ! ... to bypass the per process RMS directory entry cache

$ RENAME [SYS0]VMS$COMMON.DIR [000000]VMS$COMMON.DIR ! place in correct directoy as non-alias

$ SET FILE/ENTER=[SYS0]SYSCOMMON.DIR [000000]VMS$COMMON.DIR ! create the alias entry

/Guenther

Re: VMS 8.3 Backup Command...

MJ26 — Mon, 12 Sep 2011 18:05:18 GMT

I know this may upset a few people, and I really appricate all of the assistance. I was able to figure out a soution to the problem. Basically, the issue yes was in fact an alias problem. Specifically on the 6.2 OS, both AXP and VAX. On the 6.2 (client) system, I modified the SLS parameter of the backup command to also include /image/record/ignore=interlock/block=65534/NOALIAS. Then after the backups run......I can successfully run backup/image...... from the 8.3 system to a local disk, remove that disk and take it to the 6.2 system and boot it back up. So again, thanks everyone for the time and effor to help me troubleshoot. I really appriciate it.