Re: FTP issue

Dennis Lovelady wrote:

If the recipient is also placing the file into a save file, and
if the recipient's system is backlevel from the version required
by the save file, this kind of thing can happen.

Is that an implication that the checksum algorithm changed across some release boundary? AFaIK there is no inter-release issues for transporting save file data records; i.e. save file data /records/ as binary data are release independent, and the only inter-release issue should be with the capability of restoring the saved data, according to the TGTRLS() that was specified on the save. I used to receive save file data into save files on v3r2, v3r7, and various V4 systems from most of the v5 system release levels without any problems.

Or if the recipient is downloading in ASCII mode (though I
would not expect it to get halfway through unless this is a particularly small save file).

The transfer should not even start in that case. The i as either FTP client or FTP server is supposed to issue an error when the target file exists as a device file with the attribute SAVF and the transfer mode is not binary\image. That validation & error has in my experience, occurred before any data is either read or written from\to the i per the transfer direction.

If recipient is receiving into a save file, you might have them
try receiving into a normal file instead, just to prove there's
no FTP issue.

I do not think success with that scenario would prove conclusively that there is no FTP issue. However that scenario would probably be worthwhile to infer if the problem may be specific to the target file being a save file or being that specific save file. Transfer of the binary stream into a database file as binary data records can be accomplished by specifying the target as a previously created file; created using CRTPF RCDLEN(528) SIZE(*NOMAX), and if a member was created by that request, e.g. per MBR(*FILE), then being sure to either omit the member name or explicitly name that member as target [or, although not desirable, to specify MAXMBRS(*NOMAX) or some value greater than the default of 1, to avoid an issue with "too many members"].

Regards, Chuck