Translate

terça-feira, 17 de fevereiro de 2026

🔥💀 COBOL SECURITY LAB — “SEU CICS SOB ATAQUE”

 

Bellacosa Mainframe lab seu cics sob ataque


🔥💀 COBOL SECURITY LAB — “SEU CICS SOB ATAQUE”

Hands-on prático com CICS + DB2 para aprender segurança na marra


☕ INTRODUÇÃO

Você não vai só aprender…

👉 você vai:

  • explorar vulnerabilidade
  • corrigir
  • validar

💣 exatamente como um atacante faria


🧪 LAB 1 — SQL INJECTION NO DB2

🎯 Objetivo

Mostrar como um COBOL pode ser vulnerável


💻 Código vulnerável

IDENTIFICATION DIVISION.
PROGRAM-ID. LOGIN.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-USER PIC X(20).
01 WS-PASS PIC X(20).

PROCEDURE DIVISION.

EXEC SQL
SELECT NAME INTO :WS-USER
FROM USERS
WHERE NAME = :WS-USER
AND PASSWORD = :WS-PASS
END-EXEC.

💣 Ataque

Input:

' OR '1'='1

💥 Resultado

👉 bypass de autenticação


✅ Correção

IF WS-USER NOT ALPHABETIC
DISPLAY "INVALID INPUT"
STOP RUN
END-IF.

💬 Insight

👉 validação é a primeira defesa


🧪 LAB 2 — BUFFER / TAMANHO DE INPUT

🎯 Objetivo

Evitar overflow e dados inválidos


💻 Problema

01 WS-NAME PIC X(10).

Input:

AAAAAAAAAAAAAAAAAAAAAAAAAAAA

💥 Resultado

👉 truncamento / corrupção


✅ Correção

IF LENGTH OF WS-NAME > 10
DISPLAY "INPUT TOO LONG"
END-IF.

🧪 LAB 3 — HARDCODED PASSWORD

🎯 Objetivo

Eliminar segredo no código


❌ Código

MOVE "DB123456" TO WS-PASS.

💣 Problema

👉 vazamento garantido


✅ Correção

  • usar RACF
  • usar external security

👉 RACF


🧪 LAB 4 — VALIDAÇÃO DE COMMAREA (CICS)

🎯 Objetivo

Proteger entrada CICS


💻 Código vulnerável

MOVE DFHCOMMAREA TO WS-DATA.

💣 Problema

👉 dados maliciosos


✅ Correção

IF EIBCALEN = 0
DISPLAY "NO DATA"
RETURN
END-IF.

🧪 LAB 5 — LOGGING SEGURO

🎯 Objetivo

Evitar vazamento de dados


❌ Errado

DISPLAY "PASSWORD: " WS-PASS.

💣 Problema

👉 senha em log


✅ Correção

DISPLAY "LOGIN ATTEMPT".

🧪 LAB 6 — CONTROLE DE ACESSO (RACF)

🎯 Objetivo

Simular autorização


💻 Exemplo

CALL 'RACROUTE' USING ...

💬 Resultado

👉 só usuários autorizados acessam


🧪 LAB 7 — INTEGRAÇÃO COM API (RISCO REAL)

🎯 Objetivo

Simular API via CICS


💣 Problema

👉 input externo não confiável


✅ Solução

  • validar JSON
  • sanitizar campos

🧪 LAB 8 — TRATAMENTO DE ERRO

🎯 Objetivo

Não expor sistema


❌ Errado

DISPLAY SQLCODE.

💣 Problema

👉 revela estrutura interna


✅ Correto

DISPLAY "ERROR OCCURRED".

🧪 LAB 9 — CONTROLE DE TRANSAÇÃO

🎯 Objetivo

Evitar inconsistência


💻 Uso

EXEC CICS SYNCPOINT
END-EXEC.

💬 Importante

👉 protege integridade


🧪 LAB 10 — SIMULAR ATAQUE REAL

🎯 Objetivo

Mentalidade hacker


💻 Faça

  • testar inputs inválidos
  • tentar bypass
  • observar comportamento

