/backup/list how to (error)

[Joko Subuh Sas]

Hello alls,

Im have problem in V5.5-2.
bellow this error.
SYS$GENERAL5:[000000]
BDKVXA> BACKUP/LIST SYS$GENERAL5:[000000]RPRSYJUL1991.BCK/SAVE_SET
Listing of save set(s)

%BACKUP-E-READERR, error reading SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1
-BACKUP-E-BLOCKCRC, software block CRC error
%BACKUP-E-INVBLKSIZE, invalid block size in save set
%BACKUP-E-INVRECSIZ, invalid record size in save set
%BACKUP-E-INVRECSIZ, invalid record size in save set
%BACKUP-E-READERR, error reading SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1
-BACKUP-E-HDRCRC, software header CRC error
%BACKUP-E-INVBLKSIZE, invalid block size in save set
%BACKUP-E-INVRECSIZ, invalid record size in save set

i have used Vms 1 Weeks. Still learning bout VMS, anybody can help me to resolve this problem. Thanks before.

Jokos.

[Steven Schweda]

A Google search for the error messages would
return many useful pages, possibly including
this one:

http://antinode.org/dec/sw/fixrec.html

With VMS V5.5-2, you'll need to use the old
("Obsolete") method.

[Jon Pinkley]

Jokos,

Welcome to the forum.

You will definately want ot download and read the VMS FAQ.

This looks like a problem due to copying the
SYS$GENERAL5:[000000]RPRSYJUL1991.BCK file using FTP.

If the output of

$ directory/full SYS$GENERAL5:[000000]RPRSYJUL1991.BCK

Has a line that looks like this

Record format: Fixed length 512 byte records

then the chances are good that it is the result of a binary mode ftp from another system. This can be fixed in several ways.

There is a tool to reset the VMS file attributes on the freeware, but since you are running a very old version of VMS, new versions may not run there.

You need to know what the original backup command was so you can reset the resord size to the correct value.

Use the following command to determine that.

$ dump/record=(start:1,count=2) SYS$GENERAL5:[000000]RPRSYJUL1991.BCK ! dump beginning of saveset.

This should have the original backup command used to create the saveset.

If it specifies a /block=xxxx you will need to use that value. If it was a saveset on disk, and the blocksize was not specified use 32256

Here is how to recover using only standard tools that existed on V5.5-2:

1. create a new saveset with the same blocksize as the original. The contents don't matter.

2. copy the old saveset /over the newly crated one.

Example assuming original blocksize was 32256

$ backup sys$general5:[000000]000000.dir;1 sys$general5:[000000]jokos.bck/block=32256
$ backup sys$general5:[000000]RPRSYJUL1991.BCK sys$general5:[000000]jokos.bck/over
$ backup/list sys$general5:[000000]jokos.bck/save

If there isn't sufficient room on sys$general5: to have two copies of the RPRSYJUL1991.BCK file, you will need to use a tool like DFU or Joe Meadow's file program to change the attributes of the file inplace. I don't believe there were any tools on the standard V5.5-2 distribution that would allow that.

Have fun with VMS,

Jon

[Jon Pinkley]

Joko,

Sorry, my memory was incorrect. You must use copy/over instead of backup/over.

So the example should have been:

Example assuming original blocksize was 32256

$ backup sys$general5:[000000]000000.dir;1 sys$general5:[000000]jokos.bck/block=32256
$ copy sys$general5:[000000]RPRSYJUL1991.BCK sys$general5:[000000]jokos.bck/over
$ backup/list sys$general5:[000000]jokos.bck/save

This is because backup/over just reuses the disk space occupied, but it rewrites the file attributes, where copy/over leaves the file attributes as is. In this case it leaves the record length as 32256 but copied all the blocks from the original file.

If you are goin to be using VMS, you will want to equip yourself with some tools from the freeware, and Hunter Goatley's Fileserver, and other locations.

[Joko Subuh Sas]

Jon & Alls,

Thanks alot for u help me,
i have tried ur solutions but result is same, error and error. i dunno what i can do. maybe tommorow i try again, coz today so tired. one more thanks botha...

cheers.

[Jon Pinkley]

Joko,

If the corrected procedure doesn't work, please provide output of:

$ directory/ful SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1

If it does not show "Record format: Fixed length 512 byte records" then the data has probably been corrupted by a non-binary mode ftp transfer, and fixing that is not trivial, if possible at all.

Do you still have this saveset available on another system where it has not been corrupted by a network copy? If so, there are better ways to transfer backup savesets. Specfically, an up to date copy of zip and unzip will allow you to zip the saveset and preserve the file attributes. You can then ftp the resulting .zip file, and unzip it on the receiving end, where the original file attributes will be restored. Than you can use the backup savset in the same manner as the original.

Jon

[Joko Subuh Sas]

Jon,
This the result:

BDKVXA> directory/ful SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1

Directory SYS$GENERAL5:[000000]

RPRSYJUL1991.BCK;1 File ID: (15119,2,0)
Size: 236496/236502 Owner: [EIS100,OPERATOR]
Created: 8-APR-2007 16:34:51.77
Revised: 8-APR-2007 16:37:47.59 (1)
Expires:
Backup:
File organization: Sequential
File attributes: Allocation: 236502, Extend: 0, Global buffer count: 0
No version limit
Record format: Fixed length 512 byte records
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:R
Access Cntrl List: None

Total of 1 file, 236496/236502 blocks.

[Jon Pinkley]

Joko,

Since I didn't specify, always use binary mode when FTPing .zip files or backup savesets. The only reason to FTP the savesets is if zip isn't availablle, since they will then need to have their recordsize fixed after the FTP transfer, unless both ends of the FTP are using VMS specific extensions like Multinet's "STRU O VMS"

Jon

[Jon Pinkley]

Joko,

It does look like you have a good chance or recoverey. Other than the file being big and thus taking up a lot of temporary space to recover the original file, as long as there aren't other causes of corruption, you should be able to use the procedure with copy/over. If the FIXREC program didn't work, then the original backup saveset may not have had a blocksize of 32256.

Whst does

$ dump/record=(start:1,count:2) SYS$GENERAL5:[000000]RPRSYJUL1991.BCK

display? It should have the original backup command in it. It if does not, then what you have isn't a backup saveset.

Jon

[Joko Subuh Sas]

Jon,

Yes that command work and display, this the result.

Dump of file SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1 on 8-APR-2007 17:50:38.30
File ID (15119,2,0) End of file block 236496 / Allocated 236502

00000000 00000001 00000000 00041C00 ................ 000140
00000000 00000000 00000000 00000000 ................ 000150
00000000 00000000 00000000 00000000 ................ 000160
00000000 00000000 00000000 00000000 ................ 000170
00000000 00000000 00000000 00000000 ................ 000180
00000000 00000000 00000000 00000000 ................ 000190

anyway sorry, my english little bit, and then bout this files can be to read? or corrupt? 1 week im learning bout VMS, and this first problem on VMS :)

Joko Subuh