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



Hello Barbara,

Am 29.08.2023 um 18:28 schrieb Barbara Morris <bmorris@xxxxxxxxxx>:

Again, this is only an issue with UTF-8 data in database files. There is no similar issue with UCS-2 and UTF-16 data in database files.

Why should one mess with UTF-8 in the i database then? As long as automatic conversion works towards the end user UI, I see no reason to introduce workarounds to prohibit any conversion just for the sake of "UTF-8 in the database"? To me, this smells quite a bit like the ever-touched-QCCSID issue.

As far as I know, this issue with UTF-8 in the database is an RPG issue, mainly due to the fact that RPG did not become "aware" of alphanumeric CCSIDs until V7R2.

Interesting remark.

I'm coming closer to the point facing a similar issue myself.

I have a bunch of DDS derived PFs with CCSID 1141 (EBCDIC + €), on a 7.2 machine. An external PHP application running on Linux uses ODBC to meddle with the data within. For some reason, the Linux side gets (and must send) Latin1. Modern browser based infrastructure wants to use UTF-8 exclusively. Because the PHP stuff must be reworked anyway, I was asked to help with the database side of affairs.

Now I'm contemplating which CCSID to give text database fields for new data tables, copying data with "insert into… select from" from the existing tables, and do automatic conversion to the right thing.

Looking at this:
https://www.ibm.com/docs/en/i/7.2?topic=encodings-fileencoding-values-i-ccsid

You said that UTF-8 in database files is (mainly) a problem because of RPG vs. alphanumeric CCSIDs. But from the table above I see UTF-8 is said to match CCSID 1208, which only has digits. Currently, the database PFs are used solely over ODBC. No local 5250 applications. Yet. Maybe someday this might become a thing.

May I kindly ask you to elaborate about this alphanumeric thing for RPG?

Thanks!

In addition, I was under the impression that there is a "UTF-8 EBCDIC" encoding. AFAIK UTF-8 low positions are ASCII compatible and I assumed there is a similar, backwards compatible entity for EBCDIC. Apparently I assumed wrong. :-)

One more thing… I can compile a PF with CCSID(1208) character fields to an object, but not CCSID(1200) which should be UTF-16 according to the above table. This fails due to CPD7678. The help text leaves me puzzled. Is this just a badly worded "not supported"? Which means my only meaningful option is CCSID(1208).

Thanks for helping. This topic is highly confusing.

:wq! PoC


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.