DB2 Universal Database for z/os

Transcription

1 DB2 Uniersal Database for z/os Version 8 Internationalization Guide SC

2

3 DB2 Uniersal Database for z/os Version 8 Internationalization Guide SC

4 Note Before using this information and the product it supports, be sure to read the general information under Notices at the end of this information. First edition (June 2009) This edition applies to Version 8 of IBM DB2 Uniersal Database for z/os (DB2 UDB for z/os), product number 5625-DB2, and to any subsequent releases until otherwise indicated in new editions. Make sure you are using the correct edition for the leel of the product. Specific changes are indicated by a ertical bar to the left of a change. A ertical bar to the left of a figure caption indicates that the figure has changed. Editorial changes that hae no technical significance are not noted. Copyright International Business Machines Corporation 2003, US Goernment Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents About this information Who should read this information DB2 Utilities Suite Terminology and citations i Accessibility features for DB2 UDB for z/os i How to send your comments ii Chapter 1. Introduction to character conersion Character conersion terminology Code pages, CCSIDs, and encoding schemes Code point differences between EBCDIC CCSIDs Unicode UTFs Situations in which character conersion occurs Types of character conersion Expanding conersion Contracting conersion Round-trip conersion Enforced subset conersion Chapter 2. Ensuring that DB2 interprets characters correctly How DB2 performs character conersions Specifying CCSIDs in DB CCSIDs in DB Specifying a CCSID for your application Setting up z/os Unicode Conersion Serices Conersion image DD statements for the CUNJIUTL job Identifying additional case conersions in the z/os conersion image CASE control statement Defining basic character conersions in the z/os conersion image Defining character conersions for Chinese, Japanese, and Korean character sets CONVERSION control statement Loading a new conersion image Adding a single conersion definition to an existing conersion image Deleting conersion tables from your conersion image Replacing conersion tables in your conersion image Defining additional character conersions SYSIBM.SYSSTRINGS catalog table Checking defined character conersions Chapter 3. How DB2 for z/os uses Unicode Chapter 4. Storing Unicode data Creating a Unicode table Estimating the column size for Unicode data Conerting data to Unicode Chapter 5. Application programming with Unicode data and multiple CCSIDs Determining the CCSID of DB2 data Determining the CCSID of a string alue in an SQL statement Multiple CCSIDs in the same SQL statement Retrieing data from the DB2 catalog Differences between Unicode and EBCDIC sorting sequences Copyright IBM Corp. 2003, 2009 iii

6 Performing culturally correct case conersions Locale Conerting between Unicode encoded characters and strings How DB2 handles Unicode supplementary characters Processing Unicode data in COBOL applications How Jaa programs handle character conersion Chapter 6. Debugging database and application problems with Unicode Potential problems when inserting non-unicode data into a Unicode table Specifying that IFCID output should be in Unicode Chapter 7. DB2 utilities Unicode support Chapter 8. EXPLAIN Unicode support Chapter 9. ODBC Unicode support Chapter 10. Tools Unicode support Chapter 11. The International Components for Unicode Information resources for DB2 UDB for z/os and related products How to obtain DB2 information How to use the DB2 library Notices Trademarks Glossary Index i Internationalization Guide

7 About this information This information describes how internationalization and character conersion work in a DB2 UDB for z/os Version 8 (DB2 for z/os) enironment. This information proides basic guidance about internationalization, character conersion, and how Unicode works in a DB2 for z/os enironment. Topics include detailed information about internationalization and character conersion and about how to communicate with other subsystems that use different encoding schemes. This information assumes that your DB2 subsystem is running in Version 8 new-function mode. New functions are aailable only in new-function mode, unless explicitly stated otherwise in the product documentation. A few general exceptions exist for utilities and for optimization. In most cases, new functions are not supported in compatibility mode unless noted. For utilities and optimization, new functions are aailable in compatibility mode unless noted. The new functions that are aailable in compatibility mode and enabling-new-function mode are almost identical, but some new functions are supported to proide easier migration. Exceptions to these general statements are noted in the information. Who should read this information DB2 Utilities Suite This information is primarily intended for people who are responsible for using character conersion in a DB2 for z/os enironment. It assumes that the user is familiar with the following concepts: The basic concepts and facilities of DB2 in the z/os enironment The basic concepts of Structured Query Language (SQL) Important: In this ersion of DB2 UDB for z/os, the DB2 Utilities Suite is aailable as an optional product. You must separately order and purchase a license to such utilities, and discussion of those utility functions in this publication is not intended to otherwise imply that you hae a license to them. The DB2 Utilities Suite is designed to work with the DFSORT program, which you are licensed to use in support of the DB2 utilities een if you do not otherwise license DFSORT for general use. If your primary sort product is not DFSORT, consider the following informational APARs mandatory reading: II14047/II14213: USE OF DFSORT BY DB2 UTILITIES II13495: HOW DFSORT TAKES ADVANTAGE OF 64-BIT REAL ARCHITECTURE These informational APARs are periodically updated. Related information DB2 utilities packaging (Utility Guide) Copyright IBM Corp. 2003, 2009

