vmsbackup, new problem but last posting

[Yates, John H.]

The continuing (but last from me) vmsbackup saga: As posted, I can now
get vmsbackup to work, even extracting single files on our sgi (however,
see warning in P.S. note below). So, today I went to try multiple reel
backup sets (the goal, of course) to see what would happen and... you
guessed it! Dead in the water! It must be the attributes of the Backup
because this was all tested between the same two machines.

vmsbackup fails with:

Volume: DUA2
Saveset name: DUA2.BCK   number: 1
 Snark: invalid record type
 record type = 2

on the first volume of a backup/image whose header backup/list is:

Save set:          DUA2.BCK
Written by:        SYSTEM      
UIC:               [000001,000004]
Date:              13-AUG-1990 09:55:03.28
Command:           BACK/IMAGE/REW/INIT/IGNORE=INTERLOCK DUA2: MSA0:DUA2.BCK/SAVE
Operating system:  VAX/VMS version V4.5
BACKUP version:    V4.5
...
Written on:        _MSA0:
Block size:        8192
Group size:        10
Buffer count:      3

Image save of volume set
Number of volumes: 1

Volume attributes
Structure level:   2
Label:             SYS$USER2   
Owner:             SYSTEM      
Owner UIC:         [000001,000004]
Creation date:     21-NOV-1988 14:21:49.69
Total blocks:      1216665
Access count:      3
Cluster size:      3
Data check:        No Read, No Write
Extension size:    5
File protection:   System:RWED, Owner:RWED, Group:RE, World:
Maximum files:     152083
Volume protection: System:RWCD, Owner:RWCD, Group:RWCD, World:RWCD
Windows:           7

[000000]A3V01B.DIR;1                                        1   3-FEB-1989 15:10
[A3V01B]ATOG_CONV.DIR;1                                     1   3-FEB-1989 15:43
...

vmsbackup works just fine on my test case, which for comparison I include
the backup/list heading here:

Save set:          TEX.BCK
Written by:        YATES       
UIC:               [000011,000001]
Date:               7-SEP-1990 13:16:01.73
Command:           BACK/REW/INIT/LOG [JY.TEX]* MSA0:TEX.BCK/SAVE
Operating system:  VAX/VMS version V4.5
BACKUP version:    V4.5
...
Written on:        _MSA0:
Block size:        8192
Group size:        10
Buffer count:      3

[JY.TEX]ARTICLE.DIR;1                                       2  26-FEB-1988 09:48
...

I guess I am more just reporting this than anything. It now really belongs
on a unix programming bb, but I have to abandon it now for other larger
issues as I have spent far too much time fooling with it already. I had
hoped vmsbackup on the sgi would allow us to be totally independent of VAX
tape drives. (i.e. be able to restore a file reliably from old VMS image
backup tapes lying on the shelf). It is now clear that is not the case. It
may work only without the /image switch, but that defeats 99% of my need.
So this is the last from me on this subject.

John
yates at c.chem.upenn.edu

P.S. Even if this does get sorted out, I think VMS Backup save sets will
     always be unexpectedly subject to failure, perhaps only on a file by
     file basis (worst case: whole saveset). VMS Backup is clever enough
     to skip over bad portions of tape, and to recover from it. (the CRC
     check I guess) I discovered this by coping DECUS tapes in the Files-11
     mode (every VMS backup save set is a Files-11 file). Once in a while I
     could not successfully copy the file off and back onto another tape,
     however, using VMS Backup to dump it to disk worked fine, then Backup
     to the fresh tape worked as expected.