Bellacosa Mainframe um pequeno exemplo de API REST no Mainframe

💣🔥 API REST no Mainframe — QUANDO O COBOL VIROU BACKEND DE APLICATIVO SEM PEDIR LICENÇA

Se você ainda acha que COBOL só roda batch, prepara o choque:
com z/OS Connect, seu programa vira API REST consumida por mobile, web e cloud.

---

🚀 O que é o z/OS Connect (explicado sem enrolação)

👉 É o “tradutor oficial” entre:

• 🌐 Mundo moderno (REST / JSON)
• 🏦 Mundo legado (COBOL / CICS / IMS)

Ele roda no z/OS e conversa direto com:

• CICS
• IMS

💣 Tradução Bellacosa:

“Ele pega um GET/POST da internet e transforma em chamada de programa COBOL… e volta como JSON.”

---

🧠 Arquitetura (visão de guerra)

Fluxo real:

📱 Mobile / Web
        ↓
🌐 API REST (HTTP/JSON)
        ↓
🔌 z/OS Connect
        ↓
🧠 CICS / IMS
        ↓
💾 COBOL
        ↓
📦 Dados (Db2 / VSAM / EzNoSQL)

---

🧪 Exemplo prático (nível COBOL júnior)

🎯 Cenário

Você tem um programa COBOL que consulta saldo.

---

🧩 1. COBOL (legado)

       IDENTIFICATION DIVISION.
       PROGRAM-ID. SALDO01.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WS-CONTA    PIC 9(10).
       01 WS-SALDO    PIC 9(10)V99.

       PROCEDURE DIVISION.
           MOVE 12345 TO WS-CONTA
           MOVE 1500.75 TO WS-SALDO
           DISPLAY "SALDO: " WS-SALDO
           STOP RUN.

---

🌐 2. API REST exposta

GET /api/saldo/12345

---

🔁 3. Resposta JSON

{
  "conta": "12345",
  "saldo": 1500.75
}

💣 Sem reescrever COBOL
💣 Sem migrar sistema
💣 Só expondo via z/OS Connect

---

⚙️ Como funciona por dentro (o pulo do gato)

O z/OS Connect usa:

• Service Definition (SAR) → define entrada/saída
• Data Mapping → JSON ↔ estrutura COBOL
• Runtime Liberty (Java) → engine REST

👉 Ele faz o binding automático entre:

JSON ↔ Copybook COBOL

---

🔐 Segurança nível banco

Tudo integrado com:

• RACF
• TLS / HTTPS
• Controle de identidade

💣 Diferente de API na cloud:
👉 aqui segurança já nasce pronta

---

🚀 Vantagens (o que faz isso ser absurdo)

⚡ Modernização instantânea

Seu COBOL vira backend REST

---

💰 Economia brutal

Sem reescrever sistema legado

---

🔗 Integração total

Funciona com:

• mobile
• fintech
• cloud
• parceiros

---

🧩 Plugável com EzNoSQL

Sim, o combo fica insano:

👉 API REST + JSON + mainframe
👉 💣 arquitetura híbrida real

---

⚠️ Desvantagens (real talk)

❌ Setup inicial não é trivial

Precisa entender:

• contratos
• mapping
• deploy

---

❌ Debug pode confundir iniciante

Problema pode estar em:

• JSON
• mapping
• COBOL
• CICS

---

🧠 Curiosidades (nível insider)

💡 Muitas fintechs usam isso escondido
👉 API moderna… backend COBOL

💡 Você pode versionar APIs
👉 v1, v2 sem quebrar legado

💡 Integra com Swagger/OpenAPI
👉 documentação automática

---

🥚 Easter Egg

💣 O maior hack corporativo:

Empresas dizem:

👉 “Somos cloud-native”

Mas o core…

👉 ainda é COBOL exposto via z/OS Connect 😎

---

🧠 Insight que muda carreira

👉 Aprender isso te coloca à frente de 90% dos devs COBOL

Porque você passa a ser:

💣 Dev de integração + legado + API

---

🚀 Conclusão

O z/OS Connect é a ponte definitiva:

👉 passado (COBOL)
👉 presente (REST)
👉 futuro (cloud híbrida)

 

Bellacosa Mainframe apresenta EzNoSQL no Z/OS

💣🔥 EzNoSQL no z/OS — O Golpe Silencioso: COMO O MAINFRAME APRENDEU JSON SEM PEDIR PERMISSÃO

Se você é COBOL júnior e acha que NoSQL é coisa de cloud, segura essa:
o mainframe não só entendeu… como absorveu o conceito sem quebrar uma linha de negócio.

---

🧬 Origem — de onde veio essa “mutação”?

Tudo começa com um problema real:

👉 Sistemas core em z/OS
👉 Dados rígidos em Db2, VSAM, IMS
👉 Mundo moderno falando JSON, REST, mobile, eventos

💥 Conflito inevitável.

A IBM já vinha preparando o terreno com:

• Suporte a JSON no Db2
• z/OS Connect expondo APIs
• Integração com cloud

👉 O EzNoSQL for z/OS® surge como uma resposta pragmática:

💣 “E se a gente trouxer o modelo NoSQL pra dentro do mainframe ao invés de empurrar o mainframe pra fora?”

---

📅 História e lançamento

Diferente de produtos clássicos da IBM, o EzNoSQL não nasceu como um “big bang” tipo CICS ou Db2.

👉 Ele aparece por volta da década de 2010 (era pós-cloud), como parte da estratégia de:

• Modernização de aplicações
• APIs REST
• Dados semi-estruturados

💡 Não é um produto mainstream amplamente divulgado como CICS ou Db2
👉 É mais nichado, usado em arquiteturas modernas híbridas

---

🧠 O que ele realmente é (explicação raiz)

Pensa assim, jovem COBOLista:

👉 VSAM = registro fixo
👉 Db2 = tabela estruturada
👉 EzNoSQL = documento flexível (tipo JSON)

Exemplo:

{
  "conta": "123",
  "cliente": "Bellacosa",
  "apps": ["mobile", "web"],
  "config": {
    "notificacao": true
  }
}

💣 Isso no mundo antigo exigiria:

• várias tabelas
• joins
• redesign

👉 Aqui: 1 documento

---

⚙️ Como ele funciona na prática

Arquitetura típica:

App → API → z/OS Connect → COBOL → EzNoSQL

Integra com:

• CICS
• z/OS
• Segurança via RACF

---

🚀 Vantagens (o lado poderoso)

🔥 1. Modernização sem reescrita

Você não precisa jogar COBOL fora.

👉 Você evolui.

---

⚡ 2. JSON nativo no mainframe

Perfeito para:

• APIs REST
• Mobile
• Integrações modernas

---

🛡️ 3. Segurança absurda

Tudo herdado do mainframe:

• RACF
• auditoria
• controle fino

---

🧩 4. Integração natural

Nada de ETL maluco ou sync externo.

---

⚠️ Desvantagens (a parte que ninguém te conta)

❌ 1. Não é cloud-native puro

Não compete diretamente com:

• MongoDB
• Cassandra

---

❌ 2. Escalabilidade diferente

Mainframe escala verticalmente
NoSQL moderno escala horizontalmente

---

❌ 3. Curva de entendimento

COBOL + JSON = choque cultural no começo 😅

---

🧪 Exemplo mental (modo Bellacosa)

🎯 Problema

Cliente muda preferências toda hora.

No Db2:

• ALTER TABLE?
• nova coluna?
• impacto em batch?

💣 Dor.

---

🎯 Com EzNoSQL

{
  "cliente": "123",
  "preferencias": {
    "tema": "dark",
    "idioma": "pt-BR",
    "notificacao": true
  }
}

