If you're doing the ASCII-EBCDIC translation outside of the FTP transfer process, I have to assume that you're transferring in binary mode (otherwise the translation would be done again and your data would be bad).
If that is the case, then I'm pretty certain you're responsible yourself for the conversion of line endings as well. Binary transfers will not attempt to convert line endings. You'll need to pad out the lines to the desired lengths and remove the line endings altogether, before sending it up to the host.
By way of example, if you transfer this file:
12345
67890
up in binary mode using literal site recfm=vb
, you'll get the following (shown in ISPF editor with hex on
):
000001
3333300333330044444
12345DA67890DA00000
--------------------------
You can see it's just transferred the bytes as-is, including the CR/LF. If you switch to ASCII mode in FTP and upload again, you get:
000001 12345
FFFFF44444444
1234500000000
--------------------
000002 67890
FFFFF44444444
6789000000000
--------------------
Here, the characters have been converted to the right EBCDIC code points and the line endings have been morphed into padding with EBCDIC spaces.
I suppose my first question to you would be: "Why are you doing the translation outside of FTP?"
IBM invests quite a lot of money in ensuring that it will accept all sorts of different encodings and translate them into the correct code page. It's very unlikely that a stand-alone solution will work on all the internationalised versions of z/OS as well as IBM's own.
If you must convert on the client and transfer in binary mode, you'll either have to have the client do the line ending conversion and padding as well or post-process the file after the transfer, such as with a REXX script.
If you don't know what the properties of the target data set will be (such as if you're transferring into a member in a PDS), the latter option may be the only viable one.