Bellacosa Mainframe e o db2 connect e a banheira do tempo

☕ Um Café no Bellacosa Mainframe

Db2 Connect e a Banheira do Tempo — Quando Quatro Programadores Voltaram a 1986, Encontraram um JDBC no Fliperama e Descobriram que TCP/IP Não Sabia Executar `SELECT`

Ou: o jovem padawan COBOL entrou numa banheira instalada ao lado do datacenter, Igor derramou energético sobre o painel do DDF, o Db2 for z/OS abriu um DBAT e todos descobriram que conexão, sessão, transação e pacote não são quatro nomes para a mesma coisa

Prólogo — A banheira que apontava para o mainframe

Era sexta-feira, 23h47, no datacenter Bellacosa Mainframe.

O processamento noturno já havia começado, o café estava com gosto de óleo hidráulico e Igor acabara de instalar uma banheira de hidromassagem ao lado do rack de desenvolvimento.

— Para reduzir o estresse da equipe — explicou ele, segurando um cabo de rede molhado.

Sobre a borda da banheira havia um notebook executando uma aplicação Java. Na tela, uma mensagem nada relaxante:

ERRORCODE=-4499
SQLSTATE=08001

A aplicação precisava consultar uma tabela no Db2 for z/OS, mas não conseguia estabelecer a conexão.

O jovem padawan COBOL examinou o diagrama preso na parede:

Aplicação → API → TCP/IP → Db2

— Parece simples. Se o ping funciona, o banco deveria funcionar.

Nesse instante, Igor deixou cair uma lata de energético sobre o controlador da banheira. As luzes piscaram, o ventilador do mainframe mudou de tom e os três foram transportados para 1986.

Quando abriram os olhos, havia terminais verdes, cabelos volumosos, fitas cassete e um operador perguntando:

— Que negócio é esse de JDBC? É uma banda de rock?

Aquela viagem ensinaria uma lição importante:

Um diagrama simples pode apresentar a direção da estrada, mas não explica quem dirige o carro, qual idioma é falado na fronteira, quem verifica o passaporte e quem executa a SQL quando todos finalmente chegam ao Db2.

1. O que é Db2 Connect?

Db2 Connect é a família de recursos, drivers, clientes, componentes e direitos de uso que permite a aplicações distribuídas acessar bancos Db2 executados principalmente em plataformas host, como:

Db2 for z/OS;
Db2 for IBM i;
Ambientes host compatíveis previstos pela solução;
Outros servidores Db2 suportados, conforme produto, versão e driver.

Imagine uma aplicação Java executada em Linux que precisa consultar uma conta bancária armazenada no Db2 for z/OS.

Os dois sistemas vivem em mundos diferentes:

Aplicação Java
Linux
JDBC
Objetos Java
UTF-8
Containers

Do outro lado:

Db2 for z/OS
DDF
DBAT
Packages
RACF
WLM
Tablespaces

Db2 Connect participa da construção da ponte entre esses mundos.

Mas aqui começa a primeira armadilha: Db2 Connect não é apenas “um conversor de TCP/IP”.

TCP/IP é o transporte. Ele entrega bytes de um endereço a outro. Não conhece:

SELECT;
INSERT;
Cursor;
Package;
COMMIT;
ROLLBACK;
SQLCODE;
Result set;
Unidade de trabalho.

O diálogo de banco utiliza principalmente o DRDA — Distributed Relational Database Architecture. A IBM define Db2 Connect como uma implementação da arquitetura DRDA para acesso distribuído a servidores Db2. IBM — Db2 Connect e DRDA

A arquitetura básica não é apenas:

Aplicação → TCP/IP → Db2

É mais próxima de:

Aplicação
    ↓
API
    ↓
Driver IBM
    ↓
DRDA
    ↓
TLS, quando configurado
    ↓
TCP/IP
    ↓
DDF
    ↓
DBAT
    ↓
Package e SQL
    ↓
Dados

O infográfico original mostra o portal da máquina do tempo. Nosso trabalho é abrir a tampa e descobrir quais peças fazem a viagem acontecer.

2. Aplicação, linguagem, API e driver não são a mesma coisa

O diagrama coloca no mesmo bloco:

