[Info-vax] difference in files being copied by scp from Unix to VMS

[JF Mezei]

Sumir wrote:

>  00000000 00000000 00000000 00000A20 0A200A20 0A200A20 4D4F2020 2020204E N     OM . . . . ............... 0000A0
>  00000000 00000000 00000000 00000A20 0A200A20 0A200A20 4D4F2020 2020204E N     OM . . . . ............... 0000A0

The actual data in both files appears identical. So the logical
conclusion is that the applicaion receiving the file ends up specifying
the wrong number of bytes to write for the last block reulting in VMS
including a bunch of nulls inside the file instead of ending it at the
last 0A (line feed).

However, this still leaves a number of possible culprits:

*when VMS sends the file to the remote system, it might tag on those
extra bytes

*when the unix system receives the file, it might tag on those extra bytes

*when the unix system transmits the file back to VMS, it may tag on
those extra bytes

*when VMS receives the file, it might tag on those extra bytes.

Knowing the exact number of bytes that are stored on the unix version of
the file would help narrow down to either the first or last 2
possibilities by comparing it with the exact number of bytes in the
original VMS file.


> 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.

This is normal because the second file is bigger than the first one, so
any data in file2 that is beyond the end of file for file1 will show up
as a difference.


> 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 ?

VMS was told that those extra nulls are part of the file's content.

You would need to write a small program to process the file and find the
logical end of file (the last linefeed in the last block of the file)
and then truncate the file at that point to reset the end of file marker
to the right location.

When accessing that file, VMS has no wait to know that those nulls
shouldn't be there.



Knowing what sort of IO is used by the VMS software (the sending and
receiving programs) might lead to a clue. You'd probably have to call
VMS support to try to extract this from them.  It might be doing raw
block io with SYS$READ and SYS$WRITE, it could be doing RMS record IO
with SYS$GET and SYS$PUT, or it would be doing C io with either
read/write or fgets/fputs, or even character io with fgetc and fputc.