 |
| Bellacosa Mainframe explica como funciona um programa COBOL com DB2 |
🔥☕ PACKAGE, PLAN, DBRM E O SUBMUNDO DA COMPILAÇÃO Db2 — O GUIA PADAWAN DO COBOL MAINFRAME ☕🔥
Todo programador COBOL iniciante passa por isso.
Você escreve:
EXEC SQL
SELECT *
FROM EMPLOYEE
END-EXEC.
compila…
e de repente aparecem criaturas malignas como:
- DBRM
- PACKAGE
- PLAN
- BIND
- DSNHPC
- SQLCODE -805
- SQLCODE -818
E o padawan pensa:
“Mas eu só queria fazer um SELECT…”
☕🔥
Então vamos entrar no verdadeiro submundo do Db2 z/OS.
☕ O MAIOR SEGREDO DO Db2
O Db2 NÃO executa SQL diretamente do fonte COBOL.
Ele precisa:
- analisar SQL
- validar objetos
- escolher access path
- gerar runtime structures
Por isso existe toda a cadeia:
SOURCE
↓
PRECOMPILE
↓
DBRM
↓
COMPILE
↓
LINK
↓
BIND PACKAGE
↓
BIND PLAN
↓
RUN
🔥 VISÃO GERAL DA ARQUITETURA
☕ SOURCE COBOL
Seu programa original.
Exemplo:
EXEC SQL
SELECT EMPNO
INTO :WS-EMPNO
FROM EMPLOYEE
END-EXEC.
Dataset típico:
USERID.COBOL.SOURCE(MEUCOB)
🔥 STEP 1 — PRECOMPILE
Programa usado:
//DB2PC EXEC PGM=DSNHPC
☕ O QUE É O DSNHPC?
É o:
Db2 PRECOMPILER
🔥 O QUE ELE FAZ?
Ele:
✅ encontra EXEC SQL
✅ valida sintaxe SQL
✅ remove SQL do COBOL
✅ gera COBOL expandido
✅ gera DBRM
☕ RESULTADO DO PRECOMPILE
Saídas:
| Saída | Função |
|---|---|
| COBOL expandido | será compilado |
| DBRM | usado no BIND |
🔥 O QUE É O DBRM?
DBRM =
DATABASE REQUEST MODULE
☕ PENSE NO DBRM COMO:
“o extrato SQL do seu programa”
Ele contém:
- SQL do programa
- informações internas Db2
- metadados SQL
🔥 O DBRM NÃO É EXECUTÁVEL
Isso é importante.
Ele NÃO roda.
Ele apenas alimenta o BIND.
☕ ONDE O DBRM É SALVO?
Normalmente em:
//DBRMLIB DD DSN=USERID.DBRM.LIB(MEUPRG)
Dataset típico:
USERID.DBRM.LIB
Tipo:
PDS ou PDSE
🔥 EXEMPLO REAL DE PRECOMPILE
//DB2PC EXEC PGM=DSNHPC,
// PARM=('HOST(IBMCOB),APOST')
☕ EXPLICANDO OS PARÂMETROS
HOST(IBMCOB)
Define linguagem COBOL IBM.
APOST
Aspas simples delimitam strings SQL.
SOURCE
Mantém fonte expandido legível.
XREF
Gera cross reference.
DATE(ISO)
Formato ISO de datas.
🔥 STEP 2 — COMPILE COBOL
Programa:
//COB EXEC PGM=IGYCRCTL
☕ O QUE ACONTECE?
Agora o compilador COBOL compila:
o COBOL expandido gerado pelo precompiler
🔥 ELE NÃO COMPILA MAIS EXEC SQL
Porque o precompiler já removeu.
☕ SAÍDA DO COMPILE
Gera:
OBJECT MODULE
temporário.
🔥 STEP 3 — LINK-EDIT
Programa:
//LKED EXEC PGM=IEWL
☕ O QUE O LINK FAZ?
Une:
- objeto COBOL
- bibliotecas runtime
- chamadas Db2
🔥 RESULTADO
LOAD MODULE EXECUTÁVEL
☕ ONDE FICA O LOAD MODULE?
Exemplo:
//SYSLMOD DD DSN=USERID.LOADLIB(MEUPRG)
Dataset típico:
USERID.LOADLIB
🔥 AGORA ENTRA O VERDADEIRO MUNDO Db2
Até aqui temos apenas:
programa COBOL executável
Mas o Db2 ainda NÃO sabe nada sobre ele.
☕ STEP 4 — BIND PACKAGE
Programa:
//BIND EXEC PGM=IKJEFT01
🔥 O QUE É O PACKAGE?
PACKAGE é:
o SQL compilado e otimizado do programa
☕ O PACKAGE CONTÉM
✅ access paths
✅ SQL otimizado
✅ metadados
✅ permissões
✅ informações de runtime
🔥 QUEM CRIA O PACKAGE?
O comando:
BIND PACKAGE
☕ O BIND USA:
- DBRM
- catálogo Db2
- índices
- estatísticas
- permissões
🔥 O ACCESS PATH NASCE AQUI
Db2 decide:
- index scan?
- tablespace scan?
- join order?
- sort?
- parallelism?
☕ ONDE PACKAGE É ARMAZENADO?
No próprio catálogo Db2.
Tabelas internas como:
SYSIBM.SYSPACKAGE
🔥 NÃO FICA EM PDS
Isso pega MUITOS iniciantes.
PACKAGE NÃO fica em dataset.
Fica dentro do Db2.
☕ EXEMPLO DE BIND PACKAGE
DSN SYSTEM(DBCG)
BIND PACKAGE(MYCOLL)
MEMBER(MEUPRG)
ACTION(REPLACE)
ISOLATION(CS)
VALIDATE(BIND)
EXPLAIN(YES)
🔥 EXPLICANDO OS PARÂMETROS
PACKAGE(MYCOLL)
Collection/package name.
MEMBER(MEUPRG)
Nome do DBRM.
ACTION(REPLACE)
Substitui package antigo.
ISOLATION(CS)
Cursor Stability.
VALIDATE(BIND)
Valida objetos no bind.
EXPLAIN(YES)
Salva access path.
☕ STEP 5 — BIND PLAN
Agora vem o PLAN.
🔥 O QUE É O PLAN?
PLAN é:
um agrupador de packages
☕ ANTIGAMENTE
Db2 antigo usava:
PLAN + DBRM
🔥 Db2 MODERNO USA:
PLAN + PACKAGE
☕ O PLAN FUNCIONA COMO
“container lógico de execução”
🔥 EXEMPLO
BIND PLAN(MYPLAN)
PKLIST(MYCOLL.*)
☕ PKLIST
Lista packages autorizados.
🔥 ONDE O PLAN FICA?
Também no catálogo Db2.
Tabela:
SYSIBM.SYSPLAN
☕ EXECUÇÃO — RUN
Agora sim:
RUN PROGRAM(MEUPRG)
PLAN(MYPLAN)
🔥 O FLUXO EM EXECUÇÃO
Programa chama:
PLAN
↓
PACKAGE
↓
SQL
↓
Db2 Engine
☕ ANALOGIA PADAWAN
Imagine:
☕ SOURCE
Receita escrita.
🔥 DBRM
Lista dos ingredientes.
☕ PACKAGE
Receita otimizada pelo chef.
🔥 PLAN
Cardápio do restaurante.
☕ LOAD MODULE
Cozinheiro executando.
☕🔥
🔥 ERROS MAIS FAMOSOS
☕ SQLCODE -805
O terror dos iniciantes.
PACKAGE NÃO ENCONTRADO
CAUSAS
✅ bind não executado
✅ collection errada
✅ package apagado
✅ plan errado
🔥 SQLCODE -818
TIMESTAMP MISMATCH
SIGNIFICA
LOAD MODULE ≠ PACKAGE atual.
ACONTECE QUANDO
recompila COBOL mas não rebinda package.
☕ SQLCODE -204
objeto não encontrado
NORMALMENTE
schema/qualifier errado.
🔥 SQLCODE -551
sem autorização
☕ COMO INVESTIGAR PROBLEMAS
🔥 VER PACKAGE
SELECT *
FROM SYSIBM.SYSPACKAGE
WHERE NAME = 'MEUPRG'
☕ VER PLAN
SELECT *
FROM SYSIBM.SYSPLAN
WHERE NAME = 'MYPLAN'
🔥 DISPLAY PACKAGE
-DISPLAY PACKAGE(*)
☕ O QUE O JUNIOR PRECISA ENTENDER
🔥 O COBOL NÃO EXECUTA SQL DIRETAMENTE
☕ O PACKAGE É O SQL “COMPILADO”
🔥 O PLAN ORGANIZA EXECUÇÃO
☕ O DBRM É A PONTE ENTRE FONTE E PACKAGE
🔥 O BIND DEFINE PERFORMANCE
☕ O ACCESS PATH NASCE NO BIND
🔥 O MAIOR SEGREDO DO Db2
Muitos problemas de produção NÃO estão no COBOL.
Estão em:
- package inválido
- bind errado
- access path ruim
- rebind problemático
- estatísticas ruins
- qualifier incorreto
☕ A VERDADEIRA MAGIA
Enquanto frameworks modernos escondem tudo…
o programador mainframe aprende:
- como SQL realmente executa
- como runtime funciona
- como otimização nasce
- como banco conversa com aplicação
E isso transforma um simples padawan COBOL…
num verdadeiro Jedi do Db2 z/OS. ☕🔥
