📜 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

🐉 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

 

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.

📘💾🛡️🔥