On May 14, 2010, at 04:44, Rob van der Heij wrote: > > You may have located the wrong tree to bark upon. Trailing nulls cause > no problems. Since the packed file is F1024 it will be padded with > extra X'00' almost 99.9% of the time. > Nope. It's the right tree; the trailing NULs caused a problem; I'm confident, and I can reproduce it. The original VMFPLCD archive:
listfile foo plcd i (label FILENAME FILETYPE FM FORMAT LRECL RECS BLOCKS DATE TIME LABEL FOO PLCD I1 V 80 229 4 5/14/10 9:32:06 TDISKC Ready; T=0.01/0.01 09:32:17 Extracts OK with VMFPLCD LOAD: VMFPLCD RST ENV= foo PLCD I Ready; T=0.01/0.01 09:32:49 VMFPLCD LOAD * * I Loading ... ... ... I1 ... ... I1 ... ... I1 End-Of-Group OR End-Of-Disk Ready; T=0.01/0.02 09:32:58 Now, I use FBLOCK 80 00 to simulate the corruption by IND$FILE: pipe < foo plcd i | pack | fblock 80 00 | fblock 1024 | unpack | > foo pad i Ready; T=0.01/0.01 09:36:35 There's one more record, which inspection shows to be 32 NULs. The file is otherwise identical. listfile foo pad I (label FILENAME FILETYPE FM FORMAT LRECL RECS BLOCKS DATE TIME LABEL FOO PAD I1 V 80 230 4 5/14/10 9:36:35 TDISKC Ready; T=0.01/0.01 09:36:39 And VMFPLCD LOAD fails on it. VMFPLCD RST ENV= foo pad I Ready; T=0.01/0.01 09:37:26 VMFPLCD LOAD * * I Loading ... ... ... I1 ... ... I1 DMSWPD1459S Number of records for file fn ft different DMSWPD1459S than when dumped Ready(00040); T=0.01/0.01 09:37:39 > More likely the data was translated from EBCDIC to ASCII and back > again in the process. When the record length of a RECFM V file is > misformed in that process, the unpack stage will even recognize. > No evidence of this. The VMFPLCD archive extracted correctly after the superfluous record was deleted. Many sources (example on http://www.vm.ibm.com/download/ ) recommend padding with FBLOCK nn 00. I disapprove: this is more likely to conceal a data error than to repair it. If IND$FILE had reported invalid input data rather than quietly padding the last record, the problem would have been recognized and corrected much sooner. -- gils
