IC62173: USAGE OF THE GL_USEGLU ENVIRONMENT VARIABLE IN CONJUNCTION WITH UTF8 DATABASES IS NOT FULLY DOCUMENTED

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 is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels