🧙‍♂️ REXX em Modo Jedi Avançado

Quando o script deixa de ser código e vira governo do sistema

“Todo mundo escreve REXX.
Poucos entendem o que realmente estão controlando.”

---

☕ Introdução – REXX não é uma linguagem, é uma posição de poder

No mundo distribuído, scripts automatizam tarefas.
No mainframe, REXX governa fluxos.

REXX não nasceu para competir com COBOL, PL/I ou Python.
Ele nasceu para orquestrar, colar, conectar e, quando mal usado, derrubar produção em silêncio.

Entrar no modo Jedi do REXX significa entender que:

Você não escreve REXX para resolver problemas.
Você escreve REXX para controlar o sistema que resolve problemas.

---

🧠 Capítulo 1 – ADDRESS: o sabre de luz do REXX

Se você só usa ADDRESS TSO, você ainda é um Padawan.

O verdadeiro poder começa quando você entende que ADDRESS é um roteador de autoridade:

• ADDRESS TSO → usuário

• ADDRESS ISPEXEC → interface

• ADDRESS SDSF → JES

• ADDRESS CONSOLE → operador

• ADDRESS OPERCMDS → sistema

• ADDRESS LINK / LINKMVS / LINKPGM → MVS puro

🧩 Insight Jedi

ADDRESS define quem executa.
REXX apenas decide quando.

No modo Jedi, o REXX não executa — ele coordena entidades que têm poder real.

---

📦 Capítulo 2 – Data Stack: o lado invisível da Força

Todo REXX poderoso depende do Data Stack.
Quem não domina a stack, não domina REXX.

O Data Stack é:

• STDIN/STDOUT do mainframe

• Pipe de comunicação invisível

• Fonte de 80% dos bugs silenciosos

Jedi sabe:

• Quando usar PUSH (LIFO)

• Quando usar QUEUE (FIFO)

• Quando isolar com NEWSTACK

• Quando limpar antes de sair

Stack suja = decisão errada baseada em lixo.

---

🛡️ Capítulo 3 – SYSREXX: quando o script vira operador invisível

SYSREXX não é um nome bonito.
É uma categoria mental.

SYSREXX é:

• REXX que roda sem você

• REXX que toma decisões

• REXX que opera produção

Ele normalmente envolve:

• Batch

• SDSF

• GETMSG

• CART

• OPERCMDS

• CONSOLE

Verdade desconfortável

SYSREXX mal governado é mais perigoso que operador humano.

Operador erra uma vez.
SYSREXX erra toda vez, automaticamente.

---

🔐 Capítulo 4 – OPERCMDS: o Dark Side do REXX

OPERCMDS é o ponto onde engenharia vira ética.

Quem usa OPERCMDS sem checklist:

• Não está automatizando

• Está delegando autoridade sem supervisão

Regras Jedi absolutas

• OPERCMDS sem log é proibido

• OPERCMDS sem GETMSG é irresponsável

• OPERCMDS em loop é incidente garantido

• OPERCMDS sem RACF é suicídio institucional

Não é sobre conseguir executar o comando.
É sobre merecer executar o comando.

---

🔗 Capítulo 5 – LINK / LINKMVS / LINKPGM: REXX como maestro

Aqui o REXX para de ser script e vira maestro de orquestra.

• COBOL executa regra

• ASM executa velocidade

• Utilities executam trabalho pesado

• REXX coordena tudo

No modo Jedi:

• REXX não faz I/O pesado

• REXX não replica lógica de negócio

• REXX chama quem sabe fazer melhor

REXX não substitui COBOL.
REXX governa COBOL.

---

🧪 Capítulo 6 – Checklists: a diferença entre mestre e herói morto

Padawans confiam no código.
Jedis confiam em processo.

Checklist não é burocracia.
Checklist é memória externa para evitar arrogância técnica.

Checklist Jedi inclui:

• Segurança RACF

• Data Stack limpa

• RC validado

• Mensagem interpretada

• Log auditável

• Rollback possível

REXX sem checklist é talento desperdiçado.

---

