Re: CPYFRMIMPF and Unicode - UTF-16 in particular

On 04 Mar 2013 09:07, Vernon Hamberg wrote:

I believe I've an answer that ends up being very flexible.
CPYFRMSTMF. <<SNIP>>
CPYFRMSTMF ... DBFCCSID(*FILE) ... CVTDTA(*AUTO)<<SNIP>>
This was preceded by a CRTPF QTEMP/FLATFILE RCDLEN(3000)

That should convert to EBCDIC using the Job [default] CCSID. The program-described file effectively has no CCSID, but *AUTO still must effect conversion from ASCII encoding to EBCDIC encoding. That would sure limit the data that can be processed; i.e. sure defeats the purpose of having used UTF-16 :-)

With UTF-16, there is an extra row interleaved - because there is a
Unicode CRLF, and the conversion sees the CR and the LF as separate.
No problem - this is easy to clean up!

I do not see that issue on v5r3; my files have just *LF. Seems like a defect. Or perhaps I do not understand what is being described.?

<<SNIP>> And the nulls (UTF-16 only) can be cleaned up with an SQL
REPLACE function. <<SNIP>>

Why would a null character appear in /text/ data? The only expected control characters in a text file are EOR; e.g. *CR, *CRLF, *LF, *LFCR.

Any cautions are much appreciated

The ability to have embedded CRLF in delimited column data would be lost, because the stream is split into database records for each apparent EOR, even if the control characters were not meant to be seen as EOR. Obviously having to choose a fixed record length can be an issue, since there is no such limit for the stream data.

still, this does look pretty cool - no transform needed, similar
effect to how we were using CPYFRMIMPF for ANSI-encoded stream files.

So does that mean that the noted CPYFRMSTMF is functional for both UTF-16BE and UTF-16LE, such that effectively it does the transform of the data to enable the CCSID xlation from 1200 to the defaulted EBCDIC CCSID?

If it can handle the transform, then it would seem odd that the Byte-Order-Mark (BOM) would not be dropped per its no longer having meaning in a database file.mbr.