extra carriage return (CR) when ftp to mainframe server

Question

We use edtFTP java api which runs on Linux to upload windows files (windows folder is mounted on linux) to mainframe ftp server. The source files have \r\n at the end of each line as it is windows format file. But our application (ftp client) runs on linux, therefore the line.separator='\n'. When the file is uploaded to mainframe with Fixed Block (FB), we observe a carriage return which upsets mainfram application, as it does not expect extra carriage return.

I wonder if anybody has similar problem like this. After we modified the code in FTPClient.java to remove the carriage return in putData(), then it is OK.

Is this a defect?

Thanks.

Richard

Answer 1

This isn't really a bug in edtFTPj. It is running on Linux, therefore it expects a Linux line separator of '\n'. So it will replace '\'n' with the FTP protocol's line separator, which is interpreted correctly by the FTP server and replaced with the mainframe separator. The '\r' is passed through and will appear in the mainframe file.

I suppose we could try to detect other platforms' line separators on each platform, or at least '\r\n'. But you are doing a non-standard thing by having the wrong line separator on Linux.

We use edtFTP java api which runs on Linux to upload windows files (windows folder is mounted on linux) to mainframe ftp server. The source files have \r\n at the end of each line as it is windows format file. But our application (ftp client) runs on linux, therefore the line.separator='\n'. When the file is uploaded to mainframe with Fixed Block (FB), we observe a carriage return which upsets mainfram application, as it does not expect extra carriage return.

I wonder if anybody has similar problem like this. After we modified the code in FTPClient.java to remove the carriage return in putData(), then it is OK.

Is this a defect?

Thanks.

Richard