/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

[Jon Pinkley]

What was in the first part of the record? That's where I would have expected the original backup command to have been. If it was like what you have displayed, then it certainly doesn't look like a recoverable saveset.

Do you know where the file came from? It is possible this was originally an on disk backup saveset that was marked /nobackup so it wouldn't take up space on normal backups, and then somewhere along the way, someone migrated from one disk to another using backup/image without specifying /ignore=nobackup. Once that happened all chances of recovering the data from the new file are gone.

Is there another copy of the backup saveset another system? It appears to have been created today, and the recordsize is consistent with a file FTPed in binary mode, so can you go to the original system and do a directory/full there? If it is showing up with "File attributes: ... Backups disabled", and you can't get backup/list to work there, then you are out of luck unless you can find a copy on tape that was made before the saveset was marked /nobackup. Or you can find the original disk. Given the filename, it appears this is from quite some time ago.

Summary: To see what you should expect to see from the dump of the backup saveset, create a saveset and dump it.

Example attached

[Steven Schweda]

> If the FIXREC program didn't work, then the
> original backup saveset may not have had a
> blocksize of 32256.

As it says on the Web page cited above, _my_
version if the FIXREC program "reads the file
to determine the BACKUP save set's original
block size."

I don't see anything in my Web server log to
suggest that anyone has downloaded the
program recently, so I'd tend to believe that
the original inquirer has not tried it.
(There was one look at the page from a ".id"
domain, referred from this forum page, but
nothing past the cited page -- nothing
containing the program in any form.)

Show me the output from FIXREC, and I'll
think harder about the problem. Or the
_beginning_ of the DUMP output where the
block size should be, like the "7E00" (32256)
here (DUMP /WORD /RECO):

0000 0000 0000 0001 0001 0001 0800 0100 ................ 000000
0000 0000 0000 0000 0000 0000 0000 0000 ................ 000010
0000 0000 0000 7E00 F5FC 178C 0001 0101 ......üõ.~...... 000020
0000 0000 0000 0000 6361 622E 7069 7A07 .zip.bac........ 000030
[...]

[Hein van den Heuvel]

Jokos.,

Welcome to the HP ITRC Forum.

Your file can 99% certain be fixed as it clearly has the broken file attribute.

You do have to wonder about the system you inheritied. Did this ever work? Did you miss out on some hand over instructions? Is there local support avaiable? Get ready to engage in some (on the job) traiing or consulting or heavy duty manual and help-text reading.

Now go back to that very first reply.
Read it.
Good.

Now read it again and DO IT.
No, noone will do this for you.

So now you read the referenced site.
Read it again and DO IT.

If you have no C compiler, then you can look at a MACRO alternative at this site:
http://www.openvms.org/phorum/read.php?1,4592
Be sure to read the context. Do you recognize the problem and advices?

You would need to figure out where the macro code starts and ends; cut it; paste it into a file called for example FIXSAVSET.MAR; compile it: $MACRO FIXSAVSET; link it: $LINK FIXSAVSET; run it $RUN FIXSAVSET or MCR dev:[dir]FIXSAVSET SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1

Good luck!
Hein van den Heuvel.

[Hein van den Heuvel]

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

Yeah, but the blocksize might not have been specified.
Also I would recommend to suggest DUMP/BLOC=COUNT=1
Makes not difference in this case, as the record size was 512, but if it is 32K...
We just want to see the hex word at byte 40.

Steven,
Reply collision!
I peaked at the site before re-recommending it.
Should have come from xxx.east.verizon.net.

Jokos,
As an alternative to the DUMP, you can use the read-only version of my fixsavset.com as per below.
Cut out; paste into .com file; execute with @.

Hein.


$!---------------------------- read_only_fixsavset.com ----------------
$IF p1.EQS."" THEN INQUIRE p1 "Save set file name ?"
$IF f$search(p1).EQS."" THEN EXIT
$IF F$FILE(p1,"MRS").GT.512 THEN GOTO no_can_do
$OPEN/READ file 'p1
$READ file record
$CLOSE file
$mrs = F$CVSI(40*8,32,record)
$WRITE SYS$OUTPUT "Backup blocksize used was: ",MRS
$EXIT
$no_can_do:
$type sys$input

The record size for the selected file is larger than 512.
This script cannot be used for that file.

$exit

[Jon Pinkley]

Steven Schweda,

I looked at the cited page and stopped reading after the first paragraph of the obsolet section. If I would have continued I would have seen that the improved version automatically determined the original blocksize.

I also downloaded, compiled the FIXREC.C_DECC on AXP and verified it works. Nice tool for this specific problem.

Hein,