8 Terminology and citations In this information, DB2 Uniersal Database for z/os is referred to as DB2 UDB for z/os. In cases where the context makes the meaning clear, DB2 UDB for z/os is referred to as DB2. When this information refers to titles of books in this library, a short title is used. (For example, See DB2 SQL Reference is a citation to IBM DB2 Uniersal Database for z/os SQL Reference.) When referring to a DB2 product other than DB2 UDB for z/os, this information uses the product s full name to aoid ambiguity. The following terms are used as indicated: DB2 Represents either the DB2 licensed program or a particular DB2 subsystem. OMEGAMON Refers to any of the following products: IBM Tioli OMEGAMON XE for DB2 Performance Expert on z/os IBM Tioli OMEGAMON XE for DB2 Performance Monitor on z/os IBM DB2 Performance Expert for Multiplatforms and Workgroups IBM DB2 Buffer Pool Analyzer for z/os C, C++, and C language Represent the C or C++ programming language. CICS Represents CICS Transaction Serer for z/os. IMS Represents the IMS Database Manager or IMS Transaction Manager. MVS Represents the MVS element of the z/os operating system, which is equialent to the Base Control Program (BCP) component of the z/os operating system. RACF Represents the functions that are proided by the RACF component of the z/os Security Serer. Accessibility features for DB2 UDB for z/os Accessibility features help a user who has a physical disability, such as restricted mobility or limited ision, to use information technology products successfully. Accessibility features The following list includes the major accessibility features in z/os products, including DB2 UDB for z/os. These features support: Keyboard-only operation. Interfaces that are commonly used by screen readers and screen magnifiers. Customization of display attributes such as color, contrast, and font size Tip: The Information Management Software for z/os Solutions Information Center (which includes information for DB2 UDB for z/os) and its related publications are accessibility-enabled for the IBM Home Page Reader. You can operate all features using the keyboard instead of the mouse. Keyboard naigation i Internationalization Guide You can access DB2 UDB for z/os ISPF panel functions by using a keyboard or keyboard shortcut keys.

9 For information about naigating the DB2 UDB for z/os ISPF panels using TSO/E or ISPF, refer to the z/os TSO/E Primer, the z/os TSO/E User s Guide, and the z/os ISPF User s Guide. These guides describe how to naigate each interface, including the use of keyboard shortcuts or function keys (PF keys). Each guide includes the default settings for the PF keys and explains how to modify their functions. Related accessibility information Online documentation for DB2 UDB for z/os is aailable in the Information Management Software for z/os Solutions Information Center, which is aailable at the following Web site: IBM and accessibility How to send your comments See the IBM Accessibility Center at for more information about the commitment that IBM has to accessibility. Your feedback helps IBM to proide quality information. Please send any comments that you hae about this book or other DB2 UDB for z/os documentation. You can use the following methods to proide comments: Send your comments by to db2zinfo@us.ibm.com and include the name of the product, the ersion number of the product, and the number of the book. If you are commenting on specific text, please list the location of the text (for example, a chapter and section title or a help topic title). You can send comments from the Web. Visit the DB2 for z/os - Technical Resources Web site at: This Web site has an online reader comment form that you can use to send comments. You can also send comments by using the feedback link at the footer of each page in the Information Management Software for z/os Solutions Information Center at About this information ii

10 iii Internationalization Guide

11 Chapter 1. Introduction to character conersion All characters within a string are represented by a common encoding representation. In some cases, these characters need to be conerted to a different encoding representation. This process of conersion is known as character conersion. When required, character conersion is automatic and transparent to the application. Character conersion terminology To understand the concept of character conersion, you should know the meaning of some basic related terms. The following terms are related to character conersion: ASCII Acronym for American Standard Code for Information Interchange, an encoding scheme that is used to represent characters. In this information, the term ASCII is used to refer to IBM-PC data or ISO 8-bit data. CCSID set The single byte CCSID alue (SBCS), mixed CCSID alue and double byte CCSID alue (DBCS) that is associated with a particular encoding scheme. character set A defined set of characters, in which a character is the smallest component of written language that has semantic alue. code page A specification of code points from a defined encoding scheme for each character in a set or in a collection of character sets. Within a code page, a code point can hae only one specific meaning. code point A unique bit pattern that represents a character. coded character set A set of unambiguous rules that establishes a character set and the one-to-one relationships between the characters of the set and their coded representations. A coded character set is the assignment of each character in a character set to a unique numeric code alue. coded character set identifier (CCSID) A 16-bit number that identifies a specific set of encoding scheme identifiers, character set identifiers, code page identifiers, and additional coding-related information. A CCSID is an attribute of strings, just as length is an attribute of strings. All alues of the same string column hae the same CCSID. A CCSID may contain one or more code pages. EBCDIC Acronym for Extended Binary-Coded Decimal Interchange Code, a group of coded character sets that consists of 8-bit coded characters. EBCDIC coded character sets map characters onto code points. Each code point consists of 8 bits. encoding scheme A set of rules that is used to represent character data. All string data that is stored in a table must use the same encoding scheme, and all tables within Copyright IBM Corp. 2003,