⚖️ Capítulo 7 – REXX vs Shell vs Python: maturidade arquitetural

O Jedi não briga por linguagem.

Ele sabe que:

• REXX governa o core

• Shell conecta ao Unix

• Python conecta ao futuro

A arquitetura madura combina, não substitui.

Trocar REXX por Python no core do z/OS não é modernização.
É amnésia técnica.

---

🧠 Capítulo 8 – A mentalidade Jedi REXX

Um Jedi REXX:

• Pensa em risco antes de pensar em sintaxe

• Prefere previsibilidade a elegância

• Documenta o óbvio

• Desconfia de RC=0

• Nunca confia em automação sem auditoria

Frase final (para colar na parede do data center):

REXX não é uma linguagem de programação.
É uma linguagem de responsabilidade.

---

☕ Epílogo – Um Café no Bellacosa Mainframe

O REXX Jedi não aparece no LinkedIn dizendo que “automatizou tudo”.
Ele aparece quando nada quebrou.

E no mainframe, isso é o maior elogio possível.

 

🔐 Guia de Segurança – OPERCMDS em REXX Mainframe

OPERCMDS não é automação.
OPERCMDS é autoridade delegada de operador.

---

1️⃣ O que é OPERCMDS (sem romantizar)

OPERCMDS permite que um REXX envie comandos de operador MVS/JES como se estivesse no console do sistema.

Exemplos do que isso significa na prática:

• Cancelar jobs

• Parar subsistemas

• Exibir status do sistema

• Interferir diretamente na produção

📌 Conclusão:
Quem controla OPERCMDS, controla o sistema.

---

2️⃣ Princípio Zero: quando NÃO usar OPERCMDS

❌ Não use OPERCMDS se:

• O comando pode ser feito via SDSF read-only

• É apenas consulta de status

• É um script de usuário final

• Não existe logging/auditoria

👉 OPERCMDS só entra quando não há alternativa segura.

---

3️⃣ Pré-requisitos obrigatórios de segurança

Antes de QUALQUER ADDRESS OPERCMDS:

• Autorização formal da área de segurança

• Perfil RACF específico (não genérico)

• Execução restrita (SYSREXX / batch controlado)

• Script armazenado em library protegida

• Alteração via change management

🧠 OPERCMDS sem RACF é uma bomba-relógio.

---

4️⃣ Classificação de comandos OPERCMDS

🟢 Classe 1 – Consulta (menor risco)

Exemplos:

• D A

• D J,L

• D OMVS

Regras:

• Preferir leitura

• Log obrigatório

• Nunca usar como gatilho de ação direta

---

🟡 Classe 2 – Controle (alto risco)

Exemplos:

• CANCEL jobname

• P subsystem

• S subsystem

Regras:

• Só em SYSREXX

• Validação prévia obrigatória

• RC + mensagem analisados

• Execução única (sem loop)

---

🔴 Classe 3 – Impacto sistêmico (crítico)

Exemplos:

• Z EOD

• VARY

• FORCE

📌 Regra absoluta:
REXX NÃO deve executar esses comandos automaticamente.

---

5️⃣ Checklist técnico antes do comando

Antes de executar OPERCMDS:

• O comando foi validado?

• Existe confirmação lógica (não humana)?

• O ambiente é o correto (LPAR, sistema)?

• O job alvo realmente existe?

• O comando é idempotente?

• Existe timeout / proteção contra loop?

---

6️⃣ Captura e validação de mensagens (obrigatório)

Nunca execute OPERCMDS “cego”.

Fluxo correto:

1. Executar comando

2. Capturar mensagem

3. Interpretar resposta

4. Só então decidir próxima ação

Ferramentas:

• GETMSG

• CART

• Data Stack

📌 OPERCMDS sem GETMSG é irresponsável.

---

7️⃣ Tratamento de RC e mensagens

• RC analisado imediatamente

• Mensagem validada (texto, não só RC)

• Erro gera abort controlado

• Sucesso gera log explícito

• Nenhum “continue anyway”

🥚 RC = 0 não significa sucesso operacional.

---

8️⃣ Logs e Auditoria (não negociável)

Todo OPERCMDS deve gerar:

• Quem executou

• Quando executou

• Qual comando

• Qual retorno

• Qual decisão foi tomada

Regras:

• Log em dataset protegido

• SYSOUT identificado

• Retenção definida

🧠 Sem log, não há defesa em auditoria.

---

9️⃣ Proteções obrigatórias no código

• Nunca hardcode jobnames críticos

• Nunca aceitar input direto do usuário

• Nunca rodar em loop sem limite

• Nunca executar em ambiente errado

• Nunca assumir sucesso

📌 REXX é rápido — erros também.

---

🔟 OPERCMDS em Batch vs TSO

Ambiente	Recomendação
TSO interativo	❌ Evitar
ISPF	⚠️ Só leitura
Batch controlado	✅ Recomendado
SYSREXX	✅ Ideal

---

1️⃣1️⃣ Governança e Versionamento

• Header com aviso de risco

• Versão explícita

• Responsável técnico

• Revisão periódica

• Aprovação da operação

---

1️⃣2️⃣ Frases que salvam produção

❝ OPERCMDS não falha — pessoas falham ❞
❝ Automação sem controle é incidente futuro ❞
❝ Se pode derrubar o sistema, precisa de checklist ❞

---

🧠 Conclusão – mentalidade correta

OPERCMDS não é para mostrar poder técnico.
É para reduzir risco operacional com disciplina.

 

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.

📘💾🛡️🔥

 

Bellacosa Mainframe apresenta Auditoria no IBM SMP/E

📋 Checklist de Auditoria SMP/E

O que o auditor pergunta (e o que você precisa provar)

“Auditor não quer opinião.
Quer evidência.”

---

🧠 Objetivo do checklist

Garantir que:

• O z/OS está íntegro

• A manutenção é controlada

• As mudanças são rastreáveis

• O ambiente é auditável

👉 SMP/E é prova técnica, não discurso.

---

🔐 1. Controle de Acesso (RACF / ACF2 / TSS)

✔ CSI protegido (UACC=NONE)
✔ ALTER restrito a sysprogs autorizados
✔ READ para auditoria
✔ Logging ativo
✔ Revisão periódica de acessos

📌 Evidência:

• LISTDSD

• Relatórios RACF

• Perfis ativos

---

📦 2. Proteção das bibliotecas SMP/E

✔ TARGET libraries protegidas
✔ DLIB libraries protegidas
✔ SMPTLIB, SMPMTS, SMPPTS controlados
✔ Separação TEST / PROD

📌 Evidência:

• RACF profiles

• Dataset attributes

---

🔁 3. Processo RECEIVE / APPLY / ACCEPT

✔ RECEIVE documentado
✔ APPLY CHECK executado
✔ APPLY validado em teste
✔ ACCEPT autorizado formalmente

📌 Evidência:

• Outputs SMP/E

• JCL versionado

• Change records

---

🚨 4. Gestão de ++HOLD e ++ERROR

✔ HOLDS analisados
✔ Decisão documentada
✔ ERROR tratados com cautela
✔ Mitigações registradas

📌 Evidência:

• PTF cover letters

• APARs

• Decisões de risco

---

🧩 5. Gestão de USERMOD

✔ USERMOD documentado
✔ Justificativa formal
✔ Controle de APPLY/ACCEPT
✔ Revisão periódica

📌 Evidência:

• SYSMOD history

• Documentação técnica

---

🧪 6. APPLY CHECK (obrigatório)

✔ APPLY CHECK sempre executado
✔ Resultados arquivados
✔ Conflitos analisados

📌 Evidência:

• Output APPLY CHECK

• Aprovação formal

---

🧱 7. Controle de DLIB (baseline)

✔ DLIB atualizado
✔ ACCEPT consciente
✔ Baseline consistente
✔ DLIB protegido

📌 Evidência:

• CSI

• Relatórios SMP/E

---

🔄 8. Capacidade de RESTORE

✔ Processo definido
✔ Histórico preservado
✔ Testes de rollback
✔ Documentação clara

📌 Evidência:

