Re: CPYFRMIMPF and Unicode - UTF-16 in particular -- MIDRANGE-L

× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.

It's good to know that things work if the file CCSID is right - I might not have clarified that the CCSID is almost always 1252, coming from Windows in some fashion.

I am surprised that the FROMCCSID does not affect things when working with IFS files - that kind of irks me. It seems it is documented, I just find it odd.

More reasons to be a bit unhappy with CPYFRMIMPF - it's history is checkered, as a search of these archives will show. Maybe there's a way to make it dance, but hardly anyone has done so reliably.

Cheers
Vern

On 3/2/2013 10:59 AM, CRPence wrote:

On 01 Mar 2013 23:22, Vernon Hamberg wrote:

I agree with your suggestions - trouble is, the scenario doesn't
match their use. The files are being saved, perhaps, from Notepad,
and we don't know which encoding the user chooses.

Sorry. I was not meaning to address anything other than big-endian
UTF-16 and the "with or w/out BOM" claim. My point was to refute the
claim that all the variations of UTF-16 were nonfunctional... by
pointing out that the CPYFRMIMPF worked fine for the endian-ness of the
system, but with the BOM, the feature does not ignore them as valid
data; and that CCSID is 1200.

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.