 |
| Bellacosa Mainframe apresenta o db2i |
☕ Um Café no Bellacosa Mainframe
DB2I sem Mistérios: o Portal Clássico que Leva o Programador COBOL Padawan do Primeiro SELECT ao BIND de Produção
Imagine a seguinte cena.
Você acabou de entrar no TSO. A tela preta surgiu diante de seus olhos como a entrada de uma antiga fortaleza digital. Depois de informar seu usuário, sua senha e atravessar os corredores do ISPF, você finalmente executa o comando que abre uma das áreas mais tradicionais do universo IBM Z.
Na tela aparece:
DB2I PRIMARY OPTION MENU
No canto superior direito:
SSID: DB9G
E logo abaixo, um conjunto de opções aparentemente simples:
1 SPUFI
2 DCLGEN
3 PROGRAM PREPARATION
4 PRECOMPILE
5 BIND/REBIND/FREE
6 RUN
7 DB2 COMMANDS
8 UTILITIES
D DB2I DEFAULTS
X EXIT
Para um iniciante, isso pode parecer apenas mais um menu antigo em modo texto.
Mas não se engane, jovem padawan.
Essa tela é uma verdadeira central de comando para o desenvolvimento de aplicações COBOL com Db2 no mainframe. Ela reúne, em um único lugar, grande parte da jornada que transforma uma instrução SQL escrita dentro de um programa COBOL em uma operação real, autorizada, otimizada e executada contra um banco de dados corporativo.
Estamos diante do DB2I, sigla para Db2 Interactive.
Ele é um dos portais clássicos do desenvolvimento no IBM Z.
Neste café, vamos atravessar cada porta desse menu, entender sua história, observar como ele funciona, descobrir o que acontece nos bastidores e acompanhar, passo a passo, o nascimento de um programa COBOL com SQL embutido.
Prepare sua caneca.
O Db2 está acordado.
 |
| Bellacosa Mainframe e o db2i no emulador 3270 |
1. O que é o DB2I?
O DB2I é uma interface interativa integrada ao ISPF que permite acessar diversas funções relacionadas ao Db2 for z/OS.
Ele não é o banco de dados propriamente dito.
Também não é o compilador COBOL.
Ele funciona como um grande painel de controle que organiza diferentes ferramentas, processos e utilitários do ecossistema Db2.
Por meio dele, o usuário pode:
executar comandos SQL;
gerar declarações de tabelas;
preparar programas para execução;
realizar precompile;
executar BIND e REBIND;
rodar programas;
emitir comandos administrativos;
executar utilitários;
configurar parâmetros pessoais.
Sua grande virtude é a integração.
Em vez de o programador precisar decorar vários comandos, jobs e programas utilitários, o DB2I apresenta painéis que solicitam os parâmetros necessários e, em muitos casos, gera ou submete o JCL correspondente.
É importante entender que o DB2I não eliminou o JCL.
Ele apenas oferece uma interface mais amigável para preparar ou executar processos que, por baixo da superfície, continuam dependendo de datasets, procedimentos catalogados, módulos de carga, bibliotecas, parâmetros, planos e packages.
O DB2I é, portanto, uma espécie de ponte entre o usuário e a complexidade da infraestrutura.
2. Em que ambiente estamos trabalhando?
A tela mostrada é acessada por meio de um emulador TN3270.
A arquitetura normalmente segue este caminho:
Computador do usuário
|
v
Emulador TN3270
|
v
TSO/E
|
v
ISPF
|
v
DB2I
|
v
Subsistema Db2
Cada camada possui uma função.
O TN3270 permite que o computador moderno se comporte como um terminal IBM 3270.
O TSO/E oferece a sessão interativa no z/OS.
O ISPF fornece os painéis, menus, editores e serviços de produtividade.
O DB2I organiza as funções relacionadas ao Db2.
Finalmente, o subsistema Db2 executa o trabalho real de gerenciamento de dados, SQL, locks, buffer pools, logs, recuperação, autorização e otimização.
O programador enxerga uma tela.
O sistema enxerga uma cadeia inteira de componentes.
3. O significado de SSID
No canto superior direito aparece:
SSID: DB9G
SSID significa:
Subsystem Identifier
É o identificador do subsistema Db2 ao qual a sessão está associada.
Em um mesmo ambiente z/OS podem existir vários subsistemas Db2.
Por exemplo:
DB2D = desenvolvimento
DB2T = testes
DB2H = homologação
DB2P = produção
Também podem existir subsistemas diferentes por aplicação, unidade de negócio, versão, data sharing group ou finalidade técnica.
O nome não precisa obrigatoriamente indicar o ambiente. Cada empresa define sua convenção.
O ponto essencial é este:
Sempre confirme em qual SSID você está trabalhando antes de executar comandos.
Essa é uma regra de ouro.
Um SELECT executado no ambiente errado pode causar apenas confusão.
Um DELETE executado no ambiente errado pode causar uma reunião de emergência com vinte pessoas, três gerentes, dois DBAs e um café que já perdeu a temperatura.
4. Opção 1 — SPUFI
A primeira opção é:
1 SPUFI
SPUFI significa:
SQL Processor Using File Input
Em muitas documentações antigas, também é descrito como uma interface para processar SQL armazenado em um dataset de entrada.
Na prática, ele permite escrever instruções SQL em um arquivo, executá-las e armazenar os resultados em outro arquivo.
É uma das ferramentas mais tradicionais do Db2 for z/OS.
4.1 Como o SPUFI funciona?
O fluxo básico é:
Dataset de entrada
|
v
Instruções SQL
|
v
SPUFI
|
v
Db2
|
v
Dataset de saída
O usuário informa:
o dataset que contém o SQL;
o dataset em que deseja receber o resultado;
parâmetros de execução;
formato da saída;
número máximo de linhas;
opções de commit;
isolamento.
Um exemplo de dataset de entrada:
SELECT EMPNO,
FIRSTNME,
LASTNAME,
SALARY
FROM DSN8C10.EMP
ORDER BY LASTNAME;
O SPUFI envia a instrução ao Db2 e grava a resposta no dataset de saída.
4.2 Primeiro passo a passo com SPUFI
Suponha que você queira consultar uma tabela chamada CLIENTE.
Entre na opção 1.
Informe um dataset de entrada, por exemplo:
VAGNER.SQL.CONSULTA
Caso o dataset não exista, o DB2I poderá permitir sua alocação, dependendo das configurações.
No editor ISPF, escreva:
SELECT ID_CLIENTE,
NOME_CLIENTE,
LIMITE_CREDITO
FROM APP.CLIENTE
FETCH FIRST 20 ROWS ONLY;
Salve o membro ou dataset.
Retorne ao painel do SPUFI.
Informe o dataset de saída:
VAGNER.SQL.RESULTADO
Execute.
Depois, abra o resultado.
Você poderá ver algo semelhante a:
---------+---------+---------+---------+
ID_CLIENTE NOME_CLIENTE LIMITE_CREDITO
---------+---------+---------+---------+
000001 ANA SILVA 5000.00
000002 JOAO SOUZA 3500.00
000003 MARIA COSTA 8000.00
DSNE610I NUMBER OF ROWS DISPLAYED IS 3
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL
O formato real varia conforme parâmetros, versão e configuração do ambiente.
4.3 Cuidados com SPUFI
O SPUFI não é apenas uma ferramenta de consulta.
Ele também pode executar:
INSERT
UPDATE
DELETE
CREATE
ALTER
DROP
GRANT
REVOKE
Portanto, trate-o com respeito.
Antes de executar:
DELETE FROM APP.CLIENTE;
verifique se faltou uma cláusula WHERE.
Uma pequena ausência pode transformar uma manutenção de um registro em uma limpeza completa da tabela.
Uma boa prática é primeiro executar:
SELECT COUNT(*)
FROM APP.CLIENTE
WHERE STATUS = 'I';
Depois:
SELECT *
FROM APP.CLIENTE
WHERE STATUS = 'I'
FETCH FIRST 50 ROWS ONLY;
Somente após validar os dados, executar:
DELETE FROM APP.CLIENTE
WHERE STATUS = 'I';
O padawan prudente consulta antes de alterar.
5. Opção 2 — DCLGEN
A segunda opção é:
2 DCLGEN
DCLGEN significa:
Declarations Generator
Sua finalidade é gerar declarações de tabela e estruturas de host variables para linguagens como COBOL.
Suponha que exista a tabela:
CREATE TABLE APP.CLIENTE
(
ID_CLIENTE INTEGER NOT NULL,
NOME_CLIENTE VARCHAR(80) NOT NULL,
LIMITE_CREDITO DECIMAL(11,2),
DATA_CADASTRO DATE,
STATUS CHAR(1)
);
O programa COBOL precisa conhecer a estrutura dos campos que serão usados nas instruções SQL.
O DCLGEN pode gerar algo semelhante a:
EXEC SQL DECLARE APP.CLIENTE TABLE
( ID_CLIENTE INTEGER NOT NULL,
NOME_CLIENTE VARCHAR(80) NOT NULL,
LIMITE_CREDITO DECIMAL(11,2),
DATA_CADASTRO DATE,
STATUS CHAR(1)
) END-EXEC.
Também gera a estrutura COBOL:
01 DCLCLIENTE.
10 ID-CLIENTE PIC S9(9) COMP.
10 NOME-CLIENTE.
49 NOME-CLIENTE-LEN PIC S9(4) COMP.
49 NOME-CLIENTE-TEXT PIC X(80).
10 LIMITE-CREDITO PIC S9(9)V99 COMP-3.
10 DATA-CADASTRO PIC X(10).
10 STATUS-CLIENTE PIC X(1).
Os nomes e formatos podem variar de acordo com as opções escolhidas.
5.1 Por que o DCLGEN é tão importante?
Sem ele, o programador teria que converter manualmente cada tipo SQL em um formato COBOL.
Exemplos:
INTEGER -> PIC S9(9) COMP
SMALLINT -> PIC S9(4) COMP
DECIMAL(9,2) -> PIC S9(7)V99 COMP-3
CHAR(10) -> PIC X(10)
DATE -> PIC X(10)
VARCHAR -> campo de tamanho + texto
Essa conversão manual pode gerar erros.
Um campo definido incorretamente pode resultar em:
truncamento;
dados corrompidos;
SQLCODE negativo;
valores numéricos inválidos;
ABEND S0C7;
comportamento imprevisível.
O DCLGEN reduz essa possibilidade.
5.2 DCLGEN não substitui governança
Há um detalhe importante.
Gerar o DCLGEN é apenas o começo.
A empresa precisa controlar:
onde o copybook será armazenado;
qual versão está em produção;
quais programas usam aquela estrutura;
o que acontece quando a tabela muda;
se os programas precisam ser recompilados;
se o BIND precisa ser renovado.
Em ambientes maduros, alterações de tabela seguem processos rigorosos.
Não basta alterar uma coluna e esperar que todos os programas se adaptem magicamente.
No mainframe, magia sem controle costuma receber outro nome: incidente.
6. Opção 3 — Program Preparation
A opção 3 é:
3 PROGRAM PREPARATION
Ela reúne etapas necessárias para preparar uma aplicação Db2 para execução.
Um programa COBOL com SQL embutido precisa passar por várias fases:
Fonte COBOL com EXEC SQL
|
v
Precompile
|
+----> DBRM
|
v
Fonte COBOL transformado
|
v
Compilação
|
v
Objeto
|
v
Link-edit
|
v
Load module
|
v
BIND
|
v
Package ou plan
A opção Program Preparation tenta coordenar essas etapas.
É excelente para laboratórios, ambientes educacionais e processos padronizados.
Em grandes empresas, porém, muitas dessas fases são executadas por pipelines, ferramentas de change management ou JCLs corporativos.
Entre as ferramentas modernas ou tradicionais podem aparecer:
Endevor;
ISPW;
Changeman;
DBB;
Jenkins;
GitLab;
GitHub Actions;
IBM Developer for z/OS;
zBuilder.
Mesmo assim, o conceito permanece exatamente o mesmo.
7. Opção 4 — Precompile
A opção 4 chama o precompiler do Db2.
Essa é uma das etapas mais fascinantes.
O compilador COBOL não compreende diretamente uma instrução como:
EXEC SQL
SELECT NOME_CLIENTE,
LIMITE_CREDITO
INTO :WS-NOME,
:WS-LIMITE
FROM APP.CLIENTE
WHERE ID_CLIENTE = :WS-ID
END-EXEC.
O SQL embutido precisa ser tratado antes da compilação COBOL.
O precompiler percorre o fonte e identifica blocos entre:
EXEC SQL
e:
END-EXEC
Ele separa as instruções SQL e gera dois resultados principais:
Um fonte COBOL modificado.
Um DBRM.
7.1 O que é o DBRM?
DBRM significa:
Database Request Module
Ele contém representações das instruções SQL extraídas do programa.
O DBRM não é o executável.
Ele também não é uma tabela.
Ele é um artefato intermediário utilizado posteriormente no BIND.
Pense nele como um dossiê contendo os pedidos de acesso ao banco feitos pelo programa.
Exemplo conceitual:
Programa: PGMCAD01
SQL 1:
SELECT NOME_CLIENTE
FROM APP.CLIENTE
WHERE ID_CLIENTE = ?
SQL 2:
UPDATE APP.CLIENTE
SET STATUS = ?
WHERE ID_CLIENTE = ?
Esse conjunto de solicitações será analisado pelo Db2 durante o BIND.
7.2 O que acontece com o fonte COBOL?
O SQL é substituído ou acompanhado por chamadas apropriadas à interface do Db2.
O fonte resultante pode conter referências a módulos e estruturas necessárias para a comunicação com o banco.
Depois disso, o compilador COBOL consegue processar o programa.
O fluxo é:
COBOL + SQL
|
v
Precompiler Db2
|
+----> DBRM
|
v
COBOL sem SQL nativo
|
v
Compiler
8. SQLCA: o mensageiro do Db2
Quase todo programa COBOL com Db2 possui:
EXEC SQL
INCLUDE SQLCA
END-EXEC.
SQLCA significa:
SQL Communication Area
É uma estrutura usada para receber informações sobre a execução da instrução SQL.
O campo mais famoso é:
SQLCODE
Exemplos:
SQLCODE = 0 sucesso
SQLCODE = 100 nenhuma linha encontrada
SQLCODE = -811 mais de uma linha retornada
SQLCODE = -904 recurso indisponível
SQLCODE = -911 deadlock ou timeout com rollback
SQLCODE = -913 deadlock ou timeout
SQLCODE = -805 package não encontrado
SQLCODE = -818 timestamp inconsistente
Um programa sério deve testar o SQLCODE após cada operação relevante.
Exemplo:
EXEC SQL
SELECT NOME_CLIENTE
INTO :WS-NOME
FROM APP.CLIENTE
WHERE ID_CLIENTE = :WS-ID
END-EXEC.
EVALUATE SQLCODE
WHEN 0
DISPLAY 'CLIENTE ENCONTRADO: ' WS-NOME
WHEN 100
DISPLAY 'CLIENTE NAO ENCONTRADO'
WHEN OTHER
DISPLAY 'ERRO SQLCODE: ' SQLCODE
END-EVALUATE.
Ignorar o SQLCODE é como pilotar uma nave sem olhar o painel.
Talvez ela continue voando.
Talvez o motor já esteja em chamas.
9. Opção 5 — BIND, REBIND e FREE
A opção 5 é uma das mais importantes do menu:
5 BIND/REBIND/FREE
Esses três comandos controlam packages e plans.
10. O que é BIND?
O BIND pega o DBRM e cria uma estrutura executável pelo Db2, geralmente um package.
Durante o BIND, o Db2:
valida as instruções SQL;
verifica objetos referenciados;
avalia autorizações;
analisa estatísticas;
escolhe caminhos de acesso;
registra dependências;
cria o package;
armazena informações no catálogo.
O otimizador decide como acessar os dados.
Ele pode escolher:
table space scan;
index scan;
index-only access;
nested loop join;
merge scan join;
hybrid join;
acesso por particionamento;
paralelismo.
Duas instruções SQL textualmente iguais podem receber caminhos de acesso diferentes dependendo de:
índices;
cardinalidade;
distribuição de dados;
estatísticas;
parâmetros de BIND;
versão do Db2;
nível de função;
configuração do subsistema.
10.1 Package e plan
Um package contém a forma preparada das instruções SQL de um programa ou unidade lógica.
Um plan organiza a execução e pode referenciar collections e packages.
No modelo moderno, é comum trabalhar principalmente com packages.
Fluxo simplificado:
Programa COBOL
|
v
Package
|
v
Collection
|
v
Plan
|
v
Db2
Nem todas as empresas usam exatamente a mesma convenção, mas o conceito geral permanece.
11. O que é REBIND?
O REBIND recria o package ou plan sem precisar gerar um novo DBRM.
Ele é útil quando:
estatísticas foram atualizadas;
índices foram criados;
índices foram removidos;
o volume de dados mudou;
houve alteração de parâmetros;
o Db2 foi atualizado;
deseja-se obter um novo access path.
Exemplo clássico:
RUNSTATS
|
v
Novas estatísticas
|
v
REBIND
|
v
Novo caminho de acesso
O programa COBOL pode permanecer o mesmo.
O executável pode permanecer o mesmo.
Mas o Db2 pode escolher uma estratégia diferente para acessar os dados.
Esse desacoplamento é uma das maiores forças da arquitetura Db2.
12. O que é FREE?
FREE remove packages ou plans do catálogo.
É uma operação poderosa e potencialmente perigosa.
Se você remover um package necessário, o programa poderá falhar com erro semelhante ao:
SQLCODE -805
Esse erro normalmente indica que o package esperado não foi encontrado, não está disponível na collection correta ou não corresponde ao que o programa está tentando usar.
Nunca execute FREE por curiosidade em ambiente corporativo.
Curiosidade é excelente para estudar.
Em produção, curiosidade sem mudança aprovada pode virar RCA.
13. Opção 6 — RUN
A opção 6 permite executar um programa SQL.
Dependendo da instalação, o painel solicita:
nome do programa;
plan;
parâmetros;
bibliotecas de carga;
datasets;
ambiente;
opções de execução.
Essa função é bastante útil para testes.
Em ambientes reais, programas batch normalmente são executados por JCL.
Um exemplo conceitual:
//RUNDB2 JOB ...
//STEP01 EXEC PGM=IKJEFT01
//STEPLIB DD DISP=SHR,DSN=APP.LOADLIB
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(DB9G)
RUN PROGRAM(PGMCAD01) PLAN(PLANAPP) -
LIB('APP.LOADLIB')
END
/*
O exemplo exato varia conforme o ambiente.
O programa pode também ser executado em:
CICS;
IMS;
stored procedure;
WLM;
batch;
TSO;
z/OS Unix;
aplicações distribuídas.
14. Opção 7 — Db2 Commands
A opção 7 permite emitir comandos administrativos do Db2.
Exemplos:
-DISPLAY DATABASE
-DISPLAY THREAD
-DISPLAY UTILITY
-DISPLAY BUFFERPOOL
-START DATABASE
-STOP DATABASE
-RECOVER INDOUBT
Esses comandos não são SQL.
Eles são comandos do subsistema Db2.
Por exemplo:
-DISPLAY DATABASE(APPDB)
Pode mostrar o estado dos objetos relacionados ao banco.
Outro exemplo:
-DISPLAY THREAD(*)
Pode exibir threads conectadas.
Essas funções geralmente são controladas por autorização.
Um programador comum talvez possa executar alguns comandos de consulta, mas não terá autoridade para iniciar, parar ou alterar recursos críticos.
E isso é saudável.
Segurança não é um obstáculo.
É o cinto de segurança da operação.
15. Opção 8 — Utilities
Os utilitários do Db2 são responsáveis por diversas tarefas essenciais de manutenção.
Entre os principais:
LOAD
UNLOAD
REORG
RUNSTATS
COPY
RECOVER
CHECK DATA
CHECK INDEX
REBUILD INDEX
QUIESCE
MODIFY RECOVERY
15.1 RUNSTATS
Coleta estatísticas sobre:
quantidade de linhas;
cardinalidade;
distribuição;
frequência;
índices;
colunas;
partições.
O otimizador usa essas informações para escolher access paths.
Estatística desatualizada pode levar a decisões ruins.
É como usar um mapa de uma cidade de 1995 para dirigir em 2026.
Algumas ruas ainda existem.
Outras viraram avenidas, túneis, condomínios e rotatórias criadas por alguém que parecia gostar muito de rotatórias.
15.2 REORG
Reorganiza os dados fisicamente.
Pode ajudar a:
reduzir fragmentação;
recuperar espaço;
melhorar clustering;
restaurar organização física;
tratar estados pendentes;
melhorar acesso.
15.3 COPY
Cria cópias de imagem para recuperação.
Sem cópias adequadas, uma falha pode se tornar uma tragédia operacional.
15.4 RECOVER
Restaura objetos após falhas ou perda de dados.
Pode utilizar:
image copies;
logs;
pontos de recuperação;
informações do catálogo.
15.5 LOAD
Carrega grandes volumes de dados com eficiência.
É muito mais apropriado para cargas massivas do que executar milhões de INSERTs individuais.
16. Opção D — DB2I Defaults
A opção D permite configurar padrões utilizados pelo DB2I.
Podem existir parâmetros para:
nomes de datasets;
classes de job;
opções de saída;
SQL terminator;
parâmetros de execução;
bibliotecas;
identificadores;
formato dos resultados.
Esses defaults economizam tempo.
Em vez de digitar os mesmos valores em todos os painéis, o usuário configura uma vez e reaproveita.
Porém, sempre revise os parâmetros antes de executar.
Um default antigo pode apontar para:
SSID incorreto;
biblioteca obsoleta;
plan antigo;
collection inadequada;
dataset inexistente.
Automação ajuda.
Automação desatualizada ajuda a errar mais rápido.
17. Passo a passo completo: criando um programa COBOL com Db2
Agora vamos juntar tudo.
Imagine um programa que consulta o nome de um cliente.
Passo 1 — Criar o DCLGEN
Use a opção 2.
Informe:
TABLE OWNER: APP
TABLE NAME: CLIENTE
Defina o dataset de saída:
VAGNER.COBOL.COPYLIB(DCLCLI)
O DCLGEN será gerado.
Passo 2 — Escrever o programa COBOL
Exemplo simplificado:
IDENTIFICATION DIVISION.
PROGRAM-ID. PGCLI001.
DATA DIVISION.
WORKING-STORAGE SECTION.
EXEC SQL
INCLUDE SQLCA
END-EXEC.
EXEC SQL
INCLUDE DCLCLI
END-EXEC.
01 WS-ID-CLIENTE PIC S9(9) COMP VALUE 100.
01 WS-NOME-CLIENTE PIC X(80).
PROCEDURE DIVISION.
EXEC SQL
SELECT NOME_CLIENTE
INTO :WS-NOME-CLIENTE
FROM APP.CLIENTE
WHERE ID_CLIENTE = :WS-ID-CLIENTE
END-EXEC
EVALUATE SQLCODE
WHEN 0
DISPLAY 'CLIENTE: ' WS-NOME-CLIENTE
WHEN 100
DISPLAY 'CLIENTE NAO ENCONTRADO'
WHEN OTHER
DISPLAY 'ERRO SQL: ' SQLCODE
END-EVALUATE
GOBACK.
Passo 3 — Precompile
Use a opção 4 ou Program Preparation.
Entradas:
Fonte COBOL
DBRM library
Copy library
Parâmetros SQL
Saídas:
Fonte COBOL modificado
DBRM
Listing
Mensagens
Verifique erros de sintaxe SQL.
Passo 4 — Compilar
O fonte modificado segue para o Enterprise COBOL.
O compilador gera:
Object deck
Compiler listing
Mensagens
Corrija qualquer erro COBOL.
Passo 5 — Link-edit
O objeto é transformado em load module ou program object.
Ele será armazenado em uma biblioteca de carga.
Exemplo:
VAGNER.APP.LOADLIB
Passo 6 — BIND PACKAGE
Use a opção 5.
Informe:
DBRM: PGCLI001
COLLECTION: APPDEV
PACKAGE: PGCLI001
OWNER: VAGNER
QUALIFIER: APP
Parâmetros comuns podem incluir:
ACTION(REPLACE)
ISOLATION(CS)
VALIDATE(BIND)
RELEASE(COMMIT)
CURRENTDATA(NO)
Os parâmetros exatos dependem dos padrões da empresa.
Passo 7 — BIND PLAN
Caso o ambiente utilize plan explícito para a execução, associe a package list ou collection.
Exemplo conceitual:
PLAN: PLANAPP
PKLIST: APPDEV.*
Passo 8 — Executar
Use a opção 6 ou submeta o JCL.
Observe:
retorno do job;
SQLCODE;
mensagens;
dumps;
saídas;
tempo de CPU;
quantidade de linhas.
18. Erros clássicos do padawan
SQLCODE -805
Package não encontrado.
Possíveis causas:
BIND não executado;
collection errada;
plan incorreto;
package removido;
versão incompatível.
SQLCODE -818
Incompatibilidade de timestamp entre programa e package.
Pode acontecer quando o programa foi recompilado, mas o package não foi gerado de forma correspondente.
A solução geralmente envolve sincronizar:
Precompile
Compile
Link-edit
Bind
SQLCODE -811
Um SELECT INTO retornou mais de uma linha.
Exemplo perigoso:
SELECT NOME_CLIENTE
INTO :WS-NOME
FROM APP.CLIENTE
WHERE STATUS = 'A';
Se existem mil clientes ativos, o Db2 não sabe qual retornar.
Use chave única, agregação ou cursor.
SQLCODE +100
Nenhuma linha encontrada.
Não é necessariamente erro.
Pode ser uma condição normal de negócio.
SQLCODE -911
Deadlock ou timeout com rollback.
O programa perdeu uma disputa por recurso e a unidade de trabalho foi desfeita.
É necessário avaliar:
ordem de acesso;
tempo entre commits;
índices;
isolamento;
concorrência;
volume de processamento.
19. Curiosidades históricas
O DB2I carrega a filosofia de uma época em que memória, largura de banda e espaço de tela eram recursos valiosos.
Por isso, seus painéis são diretos.
Não existem animações.
Não existem botões brilhantes.
Não existem notificações perguntando se você gostaria de conhecer cinco novidades.
Existe uma linha de comando, campos objetivos e uma tecla Enter.
Essa simplicidade ajudou o ambiente a permanecer produtivo por décadas.
Outra curiosidade é que muitos profissionais que começaram no Db2 em versões antigas ainda reconhecem imediatamente o menu.
Os detalhes evoluíram.
O banco ganhou novos tipos, novos níveis de função, novas capacidades e otimizações.
Mas a lógica fundamental continua familiar.
Isso é compatibilidade cultural.
Não apenas compatibilidade técnica.
20. Easter egg Bellacosa Mainframe
Vamos transformar a jornada em uma aventura galáctica.
O programa COBOL é um jovem Jedi.
O DCLGEN entrega o mapa da estrutura do planeta-tabela.
O precompiler é C-3PO, traduzindo SQL para uma linguagem compreendida pela infraestrutura.
O DBRM é o pergaminho contendo todas as missões de acesso ao banco.
O compilador COBOL treina o guerreiro.
O link-editor entrega o sabre de luz.
O BIND apresenta a missão ao Conselho Jedi.
O otimizador decide a rota: índice, scan, join, paralelismo.
O package é a autorização oficial.
O plan é o plano de batalha.
O SQLCA é o comunicador preso ao cinto.
E o SQLCODE informa se a missão foi cumprida ou se o grupo acabou preso em um compactador de lixo da Estrela da Morte.
O mais importante é compreender que nenhuma etapa existe por acaso.
O mainframe não gosta de improviso.
Ele gosta de processos repetíveis, auditáveis e previsíveis.
Essa disciplina é uma das razões pelas quais sistemas IBM Z sustentam bancos, governos, seguradoras, companhias aéreas, indústrias e cadeias globais de negócios.
Conclusão
A tela do DB2I pode parecer modesta, mas ela concentra uma quantidade impressionante de conhecimento.
Por trás de suas opções existem:
linguagens;
compiladores;
catálogos;
packages;
plans;
access paths;
estatísticas;
segurança;
recuperação;
concorrência;
utilitários;
JCL;
datasets;
décadas de engenharia.
Dominar o DB2I não significa apenas aprender a navegar em um menu.
Significa compreender o ciclo de vida de uma aplicação Db2 no z/OS.
O programador COBOL padawan que aprende apenas a escrever SELECT conhece a superfície.
O profissional que compreende precompile, DBRM, BIND, package, plan, SQLCA, utilitários e access path começa a enxergar o sistema inteiro.
E é nesse momento que a velha tela preta deixa de parecer antiga.
Ela passa a parecer aquilo que realmente é:
Um painel de controle compacto para uma das plataformas de dados mais robustas já construídas pela indústria da computação.
Portanto, na próxima vez que você entrar no DB2I e enxergar suas opções em ciano, não veja apenas números.
Veja uma linha de produção.
Veja o SQL sendo extraído.
Veja o DBRM sendo criado.
Veja o compilador trabalhando.
Veja o otimizador avaliando caminhos.
Veja o package sendo autorizado.
Veja o programa entrando em execução.
Porque, no IBM Z, quase sempre existe muito mais acontecendo por trás da tela do que o terminal permite enxergar.
E essa, jovem padawan, é parte da beleza do mainframe.
