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

Question

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.

ble1 · Answer

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

VolkerHalle · Answer

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.

VolkerHalle · Answer

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.

NetWorker

Was this post helpful?