💥 Resultado

👉 descobrir falhas reais


🧠 VISÃO FINAL

Você fez:

  • ataque
  • defesa
  • validação

👉 isso é segurança real


💬 FRASE FINAL

“Mainframe não é seguro por ser forte…
é seguro quando você fecha as portas certas.”

segunda-feira, 16 de fevereiro de 2026

🔥💀 SEU CÓDIGO ESTÁ SEGURO… OU SÓ AINDA NÃO FOI HACKEADO?

 

Bellacosa Mainframe apresenta segurança em codigo

🔥💀 “SEU CÓDIGO ESTÁ SEGURO… OU SÓ AINDA NÃO FOI HACKEADO?”

Do Cartão Perfurado ao DevSecOps: como as mesmas falhas continuam derrubando sistemas — inclusive o seu


☕ INTRODUÇÃO — O ERRO QUE ATRAVESSOU DÉCADAS

Se você acha que segurança de aplicação é algo “moderno”…

👉 você já começou errado.

Há mais de 20 anos, os mesmos problemas que aparecem hoje na lista da OWASP já existiam.

E o mais assustador:

💣 Eles continuam sendo explorados hoje.


🧠 UM POUCO DE HISTÓRIA (SIM, ISSO COMEÇA NO MAINFRAME)

Antes de:

  • APIs REST
  • microservices
  • cloud

…existia:

🧱 Mainframe + COBOL + CICS + DB2

E adivinha?

👉 Os mesmos problemas já estavam lá:

  • input sem validação
  • acesso indevido
  • dados sensíveis expostos

💀 EASTER EGG HISTÓRICO

Nos anos 70–80, segurança era baseada em:

👉 “ninguém tem acesso físico ao terminal”

Spoiler:

💣 isso não durou muito


🔐 O NASCIMENTO DA SEGURANÇA REAL

Ferramentas como o RACF surgiram para resolver:

  • quem pode acessar
  • o que pode acessar
  • quando pode acessar

👉 primeiro passo para segurança moderna


💣 O PROBLEMA REAL: NÃO É TECNOLOGIA

👉 É comportamento

Hoje temos:

  • scanners
  • IA
  • automação
  • cloud

E mesmo assim…

💥 vazamentos continuam acontecendo


📊 DADO REAL (que assusta)

Tempo médio para detectar um breach:

👉 ~212 dias

Tempo suficiente para:

  • invadir
  • explorar
  • exfiltrar dados
  • desaparecer

🔥 OWASP TOP 10 — O MANUAL DO ATACANTE

A OWASP lista os erros mais explorados.

E aqui vai o choque:

👉 quase todos são básicos


💣 EXEMPLO 1 — SQL INJECTION (O DINOSSAURO QUE AINDA MATA)

' OR 1=1 --

👉 isso ainda quebra sistemas hoje


💣 EXEMPLO 2 — XSS (VOCÊ CONFIA NO USUÁRIO?)

<script>stealCookies()</script>

👉 o browser executa
👉 o atacante assume a sessão


💣 EXEMPLO 3 — DEPENDÊNCIAS VULNERÁVEIS

Você escreve:

👉 20% do código

O resto?

👉 bibliotecas externas 😬


🛠️ DEVSECOPS — A VIRADA DE JOGO

Antes:

👉 segurança era responsabilidade de outro time

Hoje:

👉 “You build it, you run it… and you secure it.”


🔄 PIPELINE MODERNO

code → scan → test → deploy → monitor

Ferramentas:

  • SAST (ex: análise estática)
  • DAST (ataque simulado)
  • SCA (dependências)
  • runtime protection

🧪 MÃO NA MASSA (O QUE VOCÊ PRATICOU)

Você fez:

🔍 SAST

  • analisou código sem rodar

🌐 DAST

  • atacou a aplicação com ferramentas

📦 SCA

  • descobriu vulnerabilidade em libs

🔐 Secrets

  • saiu do hardcode → Vault

🐳 Docker Security

  • corrigiu imagem vulnerável

