× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.

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


From: "Patrik Schindler" <poc@xxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
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

We are transferring files from a new ftp server hosted on a unix/linux

The transfer is using ascii mode

If you look at the ascii file there are CRLF (0A0D) at the end of each

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2023 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.