[Info-vax] difference in files being copied by scp from Unix to VMS
Sumir
sumirmehta at gmail.com
Mon Apr 27 23:06:06 EDT 2009
On Apr 27, 6:58 pm, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
> Sumir wrote:
> > ------ FILE 1 ------
> > Highest block: 20
> > End of file block: 14
> > End of file byte: 178
> > ------ FILE 2 ------
> > Highest block: 20
> > End of file block: 14
> > End of file byte: 340
>
> The second file has an extra 162 bytes at the end (340 - 178).
>
> The first file has a total of:
>
> 13*512 + 178 bytes (14th partial block) = 6834 bytes
>
> The second file has a total of:
>
> 13*512 + 340 = 6996 bytes.
>
> You may wish to check on the remote machine how big the file is.
> This could provide insight on whether it is the VMS->other transfer
> which adds those extra bytes, or when you move the file back to VMS.
>
> You can also use
>
> DUMP file1/block=(start=14,count=1)
> DUMP file2/block=(start=14,count=1)
>
> And compare. You might see some end of file character in the file2
> followed by nulls. Some file systems might see the CTRL-Z as an end of
> file marker and they won't mind if there is trailing data following it,
> but when the file gets transfered, that end of file semantic may not be
> tranlated.
>
> What I find interesting is that the second file does have an end of file
> byte set, bu it is wrong value. I was epectong that your problem was
> that the file would get created with the 14th block marked as full (last
> byte at 512). But with the end of file byte changing from 178 to 340 is
> puzzling.
Hi,
the dump of the files is as below ---
**** FILE 1 ****
Dump of file BT$$_CURES:[CURES.REPT]CONV_COMP_TRACK.TXT_20090427;1 on
27-APR-2009 22:46:57.86
File ID (2278,3,0) End of file block 14 / Allocated 20
Virtual block number 14 (0000000E), 512 (0200) bytes
2D2D2D2D 2020202D 2D2D2D2D 2D2D2D2D 2D2D2D2D 2020202D 2D2D2D2D
2D2D2D2D --------- ------------- ---- 000000
20202020 20202020 20202020 20202020 20202020 20200A2D 2D2D2D20
20202D2D -- ----. 000020
20202020 20202020 20202020 20202020 20202020 20202020 20202020
20202020 000040
34323430 20202020 20202020 20202020 20202020 20202020 20202020
20202020 0424 000060
41432020 20202030 33363130 36203930 36303430 20202031 30303030
31203930 09 100001 040609 601630 CA 000080
00000000 00000000 00000000 00000A20 0A200A20 0A200A20 4D4F2020
2020204E N OM . . . . ............... 0000A0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0000C0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0000E0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000100
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000120
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000140
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000160
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000180
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0001A0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0001C0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0001E0
**** FILE 2 ****
Dump of file BT$$_CURES:[CURES.REPT]TEMP_COMP_TRACK.TXT_20090424;1 on
27-APR-2009 22:46:22.27
File ID (2275,10,0) End of file block 14 / Allocated 20
Virtual block number 14 (0000000E), 512 (0200) bytes
2D2D2D2D 2020202D 2D2D2D2D 2D2D2D2D 2D2D2D2D 2020202D 2D2D2D2D
2D2D2D2D --------- ------------- ---- 000000
20202020 20202020 20202020 20202020 20202020 20200A2D 2D2D2D20
20202D2D -- ----. 000020
20202020 20202020 20202020 20202020 20202020 20202020 20202020
20202020 000040
34323430 20202020 20202020 20202020 20202020 20202020 20202020
20202020 0424 000060
41432020 20202030 33363130 36203930 36303430 20202031 30303030
31203930 09 100001 040609 601630 CA 000080
00000000 00000000 00000000 00000A20 0A200A20 0A200A20 4D4F2020
2020204E N OM . . . . ............... 0000A0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0000C0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0000E0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000100
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000120
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000140
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000160
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000180
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0001A0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0001C0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0001E0
its kind of confusing to see that both have the same contents in the
last block, but diff shows a difference in both the files.
Also i tried out this transfer on a different set of boxes (vms and
unix), but using the same original file (FILE 1), and it did not fail
there. Both files turned out to be identical. so is it something to do
with the specific unix/vms box.
Unfortunately i donot have access to the machines were this failed, so
i am not able to run it there.
So, is there a way to just ignore this set of nulls in vms. or some
kind of setting in unix to ensure that these are not inserted ?
More information about the Info-vax
mailing list