VMS 8.3 Backup Command...

[MJ26]

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.

[MJ26]

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

[Duncan Morris]

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

[Hein van den Heuvel]

>> 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        

[Bob Blunt]

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

[Bob Blunt]

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.

[MJ26]

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]000000.DIR;1                                        4  19-SEP-1995 09:55

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

[GuentherF]

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

[MJ26]

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.