👉 isso é exatamente o que empresas fazem hoje


💀 ERRO CLÁSSICO (QUE DERRUBA EMPRESA)

password = "123456"

👉 parece inofensivo

👉 vira incidente milionário


🧠 A VERDADE QUE NINGUÉM TE CONTA

👉 Segurança não falha por falta de ferramenta

👉 Segurança falha por:

  • pressa
  • ignorância
  • negligência

🔥 CURIOSIDADE (QUE MUDA SUA VISÃO)

O maior ataque da história recente (Log4j):

👉 veio de uma biblioteca

Não do código principal


🚀 DO DEV AO ENGENHEIRO DE SEGURANÇA

Depois desse conhecimento, você não é mais só dev:

👉 você entende:

  • como atacar
  • como defender
  • onde estão os riscos

🧱 E O COBOL NISSO TUDO?

Tudo isso se aplica em:

  • CICS
  • DB2
  • APIs via z/OS Connect

👉 Mainframe não é imune
👉 ele só é mais disciplinado


💬 FRASE PRA GRAVAR

“Você não precisa ser hackeado para estar vulnerável…
basta ignorar o básico.”


🔥 CONCLUSÃO (SEM FILTRO)

👉 Se você não:

  • valida input
  • protege secrets
  • escaneia dependências
  • monitora

💣 seu sistema já está em risco


🚀 CHAMADA FINAL

Agora você tem duas opções:

👉 continuar escrevendo código
ou
👉 começar a proteger sistemas

domingo, 15 de fevereiro de 2026

🔥💀 DO CARTÃO PERFURADO AO COFRE NA MONTANHA

 

Bellacosa Mainframe e o mundo secreto do Storage Mainframe cartridges e o cofre na montanha de ferro

🔥💀 DO CARTÃO PERFURADO AO COFRE NA MONTANHA

“Como seus dados COBOL sobreviveram a guerras, ransomware… e ao tempo”


🧨 Introdução (sem mimimi)

Se você escreve COBOL hoje…
existe uma chance enorme de que o dado que você manipula:

  • já esteve em um cartão perfurado
  • passou por uma fita magnética
  • e talvez hoje esteja guardado em um cofre subterrâneo

Sim… isso não é romantização.
Isso é a linha evolutiva real do mainframe.

E no meio dessa história… existe um nome quase lendário:

👉 Iron Mountain


🧱 Capítulo 1 — Cartão perfurado: o “INSERT INTO” de 1930

Antes de existir dataset…
antes de existir VSAM…

👉 Existia isso:

  • Cartões físicos
  • 80 colunas
  • Cada furo = dado

💀 Tradução Bellacosa:

“Seu SELECT era um buraco no papel”


🧠 Curiosidades

  • Um programa COBOL inteiro = caixa de cartões
  • Derrubar a pilha = ABEND físico real
  • Ordenação = literalmente reorganizar papel

⚠️ Problema

  • Lento
  • Frágil
  • Não escalável

👉 Aí veio a revolução…


📼 Capítulo 2 — Tape: o primeiro “Big Data” do mundo

👉 A fita trouxe:

  • 📦 Volume massivo
  • 🔄 Processamento sequencial
  • ⚡ Muito mais velocidade que cartão

💀 Tradução:

“Sai o papel… entra o fluxo contínuo”


🧠 Como isso impactou o COBOL?

👉 Nasce o modelo que você usa até hoje:

  • Arquivo sequencial
  • Batch
  • Processamento em massa

💡 Insight poderoso

👉 Seu COBOL batch moderno…

💀 ainda pensa como fita


📦 Capítulo 3 — Cartridge: o “pendrive” do mainframe

  • Fita aberta → cartridge fechado
  • Mais proteção
  • Mais densidade
  • Automação

📊 Exemplo real

  • LTO-9 → 18 TB (nativo)
  • Compressão → até 45 TB

💀 Tradução:

“Uma fita hoje guarda mais que um datacenter antigo inteiro”


🏔️ Capítulo 4 — Iron Mountain: o cofre dos dados do mundo

👉 Agora entra o nível lendário…

A Iron Mountain:

  • Guarda dados em minas subterrâneas
  • Protegidas contra:
    • fogo
    • guerra
    • desastre
  • Usada por:
    • bancos
    • governos
    • Fortune 500

💀 Tradução Bellacosa:

“Se tudo der errado… seus dados estão dentro de uma montanha”


🚚 Como funciona

  1. Backup em fita
  2. Fita retirada da library
  3. Transporte seguro
  4. Armazenamento em cofre

🔐 Segurança real

👉 Isso cria o famoso:

AIR GAP físico


🧠 Capítulo 5 — Por que fita ainda manda?


⚔️ Disk vs Tape (sem romantismo)

CritérioDiskTape
Velocidade🐢
Custo💸💰
Durabilidade
Segurança⚠️🔐

💀 Verdade dura:

“Disco é rápido… fita é eterna”


🧨 Capítulo 6 — Ransomware não perdoa (mas fita sim)

👉 Se o backup estiver online:

💀 Ele será criptografado junto


👉 Se estiver em fita offline:

✔️ Intocado
✔️ Recuperável
✔️ Seguro


🧠 Capítulo 7 — O que o dev COBOL precisa entender


💡 Você NÃO está só escrevendo código

Você está:

  • Alimentando sistemas de retenção
  • Gerando dados regulatórios
  • Criando histórico corporativo

🎯 Dicas práticas

👉 Quando pensar em arquivos:

  • Sequencial → fita-friendly
  • Batch → tape-driven
  • Grande volume → tape inevitável

👉 Quando pensar em backup:

  • Disk → rápido
  • Tape → seguro

👉 Quando pensar em DR:

💀 “Se não tem fita… não tem garantia”


🧨 Curiosidades que ninguém te conta

  • CERN usa tape para centenas de PB
  • Cloud providers usam tape no backend
  • LTO roadmap chega a 576 TB por fita (futuro)

💀 Conclusão — A verdade que poucos entendem

👉 O mundo mudou
👉 A tecnologia evoluiu

Mas…


💀 A fita nunca morreu


Ela só:

  • Ficou mais densa
  • Mais segura
  • Mais invisível

🎯 Frase final estilo Bellacosa

“Seu COBOL pode rodar no Z17…
mas a memória da empresa ainda descansa em fita — guardada dentro de uma montanha.”

 

👻 Ayakashi — O “Bug Sobrenatural” do Japão

 

Bellacosa Mainframe apresenta ayakashi

👻 Ayakashi — O “Bug Sobrenatural” do Japão

Se Yokai são todos os processos sobrenaturais do sistema…
os Ayakashi são aqueles processos instáveis, perigosos e geralmente ligados à morte ou energia pesada.

👉 Estilo Bellacosa:

Ayakashi = job corrompido rodando fora do controle.


📜 Origem e Significado

“Ayakashi” (あやかし) é um termo antigo japonês usado para descrever:

  • Aparições misteriosas no mar 🌊
  • Espíritos perigosos 👻
  • Fenômenos sobrenaturais estranhos

Com o tempo, virou um termo mais amplo para:

👉 entidades sobrenaturais malignas ou instáveis


🧬 Diferença entre Yokai x Ayakashi

TipoO que é
YokaiQualquer criatura sobrenatural
AyakashiYokai mais sombrio / perigoso / espiritual

📌 Resumo Bellacosa:

Todo Ayakashi é Yokai…
mas nem todo Yokai virou problema em produção.


👁 Aparência — Não Existe Padrão


Ayakashi pode ser:

  • Forma humana distorcida
  • Sombra viva
  • Monstro grotesco
  • Espírito invisível

📌 Regra geral:

Se parece errado… provavelmente é Ayakashi.


🧠 Comportamento

  • Ligados a emoções negativas
  • Atraídos por humanos
  • Podem possuir ou influenciar
  • Nem sempre são racionais

Eles não seguem lógica humana.
Eles seguem energia emocional.


