× 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.



hi John,

When you do your FTP transfer in "binary" mode, FTP will do absolutely no translation. It will simply copy the data byte-by-byte to the remote system.

When you use "ascii" mode, then the system will translate from the CCSID of the file to the remote CCSID (which is configured via the CCSID parameter of the FTP or STRTCPFTP commands, and defaults to 819).

ASCII mode may also cause FTP to translate the end-of-line delimiter... when FTPing a PF, for example, it will add CRLF to the end of each record. When FTPing a stream file, the CRLF that's already in the file may be translated to LF-only if sending to a Unix machine (but, of course, you're sending to Windows so that wouldn't be an issue.)

If you already have the file in 1252, then it's probably intended to already be in Windows format, so I'd recommend using binary mode. No point in having FTP translate it from 1252 to 819!


John McKee wrote:
This will sound naive. I have a file in the IFS. CCSID is 1252.

If I FTP that file to a Windows server, will the file be readable on the other
end? Or, perhaps a better question: What determines when FTP translates the
characters in a file?

The reason I ask is the only access I have to the Windows server is via FTP. I
could retrieve the file and look at it, but how would I know if FTP did not do
a second character conversion, to "help" me?

John McKee



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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.