• JCL RESTORE

• Registros históricos

---

🧠 9. Atualização e Segurança

✔ PTFs de segurança aplicados
✔ CVEs avaliados
✔ Backlog controlado
✔ Plano de atualização

📌 Evidência:

• Relatórios IBM

• Histórico SMP/E

---

🧾 10. Evidências e documentação

✔ Outputs armazenados
✔ Logs disponíveis
✔ Histórico preservado
✔ Responsáveis identificados

📌 Evidência:

• CSI

• JCL

• Relatórios

---

🚨 Red flags para auditor

❌ ALTER irrestrito
❌ ACCEPT sem teste
❌ USERMOD esquecido
❌ CSI sem proteção
❌ Falta de APPLY CHECK

👉 Tudo isso gera não conformidade.

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• SMP/E é trilha de auditoria nativa

• Segurança começa no controle de mudança

---

🧾 Comentário final – Checklist SMP/E

Quem tem SMP/E bem cuidado
não teme auditoria.

📋 Checklist de Auditoria SMP/E, no estilo Bellacosa Mainframe, pensado para auditoria interna, externa, SOX, PCI, ISO, ou simplesmente para dormir tranquilo. 

📋💾🛡️

 

Bellacosa Mainframe apresenta IBM SMP/E

🧩 SMP/E + RACF na prática

Onde manutenção encontra segurança (e o auditor sorri)

“Não adianta proteger usuário se qualquer um pode mudar o sistema.”

---

🧠 Por que SMP/E precisa de RACF?

SMP/E controla o código do z/OS.
RACF controla quem pode tocar nesse código.

👉 Separados, são fortes.
👉 Juntos, são governança.

---

🔐 O que exatamente deve ser protegido?

🎯 Alvos críticos

• CSI (Consolidated Software Inventory)

• SMP/E libraries

• Datasets TARGET e DLIB

• JCL de manutenção

• Procedimentos de APPLY/ACCEPT

📌 Quem altera isso altera o sistema inteiro.

---

🧩 Princípio da menor permissão

Não existe:

“Acesso total para facilitar.”

Existe:

• Acesso mínimo

• Temporário

• Auditável

---

🧾 Protegendo o CSI

Recomendação clássica

• DATASET profile no RACF

• UACC=NONE

• ALTER só para sysprog autorizado

• READ para auditoria

📌 CSI é prova histórica.

---

🛡️ Protegendo bibliotecas SMP/E

• SMPTLIB

• SMPMTS

• SMPPTS

• SMPSCDS

👉 Controle separado de produção e teste.

💡 Dica Bellacosa:

“Quem pode escrever no SMPMTS pode quebrar o sistema.”

---

👥 Segregação de funções (SOX friendly)

Função	Permissão
Sysprog	APPLY
Change Mgmt	Aprovar
Auditor	READ
Operação	Executar JCL controlado

📌 Uma pessoa não deve fazer tudo.

---

🔎 Auditoria e rastreabilidade

Auditor pergunta:

• Quem aplicou?

• Quando?

• O quê?

• Por quê?

👉 SMP/E responde
👉 RACF confirma

---

🧪 APPLY CHECK como controle

• APPLY CHECK obrigatório

• Output guardado

• Assinatura de mudança

💡 Dica Bellacosa:

“APPLY CHECK é evidência de controle.”

---

🚨 Cenário de risco real

Sysprog com ALTER irrestrito
USERMOD sem controle
ACCEPT em produção
Auditor encontra

📌 Resultado:

• Não conformidade

• Risco operacional

• Stress garantido

---

🛠️ Boas práticas recomendadas

✔ Perfis RACF específicos
✔ Logging ativo
✔ Revisão periódica
✔ Separação TEST/PROD
✔ Documentação SMP/E

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• RACF mal configurado invalida SMP/E

• Segurança começa no dataset

---

🧾 Comentário final – SMP/E + RACF

RACF protege acesso.
SMP/E protege integridade.
Juntos, protegem o negócio.

🧩🛡️💾🔥

🧩SMP/E: USERMOD na prática

 