JDBC;
ADO.NET;
Python;
SQL;
ODBC;
Db2 CLI;
Perl;
OLE DB;
Embedded SQL;
Ruby.

O problema é que esses elementos pertencem a categorias diferentes.

Categoria	Exemplos	O que representa
Linguagem	Java, Python, Ruby, Perl, PHP, COBOL	Linguagem em que o programa foi escrito
API	JDBC, ODBC, CLI, ADO.NET	Interface usada pelo programa para solicitar serviços do banco
Driver	IBM JCC, IBM ODBC/CLI Driver, IBM .NET Provider	Implementação que conversa efetivamente com o Db2
Linguagem de banco	SQL	Forma de consultar e alterar os dados
Técnica de programação	Embedded SQL, SQLJ	Forma de incorporar SQL ao programa

Dizer que Python, JDBC e SQL são todos “APIs” seria como dizer que COBOL, CICS e EXEC CICS READ são a mesma coisa.

Eles cooperam, mas exercem funções diferentes.

Exemplo Java

Connection conn = DriverManager.getConnection(
    "jdbc:db2://db2host.empresa.com:448/DBP1",
    usuario,
    senha
);

Neste exemplo:

Java é a linguagem;
JDBC é a API;
O IBM Data Server Driver for JDBC and SQLJ implementa a comunicação;
A URL descreve o destino;
DRDA organiza o diálogo com o servidor;
TCP/IP transporta as mensagens.

Exemplo Python

import ibm_db

conexao = ibm_db.connect(
    "DATABASE=DBP1;"
    "HOSTNAME=db2host.empresa.com;"
    "PORT=448;"
    "PROTOCOL=TCPIP;"
    "UID=APPUSER;"
    "PWD=senha;",
    "",
    ""
)

Python continua sendo a linguagem. O módulo e o driver cuidam do acesso. Depois, a aplicação pode executar SQL:

sql = """
    SELECT NOME, SALDO
      FROM CLIENTE
     WHERE ID_CLIENTE = 100
"""

stmt = ibm_db.exec_immediate(conexao, sql)

Exemplo COBOL

EXEC SQL
    SELECT NOME,
           SALDO
      INTO :WS-NOME,
           :WS-SALDO
      FROM CLIENTE
     WHERE ID_CLIENTE = :WS-ID-CLIENTE
END-EXEC.

COBOL é a linguagem. SQL é a linguagem de banco. EXEC SQL delimita o comando embutido. O programa ainda precisa passar por pré-compilação, compilação, linkedição e preparação dos componentes Db2.

O jovem padawan deve guardar:

A API é o painel da banheira. O driver é a máquina escondida embaixo dela. DRDA é o manual de comunicação temporal. TCP/IP é o túnel. O Db2 é o destino.

3. O personagem que o infográfico esqueceu: o driver

O driver é um dos componentes mais importantes da arquitetura.

Ele:

Implementa JDBC, ODBC, CLI ou .NET;
Converte chamadas da aplicação em mensagens entendidas pelo servidor;
Monta e interpreta o protocolo DRDA;
Converte tipos de dados;
Entrega result sets;
Envia COMMIT e ROLLBACK;
Controla propriedades de timeout;
Participa de pooling e concentração de conexões;
Pode colaborar com automatic client reroute;
Pode colaborar com Sysplex workload balancing;
Negocia capacidades com o servidor;
Reporta SQLCODE, SQLSTATE e erros de comunicação.

A IBM distribui drivers e clientes diferentes para JDBC/SQLJ, ODBC/CLI, .NET, OLE DB e outras interfaces. IBM — Tipos de clientes e drivers

Por isso, ao atualizar um driver, não estamos apenas trocando “um arquivo .jar qualquer”.

A atualização pode alterar:

Suporte a TLS;
Conversão de timestamps;
Tipos de dados suportados;
Propriedades de failover;
Comportamento de timeouts;
Pacotes utilizados no servidor;
Recursos de compatibilidade;
Balanceamento no Sysplex.

Uma aplicação pode funcionar com determinada versão do driver em homologação e falhar em produção porque os pacotes correspondentes não foram preparados no Db2 for z/OS.

