Re: FTP PF to Windows Server with Chinese Characters

On 27 Jun 2013 10:36, Robert Engelhardt wrote:

<<SNIP>> Something tells me that doing this from a Windows machine to
a Windows machine would have been much more intuitive. <<SNIP>>

Probably. But like I had suggested in my prior reply, better results can probably be expected by changing the process to generate the data [that will be PUT via FTP] in a manner that other systems [more specifically *the* target system being used] would prefer. Doing that, rather than trying to use the IBM i as the EBCDIC-centric system that it is, and by avoiding the database file member as a data container, the transfer of data betwixt can probably be as simple as Win-to-Win. That is to suggest, use a STMF instead, and include a Byte Order Mark (BOM) or whatever else identifies the data to the recipient system and application. But definitely use something ASCII that the Windows OS can /infer/ what is the data, when there is no BOM. As if... any system that would effectively /ask the data/ what type of data it is, is more "intuitive" than the container identifying what type of data is within; I am unlikely ever to be convinced.

A physical database file, even non-described or described as "source" [PF-SRC] is not merely a data stream. The database member is never going to match the conceptual /stream file/ as they are recognized and treated by other [operating] systems; i.e. database files will never be treated in the somewhat agnostic manner of file-is-data\data-is-file. That perspective of /files as data/ by other systems, rather than as /objects with data/ within the file, is consistent with the even more agnostic [err... ignorant] concept of the FTP about so-called "files". In contrast with what is alluded by the name File Transfer Protocol, the FTP is actually little more than a /data transport/ feature; and limited to transferring stream data *either* as binary\image or text /record data/ for which some EOR embedded in the stream is honored, rather than the fixed-record-length concept. The FTP can legitimately IMO, only be considered a /file transport/ feature when the server and client both have little effective differentiation between the terms data and file, and the "file" is little more than a name\label with which the data is associated [as contrasted with the /object/ as container which is the concept of IBM i for the /QSYS.LIB database file member].

So IMO if one were to "dumb down" the scenario to mimic the level of support provided by the recipient system of type-¿X?, then very likely the transfer between the IBM i and the system of type-¿X? could be as seamless as when effecting the transfer between two systems of the same type-¿X?