Handling BiDi data

The following section applies to OS/390^® and z/OS^® servers only. This feature must not be enabled for a DB2^® for i5/OS™ server as full BiDi support is already provided.

The following BiDi attributes are required for correct handling of BiDi data on different platforms:

Numeral shape (ARABIC versus HINDI)
Orientation (RIGHT-TO-LEFT versus LEFT-TO-RIGHT)
Shaping (SHAPED versus UNSHAPED)
Symmetric swapping (YES or NO)
Text type (LOGICAL versus VISUAL)

Since defaults on different platforms are not the same, problems appear when DB2 data is sent from one platform to another. For example, Windows^® platforms use LOGICAL UNSHAPED data, while OS/390 or z/OS data is usually in SHAPED VISUAL format. Therefore, without any support for BiDi attributes, data sent from DB2 for OS/390 and z/OS to DB2 Connect™ on Windows displays incorrectly.

When data is exchanged between DB2 Connect and a database on a server, it is usually the receiver that performs conversion on the incoming data. The same convention would normally apply to BiDi layout transformation also, which is in addition to the usual code page conversion. However, currently no host DB2 product supports BiDi-specific CCSIDs or BiDi layout transformation. Therefore, DB2 Connect has been enhanced with the optional ability to perform BiDi layout transformation on data it is about to send to the server database in addition to data received from the server database.

For DB2 Connect to perform BiDi layout transformation on outgoing data to a server database, the BiDi CCSID of the server database will have to be overridden. This is accomplished through the use of the BIDI parameter in the PARMS field of the DCS database directory entry for the server database.

The use of this feature is best illustrated with an example.

Consider a Hebrew IBM^® data server client running CCSID 62213 (BiDi string type 5) and you would like to access a DB2 host database running CCSID 424 (BiDi string type 4). However, you know that the data contained in the DB2 host database is instead based on CCSID 62245 (BiDi string type 10).

There are two problems in this situation. The first is that the DB2 host database does not know the difference between the BiDi string types with CCSIDs 424 and 62245. The second problem is that the DB2 host database does not recognize the IBM data server client CCSID of 62213. It only supports CCSID 62209 (BiDi string type 10), which is based on the same code page as CCSID 62213.

You will need to make sure that data sent to the DB2 host database is in BiDi string type 6 format to begin with and also let DB2 Connect know that it has to perform BiDi layout transformation on data it receives from the DB2 host database. You will use the following cataloging for the DB2 host database:

   catalog dcs database nydb1 as TELAVIV parms ",,,,,,,,BIDI=62245"

This tells DB2 Connect to override the DB2 host database CCSID of 424 with 62245. This override includes the following processing:

DB2 Connect will connect to the DB2 host database using CCSID 62209 (BiDi string type 10).
DB2 Connect will perform BiDi layout transformation on data it is about to send to the DB2 host database from CCSID 62213 (BiDi string type 5) to CCSID 62209 (BiDi string type 10).
DB2 Connect will perform BiDi layout transformation on data it receives from the DB2 host database from CCSID 62245 (BiDi string type 10) to CCSID 62213 (BiDi string type 5).

Note:

The environment variable or registry value DB2BIDI has to be set to YES in order for the BIDI parameter to take effect. DB2BIDI must be set at the DB2 Connect workstation where the DCS database directory entry is catalogued. For applications running on a client remote to a DB2 Connect server, the DB2BIDI variable must be set at that client as well.
If you would like DB2 Connect to perform layout transformation on data it is about to send to the DB2 host database even though you do not have to override its CCSID, you still have to add the BIDI parameter in the DCS database directory PARMS field. In this case, the CCSID that you should provide would be the default DB2 host database CCSID.
In some cases, use of a bidirectional CCSID might cause the SQL query itself to be modified such that it is not recognized by the DB2 server. Specifically, you should try to avoid using IMPLICIT CONTEXTUAL and IMPLICIT RIGHT-TO-LEFT CCSIDs when a different string type can be used. CONTEXTUAL CCSIDs can produce unpredictable results if the SQL query contains quoted strings. Avoid using quoted strings in SQL statements, and use host variables instead when possible.
If a specific bidirectional CCSID is causing problems which cannot be rectified by following these recommendations, then you should set the environment variable or registry value DB2BIDI to NO.

Parameter string specifications

The following are examples of DCS parameters (each line is a set of parameters):

   NOMAP    /u/username/sqllib/map/dcs1new.map,D    ,D    ,,INTERRUPT_ENABLED    NOMAP,D,INTERRUPT_ENABLED,,,SYSPLEX,LOCALDATE="YYMMDD",,

Alternatively you can accept the defaults by not specifying a parameter string.

Note: You must use the operating system escape character "\" (backslash) when using CLP from the operating system's command line on UNIX^® systems because of the need to specify two pairs of double quotation marks when specifying the LOCALDATE mask in the parameter string. For example:

   db2 catalog dcs db x as y parms \",,,,,,LOCALDATE=\"\"YYMMDD\"\"\"

This results in the following DCS directory entry:

   DCS 1 entry:

    Local database name                = X     Target database name               = Y     Application requestor name         =
    DCS parameters                     = ,,,,,,LOCALDATE="YYMMDD"
    Comment                            =
    DCS directory release level        = 0x0100

Related concepts
Bidirectional support with DB2 Connect

Related reference
Bidirectional-specific CCSIDs