12 a table space must use the same encoding scheme, except for global temporary tables, declared temporary tables, and work file table spaces. An encoding scheme only describes the type of encoding; it does not specify code points or a code page. Examples of encoding schemes include ASCII, EBCDIC, and Unicode. substitution character A unique character that is substituted during character conersion for any characters in the source encoding representation that do not hae a match in the target encoding representation. Unicode An international character code for information processing that is designed to encode all characters that are used for written communication in a simple and consistent manner. The Unicode character encoding was originally established as a fixed-width, 16-bit encoding to proide enough code points for all the scripts and technical symbols in common usage around the world, plus some ancient scripts. Code pages, CCSIDs, and encoding schemes All character data has an associated CCSID, which identifies a particular code page and encoding scheme. The CCSID alue affects whether and how character data is conerted in a gien situation. Computers store only numbers. They store letters and other characters by assigning a number to them. This number representation of a character is called a code point. For example, the letter A can be stored as the hexadecimal alue X C1. A set of code points for a particular character set, such as US English characters, is called a code page. A coded character set identifier (CCSID) is a number that identifies a particular code page. For example, the US-English code page has a CCSID of 037. In some cases, a CCSID identifies more than one pair of character sets and code pages. DB2 uses CCSIDs to describe data. An encoding scheme is a collection of the code pages for arious languages that are used on a particular computing platform. For example, the EBCDIC encoding scheme is typically used on z/os and iseries (AS/400 ). The ASCII encoding scheme is used on Intel-based systems, such as Windows, and UNIX-based systems. These encoding schemes were inented to standardize the encoding of character sets. Each encoding scheme defines a set of rules for representing character data. A number of code pages are defined according to the rules of each encoding scheme. You can compare data in compatible encoding schemes. Related concepts CCSIDs in DB2 on page 12 Related information IBM code pages Character Data Representation Architecture Reference 2 Internationalization Guide

13 Code point differences between EBCDIC CCSIDs If you need to conert between different EBCDIC CCSIDs, be aware that seeral hexadecimal code points map to different characters depending on the CCSID. The following table shows the difference in code points between EBCDIC CCSID 37 and EBCDIC CCSID 500. Table 1. Code point differences between EBCDIC CCSID 37 and EBCDIC CCSID 500 Character Code point CCSID 37 CCSID 500 4A cent sign left bracket 4F logical or exclamation point 5A exclamation point right bracket 5F logical not circumflex accent B0 circumflex accent cent sign BA left bracket logical not BB right bracket logical or The following table shows the difference in code points between EBCDIC CCSID 37 and EBCDIC CCSID Table 2. Code point differences between EBCDIC CCSID 37 and EBCDIC CCSID 1047 Character Code point CCSID 37 CCSID F logical not circumflex accent AD capital Y with accent acute left square bracket B0 circumflex accent logical not BA left square bracket capital Y with accent acute BB right square bracket umlaut/diaeresis BD umlaut/diaeresis right square bracket The following table shows the difference in code points between EBCDIC CCSID 500 and EBCDIC CCSID Table 3. Code point differences between EBCDIC CCSID 500 and EBCDIC CCSID 1047 Character Code point CCSID 500 CCSID A left bracket cent sign 4F exclamation point logical or 5A right bracket exclamation point AD capital Y with accent left bracket B0 cent sign logical not BA logical not capital Y with accent BB logical or umlaut/diaeresis BD umlaut/diaeresis right bracket Chapter 1. Introduction to character conersion 3

14 Unicode Unicode is an encoding scheme that enables systems to handle global data by proiding a single standard that includes eery character in the world. In this era of globalization, the ability for systems to handle data from around the world is paramount. Howeer, workstations and serers might use different code pages, depending on the country in which they reside. In effect, they are speaking different languages, which makes communication difficult. Unicode aoids these communication problems by haing a single standard that has a code point mapping for eery character in the world. Before Unicode was defined, the existing encoding schemes had the following limitations: No single encoding was adequate for all letters and symbols aailable. For example, most encoding schemes hae one code page to map Japanese characters and another code page to map German characters. Encoding schemes often encode data in different positions. For example, the letter A is encoded as X C1 in EBCDIC, but X 41 in ASCII. Consequently, character conersions occurred frequently, which raised the risk of potential communication errors between systems. Unicode enables data to be transferred between many different systems without conersion and thus limits the risk of data corruption. Howeer, if you also use other encoding schemes, Unicode data does sometimes need to be conerted to those encoding schemes. Related information DB2 for z/os Unicode QuickPlace forum Unicode Character Code Charts Unicode Consortium UTFs Unicode transformation formats (UTFs) are forms of Unicode encoding that were deised by the Unicode Consortium to ensure that systems can communicate efficiently. Each UTF is designed for different processing objecties. All UTFs map the full Unicode character repertoire, or set of characters. 4 Internationalization Guide The different UTFs are as follows: UTF-8 UTF-8 is designed to be an Internet encoding transformation format. Each character is encoded as 1 to 4 bytes. The first 128 code points from X 00 to X 7F are the same as the first 128 code points in ASCII. The characters A-Z, a-z, 0-9, and some special characters are encoded with a 1-byte code unit in UTF-8. DB2 uses UTF-8 to encode data in the following ways: DB2 encodes data in CHAR, VARCHAR, and CLOB columns in UTF-8. DB2 parses and precompiles data in UTF-8. The DB2 catalog is encoded in UTF-8. UTF-16 UTF-16 is a transformation format that is based on 16-bit code units. Some characters that are encoded with a 1-byte code unit in UTF-8 are encoded with a 2-byte code unit in UTF-16. Most Chinese, Japanese, and Korean characters are encoded with a 2-byte code unit in UTF-16.

