Single Source of Truth (SSOT): a verdade nua, crua… e versionada

 

Bellacosa Mainframe e o conceito de single source of truth

Single Source of Truth (SSOT): a verdade nua, crua… e versionada

Se existe um conceito que todo arquiteto, analista, DBA, operador e até estagiário já ouviu — e todo mundo acha que já tem — esse conceito é o tal do Single Source of Truth.
Spoiler: quase ninguém tem de verdade. E no mainframe isso é ainda mais sagrado (e mais difícil).

Senta que lá vem história.

---

🧠 Origem: quando a verdade ainda cabia em um arquivo VSAM

Antes de buzzwords, cloud, data mesh e dashboards coloridos, o SSOT já existia — só não tinha nome chique.

Nos anos 60/70, no mundo IBM Mainframe, a regra era simples:

“Existe um dado oficial. O resto é cópia, relatório ou dor de cabeça.”

• Um master file VSAM

• Um DB2 table owner bem definido

• Um CICS que mandava na regra de negócio

Se o saldo do cliente estava no arquivo X, qualquer outro valor estava errado, não “divergente”.

👉 Isso era SSOT by design, não por moda.

---

📜 Definição curta (para colar na parede da sala)

Single Source of Truth é a fonte única, autorizada e confiável de um dado, regra ou estado de negócio.

• Não é só onde o dado está

• É quem manda nele

• É quem pode mudar

• É quem responde quando dá problema

No mainframe, isso sempre foi levado a sério porque…
💸 erro de dado = dinheiro real sumindo.

---

🏗️ SSOT no Mainframe: raiz forte, galhos controlados

No mundo IBM Mainframe, o SSOT normalmente assume estas formas:

• 📦 DB2 → verdade transacional

• 📁 VSAM KSDS/ESDS → registros mestres históricos

• 🧠 CICS → verdade das regras online

• 📊 SMF/RMF → verdade operacional

• 🔐 RACF → verdade de segurança (e ponto final)

E aqui vai a regra de ouro, estilo Bellacosa:

Se dois sistemas “mandam” no mesmo dado… nenhum manda.

---

⚠️ O problema moderno: todo mundo quer sua própria verdade

Com a chegada de:

• Data Lakes

• BI Self-Service

• Microservices

• Replicações near-real-time

• APIs para tudo

Nasceu o monstro de três cabeças:

🧟 A Verdade Paralela
🧟 A Verdade de Cache
🧟 A Verdade do PowerPoint

Cada área passa a ter:

• “Meu dado”

• “Meu relatório”

• “Minha métrica”

E quando os números não batem…

👉 a culpa é do mainframe, claro 😏

---

🧩 Formatos de SSOT (sim, existem vários)

1️⃣ SSOT Transacional

• Fonte: DB2 / CICS

• Uso: sistemas core

• Alta integridade

• Baixa tolerância a erro

💡 Mainframe é rei aqui.

---

2️⃣ SSOT Analítico

• Fonte: DW / Lakehouse

• Uso: BI, KPIs

• Risco: latência e transformação

⚠️ Não confundir com verdade operacional.

---

3️⃣ SSOT de Configuração

• Fonte: repositórios únicos

• Ex: parâmetros, tabelas de domínio

🧨 Dica: tabela “copiada” em cada sistema não é SSOT.

---

4️⃣ SSOT de Governança

• Catálogos de dados

• Data lineage

• Glossário corporativo

📚 Onde a verdade é documentada, não só armazenada.

---

🛠️ Dicas práticas (da trincheira, não do slide)

✔️ Defina ownership real

“Quem acorda às 3h da manhã se der erro?”

✔️ Separe dado de consumo

• Origem ≠ réplica ≠ cache

✔️ Documente a verdade

• Se não está escrito, vira lenda urbana.

✔️ Controle quem escreve

• Ler é democrático. Escrever não.

✔️ Mainframe como âncora

• Sistemas modernos orbitam. O core não flutua.

---

💣 Riscos clássicos (a lista da vergonha)

• ❌ Duas bases “oficiais”

• ❌ ETL que “corrige” dado

• ❌ BI explicando divergência em reunião

• ❌ Regra de negócio fora do core

• ❌ “É só um relatório…”

⚠️ Relatório nunca é inocente.

---

🧪 Curiosidades & Easter Eggs

🥚 Easter Egg #1

Muitos sistemas “modernos” recriam SSOT… e descobrem 30 anos depois o que o CICS já fazia.

🥚 Easter Egg #2

RACF é um dos SSOTs mais respeitados da empresa — ninguém questiona.

🥚 Easter Egg #3

O termo SSOT ficou famoso com BI, mas nasceu no batch noturno.

---

🧠 Reflexão final (El Jefe mode ON)

SSOT não é tecnologia.
É disciplina organizacional.

Você pode ter:

• Cloud

• Kafka

• Lakehouse

• AI

• Dashboard bonito

Mas se não souber qual dado é o oficial…

👉 Você só tem várias mentiras bem organizadas.

---

☕🌙 Midnight Lunch Thought
No fim do dia (ou da madrugada):
quem controla a verdade controla o sistema.
E historicamente…
o mainframe sempre soube disso.

Visite Bellacosa Mainframe

Ajude a divulgar nossa pagina sobre IBM Mainframe, visite, compartilhe, interaja, seu click nos ajudará na Missão de Divulgar o COBOL as novas gerações de DEV.

BELLACOSA MAINFRAME

Fluxo de Compilação de um programa COBOL com DB2

Infografico demonstrando o fluxo de compilação de um programa mainframe COBOL com acesso ao Banco de Dados DB2.

Conheça a Stack Mainframe

Bem-vindo a Stack Mainframe, aprenda COBOL #ibm #mainframe #cobol #cics #db2 #sdsf #jes2 #job #jcl #rexx #qsam #vsam

Conversão do REAL um grande trabalho da informática mainframe

A resiliência e a tenacidade técnica dos Analistas de Sistemas Mainframe, que em quatro dias conseguiram virar a chave, convertendo sistemas críticos para a conversão de moeda, do URV para o REAL. 

