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 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. 💾🧠

 

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.

 

 

Bellacosa Mainframe explica como funciona uma query no Db2

☕ DB2 no IBM Mainframe: o que realmente acontece quando você executa um SQL

---

🧠 Introdução – “É só um SELECT”… será mesmo?

Para quem está começando, parece simples:

SELECT * FROM CONTA WHERE SALDO > 1000;

Mas no IBM Mainframe, esse comando aciona uma cadeia de decisões complexas, refinadas por décadas de engenharia.
Antes de qualquer dado ser lido, o DB2 passa por um verdadeiro ritual técnico — silencioso, preciso e implacável.

Hoje vamos abrir a caixa-preta e entender, passo a passo, o que o DB2 faz quando recebe um SQL:

1. Parse da query e validação de sintaxe

2. Bind de tabelas e colunas

3. Criação do executável

4. Cálculo do plano de execução

5. Execução do plano

Tudo isso antes do primeiro byte sair do disco.

---

🧩 Passo 1 – Parse da query: o DB2 vira professor de português

Parse the query and check for proper syntax

Neste primeiro momento, o DB2:

• Analisa a sintaxe SQL

• Verifica comandos, cláusulas e ordem

• Garante que a query está gramaticalmente correta

Exemplo de erro clássico:

SELEC * FROM CLIENTE;

⛔ Resultado: erro imediato.
O DB2 não tenta adivinhar sua intenção.

☕ Comentário Bellacosa
Mainframe não é Google.
Se escreveu errado, aprende rápido — na marra.

---

🧩 Passo 2 – Bind lógico: tabelas e colunas entram em cena

Bind the tables and columns

Aqui o DB2 pergunta:

• Essa tabela existe?

• Esse schema está correto?

• Essa coluna pertence a essa tabela?

• Você tem permissão para isso?

Exemplo:

SELECT CPF FROM ELJEFE.CLIENTE;

Se:

• Schema errado

• Coluna inexistente

• Falta de autorização RACF

⛔ Falha antes da execução.

🧠 Curiosidade Bellacosa
Grande parte dos erros “objeto não encontrado” não é objeto inexistente —
é SQLID e schema mal resolvidos.

---

🧩 Passo 3 – Criar o executável: SQL vira código de verdade

Create an executable and hand it to the optimizer

Aqui acontece a mágica que muitos ignoram.

No DB2 z/OS:

• SQL não é interpretado a cada execução

• Ele é transformado em um executável

• Esse executável é armazenado em um PACKAGE

💡 Em programas COBOL:

• O BIND cria o package

• O package faz parte de um PLAN

• O programa executa o PLAN

☕ Comentário El Jefe
No mainframe, SQL não é script descartável.
É artefato compilado, tratado com o mesmo respeito que código fonte.

---

🧩 Passo 4 – O Otimizador entra em ação

Calculate the optimal execution plan

Agora o DB2 pensa — muito.

O otimizador avalia:

• Índices disponíveis

• Estatísticas do catálogo

• Volume de dados

• Ordem de joins

• Tipo de acesso (index scan, table scan, etc.)

Ele calcula:
👉 o plano de execução mais eficiente possível

🧠 Easter Egg técnico
O otimizador do DB2 z/OS é considerado um dos mais sofisticados do mundo, porque:

• Precisa decidir rápido

• Precisa acertar

• E não pode errar em escala bilionária

---

🧩 Passo 5 – Execução do plano: agora sim, o dado anda

Run the execution plan

Somente agora:

• O DB2 acessa tablespaces

• Usa índices (ou não)

• Aplica filtros

• Retorna os dados

Importante:

• O DB2 não executa o SQL

• Ele executa o plano previamente calculado

☕ Comentário Bellacosa
Você escreve SQL.
Quem manda é o plano de execução.

---

🧠 Visão Jedi – o fluxo completo

Tudo isso acontece nesta ordem:

SQL
 ↓
Parse (sintaxe)
 ↓
Bind lógico (tabelas / colunas / segurança)
 ↓
Criação do executável (PACKAGE)
 ↓
Otimizador calcula o plano
 ↓
Execução do plano

Se algo falhar em qualquer etapa…
👉 nada executa.

---

🧪 Dicas práticas Bellacosa Mainframe

✔ Erro de SQL geralmente é erro de modelagem ou schema
✔ Estatísticas ruins = plano ruim
✔ BIND mal feito vira problema eterno
✔ Não confunda SQL bonito com SQL eficiente
✔ EXPLAIN é seu melhor amigo

---

🥚 Curiosidades finais

• Um mesmo SQL pode ter planos diferentes em ambientes distintos

• ALTER de índice pode mudar performance sem mudar código

• Em produção, o DB2 prefere estabilidade a “milagre”

• Otimizador não é mágico — ele só decide com base no que você fornece

---

☕ Conclusão – SQL no Mainframe é disciplina

No IBM Mainframe:

• SQL não é improviso

• Execução não é tentativa

• Performance não é sorte

Cada SELECT passa por um pipeline rigoroso, desenhado para não falhar.

No El Jefe, a verdade é simples:

Quem entende o caminho do SQL dentro do DB2, para de culpar o banco e começa a dominar o sistema.

Até o próximo café ☕
— Bellacosa Mainframe

 

Bellacosa Mainframe apresenta IBM Mainframe DB2 Inner Join

