Bellacosa Mainframe comenta sobre cobol quebrando e a busca por culpados smp/e nos bastidores

🔥💀 “SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE MEXEU NOS BASTIDORES”

O guia que todo dev COBOL deveria ler antes de culpar o programa

---

Se você é dev COBOL, já viveu isso:

💣 “o programa rodava ontem… hoje ABENDOU… e ninguém mexeu em nada”

👉 Spoiler: alguém mexeu sim
👉 E provavelmente foi o SMP/E

---

🧠 A VERDADE QUE NINGUÉM TE CONTA

No mundo do mainframe, seu COBOL não vive sozinho.

Ele depende de:

• load modules
• bibliotecas
• runtime
• serviços do sistema

E tudo isso é controlado por um cara invisível:

💀 SMP/E — o gerente silencioso do ambiente

---

🕰️ UM POUCO DE HISTÓRIA (QUE EXPLICA TUDO)

Antes dos anos 80…

• sysprog fazia manutenção manual
• copiava módulos na mão
• sobrescrevia código sem controle

Resultado?

💣 ambiente inconsistente
💣 sistema instável
💣 caos

Então nasceu o SMP (depois SMP/E):

👉 pra trazer controle, rastreabilidade e sanidade

---

🔥 TRADUZINDO PRA VOCÊ, DEV COBOL

Pensa assim:

seu programa = ponta do iceberg
smp/e = quem controla o iceberg inteiro

---

⚙️ O QUE O SMP/E FAZ (NA VIDA REAL)

• instala produtos (CICS, DB2, z/OS)
• aplica correções (PTFs)
• atualiza módulos que você usa
• controla versões do ambiente

💡 Ou seja:

🔥 ele pode mudar seu runtime sem você tocar no código

---

💀 O FLUXO QUE DECIDE SEU DESTINO

receive → apply → accept

🧩 RECEIVE

👉 baixa a mudança
👉 não altera nada ainda

---

💥 APPLY

👉 altera o ambiente
👉 muda módulos que seu programa usa

💀 é aqui que seu COBOL pode “mudar de comportamento”

---

🏁 ACCEPT

👉 oficializa a mudança
👉 vira baseline

---

⚠️ EASTER EGG (VIDA REAL)

💣 “ninguém mexeu no programa”
👉 mas alguém fez APPLY ontem à noite

---

🧱 TARGET vs DLIB (A CHAVE DO UNIVERSO)

👉 Isso aqui explica MUITA coisa:

Tipo	O que é
TARGET	o que roda
DLIB	base confiável

---

💡 Cenário clássico:

• APPLY alterou TARGET
• seu programa usa nova versão
• comportamento mudou

👉 você nem viu acontecer

---

♻️ RESTORE — O HERÓI ESQUECIDO

Quando dá ruim:

👉 SMP/E pode restaurar versão da DLIB

restore = desfazer desastre

💡 Sim… dá pra “voltar no tempo”

---

🧠 CSI — O CÉREBRO DO SISTEMA

SMP/E não trabalha no escuro.

Ele mantém um banco chamado:

🔥 CSI (Consolidated Software Inventory)

Ali ele sabe:

• o que está instalado
• versões
• dependências
• histórico

---

💀 Sem CSI consistente:

você não tem ambiente… tem uma bomba relógio

---

📦 SYSMOD — O PACOTE QUE MUDA TUDO

Tudo que entra no sistema vem assim:

👉 SYSMOD

Tipos:

• PTF → correção
• APAR → problema corrigido
• FUNCTION → nova funcionalidade
• USERMOD → customização

---

💡 Curiosidade:

USERMOD mal feito = pesadelo eterno 😄

---

🧠 MCS — A LINGUAGEM SECRETA

Dentro do SYSMOD existe:

++ alguma coisa

Isso são MCS (instructions)

Exemplo:

++VER
++MOD
++HOLD

---

💡 Tradução:

SMP/E não “decide”… ele executa ordens do SYSMOD

---

💣 DEPENDÊNCIAS (ONDE O BICHO PEGA)

Tipos:

• PRE → precisa antes
• REQ → precisa junto
• SUP → substitui

---

💥 Se faltar dependência:

APPLY FAILED

👉 e o sysprog entra em guerra

---

🧬 TRACKING — O NÍVEL NINJA

SMP/E sabe exatamente o nível de cada módulo:

FMID = origem
RMID = última substituição
UMID = updates

---

💡 Isso permite:

• saber versão real
• evitar conflito
• diagnosticar erro

---

⚠️ EASTER EGG DE PRODUÇÃO

💣 “o bug apareceu do nada”

👉 não apareceu

👉 o RMID mudou 😄

---

🧠 VISÃO DE GUERRA (PRA DEV COBOL)

Se você entender SMP/E:

✅ você para de culpar o programa
✅ entende mudanças de ambiente
✅ conversa melhor com sysprog
✅ vira profissional diferenciado

---

🔥 UMA GRANDE VERDADE

💀 COBOL quebra raramente
💀 ambiente quebra frequentemente

---

🍛 A PENSAR NA HORA DO ALMOÇO

👉 Quantos erros você já debugou…

…que na verdade eram:

• mudança de load module
• alteração de runtime
• PTF aplicada

---

🧪 MÃO NA MASSA (MENTALIDADE)

Próxima vez que algo quebrar:

❌ não pergunte:

“quem mudou o programa?”

✅ pergunte:

“teve APPLY recente?”

---

🚀 FRASE FINAL (ESTILO BELLACOSA)

🔥 “Seu programa não mudou…
o mundo ao redor dele mudou.”

 

Bellacosa Mainframe explica smp/e para padawans

🔥💀 DÚVIDAS FREQUENTES SOBRE SMP/E

“o que todo mundo já errou… mas não admite”

---

🧠 1. SMP/E é só para sysprog?

👉 Resposta curta: SIM (na prática)

👉 Resposta real:

• Dev COBOL não usa direto
• Mas é impactado o tempo todo

💡 Se você é dev e entende SMP/E:

você para de sofrer debug desnecessário

---

⚙️ 2. Qual a diferença entre RECEIVE, APPLY e ACCEPT?

👉 Clássico:

RECEIVE → carrega
APPLY   → instala (TARGET)
ACCEPT  → oficializa (DLIB)

💥 Dica:

APPLY muda o ambiente
ACCEPT muda o futuro

---

💀 3. Posso dar APPLY direto em produção?

👉 Pode…

👉 Mas também pode:

• quebrar sistema
• gerar incidente
• trabalhar de madrugada 😄

💡 Regra:

sempre APPLY CHECK + ambiente clone

---

🔁 4. O que faz o RESTORE?

👉 Volta para versão anterior usando DLIB

💡 Tradução:

botão “desfazer desastre”

---

🧩 5. O que é SYSMOD?

👉 Tudo que entra no SMP/E

Tipos:

• PTF → correção
• APAR → bug
• FUNCTION → produto
• USERMOD → custom

---

🧠 6. O que é CSI?

👉 Banco de dados do SMP/E

Guarda:

• o que está instalado
• histórico
• dependências

💀 Sem CSI:

você está cego

---

🧬 7. O que são FMID, RMID e UMID?

👉 Controle de versão real:

• FMID → origem
• RMID → última substituição
• UMID → updates

💡 SMP/E sabe mais do sistema do que você 😄

---

⚠️ 8. O que é HOLDDATA?

👉 Bloqueio de instalação

Tipos:

• ERROR
• SYSTEM
• USER

💥 Ignorar HOLD:

pedir problema

---

🔗 9. Por que o APPLY falha?

👉 90% dos casos:

• dependência (PRE/REQ)
• HOLDDATA
• zone errada
• FMID incorreto

---

🧠 10. O que é ++VER?

👉 A linha mais importante do SYSMOD

Define:

• onde instalar
• dependências
• compatibilidade

💡 Se der erro:

começa por aqui

---

🏗️ 11. O que é JCLIN?

👉 “manual de montagem” do load module

💡 Não executa… mas ensina o SMP/E

---

📦 12. Onde o SMP/E roda?

👉 Dentro do z/OS

Interfaces:

• ISPF (tela)
• JCL (produção)

❌ não é HMC

---

⚙️ 13. SMP/E automatiza manutenção?

👉 Sim (e deveria)

Com:

• REXX
• RECEIVE ORDER
• scripts

---

💣 14. Por que meu COBOL mudou comportamento?

👉 Possíveis causas:

• novo PTF
• alteração de load module
• mudança no runtime

💀 não foi seu código

---

🧠 15. Como evitar problemas com SMP/E?

👉 Checklist:

✔ APPLY CHECK
✔ validar dependências
✔ analisar HOLDDATA
✔ testar em clone
✔ só depois produção

---

🔥 BÔNUS — VERDADE FINAL

💀 “o erro raramente está no COBOL…
está no que mudou ao redor dele”

 

 

Bellacosa Mainframe em uma missao possivel troubleshooting smp/e

🔥💀 TROUBLESHOOTING SMP/E PARA PADAWAN

“Quando o APPLY falha… começa o seu treinamento”

---

🧠 REGRA Nº1 (GRAVA ISSO)

💣 SMP/E NÃO ERRA
💣 ELE TE AVISA — VOCÊ NÃO ENTENDEU A MENSAGEM

---

🔍 1. ONDE OLHAR PRIMEIRO?

Quando algo falhar:

👉 NÃO OLHE O JCL PRIMEIRO

Olhe:

• 📄 SMPLOG
• 📄 SMPOUT

💡 ali está a verdade

---

⚠️ 2. ERRO MAIS COMUM — DEPENDÊNCIA

💥 Sintoma:

GIM35901E APPLY PROCESSING FAILED

👉 Causa:

• faltou PRE
• faltou REQ

---

🔥 Como resolver:

👉 use:

APPLY CHECK

👉 ou:

LIST SYSMODS

💡 descubra o que está faltando

---

🧩 3. HOLD DATA (PEGADINHA CLÁSSICA)

💥 Sintoma:

SYSMOD HELD

👉 Tradução:

“não instala isso ainda, jovem padawan”

---

🔥 Solução:

• verificar HOLDDATA
• ou usar (com cuidado 😈):

BYPASS(HOLDERR,HOLDSYS)

💡 nunca faça isso sem saber o impacto

---

💀 4. ZONE ERRADA (ERRO DE INICIANTE)

💥 Sintoma:

• nada acontece
• ou erro estranho

👉 Causa:

SET BDY errado

---

🔥 Correto:

GLOBAL → RECEIVE
TARGET → APPLY
DLIB   → ACCEPT

---

🧨 5. CSI INCONSISTENTE

💥 Sintoma:

• erro sem sentido
• comportamento estranho

👉 Causa:

• CSI fora de sincronia

---

🔥 Solução:

• revisar zones
• rodar REPORT
• validar histórico

---

⚙️ 6. ELEMENTO NÃO ENCONTRADO

💥 Sintoma:

ELEMENT NOT FOUND

👉 Causa:

• FMID errado
• elemento não pertence àquela zone

---

🔥 Solução:

👉 verificar:

++VER FMID(...)

---

🔁 7. QUANDO TUDO DER ERRADO

👉 use o poder supremo:

RESTORE

💥 volta versão estável da DLIB

---

🧠 CHECKLIST DE SOBREVIVÊNCIA

Antes de APPLY:

✔ RECEIVE ok
✔ APPLY CHECK rodado
✔ dependências resolvidas
✔ HOLDDATA analisado
✔ zone correta

---

⚠️ EASTER EGG (REALIDADE)

💣 “funcionava ontem”

👉 ontem não tinha APPLY 😄

---

🧠 DICA DE OURO

Sempre pergunte:

teve mudança de smp/e?

antes de:

debugar cobol

---

🔥 FRASE FINAL

💀 “o erro não está no código…
está no nível do sistema”

 

Bellacosa Mainframe apresenta smp/e sysmod packaging

SMP/E na prática – SYSMOD Packaging sem medo

---

🧠 Introdução – SMP/E não é bicho‑papão

Quem trabalha com z/OS cedo ou tarde se depara com ele: SMP/E. Para alguns, um monstro antigo. Para outros, um mal necessário. A verdade é simples:

SMP/E é só método, disciplina e leitura correta das MCS.

Neste post vamos direto ao ponto: SYSMOD Packaging, ou seja, como os produtos, correções e USERMODs são empacotados, entregues e entendidos pelo SMP/E.

Sem marketing. Sem misticismo. Só mainframe raiz.

---

📦 O que é um SYSMOD de verdade?

Todo SYSMOD é composto por duas partes inseparáveis:

1. Conteúdo

   • módulos

   • macros

   • source

   • dados

   • HFS / JAR

2. MCS – Modification Control Statements

   • instruções que dizem ao SMP/E como, onde e quando instalar

👉 Durante o RECEIVE, o SMP/E lê primeiro as MCS, cria as MCS entries e armazena tudo no SMPPTS.

Se as MCS estiverem erradas… não há santo que salve o APPLY.

---

🧾 Regras de ouro das MCS (decore isso)

• Todas começam com ++

• Colunas 1–2 obrigatórias

• Terminam com ponto final (.)

• Continuação de linha só se não houver ponto antes da coluna 73

• Colunas 73–80 são ignoradas

📌 Erro clássico: esquecer o ponto final. Resultado? SMP/E surtando.

---

🪪 HEADER – identidade do SYSMOD

Toda SYSMOD começa com:

++HEADER

É aqui que o SMP/E descobre:

• o tipo do SYSMOD

• o SYSMOD‑ID

