On 04 Mar 2013 09:07, Vernon Hamberg wrote:
I believe I've an answer that ends up being very flexible.
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
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.