× 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.



You probably need to tag the IFS file as 1208 instead of 819 - or CPY it binary to an IFS file so tagged.

Or is there a setting on CPYFRMIMPF for CCSID, from and to? Used to be one for code page, but you should not use that, IIRC.

Vern

On 5/18/2020 10:14 AM, smith5646midrange@xxxxxxxxx wrote:
I must be missing a step because I did not get what I thought that I would.

The file on our IFS is CCSID 819.
I created a DB2 file that is CCSID 37 except for the two fields that are
problems and they are defined as 1208.
I did a CPYFRMIMPF and did not change any of the default values except
record delimiter.
I created a test RPGLE program that read the DB2 file and then moved one of
the 1208 fields to a work field in the program.
The value in the work field is identical to the 1208 field and does not
contain hex 3F chars.

What did I miss?

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Barbara Morris
Sent: Wednesday, May 13, 2020 12:14 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Chinese characters in an interface file

On 2020-05-13 11:22 a.m., Vernon Hamberg wrote:
Hi

It is possible that the CSV file is in UTF-8 -- the hex 31 you
describe is what the number 1 would be in UTF-8.
...

If it IS UTF-8, you might try marking the file with CCSID 1208 and do
a text transfer, not a binary transfer.

Or mark the field in your PF as 1208 CCSID, do the binary transfer,
then see what RPG does with it. In RPG, do and EVAL from the UTF-8
field to a regular 37 EBCDIC field.
...
I agree with Vern that it is likely that you have UTF-8 data.

If you get the data into a UTF-8 RPG field and assign it to a CCSID 37 using
RPG, the characters that can't convert to CCSID(37) will be x'3F'.
You could then scan for x'3F' and blank the field if you find one.

Or, if you're specifically only concerned with Chinese, you could assign to
a CCSID(937) field, and then scan for x'0E' to see if there are any Chinese
characters.

But ... following the Never Lose Data principle, I think it would be a
zillion times better to save the UTF-8 data as is and not try to convert it
to CCSID 37, and especially not blank the field if it has Chinese data.

Just guessing, but assuming you do need this in CCSID 37, wouldn't it be
better to just replace the unconvertable characters with say '?' than to
blank out the entire field?

--
Barbara

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.