Bellacosa Mainframe apresenta IBM SMP/E

🧩 USERMOD na prática

Poder absoluto nas mãos erradas (ou a salvação do sysprog)

“USERMOD é liberdade.
USERMOD sem controle é tragédia.”

---

🧠 O que é USERMOD (sem romantizar)

USERMOD é um SYSMOD criado pelo próprio cliente, não pela IBM.

Ele permite:

• Ajustes locais

• Correções temporárias

• Customizações específicas

• Patches emergenciais

👉 Em Bellacosa claro:

USERMOD é mexer no z/OS sem a IBM te segurar a mão.

---

🕰️ Origem do USERMOD

USERMOD nasceu da necessidade real:

• A IBM não entrega tudo pronto

• Ambientes são únicos

• Nem toda correção pode esperar um PTF oficial

📌 Mas a IBM sempre deixou claro:

USERMOD é por sua conta e risco.

---

🧩 Quando USERMOD faz sentido

✔ Ajuste emergencial
✔ Correção temporária
✔ Customização local
✔ Teste de solução
✔ Mitigação até PTF oficial

❌ Substituir manutenção IBM
❌ “Resolver rápido” sem documentação
❌ Correção definitiva

---

⚠️ Riscos reais do USERMOD

• Conflito com PTF futuro

• Perda de suporte IBM

• Dificuldade em upgrades

• Dependências invisíveis

• Esquecimento (o pior de todos)

👉 USERMOD mal documentado vira fantasma.

---

🧠 USERMOD e SMP/E

USERMOD:

• É tratado como SYSMOD

• Tem MCS

• Usa RECEIVE/APPLY/ACCEPT

• Entra no CSI

📌 Se não está no SMP/E, não existe.

---

🧾 Estrutura básica de um USERMOD

Exemplo simples

++USERMOD(UM0001).
++VER(Z038) FMID(HJES770).
++MOD(JES2MOD).

👉 Tradução:

• USERMOD UM0001

• Para JES2

• Modificando módulo específico

---

🔎 Boas práticas de MCS em USERMOD

Sempre usar:

• ++VER → versão correta

• ++IF → controle condicional

• ++HOLD → alertar risco

• Comentários claros

💡 Dica Bellacosa:

“USERMOD sem ++VER é roleta russa.”

---

🧪 APPLY CHECK é obrigatório

Nunca aplique USERMOD direto:

APPLY CHECK.

Avalie:

• Impacto

• Conflitos

• Pré-requisitos

• PTFs existentes

---

🔄 USERMOD x PTF futuro

Quando um PTF oficial sai:

• Ele pode sobrescrever o USERMOD

• Ele pode falhar por causa do USERMOD

• Ele pode exigir remoção do USERMOD

📌 Processo saudável:

1. Identificar USERMOD afetado

2. RESTORE USERMOD

3. APPLY PTF

4. Descartar USERMOD

---

📦 ACCEPT de USERMOD: pense duas vezes

❗ ACCEPT de USERMOD é perigoso.

Só faça se:

• For permanente

• For bem documentado

• For aprovado formalmente

👉 ACCEPT grava na história.

---

🧠 Caso real (Bellacosa clássico)

USERMOD criado em 2014
Ninguém lembra por quê
Upgrade falha em 2025
PTF não aplica

📌 Moral:

USERMOD esquecido custa caro.

---

🎓 Como aprender USERMOD com segurança

• Estudar MCS

• Praticar em laboratório

• Simular conflito

• Ler Redbooks

• Usar SMP/E Workshop

---

🧠 Curiosidades Bellacosa

• USERMOD já salvou sistemas críticos

• USERMOD já derrubou produção

• USERMOD nunca deve ser invisível

---

🧾 Comentário final – USERMOD

USERMOD é bisturi, não martelo.
Use com precisão.
Documente tudo.

🧩💾🔥

🛡️ SMP/E e Segurança: Quando manutenção vira proteção (ou vulnerabilidade)

 

Bellacosa Mainframe apresenta IBM SMP/E

🛡️ SMP/E e Segurança

