DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

Since the database is defined as Unicode, any data being sent or received by the application
must be converted by the DBM1 address space, such as in this example in which the
EBCDIC code page is 37. Had the database remained as EBCDIC 37, no CCSID conversion
would be necessary. The table contains one CHAR column called COLC (CCSID 1208) and
one GRAPHIC column called COLG (CCSID 1200). When the application inserts host
variables HV1 and HV2 into the table, the strings are converted by the DBM1 address space
to Unicode. The CPU time for these conversions is added to the class 2 CPU time.
Figure 4-13 shows a DB2 Connect example using the same Unicode table.
C-program
INSERT
HV1 943
HV2 943
SELECT
HV1 943
HV2 943
DB2 Connect V8
Conversion
Routines
DisableUnicode=1
AIX z/OS
DRDA
Common
Layer
Figure 4-13 CCSID conversion - Remote application - 1
The application is running remotely on an AIX client and uses the Japanese ASCII CCSID
943. The application uses DB2 Connect V8 to communicate to the z/OS server.
The DRDA protocol and DB2 maintain a convention strategy in which the "receiver makes
right". Hence, DRDA lets DB2 for z/OS do the conversions when sending data to the server,
and DB2 for z/OS lets the client do the conversions for data being retrieved by the client.
Note however that the conversion is actually performed by the DBM1 address space, not the
DIST address space. The DBM1 address space actually does the inbound CCSID conversion
for character strings, while the DIST address space performs the conversion for numeric data.
IBM first introduced a JDBC Driver in V5 and V6, which is now known as the Legacy JDBC
Driver. On workstations, the Legacy JDBC Driver interfaced with DB2 Connect. When
sending data to a DB2 for z/OS V6 server, the Legacy JDBC Driver converted the data from
UTF-16 to EBCDIC, because V6 was unable to handle incoming data in Unicode. (All IBM
implementations of Java use CCSID 1200 corresponding to UTF-16.)
However, DB2 V7 supports Unicode databases. If DB2 Connect were to convert UTF-16 data
to EBCDIC and then the server converted it to back to Unicode, there would be a potential for
data loss since not all Unicode characters exist in the intermediate EBCDIC character set. To
DDF
DB2 Connect V8
DBM1
1208 COLC
1200 COLG
1208 COLC
1200 COLG
Chapter 4. DB2 subsystem performance 177