🎌 Onde aparece em animes

  • Ayakashi: Samurai Horror Tales
  • Natsume's Book of Friends
  • Noragami
  • Jujutsu Kaisen (versão moderna = maldições)

🤫 Curiosidades

  • Originalmente ligados ao mar 🌊
  • Podem ser invisíveis para humanos comuns
  • Alguns são apenas energia, não criaturas físicas
  • Às vezes são confundidos com fantasmas (Yurei)

🕹️ Easter Egg Cultural

👉 Em muitos animes modernos:

  • “Maldição”
  • “Espírito negativo”
  • “Energia amaldiçoada”

📌 Tudo isso tem DNA direto de Ayakashi.


🧠 Interpretação (Modo Bellacosa ON)

Ayakashi representam:

  • Emoções fora de controle
  • Trauma acumulado
  • Energia negativa
  • O lado oculto da mente humana

📌 Conclusão

Ayakashi não são só monstros.
Eles são o resultado de algo que deu errado — emocional, espiritual ou existencial.

Não é só criatura…
é consequência.

 

sábado, 14 de fevereiro de 2026

🔥💀 DÚVIDAS FREQUENTES SOBRE SMP/E

 

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”

 

sexta-feira, 13 de fevereiro de 2026

🔥 “Shangri-La Frontier: O Mainframe dos MMORPGs — o jogo perfeito que só os jogadores ‘quebrados’ conseguem dominar”

 

Bellacosa Mainframe apresenta Shangri-la Frontier

🔥 “Shangri-La Frontier: O Mainframe dos MMORPGs — o jogo perfeito que só os jogadores ‘quebrados’ conseguem dominar”

Se você acha que já viu tudo sobre animes de MMORPG… prepare-se.

Porque Shangri-La Frontier não é só mais um anime de fantasia digital.
Ele é praticamente um sistema crítico em produção, onde cada erro custa caro — e cada acerto parece um tuning fino em ambiente z/OS.

Bem-vindo, Padawan. ☕


🧠 🖥️ O Conceito: Quando o “Kusoge” vira Skill de Produção

Nosso protagonista, Rakuro Hizutome, é um especialista em jogos ruins — os famosos kusoge.

👉 Traduzindo para o mundo mainframe:
Ele é aquele cara que aprendeu em sistema legado cheio de gambiarra, JCL torto e dump todo dia.

Então ele entra no jogo perfeito:

👉 Shangri-La Frontier — um VRMMO com milhões de players e zero bugs aparentes.

💡 Só que tem um detalhe genial:

Quem sobreviveu ao caos… domina o perfeito.


⚔️ 🎮 Gameplay = Debug em Tempo Real

Esse anime não é sobre ser forte.
É sobre entender o sistema.

Sunraku joga como um verdadeiro:

  • 🧪 Analista de problema em produção
  • 🔍 Investigador de comportamento anômalo
  • ⚙️ Otimizador de performance

Ele:

  • Lê padrões de ataque como logs SMF
  • Testa hipóteses como batch em DEV
  • Aprende com erro (tipo abend S0C7 😅)

👉 Resultado: batalhas que parecem troubleshooting em tempo real.


🧍‍♂️ 👥 Personagens — A Party que Parece um Squad de Produção

🐦 Sunraku (Rakuro)

  • Máscara de pássaro (Easter egg visual icônico)
  • Joga com build “quase suicida”
  • Vive no limite — tipo job sem checkpoint

💡 Curiosidade:
A máscara simboliza anonimato + liberdade — igual dev em ambiente sandbox 😄


⚔️ Arthur Pencilgon

  • Jogadora elite
  • Personalidade caótica
  • Mentalidade de PvP hardcore

💡 Easter egg:
👉 O nome “Pencilgon” é uma zoeira com pen tool precision — precisão absurda.


🔫 Oikatzo

  • Estratégico
  • Focado em eficiência
  • Representa o “cara do script que resolve tudo”

💡 Ele é basicamente:
👉 o sysprog que ninguém vê… mas salva tudo.


🐉 🌍 O Mundo — Um Sistema Distribuído Vivo

