Que beijinho mais gostoso o Luigi e os Esquilos natalinos.

 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.

 

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 criado com sucesso ✅

Ele já está pronto para:

• 🧪 execução técnica real (com comandos e evidências)

• 🛡️ auditoria interna e externa

• 📄 impressão / PDF

• 🎓 treinamento de sysprogs

Checklist Executável De Auditoria Z/os (smp/e + Racf)

📜 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:

IF CUSTOMER-STATUS = 'A'
   PERFORM PROCESS-ACTIVE-CUSTOMER
END-IF

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

IF WS-FLAG = 'Y'
   MOVE ZERO TO WS-TAX
END-IF

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

* Move value to variable
MOVE A TO B.

✅ Comentário que salva vidas

* REGRA FISCAL BR-ICMS-2017
* Conforme decreto 12.887, clientes com FLAG = 'Y'
* estao isentos de imposto nesta operacao
IF WS-FLAG = 'Y'
   MOVE ZERO TO WS-TAX
END-IF

📌 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:

*****************************************************************
* PROGRAMA....: FINC1023
* DESCRICAO...: Calculo de impostos para faturamento
* MODULO......: Financeiro
* AUTOR.......: J. SILVA
* DATA........: 12/03/2017
* ALTERACOES..:
*  - 05/06/2019 - Ajuste ICMS MG (CHG#45871)
*  - 10/08/2022 - Isencao clientes FLAG=Y (LEGAL-889)
*****************************************************************

🧠 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

01 A.
   05 B PIC 9(05).

✅ Código legível e sustentável

01 WS-INVOICE-TOTAL        PIC 9(07)V99.
01 WS-INVOICE-TAX          PIC 9(07)V99.

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

☕💾

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.

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.

 

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:

1. Impede alterações na tabela

   • Nenhum INSERT, UPDATE ou DELETE é permitido.

2. Permite leitura

   • Transações de SELECT ainda podem ser executadas normalmente (dependendo da configuração).

3. 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

-- Congela a tabela para manutenção
QUIESCE TABLE schema.tabela;

• schema.tabela → tabela que você quer “congelar”

• DB2 mantém o estado consistente até que você libere a tabela.

Liberando a tabela:

QUIESCE TABLE schema.tabela RELEASE;

• Permite que transações de escrita voltem ao normal.

---

💡 Dicas e Boas Práticas

1. Use somente quando necessário

   • Congelar muitas tabelas por muito tempo = impacto em aplicações.

2. Combine com backups offline

   • QUIESCE + COPY OUT = backup consistente sem travar o banco inteiro.

3. Evite longos períodos de quiesce

   • Transações concorrentes ficam bloqueadas, podendo causar timeout ou deadlocks.

4. Verifique o status

SELECT * FROM SYSIBM.SYSTABLES
WHERE NAME = 'TABELA' AND CREATOR = 'SCHEMA';

• O estado QUIESCED indica 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.

 

 

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