I suppose it's possible that this is a binary file, and that it was originally
transferred in ASCII mode, so that binary values that happen to match CR/LF got
changed to be just CR.  Then sending it to the 987 and back would be putting the
CR characters back.  It would be quite a coincidence, though, if the ONLY place
that the LF characters appear in a non-text file is in a CR/LF combination.  I'd
expect both values to appear separately as well as (possibly) in combination in
a binary file, in which case FTP wouldn't know where to put the CR characters
when it added them back, and the file would still be corrupted.

Wayne




"Emerson, Tom # El Monte" <[log in to unmask]> on 11/06/2000 04:33:38
PM

Please respond to "Emerson, Tom # El Monte" <[log in to unmask]>

To:   [log in to unmask]
cc:    (bcc: Wayne Brown/Corporate/Altec)

Subject:  Re: [HP3000-L] FTP to UNIX



My response was similar, but the part that REALLY doesn't make sense is a
difference of 67 bytes for a 125 THOUSAND byte file -- somehow I doubt the
file is only 60+ records long...

> -----Original Message-----
> From: Wayne Brown [mailto:[log in to unmask]]
> I'm just guessing, but I suspect that there are 67 lines in
> your file and that a
> carriage return is getting added to each line when it is
> transferred back from
> the 987.  [...]

> Steve Hammond <[log in to unmask]> on 11/06/2000 03:26:25 PM
> [...] The original data file in the Sun system
> has 125,807 bytes, when it comes back from the 987 it has 125,874.
>
> What are those extra 67 bytes and what difference did they make.