👉 Mudou? Só adiciona campo.

SEM ALTER TABLE.
SEM impacto global.

---

🧠 Curiosidades (nível raiz)

💡 EzNoSQL não substitui Db2
👉 Ele resolve outro tipo de problema

💡 Ele é mais comum em:

• bancos
• fintechs
• modernização de legado

💡 Muitas vezes você usa sem perceber:
👉 “camada invisível” por trás de APIs

---

🥚 Easter Egg (essa é boa)

💣 O maior segredo:

Muita empresa diz:

👉 “Estamos usando microserviços modernos”

Mas por trás…

👉 ainda existe COBOL chamando algo tipo EzNoSQL no z/OS 😎

---

🧠 Insight profundo (pra você crescer rápido)

👉 O futuro NÃO é:

• COBOL vs NoSQL
• Mainframe vs Cloud

💣 O futuro é:

Mainframe + NoSQL + APIs + eventos

---

🧪 Analogia final (pra fixar de vez)

• Db2 = planilha Excel organizada
• VSAM = arquivo binário rápido
• EzNoSQL = JSON flexível tipo API moderna

---

🚀 Conclusão

O EzNoSQL for z/OS® é uma peça estratégica:

👉 Ele permite que o mainframe:

• fale JSON
• exponha APIs
• se conecte ao mundo moderno

💣 Sem perder:

• performance
• segurança
• confiabilidade
•  

 

Bellacosa Mainframe apresenta Storage para DEV Cobol

💣 SEU COBOL NÃO É LENTO — SEU STORAGE É QUE DECIDE O DESTINO DO JOB

Um papo direto com quem já escreveu milhões de linhas em COBOL…
mas talvez nunca tenha olhado o storage como o verdadeiro protagonista.

---

☕ Introdução — o erro que ninguém te contou

Você já viu isso:

• Job que ontem rodava em 5 minutos… hoje leva 40
• Batch que “do nada” começa a gargalar
• VSAM “misteriosamente” lento
• DB2 com I/O explodindo

E alguém diz:

“É o programa.”

Não.
Na maioria das vezes… é o storage.

---

🧠 CAPÍTULO 1 — Antes do disco… existia o tempo físico

🧾 Cartão perfurado: o primeiro “storage”

Antes de DASD, antes de tape…
o dado era literalmente um buraco no papel.

• Cada linha COBOL → um cartão
• Ordem física → lógica do programa
• Caiu no chão? 💣 acabou o sistema

💡 Insight:

O primeiro “bug” da história era… baralho embaralhado.

---

🎞️ CAPÍTULO 2 — Tape: o começo do streaming

📼 Fita magnética — o avô do Big D

Tape trouxe algo revolucionário:

• Processamento sequencial
• Grandes volumes
• Backup antes de existir “backup”

👉 E aqui nasce o conceito que você usa até hoje:

Batch

💡 Curiosidade:

• Tape ODEIA parar
• Se parar → “shoe-shining” (vai e volta igual fita cassete)

---

💿 CAPÍTULO 3 — Disco: quando o acesso ficou inteligente

🏢 DASD (Direct Access Storage Device)

Aqui muda o jogo:

• Acesso direto (não sequencial)
• Surge VSAM
• Surge CICS
• Surge DB2

👉 Você para de ler tudo… e passa a ler o que precisa

💡 Insight COBOL:

READ NEXT virou READ KEY

---

⚡ CAPÍTULO 4 — Flash: o fim da mecânica

🔥 SSD no mundo enterprise

Sem disco girando
Sem braço mecânico
Sem latência física relevante

👉 Resultado:

• I/O quase instantâneo
• Batch acelera absurdamente
• DB2 muda comportamento

💡 Insight crítico:

Flash não melhora programa ruim…
ele expõe arquitetura ruim

---

🚀 CAPÍTULO 5 — NVMe: paralelismo bruto