🔷 INNER JOIN no IBM DB2 Mainframe – A Arte de Relacionar Tabelas

Se você trabalha com IBM Mainframe, provavelmente já precisou combinar dados de diferentes tabelas. E para isso existe o INNER JOIN, que é o clássico entre os joins em SQL.

Mas antes de entrar nos detalhes, vamos à história…

---

🕰️ História e Origem

O conceito de INNER JOIN vem diretamente do Modelo Relacional de Codd (1970), criado dentro da IBM.

• Edgar F. Codd, um cientista da IBM, imaginou que dados deveriam ser armazenados em tabelas relacionais e manipulados por álgebra relacional.

• Ele não inventou “INNER JOIN” como conhecemos hoje, mas a ideia de combinar tabelas via chaves comuns nasceu com ele.

• SQL evoluiu nos anos 80 para suportar explicitamente joins:

  • Sintaxe implícita: FROM A, B WHERE A.key = B.key

  • Sintaxe explícita: FROM A INNER JOIN B ON A.key = B.key

No DB2 para Mainframe, o INNER JOIN é altamente otimizado para lidar com milhões de linhas em transações batch ou OLTP, mantendo a performance crítica.

---

⚙️ O que é INNER JOIN?

INNER JOIN é a operação que retorna somente as linhas onde existe correspondência em ambas as tabelas, baseado em uma chave comum.

🔹 Sintaxe padrão DB2

-- Explicit INNER JOIN (recomendado)
SELECT E.EmployeeID, E.LastName, O.OrderID
FROM Employees E
INNER JOIN Orders O
  ON E.EmployeeID = O.EmployeeID;

-- Implicit INNER JOIN (estilo antigo)
SELECT E.EmployeeID, E.LastName, O.OrderID
FROM Employees E, Orders O
WHERE E.EmployeeID = O.EmployeeID;

🔹 Observações

• Chave comum: não precisa ter o mesmo nome, apenas valores compatíveis.

• Sem correspondência → linha é descartada.

• Pode usar múltiplas tabelas → INNER JOIN é associativo.

---

💡 Dicas Bellacosa para Mainframe

1. Prefira joins explícitos (INNER JOIN ON) em DB2 → facilita leitura e manutenção.

2. Sempre qualifique colunas se houver nomes repetidos → evita ambiguidade (E.EmployeeID, O.EmployeeID).

3. Use aliases curtos → economiza digitação e deixa o código limpo.

4. Evite cartesian products sem intenção → FROM A, B sem WHERE é um Product, que explode linhas.

5. Verifique estatísticas de tabela → DB2 otimiza join usando índices.

---

🔍 Curiosidades & Easter Eggs

• No DB2, todas as joins são INNER por padrão se você não usar OUTER.

• Internamente, o otimizador transforma INNER JOIN em operações de álgebra relacional: Product + Selection.

• Usar JOIN explícito ajuda o Explain Plan a gerar caminhos de acesso mais eficientes.

• Combinar índices corretos + INNER JOIN = batch mais rápido, menos I/O.

---

🧪 Exemplo prático

Imagine que temos duas tabelas no z/OS DB2:

EMPLOYEES

EmployeeID	LastName	DeptID
101	Smith	10
102	Jones	20

DEPARTMENTS

DeptID	DeptName
10	Accounting
20	HR
30	IT

Query: INNER JOIN

SELECT E.LastName, D.DeptName
FROM Employees E
INNER JOIN Departments D
  ON E.DeptID = D.DeptID;

Resultado:

LastName	DeptName
Smith	Accounting
Jones	HR

Observe: DeptID = 30 não aparece porque não há funcionário correspondente.

---

📈 Uso e Razão de Uso

• Combinar tabelas relacionadas → RELACIONAL puro

• Resumir informações em relatórios ou dashboards OLAP

• Criar answer sets consistentes para análises

• Fundamental para consultas em ERP, finanças e logística

No mainframe, INNER JOIN é usado em:

• Batch → processa milhões de registros rapidamente

• Online Transaction Processing (OLTP) → respostas rápidas e consistentes

---

⚡ Impacto na Performance e Otimização

1. Indexes importam muito:

   • JOIN em colunas indexadas = leitura rápida, menos I/O

   • Sem índice → DB2 faz table scan → lento em tabelas grandes

2. Estatísticas DB2:

   • RUNSTATS ajuda o otimizador a escolher o caminho ideal

3. Número de tabelas no JOIN:

   • Mais joins = mais complexidade e consumo de CPU

   • Prefira joins em cascata controlados, evite joins desnecessários

4. Filtros antes do JOIN:

   • Use WHERE/qualificação para reduzir linhas antes do INNER JOIN

   • Isso diminui o volume de dados processados e acelera o batch

---

🔑 Comentários finais Bellacosa

• INNER JOIN é a base do SQL relacional, especialmente no DB2 do mainframe.

• Sintaxe explícita + colunas qualificadas + índices corretos = performance top de linha.

• Mesmo em 2026, ele é indispensável em sistemas críticos da IBM.

• Dica bônus: use EXPLAIN PLAN para ver como DB2 executa seus INNER JOINs.

💡 Easter Egg:

Por baixo do capô, o DB2 transforma cada INNER JOIN em Product + Selection + Projection na álgebra relacional — a magia acontece silenciosa enquanto você apenas digita INNER JOIN.