Easter egg número 1: se Igor disser “é só trocar o db2jcc4.jar escondido e ninguém perceberá”, esconda a senha do RACF e chame o change manager.

4. TCP/IP é a estrada; DRDA é o idioma

Durante a viagem de volta a 1986, o jovem padawan viu um telefone público.

Igor levantou o aparelho e começou a falar COBOL com a telefonista.

— MOVE TELEFONISTA TO WS-CONEXAO.

A telefonista desligou.

O telefone funcionava. A linha estava ativa. Mas ninguém falava o mesmo idioma.

Essa é a diferença entre TCP/IP e DRDA.

TCP/IP estabelece o transporte confiável e ordenado entre endpoints. DRDA define como clientes e servidores de bancos relacionais distribuem solicitações e respostas.

Uma forma didática de separar as camadas é:

SQL          → O que queremos fazer
API          → Como a aplicação solicita
Driver       → Quem implementa a solicitação
DRDA         → Como cliente e Db2 conversam
TLS          → Como o conteúdo pode ser protegido
TCP/IP       → Como os bytes viajam

Por isso, executar:

ping db2host

e receber resposta não prova que o Db2 funciona.

O ping pode confirmar que algum caminho IP está disponível, mas não confirma:

Que a porta do DDF está aberta;
Que o listener está ativo;
Que o firewall permite o tráfego da aplicação;
Que o TLS consegue negociar;
Que o certificado é confiável;
Que o usuário consegue autenticar;
Que o location name está correto;
Que os pacotes existem;
Que o usuário possui autorização;
Que a SQL pode ser executada.

É como chegar à cidade correta e concluir que sua reserva no hotel está garantida.

5. No z/OS, quem abre o portal é o DDF

Quando o destino é Db2 for z/OS, entra em cena o:

DDF — Distributed Data Facility

O DDF é o componente que permite ao Db2 for z/OS participar do processamento distribuído, recebendo e iniciando comunicações com sistemas remotos.

Para uma aplicação externa estabelecer uma conexão, o DDF precisa estar:

Instalado e configurado;
Ativo;
Associado a portas TCP/IP;
Publicado no endereço correto;
Integrado à segurança;
Preparado para o protocolo utilizado.

A IBM deixa claro que o subsistema Db2 for z/OS precisa ter o DDF habilitado para receber conexões JDBC por TCP/IP. IBM — JDBC acessando Db2 for z/OS

No diagnóstico, dois comandos são particularmente conhecidos:

-DISPLAY DDF DETAIL

-DISPLAY LOCATION

Eles podem ajudar a verificar informações como:

Estado do DDF;
Location name;
Endereços;
Portas;
Informações de comunicação;
Características do ambiente distribuído.

Se o DDF estiver parado, a aplicação poderá enxergar o host, alcançar o z/OS e mesmo assim não falar com o Db2.

Easter egg número 2: no filme, a banheira precisava de uma combinação improvável de água, energia e bebida derramada. No datacenter, DDF não deve depender de Igor derramando energético no console.

6. DBAT: o funcionário que recebe o visitante

Depois que a conexão chega ao DDF, o trabalho precisa ser processado. Entra o:

DBAT — Database Access Thread

O DBAT é uma thread de acesso ao banco utilizada no processamento de solicitações distribuídas.

Imagine a recepção de um hotel:

A conexão é o hóspede;
DDF é a recepção;
A autenticação verifica o documento;
O DBAT é o funcionário que atende a solicitação;
O package define determinados recursos e regras de execução;
O Db2 acessa os dados.

Uma conexão lógica não significa necessariamente um DBAT permanentemente dedicado.

O Db2 for z/OS pode utilizar pooling de DBATs. Depois de uma unidade de trabalho, um DBAT elegível pode ser liberado para atender outra conexão. Isso reduz o consumo de recursos em ambientes com grandes quantidades de conexões remotas. IBM — Gerenciamento de DBATs

Também existem high-performance DBATs. Nesse caso, o DBAT permanece associado à conexão através das fronteiras de transação, reduzindo determinados custos de liberação e reassociação, mas mantendo recursos dedicados por mais tempo. IBM — Como DBATs processam conexões remotas

Portanto:

Conexão ≠ DBAT permanentemente ativo