Tipos clássicos

• FUNCTION – produto base

• PTF – correção testada

• APAR – correção de problema

• USERMOD – correção local

Sem HEADER correto, não existe SYSMOD.

---

🧬 FMID – quem é o dono do código

O FMID (Function Modification ID):

• tem 7 caracteres

• identifica qual função é dona do elemento

• aparece normalmente no ++VER

📌 Em FUNCTION SYSMOD, o FMID é o próprio SYSMOD‑ID.

Erro comum em prova e produção: FMID errado = APPLY recusado.

---

🔗 ++VER – o cérebro do SMP/E

O ++VER é obrigatório e define:

• releases suportados

• pré‑requisitos

• co‑requisitos

• supersedes

Principais operandos:

• SREL – release do sistema

• FMID – função dona

• PRE – pré‑requisito

• REQ – co‑requisito

• SUP – supersede

👉 Sem ++VER, o SMP/E não confia em você.

---

🚦 ++HOLD – bloqueios controlados

Existem três HOLDs clássicos:

• ERROR – correção com problema

• SYSTEM – ação manual necessária

• USER – regra local

O HOLD pode vir:

• dentro do SYSMOD

• ou separado em HOLDDATA

📌 HOLD não é erro. HOLD é controle.

---

🏗️ ++JCLIN – a planta da casa

O ++JCLIN descreve:

• como o load module deve ser montado

• quais objetos entram

• qual link‑edit será usado

⚠️ JCLIN não executa JCL.

Ele apenas documenta a estrutura, permitindo RESTORE e rebuild corretos.

Sem JCLIN, o SMP/E fica cego.

---

🧩 MCS de elementos – o que realmente instala

Alguns exemplos:

• ++MOD – módulo

• ++SRC – source

• ++MAC – macro

• ++DATA – dados

• ++HFS – arquivo Unix

• ++JAR – JAR inteiro

• ++JARUPD – update parcial

• ++ZAP – patch binário

📌 ZAP e UPD alteram partes. DATA e HFS sempre substituem tudo.

---

☕ JAR no SMP/E (onde muita gente erra)

• ++JAR → substituição total

• ++JARUPD → update parcial

O SMP/E usa comandos do JDK para manipular o conteúdo.

Sim, Java também é mainframe.

---

📦 Técnicas de empacotamento SYSMOD

1️⃣ Relative File (tape)

• clássico IBM

• MCS em um arquivo

• elementos em arquivos seguintes

• usa RELFILE

Muito comum em FUNCTION SYSMOD.

---

2️⃣ Inline

• MCS e conteúdo juntos

• registros fixos de 80 bytes

• simples e direto

⚠️ Dados variáveis exigem GIMDTS.

---

3️⃣ Indirect Library

• MCS no SMPPTS

• conteúdo fora (PDS indicado no APPLY)

• comum em USERMOD

Flexível e perigoso se mal documentado.

---

4️⃣ GIMZIP Archive (Shopz / Internet)

• entrega moderna

• tudo compactado

• inclui MCS, conteúdo e HOLDDATA

Base do RECEIVE FROMNETWORK.

---

❌ Pegadinhas clássicas (anota aí)

• ++MOD não é o último MCS

• Inline com RELFILE

• FMID inexistente

• SREL inválido

• falta de ponto final

👉 Todas já derrubaram produção algum dia.

---

🧠 Conclusão – SMP/E é método

RECEIVE entende
APPLY constrói
ACCEPT congela

Quando você entende SYSMOD Packaging, o SMP/E deixa de ser mistério e vira aliado.

Mainframe não é velho.
Velho é não saber o que está rodando.

---

💾 Até o próximo post. Porque mainframe bom é mainframe bem documentado.

📦 SMP/E for z/OS – SYSMOD Packaging

Bellacosa Mainframe apresenta smp/e sysmod packaging

📦 SMP/E for z/OS – SYSMOD Packaging

Entendendo MCS e técnicas de empacotamento sem dor de cabeça

---

🧠 Ideia central (em uma frase)

SYSMOD = conteúdo + instruções (MCS)
O como, onde e quando instalar é decidido pelas MCS.

---

🧩 O que existe dentro de um SYSMOD?

Todo SYSMOD tem duas coisas:

1. Texto de modificação

   • módulos

   • macros

   • source

   • dados

   • HFS / JAR

2. MCS – Modification Control Statements

   • instruções para o SMP/E

   • dizem onde, quando e em que ordem instalar

📌 Durante o RECEIVE, o SMP/E:

• lê primeiro as MCS

• grava tudo no SMPPTS

• cada SYSMOD vira uma MCS entry

