Re: FTP and Unicode files

On 18-Nov-2015 08:32 -0600, Mike Jones wrote:

On 18-Nov-2015 07:26 -0600, CRPence wrote:

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

<<SNIP>>

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:

I think there's a typo in the below (should be x'0D0A'):

Thanks for that correction.

But given the [IMO improper] effect of the SQL interpreting the hexadecimal expression as having the EBCDIC [possibly the default] Job CCSID, the more appropriate correction for that expression requires specification of the <CR>&<LF> characters in EBCDIC, and has since been incorporated in the expression in the quoted text just below:

CAST( RTRIM(C) CONCAT x'0D25' AS CHAR(400) CCSID 1208 )

<<SNIP>>

<<SNIP>>

However I suppose worth noting:

That particular portion of my reply, probably is moot for the purposes of the OP anyhow. First, the fixed-length nature of the data will not allow for an IMAGE transfer, like would be available had the data been placed into a STMF directly with the <CRLF> as record-delimiters. Second, IIRC, a MODE=S (Stream) STRUC=F (File) transfer of the non-EBCDIC data from a database file member sends the trailing blanks irrespective having enabled both the setting of LOCSITE TRIM 1 and the inclusion of ASCII record-delimiters of <CR><LF> because the client knows only how to trim EBCDIC blanks.

The given expression was more about _literally effecting_ what was described just prior, rather than being directly helpful; in effect, I was being somewhat facetious with that tidbit, even while also trying [though failing] to be accurate. Besides, that approach [was predicated on an _assumption_, per lack of a given setup and] would not be helpful *unless* appending those control characters *and* the LTYP C 1208 [and possibly also, only if preceded by the TYPE IMAGE] proved fruitful when used in conjunction; a quick test suggests not. And if the data needed to maintain an arrival-sequence ordering, only the UPDATE of the data using that expression would prove useful [although the CAST would be optional in that statement]. Yet doing an update of every row of database data is little better in many\most scenarios, than just copying the data into a STMF using a feature like CPYTOSTMF that would add the desired record-delimiters to the stream [file].

So just as in my original reply, my conclusion remains the same: That probably the best option would be to just write the CCSID 1208 data with record-delimiters directly to the STMF that will be PUT using FTP with TYPE BINARY, so as to skip entirely, using any database file. But if the database file will be created anyhow, e.g. needs to exist for other reasons, and if the database file would be for text only, then the file probably just as well could be created as a flat [source or data] file rather than as a described file with just one column [if even that is the scenario] such that the CPYFRMSTMF could be used instead of the database export.