On 04 Mar 2013 11:52, Vernon Hamberg wrote:
... CPYFRMSTMF appears to do a byte-by-byte conversion, as it seemed
CPYFRMIMPF did as well, just not all the time. So the typical UTF-16
representation for our situation is ANSI characters alternating with
x00's. ...
Ignoring any little-endian data:
Again, that issue [almost positively] is due to the incorrect
tagging; i.e. wrong CCSID. When the STMF is tagged with something other
than 1200 but its data is UTF-16BE, then the copy feature does not work.
So if the file is incorrectly tagged with CCSID-1252 or CCSID-819,
then CPYFRMSTMF does not know you lied, and tries to convert the data
based on that lie, then the effect will *appear to be* byte-by-byte
conversion. That is because the feature has no idea that the data is
two-byte characters, when the CCSID says they are not. Unlike the
CPYFRMIMPF however, the STMFCCSID [or STMFCODPAG on older releases] can
be used to override the STMF CCSID to 1200.
I can use the CPYFRMSTMF to copy [western characters as] UTF-16BE
data into EBCDIC without any issues on v5r3, so it should function
properly [the same] in any later release as well. I just have to ensure
the data in the STMF is really UTF-16BE and the STMF has the *CCSID
attribute of VALUE(1200). The feature recognizes the two-byte control
characters for EOR, so there would be no null character getting sent to
the flat file.
