Programar num Ambiente de Sistema Central ou de iSeries
Aplicações em Ambientes de Sistema Central ou de iSeries
O DB2 Connect permite a um programa de aplicação aceder a dados em bases de dados de DB2 em servidores de System/390, zSeries e iSeries. Por
exemplo, uma aplicação que esteja a ser executada em Windows pode aceder a dados numa base de dados de DB2 Universal Database for OS/390 and z/OS. O utilizador pode criar novas aplicações ou modificar aplicações existentes para executar num ambiente de sistema central ou de iSeries. Também pode desenvolver aplicações num ambiente e enviá-los para outro. O DB2 Connect permite-lhe utilizar as seguintes APIs com produtos de base de dados de sistema central como, por exemplo, o DB2 Universal Database for OS/390 and z/OS, desde que o artigo seja suportado pelo produto de base de dados de sistema central:
v SQL incorporada, tanto estática como dinâmica v O DB2 Call Level Interface
v A API de ODBC da Microsoft v JDBC
Algumas instruções de SQL são diferentes entre produtos de base de dados relacional. Poderá encontrar instruções de SQL que:
v São iguais em todos os produtos de base de dados que utilizar, independentemente dos padrões
v Que estão disponíveis em todos os produtos de base de dados relacional da IBM (consultar as informações relativas a SQL para obter detalhes)
v Que são únicas de um sistema de base de dados ao qual o utilizador acede As instruções de SQL das primeiras duas categorias são altamente SQL portáteis, mas as da terceira categoria necessitarão primeiro de alterações. Em geral, as instruções de SQL em Linguagem de Definição de Dados (DDL) não são tão portáteis como as da Linguagem de Manipulação de Dados (DML). O DB2 Connect aceita algumas instruções de SQL que não são suportadas pelo DB2 Universal Database. O DB2 Connect transmite algumas instruções ao servidor de sistema central ou de iSeries. Para obter informações relativas aos limites de diferentes plataformas, tais como o comprimento máximo de coluna, consulte o tópico relativo a limites de SQL.
Se mover uma aplicação de CICS de OS/390 ou VSE para ser executada noutro produto de CICS (por exemplo, CICS for AIX), esta também pode aceder à base de dados de OS/390 ou VSE utilizando o DB2 Connect. Consulte o CICS/6000 Application Programming Guide e o manual de CICS
Customization and Operation para obter mais detalhes.
Nota: Pode utilizar o DB2 Connect com uma base de dados de DB2 Universal Database Versão 8, apesar de necessitar de um cliente de DB2. A maior parte das questões de incompatibilidade listadas nos tópicos seguintes não serão aplicáveis, caso esteja a utilizar o DB2 Connect numa base de dados de DB2 Universal Database Versão 8, excepto em casos em que uma restrição se deve a uma limitação do próprio DB2 Connect.
Tarefas relacionadas:
v “Creating the sample Database on Host or AS/400 and iSeries Servers” em
Application Development Guide: Building and Running Applications
Referência relacionada:
v “SQL limits” em SQL Reference, Volume 1
Linguagem de Definição de Dados em Ambientes de Sistema Central ou
de iSeries
As instruções de DDL são diferentes entre produtos de bases de dados da IBM pois o armazenamento é processado de forma distinta em sistemas diferentes. Em sistemas de servidor de sistema central ou de iSeries podem existir vários passos entre conceber uma base de dados e emitir uma instrução CREATE TABLE. Por exemplo, uma série de instruções pode traduzir a concepção de objectos lógicos numa representação física desses objectos armazenados.
O pré-compilador transmite muitas destas instruções de DLL para o servidor de sistema central ou de iSeries quando o utilizador efectua a pré-compilação para uma base de dados de servidor de sistema central ou de iSeries. As mesmas instruções não seriam pré-compiladas numa base de dados do
sistema em que a aplicação está a ser executada. Por exemplo, numa aplicação de Windows, a instrução CREATE STORGROUP irá pré-compilado com êxito para uma base de dados de DB2 Universal Database for OS/390 and z/OS, mas não para uma base de dados de DB2 para Windows.
Linguagem de Manipulação de Dados em Ambientes de Sistema Central
ou de iSeries
Em geral, as instruções de DML são extremamente portáteis. As instruções SELECT, INSERT, UPDATE e DELETE são semelhantes nos produtos de base
de dados relacionais da IBM. A maior parte das aplicações utiliza
principalmente as instruções de SQL de DML, que são suportadas pelo DB2 Connect.
De seguida são apresentadas as considerações relativas à utilização de DNL em ambientes de sistema central ou de iSeries :
v Tipos de dados numéricos
Quando se transferem dados numéricos para o DB2 Universal Database, o tipo de dados pode ser alterado. Os SQLTYPEs numéricos e decimais zonados, suportados pelo OS/400, são convertidos para SQLTYPEs decimais (Compactados) fixos.
v Dados de byte misto
Os dados de byte misto consistem em caracteres de um conjunto de
caracteres de código expandido de UNIX (EUC), um conjunto de caracteres de duplo byte (DBCS) e um conjunto de caracteres de byte único (SBCS) na mesma coluna. Em sistemas que armazenam dados em EBCDIC (OS/390, z/OS, OS/400, VSE e VM), os caracteres de código base e de código alternativo marcam o início e o fim de dados de duplo byte. Em sistemas que armazenam dados em ASCII (tais como UNIX), não são necessários caracteres de código de base e de código alternativo.
Se a aplicação do utilizador transferir dados de byte misto de um sistema de ASCII para um sistema de EBCDIC, certifique-se de que disponibiliza espaço suficiente para os caracteres de código base e código alternativo. Para cada comutação entre dados de SBCS para DBCS, adicione 2 bytes ao comprimento dos dados. Para melhor portabilidade, utilize cadeias de comprimento variável em aplicações que utilizam dados de byte misto. v Campos longos
Os campos longos (cadeias superiores a 254 caracteres) são processados de forma diferente em sistemas diferentes. Um servidor de sistema central ou de iSeries pode suportar apenas um sub-conjunto de funções escalares para campos longos; por exemplo, o DB2 Universal Database for OS/390 and z/OS permite apenas as funções de LENGTH e SUBSTR para campos longos. Para além disso, um servidor de sistema central ou de iSeries poderá necessitar de processamentos diferentes relativamente a certas instruções de SQL; por exemplo, o DB2 for VSE & VM requer que, com a instrução INSERT, apenas seja utilizada uma variável de sistema central, o SQLDA ou um valor NULO.
v Tipo de dados de objecto volumoso
O tipo de dados LOB é suportado por DB2 Connect. v Tipos definidos pelo utilizador
Apenas os tipos distintos definidos pelo utilizador são suportados por DB2 Connect. Os tipos estruturados, também conhecidos como tipos de dados abstractos, não são suportados por DB2 Connect.
v Tipo de dados ROWID
O tipo de dados ROWID é processado por DB2 Connect como VARCHAR para dados de bit.
v Tipo de dados BIGINT
São suportados números inteiros de oito bytes (64 bits) peloDB2 Connect. O tipo de dados interno BIGINT é utilizado para facultar suporte para a cardinalidade de bases de dados de grande dimensão, ao mesmo que retém a precisão dos dados.
Linguagem de Controlo de Dados em Ambientes de Sistema Central ou
de iSeries
Cada sistema de gestão de bases de dados relacionais da IBM faculta níveis diferentes de granularidade para as instruções GRANT e REVOKE de SQL. Consulte as publicações específicas do produto para verificar as instruções de SQL adequadas para utilizar em relação a cada sistema de gestão de bases de dados.
Gestão de Ligações de Bases de Dados com o DB2 Connect
O DB2 Connect suporta as versões CONNECT TO e CONNECT RESET da instrução CONNECT. bem como CONNECT sem parâmetros. Se uma
aplicação chamar uma instrução de SQL sem primeiro executar uma instrução CONNECT TO explícita, é executada uma ligação implícita ao servidor de aplicação predefinido (se existir um definido).
Ao estabelecer ligação a uma base de dados, as informações que identificam o sistema de gestão de bases de dados relacionais são devolvidas no campo SQLERRP do SQLCA. Se o servidor de aplicação for uma base de dados relacional da IBM , os primeiros três bytes de SQLERRP contêm um dos seguintes:
DSN DB2 Universal Database for OS/390 and z/OS
ARI DB2 for VSE & VM
QSQ DB2 UDB para iSeries
SQL DB2 Universal Database.
Se emitir uma instrução CONNECT TO ou null CONNECT ao utilizar o DB2 Connect, o código de território ou o símbolo de território no campo
SQLERRMC do SQLCA são devolvidos como espaços em branco; o CCSID do servidor de aplicação é devolvido no símbolo de página de códigos ou de conjunto de códigos.
de ligação) ou a instrução DISCONNECT (qualquer um dos tipos de ligação, mas não num ambiente de supervisor de TP).
Nota: Uma aplicação pode receber SQLCODEs que indicam erros e terminar normalmente; o DB2 Connect, neste caso, consolida os dados. Se não pretender que os dados sejam consolidados, deve emitir um comando ROLLBACK.
O comando FORCE permite-lhe desligar utilizadores seleccionados ou todos os utilizadores da base de dados. Esta acção é suportada em ambientes de servidor de sistema central e de iSeries; a anulação da ligação do utilizador pode ser forçada na estação de trabalho de DB2 Connect.
Referência relacionada:
v “CONNECT (Type 1) statement” em SQL Reference, Volume 2 v “CONNECT (Type 2) statement” em SQL Reference, Volume 2
Processamento de Pedidos de Interrupção
O DB2 Connect processa um pedido de interrupção por parte de um cliente de DB2 de acordo com uma das duas seguintes formas:
v Se a palavra-chave INTERRUPT_ENABLED existir no campo PARMS da entrada de catálogo de DCS, o DB2 Connect irá largar a ligação no servidor de sistema central ou de iSeries ao receber um pedido de interrupção. A perda da ligação, pelo menos nos servidores de DB2 UDB para OS/390 e z/OS, irá levar à interrupção do actual pedido no servidor.
v Se a palavra-chave INTERRUPT_ENABLED não existir no campo PARMS da entrada de catálogo de DCS, os pedidos de interrupção são ignorados.
Diferenças de Atributos de Pacote entre Sistemas de Bases de Dados
Relacionais da IBM
Um pacote possui os seguintes atributos:
ID de Colecção
O ID do pacote. Este pode ser especificado no comando PREP.
Proprietário
O ID de autorização do proprietário do pacote. Este pode ser especificado nos comandos PREP ou BIND.
Criador
O nome do utilizador que associa o pacote.
Qualificador
O qualificador implícito de objectos do pacote. Este pode ser especificado nos comandos PREP ou BIND.
Cada sistema de servidor de sistema central ou de iSeries possui limitações sobre a utilização destes atributos:
DB2 Universal Database for OS/390 and z/OS
Os quatro atributos podem ser diferentes. A utilização de um qualificador diferente requer privilégios administrativos especiais. Para obter mais informações relativas às condições de utilização destes atributos, consulte o Command Reference for DB2 Universal Database for OS/390 and z/OS.
DB2 for VSE & VM
Todos os atributos devem ser idênticos. Se o USER1 criar um ficheiro de associação (com PREP) e o USER2 executar a associação, o USER2 necessita de autoridade de DBA para associar para USER1. Apenas o nome do utilizador USER1 é utilizado nos atributos.
DB2 UDB para iSeries
O qualificador indica o nome da colecção. A relação entre os qualificadores e a propriedade afecta a concessão e revogação de privilégios sobre um objecto. O nome do utilizador que possui uma sessão iniciada é o criador e o proprietário, a menos que seja qualificado por um ID de colecção, o que fará com que o ID de colecção seja o proprietário. O ID de colecção já deve existir antes de ser utilizado como qualificador.
DB2 Universal Database
Os quatro atributos podem ser diferentes. A utilização de um
proprietário diferente requer autoridade administrativa e o associador deve possuir o privilégio CREATEIN no esquema (caso este já exista).
Opção CNULREQD BIND para Cadeias C de Terminação Nula
A opção de associação CNULREQD sobrepõe o processamento de cadeias com terminação nula que são especificadas utilizando a opção LANGLEVEL. Por predefinição, CNULREQD é definida para SIM. Isto faz com que as cadeias de terminação nula sejam interpretadas de acordo com os padrões de MIA. Se estiver a estabelecer ligação a um servidor de DB2 Universal
Database for OS/390 and z/OS, recomenda-se fortemente que defina CNULREQD para SIM. O utilizador deve associar as aplicações codificadas para os padrões de SAA1 (relativamente a cadeias de terminação nula) com a opção CNULREQD definida para NÃO. Caso contrário, as cadeias de
terminação nula irão ser interpretadas de acordo com os padrões de MIA, mesmo que sejam apresentadas utilizando LANGLEVEL definida para SAA1.
Conceitos Relacionados:
Variáveis Autónomas de SQLCODE e SQLSTATE
As variáveis de SQLCODE e SQLSTATE autónomas, tal com está definido na norma ISO/ANS SQL92, são suportadas através da opção de pré-compilação LANGLEVEL SQL92E. Será emitido um aviso SQL0020W na altura da
pré-compilação, para indicar que LANGLEVEL não é suportado. Este aviso só se aplica às funções listadas sob LANGLEVEL MIA, que é um sub-conjunto de LANGLEVEL SQL92E.
Referência relacionada:
v “PRECOMPILE Command” em Command Reference
Ordenações Definidas pelo Utilizador
As diferenças entre EBCDIC e ASCII provocam diferenças nas ordenações dos vários produtos de bases de dados e afectam também as cláusulas ORDER BY e GROUP BY. Uma forma de minimizar estas diferenças é criar uma sequência de ordenação definida pelo utilizador que reproduza a ordem de EBCDIC. O utilizador pode especificar uma sequência de ordenação apenas quando criar uma nova base de dados.
Nota: As tabelas de bases de dados podem agora ser armazenadas no DB2 Universal Database for OS/390 and z/OS em formato ASCII. Isto permite uma troca mais rápida de dados entre o DB2 Connect e DB2 Universal Database for OS/390 and z/OS e elimina a necessidade de facultar procedimentos de campo que, caso contrário, devem ser utilizados para converter dados e para os voltar a sequenciar.
Diferenças de Integridade Referencial entre Sistemas de Bases de Dados
Relacionais da IBM
Os sistemas diferentes processam restrições referenciais de forma diferente:
DB2 Universal Database for OS/390 and z/OS
Deve ser introduzido um índice numa chave primária antes de criar uma chave externa utilizando essa chave primária. As tabelas podem fazer referência a si mesmas.
DB2 for VSE & VM
É automaticamente criado um índice para uma chave externa. As tabelas não podem fazer referência a si mesmas.
DB2 UDB para iSeries
É automaticamente criado um índice para uma chave externa. As tabelas podem fazer referência a si mesmas.
DB2 Universal Database
Para bases de dados de DB2 Universal Database, é automaticamente
criado um índice para uma restrição única, incluindo uma chave primária. As tabelas podem fazer referência a si mesmas.
Outras regras variam em relação aos níveis de cascata.
Bloquear e Portabilidade das Aplicações
A forma como o servidor de base de dados executa o bloqueio pode afectar algumas aplicações. Por exemplo, as aplicações concebidas em torno do bloqueio de nível de linha e do nível de isolamento da estabilidade do cursor não são directamente portáveis para sistemas que executam bloqueio de nível de páginas. Devido a estas diferenças subjacentes, as aplicações poderão ter de ser ajustadas.
Os produtos DB2 Universal Database for OS/390 and z/OS e DB2 Universal Database possuem a capacidade de exceder o tempo de espera de um bloqueio e enviar um código de retorno de erro para aplicações a aguardar.
Diferenças de SQLCODE e SQLSTATE entre Sistemas de Bases de Dados
Relacionais da IBM
Diferentes produtos de base de dados relacional da IBM não produzem sempre os mesmos SQLCODEs em relação a erros semelhantes. O utilizador pode lidar com este problema de duas formas:
v Utilize SQLSTATE em vez de SQLCODE para um erro específico.
SQLSTATEs possuem aproximadamente o mesmo significado em todos os produtos de base de dados e os produtos geram SQLSTATEs que
correspondem a SQLCODEs.
v Correlacione as SQLCODEs de um sistema a outro sistema.
Por predefinição, o DB2 Connect correlaciona SQLCODEs e símbolos de cada sistema de servidor de sistema central ou iSeries da IBM ao sistema de DB2 Universal Database do utilizador. O utilizador pode especificar um ficheiro de correlação de SQLCODE se pretender sobrepor a correlação predefinida ou se estiver a utilizar um servidor de base de dados que não possui correlação de SQLCODE (um servidor de base de dados que não é IBM). O utilizador pode também desactivar a correlação de SQLCODE.
Conceitos Relacionados:
Diferenças de Catálogos do Sistema entre Sistemas de Bases de Dados
Relacionais da IBM
Os catálogos do sistema variam entre os produtos de bases de dados da IBM. Muitas diferenças podem ser mascaradas pela utilização de vistas. Para obter informações, consulte a documentação relativa ao servidor de base de dados que está a utilizar.
As funções de catálogo em CLI evitam este problema apresentado suporte da mesma API e conjunto de resultados para consultas de catálogos em toda a família DB2.
Conceitos Relacionados:
v “Catalog Functions for Querying System Catalog Information in CLI Applications” em CLI Guide and Reference, Volume 1
Excessos de Conversão Numérica em Atribuições de Obtenção
Os excessos de conversão numérica em atribuições de obtenção podem ser processados de forma diferente por produtos diferentes de base de dados relacionais da IBM. Por exemplo, coloque a hipótese de obter uma coluna flutuante para uma variável de sistema central inteiro de DB2 Universal Database for OS/390 and z/OS e de DB2 Universal Database. Ao converter o valor flutuante para um valor inteiro, pode ocorrer um excesso de conversão. Por predefinição, o DB2 Universal Database for OS/390 and z/OS irá
devolver um SQLCODE de aviso e um valor nulo para a aplicação. Em contraste, o DB2 Universal Database irá devolver um erro de excesso de conversão. Recomenda-se que as aplicações evitem os excessos de conversão numérica em atribuições de obtenção através da execução da obtenção para variáveis de sistema central de tamanho adequado.
Níveis de Isolamento Suportados pelo DB2 Connect
O DB2 Connect aceita os seguintes níveis de isolamento quando efectua prep ou bind numa aplicação:
EE Leitura Repetível
RS Estabilidade de Leitura
CS Estabilidade do Cursor
UR Leitura Não Consolidada
NC Sem Consolidação
Os níveis de isolamento são listados por ordem desde a maior protecção à menor protecção. Se o servidor de sistema central ou iSeries não suportar o nível de isolamento que especificar, é utilizado o seguinte nível suportado mais elevado.
A seguinte tabela mostra o resultado de cada nível de isolamento em cada servidor de aplicação de sistema central ou iSeries.
Tabela 1. Níveis de Isolamento DB2 Connect DB2 Universal Database for OS/390 and z/OS
DB2 for VSE & VM DB2 UDB para iSeries DB2 Universal Database RR RR RR nota 1 RR RS nota 2 RR COMMIT(*ALL) RS CS CS CS COMMIT(*CS) CS UR nota 3 CS COMMIT(*CHG) UR
NC nota 4 nota 5 COMMIT(*NONE) UR
Notas:
1. Não existe uma opção COMMIT equivalente no DB2 UDB para iSeries que corresponda a RR. O DB2 UDB para iSeries suporta RR bloqueando toda a tabela.
2. Resultados em RR para Versão 3.1 e resultados em RS para Versão 4.1 com APAR PN75407 ou Versão 5.1.
3. Resultados em CS para Versão 3.1 e resultados em UR para Versão 4.1 ou Versão 5.1.
4. Resultados em CS para Versão 3.1 e resultados em UR para Versão 4.1 com APAR PN60988 ou