Re: Can I make FTP embed EOLs in source members transfered as EBCIDIC?

On Sat, Jan 23, 2016 at 11:41 AM Steve Landess <sjl_abc@xxxxxxxxxxx> wrote:

As you already know, with a regular FTP transfer from IBM i (not BINARY),
FTP automatically inserts <CR> <LF> when using FTP to GET from the PC
(i.e.,
as an ASCII file). Likewise, FTP strips out the <CR><LF> found in the text
file when PUTting it back into a member on IBM i.

It's funny you call ASCII "regular." Outside of IBM land, the point of TEXT
mode was not to change encodings. It was to take advantage of the fact that
ASCII needed 7 of the 8 bits, and you had a "free" parity bit. That
probably made a lot of sense when the backbone of the internet talked to
each other via 56k links and PCs were talking 300bps via acoustical
decouplers. However, before I went to tilt this source member ftp windmill,
the FTP ASCII command was just a way people would screw up file transfers
because of the the 8th bit of every binary file would be written as 0.

I'm not saying you're wrong. It was very clever of IBM to take advantage of
the ASCII command in the protocol to do something it was never intended to
do. Just realize that "normal" and "regular" is subjective.

For BINARY files, I think you're SOL.

Actually I think I can autowrap at 80 characters as I pointed out to Vernon.

Another problem you may encounter . . .is . . . source members which are
encoded in CCSID's other than English
(37) - FTP'ing them to the PC as ASCII can cause loss of data

My current clients all love mom, apple pie and ASCII, plus a canadian one,
so not an immediate concern. However, you make a good point. I should solve
this with word wrapping and not with ASCII translation if its not to
painful in case I have to deal with some non-english code.

Great food for thought.