15 Characters that are surrogate or supplementary characters use 4 bytes and thus require additional storage. These characters can also be stored in UTF-8 or UTF-32, but because they always require 4 bytes of storage, neither of these formats proide any space saings. DB2 uses UTF-16 to encode data in GRAPHIC, VARGRAPHIC, and DBCLOB columns. UTF-32 UTF-32 encodes each character as 4 bytes. DB2 does not use UTF-32. Related information Unicode Consortium Situations in which character conersion occurs Character conersion is the process of conerting data from one CCSID to another. This process can occur when data is transferred between a remote and local system or when data is being manipulated on the same local system. Character conersion is more likely to occur when you are accessing data remotely, because this situation often inoles different platforms and encoding schemes. Consider the following data that is likely to be exchanged in a client/serer enironment: The alues of host ariables that are sent from the requester to the current serer, such as SELECT predicates or INSERT column alues The alues of result columns that are sent from the current serer back to the requester In either case, if the string data has a different representation at the sending and receiing systems, conersion might be required. Conersion can also occur during string operations on the same system, as in the following examples: A DECLARE VARIABLE statement specifies an oerriding CCSID. The SQLDA specifies an oerriding CCSID for a string column. An SQL statement refers to data that is defined with different CCSIDs. An SBCS string is assigned to an MBCS column or host ariable. For example, if you hae set MIXED=NO in DSNHDECP and you use SPUFI to insert data into a UTF-8 table, which is MIXED=YES by default, a conersion occurs. The alue of the ENCODING bind option (for static SQL statements) or the CURRENT APPLICATION ENCODING SCHEME special register (for dynamic SQL statements) is different than the encoding scheme of the data that is being retrieed. An ASCII application proides SQL statement text to DB2 in a PREPARE statement. DB2 conerts the statement text to Unicode for parsing. Related reference BIND and REBIND options (DB2 Command Reference) DECLARE VARIABLE (DB2 SQL Reference) Chapter 1. Introduction to character conersion 5

16 Types of character conersion Character conersion between two CCSIDs can impact your subsystem. The effect depends on the type of conersion that DB2 uses. For example, expanding conersions and contracting conersions might affect the length of the conerted string. Enforced subset conersions and round-trip conersions might affect the contents of the string. For characters that don t exist in the target CCSID, DB2 uses a combination of round-trip conersions and enforced subset conersions. When conerting from ASCII or EBCDIC to Unicode, DB2 uses round-trip conersions. When conerting from Unicode to ASCII or EBCDIC, DB2 uses enforced subset conersions. Expanding conersion An expanding conersion occurs when the length of the conerted string is greater than that of the source string. For example, an expanding conersion occurs when an ASCII mixed data string that contains DBCS characters is conerted to an EBCDIC mixed data string, because of the addition of shift-out and shift-in control characters. Expanding conersions can also occur when string data is conerted to or from Unicode. Expanding conersions might cause problems with fixed-length ariables. For example, an error occurs when a fixed-length host ariable needs to be conerted from ASCII mixed data to EBCDIC mixed data, because the conersion is an expanding conersion. The solution is to use a arying-length string ariable with a maximum length that is sufficient to contain the expansion. To determine the result length of a CCSID conersion, use the following table. Table 4. Result length of CCSID conersion, where X represents LENGTH(string in bytes) To CCSID EBCDIC ASCII Unicode From CCSID SBCS Mixed DBCS SBCS Mixed DBCS SBCS UTF-8 UTF-16 SBCS X X X*2 1 X X X*2 1 X 1 X*3 X*2 EBCDIC Mixed X X X*2 1 X X X*2 1 X 1 X*3 X*2 DBCS X*0.5 1 X+2 X X*0.5 1 X X X*0.5 X*1.5 X SBCS X X X*2 1 X X X*2 1 X 1 X*3 X*2 ASCII Mixed X X*1.8 X*2 1 X X X*2 1 X 1 X*3 X*2 DBCS X*0.5 1 X+2 X X*0.5 1 X X X*0.5 X*1.5 X SBCS X X X*2 X X X*2 X X X*2 Unicode UTF-8 X X*1.25 X X X X X X X*2 UTF-16 X*0.5 X+2 X X*0.5 X X X*0.5 X*1.5 X Note: 1. Because of the high probability of data loss, IBM does not proide conersion tables for this combination of two CCSIDs and data subtypes. Example: In CCSID 819, the character Å is represented by the code point X C5. In CCSID 1208, this character is represented by X C385. The conersion of the character Å from CCSID 819 to CCSID 1208 is an expanding conersion. 6 Internationalization Guide

