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.
midrange.com