Feriado bancário na Sexta-feira, mas Segunda-feira estava tudo no ar, funcionando, quatro dias de loucura no Departamento de Informatica, muita pizza, companheirismo, horas-extra, mas sensação de dever cumprido. 

 Programas em COBOL, PLI e Natural em Sistemas Mainframe alterados para a conversão da Moeda, sem perdas ou prejuízos aos clientes e empresas. Sendo um Caso de Estudo de Sucesso, visto de perto pelas autoridades europeias, que passado 7 anos repetiram o processo na Conversão do Euro.

#ibm #mainframe #real #urv #conversao #cobol #natural #jcl #pli #db2 #adabas #job #sistemas #dev #programador #sucesso

 

Road Map para Aprender Mainframe

O que um jovem padawan deve aprender para ser um especialista na Stack Mainframe. Um caminho com inúmeras possibilidades, requer esforço e dedicação, porém os frutos condizem ao esforço. Descubra o z/OS, codifique em COBOL, crie queries no SQL DB2 e vá além. #ibm #mainframe #cobol #cics #db2 #jcl #sdsf #qsam #vsam #query #sql #etl #jobs #procs #jes2 #lpar #sysplex

 

Bellacosa Mainframe e o  Relation Problem 

🧩 O “Relational Problem”: quando o modelo relacional começa a ranger os dentes

Teve uma época — lá pelos anos 70 e 80 — em que o modelo relacional era praticamente um presente divino.
Ted Codd apareceu com tabelas, chaves, normalização e alguém pensou:

“Pronto, agora dá pra organizar o mundo inteiro em linhas e colunas.”

E funcionou. Funcionou bem demais.
Funcionou tanto que virou padrão em bancos, governos, ERPs, mainframes, folha de pagamento, compensação bancária, impostos, seguros… o pacote completo.

Só que aí veio o mundo moderno.
E ele veio sem pedir licença.

---

📈 A explosão de dados (ou: quando o DB começou a suar frio)

Web, mobile, redes sociais, IoT, logs, sensores, streaming, analytics em tempo real…
De repente, o banco relacional passou a ouvir frases como:

• “Preciso escalar horizontalmente.”

• “Tem que responder em milissegundos.”

• “O schema muda toda semana.”

• “Esse JSON aqui é meio… flexível.”

Nesse momento nasce o que chamamos de Relational Problem:
👉 a dificuldade crescente de gerenciar, escalar e consultar dados usando RDBMS tradicionais em ambientes cada vez maiores, mais variados e mais exigentes.

O vilão clássico?

• Schemas rígidos

• Joins caros

• Crescimento exponencial de volume

• Performance sofrendo conforme a complexidade aumenta

📌 Easter egg: se você já viu um EXPLAIN com 12 joins e custo astronômico, você já sentiu o Relational Problem na pele.

---

🏗️ Solução 1: Escalar pra cima (o famoso “compra mais ferro”)

A primeira reação clássica é:

“Coloca mais CPU, mais memória e mais disco.”

No mundo mainframe isso tem nome, sobrenome e fatura alta 💸.

✔️ Funciona? Funciona.
❌ Resolve pra sempre? Não.

• É caro

• Tem limite físico

• E uma hora… acaba

👉 Vertical scaling resolve dor imediata, não o problema estrutural.

---

🔧 Solução 2: Otimizar até a última gota

Aí entra o arsenal conhecido:

• Índices

• Partitioning

• Denormalização

• Tuning de SQL

• Estatísticas afinadas na lua certa 🌕

Isso melhora muito, mas cobra seu preço:

• Mais complexidade

• Mais overhead operacional

• Mais chances de alguém quebrar tudo num ALTER inocente

📌 Fofoquinha: todo ambiente tem aquele índice criado “em produção às pressas” que ninguém sabe se pode remover.

---

🌐 Solução 3: Relacional distribuído (o meio do caminho)

Aqui a ideia é ousada:

“Vamos manter o modelo relacional, mas espalhar os dados.”

Resultado:

• Mais escalabilidade

• Mais disponibilidade

• E… mais complexidade de consistência e transação

💡 ACID distribuído não é trivial.
Quem já estudou two-phase commit sabe que não existe almoço grátis.

---

🚀 Solução 4: NoSQL — o rebelde sem gravata

Aí surgem os NoSQL:

• Key-value

• Documento

• Colunar

• Grafos

Eles dizem:

“Relaxa o schema, relaxa o relacionamento, escala horizontalmente e seja feliz.”

✔️ Alta performance
✔️ Flexibilidade
✔️ Escala global

❌ Menos garantias transacionais
❌ Consistência eventualmente… eventual 😅

📌 Easter egg: NoSQL não significa “No SQL”, mas muita gente usa como “No JOIN, graças a Deus”.

---

🔀 Solução 5: Abordagem híbrida (o mundo real)

Na prática, o que venceu foi o híbrido:

• Relacional para transação crítica

• NoSQL ou Data Warehouse para analytics e volume massivo

• Cada banco no seu quadrado

👉 O banco certo para o problema certo.

💬 Comentário Bellacosa:
Mainframe + DB2 continua reinando onde consistência, auditoria e confiabilidade não são opcionais.

---

⚖️ Os grandes trade-offs (onde mora a dor)

Resolver o Relational Problem é basicamente escolher qual dor você aceita.

🔐 Consistência vs Disponibilidade & Escala

• Relacional ama ACID

• Distribuído ama performance

• CAP theorem fica no meio rindo da sua cara

🧱 Rigidez de schema vs Flexibilidade

• Schema fixo protege a integridade

• Schema flexível acelera mudança

• Um trava, o outro corre… e tropeça às vezes

⚙️ Performance vs Complexidade

• Tuning melhora performance

• Mas aumenta custo, risco e dependência de especialistas

💰 Custo vs Controle

• Hardware e licenças caros

• Cloud e distribuído mais baratos (até não serem)

---

🏦 Quem escolhe o quê?

• Bancos, governos, seguradoras
  👉 Consistência, governança, auditoria
  👉 Relacional forte, bem cuidado, bem documentado

• Empresas web-scale, data-driven
  👉 Escala, agilidade, crescimento rápido
  👉 Distribuído, NoSQL, híbrido

📌 Não é sobre tecnologia “melhor”.
É sobre prioridade de negócio.

---

☕ Conclusão estilo café no mainframe

O Relational Problem não significa que o modelo relacional falhou.
Significa que ele foi bom demais por tempo demais em um mundo que mudou radicalmente.

A maturidade está em entender:

• Onde ele brilha

• Onde ele sofre

• E como combiná-lo com outras abordagens

💬 Última fofoquinha:
Quem decreta a “morte do relacional” geralmente nunca precisou fechar um balanço financeiro auditado.

Uma visão geral sobre o trabalhador de Mainframe

Equipe de desenvolvimento mainframe

Descubra a Stack MAINFRAME e veja o que necessita para ser um Desenvolvedor COBOL de Sucesso. Aprenda COBOL, há 65 anos revolucionando o mercado de informática.

Conheças algumas vantagens de desenvolver em COBOL Mainframe

Stack Mainframe

Descubra a Stack MAINFRAME Aprenda COBOL, há 65 anos revolucionando o mercado de informática.

O COBOL em sua primeira reunião

Codasyl em 1959 o pontapé inicial do COBOL

Em 08 de Abril de 1959, foi dado o pontapé inicial da criação do COBOL. Muita coisa aconteceu desde então, surgiu o armazenamento em cartão perfurado, tape, disco e cartridge, surgiram o qsam, vsam, db2. Acompanhe-nos e descubra mais

 

Bellacosa Mainframe apresente o IBM DB2 schemas tables columns and rows

☕ IBM Mainframe & DB2: a engenharia relacional que sustenta o mundo

---

🧠 Introdução – DB2 no Mainframe não é “apenas um banco”

Quando alguém diz “DB2 é um banco de dados relacional”, está tecnicamente correto…
e conceitualmente incompleto.

No IBM Mainframe, o DB2 não é um software isolado.
Ele é parte da espinha dorsal do z/OS, responsável por processar trilhões de dólares, milhões de transações por segundo e manter sistemas que não podem falhar — nunca.

Enquanto no mundo distribuído o banco “reinicia”,
no mainframe o DB2 continua.

---

🕰️ Origem & História – da teoria acadêmica ao Big Iron

Tudo começa em 1970, quando Edgar F. Codd, pesquisador da IBM, publica o artigo que mudaria a computação:

“A Relational Model of Data for Large Shared Data Banks”

Ali nascia o modelo relacional.

💡 Curiosidade Bellacosa
O modelo relacional nasceu antes do DB2.
O DB2 foi a industrialização dessa teoria no ambiente mais exigente do planeta: o mainframe.

• 1983 → DB2 v1 no MVS

• SQL ainda era novidade

• Muitos achavam que banco relacional era “moda acadêmica”

Quatro décadas depois…
👉 o dinheiro do mundo discorda.

---

⚙️ DB2 no Mainframe: como ele realmente funciona

No z/OS, o DB2 é um subsistema profundamente integrado, explorando:

• Endereçamento de memória avançado

• Controle sofisticado de concorrência

• Logging e recovery em nível cirúrgico

• Data Sharing entre múltiplos LPARs

Ele não vive sozinho:

• Integra-se ao WLM

• Usa RACF para segurança

• Depende de DFS/SMS para storage

• Trabalha com IRLM para locking

☕ Comentário El Jefe
DB2 no mainframe não é “um processo rodando”.
É um cidadão de primeira classe do sistema operacional.

---

🧩 Os 4 componentes fundamentais de um banco relacional

(e como o DB2 os executa em escala real)

1️⃣ Tables – onde o dado mora

A tabela é a principal estrutura lógica do modelo relacional.

No DB2:

• Criada com CREATE TABLE

• Armazenada fisicamente em Tablespaces

• Representa entidades reais do negócio:

  • CLIENTE

  • CONTA

  • TRANSACAO

🪺 Easter Egg
Você nunca acessa o dataset da tabela diretamente.
DB2 abstrai tudo — quem tenta “dar jeitinho” apanha 😈

---

2️⃣ Columns – o contrato do dado

As colunas definem:

• Tipo

• Tamanho

• Regra de nulidade

CPF         CHAR(11) NOT NULL
SALDO       DECIMAL(15,2)
DT_ABERTURA DATE

💡 Dica Bellacosa
No DB2 z/OS, erro de modelagem vira dívida técnica de décadas.
Mainframe não perdoa definição mal pensada.

---

3️⃣ Rows – onde a vida acontece

Cada row é um fato real do negócio:

• Um cliente

• Uma conta

• Uma transação às 14:32:10

No DB2:

• Linhas são protegidas por locking avançado

• Trabalham com commit, rollback e isolamento

• Suportam milhares de acessos simultâneos

☕ Comentário El Jefe
DB2 nasceu para concorrência massiva antes disso virar problema no mercado.

---

4️⃣ Keys & Relationships – a alma do modelo relacional

Aqui mora a inteligência:

• Primary Key → identidade

• Foreign Key → relacionamento

• Indexes → performance

• Constraints → integridade

🧠 Curiosidade histórica
Antes do DB2, muitos sistemas usavam arquivos hierárquicos (IMS).
O modelo relacional trouxe algo revolucionário:
👉 relacionar dados sem duplicar estrutura física.

---

DB2 Schema

🧱 O 5º elemento invisível (e essencial): SCHEMA

Se tabela é a casa…
Schema é o bairro inteiro.

📌 O que é Schema no DB2?

Schema é um namespace lógico que organiza objetos:

• Tables

• Views

• Indexes

• Procedures

• Functions

ELJEFE.CLIENTE
ELJEFE.CONTA
ELJEFE.TRANSACAO

Sem schema, o DB2 seria como:

• Dataset sem HLQ

• PDS sem padrão

• Ambiente pronto para desastre

---

⚙️ Funcionamento prático

• Todo objeto pertence a um schema

• Se não informado:

  • DB2 usa o CURRENT SQLID

SET CURRENT SQLID = 'ELJEFE';
SELECT * FROM CLIENTE;

Na prática:

SELECT * FROM ELJEFE.CLIENTE;

☕ Comentário Bellacosa
Isso é HLQ de dataset aplicado ao mundo relacional.

---

🔐 Schema e Segurança

Schema também é governança:

• Permissões por schema

• Integração com RACF

• Separação clara entre sistemas e times

🛡️ Dica El Jefe
Grande parte dos erros em produção não é SQL errado —
é schema errado.

---

🧠 Visão Jedi – tudo conectado

Agora o modelo completo:

SCHEMA
 └── TABLE
      ├── COLUMNS
      ├── ROWS
      └── KEYS / CONSTRAINTS

• Schema organiza

• Tabela estrutura

• Coluna define

• Linha materializa

• Chave relaciona

Tudo isso sustentado por DB2 + z/OS + RACF.

---

🧪 Dicas práticas Bellacosa Mainframe

✔ Pense em volume e longevidade, não só no hoje
✔ Performance começa no CREATE TABLE
✔ DB2 é arquitetura, não só SQL
✔ Schema bem definido evita desastre silencioso
✔ Mainframe foi feito para não cair

---

🥚 Easter Eggs & Curiosidades finais

• DB2 sobrevive a falhas que derrubariam qualquer stack moderna

• Muitos padrões SQL nasceram no DB2

• O otimizador do DB2 z/OS é referência mundial

• COBOL + DB2 ainda move a maior parte do dinheiro do planeta

---

☕ Conclusão – DB2 é filosofia

Entender os componentes do modelo relacional é fácil.
Entender como o DB2 os executa em escala planetária é outra história.

No El Jefe, a regra é clara:

Quem domina DB2 no Big Iron, domina sistemas críticos de verdade.

Nos vemos no próximo café ☕
— Bellacosa Mainframe

 

Bellacosa Mainframe apresenta o DCLGEN

🔥 DB2 DCLGEN para COBOL – Onde a Tabela Vira Código e o Código Vira Contrato 🔥

---

Se existe um ponto em que DB2, COBOL e disciplina se encontram, esse ponto se chama DCLGEN.

Quem já manteve sistema legado sabe:
👉 layout duplicado dá problema
👉 tipo mal definido vira bug
👉 desalinhamento vira incidente às 3h da manhã

O DCLGEN não é só uma ferramenta.
Ele é um pacto de não-agressão entre o banco e o programa.

---

🕰️ Um Pouco de História – Por Que o DCLGEN Existe?

Antes do DCLGEN, o programador:

• Lia a DDL

• “Interpretava” os tipos

• Criava o layout na mão

• Rezava

💡 Resultado:

• Campos truncados

• Decimais errados

• -302 misterioso

A IBM, num raro momento de empatia com o ser humano, criou o DCLGEN (Declarations Generator):
👉 a definição oficial da tabela vira estrutura COBOL.

Menos interpretação.
Mais verdade.

---

🧬 O Que o DCLGEN Gera, de Fato?

Um DCLGEN padrão gera:

1. EXEC SQL DECLARE TABLE

2. Estrutura COBOL (01 / 05)

3. EXEC SQL DECLARE CURSOR (opcional)

Tudo alinhado com:

• Tipo

• Tamanho

• Precisão

• Nulidade

💡 Regra de ouro Bellacosa:
Se não veio do DCLGEN, desconfie.

---

🧱 Tipos DB2 vs Tipos COBOL – Onde a Magia Acontece

Aqui mora a maioria dos bugs silenciosos.

🔢 NUMERIC / DECIMAL

DB2

DECIMAL(9,2)

COBOL (DCLGEN)

05 COL-VALOR       PIC S9(7)V99 COMP-3.

💡 Por quê COMP-3?
Porque DB2 armazena decimal compactado.
DISPLAY aqui é convite ao desastre.

---

🔠 CHAR / VARCHAR

DB2

CHAR(10)
VARCHAR(50)

COBOL

05 COL-NOME        PIC X(10).
05 COL-DESC-LEN    PIC S9(4) COMP.
05 COL-DESC-TEXT   PIC X(50).

💡 Curiosidade:
VARCHAR vira dois campos em COBOL.
Esqueceu do LENGTH? Vai ler lixo.

🥚 Easter egg clássico:
LENGTH negativo = dado inválido ou bug sorrateiro.

---

📅 DATE / TIME / TIMESTAMP

DB2

DATE
TIMESTAMP

COBOL

05 COL-DATA        PIC X(10).
05 COL-TS          PIC X(26).

💡 Comentário Bellacosa:
Não trate data DB2 como número.
Isso termina em lágrimas.

---

🔣 INTEGER / SMALLINT / BIGINT

DB2

INTEGER
SMALLINT
BIGINT

COBOL

05 COL-ID          PIC S9(9) COMP.
05 COL-COD         PIC S9(4) COMP.
05 COL-SEQ         PIC S9(18) COMP.

💡 Dica de sobrevivência:
Nunca use DISPLAY para inteiros DB2.
Nunca.

---

🚨 NULLs – O Inimigo Invisível

DB2 aceita NULL.
COBOL… não.

DCLGEN resolve isso com indicadores:

05 COL-VALOR       PIC S9(7)V99 COMP-3.
05 COL-VALOR-IND   PIC S9(4) COMP.

• 0 → valor válido

• -1 → NULL

💡 Dica Bellacosa:
Esqueceu de tratar indicador?
Parabéns, você acaba de criar um dump futuro.

---

🧪 Conversões Implícitas – Onde o DB2 Avisa (ou não)

DB2 até converte tipos…
Mas cobra juros.

• CHAR → DECIMAL

• DATE → CHAR

• VARCHAR → FIXED

💡 Conhecimento de bastidor:
Conversão implícita custa CPU e pode quebrar índice.

👉 Converta no COBOL, não no SQL.

---

⚙️ DCLGEN no Mundo Moderno (Git, CI/CD, DevOps)

Hoje o DCLGEN:

• É versionado no Git

• Gerado automaticamente

• Sincronizado com DDL

• Integrado ao pipeline

💡 Regra de ouro moderna:
DDL mudou?
👉 gere novo DCLGEN
👉 recompile
👉 rebind

Sem atalhos.

---

🗣️ Fofoquices de Sala-Cofre

• “Funcionava ontem” → tabela mudou

• “Só aumentaram o tamanho” → DCLGEN não regenerado

• “É só um campo novo” → layout desalinhado

---

🧠 Pensamento Final do El Jefe

DCLGEN não é burocracia.
É contrato.

Ele garante que:

• O que o DB2 grava

• É exatamente o que o COBOL lê

Sem achismo.
Sem “interpretação criativa”.

🔥 Regra final Bellacosa Mainframe:
Se a tabela é verdade,
o DCLGEN é a tradução oficial.

Todo o resto…
é boato que vira incidente. 💾🧠

 

Bellacosa Mainframe apresenta o Db2 e seus pools

🔥 DB2 Buffer Pool e a Família de Pools – Onde o DB2 Guarda o Cérebro (e a Paciência) 🔥

 

---

Se o DB2 fosse um organismo vivo, o buffer pool seria o cérebro de curto prazo.
Não é onde o dado nasce.
Não é onde o dado mora definitivamente.
Mas é onde tudo passa antes de fazer sentido.

Quem entende buffer pool:

• entende performance

• entende CPU

• entende por que “não mexemos nisso em produção”

E quem não entende…
culpa o SQL.

---

🕰️ Um Pouco de História – Quando Disco Era Lento de Verdade

No DB2 antigo (e não tão antigo assim):

• disco era caro

• I/O era lento

• memória era luxo

A IBM fez o óbvio (e genial):
👉 ler do disco uma vez e reutilizar o máximo possível.

Assim nasceu o buffer pool:

• páginas lidas do tablespace

• mantidas em memória

• reutilizadas enquanto fizer sentido

💡 Resultado:
Menos I/O.
Mais performance.
Menos gritos no plantão.

---

🧠 O Que é um Buffer Pool, na Prática?

Buffer pool é uma área de memória onde o DB2 mantém:

• páginas de dados

• páginas de índice

Antes de ir ao disco, o DB2 pergunta:

“Isso já está no buffer?”

Se estiver:
🚀 rápido
Se não estiver:
🐢 I/O físico

💡 Regra Bellacosa:
DB2 rápido = buffer pool feliz.

---

📦 Tipos de Buffer Pool no DB2

🔹 BP0 – O Histórico

O buffer pool default, o “pai de todos”.

💡 Fofoquinha:
Ambiente que só tem BP0 geralmente tem performance “misteriosa”.

---

🔹 Buffer Pools Customizados (BP1, BP2, …)

Criados para separar:

• dados críticos

• índices quentes

• tabelas gigantes

• tabelas raramente acessadas

💡 Boa prática:
Índice quente em buffer pool separado = ganho imediato.

---

🔹 Buffer Pools Especiais

• BP32K → tabelas com page size 32K

• BP8K / BP16K → workloads específicos

🥚 Easter egg:
Criar BP32K sem necessidade é desperdício elegante de memória.

---

📊 Page Size – O Detalhe que Muda Tudo

Page size define:

• quanto dado cabe por página

• quantas linhas por I/O

Page Size	Quando usar
4K	OLTP clássico
8K	Índices largos
16K	LOB leve
32K	LOB pesado

💡 Dica Bellacosa:
Page grande = menos I/O
Mas também = menos páginas no buffer pool.

---

🔄 Outros Pools Importantes no DB2 (Além do Buffer Pool)

🧾 EDM Pool (Environmental Descriptor Manager)

Guarda:

• SQL dinâmico

• Planos preparados

• Descrições de objetos

💡 EDM pequeno = SQL recompilando toda hora.

---

🧠 Sort Pool

Usado para:

• ORDER BY

• GROUP BY

• DISTINCT

💡 Comentário:
Sort indo para disco = SQL chorando.

---

🧵 RID Pool

Controla:

• listas de RIDs para acesso indireto

💡 RID pool insuficiente = access path ruim sem aviso claro.

---

📥 Log Buffer

Onde o DB2 guarda logs antes de gravar no disco.

💡 Dica de guerra:
Log buffer pequeno = commit lento = aplicação reclamando.

---

🧰 Utility Pool

Usado por:

• LOAD

• REORG

• RUNSTATS

💡 Ambiente sem utility pool dedicado sofre em batch pesado.

---

🔥 Buffer Pool e Performance – Onde os Adultos Conversam

Indicadores clássicos:

• Hit ratio alto

• Read I/O baixo

• Write eficiente

💡 Fofoquinha séria:
Hit ratio alto não garante bom desempenho.
Às vezes o dado certo está fora do pool certo.

---

🧪 Buffer Pool vs Lock – O Drama Oculto

Buffer pool cheio:

• mantém páginas sujas

• segura lock mais tempo

• aumenta contenção

💡 Dica Bellacosa:
Performance não é só memória.
É equilíbrio.

---

⚠️ Erros Clássicos que Todo Mundo Já Viu

• Tudo no BP0

• Índice crítico no mesmo pool que tabela fria

• BP gigante sem uso real

• BP pequeno para workload OLTP pesado

🥚 Easter egg de produção:
“Mudamos só o buffer pool” já causou tanto incidente quanto ALTER TABLE.

---

🧠 Buffer Pool no Mundo Moderno (DevOps & Observabilidade)

Hoje monitoramos:

• hit ratio por pool

• read/write por objeto

• aging de páginas

• comportamento por workload

💡 Regra moderna:
Tune sem métrica é chute elegante.

---

🗣️ Fofoquices de Sala-Cofre

• “DB2 está lento hoje” → buffer pool cheio

• “Nunca mexemos nisso” → por isso mesmo

• “É só aumentar memória” → nem sempre

---

🧠 Pensamento Final do El Jefe

Buffer pool não é detalhe técnico.
É arquitetura viva.

Quem entende pool:

• evita I/O

• reduz CPU

• ganha previsibilidade

Quem ignora:

• otimiza SQL errado

• culpa o hardware

• trabalha de madrugada

🔥 Regra final Bellacosa Mainframe:
No DB2,
o dado pode morar no disco…
mas a performance mora na memória. 💾🧠

 

Bind DB2 Package Plan COBOL ao estilo Bellacosa Mainframe

🔥 BIND DB2 em COBOL – O Ritual Sagrado Entre o Código e o Plano de Execução 🔥

 

---

Se o compile COBOL é o nascimento do programa, o BIND DB2 é o batismo de fogo.
Sem ele, seu programa até existe… mas não fala com o banco.

Quem nunca ouviu no plantão noturno:

“Compilou, linkou… mas esqueceu o BIND.”

Silêncio. Café. Olhar para o SYSOUT. ☕😐

Este artigo é para desmistificar o BIND, separar lenda de verdade e registrar aquele conhecimento que normalmente só se aprende depois do primeiro -805 em produção.

---

🕰️ Um Pouco de História – Por Que o BIND Existe?

Nos primórdios do DB2 (lá no fim dos anos 70), a IBM fez uma escolha genial e cruel ao mesmo tempo:

👉 Separar lógica do programa de estratégia de acesso aos dados.

Assim nasceu o BIND:

• O COBOL descreve o que quer

• O DB2 decide como fazer

💡 Resultado:
O mesmo programa pode ter planos diferentes em ambientes diferentes.
Flexibilidade máxima… e dor de cabeça proporcional.

---

🧩 O Que é o BIND DB2, de Verdade?

BIND é o processo onde o DB2:

• Analisa o SQL estático

• Escolhe access paths

• Cria PACKAGE (ou PLAN)

• Valida permissões

• Gera dependências

Sem BIND:

• Não existe plano

• Não existe package

• Não existe execução

💡 Frase clássica de mainframer:

“O erro não está no código. Está no BIND.”

---

📦 PACKAGE vs PLAN – A Confusão Eterna

PACKAGE

• Gerado a partir do DBRM

• Contém SQL otimizado

• Versionável

• Reutilizável

PLAN

• Aponta para um ou mais packages

• Controla isolamento, owner, bind time

💡 Dica Bellacosa:
Em ambientes modernos, package é rei. PLAN virou maestro — não solista.

🥚 Easter egg histórico:
Antigamente se dava BIND direto em PLAN. Hoje isso é quase arqueologia DB2.

---

🔗 O Caminho Sagrado: Compile → DBRM → BIND

Fluxo real da vida:

1. Compile COBOL com SQL

2. Gera DBRM

3. BIND PACKAGE

4. Link-edit

5. Run

Se alguém inverter isso…
📛 cheiro de incidente.

💡 Dica prática:
Sempre valide se o DBRM que você está bindando é do mesmo compile. Erro clássico de esteira mal montada.

---

⚠️ Erros Clássicos que Todo Mundo Já Viu

🔥 -805 (DBRM ou PACKAGE não encontrado)

Tradução livre:

“Você esqueceu o BIND ou apontou para o lugar errado.”

🔥 -818 (Timestamp mismatch)

Tradução:

“Você recompilou, mas não rebindeou.”

🔥 -204 / -551

Permissão, owner ou qualifier errado.

💡 Dica de sobrevivência:
Antes de xingar o DB2, olhe:

• COLLECTION

• OWNER

• QUALIFIER

• VERSION

---

🧠 Parâmetros de BIND que Salvam Carreiras

Alguns parâmetros não são opcionais — são estratégia de vida:

• ISOLATION(CS|RR|UR)

• RELEASE(COMMIT|DEALLOCATE)

• VALIDATE(BIND|RUN)

• EXPLAIN(YES)

• REOPT(ALWAYS|ONCE|NONE)

💡 Dica Bellacosa:
Não copie BIND de outro sistema sem entender.
Cada parâmetro muda performance, locking e risco.

---

🧪 BIND e Performance – Onde o Jogo Começa

O SQL pode estar perfeito…
Mas um BIND mal feito:

• Gera table scan

• Estoura buffer pool

• Cria lock em horário nobre

💡 Conhecimento de bastidor:
90% dos “problemas de SQL” são problemas de BIND mal ajustado.

🥚 Easter egg de guerra:
Já vi sistema “otimizado” só mudando ISOLATION e refazendo o BIND. Código intocado.

---

🤝 BIND, DevOps e Git – O Mundo Novo

No mundo moderno:

• Código está no Git

• DBRM nasce no pipeline

• BIND é automatizado

💡 Regra de ouro:
Se o pipeline não controla BIND, você não controla produção.

Automatize:

• Collection por ambiente

• Versionamento de package

• Rollback de BIND

---

🗣️ Fofoquices de Sala-Cofre

• “Rodou em QA, mas não em PROD” → COLLECTION errada

• “Código antigo, erro novo” → REBIND automático noturno

• “Não mexemos no SQL” → alguém mexeu no BIND

---

🧠 Pensamento Final do El Jefe

O BIND DB2 não é um detalhe técnico.
Ele é o contrato invisível entre seu COBOL e o banco.

Quem domina BIND:

• Evita incidentes

• Ganha performance

• Dorme melhor

Quem ignora:

• Vive de -805

• Culpa o DB2

• Trabalha de madrugada

🔥 Pergunta final para o leitor:
Você trata o BIND como rotina… ou como arquitetura?

Porque no mainframe,
o código passa — o plano fica. 🧠💾

 

SQLCODE quando o programa Cobol deve tratar o retorno do db2

🔥 SQLCODE no DB2 – Lendo os Sinais da Força (Guia para Padawans Mainframe) 🔥

 

---

Todo padawan que começa no DB2 passa pelo mesmo rito de iniciação:
o programa compila, o BIND passa…
e na execução surge aquela linha silenciosa e cruel:

SQLCODE = -911

Fim.
Tela verde.
Respiração suspensa.

Mas calma. SQLCODE não é inimigo.
Ele é o oráculo do DB2 — fala pouco, mas fala a verdade.

---

🧠 O Que é SQLCODE, de Verdade?

SQLCODE é a forma que o DB2 tem de dizer:

👉 “Eu tentei.”
👉 “Funcionou.”
👉 “Funcionou mais ou menos.”
👉 “Deu ruim.”

Cada comando SQL retorna um SQLCODE.
Sempre.
Sem exceção.

💡 Regra de ouro Bellacosa:
Nunca ignore SQLCODE.
Quem ignora SQLCODE, debuga em produção.

---

⚖️ Zero, Positivo ou Negativo – A Trindade Sagrada

🟢 SQLCODE = 0 → Tudo Certo

O DB2 está feliz.
Você também deveria estar.

• SELECT encontrou linha

• INSERT gravou

• UPDATE atualizou

• DELETE removeu

💡 Comentário:
Zero não é “talvez”.
Zero é sucesso absoluto.

---

🟡 SQLCODE > 0 → Aviso (Warning)

Aqui mora a confusão dos iniciantes.

Positivo não é erro.
É o DB2 dizendo:

“Funcionou… mas presta atenção.”

Exemplos clássicos:

• +100 → nenhuma linha encontrada

• +802 → divisão por zero evitada

• +466 → truncate de dado

💡 Dica Padawan:
+100 em SELECT não é falha.
É lógica de negócio.

🥚 Easter egg:
Muitos sistemas tratam +100 como erro… e criam bugs por conta própria.

---

🔴 SQLCODE < 0 → Erro

Aqui o DB2 cruzou os braços.

Nada foi feito.
Ou pior: foi feito parcialmente.

Negativo significa:

• SQL inválido

• Dados inconsistentes

• Lock

• Timeout

• Permissão

• Conversão errada

💡 Regra Jedi:
SQLCODE negativo exige ação imediata.
Ignorar é lado sombrio.

---

🧨 SQLCODEs que Todo Padawan Precisa Conhecer

🔥 -100 → Nenhuma linha encontrada (antigo)

Hoje quase arqueologia.
Substituído por +100.

---

🔥 +100 → Nenhuma linha encontrada

Clássico do SELECT:

SELECT ... INTO ...

Sem registro.

💡 Dica:
Teste +100 como fluxo normal.
Não como exceção.

---

🔥 -305 → NULL sem indicador

DB2 tentou colocar NULL em campo COBOL “cheio de orgulho”.

💡 Lição:
Campo nullable exige indicador.

---

🔥 -302 → Conversão ou tamanho inválido

Número grande demais, decimal errado, CHAR mal definido.

💡 Fofoquinha:
90% dos -302 vêm de DCLGEN desatualizado.

---

🔥 -803 → Violação de chave única

Tentou inserir algo que já existe.

💡 Boa prática:
-803 não é erro técnico.
É regra de negócio.

---

🔥 -805 → DBRM / PACKAGE não encontrado

O terror noturno.

💡 Tradução Bellacosa:
“Esqueceu o BIND.”

---

🔥 -818 → Timestamp mismatch

Recompilou, mas não rebindeou.

💡 Comentário:
Esse erro ensina disciplina melhor que qualquer curso.

---

🔥 -911 / -913 → Deadlock ou Timeout

DB2 desistiu da briga.

💡 Dica Jedi:
Trate retry no código.
Não xingue o DB2 — ele só sobreviveu.

---

🧪 SQLERRD(3) – O Número que Poucos Olham

Dentro do SQLCA existe um tesouro esquecido:

👉 SQLERRD(3) = número de linhas afetadas

• UPDATE

• DELETE

• INSERT

💡 Easter egg profissional:
Às vezes SQLCODE = 0…
mas SQLERRD(3) = 0.

Executou, mas não mudou nada.

---

⚙️ Tratamento de SQLCODE no COBOL – Boas Práticas

Nunca faça:

IF SQLCODE NOT = 0
   DISPLAY 'ERRO'
END-IF

Faça:

• Trate 0

• Trate +100

• Trate negativos relevantes

💡 Dica Bellacosa:
SQLCODE é parte da lógica, não exceção.

---

🗣️ Fofoquices de Sala-Cofre

• “Mas em QA funciona” → dado diferente

• “Nunca deu isso antes” → agora deu

• “É erro intermitente” → lock

---

🧠 Pensamento Final do El Jefe

SQLCODE é o idioma do DB2.
Quem não fala esse idioma:

• culpa o banco

• cria workaround perigoso

• aprende do jeito difícil

🔥 Para o Padawan:
Leia o SQLCODE.
Entenda o contexto.
Respeite os avisos.

Porque no DB2,
o erro não grita — ele retorna um número. 🧠💾

 

Aprenda COBOL com DB2 ao estilo Bellacosa Mainframe

🔥 Aprender COBOL com DB2 — o caminho do programador mainframer de verdade

---

🧠 Introdução: por que COBOL + DB2 ainda manda no jogo

Se você quer ser programador mainframe COBOL com DB2, precisa entender uma verdade simples:

COBOL processa.
DB2 guarda.
SQL conecta o cérebro à memória do negócio.

Não estamos falando de tecnologia “antiga”.
Estamos falando da infraestrutura que processa bilhões por dia, com ACID, consistência e auditoria que muita stack moderna ainda tenta copiar.

Esse artigo é um mapa de estrada, do zero até o código profissional, misturando:

• técnica

• história

• prática

• fofoca de data center

• e aquela sabedoria que só mainframer velho passa no café ☕

---

DB2 o banco de dados do Mainframe

