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. ☕🔥