O jogo é um absurdo de bem construído:

  • 🌐 Eventos dinâmicos
  • 🐉 Bosses únicos (quase “APIs ocultas”)
  • 🎯 Missões secretas raríssimas
  • ⚙️ Sistema de combate emergente

👉 Alguns bosses são tão raros que parecem:

🔥 JOB que roda uma vez por década


🧩 🐺 Easter Eggs e Curiosidades que Pouca Gente Percebe

🐺 Lycagon — O “Erro Fatal”

  • Boss lendário que marca o jogador
  • Após isso, o jogo muda completamente

💡 Analogia Bellacosa:
👉 É tipo quando você altera algo em produção…
e nunca mais o sistema é o mesmo.


🎮 Referências a jogos reais

O anime bebe direto de:

  • Dark Souls → dificuldade e leitura de padrão
  • Monster Hunter → caça e estratégia
  • Final Fantasy XI → MMO raiz

🧠 Filosofia escondida

O autor, Katarina, construiu uma ideia brilhante:

“Não é o melhor sistema que cria o melhor jogador…
é o pior sistema que forja os mais preparados.”


📖 🚀 Enredo — Sem Spoilers Pesados

A história gira em torno de:

  • Exploração de conteúdo oculto
  • Evolução por habilidade (não nível)
  • Confrontos com bosses lendários
  • Relações entre players de alto nível

👉 E principalmente:

💡 A busca por dominar algo que ninguém entende completamente.


📈 📊 Por que esse anime virou cult hit?

  • 🏆 Premiado pela Kodansha
  • 📚 Milhões de cópias vendidas
  • 🎥 Anime com múltiplas temporadas

Mas o verdadeiro motivo:

👉 Ele respeita a inteligência do espectador.


☕ 🧠 O Insight Bellacosa

Se fosse traduzir esse anime para o mundo mainframe:

Shangri-La FrontierMainframe
Boss raroProblema intermitente
Build do playerParâmetros de JCL
GrindBatch processing
Skill do jogadorExperiência em produção

🚨 🎯 Conclusão — O que o Padawan precisa levar

👉 Shangri-La Frontier não é sobre jogo. É sobre mentalidade.

  • Aprender com erro
  • Adaptar rápido
  • Entender sistema complexo
  • Explorar o que ninguém vê

💡 Em outras palavras:

É o anime que todo profissional de tecnologia deveria assistir.

🔥 “ENCLAVE NO z/OS: O JOB INVISÍVEL QUE MANDA MAIS QUE SEU COBOL” 💀

 

Bellacosa Mainframe analise o enclave no z/os

🔥 “ENCLAVE NO z/OS: O JOB INVISÍVEL QUE MANDA MAIS QUE SEU COBOL” 💀

Se você acha que quem manda no z/OS é o seu JOB, seu STEP ou seu programa COBOL… já começou errado 😈
Existe uma entidade silenciosa, poderosa e MUITO mais inteligente: o ENCLAVE.

E depois que você entende isso… nunca mais olha para performance, WLM ou CICS da mesma forma.


🧠 O QUE É UM ENCLAVE (SEM MIMIMI)

Um enclave no z/OS é uma unidade lógica de trabalho gerenciada pelo WLM (Workload Manager).

👉 Tradução Bellacosa:

É como se fosse um “JOB fantasma” criado pelo sistema pra medir, priorizar e controlar o que realmente importa.

Ele não aparece no JES como um JOB comum.
Ele não está preso a um único address space.
Mas… ele é quem decide quanto CPU você ganha ou perde.


🏛️ ORIGEM — POR QUE ISSO EXISTE?

Lá atrás, no mundo pré-WLM, o controle era baseado em:

  • Prioridade fixa
  • Dispatching clássico
  • Regras estáticas

Problema? 😬
Ambientes modernos (CICS, DB2, WebSphere, Java, API REST) quebraram esse modelo.

👉 A IBM respondeu com o WLM Goal-Oriented:

