IBM Support

JR28193: BIDI CHARACTER DATA PASSED TO SQLBINDPARAMETER WITH VALUETYPE SQL_C_WCHAR ENDS UP WITH INCORRECT BIDI ATTRIBUTES IN DB2 ON ZOS

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • In a DB2 LUW (DB2 on Linux, UNIX and Windows) application,
    when you pass BIDI character data to the CLI (Call Level
    Interface)
    function SQLBindParameter, and the ValueType parameter has the
    value SQL_C_WCHAR,
    the character data is written to a DB2 on zOS database with the
    wrong BIDI attributes.
    
    (BIDI character data means data in a script that is written
    partly from right to left and
    partly from left to right. Arabic and Hebrew are BIDI scripts.
    Having the wrong BIDI attributes might mean, for example, that
    Arabic letters
    are unshaped when they should be shaped, or that letters are in
    the wrong order.)
    
    When the DB2 registry variable DB2BIDI=YES, DB2 LUW ought to do
    any necessary
    BIDI string transformation before writing it to a DB2 on zOS
    database.
    But because of this defect DB2 LUW does not do the necessary
    transformation,
    so the data ends up wrong in the DB2 on zOS database.
    
    This defect causes character data to end up wrong when
    you use the Open Table dialog window in Control Center to add a
    row of character data into a DB2 on zOS database.
    
    The following reproduction script demonstrates the problem. It
    uses db2cli, the DB2 CLI interpreter.
    The Arabic character data should end up in the
    DB2 on zOS database as shaped but is instead unshaped.
    And it should end up
    in the DB2 on zOS database in visual order but is instead in
    logical order.
    
    (Visual order means the order in which text appears when you
    scan it with your eyes from left to right. Logical order means
    the order in which you write text.
    For text which you write from right to left, visual order is the
    reverse of logical order.
    In DB2 LUW, Arabic letters are generally unshaped and in logical
    order.
    In DB2 on zOS, Arabic letters are generally shaped and in visual
    order.)
    
    
    In order to run this script, first do the following:
    - Make the connection string in the line beginning with
      SQLDriverConnectW into a valid
      connection string to a DB2 on zOS database.
    - Create a table in the DB2/zOS database with
      DDL (Data Description Language) like this:
        create table TAB1(COL1 char(5))
    - Make the string in the line beginning with UpdateElem into an
      Arabic string as represented
      in the application code page.
    
    
    db2set DB2BIDI=YES
    $HOME/sqllib/samples/cli/db2cli <<EOF
    opt echo on
    SQLAllocHandle SQL_HANDLE_ENV SQL_NULL_HANDLE 1
    SQLAllocConnect  1 1
    SQLDriverConnectW 1 0 "DSN=********;UID=********;PWD=********"
    SQL_NTS 0 SQL_DRIVER_NOPROMPT
    SQLAllocStmt 1 1
    SQLPrepareW 1 "INSERT INTO TAB1 (COL1) VALUES ( ? )" SQL_NTS
    GetMemArray 1 1 1 SQL_C_WCHAR 10
    SQLBindParameter 1 1 SQL_PARAM_INPUT SQL_C_WCHAR SQL_CHAR 0 0 1
    MEMARRAY
    UpdateElem 1 0 VALUE 6 "???"
    SQLExecute 1
    SQLTransact 1 1 SQL_COMMIT
    SQLFreeStmt 1 SQL_DROP
    SQLDisconnect 1
    SQLFreeConnect 1
    SQLFreeEnv 1
    EOF
    

Local fix

Problem summary

  • Users Affected:
    Users of DB2 LUW 9.5 who connect to a DB2 on zOS database
    
    
    Problem Description:
    In a DB2 LUW (DB2 on Linux, UNIX and Windows) application,
    when you pass BIDI character data to the CLI (Call Level
    Interface)
    function SQLBindParameter, and the ValueType parameter has the
    value SQL_C_WCHAR,
    the character data is written to a DB2 on zOS database with the
    wrong BIDI attributes.
    
    (BIDI character data means data in a script that is written
    partly from right to left and
    partly from left to right. Arabic and Hebrew are BIDI scripts.
    Having the wrong BIDI attributes might mean, for example, that
    Arabic letters
    are unshaped when they should be shaped, or that letters are in
    the wrong order.)
    
    When the DB2 registry variable DB2BIDI=YES, DB2 LUW ought to do
    any necessary
    BIDI string transformation before writing it to a DB2 on zOS
    database.
    But because of this defect DB2 LUW does not do the necessary
    transformation,
    so the data ends up wrong in the DB2 on zOS database.
    
    This defect causes character data to end up wrong when
    you use the Open Table dialog window in Control Center to add a
    row of character data into a DB2 on zOS database.
    
    
    Problem Description:
    The following reproduction script demonstrates the problem. It
    uses db2cli, the DB2 CLI interpreter.
    The Arabic character data should end up in the
    DB2 on zOS database as shaped but is instead unshaped.
    And it should end up
    in the DB2 on zOS database in visual order but is instead in
    logical order.
    
    (Visual order means the order in which text appears when you
    scan it with your eyes from left to right. Logical order means
    the order in which you write text.
    For text which you write from right to left, visual order is the
    reverse of logical order.
    In DB2 LUW, Arabic letters are generally unshaped and in logical
    order.
    In DB2 on zOS, Arabic letters are generally shaped and in visual
    order.)
    
    
    In order to run this script, first do the following:
    - Make the connection string in the line beginning with
      SQLDriverConnectW into a valid
      connection string to a DB2 on zOS database.
    - Create a table in the DB2/zOS database with
      DDL (Data Description Language) like this:
        create table TAB1(COL1 char(5))
    - Make the string in the line beginning with UpdateElem into an
      Arabic string as represented
      in the application code page.
    
    
    db2set DB2BIDI=YES
    $HOME/sqllib/samples/cli/db2cli <<EOF
    opt echo on
    SQLAllocHandle SQL_HANDLE_ENV SQL_NULL_HANDLE 1
    SQLAllocConnect  1 1
    SQLDriverConnectW 1 0 "DSN=********;UID=********;PWD=********"
    SQL_NTS 0 SQL_DRIVER_NOPROMPT
    SQLAllocStmt 1 1
    SQLPrepareW 1 "INSERT INTO TAB1 (COL1) VALUES ( ? )" SQL_NTS
    GetMemArray 1 1 1 SQL_C_WCHAR 10
    SQLBindParameter 1 1 SQL_PARAM_INPUT SQL_C_WCHAR SQL_CHAR 0 0 1
    MEMARRAY
    UpdateElem 1 0 VALUE 6 "???"
    SQLExecute 1
    SQLTransact 1 1 SQL_COMMIT
    SQLFreeStmt 1 SQL_DROP
    SQLDisconnect 1
    SQLFreeConnect 1
    SQLFreeEnv 1
    EOF
    

Problem conclusion

  • Problem was first fixed in Version 9.5 Fix Pack 3
    

Temporary fix

Comments

APAR Information

  • APAR number

    JR28193

  • Reported component name

    DB2 UDB ESE WIN

  • Reported component ID

    5765F4101

  • Reported release

    950

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2007-12-24

  • Closed date

    2009-03-13

  • Last modified date

    2009-03-13

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

    JR28191

  • 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

  • R820 PSN

       UP

  • R910 PSN

       UP

  • R950 PSN

       UP

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSEPGG","label":"DB2 for Linux, UNIX and Windows"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"950","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
13 March 2009