Essa diferença torna-se crucial quando containers entram na história.

Suponha:

50 pods
× 100 conexões máximas
= 5.000 conexões potenciais

Agora o Kubernetes faz autoscaling:

200 pods
× 100 conexões
= 20.000 conexões potenciais

O desenvolvedor olha para uma configuração e pensa:

“Cem conexões é um número pequeno.”

O Db2 olha para o conjunto e vê vinte mil visitantes atravessando o portal temporal.

7. Conexão direta ou servidor Db2 Connect?

Nas arquiteturas antigas, era comum encontrar:

Aplicação
    ↓
Servidor Db2 Connect
    ↓
Db2 for z/OS

O servidor Db2 Connect funcionava como um ponto intermediário de conectividade.

Essa arquitetura ainda pode fazer sentido em situações específicas:

Centralização de determinados componentes;
Ambientes com requisitos legados;
Federation;
Monitores transacionais;
Necessidades operacionais específicas;
Administração concentrada.

Mas não é obrigatório colocar um gateway intermediário em todos os cenários.

Muitas aplicações modernas utilizam:

Aplicação + driver IBM
    ↓
DRDA/TCP/IP
    ↓
Db2 for z/OS

A própria IBM recomenda conexão direta por cliente ou driver em muitos ambientes, reduzindo a necessidade de uma máquina intermediária. IBM — Opções de conexão cliente-servidor

Conexão direta

Vantagens:

Menos saltos de rede;
Menor latência;
Menos infraestrutura intermediária;
Diagnóstico potencialmente mais simples;
Recursos implementados diretamente pelo driver.

Cuidados:

Controle de versões dos drivers;
Distribuição de certificados;
Configuração em múltiplos servidores;
Licenciamento;
Padronização entre equipes.

Gateway Db2 Connect

Vantagens possíveis:

Ponto central de conectividade;
Administração concentrada;
Suporte a arquiteturas específicas;
Menor dispersão de certas configurações.

Cuidados:

Mais um salto;
Mais um componente monitorado;
Possível gargalo;
Possível ponto único de falha;
Maior cadeia de diagnóstico.

Um gateway não é automaticamente ruim. Conexão direta não é automaticamente melhor. A escolha deve nascer dos requisitos, não da nostalgia de um diagrama de 1998.

8. O que acontece durante um `SELECT`?

Considere:

SELECT NOME,
       LIMITE_CREDITO
  FROM CLIENTE
 WHERE CPF = ?

A aplicação Java executa algo aparentemente simples:

ResultSet rs = statement.executeQuery();

Por baixo dessa linha, a banheira do tempo entra em funcionamento:

A requisição da aplicação precisa de uma conexão;
A aplicação solicita essa conexão ao pool;
O pool entrega uma conexão existente ou cria outra;
JDBC recebe a solicitação;
O driver IBM converte os parâmetros;
O driver monta a conversa DRDA;
TLS pode proteger o tráfego;
TCP/IP transporta as mensagens;
DDF recebe a requisição no z/OS;
O usuário é autenticado;
A conexão é associada a um DBAT;
O Db2 identifica o package e o contexto;
As autorizações são verificadas;
A SQL é preparada ou localizada;
O access path é utilizado;
Os dados são lidos;
As linhas retornam por DRDA;
O driver converte os tipos;
JDBC entrega o ResultSet;
A aplicação consome os registros;
COMMIT ou ROLLBACK encerra a unidade de trabalho;
A conexão pode retornar ao pool.

Portanto, “tempo da query” pode significar coisas diferentes:

Espera pelo pool;
Abertura da conexão;
Autenticação;
Negociação TLS;
Transporte de rede;
Espera por DBAT;
Espera por WLM;
Prepare;
Execução;
Locks;
Fetch das linhas;
Conversão no driver;
Processamento na aplicação.

Quando alguém disser “o Db2 demorou oito segundos”, primeiro descubra onde os oito segundos foram gastos.

9. Packages: o detalhe que aparece quando chega o `-805`

Uma conexão pode alcançar o host, atravessar a porta, autenticar o usuário e ainda assim falhar.

Um erro clássico é:

SQLCODE -805
SQLSTATE 51002

