Translate

Mostrar mensagens com a etiqueta Governança. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Governança. Mostrar todas as mensagens

terça-feira, 21 de abril de 2026

🔥 Quem Realmente Manda no Seu z/OS? — RACF vs TSS vs ACF2, a Guerra Silenciosa que Decide Tudo

 

Bellacosa Mainframe fala sobre segurança mainframe RACF TSS ACF2

🔥 Quem Realmente Manda no Seu z/OS? — RACF vs TSS vs ACF2, a Guerra Silenciosa que Decide Tudo

Se você trabalha com mainframe há tempo suficiente, já sabe:
o sistema pode ser o mais estável do mundo… mas quem decide o que acontece nele não é o z/OS — é o ESM.

E aí entra o trio que moldou décadas de segurança no mainframe:

  • IBM RACF
  • CA Top Secret (TSS)
  • CA ACF2

Três filosofias. Três formas de pensar segurança.
E, mais importante: três maneiras completamente diferentes de cometer erros — ou evitá-los.


🧠 Capítulo 1 — Origem: Quando Segurança Virou Necessidade (não luxo)

Volta para os anos 70/80.

Mainframe já processava:

  • bancos
  • governo
  • folha de pagamento
  • defesa

E aí veio a pergunta que mudou tudo:

“Quem pode acessar o quê?”

A resposta não era trivial — porque o z/OS (na época MVS) não nasceu com segurança robusta nativa.

🔵 RACF (IBM)

Criado pela própria IBM:

  • integração total com o sistema
  • modelo corporativo
  • foco em governança

👉 DNA:

segurança como parte da arquitetura


🟢 TSS (CA Top Secret)

Criado pela CA:

  • foco em simplicidade
  • modelo centrado no usuário

👉 DNA:

segurança como controle direto


🟣 ACF2

Também da CA:

  • abordagem radicalmente diferente
  • rule-based

👉 DNA:

segurança como linguagem


🧬 Capítulo 2 — O DNA de Cada Um

🔵 RACF — O Burocrata Organizado

RACF pensa assim:

Usuário → Grupo → Recurso → Permissão

Ele cria estrutura.

Exemplo real:

ADDUSER DEV01 DFLTGRP(DEV)
PERMIT PROD.APP.* CLASS(DATASET) ID(DEV01) ACCESS(READ)

👉 RACF gosta de:

  • hierarquia
  • governança
  • previsibilidade

🟢 TSS — O Operador Pragmático

TSS elimina intermediários:

ACID → Permissões

Exemplo:

TSS PERMIT(DEV01) DATASET(PROD.APP.*) ACCESS(READ)

👉 TSS gosta de:

  • simplicidade
  • rapidez
  • controle direto

🟣 ACF2 — O Hacker Formal

ACF2 inverte tudo:

Recurso → Regra → Usuário

Exemplo:

$KEY(PROD)
UID(DEV01) ALLOW

👉 ACF2 gosta de:

  • regras
  • lógica
  • flexibilidade extrema

⚔️ Capítulo 3 — A Diferença que Ninguém Te Conta

Aqui está o ponto que separa júnior de sênior:

Esses produtos não são equivalentes — eles são modelos mentais diferentes


🧠 RACF pensa em “organização”

Você define estrutura e depois controla acesso.


🧠 TSS pensa em “identidade”

Você dá poder direto ao usuário.


🧠 ACF2 pensa em “lógica”

Você escreve regras e deixa o sistema decidir.


🧨 Capítulo 4 — Onde os Projetos Quebram

Vamos direto ao campo de batalha.

🔥 Caso real 1 — Migração TSS → RACF

Problema:

  • TSS:

    DIVISION / DEPARTMENT
  • RACF:

    GROUP

👉 Não existe equivalência direta.

Resultado:

  • perda de contexto
  • decisões arquiteturais obrigatórias

🔥 Caso real 2 — ACF2 mal governado

ACF2 permite:

  • regras complexas
  • lógica condicional

👉 Sem controle vira:

“ninguém entende mais quem tem acesso a quê”


🔥 Caso real 3 — RACF mal configurado

Erro clássico:

UACC(READ)

👉 Tradução:

você abriu o dataset para meio mundo


🧠 Capítulo 5 — Como Eles Funcionam HOJE (2026)

🔵 RACF hoje

  • integrado ao z/OS
  • forte com ferramentas como:
    • auditoria
    • compliance
  • padrão de mercado

👉 Usado em:

  • bancos
  • governo
  • grandes corporações

🟢 TSS hoje

  • ainda muito presente
  • especialmente em ambientes antigos

👉 Problema:

  • escassez de profissionais
  • pressão de custo

🟣 ACF2 hoje

  • nicho forte
  • ambientes altamente customizados

👉 Perfil:

  • organizações com regras complexas

🧩 Capítulo 6 — Easter Eggs de Quem Já Viveu Isso

🥚 1. O mito do “ALL”

No TSS:

ACCESS(ALL)

👉 Pode significar mais do que você imagina…


🥚 2. O clássico “por que isso funcionava antes?”

Resposta:

porque estava no TSS… e ninguém sabia


🥚 3. O fantasma do dataset genérico

PROD.*

👉 Um único profile pode abrir acesso para centenas de datasets.


🥚 4. O usuário com SPECIAL no RACF

👉 Isso aqui é praticamente “root do mainframe”


🧠 Capítulo 7 — Comparação Brutal (sem filtro)

CritérioRACFTSSACF2
GovernançaAltaMédiaAlta
SimplicidadeMédiaAltaBaixa
FlexibilidadeAltaMédiaExtremamente alta
Risco operacionalMédioMédioAlto
Mercado atualDominanteCaindoNicho

💣 Capítulo 8 — A Verdade que Poucos Dizem

Não existe “melhor” absoluto.

Existe:

  • o mais adequado ao seu ambiente
  • o mais governável pela sua equipe
  • o menos arriscado para auditoria

🧠 Insight de arquiteto

Se você precisa:

  • padronização → RACF
  • simplicidade → TSS
  • controle extremo → ACF2

🔥 Conclusão — A Guerra Invisível

Enquanto todo mundo fala de:

  • cloud
  • APIs
  • microservices

No mainframe, a pergunta continua sendo a mesma há 40 anos:

“Quem pode fazer o quê?”

E a resposta continua dependendo de um desses três.


☕ Frase final estilo Bellacosa

“Você pode modernizar o COBOL, migrar para APIs, colocar z/OS Connect…
mas se errar no RACF, TSS ou ACF2 — nada disso importa.”

 

sábado, 25 de fevereiro de 2023

🔥 SMP/E Não Instala Software — Ele Decide se o Seu Sistema Vive ou Morre

 

Bellacosa Mainframe apresenta o software com poder de vida e morte no Mainframe SMP/E

🔥 SMP/E Não Instala Software — Ele Decide se o Seu Sistema Vive ou Morre

Se você é um dev COBOL sênior, deixa eu te provocar logo de cara:

Você confia no seu programa…
mas você confia no ambiente onde ele roda?

Porque no mundo do z/OS, não é o COBOL que quebra primeiro.

👉 É o ecossistema invisível que o SMP/E controla.


☕ A História que Ninguém Te Conta

Antes do SMP/E, instalar software no mainframe era quase artesanal:

  • Fita magnética 📼
  • JCL manual
  • Catálogo na mão
  • E muita… muita reza

Quando a IBM criou o SMP/E, a ideia não era só instalar software.

Era algo muito maior:

Criar um sistema de governança de software


🧠 O Que é SMP/E (de verdade)

Esquece a definição de manual.

👉 SMP/E é:

  • Inventário vivo do sistema
  • Motor de instalação
  • Mecanismo de auditoria
  • Sistema de dependência

💡 Tradução Bellacosa:

É o Git + Maven + Kubernetes do mainframe… só que criado décadas antes.


🧱 Como o Sistema é Construído (e você provavelmente nunca viu assim)

O SMP/E enxerga o mundo em camadas:

SOURCE → MACRO → MODULE → LOAD MODULE → LIBRARY

