JR27817: FOR DB2/ZOS DATABASE WITH BIDI CCSID (ARABIC OR HEBREW) CHARACTER DATA IN WRONG ORDER OR HAS OTHER WRONG BIDI ATTRIBUTES

APAR status

• Closed as duplicate of another APAR.

Error description

• When you use DB2 LUW (DB2 for Linux, UNIX and Windows) to query
  data in a DB2 on z/OS database, the letters in character data
  might appear in the wrong order.
  
  This might occur when all these conditions are true:
  - the DB2 on z/OS database is version 8 or above,
  - the DB2 registry variable DB2BIDI is set on,
  - the 9th entry in the DCS parameters in the DCS directory entry
    of the DB2 on z/OS database is set,
  - the DB2 on z/OS database has a CCSID (Coded Character Set
    Identifier) that is for a BIDI (bidirectional) script.
  
  A bidirectional script is a script that is written partly from
  right to left and partly from left to right. Arabic and Hebrew
  are bidirectional scripts.
  
  The problem happens when the string does not undergo the
  transformation which is appropriate for
  the BIDI (bidirectional) string attributes of the CCSID
  (Coded Character Set Identifier) specified in the 9th entry in
  the DCS parameters in the DCS directory entry.
  
  BIDI string attributes are described at
   http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?to
  pic=/com.ibm.db2.udb.admin.doc/doc/r0004571.htm
   http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?to
  pic=/com.ibm.db2.udb.doc/doc/c0006234.htm
  
  The root cause of the problem is a difference in the DRDA
  (Distributed Relational Database Architecture)
  data that DB2 version 8 on z/OS sends to the DB2 LUW client, as
  compared with the DRDA buffers that
  DB2 version 7 on z/OS sends.
  In some cases, DB2 version 8 on z/OS sends the actual CCSID of
  the DB2 on z/OS database but  DB2 version 7 on z/OS database
  does not. The symptom occurs when
  the actual CCSID of the DB2 on z/OS database does not have the
  appropriate BIDI string attributes
  for the way that the character data is actually stored there.
  
  For example, suppose you have a DB2 on z/OS database which has
  CCSID 420 but in which character
  data is actually stored in the order appropriate for the BIDI
  string attributes of CCSID 62250.
  (CCSID 62250 is for the same code page as CCSID 420, but defines
  a different
  order for the letters in a character data.) And suppose you have
  a DB2 LUW client on which
  DB2BIDI=YES and on which the 9th entry in the DCS parameters in
  the DCS directory is BIDI=62250.
  If the DB2 on z/OS database is version 7, the DB2 LUW client
  does the string transformation
  that is appropriate for CCSID 62250, because that is the CCSID
  that is specifed in the DCS parameters, so the character data
  appears correctly on the client.
  But if the DB2 on z/OS database is version 8 or above, the DB2
  LUW client does the string transformation
  that would be appropriate for CCSID 420, because that is the
  actual CCSID of the DB2 on z/OS
  database, so the letters in character data appear in the wrong
  order on the client.
  
  APAR JR27816 describes another problem when querying a DB2 on
  z/OS database that is version 8 or above.
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• duplicate of JR27803
  

APAR Information

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

  JR27601

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

Fix information

Applicable component levels