I couldn't find this actually stated anywhere, but it looks like if you want to use z/OS FTP to transmit a UTF-8 encoded file to (and I assume from) an EBCDIC codepage you have to use multi-byte encoding instead of single byte encoding. The z/OS file also has to be variable length, not fixed length.
Here is an example using curl. Note that this works even on standard Windows 10, as curl.exe is now provided with Windows 10. If you are using PowerShell instead of CMD.exe you need to specify "curl.exe" instead of just "curl". Search the internet for why, if you care. curl --user DVFJS --ftp-ssl --insecure --use-ascii --quote "site mbdataconn=(ibm-1140,utf-8) encoding=mbcs" --upload-file 20201106180101ICMUpload.txt ftp://ZOSD:8443/'DEV.RXMTIN.ICM.ICMM2M.VB' "--insecure" is necessary for me because we have a self-signed FTP server certificate. It may not be necessary for you. Note that this is only required if the source file actually has one or more multi-byte UTF-8 codepoints. A UTF-8 file that only has single-byte codepoints is identical to a standard 7-bit ASCII file and can be transmitted using a default sbcs encoding. I honestly was surprised this work, as the documentation (as I read it, anyway) didn't seem to indicate that conversion between a multi-byte codeset (UTF-8) and a single-byte EBCDIC codeset (IBM-1140, in this case) is possible. But apparently it is. Note that I didn't test anything where the EBCDIC codepage does not have a corresponding codepoint for a particular character. The character in question in this example is "รก", which is code-sequence x'C3A1' in UTF-8 and x'45' in ECBDIC-1140. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN