Revision marks indicate text that has been added or changed. A vertical bar ( | ) indicates information that was added or changed for Version 8.2 FixPak 4 (equivalent to Version 8.1 FixPak 11).
You might need to install a DB2(R) product that is at a different level than the version of another DB2(R) product that is currently installed on the computer. DB2 products are required to be at the same level.
If the product you are installing is at a more recent level than the version of other DB2 products installed on the same computer, you will need to update your existing DB2 products to the more recent level. For example, if you are installing DB2 Connect(TM) for iSeries(TM) at a level of Fixpak 10 and your other DB2 products are at a level of Fixpak 9, you need to apply Fixpak 10 to currently installed DB2 products before installing DB2 Connect(TM) for iSeries(TM) at a level of Fixpak 10.
Conversely, if you are installing a product on a computer that has a more recent version of a DB2 product installed, there are some guidelines to follow:
db2licm -a filenamewhere filename is the name of the license file, which can be found on your original media under the db2\license directory. You can also add this license to the db2\license directory of the fixpak, and the license will be installed by the installation.
Before you install an extra product or component, you must stop the following items:
The instances and DAS that must be stopped are the ones that belong to the DB2 installation where the extra DB2 product or component will be installed.
Refer to the FixPak Readme for further instructions.
If the DB2 DAS does not exist on the current system, and the extra product or component requires or supports the DB2 DAS, db2setup will set up the DB2 DAS during the installation. On some platforms, you may experience errors during the DB2 DAS creation with db2setup. These errors are expected and can be ignored.
The db2setup program can be found on the DB2 product CD or image for the extra product or component you are installing.
Refer to the Command Reference guide and the Installation and Configuration Supplement for detailed information about using db2setup.
The db2_install script can be found on the DB2 product CD or image for the extra product or component you are installing.
Refer to the Installation and Configuration Supplement for detailed information about using the db2_install script.
Refer to the Installation and Configuration Supplement for detailed information about using the system installer.
To illustrate this scenario, assume the following conditions:
As a post-installation step, you must reapply regular FixPak 10.
The package db2cliv81 is already installed on the system. Patch nnnnnnn-nnn installation terminated abnormally. To reinstall this patch, deinstall it first before attempting to reinstall it.This error occurs because the db2cliv81 in the system is already on the level same as the fixpak level being installed. You can ignore this kind of error. Use the system installer to confirm that the DB2 component or package is indeed at the same fixpak level being installed.
If you create a database with DB2 Universal Database Version 8.2, you cannot use that database at a Version 8.1 level. That database can only be used at a Version 8.2 or later level.
Databases created at the DB2 UDB Version 8.2 level may have additional functionality that was not available on earlier versions. This difference may result in unexpected and undesirable behavior if you attempt to move your new database to a previous release of DB2 UDB.
The "DB2 client overview" section of the DB2 Quick |Beginnings for Clients book states the following:
DB2 clients can |connect to DB2 servers two releases later or one release earlier than the |client's release level, as well as to servers at the same release level.|
An amendment to that statement is as follows:
|While connections from Version N clients to Version N + 2 servers are |possible in some environments, the DB2 support team will only provide support |for this configuration as long as Version N is still in service. Once Version |N is withdrawn from service, this configuration is no longer supported by |the DB2 support team. DB2 Version 7 clients connecting to a DB2 Version 8 |server is no longer supported by the DB2 support team because Version 7 has |been withdrawn from service.
Any registry changes made at the DB2 UDB Version 8.2 level are lost when you migrate back to DB2 UDB Version 8.1. The registry reverts to the version 8.1 HealthRules.reg file that contains the settings that existed before you upgraded to DB2 UDB Version 8.2 and started using the settings in the HealthRules2.reg file.
Prior to DB2 Universal Database (UDB) Version 8, FixPaks functioned only as updates to installed DB2 UDB packages or file sets in one fixed location. This meant that FixPaks installation replaced existing files with updated ones, which were provided in the FixPaks. Multiple DB2 FixPak levels could not exist on a single system. Now, DB2 UDB Enterprise Server Edition (ESE) can exist at multiple fix pack levels in the same system for Linux(TM)-based and UNIX(R)-based operating systems. This feature, supported in production operating environments since Version 8.1.2, is achieved using the following two FixPak types:
To update a multiple FixPak instance to a different FixPak level, perform one of the following operations:
For further information regarding alternate FixPaks:
Starting with Version 8.2.2 (equivalent to Version 8.1 FixPak 9), the contents of the TRACK_QUERY_INFO Query Patroller control table that were captured in a 32-bit environment can be used in a 64-bit environment. This capability eases the migration effort to a 64-bit environment. Information captured in the TRACK_QUERY_INFO Query Patroller control table at Version 8.2.2 cannot be used to generate historical data for that query or to execute held queries under any previous FixPak level.
The following limitations exist for previous server support for DB2 Universal Database (UDB) Enterprise Server Edition Version 8 Data Warehouse Center:
When using the Development Center on an Application Development client for DB2 Universal Database (UDB) Version 8 on Windows or UNIX operating systems, the following APARs need to be installed on the server to enable SQLJ and SQL Assist support:
You can invoke both Version 7 and Version 8 of SQL Assist from within DB2 Universal Database, Version 8. You can start Version 7 from the DB2 Data Warehouse Center. All other centers start the latest Version 8. The product online help has additional information for SQL Assist, Version 7.
In Version 7, Unicode servers ignored any graphic code pages sent by applications at connect time and assumed that UCS2 Unicode (code page 1200) was being used. Version 8 Unicode servers now respect the code page sent by the client.
DB2 UDB Version 8.2 uses a new 16K database configuration parameter file named SQLDBCONF. This is a separate file from the DB2 UDB Version 8.1 4K database configuration parameter file named SQLDBCON.
After migrating to DB2 UDB Version 8.2, the product migrates the contents of the Version 8.1 4K file and uses the 16K file for logging database configuration parameter changes. The Version 8.1 4K file is retained, but it is not used.
If you migrate back to DB2 UDB Version 8.1, the DB2 UDB Version 8.1 product reverts to using the original Version 8.1 4K file for logging database configuration parameter changes. The Version 8.2 16K file is retained, but it is not recognized by the DB2 UDB Version 8.1 product. Changes made to the 16K database configuration parameter file between migrating to Version 8.2 and migrating back to Version 8.1 are, in effect, concealed from the earlier DB2 UDB level because the changes are not migrated to the original 4K file.
In addition, if you migrate to DB2 UDB Version 8.2 again, the DB2 UDB Version 8.2 product recognizes that the 16K database configuration file already exists and reverts to using the Version 8.2 16K file for logging database configuration parameter changes. The Version 8.1 4K file is retained, but it is not recognized by the DB2 UDB Version 8.2 product. Changes made to the 4K database configuration parameter file between migrating back to Version 8.1 and remigrating to Version 8.2 are, in effect, concealed from the more recent DB2 UDB level because the changes are not migrated to the existing 16K file.
The db2diag.log file format has been improved in a number of ways for Version 8.2. The log file is now easier to read manually and easier to parse in software. The improvements include:
Other changes have been made as well, such as changing the database field name to DB.
Event records have been added as diagnostic messages to the db2diag.log file. Examples of such events are:
Event records have "Event" specified in the LEVEL field. Although events are not errors, they might be logged at diagnostic levels other than 4 (Informational) or 3 (Warning) depending on their importance.
Starting with Version 8.2, the following updates are logged in the db2diag.log file:
The messages for these updates are logged at high diagnostic levels due to their importance.
The following types of db2set profile registry updates are logged:
2004-04-22-19.19.14.156959-240 I79582C286 LEVEL: Event PID : 2437242 TID : 1 PROC : db2set INSTANCE: db2user NODE : 000 FUNCTION: DB2 UDB, oper system services, db2set_main, probe:40 CHANGE : CFG DB2SET: DB2DBDFT: From: "OLDDB" To: "SAMPLE"
CHANGE : CFG DB2SET: DB2DBDFT: From: "SAMPLE" To: ""
CHANGE : CFG DB2SET: Profile registry was reset
Examples for DB and DBM configuration parameter updates are
CHANGE : CFG DB SAMPLE: "Maxlocks" From: "10" To: "20" CHANGE : CFG DBM: "Diaglevel" From: "3" To: "1" CHANGE : CFG DBM: Reset to the system defaults
To find these configuration update messages, use db2diag tool. For example:
DB2 Universal Database(TM) (UDB) for Linux, UNIX, and Windows(R), Version 8.2.2 (equivalent to Version 8.1 FixPak 9), supports JDK 1.4.2 on all DB2 UDB supported 32-bit and 64-bit workstation operating system environments. This support includes, but is not limited to, support for building and running Java(TM) client applications, building and running Java(TM) routines from the command line, building and running Java(TM) routines from the DB2 Development Center where it is supported, as well as for running other DB2 tools.
When you install DB2 UDB, Version 8.2, the latest supported version of the Java developer kit will also be installed if it is not already installed, unless the DB2 UDB installation is an update of a previous DB2 UDB Version 8 installation. If you are updating a previous installation of DB2 UDB Version 8, you must install the Java developer kit from the CD.
The following table indicates the DB2 supported 32-bit and 64-bit workstation operating system environments and the latest supported JDK level for each of them. For information about earlier JDK support, refer to the Java Application Development Web page at http://www.ibm.com/software/data/db2/udb/ad/v8/java/.
| DB2 supported environment | Latest supported JDK level |
|---|---|
| Windows IA/AMD 32-bit | JDK 1.4.2 |
| Windows IA 64-bit | JDK 1.4.2 |
| Windows AMD/EM64T 64-bit | JDK 1.4.2 |
| AIX(R) 4.3.3 32-bit | JDK 1.3.1 SR6 [2] |
| AIX(R) 5 (hybrid [1]) | JDK 1.4.2 |
| Solaris (hybrid [1]) | JDK 1.4.2 |
| HPUX RISC & Itanium (hybrid [1]) | JDK 1.4.2.01 |
| Linux AMD/EM64T 32-bit, 64-bit (hybrid [1]) | JDK 1.4.2 [3] |
| Linux IA 32-bit | JDK 1.4.2 |
| Linux IA 64-bit | JDK 1.4.2 |
| Linux 390 31-bit | JDK 1.4.2 |
| Linux 390 64-bit | JDK 1.4.2 |
| Linux PPC (hybrid [1]) | JDK 1.4.2 |
An updated procedure for setting up the Linux Java Environment is provided next.
To build Java applications on Linux with DB2 JDBC support:
To run Java stored procedures or user-defined functions, the Linux runtime linker must be able to access certain Java shared libraries, and DB2 UDB must be able to load both these libraries and the Java virtual machine. The process that runs stored procedures and user-defined functions loads libraries only in secure locations, as defined in the /etc/ld.so.conf file. One of these secure locations is /usr/lib. The remaining instructions show which libraries require symbolic links in /usr/lib.
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so . ln -fs JAVAHOME/jre/bin/classic/libjvm.so . ln -fs JAVAHOME/jre/bin/libhpi.so .where JAVAHOME is the base directory for the IBM(R) Developer Kit. If DB2 UDB cannot find these libraries, you will get a -4301 error when trying to run a Java routine, and there will be messages in the administration notification log about libraries not found.
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so ln -fs JAVAHOME/jre/bin/classic/libjvm.so ln -fs JAVAHOME/jre/bin/libhpi.so ln -fs JAVAHOME/jre/bin/libjsig.sowhere JAVAHOME is the base directory for the IBM Developer Kit. If DB2 UDB cannot find these libraries, you will get a -4301 error when trying to run a Java routine, and there will be messages in the administration notification log about libraries not found.
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so ln -fs JAVAHOME/jre/bin/classic/libjvm.so ln -fs JAVAHOME/jre/bin/libhpi.so ln -fs JAVAHOME/jre/bin/libjsig.so ln -fs JAVAHOME/jre/bin/libjitc.so ln -fs JAVAHOME/jre/bin/libxhpi.so ln -fs JAVAHOME/jre/bin/libdbgmalloc.sowhere JAVAHOME is the base directory for the IBM Developer Kit. If DB2 UDB cannot find these libraries, you will get a -4301 error when trying to run a Java routine, and there will be messages in the administration notification log about libraries not found.
JAVAHOME/jre/binwhere JAVAHOME is the base directory for the IBM Developer Kit. If DB2 UDB cannot find these libraries, you will get a -4301 or -1042 error when trying to run a Java routine.
Instead of explicitly creating links to the shared libraries in the /usr/lib directory, you can add the name of the directory that stores the Java shared libraries to the /etc/ld.so.conf file. This file requires root permission. After updating /etc/ld.so.conf , you must run the ldconfig command as root to activate your changes. If you encounter any problems with this alternative procedure, create the links in the /usr/lib directory as previously instructed.
If you are using the Microsoft XP 64-bit operating system (2600) configured to use the NETBIOS protocol with the DB2 family of products, you need to obtain a hotfix from Microsoft. Contact Microsoft with the Knowledge Base article number Q317437.
The Windows XP Home Edition operating system is supported only by DB2 Universal Database (UDB) Personal Edition products.
The Windows XP Professional operating system is supported by the following DB2 products:
The following DB2 products are supported on Windows XP for development or test purposes only (production environments require Windows 2000 or Windows Server 2003):
In DB2 Universal Database(TM) (UDB) Version 8.2, customers of DB2 UDB Workgroup Server Edition and DB2 UDB Express Edition (when licensed based on per user pricing model) were not able to install the DB2 UDB High Availability Disaster Recovery (HADR) separately priced option. This problem has been fixed in DB2 UDB Version 8.2 FixPak 1 (equivalent to Version 8.1 FixPak 8).
The OLAP utilities in DB2 Warehouse Manager Standard Edition, Version 8.2 are not compatible with IBM DB2 OLAP Server FP3 (Essbase API level 6.5.4) and later. You are advised to use DB2 OLAP Server FP2 (Essbase 6.5.3) or earlier until this problem is resolved.
To use logs with raw I/O devices prior to DB2 Universal Database (UDB) Version 8.2.2 (equivalent to Version 8.1 FixPak 9), it was necessary to bind a physical device to the Linux raw character device driver with the raw utility. Starting with DB2 UDB Version 8.2.2 (equivalent to Version 8.1 FixPak 9), on the 2.6 Linux kernel, raw I/O for logs can be specified directly. For example, to use device partition /dev/sdb1 for raw logs for the SAMPLE database, issue the following command:
db2 update db cfg for sample using newlogpath /dev/sdb1
Although DB2 UDB still supports the method of using the raw utility for raw I/O, recent distributions have deprecated this feature and might remove it in the future. The preferred method is to use the new method by specifying the devices directly.
DB2 Universal Database, Version 8.2 supports Red Hat Enterprise Linux AS Versions 3 and 2.1. However, the Data Warehouse Center supports only Red Hat Enterprise Linux AS, Version 2.1. The Data Warehouse Center uses DataDirect ODBC drivers that do not support Red Hat Enterprise Linux AS, Version 3.1. Therefore, the Data Warehouse Center does not support ODBC warehouse sources and warehouse targets from a Red Hat Enterprise Linux AS, Version 3.1 agent site.
When running applications in an IBM(R) WebSphere(R) MQ (formerly known as IBM MQSeries(R)) environment, WebSphere(R) MQ can act as an XA-compliant transaction manager, coordinating any distributed, two-phase commit transactions. When WebSphere(R) MQ is acting as a transaction manager in this way, and the data sources are from the DB2 family of products, there are several configuration requirements. Most of these requirements are already documented. For example, you must set the DB2 configuration parameter TP_MON_NAME to "MQ" at the DB2 runtime client.
However, there is a configuration requirement that has not been documented. The requirement is specific to DB2 Connect when connecting to data sources that are DB2 for OS/390(R) servers: When using WebSphere MQ to coordinate distributed transactions involving DB2 for z/OS(R) and DB2 for iSeries servers, the DB2 Connect connection concentrator feature must be enabled at the gateway. The connection concentrator is enabled when the value of the MAX_CONNECTIONS configuration parameter is greater than the value of MAX_COORDAGENTS. If you do not enable the connection concentrator, unexpected transaction behavior will result.
The Microsoft Japanese Windows Shift-JIS code page is registered as the IBM coded character set identifier (CCSID) 943. However, the Shift-JIS code page on HP-UX platform is registered as CCSID 5039. CCSID 5039 contains characters in the Japanese Industry Standard (JIS) only, and does not have any vendor defined characters. You can use a DB2 Universal Database (UDB) database of CCSID 5039 on HP-UX to store Shift-JIS characters, but there will be code page conversion between CCSID 5039 and CCSID 943. When using Microsoft ODBC applications, you might encounter a problem when converting data in CCSID 5039 to Unicode, due to differences between IBM's code page conversion table and Microsoft's code page conversion table.
The following list of characters, when converted from CCSID 5039 to Unicode, will result in different code points depending on which conversion table is used (IBM or Microsoft). For these characters, the IBM conversion table conforms to the Japanese Industry Standard JISX0208 and JISX0221.
| Shift-JIS code point (character name) | IBM primary code point (Unicode name) | Microsoft primary code point (Unicode name) |
|---|---|---|
| X'815C' (EM dash) | U+2014 (EM dash) | U+2015 (Horizontal bar) |
| X'8160' (Wave dash) | U+301C (Wave dash) | U+FF5E (Fullwidth tilde) |
| X'8161' (Double vertical line) | U+2016 (Double vertical line) | U+2225 (Parallel to) |
| X'817C' (Minus sign) | U+2212 (Minus sign) | U+FF0D (Fullwidth hyphen-minus) |
For example, the character EM dash with the CCSID 5039 code point of X'815C' is converted to the Unicode code point U+2014 when using the IBM conversion table, but is converted to U+2015 when using the Microsoft conversion table. This can create potential problems for Microsoft ODBC applications because they would treat U+2014 as an invalid code point. To avoid these potential problems, DB2 UDB provides the alternate Microsoft conversion table from CCSID 5039 to Unicode, in addition to the default IBM conversion table. You need to replace the default IBM conversion table with the alternate Microsoft conversion table. Note that the default IBM conversion table from Unicode to CCSID 5039 matches the Microsoft version.
When you convert from CCSID 5039 to Unicode, the DB2 Universal Database (UDB) default code page conversion table is used. If you want to use a different version of the conversion table, such as the Microsoft version, you must manually replace the default conversion table (.cnv) file.
Before replacing the existing code page conversion table file in the sqllib/conv directory, you should back up the file in case you want to change it back. On UNIX and Linux, the sqllib/conv directory is linked to the DB2 UDB installation path.
For conversion table replacement to be effective, every DB2 UDB client that connects to the same database must have its conversion table changed. Otherwise, the different clients might store the same character using different code points.
To replace the DB2 UDB default conversion table for converting from CCSID 5039 to Unicode, follow these steps:
The IBM coded character set identifier (CCSID) for the Japanese EUC code page is registered as CCSID 954. CCSID 954 is a common encoding for Japanese UNIX and Linux platforms. When using Microsoft ODBC applications to connect to a DB2 Universal Database (UDB) database of CCSID 954, you might encounter a problem when converting data from CCSID 954 to Unicode. The potential problem is due to differences between IBM's code page conversion table and Microsoft's code page conversion table. The IBM conversion table conforms to the character names as specified in the Japanese Industry Standard (JIS) JISX0208, JISX0212, and JISX0221.
The following characters, when converted from CCSID 954 to Unicode, will result in different code points depending on whether the IBM or Microsoft conversion table is used.
| EUC-JP code point (character name) | IBM primary code point (Unicode name) | Microsoft primary code point (Unicode name) |
|---|---|---|
| X'A1BD' (EM dash) | U+2014 (EM Dash) | U+2015 (Horizontal Bar) |
| X'A1C1' (Wave dash) | U+301C (Wave Dash) | U+FF5E (Fullwidth Tilde) |
| X'A1C2' (Double vertical line) | U+2016 (Double vertical line) | U+2225 (Parallel To) |
| X'A1DD' (Minus sign) | U+2212 (Minus sign) | U+FF0D (Fullwidth hyphen-minus) |
| X'8FA2C3' (Broken bar) | U+00A6 (Broken bar) | U+FFE4 (Fullwidth broken bar) |
For example, the character EM dash with the CCSID 954 code point of X'A1BD' is converted to the Unicode code point U+2014 when using the IBM conversion table, but is converted to U+2015 when using the Microsoft conversion table. Due to this difference of conversion mapping, you might have two different code points for the same character in a DB2 UDB Unicode database, or in a graphic column of a DB2 UDB 954 database. This can create potential problems for Microsoft ODBC applications because they would treat U+2014 as an invalid code point. To avoid these potential problems, DB2 UDB provides the alternate Microsoft conversion table from CCSID 954 to Unicode, in addition to the default IBM conversion table. You need to replace the default IBM conversion table with the alternate Microsoft conversion table. Note that the default IBM conversion table from Unicode to CCSID 954 matches the Microsoft version.
When you convert from CCSID 954 to Unicode, the DB2 Universal Database (UDB) default code page conversion table is used. If you want to use a different version of the conversion table, such as the Microsoft version, you must manually replace the default conversion table (.cnv) file.
Before replacing the existing code page conversion table file in the sqllib/conv directory, you should back up the file in case you want to change it back. On UNIX and Linux, the sqllib/conv directory is linked to the installation path of DB2 UDB.
For this to be effective, every DB2 UDB client that connects to the same CCSID 954 database must have its conversion table changed. If your client is Japanese Windows, whose ANSI code page is Shift-JIS (CCSID 943), you will also need to change the DB2 default conversion tables between CCSID 943 and Unicode to the Microsoft version. Otherwise, the different clients might store the same character using different code points.
To replace the DB2 UDB default conversion table for converting from CCSID 954 to Unicode, follow these steps:
To replace the DB2 UDB default conversion tables for converting between CCSID 943 and Unicode, follow these steps:
When using the Microsoft Japanese Windows Shift-JIS code page that is registered as the IBM coded character set identifier (CCSID) 943, you might encounter the following two problems when converting characters between CCSID 943 and Unicode. The potential problem is due to differences between the IBM and Microsoft code page conversion tables. To avoid these potential problems, DB2 Universal Database (UDB) provides the alternate Microsoft conversion tables between CCSID 943 and Unicode, in addition to the default IBM conversion tables.
For historical reasons, over 300 characters in the CCSID 943 code page are represented by two or three code points each. The use of input method editors (IMEs) and code page conversion tables cause only one of these equivalent code points to be entered. For example, the lower case character for Roman numeral one 'i' has two equivalent code points: X'EEEF' and X'FA40'. Microsoft Windows IMEs always generate X'FA40' when 'i' is entered. In general, IBM and Microsoft use the same primary code point to represent the character, except for the following 13 characters:
| Character name (Unicode code point) | IBM primary Shift-JIS code point | Microsoft primary Shift-JIS code point |
|---|---|---|
| Roman numeral one (U+2160) | X'FA4A' | X'8754' |
| Roman numeral two (U+2161) | X'FA4B' | X'8755' |
| Roman numeral three (U+2162) | X'FA4C' | X'8756' |
| Roman numeral four (U+2163) | X'FA4D' | X'8757' |
| Roman numeral five (U+2164) | X'FA4E' | X'8758' |
| Roman numeral six (U+2165) | X'FA4F' | X'8759' |
| Roman numeral seven (U+2166) | X'FA50' | X'875A' |
| Roman numeral eight (U+2167) | X'FA51' | X'875B' |
| Roman numeral nine (U+2168) | X'FA52' | X'875C' |
| Roman numeral ten (U+2169) | X'FA53' | X'875D' |
| Parenthesized ideograph stock (U+3231) | X'FA58' | X'FA58' |
| Numero sign (U+2116) | X'FA59' | X'8782' |
| Telephone sign (U+2121) | X'FA5A' | X'8754' |
IBM products such as DB2 UDB primarily use IBM code points, such as X'FA4A' to present the upper case Roman numeral one 'I', but Microsoft products use X'8754' to represent the same character. An Microsoft ODBC application can insert the 'I' character as X'8754' into a DB2 UDB database of CCSID 943, and the DB2 UDB Control Center can insert the same character as X'FA4A' into the same CCSID 943 database. However, ODBC applications can find only those rows that have 'I' encoded as X'8754', and DB2 UDB Control Center can locate only those rows that have 'I' encoded as X'FA4A'. To enable DB2 UDB Control Center to select 'I' as X'8754', you need to replace the default IBM conversion tables between CCSID 943 and Unicode with the alternate Microsoft conversion tables.
The following list of characters, when converted from CCSID 943 to Unicode, will result in different code points depending on whether the IBM conversion table or the Microsoft conversion table is used. For these characters, the IBM conversion table conforms to the Japanese Industry Standard JISX0208, JISX0212, and JISX0221.
| Shift-JIS code point (character name) | IBM primary code point (Unicode name) | Microsoft primary code point (Unicode name) |
|---|---|---|
| X'815C' (EM dash) | U+2014 (EM dash) | U+2015 (Horizontal bar) |
| X'8160' (Wave dash) | U+301C (Wave dash) | U+FF5E (Fullwidth tilde) |
| X'8161' (Double vertical line) | U+2016 (Double vertical line) | U+2225 (Parallel to) |
| X'817C' (Minus sign) | U+2212 (Minus sign) | U+FF0D (Fullwidth hyphen-minus) |
| X'FA55' (Broken bar) | U+00A6 (Broken bar) | U+FFE4 (Fullwidth broken bar) |
For example, the character EM dash with the CCSID 943 code point of X'815C' is converted to the Unicode code point U+2014 when using the IBM conversion table. However, it is converted to U+2015 when using the Microsoft conversion table. Due to this difference of conversion mapping, you might have two different code points for the same character in a DB2 UDB Unicode database. This can create potential problems for Microsoft ODBC applications because they would treat U+2014 as an invalid code point. To avoid this potential problem, you need to replace the default IBM conversion tables between CCSID 943 and Unicode with the alternate Microsoft conversion tables.
The use of the alternate Microsoft conversion tables between CCSID 943 and Unicode should be restricted to closed environments, where the DB2 UDB clients and the DB2 UDB databases all have a code page of CCSID 943 and are all using the same alternate Microsoft conversion tables. If you have a DB2 UDB client using the default IBM conversion tables, and another DB2 UDB client using the alternate Microsoft conversion tables, and both clients are inserting data to the same DB2 UDB database of CCSID 943, the same character may be stored as different code points in the database.
When you convert between CCSID 943 and Unicode, the DB2 Universal Database (UDB) default code page conversion tables are used. If you want to use a different version of the conversion tables, such as the Microsoft version, you must manually replace the default conversion table (.cnv) files.
Before replacing the existing code page conversion table files in the sqllib/conv directory, you should back up the files in case you want to change them back. On UNIX and Linux, sqllib/conv is linked to the DB2 UDB installation path.
For conversion table replacement to be effective, every DB2 UDB client that connects to the same database must have its conversion table changed. Otherwise the different clients might store the same character using different code points.
To replace the DB2 UDB default conversion tables for converting characters between CCSID 943 and Unicode:
Despite being mentioned in the documentation, the MVS operating system is no longer supported by DB2 Universal Database. MVS has been replaced with z/OS.
Backup and restore operations to and from multiple tape devices might not work if you are using the Linux 390 operating system.
When accessing the Development Center on UNIX with Hummingbird Exceed, the XTEST extension version 2.2 must be enabled before you can move and dock views by dragging their title bars within the Development Center.
To enable the XTEST extension: