Unsolved

This post is more than 5 years old

505

August 25th, 2009 09:00

OpenVMS Networker Client V7.3.4 and data missing after EOF byte on restore

When testing nsrrecover on OpenVMS Alpha V7.3-2 with Networker Client V7.3.4, I recognized, that BACKUP/COMPARE reported %BACKUP-E-VERIFYERR for the last block of sequential files whereas DIFFERENCES reported no differences found for those files.

Further analysis has shown, that networker does not seem to save or restore possible data bytes following the EOF byte in the last block (EOF block) of sequential files.

This may not be a problem for 'well-behaved' applications, which do not read past the EOF byte, but could cause problems with restored files, if an application is using QIOs and is reading past the EOF byte.

$ DUMP/HEADER produces the following output of the original file:
...
End of file block: 1 <<<
End of file byte: 86 <<<
...
Virtual block number 1 (00000001), 512 (0200) bytes

3034344B 53494452 45535522 3C3C001B ..<<"USERDISK440 000000
0036003E 3E225D30 30303030 305B3A30 0:[000000]">>.6. 000010
2A202A3B 4244522E 2A203A6C 6C756E2B +null: *.RDB;* * 000020
2A202A3B 4A49412E 2A202A3B 504E532E .SNP;* *.AIJ;* * 000030
2A202A3B 4144522E 2A202A3B 4A55522E .RUJ;* *.RDA;* * 000040
00000000 00000000 FFFF2A3B 504D442E .DMP;*.......... 000050

After restoring this file from a networker backup, DUMP/HEADER shows this:

End of file block: 1
End of file byte: 86
...
Virtual block number 1 (00000001), 512 (0200) bytes

3034344B 53494452 45535522 3C3C001B ..<<"USERDISK440 000000
0036003E 3E225D30 30303030 305B3A30 0:[000000]">>.6. 000010
2A202A3B 4244522E 2A203A6C 6C756E2B +null: *.RDB;* * 000020
2A202A3B 4A49412E 2A202A3B 504E532E .SNP;* *.AIJ;* * 000030
2A202A3B 4144522E 2A202A3B 4A55522E .RUJ;* *.RDA;* * 000040
00000000 00000000 00002A3B 504D442E .DMP;*.......... 000050


Note that the 'FFFF' at offset 0x56 had been replaced with '0000' after restoring this file from the networker backup. OpenVMS BACKUP utility correctly preserves the data after the EOF byte.

Volker.

4 Operator

 • 

14.3K Posts

September 4th, 2009 04:00

You should open this with support thus that it gets to engineering.

September 8th, 2009 04:00

Interestingly, ZIP/UNZIP shows the same behaviour. So this may be caused the the way those non-native OpenVMS utilites access files.

Still, EMC engineering should be made aware of this.

Volker.

September 9th, 2009 10:00

After discussing the ZIP/UNZIP variant of this problem in comp.os.vms

http://groups.google.de/group/comp.os.vms/browse_frm/thread/587fd77b7aed948e?hl=de#

it became clear, that ZIP 2.32 has acknowledged and solved this problem back in June 2006.

Volker.
No Events found!

Top