17 Contracting conersion A contracting conersion occurs when the length of the conerted string is smaller than that of the source string. For example, a contracting conersion occurs when an EBCDIC mixed data string that contains DBCS characters is conerted to ASCII mixed data due to the remoal of shift characters. Contracting conersions can also occur when string data is conerted to or from Unicode. Example: In CCSID 1208, the character Å is represented by the code point X C385. In CCSID 819, this character is represented by X C5. The conersion of the character Å from CCSID 1208 to CCSID 819 is a contracting conersion. Round-trip conersion A round-trip conersion preseres characters that exist in the source CCSID but do not exist in the target CCSID. Round-trip conersions between two CCSIDs ensure that all characters that make the round trip arrie as they were originally, een if the receiing CCSID does not support a gien character. Example: In CCSID 1252, the trademark symbol is code point X 99. In CCSID 37, this code point does not exist. During character conersion from CCSID 1252 to CCSID 37, the trademark symbol is conerted to a control character, X 39. If you use SPUFI to select the data, the data displays as the unprintable character that you specified in your emulator, which is generally a quotation mark ( ) or a period (.). If you issue a SELECT HEX(column) statement, the data displays as X 39, which is the DEL control character. When DB2 uses a round-trip conersion to conert this character back to CCSID 1252, the trademark symbol is presered as code point X 99. DB2 uses round-trip conersions when conerting from ASCII or EBCDIC to Unicode to handle characters that don t exist in the target CCSID. Enforced subset conersion An enforced subset conersion occurs when a character in the source CCSID does not hae a code point in the target CCSID. In this case, the character is conerted to a single substitution character. Example: In CCSID 1252, the trademark symbol is represented by the code point X 99. In CCSID 37, this code point does not exist. During an enforced subset character conersion to CCSID 37, this code point is conerted to the substitution character X 3F. When the code point is conerted back to CCSID 1252, the character remains a substitution character and is represented by the code point X 1A. DB2 uses enforced subset conersions when conerting from Unicode to ASCII or EBCDIC to handle characters that don t exist in the target CCSID. Chapter 1. Introduction to character conersion 7

18 8 Internationalization Guide

19 Chapter 2. Ensuring that DB2 interprets characters correctly To ensure that DB2 interprets characters correctly: 1. Ensure that you specify the correct CCSIDs for your system, objects, and applications in DB2. 2. Set up z/os Unicode Conersion Serices. 3. Optional: Define any additional character conersions. Character conersions are already defined in the following two places: The DB2 catalog table SYSIBM.SYSSTRINGS This table contains character conersion definitions from IBM. You might hae also added your own. The conersion image in z/os Unicode Conersion Serices. You configured this image when you set up z/os Unicode Conersion Serices. Some of the definitions in this image were also proided by IBM. Howeer, you might need to define additional conersions. If you aren t sure if a particular character conersion is defined to DB2, check your character conersion definitions and add the ones that you need. How DB2 performs character conersions When character conersions are needed, DB2 performs most of these conersions automatically based on the CCSIDs of the source and target data. You need to identify alid conersion definitions for source and target CCSIDs to DB2. Some of these definitions are predefined for you. DB2 for z/os uses the following resources in the order listed to perform the conersion from one CCSID to another: 1. The DB2 catalog table SYSIBM.SYSSTRINGS Each row in the catalog table describes a conersion from one coded character set to another. IBM supplies some of the rows. You can also add your own rows. 2. z/os Unicode Conersion Serices z/os Unicode Conersion Serices uses the conersion definitions in a conersion image data set. Thus, any conersions defined in SYSIBM.SYSTRINGS oerride the conersions that are defined in z/os Unicode Conersion Serices. If SYSIBM.SYSSTRINGS does not define a conersion, DB2 uses z/os Unicode Conersion Serices. If neither DB2 nor z/os Unicode Conersion Serices proides a conersion for a certain combination of source and target CCSIDs, DB2 issues an error message. To correct the problem, add a definition for the conersion to either SYSIBM.SYSSTRINGS or z/os Unicode Conersion Serices. Related concepts SYSIBM.SYSSTRINGS catalog table on page 29 Related tasks Setting up z/os Unicode Conersion Serices on page 15 Related information Copyright IBM Corp. 2003,

20 Specifying CCSIDs in DB2 z/os Support for Unicode: Using Conersion Serices (z/os Internet Library) You must tell DB2 the correct CCSIDs to use for your data to ensure that DB2 correctly interprets your data and performs any character conersions accurately. You need to identify CCSIDs for the subsystem, any DB2 objects, and your applications. To specify CCSIDs in DB2: Specify CCSIDs for each item by performing the following actions: Subsystem Recommendation: Neer change CCSIDs on an existing DB2 subsystem without specific guidance from IBM Software Support. When you install or migrate DB2, use installation panel DSNTIPF or job DSNTIJUZ to specify the correct CCSID set for the subsystem. You must specify alid, non-zero CCSIDs for single-byte character sets (SBCS) for both EBCDIC and ASCII. For Chinese, Japanese, and Korean, you must also specify alid, non-zero CCSIDs for multibyte character sets (MBCS) and double-byte character sets (DBCS). If you set the alues by using the installation panel DSNTIPF, you need to specify only one alue. If you specify these alues in job DSNTIJUZ, you need specify all of the alues. These CCSIDs are stored in DSNHDECP. If your subsystem is already installed or migrated, you can check the CCSID alues in DSNDECP, but do not make changes. If you suspect that the specified CCSIDs are incorrect or need to change them, contact IBM Software Support. If you use installation panel DSNTIPF, specify alues for the following fields: ASCII CCSID Specifies the default CCSID for ASCII-encoded character data that is stored in your DB2 subsystem or data sharing group. The correct ASCII CCSID identifies the coded character set that is supported by remote applications, such as DB2 QMF for Windows, at your site. This system default ASCII CCSID alue is stored in the DECP alues ASCCSID (for single-byte data), AMCCSID (for mixed data), AGCCSID (for graphic data). EBCDIC CCSID Specifies the default CCSID for EBCDIC-encoded character data that is stored in your DB2 subsystem or data sharing system. The correct EBCDIC CCSID identifies the coded character set that is supported by the I/O deices, 3270 terminal emulators, and local applications such as IMS and DB2 QMF. This system default EBCDIC CCSID alue is stored in the DECP alues SCCSID (for single-byte data), MCCSID (for mixed data), GCCSID (for graphic data). 10 Internationalization Guide

