[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FTPAPI & text file transfers


As others have found, if one uses ftp_binaryMode(sessionID: *ON) then the nice ASCII (or Latin-1, etc.) files in the IFS get garbled on the FTP server (PUT), or one ends up with rubbish in the IFS (GET).

The word "BINARY" means "my file does not contain text characters, and therefore it should not be translated from one character set to another."

If you store it in your IFS in the format you want it to be in on the Windows or Unix server, then binary makes perfect sense. You're telling it not to do any translation.

For example, if I write an RPG program to export my data in the precise format that a PC application requires it to be in, I don't want FTP to mess that format up by translating the bytes from one code page to another. Instead, I want it to copy it as-is.

That's what binary mode is for. If that's not what you're looking for, then you shouldn't use binary mode!


It has been suggested in the past to use ftp_binaryMode(SessionID: *OFF) in that case.

Absolutely correct. If you want translation to occur, don't use binary mode.


Well, not only does this strike me odd, to send ASCII files as BINARY, it is also quite wrong! It has worked for you guys who GET/PUT files from/to Windows FTP servers, but what happens if you send them to UNIX style FTP servers? Right, no CRLF to LF transformations occur, which is VERY BAD. Same goes for Mac files, which have lines terminated by CR only.

Right. If you want data to be translated in any way, you want to turn binary mode off.

The recommendation to use binary mode comes from the fact that when people have ASCII files in their IFS, it's usually because they created them in the exact format that they want on the server.

Either they've written a program that writes it in the exact format they want it to be in, or they've used CPYTOIMPF or CPYTOSTMF to put it in the precise format they want it in. In that case, you don't want FTP to mess it up by doing conversions on it.


The proper way to do it is the following:

callp     ftp_binaryMode(ftp: *off)
callp     ftp_codePage(ftp: 00819: 00819)

This way the line breaks at the server (CRLF or LF or CR) get converted to/from CRLF in the IFS files rather nicely while no code page conversion occurs. The only downside is the pretty unnecessary conversion from one code page to the same (not sure if the iconv API is smart enough to take a short cut).

Should I change the ToEBCDICF an ToASCIIF routines to check if the code pages are the same, and if so, don't do ny translation?

Another problem with our current translation scheme in FTPAPI is that it uses the same buffer for both input and output. That'll cause problems if you translate from a single-byte character set to a multiple byte character set. For example, from 819 to UTF-16 would corrupt the data.

To me, this is a much bigger problem than the line break convention!

Of course, one may feel free to use different code pages, but 00819 is fine for most Western countries. If you need the € in a PC file, you better use 01252. Of course, feel free to use UTF-8 (as long as you are on V5R3 at the minimum, iirc) as well, for those dealing mainly with Linux and/or XML files.

With UTF-8, again, you run the risk of corruption of data since FTPAPI's translation routines use the same buffer for input and output. For most basic characters, like letters and numbers, you wouldn't have a problem. However, any time UTF-8 needed to use two bytes for a character, you'd have problems.

This is why I recommend that you do the ASCII/EBCDIC/UNICODE translation outside of FTPAPI, and then use BINARY mode for the transfer. That way, you don't have to use FTPAPI's translation routines.

Granted, what I'm doing is working around a bug. But, until the problem is fixed, it's a better solution. I don't have time to re-write FTPAPI right now.