Dave,
Check the attributes of the file(s). My guess is your original file (the one getting errors) has an invalid "Longest Record Length" - LRL. It could 0, or at least less than the actual LRL. The FTP client is therefore working with false information, which breaks assumptions.
When you send the file to another node, RMS is creating the remote file. Since it sees all the records, it knows the real LRL and sets it correctly in the new copy. Now that FTP has correct information, the transfer is successful.
If you know the correct LRL, you can set it with:
$ SET FILE/ATTRIBUTE=(LRL:value) file
or create a new file with:
CONVERT old-file new-file
This should ensure the LRL is correct.
One other possibility (unlikely since I'm guessing the file is effectively human readable text), it's a stream_lf file, and there's a section that has more than 32767 bytes (the RMS maximum record length) between LF characters. Since this is an architectural issue, there's no simple fix. You'd need to find the extra long "record" and somehow break it into smaller pieces.
There may be alternatives involving setting the file attributes to (say) fixed length, then sending the file in binary. This may then need the other end to fiddle with the attributues to "fix" the file (but then it's not clear what the other end is, or what it's expecting).
As ever when transferring data between different systems, you sometimes need a deeper understanding of the exact format of your data in order to reconcile differences in expectations and assumptions.
[FWIW - opinion follows:] LRL is arguably an obsolete concept - it's original purpose was to give code a hint as to what size buffer is needed to process a file. This meant that the application would minimize resource consumption by not having to allocate buffers "big enough for all possibilities".
The idea has a flaw in that a file open for shared write may have longer records written to it after it was first opened by a reader, thus the LRL which was adequate when the file was first opened may be too small to hold newer records. Furthermore, on modern systems where memory is orders of magnitude cheaper than it was when RMS was architected, allocating a 32K buffer is nowhere near as extravagant as it once would have been considered.
From this, it could be considered that we should set the LRL of all files to 32768 and be done with it (as did the DECC RTL circa V6)? Well, on the other hand this is not necessarily a good idea. The classic example where this can hurt is SORT, which uses the LRL to allocate a sort table - one LRL sized entry for each record in the file. When LRL is set higher than the real LRL, SORT performance can be significantly degraded (though it may not be as significant these days with faster CPUs and more available memory).
A crucible of informative mistakes
