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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.