Marcas de revisão indicam texto que foi incluído ou alterado. Uma barra vertical ( | ) indica informações que foram incluídas ou alteradas para a Versão 8.2 FixPak 4 (equivalente à Versão 8.1 FixPak 11).
Talvez você precise instalar um produto DB2(R) que esteja em nível diferente da versão do outro produto DB2(R) que esteja instalado atualmente no computador. Solicita-se que os produtos de DB2 estejam no mesmo nível.
Se o produto que você está instalando é de um nível mais recente que a versão dos outros produtos DB2 instalados no mesmo computador, será necessário atualizar seus produtos DB2 existentes para o nível mais recente. Por exemplo, se você estiver instalando o DB2 Connect(TM) para iSeries(TM) em um nível de Fixpak 10 e os seus outros produtos DB2 estiverem no nível de Fixpak 9, será necessário aplicar o Fixpak 10 aos produtos DB2 instalados no momento antes de instalar o DB2 Connect(TM) para iSeries(TM) no nível de Fixpak 10.
Opcionalmente, se você estiver instalando um produto em um computador que possua uma versão mais recente de um produto DB2 instalado, há algumas orientações a serem seguidas:
db2licm -a filenameem que filename é o nome do arquivo de licença, que pode ser localizado em sua mídia original no diretório db2\license. Você também pode incluir essa licença no diretório db2\license do fixpak e a licença será instalada pela instalação.
Antes de você instalar um produto ou componente extra, é necessário parar os itens a seguir:
As instâncias e o DAS que devem ser parados são aqueles que pertencem à instalação do DB2 em que o produto ou componente do DB2 extra será instalado.
Consulte o Leia-me do FixPak para obter instruções adicionais.
Se o DB2 DAS não existir no sistema atual e o componente ou produto extra requerer ou suportar o DB2 DAS, o db2setup configurará o DB2 DAS durante a instalação. Em algumas plataformas, podem ocorrer erros durante a criação do DB2 DAS com db2setup. Esses erros são esperados e podem ser ignorados.
O programa db2setup pode ser encontrado no CD ou na imagem do produto DB2 para o componente ou produto extra que você está instalando.
Consulte o guia Command Reference e o Suplemento de Instalação e Configuração para obter informações detalhadas sobre a utilização do db2setup.
O script db2_install pode ser encontrado no CD ou na imagem do produto DB2 para o componente ou produto extra que você está instalando.
Consulte o Suplemento de Instalação e Configuração para obter informações detalhadas sobre a utilização do script db2_install.
Consulte Suplemento de Instalação e Configuração para obter informações detalhadas sobre a utilização do instalador de sistema.
Para ilustrar esse cenário, assuma as seguintes condições:
Como uma etapa de pós-instalação, você deve aplicar novamente o FixPak 10 regular.
O pacote db2cliv81 já está instalado no sistema. A correção da instalação nnnnnnn-nnn finalizou de forma anormal. Para reinstalar essa correção, desinstale-a primeiro antes de tentar reinstalá-la.Esse erro ocorre porque o db2cliv81 no sistema já está no mesmo nível que o nível do fixpak que está sendo instalado. Você pode ignorar esse tipo de erro. Utilize o instalador de sistema para confirmar que o pacote ou componente do DB2 está realmente no mesmo nível do fixpak sendo instalado.
Se você criar um banco de dados com o DB2 Universal Database Versão 8.2, não será possível utilizar esse banco de dados em um nível da Versão 8.1. Esse banco de dados somente poderá ser utilizado em um nível da Versão 8.2 ou posterior.
Os bancos de dados criados no nível DB2 UDB Versão 8.2 podem ter funcionalidade adicional que não estava disponível em versões anteriores. Essa diferença pode resultar em um comportamento inesperado e indesejável se você tentar mover seu novo banco de dados para um release anterior do DB2 UDB.
A seção "Visão Geral do Cliente DB2" do manual Iniciação |Rápida para Clientes do DB2 afirma o seguinte:
Os clientes DB2 podem se conectar a servidores DB2 dois releases posteriores ou um release |anterior no nível de release do cliente e também a servidores no mesmo nível de release.|
Uma emenda para essa instrução é a seguinte:
|Embora as conexões de clientes |da Versão N com servidores da Versão N + 2 sejam possíveis em alguns ambientes, |a equipe de suporte do DB2 fornecerá suporte para esta configuração apenas se |a Versão N ainda estiver funcionando. Quando a Versão N é retirada de funcionamento, |esta configuração não é mais suportada pela equipe de suporte do DB2. Os clientes do DB2 Versão 7 que se conectam a um servidor DB2 Versão 8 não são mais suportados pela equipe de suporte do DB2, porque a Versão 7 foi retirada de funcionamento.
Todas as alterações de registro feitas no nível DB2 UDB Versão 8.2 são perdidas quando você migra de volta para o DB2 UDB Versão 8.1. O registro é revertido para o arquivo HealthRules.reg da versão 8.1 que contém as configurações que existiam antes de você fazer upgrade para o DB2 UDB Versão 8.2 e começar a utilizar as configurações no arquivo HealthRules2.reg.
Antes do DB2 UDB (Universal Database) Versão 8, os FixPaks funcionavam apenas como atualizações para pacotes ou conjuntos de arquivos do DB2 UDB instalados em um local fixo. Isso significa que a instalação de FixPaks substituiu os arquivos existentes pelos atualizados, fornecidos nos FixPaks. Vários níveis do DB2 FixPak não podem existir em um único sistema. O DB2 UDB ESE (Enterprise Server Edition) pode existir em vários níveis de fix pack no mesmo sistema para sistemas operacionais baseados em Linux(TM) e UNIX(R). Este recurso, suportado em ambientes operacionais de produção desde a Versão 8.1.2, é obtido utilizando os dois tipos de FixPak a seguir:
Para atualizar uma instância de vários FixPaks em um nível diferente de FixPak, execute uma das seguintes opções:
Para obter informações adicionais relativas a FixPaks alternativos:
Iniciando com a Versão 8.2.2, (equivalente à Versão 8.1 FixPak 9), o conteúdo da tabela de controle do Query Patroller TRACK_QUERY_INFO que foi capturado em um ambiente de 32 bits pode ser utilizado em um ambiente de 64 bits. Esse recurso facilita o esforço de migração para um ambiente de 64 bits. As informações capturadas na tabela de controle do Query Patroller TRACK_QUERY_INFO na Versão 8.2.2 não podem ser utilizadas para gerar dados históricos para essa consulta ou para executar consultas mantidas no nível de FixPak anterior.
As limitações a seguir existem para suporte ao servidor anterior para o DB2 UDB (Universal Database) Enterprise Server Edition Versão 8 Data Warehouse Center:
Ao utilizar o Development Center em um cliente do Application Development para o DB2 UDB (Universal Database) Versão 8 em sistemas operacionais Windows ou UNIX, os seguintes APARs precisarão ser instalados no servidor para ativar o suporte a SQLJ e SQL Assist:
É possível chamar a Versão 7 e a Versão 8 do SQL Assist a partir do DB2 Universal Database, Versão 8. É possível iniciar a Versão 7 a partir do Data Warehouse Center do DB2. Todos os outros centros iniciam a Versão 8 mais recente. A ajuda on-line do produto possui informações adicionais para o SQL Assist, Versão 7.
Na Versão 7, os servidores Unicode ignoravam todas as páginas de códigos de gráficos enviadas pelos aplicativos no momento da conexão e assumiam que o UCS2 Unicode (página de códigos 1200) estava sendo utilizado. Agora, os servidores Unicode Versão 8 respeitam a página de códigos enviada pelo cliente.
O DB2 UDB Versão 8.2 utiliza um novo arquivo de parâmetro de configuração de banco de dados de 16K denominado SQLDBCONF. Este é um arquivo separado do arquivo de parâmetro de configuração de banco de dados de 4K do DB2 UDB Versão 8.1 denominado SQLDBCON.
Depois de migrar para o DB2 UDB Versão 8.2, o produto migra o conteúdo do arquivo de 4K da Versão 8.1 e utiliza o arquivo de 16K para registrar as alterações do parâmetro de configuração de banco de dados. O arquivo de 4K da Versão 8.1 é retido, mas não é utilizado.
Se você migrar de volta para o DB2 UDB Versão 8.1, o produto DB2 UDB Versão 8.1 volta a utilizar o arquivo de 4K da Versão 8.1 original para registrar alterações do parâmetro de configuração de banco de dados. O arquivo de 16K da Versão 8.2 é retido, mas não é reconhecido pelo produto DB2 UDB Versão 8.1. As alterações feitas no arquivo do parâmetro de configuração de banco de dados de 16K entre migrar para a Versão 8.2 e migrar de volta para a Versão 8.1 são, na verdade, ocultas do nível do DB2 UDB anterior porque as alterações não são migradas para o arquivo de 4K original.
Além disso, se você migrar para o DB2 UDB Versão 8.2 novamente, o produto DB2 UDB Versão 8.2 reconhece que o arquivo de configuração de banco de dados de 16K já existe e volta a utilizar o arquivo de 16K da Versão 8.2 para registrar as alterações do parâmetro de configuração de banco de dados. O arquivo de 4K da Versão 8.1 é retido, mas não é reconhecido pelo produto DB2 UDB Versão 8.2. As alterações feitas no arquivo do parâmetro de configuração de banco de dados de 4K entre migrar de volta para a Versão 8.1 e migrar novamente para a Versão 8.2 são, na verdade, ocultas do nível do DB2 UDB mais recente porque as alterações não são migradas para o arquivo de 16K existente.
O formato do arquivo db2diag.log foi aprimorado de várias maneiras para a Versão 8.2. O arquivo de registro agora ficou mais fácil de ser lido e mais fácil de ser analisado no software. Os aperfeiçoamentos incluem:
Também foram feitas outras alterações, tais como: a alteração do nome de campo do banco de dados para DB.
Foram incluídos registros de eventos como mensagens de diagnósticos no arquivo db2diag.log. Exemplos de tais eventos são:
Os registros de eventos possuem "Evento" especificado no campo LEVEL. Embora os eventos não sejam erros, eles podem ser registrados nos níveis de diagnósticos diferentes de 4 (Informativo) ou 3 (Aviso), dependendo de sua importância.
Iniciando com a Versão 8.2, as atualizações a seguir são registradas no arquivo db2diag.log:
As mensagens para essas atualizações são registradas nos níveis de diagnóstico alto devido à sua importância.
Estão registrados os seguintes tipos de atualizações de registro de perfil db2set:
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
Exemplos de atualizações de parâmetros de configuração do DD e DBM são
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
Para localizar estas mensagens de atualização de configuração, utilize a ferramenta db2diag. Exemplo:
O DB2 UDB (Universal Database(TM)) para Linux, UNIX, e Windows(R), Versão 8.2.2 (equivalente à Versão 8.1 FixPak 9) suporta o JDK 1.4.2 em todos os ambientes de sistema operacional de estação de trabalho de 32 bits e de 64 bits suportados pelo DB2 UDB. Esse suporte inclui, mas não está limitado ao suporte para construção e execução de aplicativos clientes Java(TM), construção e execução de rotinas Java(TM) a partir da linha de comandos, construção e execução das rotinas Java(TM) a partir do DB2 Development Center, em que é suportado, assim como para a execução de outras ferramentas do DB2.
Ao instalar o DB2 UDB, Versão 8.2, a última versão suportada do Java Developer Kit também será instalada, se ainda não estiver instalada, a menos que a instalação do DB2 UDB seja uma atualização de uma instalação anterior do DB2 UDB, Versão 8. Se estiver atualizando uma instalação anterior do DB2 UDB, Versão 8, será necessário instalar o Java Developer Kit a partir do CD.
A tabela a seguir indica os ambientes do sistema operacional da estação de trabalho de 32 bits e 64 bits suportados pelo DB2 e o último nível do JDK suportado para cada um deles. Para obter informações sobre o suporte a JDK mais recente, consulte a página da Web do Java Application Development no http://www.ibm.com/software/data/db2/udb/ad/v8/java/.
| Ambiente Suportado do DB2 | Último Nível do JDK Suportado |
|---|---|
| Windows IA/AMD de 32 bits | JDK 1.4.2 |
| Windows IA de 64 bits | JDK 1.4.2 |
| Windows AMD/EM64T de 64 bits | JDK 1.4.2 |
| AIX(R) 4.3.3 de 32 bits | 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 de 32 bits e 64 bits (hybrid [1]) | JDK 1.4.2 [3] |
| Linux IA de 32 bits | JDK 1.4.2 |
| Linux IA de 64 bits | JDK 1.4.2 |
| Linux 390 de 31 bits | JDK 1.4.2 |
| Linux 390 de 64 bits | JDK 1.4.2 |
| Linux PPC (hybrid [1]) | JDK 1.4.2 |
Um procedimento de atualização para a configuração do Ambiente Linux Java é fornecido a seguir.
Para construir os aplicativos Java no Linux com suporte a DB2 JDBC:
Para executar procedimentos armazenados Java ou funções definidas pelo usuário, o Linux Runtime Linker deve ser capaz de acessar certas bibliotecas compartilhadas Java e o DB2 UDB deve ser capaz de carregar tais bibliotecas, bem como a Java Virtual Machine. O processo que executa procedimentos armazenados e funções definidas pelo usuário carrega bibliotecas apenas em locais seguros, como definido no arquivo /etc/ld.so.conf. Um desses locais seguros é /usr/lib. As instruções restantes mostram qual biblioteca requer links simbólicos em /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 .em que JAVAHOME é o diretório base para o IBM(R) Developer Kit. Se não for possível ao DB2 UDB localizar essas bibliotecas, você receberá um erro -4301 ao tentar executar uma rotina Java e haverá mensagens no registro de notificação de administração sobre as bibliotecas não localizadas.
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.soem que JAVAHOME é o diretório base para o IBM Developer Kit. Se não for possível ao DB2 UDB localizar essas bibliotecas, você receberá um erro -4301 ao tentar executar uma rotina Java e haverá mensagens no registro de notificação de administração sobre as bibliotecas não localizadas.
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.soem que JAVAHOME é o diretório base para o IBM Developer Kit. Se não for possível ao DB2 UDB localizar essas bibliotecas, você receberá um erro -4301 ao tentar executar uma rotina Java e haverá mensagens no registro de notificação de administração sobre as bibliotecas não localizadas.
JAVAHOME/jre/binem que JAVAHOME é o diretório base para o IBM Developer Kit. Se não for possível ao DB2 UDB localizar essa bibliotecas, você receberá um erro -4301 ou -1042 ao tentar executar uma rotina Java.
Ao invés de criar explicitamente links para as bibliotecas compartilhadas no diretório /usr/lib é possível incluir os nomes dos diretórios que armazenam as bibliotecas compartilhadas Java ao arquivo /etc/ld.so.conf. Esse arquivo requer permissão de raiz. Após atualizar /etc/ld.so.conf, você deve executar o comando ldconfig como raiz para ativar suas alterações. Se encontrar qualquer problema com esse procedimento alternativo, crie os links no diretório /usr/lib, como instruído anteriormente.
Se você estiver utilizando o sistema operacional Microsoft XP de 64 bits (2600), configurado para utilizar o protocolo NETBIOS com a família de produtos do DB2, será necessário obter um hotfix da Microsoft. Entre em contato com a Microsoft indicando o artigo do Knowledge Base número Q317437.
O sistema operacional Windows XP Home Edition é suportado apenas pelos produtos do DB2 UDB (Universal Database) Personal Edition.
O sistema operacional Windows XP Professional é suportado pelos seguintes produtos do DB2:
Os produtos do DB2 a seguir são suportados no Windows XP para fins de desenvolvimento ou teste apenas (os ambientes de produção requerem Windows 2000 ou Windows Server 2003):
No DB2 UDB (Universal Database(TM)) Versão 8.2, os clientes do DB2 UDB Workgroup Server Edition e do DB2 UDB Express Edition (quando licenciado com base no modelo de preço por usuário) não conseguiram instalar o opcional disponível para aquisição à parte do DB2 UDB HADR (High Availability Disaster Recovery). Esse problema foi corrigido no DB2 UDB Versão 8.2 FixPak 1 (equivalente à Versão 8.1 FixPak 8).
Os utilitários OLAP no DB2 Warehouse Manager Standard Edition, Versão 8.2 não são compatíveis com o IBM DB2 OLAP Server FP3 (Essbase API nível 6.5.4) e posterior. Você é aconselhado a utilizar o DB2 OLAP Server FP2 (Essbase 6.5.3) ou anterior até que esse problema seja resolvido.
Para utilizar registros com dispositivos de E/S brutos antes do DB2 UDB (Universal Database) Versão 8.2.2 (equivalente à Versão 8.1 FixPak 9), era necessário ligar um dispositivo físico ao driver de dispositivo de caracteres bruto do Linux com o utilitário bruto. Iniciando com o DB2 UDB Versão 8.2.2 (equivalente à Versão 8.1 FixPak 9), no kernel Linux 2.6, a E/S bruta para registros pode ser especificada diretamente. Por exemplo, para utilizar a partição de dispositivo /dev/sdb1 para registros brutos para o banco de dados SAMPLE, emita o seguinte comando:
db2 update db cfg for sample using newlogpath /dev/sdb1
Embora o DB2 UDB ainda suporte o método de utilização do utilitário bruto para E/S brutas, as distribuições recentes rejeitam esse recurso que poderá ser removido futuramente. O método preferido é a utilização do novo método, especificando os dispositivos diretamente.
O DB2 Universal Database, Versão 8.2 suporta o Red Hat Enterprise Linux AS Versões 3 e 2.1. Porém, o Data Warehouse Center suporta apenas o Red Hat Enterprise Linux AS, Versão 2.1. O Data Warehouse Center utiliza drivers DataDirect ODBC que não suportam o Red Hat Enterprise Linux AS, Versão 3.1. Portanto, o Data Warehouse Center não suporta origens e destinos do warehouse ODBC de um site de agente do Red Hat Enterprise Linux AS, Versão 3.1.
Ao executar aplicativos em um ambiente IBM(R) WebSphere(R) MQ (anteriormente conhecido como IBM MQSeries(R)), WebSphere(R) MQ pode atuar como um gerenciador de transição em conformidade com XA, coordenando todas as transações de confirmação de duas fases e distribuídas. Quando o WebSphere(R) MQ está agindo como um gerenciador de transações neste modo e as origens de dados são da família de produtos do DB2, há vários requisitos de configuração. A maioria desses requisitos já estão documentados. Por exemplo, você deve configurar o parâmetro de configuração TP_MON_NAME como "MQ" no Runtime Client do DB2 .
Porém, há um requisito de configuração que não está documentado. O requisito é especificado para o DB2 Connect ao conectar às origens de dados que são servidores do DB2 para OS/390(R): Ao utilizar WebSphere MQ para transações distribuídas coordenadas envolvendo servidores do DB2 para z/OS(R) e DB2 para iSeries, o recurso do centralizador de conexão do DB2 Connect deve estar ativado no gateway. O centralizador de conexão é ativado quando o valor do parâmetro de configuração MAX_CONNECTIONS é maior que o valor de MAX_COORDAGENTS. Se você não ativar o centralizador de conexão, isso resultará em comportamentos de transações inesperadas.
A página de códigos Shift-JIS do MicrosoftWindows para o idioma japonês é registrada como o CCSID (Coded Character Set Identifier) IBM 943. Entretanto, a página de códigos Shift-JIS na plataforma HP-UX está registrada como CCSID 5039. O CCSID 5039 contém caracteres somente no JIS (Japanese Industry Standard), e não possui nenhum caractere definido pelo fornecedor. Você pode utilizar um banco de dados do DB2 UDB (Universal Database) do CCSID 5039 no HP-UX para armazenar caracteres Shift-JIS, mas haverá conversão da página de códigos entre o CCSID 5039 e o CCSID 943. Ao utilizar aplicativos Microsoft ODBC, você poderá encontrar um problema ao converter dados em CCSID 5039 para Unicode, devido a diferenças entre a tabela de conversão da página de códigos da IBM e a tabela de conversão da página de códigos da Microsoft.
A lista de caracteres a seguir, quando convertida de CCSID 5039 para Unicode, resultará em pontos de código diferentes dependendo de qual tabela de conversão for utilizada (IBM ou Microsoft). Para esses caracteres, a tabela de conversão da IBM está de acordo com o Japanese Industry Standard JISX0208 e JISX0221.
| Ponto de Código do Shift-JIS (Nome do Caractere) | Ponto de Código Primário da IBM (Nome do Unicode) | Ponto de Código Primário da Microsoft (Nome do Unicode) |
|---|---|---|
| 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) |
Por exemplo, o caractere EM dash com o ponto de código CCSID 5039 de X'815C' é convertido para o ponto de código do Unicode U+2014 ao utilizar a tabela de conversão da IBM, mas é convertido para U+2015 ao utilizar a tabela de conversão da Microsoft. Isso pode criar problemas potenciais para aplicativos Microsoft ODBC porque eles tratariam o U+2014 como um ponto de código inválido. Para evitar esses problemas potenciais, o DB2 UDB fornece a tabela de conversão alternativa da Microsoft de CCSID 5039 para Unicode, além da tabela de conversão padrão da IBM. É necessário substituir a tabela de conversão padrão da IBM pela tabela de conversão alternativa da Microsoft. Observe que a tabela de conversão padrão da IBM de Unicode para CCSID 5039 corresponde à versão da Microsoft.
Ao converter de CCSID 5039 para Unicode, será utilizada a tabela de conversão da página de códigos padrão do DB2 UDB (Universal Database). Se desejar utilizar uma versão diferente da tabela de conversão, como a versão da Microsoft, você deverá substituir manualmente o arquivo da tabela de conversão padrão (.cnv).
Antes de substituir os arquivos da tabela de conversão da página de códigos existentes no diretório sqllib/conv, você deve, primeiro, fazer um backup do arquivo, caso deseje alterá-lo de volta. No UNIX e no Linux, o diretório sqllib/conv é vinculado ao caminho de instalação do DB2 UDB.
Para que a substituição da tabela de conversão seja efetiva, cada cliente do DB2 UDB que se conectar ao mesmo banco de dados deve ter sua tabela de conversão alterada. De outro modo, clientes diferentes podem armazenar o mesmo caracter utilizando pontos de código diferentes.
Para substituir a tabela de conversão padrão do DB2 UDB para converter de CCSID 5039 para Unicode, siga essas etapas:
O CCSID (Coded Character Set Identifier) da IBM para a página de códigos Japanese EUC é registrado como CCSID 954. O CCSID 954 é uma codificação comum para as plataformas Japanese UNIX e Linux. Ao utilizar aplicativos Microsoft ODBC para se conectar a um banco de dados DB2 UDB (Universal Database) do CCSID 954, você pode encontrar um problema ao converter dados do CCSID 954 para Unicode. As diferenças entre a tabela de conversão da página de códigos da IBM e da Microsoft geram tais problemas. A tabela de conversão da IBM está de acordo com os nomes de caracteres conforme especificado no JIS (Japanese Industry Standard) JISX0208, JISX0212 e JISX0221.
Os caracteres a seguir, quando convertidos de CCSID 954 para Unicode, resultarão em pontos de códigos diferentes dependendo da tabela de conversão que for utilizada (IBM ou Microsoft).
| Ponto de Código do EUC-JP (Nome do Caractere) | Ponto de Código Primário da IBM (Nome do Unicode) | Ponto de Código Primário da Microsoft (Nome do Unicode) |
|---|---|---|
| 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) |
Por exemplo, o caractere EM dash com o ponto de código CCSID 954 de X'A1BD' é convertido para o ponto de código do Unicode U+2014 ao utilizar a tabela de conversão da IBM, mas é convertido para U+2015 ao utilizar a tabela de conversão da Microsoft. Devido a essa diferença de mapeamento de conversão, você pode ter dois pontos de códigos diferentes para o mesmo caractere em um banco de dados Unicode do DB2 UDB ou em uma coluna de gráfico de um banco de dados do DB2 UDB 954. Isso pode criar problemas potenciais para aplicativos Microsoft ODBC porque eles tratariam o U+2014 como um ponto de código inválido. Para evitar esses problemas potenciais, o DB2 UDB fornece a tabela de conversão alternativa da Microsoft de CCSID 954 para Unicode, além da tabela de conversão padrão da IBM. É necessário substituir a tabela de conversão padrão da IBM pela tabela de conversão alternativa da Microsoft. Observe que a tabela de conversão padrão da IBM de Unicode para CCSID 954 corresponde à versão da Microsoft.
Ao converter de CCSID 954 para Unicode, será utilizada a tabela de conversão da página de códigos padrão do DB2 UDB (Universal Database). Se desejar utilizar uma versão diferente da tabela de conversão, como a versão da Microsoft, você deverá substituir manualmente o arquivo da tabela de conversão padrão (.cnv).
Antes de substituir os arquivos da tabela de conversão da página de códigos existentes no diretório sqllib/conv, você deve, primeiro, fazer um backup do arquivo, caso deseje alterá-lo de volta. No UNIX e Linux, o diretório sqllib/conv está vinculado ao caminho da instalação de DB2 UDB.
Para ser efetivo, todo cliente do DB2 UDB que se conectar ao mesmo banco de dados CCSID 954 deve ter sua tabela de conversão alterada. Se seu cliente for um Windows em japonês, cuja página de códigos ANSI é Shift-JIS (CCSID 943), será necessário também alterar as tabelas de conversão padrão do DB2 entre o CCSID 943 e o Unicode para a versão da Microsoft. De outro modo, clientes diferentes podem armazenar o mesmo caracter utilizando pontos de código diferentes.
Para substituir a tabela de conversão padrão do DB2 UDB para converter de CCSID 954 para Unicode, siga essas etapas:
Para substituir as tabelas de conversão padrão do DB2 UDB para converter entre o CCSID 943 e o Unicode, siga essas etapas:
Ao utilizar a página de códigos Shift-JIS do Microsoft Japanese Windows que é registrada como o CCSID (Coded Character Set Identifier) da IBM 943, você pode encontrar os dois problemas a seguir ao converter caracteres entre o CCSID 943 e o Unicode. O problema em potencial ocorre devido a diferenças entre as tabelas de conversão da página de códigos da IBM e da Microsoft. Para evitar esses problemas em potencial, o DB2 UDB (Universal Database) fornece as tabelas de conversão alternativas da Microsoft entre o CCSID 943 e o Unicode, além das tabelas de conversão padrão da IBM.
Por motivos de histórico, mais de 300 caracteres na página de códigos CCSID 943 são representados por dois ou três pontos de código cada. A utilização de IMEs (Input Method Editors) e de tabelas de conversão de páginas de códigos faz com que apenas um destes pontos de código equivalentes seja digitado. Por exemplo, a letra minúscula para o numeral romano um 'i' possui dois pontos de código equivalentes: X'EEEF' e X'FA40'. Os IMEs do Microsoft Windows sempre geram X'FA40' quando 'i' é digitado. No geral, a IBM e a Microsoft utilizam o mesmo ponto de código primário para representar o caractere, exceto para os 13 caracteres a seguir:
| Nome do Caractere (Ponto de Código Unicode) | Ponto de Código Shift-JIS Primário da IBM | Ponto de Código Shift-JIS Primário da Microsoft |
|---|---|---|
| Numeral romano um (U+2160) | X'FA4A' | X'8754' |
| Numeral romano dois (U+2161) | X'FA4B' | X'8755' |
| Numeral romano três (U+2162) | X'FA4C' | X'8756' |
| Numeral romano quatro (U+2163) | X'FA4D' | X'8757' |
| Numeral romano cinco (U+2164) | X'FA4E' | X'8758' |
| Numeral romano seis (U+2165) | X'FA4F' | X'8759' |
| Numeral romano sete (U+2166) | X'FA50' | X'875A' |
| Numeral romano oito (U+2167) | X'FA51' | X'875B' |
| Numeral romano nove (U+2168) | X'FA52' | X'875C' |
| Numeral romano dez (U+2169) | X'FA53' | X'875D' |
| Estoque ideográfico entre parênteses (U+3231) | X'FA58' | X'FA58' |
| Sinal numérico (U+2116) | X'FA59' | X'8782' |
| Sinal de telefone (U+2121) | X'FA5A' | X'8754' |
Os produtos IBM, como o DB2 UDB, utilizam principalmente pontos de código IBM, como X'FA4A' para apresentar o numeral romano um em letra maiúscula 'I', mas os produtos Microsoft utilizam X'8754' para representar o mesmo caractere. Um aplicativo Microsoft ODBC pode inserir o caractere 'I' como X'8754' em um banco de dados DB2 UDB do CCSID 943 e o DB2 UDB Control Center pode inserir o mesmo caractere como X'FA4A' no mesmo banco de dados CCSID 943. Porém, aplicativos ODBC podem localizar apenas as linhas que têm 'I' codificado como X'8754' e o DB2 UDB Control Center pode localizar apenas as linhas que têm 'I' codificado como X'FA4A'. Para ativar o DB2 UDB Control Center para selecionar 'I' como X'8754', você precisa substituir as tabelas de conversão padrão da IBM entre o CCSID 943 e o Unicode pelas tabelas de conversão alternativa da Microsoft.
A lista de caracteres a seguir, quando convertida de CCSID 943 para Unicode, resultará em pontos de códigos diferentes dependendo da tabela de conversão que for utilizada (IBM ou Microsoft). Para esses caracteres, a tabela de conversão da IBM está de acordo com o Japanese Industry Standard JISX0208, JISX0212 e JISX0221.
| Ponto de Código do Shift-JIS (Nome do Caractere) | Ponto de Código Primário da IBM (Nome do Unicode) | Ponto de Código Primário da Microsoft (Nome do Unicode) |
|---|---|---|
| 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) |
Por exemplo, o caractere EM dash com o ponto de código CCSID 943 de X'815C' é convertido para o ponto de código do Unicode U+2014 ao utilizar a tabela de conversão da IBM. Porém, ele é convertido para U+2015 ao utilizar a tabela de conversão da Microsoft. Devido a essa diferença de mapeamento de conversão, você pode ter dois pontos de códigos diferentes para o mesmo caractere em um banco de dados Unicode do DB2 UDB. Isso pode criar problemas potenciais para aplicativos Microsoft ODBC porque eles tratariam o U+2014 como um ponto de código inválido. Para evitar esse problema potencial, é necessário substituir as tabelas de conversão padrão da IBM entre CCSID 943 e Unicode pelas tabelas de conversão alternativa da Microsoft.
A utilização das tabelas de conversão alternativa da Microsoft entre CCSID 943 e Unicode deve ser restrita a ambientes fechados, onde os clientes DB2 UDB e os bancos de dados DB2 UDB tenham todos uma página de códigos de CCSID 943 e estejam todos utilizando as mesmas tabelas de conversão alternativas da Microsoft. Se você tiver um cliente DB2 UDB utilizando as tabelas de conversão padrão da IBM e outro cliente DB2 UDB utilizando as tabelas de conversão alternativas da Microsoft e ambos os clientes estiverem inserindo dados no mesmo banco de dados DB2 UDB de CCSID 943, o mesmo caractere poderá ser armazenado como pontos de códigos diferentes no banco de dados.
Ao converter entre CCSID 943 e Unicode, são utilizadas as tabelas de conversão da página de códigos padrão do DB2 UDB (Universal Database). Se deseja utilizar uma versão diferente das tabelas de conversão, como a versão da Microsoft, você deverá substituir manualmente os arquivos da tabela de conversão padrão (.cnv).
Antes de substituir os arquivos da tabela de conversão da página de códigos existente no diretório sqllib/conv, é necessário fazer backup dos arquivos, caso deseje alterá-los novamente. No UNIX e Linux, sqllib/conv é vinculado ao caminho de instalação do DB2 UDB.
Para que a substituição da tabela de conversão seja efetiva, cada cliente do DB2 UDB que se conectar ao mesmo banco de dados deve ter sua tabela de conversão alterada. De outro modo, clientes diferentes podem armazenar o mesmo caractere utilizando pontos de código diferentes.
Para substituir as tabelas de conversão padrão do DB2 UDB para converter caracteres entre CCSID 943 e Unicode:
Apesar de ser mencionado na documentação, o sistema operacional MVS não é mais suportado pelo DB2 Universal Database. O MVS foi substituído pelo z/OS.
As operações de backup e restauração para e a partir de vários dispositivos de fita podem não funcionar se você estiver utilizando o sistema operacional Linux 390.
Ao acessar o Development Center no UNIX com o Hummingbird Exceed, a extensão XTEST versão 2.2 deve ser ativada antes que você possa mover e acoplar visualizações arrastando suas barras de título dentro do Development Center.
Para ativar a extensão XTEST: