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.

 

 

Bellacosa Mainframe visita Akihabara

🗼 AKIHABARA – O MAINFRAME OTAKU DO JAPÃO

Se Tóquio fosse um datacenter, Akihabara seria aquele andar barulhento, cheio de LEDs piscando, cabos aparentes, cheiro de eletrônico quente… e personagens de anime te oferecendo panfleto na porta. Bem-vindo a Akihabara (秋葉原), ou simplesmente Akiba, o bairro que começou como loja de rádio e virou o hub definitivo da cultura otaku mundial.

---

🏯 ORIGEM – DO RÁDIO AO WAIFU

No pós-guerra, anos 1940–50, Akihabara nasceu como um mercado informal de eletrônicos.
Peças usadas, rádios, válvulas, fios — era o camelódromo high-tech da época.

📻 Décadas depois:

• anos 70–80 → eletrônicos e computadores

• anos 90 → videogames, PCs, doujinshi

• anos 2000 → anime, mangá, idols, maid cafés

Ou seja: Akihabara evoluiu como software legado bem mantido.

---

👀 O QUE VER (DEBUG VISUAL)

🔹 Lojas de eletrônicos (Yodobashi Camera – um monstro)
🔹 Prédios de 6 a 10 andares, cada piso um universo
🔹 Arcades gigantes (SEGA, Taito, GIGO)
🔹 Vitrines absurdas com figures raríssimas
🔹 Placas neon disputando atenção como batch concorrente

---

🎮 O QUE FAZER (INTERACTIVE MODE)

✔ Caçar figures (novas e usadas)
✔ Jogar claw machines até perder a dignidade
✔ Entrar em lojas de doujin (mangas independentes)
✔ Explorar andares escondidos (EASTER EGGS reais)
✔ Fotografar cosplayers (com respeito!)

💡 Dica Bellacosa: sempre olhe os andares de cima. O tesouro nunca está no térreo.

---

🍜 O QUE COMER (BUFFER DE ENERGIA)

🍛 Curry japonês
🍜 Ramen temático
🍙 Onigiri raiz
🍺 Bares minúsculos escondidos
☕ Maid cafés (experiência cultural — não é só zoeira)

👉 Maid café é tipo CICS: quem não conhece acha estranho, quem entende respeita.

---

🧠 CURIOSIDADES & EASTER EGGS

🟡 Algumas lojas vendem hardware obsoleto funcional
🟡 Tem prédios inteiros só de um único jogo
🟡 Muitas lojas mudam layout semanalmente
🟡 Mangás pornôs ficam separados (com censura pixelada 😏)
🟡 Você pode comprar um parafuso raro ou uma waifu em escala 1/4

---

🧩 AKIHABARA EM ANIMES

📺 Aparece em:

• Steins;Gate (literalmente o coração da história)

• Love Live

• Durarara!!

• Oreimo

• Genshiken

Em anime, Akiba é sempre:
➡️ lugar de encontros
➡️ caos criativo
➡️ refúgio dos “estranhos”
➡️ palco de revelações

---

🧠 COMENTÁRIO BELLACOSA

Akihabara não é só consumo.
É pertencimento.

Ali ninguém te julga por:

• gostar de coisa velha

• colecionar obsessivamente

• se apaixonar por pixels

• viver em universos paralelos

Akihabara entende legado, respeita versão antiga e celebra customização extrema.

---

🏁 CONCLUSÃO

Akihabara é:

• um Sysplex cultural

• um cluster de paixões

• um mainframe humano

Não é bairro.
É estado de espírito.

E como todo bom sistema antigo:
faz barulho, esquenta…
mas nunca cai.

🗼💾

 

Bellacosa Mainframe apresenta o motor do DB2 a algebra relacional

---

🔷 Relational Algebra no Mainframe

Uma viagem raiz pelo coração do DB2 (IBM Mainframe Edition)

Se você trabalha — ou sonha em trabalhar — com IBM Mainframe, cedo ou tarde vai ouvir um termo que parece saído de um livro de matemática dos anos 70:

👉 Relational Algebra

Calma. Respira.
Não é um bicho de sete cabeças.
É, na verdade, a Força por trás do SQL.

Antes de existir SELECT * FROM SYSIBM.SYSDUMMY1, alguém precisou pensar como os dados se relacionam. Esse alguém foi Edgar F. Codd, lá na IBM, em 1970. Sim, tudo isso nasceu dentro da IBM — respeita o mainframe. 🖥️

