 |
| Bellacosa Mainframe apresente IBM Mainframe Quiesce |
No DB2 para IBM z/OS, QUIESCE é uma operação usada para garantir consistência de dados durante operações administrativas, especialmente quando você precisa fazer backup, reorganização ou manutenção de tabelas sem corromper os dados.
Em ambientes mainframe, tabelas DB2 são acessadas 24/7, com milhares de transações simultâneas.
Antigamente, para garantir integridade, os DBAs precisavam parar o sistema inteiro para fazer backups ou reorganizações.
A IBM introduziu o QUIESCE para “congelar” temporariamente uma tabela ou partição, permitindo:
Manutenção de tabelas
Criação de backups consistentes
Redução do impacto nas transações online
Quando você executa um QUIESCE TABLE, o DB2:
Impede alterações na tabela
Nenhum INSERT, UPDATE ou DELETE é permitido.
Permite leitura
Transações de SELECT ainda podem ser executadas normalmente (dependendo da configuração).
Cria um ponto de consistência
Ideal para backup ou reorganização.
Pense no QUIESCE como uma pausa temporária e controlada na tabela, sem desligar o banco ou impactar outras tabelas.
schema.tabela → tabela que você quer “congelar”
DB2 mantém o estado consistente até que você libere a tabela.
Permite que transações de escrita voltem ao normal.
Use somente quando necessário
Congelar muitas tabelas por muito tempo = impacto em aplicações.
Combine com backups offline
QUIESCE + COPY OUT = backup consistente sem travar o banco inteiro.
Evite longos períodos de quiesce
Transações concorrentes ficam bloqueadas, podendo causar timeout ou deadlocks.
Verifique o status
O estado QUIESCED indica que a tabela está congelada.
O comando QUIESCE só existe no DB2 para z/OS. Em DB2 LUW (Linux/Unix/Windows), a abordagem é diferente (LOCK + BACKUP).
Internamente, DB2 usa locks especiais e pontos de consistência para garantir que mesmo transações longas não corrompam o backup.
Alguns DBAs chamam o QUIESCE de “pause mágico”, porque a tabela parece congelada, mas outras operações continuam normalmente.
Transações de escrita ficam suspensas, então:
Muitas sessões concorrentes → podem acumular espera
Bancos com alto volume de updates → planejar QUIESCE fora do horário de pico
Transações de leitura não são bloqueadas (depende do tipo de lock).
É mais leve que DB2 LOCK TABLE ou downtime total.
| Conceito | Detalhe |
|---|---|
| O que é | Congela temporariamente uma tabela para manutenção/backup |
| Sintaxe | QUIESCE TABLE schema.tabela; e RELEASE |
| Permite SELECT? | Sim (dependendo do lock) |
| Permite INSERT/UPDATE/DELETE? | Não durante o quiesce |
| Quando usar | Backup consistente, reorganização, manutenção de dados |
| Impacto | Leve se curto; bloqueia transações de escrita |
💡 Easter Egg:
Se você fizer QUIESCE de uma tabela grande, é quase como colocar a tabela em “hibernação”: DB2 mantém tudo consistente internamente, e você nem sente nada até liberar.
 |
| Bellacosa Mainframe explica como funciona uma query no Db2 |
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:
Parse da query e validação de sintaxe
Bind de tabelas e colunas
Criação do executável
Cálculo do plano de execução
Execução do plano
Tudo isso antes do primeiro byte sair do disco.
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.
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.
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.
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
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.
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.
✔ 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
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
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 compilaçao COBOL com DB2 plan e package |
Todo padawan que entra no mundo do IBM Mainframe + COBOL + DB2 escuta termos quase místicos:
DBRM, BIND, PACKAGE, PLAN…
No começo parecem nomes de monstros de RPG 🧙♂️, mas na prática eles formam o coração da integração entre COBOL e DB2.
Este artigo explica de onde isso veio, por que existe, como funciona, como compilar, como errar (e sobreviver) e como pensar como um Jedi do Mainframe.
IBM precisava de um banco relacional para rodar junto com aplicações COBOL críticas.
COBOL não entende SQL nativamente.
Solução: criar um pré-compilador.
👉 Nasce o conceito de SQL EMBUTIDO (EXEC SQL).
Mas…
💥 Problema:
O compilador COBOL não sabe o que é SQL.
💡 Solução IBM:
Criar um artefato intermediário → DBRM (Database Request Module).
COBOL + EXEC SQL
|
v
DB2 PRECOMPILER
|
+--> COBOL PURO
+--> DBRM
|
v
BIND
|
v
PACKAGE
|
v
PLAN
|
v
EXECUÇÃO
👉 Nada aqui é opcional.
DBRM é o arquivo que contém todas as instruções SQL extraídas do seu programa COBOL.
Criado pelo pré-compilador do DB2
Contém:
SELECT
INSERT
UPDATE
DELETE
CURSORS
Não contém código COBOL
🧠 Pense assim:
DBRM = “O livro de feitiços SQL do programa”
PACKAGE é o DBRM já compilado e otimizado pelo DB2.
Antigamente:
Um PLAN gigante para tudo ❌
Hoje:
Um PACKAGE por programa ✔️
Melhor performance
Melhor controle de versão
PACKAGE = prato pronto na cozinha do DB2 🍝
DBRM = receita
PLAN é o conjunto de PACKAGES que uma aplicação pode executar.
Quem executa é o PLAN
O PLAN aponta para vários PACKAGES
Normalmente 1 PLAN por aplicação/sistema
🧠 Jedi Tip:
Programa não executa PACKAGE direto. Executa PLAN.
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE ID = :WS-ID
END-EXEC.
Remove SQL
Gera:
COBOL puro
DBRM
👉 Executado via DSNHPC
Compila o código gerado
Produz objeto (.OBJ)
Gera LOAD MODULE
Entrada: DBRM
Saída: PACKAGE
Associa PACKAGES ao PLAN
🎉 O programa roda feliz no CICS ou Batch.
//BINDPKG EXEC PGM=IKJEFT01
//STEPLIB DD DISP=SHR,DSN=DB2.DSNLOAD
//SYSTSPRT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(DB2P)
BIND PACKAGE(MEUSCHEMA.PKGPROG1)
MEMBER(PROG1)
ACTION(REPLACE)
ISOLATION(CS)
VALIDATE(BIND)
OWNER(MEUSCHEMA)
/*
DBRM ou PACKAGE não encontrado
✔️ Solução:
PACKAGE não está no PLAN
PLAN não foi rebindado
Timestamp mismatch
✔️ Solução:
Rebind do PACKAGE
Código recompilado mas DBRM antigo
Objeto não existe
✔️ Solução:
Tabela/view não existe
Schema errado
☕ 1 DBRM = 1 PACKAGE
☕ Nunca use PLAN gigante com tudo
☕ Sempre versionar PACKAGE
☕ Nomeie PACKAGE com ambiente:
PKGPROG1_DEV
PKGPROG1_HML
PKGPROG1_PRD
🥚 DBRM é tão antigo que veio do System R, o avô do DB2
🥚 Muitos ambientes ainda têm PLAN criados nos anos 90 😱
🥚 Rebind pode melhorar performance sem recompilar COBOL
🥚 EXPLAIN do PACKAGE mostra o plano de acesso
Se você entende DBRM, PACKAGE e PLAN…
Você já saiu do nível Padawan.
Quem domina BIND domina o DB2.
DB2 + COBOL não é magia negra.
É:
Engenharia
História
Performance
Disciplina
E quando bem feito…
🚀 Roda por décadas sem cair.
☕ Um Café no Bellacosa Mainframe
 |
| Bellacosa Mainframe apresenta Guia de Auditoria Z/OS |
“Auditoria em z/OS não é caça ao erro.
É validação de maturidade operacional.”
Este guia serve para:
Preparar ambientes para auditoria
Responder auditores com evidência técnica
Evitar não conformidades
Padronizar governança em z/OS
👉 Não é teoria. É prática de campo.
Auditoria em z/OS gira em torno de 5 pilares:
1️⃣ Controle de acesso
2️⃣ Integridade do sistema
3️⃣ Gestão de mudanças
4️⃣ Rastreabilidade
5️⃣ Continuidade operacional
Cada pilar tem ferramentas nativas do mainframe.
IDs privilegiados
Perfis genéricos
UACC
Logging
Segregação de funções
LISTUSER
RLIST
Relatórios SMF
Revisão periódica de acessos
📌 Privilégio excessivo reprova auditoria.
SMP/E
CSI
DLIB
TARGET libraries
Quem muda o sistema
Como muda
Se há controle
📌 Aqui o SMP/E reina absoluto.
Processo RECEIVE/APPLY/ACCEPT
APPLY CHECK obrigatório
Análise de ++HOLD e ++ERROR
USERMOD documentado
Outputs SMP/E
Change records
APARs e PTFs
Histórico preservado
Logs acessíveis
Responsáveis identificados
CSI
SMF
Logs RACF
Versionamento de JCL
📌 Sem evidência, não existe controle.
Backup de CSI
Capacidade de RESTORE
Planos de contingência
Testes documentados
📌 Auditoria não aceita “nunca testamos”.
✔ Controle de acesso
✔ APPLY CHECK
✔ ACCEPT consciente
✔ USERMOD controlado
✔ UACC=NONE
✔ Logging ativo
✔ Revisão periódica
✔ Parâmetros controlados
✔ Alterações documentadas
✔ Coleta ativa
✔ Retenção definida
❌ IDs genéricos
❌ ALTER irrestrito
❌ USERMOD esquecido
❌ PTFs de segurança atrasados
❌ Falta de documentação
👉 Tudo isso vira finding.
Auditor pergunta sobre um módulo alterado
Não há registro no SMP/E
Ninguém sabe quem fez
📌 Conclusão:
Ambiente sem governança.
Trate auditoria como rotina
Use SMP/E como aliado
Automatize evidências
Documente decisões
Revise acessos
💡 Dica Bellacosa:
“Auditoria bem-sucedida começa meses antes.”
Auditor confia mais no CSI do que em planilha
Mainframe já nasce auditável
Falha é quase sempre humana, não técnica
z/OS não é inseguro.
Inseguro é rodar sem controle.
Quem domina:
RACF
SMP/E
Processos
👉 passa em qualquer auditoria.
📘💾🛡️🔥
 |
| Bellacosa Mainframe apresenta IBM Mainframe DB2 Inner Join |
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…
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.
INNER JOIN é a operação que retorna somente as linhas onde existe correspondência em ambas as tabelas, baseado em uma chave comum.
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.
Prefira joins explícitos (INNER JOIN ON) em DB2 → facilita leitura e manutenção.
Sempre qualifique colunas se houver nomes repetidos → evita ambiguidade (E.EmployeeID, O.EmployeeID).
Use aliases curtos → economiza digitação e deixa o código limpo.
Evite cartesian products sem intenção → FROM A, B sem WHERE é um Product, que explode linhas.
Verifique estatísticas de tabela → DB2 otimiza join usando índices.
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.
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
Resultado:
| LastName | DeptName |
|---|---|
| Smith | Accounting |
| Jones | HR |
Observe: DeptID = 30 não aparece porque não há funcionário correspondente.
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
Indexes importam muito:
JOIN em colunas indexadas = leitura rápida, menos I/O
Sem índice → DB2 faz table scan → lento em tabelas grandes
Estatísticas DB2:
RUNSTATS ajuda o otimizador a escolher o caminho ideal
Número de tabelas no JOIN:
Mais joins = mais complexidade e consumo de CPU
Prefira joins em cascata controlados, evite joins desnecessários
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
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 |
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.
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.
🔹 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
✔ 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.
🍛 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.
🟡 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
📺 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
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.
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.
🗼💾