Fixes are available
DB2 Version 9.1 Fix Pack 7 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 5 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 6 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 6a for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 7a for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 8 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 9 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 10 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 11 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12 for Linux, UNIX and Windows
APAR status
Closed as program error.
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 JR27607 describes another problem when querying a DB2 on z/OS database that is version 8 or above.
Local fix
Problem summary
Users affected: Users of DB2 9 for Linux, UNIX and Windows who connect to a DB2 on z/OS database that is version 8 or above. Problem 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. Problem Summary: 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 JR27607 describes another problem when querying a DB2 on z/OS database that is version 8 or above. LOCAL FIX: none
Problem conclusion
Problem was first fixed in Version 9 Fix Pack 5
Temporary fix
Comments
APAR Information
APAR number
JR27608
Reported component name
DB2 UDB ESE WIN
Reported component ID
5765F4101
Reported release
910
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2007-10-11
Closed date
2008-06-24
Last modified date
2008-06-24
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
DB2 UDB ESE WIN
Fixed component ID
5765F4101
Applicable component levels
R810 PSN
UP
R910 PSN
UP
Document Information
Modified date:
07 October 2021