🧱 PARTE 1 — Conhecendo o DB2 (o coração dos dados)

📜 Um pouco de história

O DB2 nasce na IBM nos anos 80, baseado no modelo relacional proposto por Edgar F. Codd.

👉 Conceito revolucionário:

• dados em tabelas

• relações lógicas

• SQL como linguagem declarativa

Enquanto o mundo brigava com arquivos VSAM:

“Me diga o que você quer, não como buscar.”

---

🧩 Modelo Relacional (base de tudo)

• Tabela → entidade de negócio

• Linha (row) → registro

• Coluna (column) → atributo

• Primary Key → identidade

• Foreign Key → relacionamento

💬 Bellacosa comenta:

“Se você não entende modelo relacional, não adianta saber COBOL.”

---

🧾 Tipos de Dados DB2 (o casamento com COBOL)

DB2	COBOL
CHAR / VARCHAR	PIC X
INTEGER	PIC S9
DECIMAL	PIC S9V
DATE	PIC X(10)
TIMESTAMP	PIC X(26)

🥚 Easter egg:
DB2 guarda DECIMAL melhor do que muito banco moderno guarda FLOAT 😏

---

Queries SQL no DB2 

🧑‍💻 PARTE 2 — Linguagem SQL no DB2

🗣️ SQL: a língua franca dos dados

SQL não é procedural.
SQL é declarativa.

🔹 DDL — Data Definition Language

CREATE TABLE CLIENTE (
  ID_CLIENTE INTEGER NOT NULL,
  NOME       VARCHAR(50),
  SALDO      DECIMAL(9,2),
  PRIMARY KEY (ID_CLIENTE)
);

• CREATE

• DROP

• ALTER

---

🔹 DCL — Data Control Language

GRANT SELECT ON CLIENTE TO USER01;

Controle de acesso.
Segurança raiz de banco.

---

🔹 DML — Data Manipulation Language

INSERT INTO CLIENTE VALUES (1, 'JOÃO', 1500.00);

SELECT * FROM CLIENTE;

UPDATE CLIENTE
SET SALDO = SALDO + 100
WHERE ID_CLIENTE = 1;

DELETE FROM CLIENTE
WHERE ID_CLIENTE = 1;

💬 Bellacosa:

“DELETE sem WHERE é como RM -RF /”

---

🔍 SELECT, JOIN e afins (onde o bicho pega)

SELECT C.NOME, P.VALOR
FROM CLIENTE C
JOIN PEDIDO P
  ON C.ID_CLIENTE = P.ID_CLIENTE;

👉 JOIN mal feito = batch lento = gente te ligando às 3 da manhã.

---

🛠️ SPUFI e QMF

• SPUFI → SQL direto no TSO

• QMF → consultas, relatórios, análise

💡 Dica Bellacosa:

“Todo mundo começa no SPUFI.
Quem fica bom, aprende QMF.”

---

🧩 PARTE 3 — COBOL com DB2 (onde nasce o profissional)

🏛️ História rápida do COBOL

• Criado em 1959

• Foco: negócio

• Legibilidade

• Estabilidade

👉 Não é bonito.
👉 É confiável.

---

🧠 Estrutura de um programa COBOL

• IDENTIFICATION DIVISION

• ENVIRONMENT DIVISION

• DATA DIVISION

• PROCEDURE DIVISION

📌 Árvore programática é fundamental para não virar macarrão lógico.

---

🔗 Host Variables (a ponte COBOL ↔ DB2)

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

• Sempre com :

• Tipagem correta

• Conversão consciente

---

📊 SQLCA — seu melhor amigo

IF SQLCODE = 0
   CONTINUE
ELSE
   DISPLAY 'ERRO DB2 ' SQLCODE
END-IF

SQLCODE	Significado
0	OK
+100	NOT FOUND
< 0	ERRO

💬 Bellacosa:

“Quem ignora SQLCODE vira operador sem saber.”

---

📚 DCLGEN — o BOOK sagrado

• Gera layout da tabela

• Gera host variables

• Evita erro humano

//STEP01 EXEC PGM=DSNTEP2

👉 Nunca escreva layout DB2 na mão. Nunca.

---

Consulta pagina via cursor no DB2

🌀 PARTE 4 — Cursores (nível profissional)

🔄 Cursor para leitura

EXEC SQL
   DECLARE C1 CURSOR FOR
   SELECT ID_CLIENTE, NOME
     FROM CLIENTE
END-EXEC.

EXEC SQL
   FETCH C1 INTO :WS-ID, :WS-NOME
END-EXEC.

📌 Sempre:

• OPEN

• FETCH

• CLOSE

---

✍️ Inserindo, alterando e excluindo via COBOL

• INSERT → novo registro

• UPDATE → alteração controlada

• DELETE → cuidado máximo

💡 Boa prática:

“Nunca DELETE direto sem histórico.”

---

🧠 PARTE 5 — Boas práticas Bellacosa Mainframe

✔ Use DCLGEN
✔ Sempre trate SQLCODE
✔ Evite SELECT *
✔ Documente regra de negócio
✔ Separe lógica de acesso a dados
✔ Teste com volume real
✔ Pense em performance desde o SELECT

🥚 Easter egg clássico:

“O batch estava lento porque alguém esqueceu o índice.”

---

🧪 Exercícios de fixação (mentalidade correta)

1. Criar tabela DB2

2. Gerar DCLGEN

3. Programa COBOL com:

   • INSERT

   • SELECT

   • UPDATE

   • DELETE

4. Programa com CURSOR

5. Programa com JOIN

6. Analisar SQLCODE

7. Ajustar performance

👉 Isso forma programador, não copiador de código.

---

🧠 Comentário final Bellacosa

Aprender COBOL com DB2 não é aprender uma linguagem.
É aprender:

• como dados movem o mundo

• como sistemas críticos pensam

• como escrever código que não pode falhar

🔥 COBOL + DB2 não é passado.
É o núcleo silencioso do presente.

Enquanto modas passam,
o batch fecha o dia.