Re: FTP and Unicode files

On 17-Nov-2015 19:09 -0600, Steve Landess wrote:

IBM I 7.1
------------

Customer wants a UTF-8 text file, so we created a PF with data
encoded as CCSID(1208) and used FTP to do a PUT (Using BINARY mode)
onto their FTP server (NOT IBM I, probably Windows, not sure).

So "we created a PF..." means essentially the following [or the same effect, just using DDS vs DDL] or perhaps something different?:

create table pf1208 (c char(400) ccsid 1208)

The customer came back and indicated that what they /really/ needed
is UTF-8 with <CR><LF> delimiters on each record.

For the above file, just making the column-c longer and appending those control characters should suffice; probably though, they want the <CRLF> appended to the trimmed data. If not done in the program writing the data, then that suffix could be added in an SQL UPDATE to the data or better as defined in a VIEW [though the order of the record data in the set is undefined] with the following expression:
CAST( RTRIM(C) CONCAT x'0DA0' AS CHAR(400) CCSID 1208 )

When using IBM i to PUT an EBCDIC-encoded [ for example, CCSID(37) ]
to another system, if BINARY is not specified on the PUT then FTP
will translate the EBCDIC to ASCII and put <CR><LF> on each record on
the target file. We tried using FTP with the CCSID(1208) file, and it
seems that IBM i FTP also translates CCSID(1208) to ASCII during the
PUT.

NOT good.

The IBM i as FTP client has the FTP subcommand LTYPE that can be used to identify the local CCSID; effectively, that is an override to the transfer TYPE on the client, without sending any corresponding TYPE to the server. I do not recall however, if\how that helps with regard to the effect for the defaulted TYPE ASCII transfer; while I recall success, I also recall others saying only BINARY\IMAGE was fruitful. Regardless, for example [similar to TYPE C 1208]:
LTYPE C 1208

Not sure if the following successive subcommand requests would help, given the latter will log explicitly in the client session, that the "Server TYPE not changed.":
TYPE IMAGE
LTYPE C 1208

After much experimentation and frustration, the solution which I
devised was to use CPYTOIMPF to copy the UTF-8 PF to an IFS file:

CPYTOIMPF FROMFILE(UTF8FILE) TOSTMF('/home/steve/test.txt')
MBROPT(*REPLACE) RCDDLM(*CRLF) STRDLM(*NONE) RMVBLANK(*TRAILING)

Then used FTP to PUT the IFS file (using BINARY mode) to the target
system.

Had the original file been created as a Source Physical File (PF-SRC) instead, or as a program described file, then Copy To Stream File (CPYTOSTMF) could be used instead of the Copy To Import File (CPYTOIMPF) to move the data to a Stream File (STMF). Seems from the description [or should I say lack of description of the file, data, and ] of the scenario, that the data is likely just text-records, so there would be no cause to perform a database file export.?

This gave them what they wanted - Is there a better way?

As already noted, writing the UTF8 data directly to the stream file with the desired End-Of-Line (EOL) [aka End-Of-Record (EOR)] characters of <CR> and <LF> might be the simplest. If nothing else, that at least eliminates later copying the data from a PF into a stream, and directly allows the stream data to be PUT using TYPE IMAGE.