21 UNICODE CCSID Specifies the default CCSID for Unicode character data that is stored in your DB2 subsystem or data sharing system. This field is pre-filled with the default alue of 1208, which is the CCSID for UTF-8. Recommendation: Do not change this default alue. Otherwise, data could be corrupted. During processing, DB2 chooses the appropriate CCSIDs for double-byte and single-byte alues. DB2 uses the following Unicode CCSIDs: Table 5. Unicode CCSIDs that DB2 uses Data for which DB2 uses the Unicode CCSID CCSID 367 Single-byte character set (SBCS) data UTF to which the CCSID corresponds the first 128 code points for UTF MBCS data UTF a Double-byte character set UTF-16 (DBCS) data Notes: 1. CCSID 1200 supports the same character repertoire, or group of characters, as CCSID This system default Unicode CCSID alue is stored in the DECP alues USCCSID (for single-byte data), UMCCSID (for mixed data), UGCCSID (for graphic data). Specifying the correct CCSIDs for the subsystem ensures that DB2 performs appropriate character conersions when distributed systems access DB2. All CCSIDs in the DSNHDECP module must be alid. During startup processing, if DB2 detects inalid CCSID alues, DB2 issues a message and terminates. Objects Specify which default system CCSID (ASCII, EBCDIC, or Unicode) DB2 is to use for objects by using the DEF ENCODING SCHEME field on installation panel DSNTIPF. System CCSIDs are stored in DSNDECP. To oerride this default alue for a particular object, use the CCSID clause in the CREATE statement to specify a different system CCSID (for ASCII, EBCDIC, or Unicode). You can specify the CCSID clause for any of the following objects: Database Table space Table Procedure or function Applications Follow the instructions for specifying a CCSID for your application. Related tasks Creating a Unicode table on page 35 Related reference Chapter 2. Ensuring that DB2 interprets characters correctly 11

22 Application programming defaults panel 1: DSNTIPF (DB2 installation) CCSIDs in DB2 The IBM character data representation architecture (CDRA) handles the differences in string representation and encoding by using CCSIDs to label the arious character representation schemes. CDRA is an IBM architecture that defines a set of identifiers, serices, supporting resources, and conentions to achiee consistent representation, processing, and interchange of graphic character data in data processing enironments. CCSID is one of seeral identifiers for graphic-character data representation that are defined by the CDRA. A CCSID is a 16-bit number that identifies an implementation of a code page at a particular point in time. The coded character set defines how bit configurations are mapped for character data. IBM maintains a repository list of all CCSIDs that are defined by CDRA. In DB2, all character data is associated with a CCSID. When you install DB2, you must specify a CCSID for ASCII, EBCDIC, and Unicode DB2 character data. Character conersion is described in terms of CCSIDs of the source and of the target. Related information Coded character sets and related resources Character Data Representation Architecture Reference Specifying a CCSID for your application The CCSID that you specify for your application affects how DB2 interprets the SQL statements, host ariable alues, and input data. If the CCSID alue is incorrect, data corruption can occur. If you do not specify a CCSID for your application, DB2 uses the system default application encoding scheme. The system default application encoding scheme is the CCSID that DB2 uses for applications if you do not explicitly specify another CCSID. You specify the system default application encoding scheme in the APPLICATION ENCODING field on installation panel DSNTIPF when you install or migrate DB2. This alue is stored in the APPENSCH DECP alue. The alue can be EBCDIC, ASCII, Unicode, or a alid CCSID. If the alue is EBCDIC, ASCII, or Unicode, DB2 uses the system default CCSID for that encoding scheme. For more information about the system default CCSID alues for EBCDIC, ASCII, and Unicode and where they are set, see the information about specifying CCSIDs in DB2. Recommendation: Neer change the following system CCSIDs on an existing DB2 subsystem without specific guidance from IBM Software Support: The default encoding scheme format (ENSCHEME DECP alue) The system default application encoding scheme (APPENSCH DECP alue) The system default CCSID for EBCDIC data (SCCSID, MCCSID, and GCCSID DECP alues) The system default CCSID for ASCII data (ASCCSID, AMCCSID, AGCCSID DECP alues) The system default CCSID for Unicode data (USCCSID, UMCCSID, and UGCCSID DECP alues) 12 Internationalization Guide