Yes I agree that dumping the the first two records probaby isn't required, and with Steven's improved fixrec, it isn't needed. However, I know nothing about what tools Joko has at his disposal, therefore I gave a way to fix things with standard tools available on VMS 5.5-2 (dump,copy),

Joko, even if you don't have a C compiler, Steven's FIXREC.ZIP has ready to run VAX images. You will need a VAX version of unzip.exe

unzip the fixrec.zip file, set def [.fixrec] then

$ mc []fixrec.exe_decc SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1

if it is a valid backup saveset, that should report something like:

SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1
Using BACKUP record size of 32256.
Old record size: 512
New record size: 32256

Then you should be able to use your original backup/list command.

If that doesn't work, then the .bck file has more problems than just the incorrect recordsize.

You seem to be doing well for someone with one week of VMS experience. Keep using the VMS help command. If you don't have hardcopy documentation, you might want to download the .pdf of the VMS User Guide and read it when you aren't busy with other tasks.

Have fun learning VMS,

Jon

[Steven Schweda]

> You will need a VAX version of unzip.exe

Actually, not. Plain executables are also
available in the directory linked to, but a
little more curiosity may be required to find
them, as I provided a link to the directory
instead of providing links to every file in
the directory from the main Web page. (Also
object files, in case a local LINK might be
needed.)

And, of course, binary FTP shouldn't damage
the executables (or the object files) enough
to keep them from working. And if we assume
that the original problem was caused by a
binary FTP transfer to the VAX, it seemed
reasonable to assume that my first response
was (or should have been) adequate. But, if
you don't follow any of the links, you may
not find much. "You can lead a horse to
water, but you can't make him drink."
(Although I like the Dorothy Parker
formulation better.)

[Joko Subuh Sas]

Dear All,

Before Thanks alot for all to Help me,
Im Still from Manager send the Original Files *.BCK, i feel is wrong/something for the files (*.BCK) coz copied used Samba.


Joko Subuh Sas.

[Steven Schweda]

I know what binary FTP will do to a file. I
do not know what Samba will do to a file. I
can't be sure, but the error messages in your
first posting look as if the FIXREC program
may fix the problem.

Did you try the FIXREC program? What did you
do? What happened?

Perhaps you should explain how this file got
to where it is.

[Verne Britton]

You have not mentioned what real problem you are trying to solve ... just curious :-)

Or is reading the saveset with BACKUP/LIST an exercise as you are just learning about VMS ?


Verne

[Volker Halle]

Jokos,

please do not cross-post questions in different forums without telling so.

http://www.openvms.org/phorum/read.php?6,4618

Please provide the full output of the command:

$ DUMP/BL=COUNT=1 RPRSYJUL1991.BCK

Volker.

[Joko Subuh Sas]

Dear Volker, & Alls

Im Sorry, i dont know bout rules this forum, One More Im sorry.

Thanks.

[Joko Subuh Sas]

BDKVXA> DUMP/BL=COUNT=1 RPRSYJUL1991.BCK

Dump of file SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1 on 11-APR-2007 07:51:09.93
File ID (15119,3,0) End of file block 236496 / Allocated 236502

Virtual block number 1 (00000001), 512 (0200) bytes

00000000 00000001 00010001 04000100 ................ 000000
00000000 00000000 00000000 00000000 ................ 000010
00000000 00002000 2544B08D 00010101 .....°D%. ...... 000020
43422E31 3939314C 554A5953 52505210 .RPRSYJUL1991.BC 000030
00000000 00000000 00000000 0000004B K............... 000040

[Hein van den Heuvel]

>> Im Sorry, i dont know bout rules this forum, One More Im sorry.

Not to worry.
It is NOT a forum rule, just common courtesy.
To type in a reply quickly takes a few minutes. If that reply has already been given (and ignored! ;-) in a different place, then that's a waste of time.
So if you cross-post in the hope of hitting a different audience, then be sure to put a pointer to the other places.

Anyway... the posted data show the BLOCKSIZE was 8192.
So now you go try Jon's suggestions again with that value, or try my program.

Also... why the &@#&(! did yo not post the full block dump, or at least attach a .txt file with the full dump after posting the critical first part.

I _know_ this will help
Cheers,
Hein.

[Joko Subuh Sas]

what program u mean? sorry Sir, Im newbie for VMS still Learning bout VMS 2 Weeks. btw r u from germain? im from indonesia :)

[Steven Schweda · Accepted solution]

Once again, slowly:

Download:

http://antinode.org/ftp/fixrec/fixrec.exe_decc

Then:

mcr []fixrec.exe_decc SYS$GENERAL5:[000000]RPRSYJUL1991.BCK

The FIXREC program should report a new record
size, probably 8192, and then the BACKUP
command should work. If not, report back
here exactly what you did, and exactly what
happened when you did it.