---

🧱 Tipos de elementos em DLIB / TLIB

Tipo	O que é
Module	Código compilado/ligado
Macro	Fonte reutilizável
Source	Código fonte
Data	CLIST, PARM, PROC etc
HFS	Arquivos Unix
JAR	Java Archive

---

🧾 Regras básicas das MCS (cai em prova)

• Todas começam com ++

• Colunas 1–2 → ++

• Terminam com ponto (.)

• Podem continuar linha se não houver ponto antes da coluna 73

• Colunas 73–80 são ignoradas

---

🪪 HEADER e identificação do SYSMOD

++HEADER

• identifica o tipo do SYSMOD

• define o SYSMOD-ID

Tipos de SYSMOD

Tipo	Para quê
FUNCTION	Introduz produto
PTF	Correção testada
APAR	Correção de problema
USERMOD	Correção local

---

🧬 FMID — quem “é dono” do código

• FMID = Function Modification ID

• 7 caracteres

• identifica a função dona do elemento

• em FUNCTION, o FMID é o próprio SYSMOD-ID

📌 Todo SYSMOD exceto base FUNCTION usa FMID no ++VER.

---

🔗 ++VER — relacionamento e dependências

O ++VER é o cérebro da compatibilidade

Regras:

• Obrigatório

• Deve vir logo após o HEADER

• Define:

  • release suportado (SREL)

  • dependências

  • pré-requisitos

  • co-requisitos

  • supersedes

Operandos importantes

Operando	Função
SREL	Release do sistema
FMID	Função dona
PRE	Pré-requisito
REQ	Co-requisito
SUP	Supersede

---

🚦 ++HOLD — bloqueios controlados

Existem 3 tipos:

Tipo	Quando usar
ERROR	PTF com erro
SYSTEM	Ação manual necessária
USER	Regra local

📌 HOLD impede APPLY/ACCEPT até ser resolvido
📌 Pode vir no SYSMOD ou em HOLDDATA separado

---

🏗️ MCS estruturais – como o sistema é montado

++JCLIN

• descreve como o load module é ligado

• não executa, apenas é analisado

• grava estrutura no TZONE

Sem JCLIN → SMP/E não sabe reconstruir load modules.

---

🧩 MCS de elemento (o que será instalado)

MCS	O que instala
++MOD	Módulo
++SRC	Source
++MAC	Macro
++DATA	Dados
++HFS	Arquivo Unix
++JAR	JAR inteiro
++ZAP	Patch binário
++SRCUPD	Update de source
++MACUPD	Update de macro
++JARUPD	Update parcial de JAR

📌 ZAP / UPD = alteração parcial
📌 DATA / HFS = sempre substituição total

---

☕ JAR no SMP/E (pegadinha comum)

• ++JAR → substitui o JAR inteiro

• ++JARUPD → atualiza arquivos internos

• SMP/E usa comandos do JDK (jar x / jar u)

---

📦 Técnicas de empacotamento SYSMOD

Como o conteúdo chega até o SMP/E

1️⃣ Relative File (tape)

📼 Clássico IBM

• MCS em um arquivo

• elementos em arquivos seguintes

• usa RELFILE

✔️ Muito usado em FUNCTION SYSMOD

---

2️⃣ Inline

📄 Tudo junto

• MCS + conteúdo no mesmo arquivo

• registros fixos de 80 bytes

• simples, direto

⚠️ Dados variáveis precisam de GIMDTS

---

3️⃣ Indirect Library

📚 USERMOD raiz

• MCS no SMPPTS

• conteúdo fica fora (PDS indicado no APPLY)

• usa TXLIB, LKLIB

✔️ Ideal para USERMOD

---

4️⃣ GIMZIP Archive

🌐 Moderno / rede

• arquivo compactado no HFS

• inclui:

  • MCS

  • elementos

  • HOLDDATA

• usa:

  • GIMZIP

  • GIMUNZIP

  • RECEIVE FROMNETWORK

✔️ Base do Shopz / Internet delivery

---

❌ “What’s wrong with this picture?” (clássico de prova)

Erros comuns:

1. ++MOD não é o último MCS

2. Inline com RELFILE

3. FMID ausente

4. Falta ponto final

5. SREL inválido (2038 ≠ Z038)

---

🧠 Resumo final (para memorizar)

🔑 RECEIVE lê MCS
🔑 APPLY instala no target
🔑 ACCEPT congela no DLIB
🔑 ++VER controla dependências
🔑 JCLIN explica como montar
🔑 Packaging define onde está o conteúdo

 

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)

 

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.

📘💾🛡️🔥