23 DB2 returns data to the application in whateer CCSID the application uses. To specify a CCSID for your application: Specify alues for one or more of the following items: CCSID SQL processing option Use this option when you prepare your application to specify the CCSID in which the source program is written. This alue ensures that the DB2 precompiler or coprocessor correctly parses the SQL statements and literal alues at precompile time. The default alue is the system EBCDIC CCSID. For more information about the system EBCDIC CCSID, see the information about specifying CCSIDs in DB2. COBOL applications hae an associated CCSID for the COBOL source. The default CCSID is specified when the compiler is installed and can usually be oerridden. Howeer, when COBOL is installed, an option exists to indicate that the default CCSID can not be oerridden. Restriction: The COBOL, PL/I, and C/C++ compilers do not support Unicode source. ENCODING bind option Use this option when you bind your application to specify the CCSID for static SQL statements. This alue does not apply to dynamic SQL statements. This alue affects how DB2 interprets host ariables at run time. The alue can be EBCDIC, ASCII, Unicode, or a alid CCSID. If the alue is EBCDIC, ASCII, or Unicode, DB2 uses the system default CCSID for that encoding scheme. For more information about the system default CCSID alues for EBCDIC, ASCII, and Unicode and where they are set, see the information about specifying CCSIDs in DB2. The default alue is the system default application encoding scheme. Restriction: DB2 ignores the ENCODING bind option when packages are executed remotely. If you use DRDA, you do not need to specify this bind option, because DRDA handles all CCSID conersions. CURRENT APPLICATION ENCODING SCHEME special register Use this special register to specify the CCSID for dynamic SQL statements. This alue does not apply to static SQL statements. You can set the alue of this special register by using the SET CURRENT APPLICATION ENCODING SCHEME statement in your application program. The alue can be EBCDIC, ASCII, Unicode, or a alid CCSID. If the alue is EBCDIC, ASCII, or Unicode, DB2 uses the system default CCSID for that encoding scheme. For more information about the system default CCSID alues for EBCDIC, ASCII, and Unicode and where they are set, see the information about specifying CCSIDs in DB2. The default alue is the alue of the ENCODING bind option or, for natie SQL procedures, the APPLICATION ENCODING SCHEME option of the CREATE PROCEDURE or ALTER PROCEDURE statement. If you do not specify these alues, the default alue is the system default application encoding scheme. Chapter 2. Ensuring that DB2 interprets characters correctly 13

24 DECLARE VARIABLE statement with the CCSID option Use this statement in your application to define a CCSID for a particular host ariable. This alue oerrides the CURRENT APPLICATION ENCODING SCHEME special register alue and the ENCODING bind option. The alue for the CCSID option can be EBCDIC, ASCII, Unicode, or a alid CCSID. If the alue is EBCDIC, ASCII, or Unicode, DB2 uses the system default CCSID for that encoding scheme. For more information about the system default CCSID alues for EBCDIC, ASCII, and Unicode and where they are set, see the information about specifying CCSIDs in DB2 The default alue is the system EBCDIC CCSID. For COBOL applications, also consider the other settings that are discussed in the information about controlling the CCSID for COBOL host ariables. If you do not specify any of these alues, DB2 uses the system default application encoding scheme. Example of ENCODING(UNICODE) bind option: Assume that the package MY_PACK is bound with the option ENCODING(UNICODE). DB2 assumes that all character input and output host ariables for static SQL statements are encoded using CCSID DB2 assumes that all graphic input and output host ariables for static SQL statements are encoded using CCSID The initial alue for the CURRENT APPLICATION ENCODING SCHEME special register is Example of setting a CCSID for applications for remote users: Assume that your DB2 for z/os subsystem is located in the United States and has an application encoding scheme associated with eery plan and package. You hae users around the world that connect to this subsystem. The users that use DRDA do not need to use the ENCODING bind option to handle CCSID conersions because DRDA handles all conersions. The users that use 3270 terminal emulators need to set up their emulators to use a CCSID that corresponds to the country in which they reside. In this example, assume that the CCSID of one of those terminal emulators is 285. You need to bind the plans or packages that that client uses with ENCODING(285). The following figure illustrates this scenario. 14 Internationalization Guide

25 3270 Client - CCSID 285 DB2 V8 serer EBCDIC CCSID Client - CCSID 37 DB2 UDB DRDA - CCSID Client - CCSID 284 DRDA - CCSID Client - CCSID 273 Figure 1. Example of setting a CCSID for applications for remote users Example of ensuring that remote users access the correct ersion of the SPUFI application according to their terminal CCSID: Suppose that you want to preent users in the U.K. from using the U.S. ersion of SPUFI. Instead of granting the EXECUTE priilege for the SPUFI packages to public, restrict access to only those users in the U.S. Then, create additional SPUFI packages and plans that specify the appropriate terminal CCSID encoding for the U.K. Authorize the U.K. users to use only this ersion of SPUFI. Related reference BIND and REBIND options (DB2 Command Reference) Application programming defaults panel 1: DSNTIPF (DB2 installation) DECLARE VARIABLE (DB2 SQL Reference) SET CURRENT APPLICATION ENCODING SCHEME (DB2 SQL Reference) Setting up z/os Unicode Conersion Serices DB2 uses z/os Unicode Conersion Serices to perform character and case conersions. If you use z/os 1.6 or earlier, you must set up these serices. If you use z/os 1.7 or later, you can use Unicode on Demand, which does not require any set up. You must hae Unicode Conersion Serices installed on z/os 1.2 or later. z/os Unicode Conersion Serices requires an actie conersion image to define how to handle arious conersions. The conersion image tells z/os Unicode Conersion Serices which conersion tables to load and use for character and case conersions. This task explains how to set up such a conersion image. Chapter 2. Ensuring that DB2 interprets characters correctly 15

