APAR status
Closed as documentation error.
Error description
There is a lack of information on how and when to use this variable in conjunction with multibyte code sets . At this time the IBM Informix GLS User's Guide, version 4.50, page 2-20 : GL_USEGLU (IDS) describes the usage with GB18030-2000 code page only. A reference to other multi byte code sets is completely missing Databases with DB_LOCALE ....UTF8 will be used, more and more by our customer. idsdb00170190 describes a workaround (see below) which uses GL_USEGLU. It should be documented. At this time there is no reference found within the documentation: Additional Information There are two defects which deals with this problem: idsdb00173351, idsdb00170190 Inserting special unicode chars (e.g Unicode char "\uf0a7" ) fails with UTF8. 408: Invalid message type received from the sqlexec process. Within defect idsdb00170190 a workaround is gathered: workaround for jdbc issue with inserting characters that are not valid in the default utf8 encoding. If the customer is heavily reliant on informix JDBC recommend migrating database to be created with GL_USEGLU=1 In the mean time, a GL_USEGLU enabled client will be required to access text and clob data inserted with JDBC. When GL_USEGLU is not set before bringing up IDS F0A7 is not a valid in utf8. jdbc should not have allowed the insert. 1 the java insert happened, idsdb00173351 opened for this. When GL_USEGLU is not set before bringing up IDS F0A7 is not a valid in utf8. jdbc should not have allowed the insert. 2 as the java insert did happen, unload should unload it to do this you have 2 options, java data can be unloaded if GL_USEGLU=1 is set by the client application unloading the data. (This changes the version of unicode used by the client) for best results, set GL_USEGLU=1 before bringing up IDS and recreate the database, but just doing this client side will be an ok workaround to the customers problem.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * * All users of IDS documentation version 10.00.xc10 and * * earlier, 11.10.xc3 and earlier, and 11.50.xc5 and earlier * **************************************************************** * PROBLEM DESCRIPTION: * * There is insufficient information regarding why, when, and * * to what value the GL_USEGLU environment variable should be * * set to support Unicode in conjunction with multibyte code * * pages and code sets. References to GL_USEGLU in GLS User's * * Guide, Administrator's Guide, and ESQL/C Programmer's Manual * * provide incomplete information about this feature, and about * * IDS and CSDK functionality that requires GL_USEGLU to be set * * to 1 (one) in the client or the server environment, or in * * both environments. * **************************************************************** * RECOMMENDATION: * * Upgrade to the next version documentation when available. * ****************************************************************
Problem conclusion
For IDS to support versions of Unicode up to 4.1, the GL_USEGLU environment variable must be set to a value of 1 on the server before the server is started, and before the database is created. This setting initializes conversion routines that enable Unicode collation by the server in databases that use UTF-8 character encoding, including the Chinese GB18030-2000 code set. The SET COLLATION statement of SQL, for example. Cannot enable localized collation for a nondefault Unicode locale, such as sh_hr.utf8, which supports the Serbo-Croatian language, unless GL_USEGLU=1 when the server was started. To enable Unicode collation by Java/JDBC or ESQL/C client applications, and for other client APIs that require compilation, set GL_USEGLU to 1 in the client environment before the routine is compiled. For ESQL/C applications, an alternative to setting GL_USEGLU is to compile with the -glu compiler flag to access internal Unicode libraries.
Temporary fix
Comments
APAR Information
APAR number
IC62173
Reported component name
IBM IDS ENTRP E
Reported component ID
5724L2304
Reported release
B15
Status
CLOSED DOC
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2009-07-22
Closed date
2010-01-22
Last modified date
2010-01-22
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSGU8G","label":"Informix Servers"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"B15","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
22 January 2010