Unsolved
This post is more than 5 years old
9 Posts
0
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.
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.
No Events found!



ble1
4 Operator
•
14.3K Posts
0
September 4th, 2009 04:00
VolkerHalle
9 Posts
0
September 8th, 2009 04:00
Still, EMC engineering should be made aware of this.
Volker.
VolkerHalle
9 Posts
0
September 9th, 2009 10:00
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.