Ele normalmente indica que um package necessário não foi encontrado, não está disponível no contexto esperado ou não corresponde ao que está sendo solicitado.

Drivers JDBC e CLI utilizam packages preparados no servidor. A collection NULLID aparece frequentemente nesses ambientes.

A IBM disponibiliza, por exemplo, o utilitário DB2Binder para vincular packages utilizados pelo IBM Data Server Driver for JDBC and SQLJ no Db2 for z/OS. IBM — DB2Binder

É possível também trabalhar com collections diferentes e níveis distintos de APPLCOMPAT.

Exemplo conceitual:

NULLID
NULLID_V12R1M500
NULLID_V12R1M501

Cada collection pode representar uma combinação planejada de packages e compatibilidade.

Isso permite que uma aplicação nova utilize determinadas capacidades sem obrigar todas as aplicações antigas a avançarem imediatamente.

Dica de produção:

Antes de atualizar o driver, confirme quais packages serão necessários, quem realizará o bind, quais opções serão usadas e como será feito o rollback.

Atualizar o .jar e esquecer o servidor é uma maneira elegante de transformar uma melhoria técnica em incidente noturno.

10. `COMMIT`, `ROLLBACK` e a viagem que talvez já tenha acontecido

Considere uma transferência:

UPDATE CONTA
   SET SALDO = SALDO - 100
 WHERE CONTA_ID = 10;

UPDATE CONTA
   SET SALDO = SALDO + 100
 WHERE CONTA_ID = 20;

As duas operações precisam pertencer à mesma unidade de trabalho.

Em JDBC:

connection.setAutoCommit(false);

try {
    debitar.executeUpdate();
    creditar.executeUpdate();
    connection.commit();
} catch (Exception e) {
    connection.rollback();
    throw e;
}

O commit() não acontece apenas dentro da aplicação Java. A solicitação precisa viajar até o servidor e ser processada pelo Db2.

Agora imagine:

A aplicação envia o COMMIT;
O Db2 recebe;
O Db2 confirma a transação;
A resposta retorna;
A rede cai antes de a aplicação receber a confirmação.

A aplicação pode concluir:

“Não recebi sucesso; tentarei novamente.”

Mas o Db2 talvez já tenha confirmado.

Se o retry repetir a operação inteira, podemos debitar o cliente duas vezes.

Esse é o lado realmente perigoso das falhas distribuídas: nem sempre sabemos imediatamente se a viagem temporal ocorreu.

Por isso, operações críticas precisam considerar:

Idempotência;
Identificador único de transação;
Controle de duplicidade;
Reconciliação;
Logs técnicos e de negócio;
Estado desconhecido após falhas;
Estratégias específicas de retry.

Retry não é GO TO TENTE-NOVAMENTE aplicado cegamente a qualquer erro.

11. Pool de conexões: o táxi que retorna à praça

Abrir uma conexão para cada requisição custa caro. Por isso, servidores de aplicações normalmente mantêm pools.

Requisição
    ↓
Solicita conexão
    ↓
Pool entrega uma conexão
    ↓
Aplicação executa SQL
    ↓
Commit ou rollback
    ↓
Conexão retorna ao pool

O problema surge quando a aplicação devolve a conexão em estado inadequado.

Ela pode retornar com:

Transação aberta;
Cursor abandonado;
Isolation level alterado;
CURRENT SCHEMA modificado;
Registros especiais alterados;
Erro não tratado;
Estado inválido após falha de comunicação.

Exemplo:

SET CURRENT SCHEMA = FINANCEIRO;

Se a aplicação devolve a conexão sem restaurar o estado, o próximo usuário pode herdar aquela configuração.

O pool é como um táxi reutilizado. O próximo passageiro não deveria encontrar no banco traseiro:

A carteira do anterior;
Uma transação aberta;
Um cursor;
O schema financeiro;
Nem Igor tentando voltar a 1986.

Boas práticas incluem:

Sempre fechar recursos;
Usar blocos try-with-resources;
Executar rollback em exceções;
Configurar validação de conexões;
Definir timeouts;
Dimensionar mínimo e máximo;
Monitorar espera pelo pool;
Evitar pools enormes em cada instância;
Considerar o total agregado de containers.