👉 E aí vem o pulo do gato:

  • Seu programa COBOL → vira MODULE
  • Vários MODULEs → viram LMOD
  • LMOD → roda no sistema

💥 Se UMA peça estiver errada…

Seu programa perfeito vira erro em produção


🔥 APPLY — O Comando Mais Perigoso do Seu Ambiente

Todo mundo já rodou:

APPLY PTFS(...)

E pensou:

“RC=0… sucesso!”

😈 Aqui está o problema:

  • Dependência pode estar faltando
  • HOLD pode estar ignorado
  • Outra zona pode quebrar

👉 E o erro?

Vai aparecer depois… no seu COBOL


🧠 Easter Egg (nível produção)

O APPLY não instala software…
ele muda o estado do sistema inteiro


🔍 LIST vs REPORT — O Momento em que você vira adulto no SMP/E

LIST

  • Mostra dados
  • Não pensa

👉 Tipo um dump bonito


REPORT

  • Analisa
  • Detecta problema
  • Sugere ação

💡 Tradução:

LIST responde
REPORT decide


💥 Exemplo real

Você roda:

REPORT CROSSZONE

E descobre:

  • Dependência faltando
  • Outro produto impactado

👉 Antes do APPLY

💥 Resultado:

Você evitou um incidente


🔗 LINK MODULE — A Cirurgia que Salva Madrugada

Cenário clássico:

  • Programa chama módulo
  • Módulo não está no LMOD

💣 Resultado:

  • Abend
  • Erro estranho
  • Chamado urgente

💡 Solução:

LINK MODULE(...)

👉 O SMP/E:

  • Busca módulos em outra zona
  • Reconstrói o executável

💥 Sem reinstalar nada


😈 Easter Egg

Isso resolve rápido…
mas cria dependência (TIEDTO)

👉 Você resolveu hoje… e criou um problema silencioso amanhã


🏗️ BUILDMCS — O Superpoder Escondido

Pouca gente usa. Pouca gente entende.

👉 Mas isso aqui é ouro:

BUILDMCS FORFMID(...)

O que ele faz?

  • Pega um ambiente instalado
  • Gera um SYSMOD completo
  • Permite reinstalar tudo

💡 Analogia moderna

BUILDMCS é o “docker commit” do mainframe


📖 Caso real

  • Sistema com USERMOD crítico
  • Sem documentação
  • Sem backup lógico

👉 Solução?

BUILDMCS

💥 Ambiente salvo


⚠️ O Lado Sombrio

Se você tiver:

  • Shared LMOD
  • Elementos comuns

👉 BUILDMCS pode gerar inconsistência


🌐 SMP/E Moderno — Ele Já Virou DevOps

Hoje você não precisa mais:

  • Fita
  • PSP manual
  • Caçar PTF

🚀 RECEIVE ORDER

RECEIVE ORDER

👉 SMP/E:

  • Pede manutenção
  • Baixa
  • Organiza

🧠 FIXCAT

O SMP/E escolhe o que você precisa instalar


🔄 Pipeline moderno

ORDER → RECEIVE → APPLY → ACCEPT

💡 Isso é CI/CD… no mainframe


🔥 Exemplo Real (nível enterprise)

Upgrade de ambiente:

  1. RECEIVE HOLDDATA
  2. REPORT MISSINGFIX
  3. APPLY FIXCAT
  4. VALIDAR

👉 Sem PSP manual
👉 Sem chute


😈 Easter Egg final

Quem ainda usa fita…
está em 1998


🧠 O Que Isso Muda para um Dev COBOL

Você deixa de ser:

❌ “quem escreve programa”

E vira:

✅ quem entende o ambiente
✅ quem evita erro antes de acontecer
✅ quem conversa com sysprog de igual para igual


💥 Passo a Passo Mental (guarda isso)

Antes de qualquer APPLY:

  1. 🔍 REPORT
  2. 📊 Analisar dependência
  3. ⚙️ APPLY CHECK
  4. 🚀 APPLY real
  5. 📦 ACCEPT

🚀 Frase Final (nível Bellacosa)

“Seu COBOL pode estar perfeito…
mas quem decide se ele roda é o SMP/E.”