---

🕰️ Um pouco de história (porque mainframe sem história não é mainframe)

Nos anos 60 e 70:

• Arquivos eram sequenciais

• Relatórios demoravam horas

• Qualquer mudança era dor e sofrimento

Então a IBM apresentou o Modelo Relacional:

• Dados em tabelas

• Relações matemáticas

• Independência entre dados e programas

E para manipular essas tabelas, surgiu a Relational Algebra — uma linguagem conceitual, não escrita diretamente no sistema, mas usada pelo otimizador do DB2 por baixo dos panos.

💡 Easter Egg:
Quando você escreve SQL no DB2, o que o banco realmente executa internamente é Relational Algebra otimizada.

---

⚙️ Os 5 operadores essenciais (o sabre de luz do DBA)

Vamos aos clássicos:

---

1️⃣ Projection (π) — “Me mostra só o que eu preciso”

📌 O que faz
Seleciona colunas específicas de uma tabela.

📘 Conceito:

π (COLUNA1, COLUNA2)

🧠 Tradução DB2:

SELECT COLUNA1, COLUNA2
FROM TABELA;

🖥️ Exemplo Mainframe:

SELECT EMPNO, LASTNAME
FROM EMP;

💡 Dica Bellacosa:

Projection reduz I/O.
Menos coluna = menos leitura = batch mais rápido = operador feliz.

---

2️⃣ Selection (σ) — “Filtra isso aí”

📌 O que faz
Seleciona linhas com base em uma condição.

📘 Conceito:

σ (SALARY > 50000)

🧠 Tradução DB2:

SELECT *
FROM EMP
WHERE SALARY > 50000;

💡 Easter Egg:

WHERE é Selection.
Sempre foi. Sempre será.

---

3️⃣ Union (∪) — “Junta tudo, mas sem duplicar”

📌 O que faz
Concatena duas relações compatíveis (mesmas colunas).

📘 Conceito:

R ∪ S

🧠 Tradução DB2:

SELECT EMPNO FROM EMP_2023
UNION
SELECT EMPNO FROM EMP_2024;

⚠️ Alerta Mainframe:

• UNION remove duplicados

• UNION ALL é mais rápido (menos CPU)

💡 Dica de ouro:

Em batch pesado, pense duas vezes antes de usar UNION sem ALL.

---

4️⃣ Product (×) — “Multiplicação que dá dor de cabeça”

📌 O que faz
Combina todas as linhas de uma tabela com todas as linhas da outra.

📘 Conceito:

R × S

🧠 Tradução SQL (implícita):

SELECT *
FROM EMP, DEPT;

😱 Resultado:

• 100 funcionários × 10 departamentos = 1000 linhas

💡 Bellacosa comenta:

Cartesian Product é tipo JCL sem COND.
Pode até rodar… mas você vai se arrepender.

---

5️⃣ Natural Join (⨝) — “O casamento perfeito”

📌 O que faz
Relaciona tabelas usando colunas comuns automaticamente.

📘 Conceito:

EMP ⨝ DEPT

🧠 Tradução DB2:

SELECT *
FROM EMP
JOIN DEPT
ON EMP.DEPTNO = DEPT.DEPTNO;

💡 Easter Egg Mainframe:

Todo JOIN começa como um Product + Selection.
O DB2 só faz isso de forma inteligente pra você.

---

🧪 Exemplo prático estilo chão de fábrica

🎯 Objetivo:
Listar nome do funcionário e nome do departamento para quem ganha mais de 60k.

🧠 Relational Algebra:

1. Selection (salário)

2. Join (EMP + DEPT)

3. Projection (nome + depto)

🖥️ DB2 SQL:

SELECT E.LASTNAME, D.DEPTNAME
FROM EMP E
JOIN DEPT D
  ON E.DEPTNO = D.DEPTNO
WHERE E.SALARY > 60000;

💡 O DB2 otimiza isso usando Relational Algebra internamente.

---

🧙 Primeiros passos para Padawans do Mainframe

Se você está começando:

✅ Entenda Selection vs Projection
✅ Saiba quando usar JOIN vs UNION
✅ Evite Cartesian Product sem intenção
✅ Pense sempre em I/O e CPU
✅ Lembre-se: SQL é declarativo, mas o DB2 pensa em álgebra

