Feliz Natal do pequeno Luigi para a famiglia Bellacosa. O pequenino Luigi aprontando arte, brincando com os Esquilinhos dançantes. Na época para ele era uma loucura ouvir esses esquilinhos, ele adorava brincar, agarrar, abraçar, apertar as musiquinhas sempre fazendo bagunca com eles.
terça-feira, 29 de dezembro de 2009
sábado, 19 de dezembro de 2009
📋 Checklist Executável de Auditoria z/OS (SMP/E + RACF)
 |
| Bellacosa Mainframe e um Checklist de Auditoria Z/OS |
📋 Checklist Executável de Auditoria z/OS (SMP/E + RACF)
Objetivo: permitir que o sysprog execute, colecione evidências e registre conformidade antes (e durante) uma auditoria.
🧭 Como usar este checklist
Execute cada item na ordem
Cole comandos/outputs como evidência
Marque OK / N/A / FAIL
Anexe decisões e aprovações quando houver
🔐 1) Controle de Acesso (RACF)
1.1 CSI protegido
Evidência (exemplo):
RLIST DATASET HLQ.SMP.CSI ALL
Esperado: UACC=NONE, ALTER restrito
1.2 Bibliotecas SMP/E protegidas
Evidência:
RLIST DATASET HLQ.SMP.* ALL
1.3 IDs privilegiados revisados
Evidência:
LISTUSER * SPECIAL
📦 2) Integridade do SMP/E (CSI)
2.1 CSI acessível e íntegro
Evidência: job SMP/E simples (ex.: LIST)
2.2 Backup periódico do CSI
Evidência: política / job de backup
🔁 3) Processo RECEIVE / APPLY / ACCEPT
3.1 RECEIVE documentado
Evidência: output RECEIVE
3.2 APPLY CHECK executado
Evidência:
SET BDY(TARGET).
APPLY CHECK.
3.3 APPLY aprovado e executado
Evidência: output APPLY
3.4 ACCEPT autorizado
Evidência: output ACCEPT + aprovação
🚨 4) Gestão de ++HOLD e ++ERROR
4.1 HOLDS analisados
Evidência: cover letter / decisão
4.2 ERRORS tratados
Evidência: APAR / mitigação
🧩 5) USERMOD
5.1 USERMOD identificado e justificado
Evidência: histórico SMP/E
5.2 Plano de remoção definido
🧪 6) Evidências Técnicas
6.1 Outputs arquivados
6.2 JCL versionado
🔄 7) Rollback / RESTORE
7.1 Processo RESTORE definido
Evidência:
SET BDY(TARGET).
RESTORE.
🛡️ 8) Segurança e Atualizações
8.1 PTFs de segurança atualizados
8.2 Backlog controlado
🧾 9) Assinaturas e Responsáveis
Sysprog: __________________ Data: //____
Segurança: ________________ Data: //____
Auditoria: ________________ Data: //____
🏁 Resultado Final
Observações:
Checklist executável, evidenciável e auditável — estilo Bellacosa Mainframe.
Checklist Executável De Auditoria Z/os (smp/e + Racf)
sexta-feira, 18 de dezembro de 2009
📜 COBOL é Autoexplicativo? Problemas na documentação do legado.
📜 COBOL é Autoexplicativo?
Documentação, Mitos, Boas Práticas e Sobrevivência no Mainframe Real
“Se o código fosse realmente autoexplicativo, não existiria analista sênior, dump, nem planilha escondida na gaveta.”
— Provérbio não-oficial do Sysprog
1️⃣ O mito do COBOL auto-documentado
Desde sua origem, o COBOL foi vendido como uma linguagem:
legível,
próxima do inglês,
acessível a gestores e usuários de negócio.
Na teoria:
Na prática, sabemos que:
legível ≠ compreensível
código não explica regra de negócio
o “porquê” quase nunca está no fonte
📌 Primeiro choque de realidade
COBOL ajuda a ler a intenção técnica, mas não documenta contexto histórico, exceções fiscais, gambiarra regulatória ou acordo verbal de 1998.
👉 E isso não é culpa da linguagem. É da ausência de documentação.
2️⃣ Self-documenting code: sonho bonito, realidade dura
Existe um conceito romântico no mundo de software:
“Código limpo se documenta sozinho”
No mainframe isso vira rapidamente:
“Código limpo ajuda, mas não se explica sozinho”
⚠️ Gotcha clássico
Perguntas que o código não responde:
Por que zera imposto?
Qual legislação?
Em que data isso foi criado?
Quem autorizou?
Isso ainda é válido?
📌 Regra de ouro Bellacosa
Código mostra o que o sistema faz.
Documentação explica por que ele faz isso.
3️⃣ Onde a documentação realmente mora no COBOL
📂 3.1 No código (sim, mas com juízo)
❌ Comentário inútil
✅ Comentário que salva vidas
📌 Comentário bom envelhece melhor que código bonito.
📘 3.2 Cabeçalho de programa (o RG do sistema)
Todo programa COBOL deveria começar com algo assim:
🧠 Easter Egg #1
Programas sem cabeçalho quase sempre:
quebram em virada de ano
explodem em auditoria
ninguém quer assumir
4️⃣ Público-alvo da documentação: quem você está tentando salvar?
Nem toda documentação é para todo mundo.
🎯 Públicos clássicos no mainframe
| Público | Precisa de |
|---|---|
| Desenvolvedor | Comentários técnicos, layout, lógica |
| Analista de negócio | Regras, exceções, impacto |
| Suporte/Produção | Fluxo, erros, RC, abends |
| Auditor | Rastreabilidade, histórico, motivo |
📌 Erro comum
Achar que um comentário no código resolve tudo.
👉 Não resolve. Ele ajuda.
5️⃣ Padrões: o verdadeiro caminho do “autoexplicativo”
COBOL só fica “auto-documentável” quando existe:
Naming convention clara
Layout consistente
Regras de codificação
Comentários padronizados
❌ Legado sem padrão
✅ Código legível e sustentável
🧠 Easter Egg #2
Quem usa A, B, X1, X2 geralmente:
herdou código sem documentação
tem trauma de manutenção
sabe interpretar dump no olho 😅
6️⃣ Documentando o “não documentado” (zona de guerra)
Agora vem a parte crítica.
⚠️ Realidade dura do mainframe
Sistemas com 30, 40, 50 anos
Regras que ninguém lembra
Desenvolvedores se aposentando
Conhecimento tribal indo embora
📌 O que fazer?
Usar ferramentas modernas
Mapear fluxos reais
Analisar batch, CICS, DB2
Documentar depois que entende
“Se está funcionando, existe uma regra.
Se ninguém sabe qual é, ela precisa ser documentada.”
7️⃣ COBOL, modernização e sobrevivência
Documentação não é nostalgia. É:
pré-requisito de modernização
base de DevOps
segurança contra falha humana
seguro contra auditoria
Sistemas mission critical não podem falhar.
E eles só sobrevivem porque:
alguém documentou
alguém deixou pistas
alguém pensou no próximo
🧠 Easter Egg #3
O programa mais crítico da empresa:
roda em batch às 02:13
ninguém sabe explicar tudo
mas todo mundo tem medo de mexer
8️⃣ Conclusão Bellacosa Mainframe
✔ COBOL não é mágico
✔ Código limpo ajuda, mas não basta
✔ Documentação é responsabilidade técnica
✔ Padrões salvam sistemas
✔ Comentários certos salvam carreiras
Documentar não é escrever mais.
É escrever o que o código nunca vai conseguir explicar.
☕💾
terça-feira, 15 de dezembro de 2009
Brincadeiras de criança, memoria do Luigi a enviar beijinhos a Tia Nana...
Nanazinha com carinho e amor do seu pequeno sobrinho Luigi, um super beijo para começar 2010 com ótimo estilo.
Fim de ano, 2009 terminando e o pequeno Luigi bem animado, brincando com seu pai lelé, mandando muitos beijos e abraços.... Ficando com frio e fazendo careta por causa do cheirinho ruim, ai esse pequeno é um barato, que rapazola fofo... te amo pequenino.terça-feira, 8 de dezembro de 2009
Coral dos Esquilinhos Malucos
O Natal dos Esquilinhos
Foi uma diversao quando comprei os Esquilinhos Cantores e ainda nao tinha ideia que o Luigi voce adorar a brincadeira. Imagine ele do alto dos seus quase 2 anos... iria abraçar, agarrar e brincar com eles.
E aproveitando o espirito natalino, aproveitamos para deixar mensagens de carinho para a familha.
sexta-feira, 6 de novembro de 2009
🔷 QUIESCE no DB2: Congelando Tabelas com Segurança
 |