12. Segurança: TCP/IP não é colete à prova de balas

A existência de uma conexão TCP/IP não garante que seu conteúdo esteja protegido.

No Db2 for z/OS, TLS pode ser implementado com participação do z/OS Communications Server e AT-TLS. O SECPORT pode identificar a porta utilizada para conexões seguras. IBM — TLS no Db2 for z/OS

Devemos separar quatro perguntas:

Quem é você?

Autenticação:

Usuário e senha;
RACF PassTicket;
Kerberos;
Outros mecanismos previstos pela arquitetura.

A conversa está protegida?

Transporte:

TLS;
Certificados;
Truststore;
Cipher suites;
AT-TLS;
Políticas de rede.

O que você pode fazer?

Autorização:

SELECT;
INSERT;
UPDATE;
DELETE;
EXECUTE em package;
EXECUTE em stored procedure;
Uso de uma collection.

Quem é a aplicação?

Identificação operacional:

Application name;
Workstation;
Client user;
Accounting string;
Correlation ID.

Sem identificação adequada, o monitoramento pode apresentar centenas de conexões chamadas simplesmente de:

db2jcc_application

É como receber 500 viajantes temporais e registrar todos como “Igor”.

13. Por que uma SQL rápida no SPUFI pode ser lenta no Java?

Essa comparação aparece frequentemente:

“No SPUFI leva meio segundo; no Java leva dez segundos. Logo, Java ou Db2 Connect está lento.”

Talvez. Mas ainda não foi provado.

Compare:

A SQL é exatamente igual?
Os valores dos parâmetros são iguais?
O usuário é o mesmo?
O schema é o mesmo?
O package é o mesmo?
O APPLCOMPAT é igual?
O isolation level é igual?
A aplicação executa apenas uma SQL?
O tempo inclui espera no pool?
Há latência de rede?
Quantas linhas retornam?
Qual é o fetch size?
A aplicação processa cada linha lentamente?
Existe gateway intermediário?
Há conversões de tipos?
A conexão foi aberta durante a medição?

SPUFI e aplicação distribuída podem usar caminhos operacionais muito diferentes.

A aplicação talvez faça:

1 consulta para obter clientes
+ 1 consulta para cada cliente

Para mil clientes:

1 + 1.000 = 1.001 SQLs

Esse é o conhecido problema N+1.

O Db2 pode executar cada consulta rapidamente, mas a aplicação acumula mil viagens de rede.

O relatório final dirá “Db2 lento”. O Db2, inocente, estará apenas respondendo mil vezes à mesma insistência.

14. Fetch size: quantas malas entram em cada viagem?

Se uma consulta retorna 100 mil linhas, trazê-las uma por uma pode ser desastroso.

Imagine:

100.000 linhas
÷ 10 linhas por bloco
= 10.000 trocas

Com blocos de cem linhas:

100.000
÷ 100
= 1.000 trocas

Ajustar fetch size e blocagem pode reduzir viagens, mas aumentar indiscriminadamente também não é solução.

Blocos maiores podem:

Consumir mais memória;
Aumentar o volume transferido antecipadamente;
Ser desperdiçados se a aplicação abandonar o cursor;
Pressionar o heap do servidor.

O ajuste deve considerar:

Tamanho médio da linha;
Volume do resultado;
Latência;
Memória disponível;
Padrão de consumo;
Necessidade real do usuário.

A melhor otimização pode ser não buscar 100 mil linhas.

Às vezes, a solução correta é:

FETCH FIRST 100 ROWS ONLY

ou implementar paginação adequada.

15. Data Sharing, Sysplex e a banheira com várias saídas

Em um Db2 Data Sharing Group, vários membros podem atender o workload.

Aplicação
    ↓
Driver com recursos de disponibilidade
    ↓
Location do grupo
    ↓
DB2A / DB2B / DB2C

O driver pode colaborar com:

Sysplex workload balancing;
Automatic client reroute;
Failover;
Afinidade;
Concentração de transporte.

Mas esses recursos precisam ser planejados e configurados. Não surgem apenas porque alguém escreveu “HA” no PowerPoint.

Também é importante compreender:

Reconectar não significa continuar uma transação interrompida exatamente de onde ela parou.