Aqui não é mais “rápido”…
é outro modelo mental.

• I/O paralelo massivo
• Filas simultâneas
• CPU quase não espera

👉 No mainframe:

O gargalo deixa de ser storage… e vira desenho da aplicação

---

🔌 CAPÍTULO 6 — O segredo que poucos entendem: I/O NÃO É CPU

🧠 Como o z/OS realmente funciona

No mundo distribuído:

• CPU faz tudo

No mainframe:

• CPU manda
• Channel executa
• Storage responde

👉 Resultado:

Seu COBOL NÃO faz I/O… ele pede I/O

💡 Easter egg:

• EXCP → você acha que controla tudo
• Mas quem manda mesmo é o Channel Subsystem

---

🧬 CAPÍTULO 7 — RAID: onde mora o risco invisível

Você nunca configurou RAID no COBOL…
mas ele define seu tempo de execução.

• RAID 5 → barato, mais lento
• RAID 10 → caro, extremamente rápido
• RAID 6 → seguro, mais pesado

💣 Verdade dura:

RAID errado = gargalo invisível

---

🧠 CAPÍTULO 8 — SMS: o cérebro invisível

Aqui está o ponto mais ignorado por dev:

SMS decide onde seu dado vai viver

• Storage Class → performance
• Management Class → lifecycle
• Data Class → formato

👉 Você escreve:

OPEN INPUT ARQUIVO

👉 Mas quem decide:

• Disco?
• Flash?
• Tape?

💡 Insight:

Você não controla o storage…
você negocia com ele

---

📦 CAPÍTULO 9 — Tape moderno: o sobrevivente

Tape não morreu.

Ele virou:

• Backup
• Archive
• Compliance
• Air gap (anti-ransomware)

💡 Insight:

Quando tudo falha…
é o tape que salva

---

🤖 CAPÍTULO 10 — Cartridge + robô = escala

• Cartucho = mídia
• Drive = leitura
• Robô = automação

👉 Você pede dataset
👉 Um robô físico movimenta o dado

Sim… existe um braço robótico trabalhando pro seu JCL

---

🧊 CAPÍTULO 11 — Air Gap: o último nível

• Offline
• Fora da rede
• Intocável

👉 Nem hacker… nem erro humano alcança

---

💣 CAPÍTULO FINAL — A verdade que muda tudo

Você achava que:

“Programa define performance”

Mas na prática:

• Storage define latência
• RAID define risco
• SMS define localização
• Tape define sobrevivência

---

☕ Bellacosa-style conclusão

“COBOL executa regra de negócio…
mas é o storage que decide se ela chega a tempo.”

 

💣 LAB MASTER 🔥 Storage Não Armazena — Ele Decide o Destino do Dado

 

Bellacosa Mainframe Treine Storage Mainframe

💣 LAB MASTER

🔥 Storage Não Armazena — Ele Decide o Destino do Dado

---

🎯 Objetivo do LAB

Ao final você será capaz de:

• Entender como o SMS decide storage
• Criar datasets com e sem striping
• Simular impacto de RAID (conceitual)
• Trabalhar com DASD vs Tape
• Ver migração automática (HSM ML1/ML2)
• Executar backup e restore
• Entender o papel do air gap

---

🏗️ Cenário

Você é responsável por:

• Um ambiente com:
  • DASD (disco)
  • Flash (simulado via classe)
  • Tape (ML2)
• Workloads:
  • Batch pesado
  • Dados críticos
  • Arquivos de archive

---

🧪 LAB 1 — Alocação sem SMS (controle manual)

🎯 Objetivo

Sentir o “mundo antigo”

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=USER.TEST.MANUAL,
//      DISP=(NEW,CATLG),
//      UNIT=3390,
//      SPACE=(CYL,(10,5))

🧠 O que observar:

• Você escolhe tudo manualmente
• Sem inteligência

---

🧪 LAB 2 — Alocação com SMS

