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

9.1 Unicode catalog
DB2 for z/OS supports three types of encoding schemes:
► EBCDIC
► ASCII
► UNICODE
Traditionally IBM mainframes have been based on EBCDIC, while Unix and Windows
applications are based on ASCII. Beginning with Windows NT®, everything stored in
Windows was stored in Unicode (UTF-16). To handle larger character sets, which are
absolutely necessary in Asian languages, double byte characters and mixtures of single byte
and double byte characters were necessary.
Each national language developed its own code pages in EBCDIC or ASCII. The character
set for a language is identified by a numeric CCSID. An encoding scheme consists of a single
byte character set (SBCS), and optionally a double byte character set (DBCS) along with a
mixed character set. For example, the EBCDIC CCSID used by the z/OS operating system
itself is 37, but Japanese can use 8482 for SBCS, 16684 for DBCS and 1390 for mixed.
Terminology: Translation is what we do going from language to another, while conversion is
what we do to character strings. CCSIDs (and code pages) are never converted, they are just
definitions. The individual character strings are converted.
9.1.1 Character conversion
9.1.2 Unicode parsing
The variety of CCSIDs made it very difficult for multinational corporations to combine data
from different sources. Unicode has arisen to solve the problem. By storing data in a single
Unicode CCSID, text data from different languages in different countries can be easily
managed. However, to make the transition to Unicode can be difficult and a lot of data
conversion is unavoidable. When storing into and retrieving data from DB2, DB2 will convert
data where necessary. Obviously, it is preferable that no conversion be carried out, because
conversion impacts performance. However, considerable work has been done to improve
conversion performance on zSeries. See 4.7, “Unicode” on page 174.
Character conversion is necessary whenever there is a mismatch between the CCSID of a
source and target string, such as between a host variable and its associated column. Such
conversion support in DB2 has existed since DB2 began to support client/server connections.
In DB2 V2.3 such translations started out between different EBCDIC CCSIDs, as well as
between EBCDIC and ASCII. To perform such character conversion (not involving Unicode),
DB2 uses a translate table which is stored in SYSIBM.SYSSTRINGS. We will refer to such
conversions as SYSSTRINGS conversions, which have particular performance
characteristics.
In DB2 V8, because the catalog has changed to Unicode, data being sent or received by the
application must be verified and possibly converted by the DBM1 address space.
Figure 9-1 depicts a legacy COBOL application running in z/OS using CCSID 37. The
database has been converted to Unicode. 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 into Unicode. The CPU time for these conversions is added to class 2
CPU time.
342 DB2 UDB for z/OS Version 8 Performance Topics