O driver pode encontrar outro membro disponível, mas a aplicação ainda precisa tratar:

Unidade de trabalho anterior;
Commit de resultado incerto;
Cursores perdidos;
Estado da sessão;
Reexecução segura.

Alta disponibilidade reduz interrupções. Não revoga as leis do processamento distribuído.

16. Mapa rápido dos erros

Sintoma	Camada provável	O que verificar
Host desconhecido	DNS	Nome e resolução
`Connection refused`	TCP/DDF	Porta, listener, firewall
Timeout de conexão	Rede	Rota, firewall, endereço
Falha de handshake	TLS	Certificado, truststore, cipher
Usuário inválido	Segurança	Credencial, RACF, método
`SQLCODE -805`	Package	Collection, bind, versão
`SQLCODE -551`	Autorização	Privilégios
`SQLCODE -911/-913`	Concorrência	Lock, deadlock, timeout
`SQLCODE -904`	Recurso	Reason code e resource name
`SQL30081N`	Comunicação	Protocolo, socket e códigos
`-4499`	JDBC/comunicação	Exceções encadeadas e timeout
Muitas conexões ociosas	Pool	Mínimo, máximo e total agregado
Lentidão intermitente	Várias	Pool, DBAT, WLM, lock, rede

Nunca pare na primeira mensagem genérica.

Em JDBC, investigue as exceções encadeadas. Registre:

SQLCODE;
SQLSTATE;
Reason code;
Timestamp;
Host de origem;
Nome da aplicação;
Versão do driver;
Correlation ID;
URL sem senha;
Operação executada;
Estado da transação.

17. Passo a passo do jovem padawan COBOL

Passo 1 — Desenhe o caminho real

Aplicação
→ servidor
→ driver
→ gateway, se houver
→ firewall
→ porta
→ DDF
→ Db2

Não use o desenho idealizado. Use o caminho de produção.

Passo 2 — Identifique o driver

Descubra:

Nome;
Versão;
Arquivo;
Configuração;
Compatibilidade;
Licença aplicável.

Passo 3 — Confirme host, porta e location

Não confunda:

Nome DNS;
Nome do subsistema;
Location name;
Alias;
Nome do data sharing group;
Database da URL JDBC.

Passo 4 — Teste a rede

Verifique:

DNS;
Rota;
Porta;
Firewall;
Origem real da aplicação.

O teste deve ser executado a partir do servidor onde o programa roda, não do notebook do analista.

Passo 5 — Verifique TLS

Confirme:

Porta segura;
Validade do certificado;
Cadeia de confiança;
Truststore;
Nome do host;
Política AT-TLS.

Passo 6 — Verifique DDF

No z/OS:

DDF está ativo?
A porta está correta?
O location está correto?
Existem mensagens DSNL?
A conexão chega?

Passo 7 — Verifique autenticação

Pergunte:

O usuário existe?
Está revogado?
A credencial expirou?
O método é compatível?
O RACF registrou falha?

Passo 8 — Verifique packages

Se houver -805:

Qual package?
Qual collection?
Qual versão do driver?
Houve atualização?
O bind foi feito?
O APPLCOMPAT é compatível?

Passo 9 — Verifique autorização

Se houver -551:

Qual authid?
Qual objeto?
Qual operação?
A autorização é direta ou por papel?
O usuário pode executar o package?

Passo 10 — Verifique a unidade de trabalho

Autocommit está ativo?
Existe commit explícito?
O rollback é garantido?
A conexão volta limpa ao pool?
Há transações longas?

Passo 11 — Verifique performance

Espera no pool;
Tempo de conexão;
Tempo de SQL;
Tempo de fetch;
Tempo da aplicação;
Lock;
DBAT;
WLM;
Número de viagens.

Passo 12 — Documente o resultado

Uma solução que vive apenas na memória do analista sofrerá um DELETE quando ele sair de férias.

18. Curiosidades escondidas na banheira

Curiosidade 1 — O nome histórico pode denunciar a idade do desenho

O infográfico usa “Db2 for i5/OS”. A nomenclatura atual é Db2 for IBM i.

Também aparece algo parecido com “Db2 for x/OS”, provavelmente um erro gráfico para Db2 for z/OS.