E aí nasceu o ENCLAVE:

  • Para representar transações distribuídas
  • Para permitir gerenciamento baseado em objetivos (response time, velocity, etc.)
  • Para desacoplar trabalho de address spaces

💡 Ou seja:

O enclave nasceu quando o mainframe percebeu que o mundo virou distribuído.


⚙️ COMO FUNCIONA NA PRÁTICA

Imagine isso:

  • Um request entra via CICS
  • Faz chamada DB2
  • Vai pra MQ
  • Volta pro CICS

👉 Isso tudo NÃO é um único processo linear

O z/OS cria um ENCLAVE para representar esse fluxo como uma única entidade lógica


🔄 O enclave acompanha:

  • Tempo de CPU
  • Tempo de resposta
  • Esperas (I/O, lock, etc.)
  • Prioridade dinâmica (via WLM)

🎯 O PAPEL DO WLM (O VERDADEIRO CHEFE)

O WLM não gerencia JOBs diretamente.

Ele gerencia:

👉 ENCLAVES

Com base em:

  • Service Class
  • Importance
  • Performance goals

💡 Resultado:

Dois programas idênticos podem ter comportamentos COMPLETAMENTE diferentes dependendo do enclave.


🧨 EXEMPLO REAL (COBOL DEV VAI SENTIR)

Você roda:

  • Um batch COBOL via JCL
  • Uma transação CICS chamando o mesmo programa

Mesmo código… MAS:

ContextoQuem manda
BatchJES / Dispatching
CICSENCLAVE + WLM

👉 Resultado:

  • No CICS, o desempenho é governado pelo enclave
  • No batch, não

💀 É por isso que “funciona no batch mas é lento no online”


🕵️ TROUBLESHOOTING (OU: POR QUE SEU JOB APANHA)

Se algo está lento e você ignora enclave… você está investigando errado.

🔍 Sintomas clássicos:

  • CPU baixa, mas resposta ruim
  • Transação lenta “sem motivo”
  • WLM aparentemente ignorando você

🧠 Possíveis causas:

  • Service class errada
  • Importance baixa
  • Goal impossível (ex: response time irreal)
  • Contenção em recursos compartilhados

🛠️ ONDE INVESTIGAR

  • RMF Monitor III
  • SMF 72 (WLM)
  • SDSF (delay reason)
  • CICS statistics

💡 Dica Bellacosa:

Se não olhou SMF 72, você não investigou WLM de verdade.


🧩 EASTER EGG (POUCA GENTE SABE)

🔥 Nem todo enclave é igual:

Existem:

  • Independent enclaves
  • Dependent enclaves

👉 Dependente = herda contexto
👉 Independente = vive sua própria vida

💡 E aqui vem o pulo do gato:

Um enclave pode atravessar múltiplos sistemas via sysplex

Sim… o “fantasma” atravessa LPARs 👻


🤯 CURIOSIDADES QUE EXPLODEM A MENTE

  • Enclaves são essenciais para Java no z/OS
  • DB2 usa enclaves para workloads distribuídos (DRDA)
  • z/OS Connect depende disso pra API REST

👉 Ou seja:

Sem enclave… não existe mainframe moderno


⚠️ ERROS CLÁSSICOS (E CAROS)

❌ “Aumenta a prioridade do address space”
👉 ERRADO — quem manda é o enclave

❌ “O problema é CPU”
👉 Nem sempre — pode ser política WLM

❌ “Batch está ok, então produção também está”
👉 Contexto diferente = enclave diferente


💬 COMENTÁRIO NO ESTILO RAIZ

Enclave é aquele tipo de coisa que:

  • Ninguém te ensina direito
  • Todo mundo usa sem saber
  • E quando dá problema… vira caos

💀


🧠 RESUMO DIRETO (SEM ENROLAR)

👉 Enclave é:

  • Uma unidade lógica de trabalho
  • Controlada pelo WLM
  • Independente de address space
  • Base para performance moderna no z/OS

🔥 FRASE PRA GRUDAR NA SUA CABEÇA

“Você acha que está rodando um programa…
mas quem está sendo julgado é o seu ENCLAVE.”