| Bellacosa Mainframe apresente IBM Mainframe Quiesce |
🔷 QUIESCE no DB2: Congelando Tabelas com Segurança
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.
🕰️ Origem e Contexto
-
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
-
⚙️ O que o QUIESCE faz?
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.
🔹 Sintaxe básica
-
schema.tabela → tabela que você quer “congelar”
-
DB2 mantém o estado consistente até que você libere a tabela.
Liberando a tabela:
-
Permite que transações de escrita voltem ao normal.
💡 Dicas e Boas Práticas
-
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
QUIESCEDindica que a tabela está congelada.
🔍 Curiosidades / Easter Eggs Bellacosa
-
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.
⚡ Impacto na Performance
-
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.
🔑 Resumo Bellacosa
| 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.
quinta-feira, 5 de novembro de 2009
☕ DB2 no IBM Mainframe: o que realmente acontece quando você executa um SQL
 |
| 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:
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.
🧩 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
quarta-feira, 4 de novembro de 2009
🐉 DB2 Compilação, DBRM, BIND, PACKAGE e PLAN
 |
| Bellacosa Mainframe apresenta compilaçao COBOL com DB2 plan e package |
🐉 DB2 + COBOL no Mainframe
Compilação, DBRM, BIND, PACKAGE e PLAN
Ao estilo Bellacosa Mainframe – do big bang ao SELECT
☕ Introdução (pegue seu café)
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.
🕰️ Origem e História (por que tudo isso existe?)
📜 Anos 70–80: quando DB2 nasceu
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).
🧩 Visão Geral do Fluxo (o mapa do tesouro)
COBOL + EXEC SQL
|
v
DB2 PRECOMPILER
|
+--> COBOL PURO
+--> DBRM
|
v
BIND
|
v
PACKAGE
|
v
PLAN
|
v
EXECUÇÃO
👉 Nada aqui é opcional.
📦 O que é DBRM (Database Request Module)?
🎯 Definição
DBRM é o arquivo que contém todas as instruções SQL extraídas do seu programa COBOL.
📌 Características
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”
🧱 O que é PACKAGE?
🎯 Definição
PACKAGE é o DBRM já compilado e otimizado pelo DB2.
📌 Por que PACKAGE existe?
Antigamente:
Um PLAN gigante para tudo ❌
Hoje:
Um PACKAGE por programa ✔️
Melhor performance
Melhor controle de versão
🧠 Analogia Bellacosa
PACKAGE = prato pronto na cozinha do DB2 🍝
DBRM = receita
🧠 O que é PLAN?
🎯 Definição
PLAN é o conjunto de PACKAGES que uma aplicação pode executar.
📌 Importante
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.
🔨 Passo a Passo para um Padawan
🥋 Passo 1 – Escrever o COBOL com SQL
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE ID = :WS-ID
END-EXEC.
🥋 Passo 2 – Pré-compilação DB2
Remove SQL
Gera:
COBOL puro
DBRM
👉 Executado via DSNHPC
🥋 Passo 3 – Compilação COBOL
Compila o código gerado
Produz objeto (.OBJ)
🥋 Passo 4 – Linkedição
Gera LOAD MODULE
🥋 Passo 5 – BIND PACKAGE
Entrada: DBRM
Saída: PACKAGE
🥋 Passo 6 – BIND PLAN
Associa PACKAGES ao PLAN
🥋 Passo 7 – Executar
🎉 O programa roda feliz no CICS ou Batch.
📜 Exemplo de JCL – BIND PACKAGE
//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)
/*
🚨 Erros Comuns (e como sobreviver)
❌ -805
DBRM ou PACKAGE não encontrado
✔️ Solução:
PACKAGE não está no PLAN
PLAN não foi rebindado
❌ -818
Timestamp mismatch
✔️ Solução:
Rebind do PACKAGE
Código recompilado mas DBRM antigo
❌ -204
Objeto não existe
✔️ Solução:
Tabela/view não existe
Schema errado
💡 Dicas de Ouro Bellacosa
☕ 1 DBRM = 1 PACKAGE
☕ Nunca use PLAN gigante com tudo
☕ Sempre versionar PACKAGE
☕ Nomeie PACKAGE com ambiente:
PKGPROG1_DEV
PKGPROG1_HML
PKGPROG1_PRD
🥚 Easter Eggs (curiosidades)
🥚 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
🧙 Comentários de Mestre Jedi
Se você entende DBRM, PACKAGE e PLAN…
Você já saiu do nível Padawan.
Quem domina BIND domina o DB2.
📌 Conclusão
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
segunda-feira, 2 de novembro de 2009
📘 Guia de Auditoria z/OS Completo
 |
| Bellacosa Mainframe apresenta Guia de Auditoria Z/OS |
📘 Guia de Auditoria z/OS Completo
Do RACF ao SMP/E: como provar que seu mainframe é confiável
“Auditoria em z/OS não é caça ao erro.
É validação de maturidade operacional.”
🎯 Objetivo deste guia
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.
🧠 Visão geral da auditoria em z/OS
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.
🔐 Pilar 1 – Controle de Acesso (RACF / ACF2 / TSS)
O auditor verifica:
-
IDs privilegiados
-
Perfis genéricos
-
UACC
-
Logging
-
Segregação de funções
Evidências:
-
LISTUSER
-
RLIST
-
Relatórios SMF
-
Revisão periódica de acessos
📌 Privilégio excessivo reprova auditoria.
🛡️ Pilar 2 – Integridade do Sistema
Ferramentas-chave:
-
SMP/E
-
CSI
-
DLIB
-
TARGET libraries
O auditor quer saber:
-
Quem muda o sistema
-
Como muda
-
Se há controle
📌 Aqui o SMP/E reina absoluto.
🔁 Pilar 3 – Gestão de Mudanças
Avaliação típica:
-
Processo RECEIVE/APPLY/ACCEPT
-
APPLY CHECK obrigatório
-
Análise de ++HOLD e ++ERROR
-
USERMOD documentado
Evidências:
-
Outputs SMP/E
-
Change records
-
APARs e PTFs
🧩 Pilar 4 – Rastreabilidade e Evidência
O auditor exige:
-
Histórico preservado
-
Logs acessíveis
-
Responsáveis identificados
Ferramentas:
-
CSI
-
SMF
-
Logs RACF
-
Versionamento de JCL
📌 Sem evidência, não existe controle.
🔄 Pilar 5 – Continuidade e Recuperação
Avaliação:
-
Backup de CSI
-
Capacidade de RESTORE
-
Planos de contingência
-
Testes documentados
📌 Auditoria não aceita “nunca testamos”.
📦 Auditoria por componente (check rápido)
🔹 SMP/E
✔ Controle de acesso
✔ APPLY CHECK
✔ ACCEPT consciente
✔ USERMOD controlado
🔹 RACF
✔ UACC=NONE
✔ Logging ativo
✔ Revisão periódica
🔹 JES / System
✔ Parâmetros controlados
✔ Alterações documentadas
🔹 SMF
✔ Coleta ativa
✔ Retenção definida
🚨 Red flags clássicos em auditoria z/OS
❌ IDs genéricos
❌ ALTER irrestrito
❌ USERMOD esquecido
❌ PTFs de segurança atrasados
❌ Falta de documentação
👉 Tudo isso vira finding.
🧠 Caso real (estilo Bellacosa)
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.
🎓 Como se preparar para auditoria
-
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.”
🧠 Curiosidades Bellacosa
-
Auditor confia mais no CSI do que em planilha
-
Mainframe já nasce auditável
-
Falha é quase sempre humana, não técnica
🧾 Encerramento – Guia de Auditoria z/OS
z/OS não é inseguro.
Inseguro é rodar sem controle.
Quem domina:
-
RACF
-
SMP/E
-
Processos
👉 passa em qualquer auditoria.
📘💾🛡️🔥
domingo, 4 de outubro de 2009
🔷 INNER JOIN no IBM DB2 Mainframe – A Arte de Relacionar Tabelas
 |
| 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
🔹 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
-
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, Bsem WHERE é um Product, que explode linhas. -
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
JOINexplí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
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
-
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:
-
RUNSTATSajuda 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
-
🔑 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.
sábado, 3 de outubro de 2009
🗼 AKIHABARA – O MAINFRAME OTAKU DO JAPÃO
 |
| 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.
🗼💾
Subscrever:
Comentários (Atom)