Quando manutenção vira proteção (ou vulnerabilidade)

“No mainframe, segurança não começa no RACF.
Começa no SMP/E.”

---

🧠 Por que SMP/E é parte da segurança?

SMP/E controla o que entra no sistema operacional.

Quem controla:

• Código

• Versões

• Dependências

• Histórico

…controla superfície de ataque.

👉 Um PTF não aplicado é uma brecha.
👉 Um PTF mal aplicado é um risco maior ainda.

---

🔓 O maior mito

❌ “Segurança é só RACF, ACF2 ou TopSecret.”

✅ Verdade:

• RACF protege acesso

• SMP/E protege integridade do código

📌 Sem SMP/E bem gerenciado:

• Módulos vulneráveis continuam rodando

• Correções críticas não entram

• Auditoria reprova

---

🚨 PTF de segurança: prioridade máxima

A IBM libera PTFs que:

• Corrigem falhas exploráveis

• Atendem compliance (PCI, SOX, LGPD)

• Eliminam vetores de ataque

Esses PTFs geralmente vêm com:

• ++HOLD(SECURITY)

• Texto explicativo detalhado

👉 Não aplicar é decisão de risco.

---

🔍 ++HOLD(SECURITY): leia com atenção

O que significa?

++HOLD(SECURITY)

Indica:

• Impacto direto em segurança

• Mudança de comportamento

• Possível quebra de compatibilidade

📌 Normalmente envolve:

• Autorização

• Criptografia

• Controle de acesso

• SMF / auditoria

---

Dica Bellacosa

Ignore um HOLD de segurança e o auditor vai encontrar.

---

🔥 ++ERROR e segurança

Um ++ERROR em PTF de segurança é crítico:

• Pode corrigir parcialmente a falha

• Pode introduzir outro risco

• Pode exigir mitigação adicional

👉 Decisão nunca é automática.

📌 Boas ações:

• Ler APAR

• Avaliar CVE

• Consultar IBM

• Planejar superseding PTF

---

🔐 Controle de acesso ao SMP/E

Quem deve ter acesso?

• System Programmers

• Pouquíssimas pessoas

• Com segregação clara

📌 Proteger:

• CSI datasets

• SMP/E libraries

• JCL de manutenção

---

Boas práticas de RACF

• UACC=NONE

• Acesso mínimo necessário

• LOG de alterações

• Perfis específicos para SMP/E

👉 Quem mexe no SMP/E mexe no sistema inteiro.

---

🧾 Auditoria e compliance

Auditores adoram perguntar:

• Quais PTFs estão aplicados?

• Quando?

• Por quem?

• Por quê?

👉 SMP/E responde tudo isso.

📌 CSI é prova documental.

---

🧪 APPLY CHECK como ferramenta de segurança

APPLY CHECK ajuda a:

• Identificar impacto

• Prever conflitos

• Avaliar risco antes da mudança

💡 Dica Bellacosa:

“APPLY CHECK é auditoria preventiva.”

---

🔄 Manutenção atrasada = risco ativo

• PTF antigo = CVE ativo

• Função obsoleta = ataque conhecido

• Versão desatualizada = não conformidade

👉 Segurança também é disciplina de manutenção.

---

🧠 Caso real (estilo Bellacosa)

Falha crítica corrigida por PTF
PTF não aplicado por medo de IPL
Exploração acontece
Auditor pergunta: “Por quê?”

📌 Resposta errada:

“Porque sempre funcionou assim.”

---

🎓 Como aprender SMP/E focado em segurança

• Ler PTFs de segurança

• Analisar HOLDS

• Estudar CVEs

• Participar de workshops

• Integrar SMP/E com gestão de risco

---

🧠 Curiosidades Bellacosa

• SMP/E já fazia secure supply chain antes do termo existir

• Código assinado é inútil se não for aplicado

• Auditor confia mais no CSI do que em planilha

---

🧾 Comentário final – SMP/E e Segurança

Segurança não é só impedir acesso.
É garantir que o código certo esteja rodando.

E isso…
👉 é trabalho do SMP/E.

🛡️💾🔥