📚 Estude:

• DB2 Explain Plan

• Access Path

• Index usage

---

🏁 Conclusão Bellacosa Style

Relational Algebra não é coisa velha.
É fundação.

Enquanto linguagens vêm e vão,
o DB2 continua rodando batch crítico,
pagando salários,
processando bancos,
e sustentando o mundo corporativo.

E por baixo de tudo isso?

👉 Projection, Selection, Union, Product e Natural Join.

Que a Força (e o z/OS) esteja com você. 🖥️✨

 

Bellacosa Mainframe apresenta Auditoria no IBM SMP/E

📋 Checklist de Auditoria SMP/E

O que o auditor pergunta (e o que você precisa provar)

“Auditor não quer opinião.
Quer evidência.”

---

🧠 Objetivo do checklist

Garantir que:

• O z/OS está íntegro

• A manutenção é controlada

• As mudanças são rastreáveis

• O ambiente é auditável

👉 SMP/E é prova técnica, não discurso.

---

🔐 1. Controle de Acesso (RACF / ACF2 / TSS)

✔ CSI protegido (UACC=NONE)
✔ ALTER restrito a sysprogs autorizados
✔ READ para auditoria
✔ Logging ativo
✔ Revisão periódica de acessos

📌 Evidência:

• LISTDSD

• Relatórios RACF

• Perfis ativos

---

📦 2. Proteção das bibliotecas SMP/E

✔ TARGET libraries protegidas
✔ DLIB libraries protegidas
✔ SMPTLIB, SMPMTS, SMPPTS controlados
✔ Separação TEST / PROD

📌 Evidência:

• RACF profiles

• Dataset attributes

---

🔁 3. Processo RECEIVE / APPLY / ACCEPT

✔ RECEIVE documentado
✔ APPLY CHECK executado
✔ APPLY validado em teste
✔ ACCEPT autorizado formalmente

📌 Evidência:

• Outputs SMP/E

• JCL versionado

• Change records

---

🚨 4. Gestão de ++HOLD e ++ERROR

✔ HOLDS analisados
✔ Decisão documentada
✔ ERROR tratados com cautela
✔ Mitigações registradas

📌 Evidência:

• PTF cover letters

• APARs

• Decisões de risco

---

🧩 5. Gestão de USERMOD

✔ USERMOD documentado
✔ Justificativa formal
✔ Controle de APPLY/ACCEPT
✔ Revisão periódica

📌 Evidência:

• SYSMOD history

• Documentação técnica

---

🧪 6. APPLY CHECK (obrigatório)

✔ APPLY CHECK sempre executado
✔ Resultados arquivados
✔ Conflitos analisados

📌 Evidência:

• Output APPLY CHECK

• Aprovação formal

---

🧱 7. Controle de DLIB (baseline)

✔ DLIB atualizado
✔ ACCEPT consciente
✔ Baseline consistente
✔ DLIB protegido

📌 Evidência:

• CSI

• Relatórios SMP/E

---

🔄 8. Capacidade de RESTORE

✔ Processo definido
✔ Histórico preservado
✔ Testes de rollback
✔ Documentação clara

📌 Evidência:

• JCL RESTORE

• Registros históricos

---

🧠 9. Atualização e Segurança

✔ PTFs de segurança aplicados
✔ CVEs avaliados
✔ Backlog controlado
✔ Plano de atualização

📌 Evidência:

• Relatórios IBM

• Histórico SMP/E

---

🧾 10. Evidências e documentação

✔ Outputs armazenados
✔ Logs disponíveis
✔ Histórico preservado
✔ Responsáveis identificados

📌 Evidência:

• CSI

• JCL

• Relatórios

---

🚨 Red flags para auditor

❌ ALTER irrestrito
❌ ACCEPT sem teste
❌ USERMOD esquecido
❌ CSI sem proteção
❌ Falta de APPLY CHECK

👉 Tudo isso gera não conformidade.

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• SMP/E é trilha de auditoria nativa

• Segurança começa no controle de mudança

---

🧾 Comentário final – Checklist SMP/E

Quem tem SMP/E bem cuidado
não teme auditoria.

📋 Checklist de Auditoria SMP/E, no estilo Bellacosa Mainframe, pensado para auditoria interna, externa, SOX, PCI, ISO, ou simplesmente para dormir tranquilo. 

📋💾🛡️