If you create a database with DB2 Universal Database Version 8.2, you cannot 8use that database at a Version 8.1 level. That database can only be used at 8a Version 8.2 or later level.
8Databases created at the DB2 UDB Version 8.2 level may have additional 8 functionality that was not available on earlier versions. This difference 8may result in unexpected and undesirable behavior if you attempt to move 8your new database to a previous release of DB2 UDB.
8 8The "DB2 client overview" section of the DB2 Quick 8Beginnings for Clients book states the following:
DB2 clients can 8connect to DB2 servers two releases later or one release earlier than the 8client's release level, as well as to servers at the same release level.8
The amendment to that statement is as follows:
87 7 7While connections from Version N clients to Version N + 2 servers are 8possible in some environments, this connection is a supported configuration 8only as long as Version N is in service. Once Version N is withdrawn from 8service, this configuration is no longer supported.
8DB2 Version 6 8clients connecting to a DB2 Version 8 server is no longer supported because 8Version 6 has been withdrawn from service.
8Similarly for DB2 UDB server support, 8a Version N client can connect to a Version N - 1 server, unless the Version 8N - 1 server is out of service.
Any registry changes made at the DB2 UDB Version 8.2 level are lost when you 7migrate back to DB2 UDB Version 8.1. The registry reverts to the version 78.1 HealthRules.reg file that contains the settings that existed before you 7upgraded to DB2 UDB Version 8.2 and started using the settings in the HealthRules2.reg 7file.
3 3 3Prior to DB2 Universal Database (UDB) Version 8, FixPaks 3functioned only as updates to installed DB2 UDB packages or file sets in one fixed 3location. This meant that FixPaks installation replaced existing files with 3updated ones, which were provided in the FixPaks. Multiple DB2 FixPak levels 3could not exist on a single system. Now, DB2 UDB Enterprise Server Edition (ESE) can 3exist at multiple fix pack levels in the same system for Linux(TM)-based 3and UNIX(R)-based operating systems. This feature, supported in production 3operating environments since Version 8.1.2, is achieved using the following 3two FixPak types:
3To update a multiple FixPak instance to a different FixPak level, perform 3one of the following operations:
3For further information regarding downloading alternate FixPaks, visit 3the IBM support site at http://www.ibm.com/software/data/db2/udb/support.html.
39 9 9Starting with Version 8.2.2, the contents of the TRACK_QUERY_INFO Query 9Patroller control table that were captured in a 32-bit environment can 9be used in a 64-bit environment. This capability eases the migration 9effort to a 64-bit environment. Information captured in the TRACK_QUERY_INFO 9Query Patroller control table at Version 8.2.2 cannot be used to generate 9historical data for that query or to execute held queries under any previous 9FixPak level.
The following limitations exist for previous server support for DB2 Universal Database (UDB) Enterprise Server Edition Version 8 Data Warehouse Center:
2When using the Development Center on an Application Development 2client for DB2 Universal Database (UDB) Version 8 on Windows or UNIX operating systems, the following APARs need to 2be 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.
8 8 8DB2 UDB Version 8.2 uses a new 16K database configuration parameter file 8named SQLDBCONF. This is a separate file from the DB2 UDB Version 8.1 4K database configuration 8parameter file named SQLDBCON.
8After migrating to DB2 UDB Version 8.2, the product migrates the contents 8of the Version 8.1 4K file and uses the 16K file for logging database configuration 8parameter changes. The Version 8.1 4K file is retained, but it is not used.
8If you migrate back to DB2 UDB Version 8.1, the DB2 UDB Version 8.1 product reverts to using 8the original Version 8.1 4K file for logging database configuration parameter 8changes. The Version 8.2 16K file is retained, but it is not recognized by 8the DB2 UDB Version 8.1 product. Changes made to the 16K database configuration 8parameter file between migrating to Version 8.2 and migrating back to Version 88.1 are, in effect, concealed from the earlier DB2 UDB level because the changes are not 8migrated to the original 4K file.
8In addition, if you migrate to DB2 UDB Version 8.2 again, the DB2 UDB Version 88.2 product recognizes that the 16K database configuration file already exists 8and reverts to using the Version 8.2 16K file for logging database configuration 8parameter changes. The Version 8.1 4K file is retained, but it is not recognized 8by the DB2 UDB Version 8.2 product. Changes made to the 4K database configuration 8parameter file between migrating back to Version 8.1 and remigrating to Version 88.2 are, in effect, concealed from the more recent DB2 UDB level because the changes are not 8migrated to the existing 16K file.
7 7 7The db2diag.log file format has been improved in a number of ways for Version 78.2. The log file is now easier to read manually and easier to parse in software. 7The improvements include:
7Other changes have been made as well, such as changing the database field name to DB.
7Event records have been added as diagnostic messages to the db2diag.log 7file. Examples of such events are:
7Event records have "Event" specified in the LEVEL field. Although events are not errors, they might be logged at 7diagnostic levels other than 4 (Informational) or 3 (Warning) depending on 7their importance.
7 7 7Starting with Version 8.2, the following updates are logged in the db2diag.log 7file:
7The messages for these updates are logged at high diagnostic levels due 7to their importance.
7The following types of db2set profile registry updates are logged:
72004-04-22-19.19.14.156959-240 I79582C286 LEVEL: Event 7PID : 2437242 TID : 1 PROC : db2set 7INSTANCE: db2user NODE : 000 7FUNCTION: DB2 UDB, oper system services, db2set_main, probe:40 7CHANGE : CFG DB2SET: DB2DBDFT: From: "OLDDB" To: "SAMPLE"7
CHANGE : CFG DB2SET: DB2DBDFT: From: "SAMPLE" To: ""7 7
CHANGE : CFG DB2SET: Profile registry was reset7 7
Examples for DB and DBM configuration parameter updates are
7CHANGE : CFG DB SAMPLE: "Maxlocks" From: "10" To: "20" 7 7CHANGE : CFG DBM: "Diaglevel" From: "3" To: "1" 7 7CHANGE : CFG DBM: Reset to the system defaults7 7
To find these configuration update messages, use db2diag tool. For example:
7DB2 Universal Database(TM) (UDB) for Linux, UNIX, 9and Windows(R), Version 8.2.2 (equivalent to Version 8.1 FixPak 9), supports JDK 1.4.2 9on all DB2 UDB supported 32-bit and 64-bit workstation operating 9system environments. This support includes, but is not limited to, support 9for building and running Java(TM) client applications, building and running Java 9routines from the command line, building and running Java routines from the 9DB2 Development Center where it is supported, as well as for running other 9DB2 tools.
9When you install DB2 UDB, Version 8.2, the latest supported version of 9the Java developer kit will also be installed if it is not already installed, 9unless the DB2 UDB installation is an update of a previous DB2 UDB Version 98 installation. If you are updating a previous installation of DB2 UDB Version 98, you must install the Java developer kit from the CD.
9The following table indicates the DB2 supported 32-bit and 64-bit 9workstation operating system environments and the latest supported JDK level 9for each of them. For information about earlier JDK support, refer to the 9Java Application Development Web page at http://www.ibm.com/software/data/db2/udb/ad/v8/java/.
9 9| DB2 supported environment | 9Latest supported JDK level | 9
|---|---|
| Windows IA/AMD 32-bit | 9JDK 1.4.2 | 9
| Windows IA 64-bit | 9JDK 1.4.2 | 9
| Windows AMD/EM64T 64-bit | 9JDK 1.4.2 | 9
| AIX(R) 4.3.3 32-bit | 9JDK 1.3.1 SR6 [2] | 9
| AIX 5 (hybrid [1]) | 9JDK 1.4.2 | 9
| Solaris (hybrid [1]) | 9JDK 1.4.2 | 9
| HPUX RISC & Itanium (hybrid [1]) | 9JDK 1.4.2.01 | 9
| Linux AMD/EM64T 32-bit, 64-bit (hybrid [1]) | 9JDK 1.4.2 [3] | 9
| Linux IA 32-bit | 9JDK 1.4.2 | 9
| Linux IA 64-bit | 9JDK 1.4.2 | 9
| Linux 390 31-bit | 9JDK 1.4.2 | 9
| Linux 390 64-bit | 9JDK 1.4.2 | 9
| Linux PPC (hybrid [1]) | 9JDK 1.4.2 | 9
An updated procedure for setting up the Linux Java Environment which is 9provided next.
9 9 9To build Java applications on Linux with DB2 JDBC support:
9To run Java stored procedures or user-defined 9functions, the Linux runtime linker must be able to access certain Java shared 9libraries, and DB2 UDB must be able to load both these libraries and the Java 9virtual machine. The process that runs stored procedures and user-defined 9functions loads libraries only in secure locations, as defined in the /etc/ld.so.conf file. One of these secure locations 9is /usr/lib. The remaining instructions show 9which libraries require symbolic links in /usr/lib.
cd /usr/lib 9 ln -fs JAVAHOME/jre/bin/libjava.so . 9 ln -fs JAVAHOME/jre/bin/classic/libjvm.so . 9 ln -fs JAVAHOME/jre/bin/libhpi.so .where JAVAHOME is 9the base directory for the IBM Developer Kit. If DB2 UDB cannot find these 9libraries, you will get a -4301 error when trying to run a Java routine, and 9there will be messages in the administration notification log about libraries 9not found. 9
cd /usr/lib 9 ln -fs JAVAHOME/jre/bin/libjava.so 9 ln -fs JAVAHOME/jre/bin/classic/libjvm.so 9 ln -fs JAVAHOME/jre/bin/libhpi.so 9 ln -fs JAVAHOME/jre/bin/libjsig.sowhere JAVAHOME is the 9base directory for the IBM Developer Kit. If DB2 UDB cannot find these libraries, 9you will get a -4301 error when trying to run a Java routine, and there will 9be messages in the administration notification log about libraries not found. 9
cd /usr/lib 9 ln -fs JAVAHOME/jre/bin/libjava.so 9 ln -fs JAVAHOME/jre/bin/classic/libjvm.so 9 ln -fs JAVAHOME/jre/bin/libhpi.so 9 ln -fs JAVAHOME/jre/bin/libjsig.so 9 ln -fs JAVAHOME/jre/bin/libjitc.so 9 ln -fs JAVAHOME/jre/bin/libxhpi.so 9 ln -fs JAVAHOME/jre/bin/libdbgmalloc.sowhere JAVAHOME is 9the base directory for the IBM Developer Kit. If DB2 UDB cannot find these 9libraries, you will get a -4301 error when trying to run a Java routine, and 9there will be messages in the administration notification log about libraries 9not found. 9
Instead of explicitly creating links to the shared libraries in the /usr/lib directory, you can add the Java shared library 9names to the /etc/ld.so.conf file. If you add 9the Java shared library names to the /etc/ld.so.conf file, you must run the ldconfig command 9with root level access after you make your changes. If you encounter any 9problems 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.
2The Windows XP Home Edition operating system is supported 2only by DB2 Universal Database (UDB) Personal Edition products.
2The Windows XP Professional operating system 2is supported by the following DB2 products:
9The following DB2 products are supported on Windows XP 9for development or test purposes only (production environments require Windows 2000 or Windows Server 2003):
In DB2 Universal Database (UDB) Version 8.2, customers of DB2 UDB Workgroup 8Server Edition and DB2 UDB Express Edition (when licensed based on per user 8pricing model) were not able to install the DB2 UDB High Availability Disaster 8Recovery (HADR) separately priced option. This problem has been fixed in 8DB2 UDB Version 8.2 FixPak 1 (equivalent to Version 8.1 FixPak 8).
8 8 8The OLAP utilities in DB2 Warehouse Manager Standard Edition, Version 8.2 are 8not compatible with IBM DB2 OLAP Server FP3 (Essbase API level 6.5.4) 8and later. You are advised to use DB2 OLAP Server FP2 (Essbase 6.5.3) or earlier 8until this problem is resolved.
9 9 9To use logs with raw I/O devices prior to DB2 Universal Database (UDB) 9Version 8.2.2, it was necessary to bind a physical device to the Linux raw 9character device driver with the raw utility. 9 Starting with DB2 UDB Version 8.2.2 (equivalent 9to Version 8.1 FixPak 9), on the 2.6 Linux kernel, raw I/O for logs can be 9specified directly. DB2 9UDB will take advantage of a special open flag in the 2.6 kernel and enable 9raw I/O for logs by default. For example, to use device partition /dev/sdb1 for raw logs for the SAMPLE database, issue the following command:
9db2 update db cfg for sample using newlogpath /dev/sdb19
The raw character driver is deprecated in the 2.6 kernel and may be removed 9from future kernels. In addition, Linux distributions might not include the 9driver in their default kernels.
9Support for the special open flag in the 2.6 kernel to enable raw I/O for 9table spaces was previously added in Version 8.2.
8 8 8DB2 Universal Database, Version 8.2 supports Red Hat Enterprise Linux AS Versions 3 and 2.1. However, the Data Warehouse Center supports 8only Red Hat Enterprise Linux AS, Version 2.1. The Data Warehouse Center uses 8DataDirect ODBC drivers that do not support Red Hat Enterprise Linux AS, Version 83.1. Therefore, the Data Warehouse Center does not support ODBC warehouse 8sources and warehouse targets from a Red Hat Enterprise Linux AS, Version 83.1 agent site.
6 6 6The Microsoft Japanese Windows Shift-JIS code page is registered 6as the IBM coded character set identifier (CCSID) 943. However, the Shift-JIS 6code page on HP-UX platform is registered as CCSID 5039. CCSID 5039 contains 6characters in the Japanese Industry Standard (JIS) only, and does not have 6any vendor defined characters. You can use a DB2 Universal Database (UDB) database of CCSID 5039 on HP-UX to store Shift-JIS characters, 6but there will be code page conversion between CCSID 5039 and CCSID 943. When 6using Microsoft ODBC applications, you might encounter a 6problem when converting data in CCSID 5039 to Unicode, due to differences 6between IBM's code page conversion table and Microsoft's code page conversion 6table.
6The following list of characters, when converted from CCSID 5039 to Unicode, 6will result in different code points depending on which conversion table is 6used (IBM or Microsoft). For these characters, the IBM conversion table 6conforms to the Japanese Industry Standard JISX0208 and JISX0221.
6 6| Shift-JIS code point (character name) | 6IBM primary code point (Unicode name) | 6Microsoft primary code point (Unicode 6name) | 6
|---|---|---|
| X'815C' (EM dash) | 6U+2014 (EM dash) | 6U+2015 (Horizontal bar) | 6
| X'8160' (Wave dash) | 6U+301C (Wave dash) | 6U+FF5E (Fullwidth tilde) | 6
| X'8161' (Double vertical line) | 6U+2016 (Double vertical line) | 6U+2225 (Parallel to) | 6
| X'817C' (Minus sign) | 6U+2212 (Minus sign) | 6U+FF0D (Fullwidth hyphen-minus) | 6
For example, the character EM dash with the CCSID 5039 code point of X'815C' 6is converted to the Unicode code point U+2014 when using the IBM conversion table, 6but is converted to U+2015 when using the Microsoft conversion table. This can create 6potential problems for Microsoft ODBC applications because they 6would treat U+2014 as an invalid code point. To avoid these potential problems, DB2 UDB 6provides the alternate Microsoft conversion table from CCSID 65039 to Unicode, in addition to the default IBM conversion table. You need to replace 6the default IBM conversion table with the alternate Microsoft conversion table. Note that 6the default IBM conversion table from Unicode to CCSID 5039 matches the Microsoft version.
6 6 6When you convert from CCSID 5039 to Unicode, the DB2 Universal Database (UDB) default code page conversion table is used. If you want to use 6a different version of the conversion table, such as the Microsoft version, 6you must manually replace the default conversion table (.cnv) file.
6Before replacing the existing code page conversion table file in the sqllib/conv directory, you should back up the file 6in 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 6connects to the same database must have its conversion table changed. Otherwise, 6the different clients might store the same character using different code 6points.
To replace the DB2 UDB default conversion table for converting from CCSID 65039 to Unicode, follow these steps:
6The IBM coded character set identifier (CCSID) for the Japanese EUC code 6page is registered as CCSID 954. CCSID 954 is a common encoding for Japanese UNIX and Linux platforms. When using Microsoft ODBC applications to connect 6to a DB2 Universal Database (UDB) database of CCSID 954, you 6might encounter a problem when converting data from CCSID 954 to Unicode. 6The potential problem is due to differences between IBM's code page conversion 6table and Microsoft's code page conversion table. The IBM conversion table 6conforms to the character names as specified in the Japanese Industry Standard 6(JIS) JISX0208, JISX0212, and JISX0221.
6The following characters, when converted from CCSID 954 to Unicode, will 6result in different code points depending on whether the IBM or Microsoft conversion 6table is used.
6 6| EUC-JP code point (character name) | 6IBM primary code point (Unicode name) | 6Microsoft primary code point (Unicode 6name) | 6
|---|---|---|
| X'A1BD' (EM dash) | 6U+2014 (EM Dash) | 6U+2015 (Horizontal Bar) | 6
| X'A1C1' (Wave dash) | 6U+301C (Wave Dash) | 6U+FF5E (Fullwidth Tilde) | 6
| X'A1C2' (Double vertical line) | 6U+2016 (Double vertical line) | 6U+2225 (Parallel To) | 6
| X'A1DD' (Minus sign) | 6U+2212 (Minus sign) | 6U+FF0D (Fullwidth hyphen-minus) | 6
| X'8FA2C3' (Broken bar) | 6U+00A6 (Broken bar) | 6U+FFE4 (Fullwidth broken bar) | 6
For example, the character EM dash with the CCSID 954 code point of X'A1BD' 6is converted to the Unicode code point U+2014 when using the IBM conversion table, 6but is converted to U+2015 when using the Microsoft conversion table. Due to this 6difference of conversion mapping, you might have two different code points 6for the same character in a DB2 UDB Unicode database, or in a graphic 6column of a DB2 UDB 954 database. This can create potential problems for Microsoft ODBC 6applications because they would treat U+2014 as an invalid code point. To 6avoid these potential problems, DB2 UDB provides the alternate Microsoft conversion 6table from CCSID 954 to Unicode, in addition to the default IBM conversion table. 6You need to replace the default IBM conversion table with the alternate Microsoft conversion table. Note that the default IBM conversion table 6from Unicode to CCSID 954 matches the Microsoft version.
6 6 6When you convert from CCSID 954 to Unicode, the DB2 Universal Database (UDB) default code page conversion table is used. If you want to use 6a different version of the conversion table, such as the Microsoft version, 6you must manually replace the default conversion table (.cnv) file.
6Before replacing the existing code page conversion table file in the sqllib/conv directory, you should back up the file 6in 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 6954 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 6need to change the DB2 default conversion tables between CCSID 943 and Unicode 6to the Microsoft version. Otherwise, the different clients 6might store the same character using different code points.
To replace the DB2 UDB default conversion table for converting from CCSID 6954 to Unicode, follow these steps:
6To replace the DB2 UDB default conversion tables for converting between 6CCSID 943 and Unicode, follow these steps:
6When using the Microsoft Japanese Windows Shift-JIS 7code page that is registered as the IBM coded character set identifier (CCSID) 7943, you might encounter the following two problems when converting characters 7between CCSID 943 and Unicode. The potential problem is due to differences 7between the IBM and Microsoft code page conversion tables. To avoid these 7potential problems, DB2 Universal Database (UDB) provides the alternate Microsoft conversion tables between CCSID 943 and Unicode, in addition 7to the default IBM conversion tables.
7For historical reasons, over 300 characters in the CCSID 943 code page 7are represented by two or three code points each. The use of input method 7editors (IMEs) and code page conversion tables cause only one of these equivalent 7code points to be entered. For example, the lower case character for Roman 7numeral one 'i' has two equivalent code points: X'EEEF' and 7X'FA40'. Microsoft Windows IMEs always generate X'FA40' 7when 'i' is entered. In general, IBM and Microsoft use the same primary code point 7to represent the character, except for the following 13 characters:
7 7| Character name (Unicode code point) | 7IBM primary Shift-JIS code point | 7Microsoft primary Shift-JIS code point | 7
|---|---|---|
| Roman numeral one (U+2160) | 7X'FA4A' | 7X'8754' | 7
| Roman numeral two (U+2161) | 7X'FA4B' | 7X'8755' | 7
| Roman numeral three (U+2162) | 7X'FA4C' | 7X'8756' | 7
| Roman numeral four (U+2163) | 7X'FA4D' | 7X'8757' | 7
| Roman numeral five (U+2164) | 7X'FA4E' | 7X'8758' | 7
| Roman numeral six (U+2165) | 7X'FA4F' | 7X'8759' | 7
| Roman numeral seven (U+2166) | 7X'FA50' | 7X'875A' | 7
| Roman numeral eight (U+2167) | 7X'FA51' | 7X'875B' | 7
| Roman numeral nine (U+2168) | 7X'FA52' | 7X'875C' | 7
| Roman numeral ten (U+2169) | 7X'FA53' | 7X'875D' | 7
| Parenthesized ideograph stock (U+3231) | 7X'FA58' | 7X'FA58' | 7
| Numero sign (U+2116) | 7X'FA59' | 7X'8782' | 7
| Telephone sign (U+2121) | 7X'FA5A' | 7X'8754' | 7
IBM products such as DB2 UDB primarily use IBM code points, such as X'FA4A' to 7present the upper case Roman numeral one 'I', but Microsoft products 7use X'8754' to represent the same character. An Microsoft ODBC 7application can insert the 'I' character as X'8754' into a DB2 UDB 7database of CCSID 943, and the DB2 UDB Control Center can insert the same 7character as X'FA4A' into the same CCSID 943 database. However, ODBC 7applications can find only those rows that have 'I' encoded as X'8754', 7and DB2 UDB Control Center can locate only those rows that have 'I' 7encoded as X'FA4A'. To enable DB2 UDB Control Center to select 'I' 7as X'8754', you need to replace the default IBM conversion tables between CCSID 943 and 7Unicode with the alternate Microsoft conversion tables.
The following list of characters, when converted from CCSID 943 to Unicode, 7will result in different code points depending on whether the IBM conversion table 7or the Microsoft conversion table is used. For these characters, 7the IBM conversion table conforms to the Japanese Industry Standard JISX0208, 7JISX0212, and JISX0221.
| Shift-JIS code point (character name) | 7IBM primary code point (Unicode name) | 7Microsoft primary code point (Unicode 7name) | 7
|---|---|---|
| X'815C' (EM dash) | 7U+2014 (EM dash) | 7U+2015 (Horizontal bar) | 7
| X'8160' (Wave dash) | 7U+301C (Wave dash) | 7U+FF5E (Fullwidth tilde) | 7
| X'8161' (Double vertical line) | 7U+2016 (Double vertical line) | 7U+2225 (Parallel to) | 7
| X'817C' (Minus sign) | 7U+2212 (Minus sign) | 7U+FF0D (Fullwidth hyphen-minus) | 7
| X'FA55' (Broken bar) | 7U+00A6 (Broken bar) | 7U+FFE4 (Fullwidth broken bar) | 7
For example, the character EM dash with the CCSID 943 code point of X'815C' 7is converted to the Unicode code point U+2014 when using the IBM conversion table. 7However, it is converted to U+2015 when using the Microsoft conversion 7table. Due to this difference of conversion mapping, you might have two different 7code points for the same character in a DB2 UDB Unicode database. This can create 7potential problems for Microsoft ODBC applications because they 7would treat U+2014 as an invalid code point. To avoid this potential problem, 7you need to replace the default IBM conversion tables between CCSID 943 and 7Unicode with the alternate Microsoft conversion tables.
7The use of the alternate Microsoft conversion tables between CCSID 7943 and Unicode should be restricted to closed environments, where the DB2 UDB 7clients and the DB2 UDB databases all have a code page of CCSID 943 and 7are all using the same alternate Microsoft conversion tables. If you have 7a DB2 UDB client using the default IBM conversion tables, and another DB2 UDB client using 7the alternate Microsoft conversion tables, and both clients are inserting 7data to the same DB2 UDB database of CCSID 943, the same character may be 7stored as different code points in the database.
7 7 7When you convert between CCSID 943 and Unicode, the DB2 Universal Database (UDB) default code page conversion tables are used. If you want to 7use a different version of the conversion tables, such as the Microsoft version, 7you must manually replace the default conversion table (.cnv) files.
7Before replacing the existing code page conversion table files in the sqllib/conv directory, you should back up the files 7in 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 7connects to the same database must have its conversion table changed. Otherwise 7the different clients might store the same character using different code 7points.
To replace the DB2 UDB default conversion tables for converting characters 7between CCSID 943 and Unicode:
7Despite 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.
2 2 2When accessing the Development Center on UNIX with Hummingbird Exceed, 2the XTEST extension version 2.2 must be enabled before you can move and dock 2views by dragging their title bars within the Development Center.
2To enable the XTEST extension:
2