Les marques de révision signalent le texte qui a été ajouté ou modifié. Une barre verticale ( | ) indique des informations ajoutées ou modifiées pour la version 8.2 FixPak 4 (équivalente de la version 8.1, FixPak 11).
Vous devrez probablement installer un produit DB2 à un niveau différent que celui de la version d'un produit DB2 actuellement sur votre ordinateur. Tous les produits DB2 doivent se situer sur un même niveau.
Si le produit que vous installez est d'un niveau plus récent que la version des produits DB2 installés sur l'ordinateur, vous devrez mettre à jour vos produits DB2 existants au niveau le plus récent. Par exemple, si vous installez DB2 Connect pour iSeries au niveau du Fixpak 10 et que vos autres produits DB2 sont au niveau du Fixpak 9, vous devrez appliquer le Fixpak 10 à tous vos produits DB2 avant d'installer DB2 Connect pour iSeries, Fixpak 10.
Inversement, si vous installez un produit sur un ordinateur qui dispose d'un produit DB2 avec une version plus récente, vous devez suivre les instructions suivantes :
db2licm -a nomfichieroù nomfichier est le nom du fichier de licence qui se trouve sur votre support original dans le répertoire db2\license. Vous pouvez également ajouter cette licence au répertoire db2\license du groupe de correctifs et la licence sera installée par le processus d'installation.
Avant d'installer un autre produit ou composant, vous devez arrêter les éléments suivants :
Les instances et le serveur DAS que vous devez arrêter sont ceux qui appartiennent à l'installation DB2 dans laquelle les produits et composants DB2 supplémentaires seront installés.
Vous obtiendrez des instructions supplémentaires en consultant le fichier Readme du FixPak.
Si votre système actuel ne dispose pas du serveur DAS DB2, et que le nouveau produit ou composant en a besoin ou le prend en charge, db2setup va configurer le serveur DAS DB2 au cours de l'installation. Sur certaines plateformes, des erreurs peuvent survenir au cours de la création du serveur DAS DB2 avec db2setup. Ces erreurs sont connues et peuvent être ignorées.
Le programme db2setup se situe sur l'image ou le CD du produit DB2 du produit ou composant supplémentaire que vous installez.
Pour obtenir des informations détaillées concernant l'utilisation de db2setup, consultez le Guide des commandes et le document relatif aux informations supplémentaires sur l'installation et la configuration.
Le script db2_install se situe sur l'image ou le CD du produit DB2 du produit ou composant supplémentaire que vous installez.
Pour obtenir des informations détaillées concernant l'utilisation du script db2_install, consultez le document d'informations supplémentaires sur l'installation et la configuration.
Pour obtenir des informations détaillées concernant l'utilisation du programme d'installation du système, consultez le document d'informations supplémentaires sur l'installation et la configuration.
Pour illustrer ce scénario, supposons que les conditions suivantes sont réunies :
L'étape de post-installation consiste en une nouvelle application du FixPak 10 courant.
Le package db2cliv81 est déjà installé sur le système. L'installation du module de correction nnnnnnn-nnn s'est terminée de façon anormale. Pour l'installer à nouveau, vous devez commencer par le désinstaller avant toute nouvelle tentative.Cette erreur se produit car le package db2cliv81 du système est déjà au même niveau que le groupe de correctifs installé. Vous pouvez ignorer ce genre d'erreur. Utilisez le programme d'installation système pour confirmer que le composant ou package DB2 est réellement au même niveau que le groupe de correctifs installé.
Si vous créez une base de données avec DB2 Universal Database version 8.2, vous ne pourrez pas l'utiliser au niveau de la version 8.1, mais uniquement au niveau de la version 8.2 ou ultérieure.
Les bases de données créées au niveau de DB2 UDB version 8.2 peuvent comporter des fonctionnalités supplémentaires non disponibles dans les versions antérieures. Ceci risque d'entraîner un comportement imprévu et inopportun si vous essayez d'utiliser votre nouvelle base de données à un niveau antérieur.
La section "Généralités concernant le client DB2" ("DB2 client |overview") du manuel Clients DB2 - Mise en |route spécifie ce qui suit :
Les clients DB2 peuvent se connecter aux serveurs DB2 de même niveau ou qui leur sont postérieurs de deux éditions ou antérieurs d'une édition.|
Cette affirmation doit être corrigée de la façon suivante :
|Si les connexions des clients de la version N aux serveurs de la version |N + 2 sont possibles dans certains environnements, l'équipe du support DB2 |prend en charge cette configuration tant que la version N est en service. Lorsqu'elle ne l'est plus, cette configuration n'est plus prise en charge. Ainsi, la connexion des clients DB2 version 7 à un serveur DB2 version 8 n'est |plus prise en charge par l'équipe du support DB2 car la version 7 a été retirée de |la commercialisation.
Toute modification du registre effectuée au niveau de DB2 UDB version 8.2 est perdue lors de la migration vers la version DB2 UDB version 8.1. Le registre revient au fichier HealthRules.reg de la version 8.1, dans lequel se trouvent les paramètres antérieurs à la mise à niveau vers DB2 UDB version 8.2 et à l'utilisation des paramètres du fichier HealthRules2.reg.
Avant DB2 Universal Database (UDB) version 8, les FixPaks ne fonctionnaient que comme des mises à jour de modules ou d'ensembles de fichiers DB2 (UDB) installés à un emplacement fixe. En d'autres termes, l'installation de FixPaks remplaçait les fichiers existants par des fichiers mis à jour fournis dans les FixPaks. En effet, plusieurs niveaux de FixPaks DB2 ne pouvaient pas coexister sur un système unique. Désormais, DB2 UDB Enterprise Server Edition (ESE) peut exister à différents niveaux de fixpack sur le même système pour les systèmes d'exploitation basés Linux et UNIX. Cette fonction, prise en charge par les environnements d'exploitation en production depuis la version 8.1.2, est mise en oeuvre à l'aide des deux types de FixPack suivants :
Pour mettre à jour une instance de FixPack multiple à un niveau de FixPack différent, effectuez l'une des opérations suivantes :
Pour plus d'informations concernant les FixPaks de remplacement :
Avec la version 8.2.2 (équivalente de la version 8.1, FixPak 9), le contenu de la table de contrôle TRACK_QUERY_INFO de Query Patroller enregistré dans un environnement 32 bits peut désormais être utilisé dans un environnement 64 bits. Cette fonctionnalité facilite la migration vers un environnement 64 bits. Les informations enregistrées dans la table de contrôle TRACK_QUERY_INFO de Query Patroller dans la version 8.2.2 ne permettent pas de générer des données d'historique pour cette requête ou d'exécuter des requêtes suspendues à un niveau de FixPak antérieur.
Les limitations suivantes s'appliquent à la prise en charge du serveur précédent pour Data Warehouse Center de DB2 Universal Database (UDB) Enterprise Server Edition version 8 :
Lors de l'utilisation du Centre de développement sur un Application Development Client (client de développement d'applications) pour DB2 Universal Database (UDB) version 8, sous Windows ou UNIX, les correctifs APAR suivants doivent être installés sur le serveur afin d'activer la prise en charge de SQLJ et SQL Assist :
Vous pouvez appeler les versions 7 et 8 de SQL Assist à partir de DB2 Universal Database, version 8. Il est possible de lancer la version 7 à partir de DB2 Data Warehouse Center. Tous les autres centres lancent la dernière version 8. L'aide en ligne du produit contient des informations complémentaires sur la version 7 de SQL Assist.
Dans la version 7, les serveurs Unicode ne prenaient pas en charge les pages de codes graphiques envoyées par les applications au moment de la connexion et partaient du principe que c'était UCS2 Unicode (page de codes 1200) qui était utilisé. Les serveurs Unicode en version 8 respectent maintenant la page de codes envoyée par le client.
DB2 UDB version 8.2 utilise un nouveau fichier (16 ko) de paramètres de configuration de la base de données intitulé SQLDBCONF. Il s'agit d'un fichier distinct du fichier SQLDBCON (4 ko) de paramètres de configuration de la base de données de DB2 UDB version 8.1.
Après la migration vers DB2 UDB version 8.2, le produit fait migrer le contenu du fichier SQLDBCON de la version 8.1 et consigne les changements de paramètres de configuration de la base de données dans le fichier SQLDBCONF. Le fichier SQLDBCON de la version 8.1 est conservé sans être utilisé.
Si vous effectuez une migration amont vers DB2 UDB version 8.1, le produit utilise alors à nouveau le fichier SQLDBCON de la version 8.1 pour consigner les changements de paramètres de configuration de la base de données. Le fichier SQLDBCONF de la version 8.2 est conservé, mais n'est pas reconnu par le produit DB2 UDB version 8.1. Les changements apportés au fichier de paramètres de configuration de la base de données entre la migration vers la version 8.2 et la migration amont vers la version 8.1 sont annulés car ils ne sont pas transmis au fichier SQLDBCON d'origine.
En outre, si vous migrez de nouveau vers DB2 UDB version 8.2, le produit DB2 UDB version 8.2 détecte l'existence du fichier SQLDBCONF de la version 8.2 et l'utilise à nouveau pour consigner les changements de paramètres de configuration de la base de données. Le fichier SQLDBCON de la version 8.1 est conservé, mais n'est pas reconnu par le produit DB2 UDB version 8.2. Les changements apportés au fichier de paramètres de configuration de la base de données, entre la migration amont vers la version 8.1 et la nouvelle migration vers la version 8.2 sont annulés car ils ne sont pas transmis au fichier SQLDBCONF existant.
Le format du fichier db2diag.log a fait l'objet de différentes améliorations pour la version 8.2. Il est maintenant plus facile de lire manuellement le fichier journal et de l'analyser par programme. Les améliorations sont les suivantes :
D'autres modifications ont été apportées, telles que le remplacement du nom de la zone base de données par DB.
Les enregistrements d'événements ont été ajoutés en tant que messages de diagnostic au fichier journal db2diag.log. Exemples d'événements :
Les enregistrements d'événements sont indiqués par la spécification "Event" dans la zone LEVEL. Bien que ces événements ne soient pas des erreurs, il se peut qu'ils soient consignés à des niveaux de diagnostic autres que 4 (Information) ou 3 (Avertissement) en fonction de leur importance.
Avec la version 8.2, les mises à jour ci-après sont désormais consignées dans le fichier db2diag.log :
Les messages relatifs à ces mises à jour sont consignés à des niveaux de diagnostic élevés en raison de leur importance.
Les types de mises à jour de registre des profils db2set consignés sont les suivants :
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
Exemples de mise à jour des paramètres de configuration de DB et DBM
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
Pour obtenir ces messages de mise à jour de configuration, utilisez l'outil db2diag. Par exemple :
La version 8.2.2 de DB2 Universal Database (UDB) pour Linux, UNIX et Windows, (équivalente de la version 8.1, FixPak 9), prend en charge JDK 1.4.2 dans tous les environnements de système d'exploitation de poste de travail 32 et 64 bits pris en charge par DB2 UDB. Cette prise en charge inclut, sans y être limitée, la construction et l'exécution d'applications client Java, la construction et l'exécution de routines Java à partir de la ligne de commande, la construction et l'exécution de routines Java à partir du Centre de développement DB2 qui les prend en charge ainsi que l'exécution d'autres outils DB2.
Lorsque vous installez la version 8.2 de DB2 UDB, la dernière version prise en charge du kit JDK l'est aussi, sauf si l'installation DB2 UDB est une mise à jour d'une précédente installation de la version 8 de DB2 UDB. Si vous mettez à jour une précédente installation de la version 8 de DB2 UDB, vous devez installer le kit JDK à partir du CD.
Le tableau ci-après indique les environnements de système d'exploitation de poste de travail 32 et 64 bits pris en charge par DB2 ainsi que le dernier niveau de JDK pris en charge par chacun d'eux. Pour des informations sur la prise en charge des précédentes versions de JDK, consultez la page Web Java Application Development à l'adresse suivante : http://www.ibm.com/software/data/db2/udb/ad/v8/java/.
| Environnement pris en charge par DB2 | Dernier niveau de JDK pris en charge |
|---|---|
| Windows IA/AMD 32 bits | JDK 1.4.2 |
| Windows IA 64 bits | JDK 1.4.2 |
| Windows AMD/EM64T 64 bits | JDK 1.4.2 |
| AIX 4.3.3 32 bits | JDK 1.3.1 SR6 [2] |
| AIX 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 bits, 64 bits (hybrid [1]) | JDK 1.4.2 [3] |
| Linux IA 32 bits | JDK 1.4.2 |
| Linux IA 64 bits | JDK 1.4.2 |
| Linux 390 31 bits | JDK 1.4.2 |
| Linux 390 64 bits | JDK 1.4.2 |
| Linux PPC (hybrid [1]) | JDK 1.4.2 |
Une procédure mise à jour de configuration de l'environnement Linux Java est fournie ci-après.
Pour construire des applications Java sous Linux avec une prise en charge DB2 JDBC :
Pour exécuter des procédures mémorisées Java ou des fonctions définies par l'utilisateur, l'éditeur de liens d'environnement d'exécution Linux doit pouvoir accéder à certaines bibliothèques partagées Java ; DB2 UDB doit en outre pouvoir charger ces bibliothèques et la machine virtuelle Java. Le processus qui exécute les procédures mémorisées et les fonctions définies par l'utilisateur charge les bibliothèques dans des emplacements sécurisés uniquement, tel que défini dans le fichier /etc/ld.so.conf. /usr/lib est l'un de ces emplacements sécurisés. Les autres instructions indiquent quelles bibliothèques requièrent des liens symboliques dans /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 .où JAVAHOME est le répertoire principal du IBM Developer Kit. Si DB2 UDB ne trouve pas ces bibliothèques, vous recevrez une erreur avec le code -4301 lorsque vous tenterez d'exécuter une routine Java ; en outre, des messages seront générés dans le journal de notification de l'administration indiquant des bibliothèques non trouvées.
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.sooù JAVAHOME est le répertoire principal pour IBM Developer Kit. Si DB2 UDB ne trouve pas ces bibliothèques, vous recevrez une erreur avec le code -4301 lorsque vous tenterez d'exécuter une routine Java ; en outre, des messages seront générés dans le journal de notification de l'administration indiquant des bibliothèques non trouvées.
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.sooù JAVAHOME est le répertoire principal pour IBM Developer Kit. Si DB2 UDB ne trouve pas ces bibliothèques, vous recevrez une erreur avec le code -4301 lorsque vous tenterez d'exécuter une routine Java ; en outre, des messages seront générés dans le journal de notification de l'administration indiquant des bibliothèques non trouvées.
JAVAHOME/jre/binoù JAVAHOME est le répertoire principal pour IBM Developer Kit. Si DB2 UDB ne trouve pas ces bibliothèques, vous recevrez une erreur avec le code -4301 ou -1042 lorsque vous tenterez d'exécuter une routine Java.
Au lieu de créer explicitement des liens vers les bibliothèques partagées dans le répertoire /usr/lib, vous pouvez ajouter le nom du répertoire qui stocke les bibliothèques partagées Java dans le fichier /etc/ld.so.conf. Ce fichier requiert une autorisation root. Après la mise à jour de /etc/ld.so.conf , vous devez lancer la commande ldconfig en tant qu'utilisateur root afin d'activer ces modifications. Si vous rencontrez des difficultés avec cette autre procédure, créez les liens dans le répertoire /usr/lib, comme indiqué précédemment.
Si vous utilisez le système d'exploitation Microsoft XP 64 bits (2600) configuré pour l'utilisation du protocole NETBIOS avec la famille de produits DB2, Microsoft doit vous fournir un correctif logiciel. Contactez Microsoft en indiquant le numéro d'article Q317437 de la base de connaissances.
Le système d'exploitation Windows XP Home Edition est uniquement pris en charge par les produits DB2 Universal Database (UDB) Personal Edition.
Le système d'exploitation Windows XP Professionel est pris en charge par les produits DB2 suivants :
Les produits DB2 ci-après sont pris en charge sous Windows XP à des fins de développement ou de test uniquement (les environnements de production requièrent Windows 2000 ou Windows Server 2003) :
Dans DB2 Universal Database (UDB) version 8.2, les détenteurs de DB2 UDB Workgroup Server Edition et DB2 UDB Express Edition (licence attribuée par utilisateur) n'ont pas pu installer l'option HADR (High Availability Disaster Recovery) de DB2 UDB, vendue séparément. Ce problème est résolu dans DB2 UDB Version 8.2 FixPak 1 (équivalent de Version 8.1 FixPak 8).
Les utilitaires OLAP de DB2 Warehouse Manager Standard Edition, version 8.2, ne sont pas compatibles avec IBM DB2 OLAP Server FP3 (API Essbase niveau 6.5.4) et ultérieur. Il est recommandé d'utiliser DB2 OLAP Server FP2 (Essbase 6.5.3) ou antérieur tant que ce problème n'est pas résolu.
Avant la version 8.2.2 (équivalente de la version 8.1, FixPak 9) de DB2 Universal Database (UDB), l'utilisation de journaux avec des périphériques d'E-S brutes nécessitait de relier une unité physique du pilote de périphérique par caractère brut Linux à l'utilitaire brut. Avec la version 8.2.2 de DB2 UDB (équivalent de la version 8.1, FixPak 9), sur le noyau Linux 2.6, les E-S brutes pour les journaux peuvent être indiquées directement. Par exemple, pour utiliser la partition /dev/sdb1 pour les journaux bruts pour la base de données SAMPLE, vous exécuterez la commande suivante :
db2 update db cfg for sample using newlogpath /dev/sdb1
Bien que DB2 UDB prenne toujours en charge la méthode d'utilisation de l'utilitaire brut pour les E-S brutes, cette méthode devient dépassée dans les distributions récentes et risque d'être supprimée dans le futur. Nous vous conseillons d'utiliser la nouvelle méthode qui consiste à indiquer directement un périphérique.
La version 8.2 de DB2 Universal Database prend en charge les versions 3 et 2.1 de Red Hat Enterprise Linux AS. Toutefois, Data Warehouse Center ne prend en charge que Red Hat Enterprise Linux AS, version 2.1. Data Warehouse Center utilise des pilotes ODBC DataDirect non compatibles avec Red Hat Enterprise Linux AS, version 3.1. Par conséquent, Data Warehouse Center ne prend pas en charge les sources et cibles d'entrepôt ODBC d'un site agent Red Hat Enterprise Linux AS, version 3.1.
Lorsque vous exécutez des applications dans un environnement IBM WebSphere MQ (anciennement connu sous IBM MQSeries), WebSphere MQ peut agir comme un gestionnaire de transactions compatible XA, coordonnant toute transaction distribuée de validation en deux phases. Lorsque WebSphere MQ agit en tant que gestionnaire de transactions et que les sources de données proviennent de la famille de produits DB2, votre configuration doit remplir plusieurs conditions. La plupart de ces conditions sont déjà documentées. Par exemple, vous devez définir le paramètre de configuration DB2 TP_MON_NAME sur "MQ" dans le client d'exécution DB2.
Toutefois, une de ces conditions n'a pas été documentée. Cette condition est spécifique à DB2 Connect lors de la connexion à des sources de données qui sont des serveurs DB2 pour OS/390 : si vous utilisez WebSphere MQ pour coordonner les transactions réparties impliquant des serveurs DB2 pour z/OS et DB2 iSeries, la fonction du concentrateur de connexions de DB2 Connect doit être activée au niveau de la passerelle. Le concentrateur de connexions est activé lorsque la valeur du paramètre de configuration MAX_CONNECTIONS est supérieure à la valeur du paramètre MAX_COORDAGENTS. Si vous n'activez pas le concentrateur de connexions, un comportement de transaction inattendu peut se produire.
La page de codes de Microsoft Windows en japonais avec codage SJIS est enregistrée en tant qu'ID de jeu de caractères codés (CCSID) IBM 943. En revanche, la page de codes avec codage SJIS sous une plateforme HP-UX est enregistrée en tant que CCSID 5039. CCSID 5039 ne contient que des caractères répondant à la norme JIS (Japanese Industry Standard) et aucun caractère défini par le fournisseur. Vous pouvez utiliser une base de données DB2 Universal Database (UDB) dotée du CCSID 5039 sous HP-UX pour stocker les caractères de codage SJIS, mais cela engendrera une conversion de la page de codes du format CCSID 5039 au format CCSID 943. Si vous utilisez des applications Microsoft ODBC, il se peut qu'un incident survienne lors de la conversion des données CCSID 5039 au format Unicode, en raison des différences entre la table de conversion des pages de codes d'IBM et celle de Microsoft.
Lors de la conversion de la liste de caractères ci-dessous du format CCSID 5039 au format Unicode, vous obtiendrez des points de code qui varient en fonction de la table de conversion utilisée (IBM ou Microsoft). Pour ces caractères, la table de conversion d'IBM répond aux normes JIS JISX0208 et JISX0221.
| Point de code avec codage SJIS (nom de caractère) | Point de code primaire d'IBM (nom Unicode) | Point de code primaire de Microsoft (nom Unicode) |
|---|---|---|
| X'815C' (tiret cadratin) | U+2014 (tiret cadratin) | U+2015 (barre horizontale) |
| X'8160' (tilde) | U+301C (tilde) | U+FF5E (tilde pleine largeur) |
| X'8161' (double ligne verticale) | U+2016 (double ligne verticale) | U+2225 (parallèle à) |
| X'817C' (signe moins) | U+2212 (signe moins) | U+FF0D (trait d'union pleine largeur) |
Par exemple, le tiret cadratin utilisé avec le point de code CCSID 5039 X'815C' est converti en point de code Unicode U+2014 si vous utilisez la table de conversion d'IBM et en U+2015 si vous utilisez celle de Microsoft. Cela peut engendrer des problèmes avec les applications Microsoft ODBC car celles-ci considéreront U+2014 comme un point de code non valide. Pour éviter ce type de problème, DB2 UDB fournit, en plus de la table de conversion par défaut d'IBM, la table de remplacement de Microsoft qui indique les conversions du format CCSID 5039 au format Unicode. Vous devez remplacer la table de conversion par défaut d'IBM par la table de conversion de remplacement de Microsoft. Notez que la table de conversion par défaut d'IBM indiquant les conversions du format Unicode au format CCSID 5039 est compatible avec la version de Microsoft.
Lorsque vous convertissez des données CCSID 5039 au format Unicode, le système utilise la table de conversion de la page de codes par défaut de DB2 Universal Database (UDB). Si vous souhaitez utiliser une autre version de table de conversion, celle de Microsoft par exemple, vous devez remplacer manuellement le fichier (.cnv) de table de conversion par défaut.
Avant de remplacer le fichier de table de conversion dans le répertoire sqllib/conv, il est recommandé d'enregistrer ce fichier au cas où vous voudriez le rétablir. Sous UNIX et Linux, le répertoire sqllib/conv pointe vers le chemin d'installation de DB2 UDB.
Pour que le remplacement des tables de conversion soit effectif, chaque client DB2 UDB se connectant à la même base de données doit changer de table de conversion, sinon les différents clients risquent d'enregistrer des points de code différents pour un même caractère.
Pour remplacer la table de conversion par défaut de DB2 UDB, permettant de convertir les données CCSID 5039 au format Unicode, procédez comme suit :
L'ID de jeu de caractères codés (CCSID) d'IBM pour la page de codes EUC en japonais est enregistré en tant que CCSID 954. CCSID 954 est un codage habituel pour les plateformes UNIX et Linux en japonais. Si vous utilisez des applications Microsoft ODBC pour vous connecter à une base de données DB2 Universal Database (UDB) dotée du CCSID 954, il se peut que vous rencontriez un problème lors de la conversion des données CCSID 954 au format Unicode. en raison des différences entre la table de conversion des pages de codes d'IBM et celle de Microsoft. La table de conversion d'IBM respecte les noms de caractères spécifiés par les normes (JIS) JISX0208, JISX0212 et JISX0221.
Lors de la conversion des caractères ci-dessous du format CCSID 954 au format Unicode, vous obtiendrez des points de code qui varient en fonction de la table de conversion utilisée (IBM ou Microsoft).
| Point de code EUC-JP (nom de caractère) | Point de code primaire d'IBM (nom Unicode) | Point de code primaire de Microsoft (nom Unicode) |
|---|---|---|
| X'A1BD' (tiret cadratin) | U+2014 (tiret cadratin) | U+2015 (barre horizontale) |
| X'A1C1' (tilde) | U+301C (tilde) | U+FF5E (tilde pleine largeur) |
| X'A1C2' (double ligne verticale) | U+2016 (double ligne verticale) | U+2225 (parallèle à) |
| X'A1DD' (signe moins) | U+2212 (signe moins) | U+FF0D (trait d'union pleine largeur) |
| X'8FA2C3' (tirets verticaux) | U+00A6 (tirets verticaux) | U+FFE4 (tirets verticaux pleine largeur) |
Par exemple, le tiret cadratin utilisé avec le point de code CCSID 954 X'A1BD' est converti en point de code Unicode U+2014 si vous utilisez la table de conversion d'IBM et en U+2015 si vous utilisez celle de Microsoft. A cause de cette différence de mappage des conversions, vous risquez d'avoir deux points de code différents pour un même caractère dans une base de données DB2 UDB Unicode ou dans une colonne graphique d'une base de données DB2 UDB 954. Cela peut engendrer des problèmes avec les applications Microsoft ODBC car celles-ci considéreront U+2014 comme un point de code non valide. Pour éviter ce type de problème, DB2 UDB fournit, en plus de la table de conversion par défaut d'IBM, la table de remplacement de Microsoft qui indique les conversions du format CCSID 954 au format Unicode. Vous devez remplacer la table de conversion par défaut d'IBM par la table de conversion de remplacement de Microsoft. Notez que la table de conversion par défaut d'IBM, indiquant les conversions du format Unicode au format CCSID 954, est compatible avec la version de Microsoft.
Lorsque vous convertissez des données CCSID 954 au format Unicode, le système utilise la table de conversion de la page de codes par défaut de DB2 Universal Database (UDB). Si vous souhaitez utiliser une autre version de table de conversion, celle de Microsoft par exemple, vous devez remplacer manuellement le fichier (.cnv) de table de conversion par défaut.
Avant de remplacer le fichier de table de conversion dans le répertoire sqllib/conv, il est recommandé d'enregistrer ce fichier au cas où vous voudriez le rétablir. Sous UNIX et Linux, le répertoire sqllib/conv est lié au chemin d'installation de DB2 UDB.
Pour que le remplacement soit effectif, chaque client DB2 UDB qui se connecte à une même base de données CCSID 954 doit changer de table de conversion. Si votre client est Windows en japonais, avec une page de codes ANSI au codage SJIS (CCSID 943), vous devrez également remplacer les tables de conversion CCSID 943/Unicode par défaut de DB2 par la version de Microsoft. sinon les différents clients risquent d'enregistrer des points de code différents pour un même caractère.
Pour remplacer la table de conversion par défaut de DB2 UDB, permettant de convertir les données CCSID 954 au format Unicode, procédez comme suit :
Pour remplacer les tables de conversion par défaut de DB2 UDB, permettant de convertir les données CCSID 943 au format Unicode, procédez comme suit :
Lorsque vous utilisez la page de codes de Microsoft Windows en japonais avec codage SJIS, qui est enregistrée en tant qu'ID de jeu de caractères codés (CCSID) IBM 943, il se peut que vous rencontriez les deux problèmes suivants lors de la conversion des caractères du format CCSID 943 au format Unicode. Cette éventualité est due aux différences entre la table de conversion des pages de codes IBM et celle de Microsoft. Afin d'éviter ce type d'incident, DB2 Universal Database (UDB) fournit, outre les tables de conversion par défaut d'IBM, les tables de remplacement de Microsoft pour les conversions du format CCSID 943 au format Unicode.
Pour des raisons d'historique, environ 300 caractères sont représentés par deux ou trois points de code chacun dans la page de codes CCSID 943. Avec l'utilisation des éditeurs de méthode d'entrée(IMEs) et de tables de conversion de page de codes, un seul de ces points de code équivalents peut être entré. Par exemple, le caractère correspondant au chiffre romain "un" en lettre minuscule'i' a deux points de code équivalents : X'EEEF' et X'FA40'. Les IME Microsoft Windows génèrent toujours X'FA40' lorsque 'i' est entré. En général, IBM et Microsoft utilisent le même point de code primaire pour représenter un caractère, à l'exception des 13 caractères suivants :
| Nom de caractère (point de code Unicode) | Point de code primaire Shift-JIS IBM | Point de code primaire Shift-JIS Microsoft |
|---|---|---|
| Chiffre romain "un" (U+2160) | X'FA4A' | X'8754' |
| Chiffre romain "deux" (U+2161) | X'FA4B' | X'8755' |
| Chiffre romain "trois" (U+2162) | X'FA4C' | X'8756' |
| Chiffre romain "quatre" (U+2163) | X'FA4D' | X'8757' |
| Chiffre romain "cinq" (U+2164) | X'FA4E' | X'8758' |
| Chiffre romain "six" (U+2165) | X'FA4F' | X'8759' |
| Chiffre romain "sept" (U+2166) | X'FA50' | X'875A' |
| Chiffre romain "huit" (U+2167) | X'FA51' | X'875B' |
| Chiffre romain "neuf" (U+2168) | X'FA52' | X'875C' |
| Chiffre romain "dix" (U+2169) | X'FA53' | X'875D' |
| Stock d'idéogrammes entre parenthèses (U+3231) | X'FA58' | X'FA58' |
| Signe de numéro (U+2116) | X'FA59' | X'8782' |
| Signe de téléphone (U+2121) | X'FA5A' | X'8754' |
Les produits IBM comme DB2 UDB utilisent principalement des points de code IBM tels X'FA4A' pour représenter le chiffre romain 'I', mais les produits Microsoft utilisent X'8754' pour représenter ce même caractère. Avec une application Microsoft ODBC, il est possible d'insérer le caractère 'I' sous la forme X'8754' dans une base de données DB2 UDB CCSID 943. Le Centre de contrôle DB2 UDB permet d'insérer le même caractère sous la forme X'FA4A' dans la même base de données CCSID 943. Toutefois, les applications ODBC ne peuvent rechercher que les lignes contenant 'I' codé sous la forme X'8754', et le Centre de contrôle DB2 UDB ne peut localiser que les lignes contenant 'I' codé sous la forme X'FA4A'. Pour que le Centre de contrôle DB2 UDB puisse sélectionner 'I' sous la forme X'8754', vous devez remplacer les tables de conversion par défaut CCSID 943/Unicode d'IBM par les tables de remplacement de Microsoft.
Lors de la conversion de la liste de caractères ci-dessous du format CCSID 943 au format Unicode, vous obtiendrez des points de code qui varient en fonction de la table de conversion utilisée (IBM ou or the Microsoft). Pour ces caractères, la table de conversion IBM répond aux normes JIS (Japanese Industry Standard) JISX0208, JISX0212 et JISX0221.
| Point de code avec codage SJIS (nom de caractère) | Point de code primaire d'IBM (nom Unicode) | Point de code primaire de Microsoft (nom Unicode) |
|---|---|---|
| X'815C' (tiret cadratin) | U+2014 (tiret cadratin) | U+2015 (barre horizontale) |
| X'8160' (tilde) | U+301C (tilde) | U+FF5E (tilde pleine largeur) |
| X'8161' (double ligne verticale) | U+2016 (double ligne verticale) | U+2225 (parallèle à) |
| X'817C' (signe moins) | U+2212 (signe moins) | U+FF0D (trait d'union pleine largeur) |
| X'FA55' (barre verticale interrompue) | U+00A6 (tirets verticaux) | U+FFE4 (tirets verticaux pleine largeur) |
Par exemple, le tiret cadratin utilisé avec le point de code CCSID 943 X'815C' est converti en point de code Unicode U+2014 si vous utilisez la table de conversion d'IBM. Cependant, il est converti en U+2015 si vous utilisez la table de conversion Microsoft. A cause de cette différence de mappage des conversions, vous risquez d'avoir deux points de code différents pour un même caractère dans une base de données DB2 UDB Unicode. Cela peut engendrer des problèmes avec les applications Microsoft ODBC car celles-ci considéreront U+2014 comme un point de code non valide. Pour éviter ce type de problème, remplacez les tables de conversion par défaut CCSID 943/Unicode d'IBM par les tables de remplacement de Microsoft.
L'utilisation de tables de remplacement de Microsoft pour la conversion CCSID 943/Unicode devrait être limitée aux environnements fermés, où les clients et les bases de données DB2 UDB ont tous une page de codes CCSID 943 et utilisent les mêmes tables de remplacement Microsoft. Si un client DB2 UDB utilise les tables de conversion par défaut d'IBM tandis qu'un autre client DB2 UDB utilise les tables de remplacement de Microsoft et que les deux clients insèrent des données dans la même base de données DB2 UDB dotée du CCSID 943, le même caractère pourra être enregistré sous forme de différents points de codes dans la base de données.
Lors de la conversion des données CCSID 943 au format Unicode, le système utilise les tables de conversion de la page de codes par défaut de DB2 Universal Database (UDB). Si vous souhaitez utiliser une autre version des tables de conversion, celle de Microsoft par exemple, vous devez remplacer manuellement les fichiers (.cnv) de la table de conversion par défaut.
Avant de remplacer les fichiers de tables de conversion dans le répertoire sqllib/conv, il est recommandé d'enregistrer ces fichiers au cas où vous voudriez les rétablir. Sous UNIX et Linux, le répertoire sqllib/conv pointe vers le chemin d'installation de DB2 UDB.
Pour que le remplacement des tables de conversion soit effectif, chaque client DB2 UDB se connectant à la même base de données doit changer de table de conversion, sinon ils risquent d'enregistrer différents points de code pour un même caractère.
Pour remplacer les tables de conversion par défaut de DB2 UDB, permettant de convertir les données CCSID 943 au format Unicode, procédez comme suit :
Contrairement à ce qui est indiqué dans la documentation, le système d'exploitation MVS n'est plus pris en charge par DB2 Universal Database. MVS a été remplacé par z/OS.
Les opérations de sauvegarde et de restauration vers et à partir de plusieurs unités de bande risquent de ne pas fonctionner si vous utilisez le système d'exploitation Linux 390.
Lorsque vous accédez au Centre de développement sous UNIX à l'aide de Hummingbird Exceed, vous devez activer l'extension XTEST version 2.2 pour pouvoir, déplacer et faire basculer les vues dans le Centre de développement en déplaçant leurs barres de titre.
Pour activer l'extension XTEST, procédez comme suit :