Thanks Roger,
Yes I am seeing the benefit in simplicity.
We now have a procedure where we pass the EOL character and replacement
character to check for and it replaces it.
And it is working
So I will stop looking for a "better" solution
Cheers
Don
From: "Roger Harman" <roger.harman@xxxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxxxxxxxx>
Date: 16/02/2023 10:10 AM
Subject: RE: FTP from unix/linux system causing EOL issues
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx>
I used to deal with this stuff daily. Can't speak to WinSCP as I used
GoAnywhere but, to me, it's just a matter of knowing what you're dealing
with.
Different EOL treatment is no different than knowing what delimiters, if
any, are in your file. Your process needs to adapt accordingly.
We did thousands of file transfers a day but they were all parameter
driven. For a given host and/or transfer type, we had the delimiters,
EOL, etc. soft coded in a config file and just dealt with it that way.
Typically using CpyFrmImpF.
Roger Harman
COMMON Certified Application Developer - ILE RPG on IBM i on Power
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jack
Woehr via MIDRANGE-L
Sent: Wednesday, February 15, 2023 6:52 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Cc: Jack Woehr <jwoehr@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: FTP from unix/linux system causing EOL issues
In PASE:
*tr -d '\r' <input.txt >output.txt*
Ladies and gentlemen, all these problems were solved in the 1970's in
Unix.
Get to know your IBM i Unix-like environment!
On Wed, Feb 15, 2023 at 12:30 AM Don Brown via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
After ftp'ing the file directly to a physical file we have a end of line
character of hex 0D
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.
midrange.com