🎯 Objetivo

Ver o SMS em ação

//STEP1 EXEC PGM=IEFBR14
//DD1   DD DSN=USER.TEST.SMS,
//      DISP=(NEW,CATLG),
//      DATACLAS=STANDARD,
//      STORCLAS=FAST,
//      MGMTCLAS=BACKUP

🧠 O que observar:

• Nenhum volume definido
• SMS decide tudo

---

🧪 LAB 3 — Striping (performance)

🎯 Objetivo

Simular I/O paralelo

👉 Criar Data Class com:

• Stripe Count = 4

//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USER.TEST.STRIP,
//     DISP=(NEW,CATLG),
//     DATACLAS=STRIPE4

🧠 Observe:

• Dataset distribuído
• Performance maior

---

🧪 LAB 4 — RAID (conceitual via comportamento)

🎯 Objetivo

Entender impacto sem ver RAID direto

Teste:

• Dataset pequeno vs grande
• Com e sem striping

👉 Analise:

• Tempo de execução
• I/O count

💡 Insight:

RAID está por baixo — você vê o efeito, não a configuração

---

🧪 LAB 5 — Tape (gravação)

🎯 Objetivo

Gravar em fita

//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=USER.TEST.SMS,DISP=SHR
//SYSUT2   DD DSN=USER.TEST.TAPE,
//         DISP=(NEW,CATLG),
//         UNIT=TAPE,
//         VOL=SER=TAPE01

🧠 Observe:

• Acesso sequencial
• Tempo maior

---

Bellacosa Mainframe apresenta leitor cartrige com braço robotico

🧪 LAB 6 — HSM (migração automática)

🎯 Objetivo

Ver dados indo para tape

Comando:

HSEND MIGRATE DATASET('USER.TEST.SMS')

🧠 Resultado:

• ML1 → disco
• ML2 → tape

---

Bellacosa Mainframe apresenta antigo leitor tape para mainframe mvs 

🧪 LAB 7 — Recall (volta do tape)

//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USER.TEST.SMS,DISP=SHR

🧠 Observe:

• Dataset volta do tape
• Delay perceptível

---

🧪 LAB 8 — Backup

🎯 Objetivo

Criar cópia de segurança

//STEP1 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//DUMP DD DSN=USER.BACKUP.TAPE,
//     UNIT=TAPE,
//     DISP=(NEW,CATLG)
//SYSIN DD *
 DUMP DATASET(USER.TEST.SMS) -
      OUTDD(DUMP)
/*

---

🧪 LAB 9 — Simulação de desastre

🎯 Objetivo

Recuperação

//STEP1 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//DUMP DD DSN=USER.BACKUP.TAPE,DISP=SHR
//SYSIN DD *
 RESTORE DATASET(USER.TEST.SMS) -
         INDD(DUMP)
/*

---

🧪 LAB 10 — Air Gap (conceito aplicado)

🎯 Objetivo

Entender proteção real

👉 Cenário:

• Dataset corrompido
• Backup online comprometido

👉 Recuperação:

• Apenas via tape

💡 Insight:

Aqui você entende por que tape ainda existe

---

🧠 Fechamento técnico

Você acabou de trabalhar com:

• DASD (3390)
• SMS (policy-driven storage)
• Striping (performance)
• RAID (efeito indireto)
• Tape (sequencial)
• HSM (automação)
• Backup/Restore
• Air Gap (segurança real)

---

☕ Bellacosa-style conclusão

“Você não manipulou disco…
você manipulou decisões sobre onde o dado vive, se move… e sobrevive.”

 

 

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ério	RACF	TSS	ACF2
Governança	Alta	Média	Alta
Simplicidade	Média	Alta	Baixa
Flexibilidade	Alta	Média	Extremamente alta
Risco operacional	Médio	Médio	Alto
Mercado atual	Dominante	Caindo	Nicho

---

💣 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.”