Thanks Patrik,
This is all client driven so difficult to get an interim step.
Client receives/downloads files from a number of agencies/suppliers and
saves to local file system.
File is then transferred to ftp server using WINSCP (Great tool)
The IBMi picks up the file and processes.
And suggesting to the user to run some steps to correctly format the file
is not really an option as they will either forget to do it or complain
about having to do it.
So our work around will do for the time being.
Appreciate your feedback
Don
From: "Patrik Schindler" <poc@xxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxxxxxxxx>
Date: 15/02/2023 07:07 PM
Subject: Re: FTP from unix/linux system causing EOL issues
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx>
Hello Don,
well diagnosed! I congratulate you!
Am 15.02.2023 um 08:30 schrieb Don Brown via MIDRANGE-L
<midrange-l@xxxxxxxxxxxxxxxxxx>:
We are transferring files from a new ftp server hosted on a unix/linux
system.
The transfer is using ascii mode
If you look at the ascii file there are CRLF (0A0D) at the end of each
line
The native line ending of UNIX style text files is only LF, no CR.
FTP I know about clients assume the following rules in ASCII mode:
LF = UNIX/Linux
CR/LF = DOS/Windows
CR = Classic Macs (Pre OS X)
Thus, the client doesn't expect "excess" CRs and passes them untreated,
even in ASCII mode.
We have added some code to replace the hex 0D with a blank and this has
enabled the file to be processed but I have not been able to find any
other option.
The cleanest option is to place a corrected file on the Linux server. You
can delete excess CR characters with tr -d '\r' < infile > outfile
Probably there are other choices how to get the initial file right from
the start?
With files that we ftp from a windows server there is no end of line
character at all as per the following example
See above: Because the file adheres to the platform standard rules.
:wq! PoC
midrange.com