Curiosidade 2 — SQL não é API de transporte

SQL descreve operações relacionais. JDBC, ODBC e CLI oferecem interfaces para a aplicação. O driver transforma essas chamadas em comunicação com o servidor.

Curiosidade 3 — “Conectou” não significa “funcionou”

Existem vários marcos:

Host respondeu
≠ porta abriu
≠ TLS negociou
≠ usuário autenticou
≠ package foi encontrado
≠ autorização concedida
≠ SQL executou
≠ commit confirmou

Curiosidade 4 — O nome da aplicação é recurso de produção

Preencher corretamente os atributos do cliente ajuda:

Accounting;
WLM;
Monitoramento;
Profile tables;
Diagnóstico;
Chargeback;
Identificação de ofensores.

Curiosidade 5 — O erro mais perigoso pode vir depois do sucesso

A SQL pode ter sido executada e confirmada, mas a resposta pode ter se perdido. Isso cria estado incerto e torna retries cegos particularmente perigosos.

Curiosidade 6 — Microserviço não reduz automaticamente o consumo

Transformar um monólito em cem containers pode multiplicar:

Pools;
Conexões;
Certificados;
Logs;
Timeouts;
Pontos de falha;
Viagens ao Db2.

A arquitetura ficou distribuída. O bom senso também precisa ser.

19. O mapa mental definitivo

Quando uma aplicação distribuída acessa Db2 for z/OS, pense nesta sequência:

A aplicação pede
A API formaliza
O driver traduz
DRDA organiza
TLS protege
TCP/IP transporta
DDF recebe
RACF autentica
WLM classifica
DBAT trabalha
O package sustenta
Db2 executa
O cursor entrega
COMMIT confirma
O pool reutiliza
A monitoração conta a história

Se cada componente possuir dono, versão, configuração, métrica e procedimento, a arquitetura será administrável.

Se tudo for chamado genericamente de “Db2 Connect”, o incidente será uma excursão temporal sem mapa.

Epílogo — Ninguém voltou para 1986, mas o chamado foi encerrado

De volta ao datacenter, o jovem padawan COBOL examinou novamente o erro:

ERRORCODE=-4499
SQLSTATE=08001

Dessa vez ele não começou pelo SELECT.

Primeiro confirmou:

O servidor de origem;
A versão do driver;
O hostname;
A porta segura;
A cadeia de certificados;
O status do DDF;
As mensagens no z/OS.

Descobriu que o certificado havia sido renovado no servidor, mas o truststore da aplicação ainda continha a cadeia anterior.

A rede funcionava.

O DDF funcionava.

O Db2 funcionava.

A SQL nunca havia chegado ao banco.

Igor olhou para a banheira e perguntou:

— Então podemos colocá-la em produção?

O padawan respondeu:

IF IGOR-IN-PRODUCTION
    MOVE 'N' TO APPROVAL-FLAG
    PERFORM CHAMAR-CHANGE-MANAGER
END-IF

A maior lição daquela noite não foi apenas aprender o que Db2 Connect faz.

Foi compreender que arquiteturas distribuídas são formadas por contratos encadeados. Cada camada promete alguma coisa à camada seguinte:

A aplicação promete usar corretamente a API;
O driver promete implementar a conversa;
DRDA promete organizar o diálogo;
TCP/IP promete transportar;
TLS promete proteger;
DDF promete receber;
DBAT promete processar;
O Db2 promete preservar integridade;
A aplicação promete saber quando confirmar ou desfazer.

Quando uma promessa é quebrada, o erro aparece em algum lugar da cadeia — nem sempre no lugar onde nasceu.

Db2 Connect, portanto, não é uma simples ponte entre um computador e um banco.

É uma máquina do tempo cuidadosamente controlada: leva aplicações escritas hoje até dados acumulados durante décadas, permite que Java, Python, .NET, ferramentas ODBC e sistemas modernos conversem com o Db2 for z/OS e demonstra que o mainframe não está preso ao passado.

O passado continua em produção.

E, ao contrário da banheira de Igor, processa bilhões de transações sem derramar energético no DDF.

Translate

quarta-feira, 14 de dezembro de 2022