26 You do not need to perform this task if you hae z/os 1.7. Howeer, you might still choose to perform this task if you want to customize your conersion image. As of z/os 1.7, Unicode support was enhanced so that you no longer need to manually set up conersion tables for Unicode Conersion Serices. This enhancement is known colloquially as Unicode On Demand. All tables that are needed for character conersion, case conersion, normalization, and collation serices are loaded automatically. Howeer, you must still ensure that the SYS1.SCUNTBL and SYS1.SCUNLOCL data sets are cataloged. Do not change the names of these data sets; the high-leel qualifier needs to be SYS1. To set up z/os Unicode Conersion Serices: 1. Customize the JOB statements for the jobs in high-leel-qualifier.scunjcl by either manually updating the statements or using the REXX execs CUNRUCST and CUNRUALL in high-leel-qualifier.scunrexx. All of the jobs in high-leel-qualifier.scunjcl are shipped by IBM with placeholders for alues in the JOB statement. For example, CUNJIUTL has the following JOB statement: //$JOBPREF$$JOBNAME$ JOB ($ACCOUNT$),'$USER$', // NOTIFY=$NOTIFY$,MSGCLASS=$MC$,MSGLEVEL=$ML$, // TIME=$TI$,CLASS=$CL$,REGION=$REGION0M$ Use the REXX exec CUNRUCST to specify your customized alues and run the REXX exec CUNRUALL to supply those alues to all the JCL images. 2. Optional: Customize how messages from Unicode Conersion Serices are displayed on your system by using the MVS Message Serice. You can make the following customizations: Display the messages in Japanese. Display the messages with modified date and time formats. 3. Set up the conersion image by editing member CUNJIUTL in high-leel-qualifier.scunjcl. CUNJIUTL contains code that is similar to the following example: //CUNMIUTL EXEC PGM=CUNMIUTL //SYSPRINT DD SYSOUT=* //TABIN DD DISP=SHR,DSN=hlq.SCUNTBL //SYSIMG DD DSN=hlq.IMAGES(CUNIMG00),DISP=SHR //SYSIN DD * /******************************************** * INPUT STATEMENTS FOR THE IMAGE GENERATOR * ********************************************/ CASE NORMAL; /* ENABLE TOUPPER AND TOLOWER */ CONVERSION 1047,850; /* EBCDIC -> ASCII */ CONVERSION 850,1047; /* ASCII -> EBCDIC */ /* Make the following changes to CUNJIUTL: a. Customize the SYSPRINT, TABIN, and SYSIMG DD statements so that they specify the appropriate alues for your system. b. If both of the following situations are true, identify additional case conersions by adding CASE control statements: You want to use the UPPER or LOWER built-in functions to process Unicode and ASCII data. You want to perform case conersions on characters other than A-Z and a-z. Refer to the instructions for identifying additional case conersions in the z/os conersion image. 16 Internationalization Guide

27 c. Define the following character conersions by adding CONVERSION control statements. The basic character conersions that DB2 needs. Refer to the instructions for defining basic character conersions in the z/os conersion image. If you use Chinese, Japanese, or Korean character sets, additional conersions for those character sets. Refer to the instructions for defining character conersions for Chinese, Japanese, and Korean character sets Any other conersions that you need that are not already defined in SYSIBM.SYSTRINGS, such as conersions that you need to load or unload data and conersions that you need to support your applications ENCODING bind option, DECLARE VARIABLE statements, or CCSID oerrides. 4. Load the conersion image by submitting the batch job in the CUNJIUTL member. The image generator creates your conersion image on disk. Check the output in the data set that is identified by the SYSPRINT DD statement, which is SYSOUT unless you changed it. If you receie a return code other than zero, refer to the z/os documentation for using the image generator listing in the Unicode Conersion Serices information. 5. If you are not using Unicode On Demand, which is aailable in z/os 1.7 or later, copy the conersion image to SYS1.PARMLIB or any other data set in the logical PARMLIB concatenation. For example, you can copy high-leel-qualifier.images(cunimg00) to SYS1.PARMLIB(CUNIMG00). 6. Calculate the irtual storage that is needed for the conersion image. The minimum required storage is the size of the image plus one page. You can find the size of the image in the CUN1017I message in the SYSPRINT log. For example: CUN1017I GENERATED IMAGE SIZE 291 PAGES Create the PARMLIB member CUNUNIxx for actiating a conersion enironment. Create this member in any data set in the logical PARMLIB concatenation, such as SYS1.PARMLIB. xx can be any two alphanumeric characters (A-Z, #, and $). Include the following information in CUNUNIxx: Specify the required irtual storage that you calculated in the preious step with the REALSTORAGE parameter. The REALSTORAGE parameter protects the system against main storage shortage that is caused by loading a conersion image that exceeds the amount of aailable storage. Alternatiely, you can specify a REALSTORAGE alue of zero to indicate that unlimited storage is aailable. In this case, your system uses a alue of pages. Specify the location of the conersion image with the IMAGE parameter. For example, you can create PARMLIB member SYS1.PARMLIB(CUNUNI00) that contains the following information: REALSTORAGE 292; IMAGE CUNIMG00; The REALSTORAGE parameter indicates that 292 pages of real storage are required for your conersion image. The IMAGE parameter indicates that the system is to look in member CUNIMG00 in SYS1.PARMLIB (or a data set in the logical concatenation) for the conersion image. 8. Make the following changes to SYS1.PARMLIB (IEASYSxx): Chapter 2. Ensuring that DB2 interprets characters correctly 17