☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

sexta-feira, 8 de maio de 2026

☕🔥 O NOVO PROFISSIONAL MAINFRAME — O “SYSOP DO FUTURO” JÁ CHEGOU… E MUITA GENTE AINDA NÃO PERCEBEU 🔥☕

 

Bellacosa Mainframe fala sobre o futuro do profissional mainframe

☕🔥 O NOVO PROFISSIONAL MAINFRAME — O “SYSOP DO FUTURO” JÁ CHEGOU… E MUITA GENTE AINDA NÃO PERCEBEU 🔥☕

Durante anos o mercado repetiu a mesma ladainha:

“Mainframe morreu.”
“COBOL acabou.”
“Tudo vai para cloud.”
“Só tem profissional velho.”
“Daqui 5 anos ninguém mais usa z/OS.”

…e mesmo assim o mainframe continua processando bilhões de transações financeiras, cartões, seguros, companhias aéreas, governo, saúde e bancos do planeta inteiro.

O mais curioso?

Enquanto muita gente fazia meme do COBOL…
a IBM lançava:

  • novas releases do z/OS,
  • melhorias absurdas de segurança,
  • integração com Linux,
  • OpenShift,
  • containers,
  • APIs REST,
  • IA embarcada,
  • automação,
  • observabilidade,
  • criptografia quântica,
  • integração cloud híbrida,
  • DevOps,
  • Ansible,
  • Zowe,
  • Python no z/OS,
  • pipelines CI/CD,
  • modernização de CICS,
  • Db2 acelerado,
  • zCX,
  • Wazi,
  • integração com Kubernetes…

Ou seja:

o mainframe não ficou parado.

Muita gente ficou.

☕💾 O PROFISSIONAL MAINFRAME DE HOJE NÃO É MAIS “OPERADOR DE TELA VERDE”

Esse é talvez o maior choque cultural.

O profissional moderno de mainframe virou um híbrido raro no mercado.

Hoje ele precisa entender:

  • infraestrutura,
  • cloud,
  • segurança,
  • automação,
  • Linux,
  • APIs,
  • containers,
  • integração distribuída,
  • observabilidade,
  • DevOps,
  • redes,
  • performance,
  • IA,
  • além do velho e poderoso conhecimento de z/OS.

O cara que antes conhecia apenas:

  • JCL,
  • JES2,
  • TSO,
  • COBOL,
  • CICS,

…agora conversa com:

  • squads cloud,
  • times DevOps,
  • arquitetos AWS/Azure/GCP,
  • desenvolvedores Java,
  • SRE,
  • engenharia de plataforma,
  • segurança ofensiva,
  • APIs e microsserviços.

E isso muda completamente a carreira.

☕🔥 O MAINFRAME VIROU O “CORE ENGINE” DA CLOUD HÍBRIDA

Muita gente ainda pensa:
“Cloud substitui mainframe.”

Mas na prática o mercado percebeu algo diferente:

☁️ Cloud resolve elasticidade.
💾 Mainframe resolve missão crítica.

E o mundo corporativo descobriu que:

  • downtime custa bilhões,
  • segurança importa,
  • consistência importa,
  • throughput importa,
  • governança importa,
  • estabilidade importa.

Resultado?

O discurso mudou de:
“vamos eliminar o mainframe”

…para:
“como integrar o mainframe com cloud?”

Esse é o novo jogo.

E quem entende dos dois mundos virou profissional premium.

☕🚀 O PROFISSIONAL 50+ MAINFRAME NÃO ESTÁ ULTRAPASSADO

Esse talvez seja o ponto mais importante.

Existe uma geração inteira de profissionais carregando:

  • décadas de experiência,
  • conhecimento de negócio,
  • troubleshooting real,
  • visão sistêmica,
  • disciplina operacional,
  • capacidade analítica,
  • experiência em crises reais.

Essa experiência vale ouro.

Porque infraestrutura crítica não é TikTok.
Não é hype.
Não é framework da semana.

Banco não pode “dar refresh”.
PIX não pode travar.
Cartão não pode cair.
Folha de pagamento não pode falhar.

E quando tudo explode às 2h da manhã…
a empresa descobre rapidamente quem é profissional de verdade.

☕💡 O DESAFIO NÃO É IDADE. É ATUALIZAÇÃO.

O mercado não está descartando profissionais 50+.

O mercado está descartando quem:

  • parou no tempo,
  • rejeita aprender,
  • tem medo de mudança,
  • trata novidade como inimiga.

Porque hoje existe espaço gigantesco para:

  • mentor técnico,
  • especialista híbrido,
  • arquiteto legado/cloud,
  • modernização,
  • automação z/OS,
  • segurança,
  • observabilidade,
  • integração API/mainframe,
  • DevOps enterprise.

O profissional experiente que aprende:

  • Linux,
  • automação,
  • APIs,
  • Python,
  • cloud híbrida,
  • IA aplicada,
  • ferramentas modernas IBM,

vira praticamente um “unicórnio corporativo”.

☕🔥 IA NÃO VEIO PARA MATAR O MAINFRAME

Na verdade…

IA vai aumentar ainda mais a importância dos ambientes estáveis.

Porque IA precisa:

  • dados confiáveis,
  • processamento consistente,
  • segurança,
  • governança,
  • rastreabilidade.

E adivinha onde estão os dados mais críticos do planeta?

No mainframe.

O que muda é o papel do profissional.

Menos trabalho repetitivo.
Mais automação.
Mais integração.
Mais análise.
Mais arquitetura.
Mais inteligência operacional.

O futuro do mainframe não é apertar ENTER em tela verde.

É orquestrar ambientes híbridos gigantescos.

☕💾 HOME OFFICE MUDOU O JOGO

Antigamente o profissional mainframe era visto quase como:
“o cara preso no CPD.”

Hoje:

  • participa de reuniões globais,
  • trabalha remoto,
  • atende clientes internacionais,
  • opera ambientes gigantes de casa,
  • ensina online,
  • cria conteúdo,
  • ministra treinamento,
  • faz consultoria mundial.

O conhecimento ficou global.

E isso abriu espaço enorme para profissionais experientes.

☕🔥 O MAINFRAME NÃO MORREU. ELE EVOLUIU.

Talvez a maior mentira da TI tenha sido:
“mainframe vai acabar.”

O que acabou foi:

  • o isolamento do mainframe,
  • a cultura fechada,
  • o profissional que só conhecia um único mundo.

O novo profissional z/OS conversa com:

  • cloud,
  • Linux,
  • IA,
  • APIs,
  • automação,
  • DevSecOps,
  • observabilidade,
  • analytics,
  • containers.

E isso é fascinante.

☕🚀 UMA MENSAGEM PARA O PROFISSIONAL MAINFRAME 50+

Se você tem décadas de carreira:
não carregue vergonha da sua experiência.

Carregue orgulho.

Você sobreviveu:

  • a migração Y2K,
  • downsizing,
  • ondas Unix,
  • client/server,
  • virtualização,
  • internet,
  • cloud,
  • DevOps,
  • microsserviços,
  • IA…

…e o mainframe continua aqui.

Mas agora existe uma missão nova:

não proteger o passado.

E sim conectar o passado ao futuro.

Aprenda algo novo.
Teste Linux.
Brinque com Python.
Entenda cloud.
Automatize tarefas.
Explore IA.
Converse com equipes jovens.
Compartilhe experiência.

Porque o mercado não precisa apenas de juventude.

O mercado precisa de gente que entende o que acontece quando sistemas críticos realmente importam.

E nisso…
o profissional mainframe ainda é uma das peças mais valiosas da tecnologia mundial. ☕🔥

quinta-feira, 7 de maio de 2026

🔥☕ O CAMINHO DO PADAWAN Db2 — COMO UM PROGRAMADOR COBOL JÚNIOR SOBREVIVE AO MUNDO REAL DOS BANCOS NO MAINFRAME ☕🔥

 

Bellacosa Mainframe com dicas para padawan cobol dominar o db2

🔥☕ O CAMINHO DO PADAWAN Db2 — COMO UM PROGRAMADOR COBOL JÚNIOR SOBREVIVE AO MUNDO REAL DOS BANCOS NO MAINFRAME ☕🔥

Tem uma coisa que quase nenhum curso ensina direito.

O problema de aprender Db2 no mainframe NÃO é decorar:

  • SELECT

  • FETCH

  • CURSOR

  • JOIN

Isso qualquer apostila faz.

O verdadeiro desafio é entender:

🚀 COMO O Db2 “PENSA”

Porque no ambiente bancário:

  • performance é dinheiro

  • CPU custa milhões

  • lock errado derruba sistema

  • SQL ruim gera guerra entre desenvolvimento e DBA

  • um tablespace scan pode parar um banco inteiro

E é aqui que nasce a diferença entre:

  • um programador COBOL comum

  • e um verdadeiro guerreiro do z/OS.


☕ O MAIOR ERRO DO PADAWAN COBOL

Todo iniciante chega no Db2 tentando programar como se estivesse lendo VSAM.

Faz:

  • loop

  • READ

  • IF

  • PERFORM

  • validação manual

  • cursor desnecessário

e transforma o Db2 num simples “arquivo sofisticado”.

🔥 Grave isso:

Db2 NÃO é VSAM.

Db2 é:

  • relacional

  • baseado em conjuntos

  • otimizado matematicamente

  • orientado a custo

  • controlado por estatísticas


🚀 O PROGRAMADOR MAINFRAME MODERNO NÃO PENSA EM LINHAS

Ele pensa em:

SETS


☕ PROCESSAMENTO RELACIONAL

O programador antigo pensa assim:

“Vou buscar linha por linha e processar.”

O programador Db2 sênior pensa:

“Como faço o Db2 processar tudo sozinho?”

Essa mudança mental vale OURO.


🔥 SQL NÃO É APENAS CONSULTA

O padawan acha que SQL é:

SELECT *
FROM CLIENTE

Mas Db2 é MUITO maior:

  • optimizer

  • locking

  • clustering

  • filter factors

  • parallelism

  • stage 1/stage 2

  • access paths

  • static SQL

  • dynamic SQL

  • utilities

  • EXPLAIN

E quando você entende isso…
você começa a dominar o ambiente bancário.


☕ O OPTIMIZER É O VERDADEIRO “CÉREBRO” DO Db2

No mainframe bancário:

  • ninguém lê bilhões de linhas “na força”

  • ninguém faz scan por diversão

  • ninguém quer CPU extra

O optimizer decide:

  • qual índice usar

  • qual join usar

  • se haverá sort

  • se haverá prefetch

  • se haverá paralelismo


🚀 E O QUE O OPTIMIZER USA?

Estatísticas.

RUNSTATS é praticamente:

“os olhos do optimizer”

Sem estatísticas:

  • access path piora

  • índice é ignorado

  • FF fica errado

  • CPU explode


☕ FILTER FACTOR — O SEGREDO QUE MUITOS IGNORAM

Pouca gente iniciante entende isso.

Mas FF muda TUDO.

🚀 Filter Factor

é:

  • a estimativa da porcentagem de linhas que satisfazem um predicado.


☕ Exemplo

WHERE DEPT = 'A00'

Se existem:

  • 10 departamentos

Db2 estima:

1/10 = 0.1

Ou seja:

  • 10% das linhas serão retornadas.


🔥 Quanto MENOR o FF:

MELHOR

Porque:

  • menos linhas

  • menos I/O

  • menos CPU

  • menos pages

  • menos lock


☕ O ERRO CLÁSSICO DO PADAWAN

WHERE COL <> 'X'

🔥 Péssimo FF.

Db2 entende:

“quase todas as linhas servem”

Então:

  • índice perde valor

  • scan aparece

  • CPU sobe


🚀 INDEX NÃO É MAGIA

Outro choque do iniciante.

Ter índice NÃO garante performance.

O optimizer escolhe:

  • usar

  • ignorar

  • combinar

  • fazer screening

  • fazer scan

dependendo:

  • FF

  • cardinalidade

  • clustering

  • custo estimado


☕ O MUNDO REAL DOS BANCOS

Em banco grande:

  • tabela pode ter bilhões de linhas

  • índice pode ter centenas de GB

  • um SQL ruim pode consumir milhares de MIPS

Por isso:

access path é assunto sagrado.


🔥 STAGE 1 vs STAGE 2

Esse conceito separa:

  • SQL eficiente

  • SQL sofrível


☕ Stage 1

Predicado processado cedo:

  • no Data Manager

  • usando índice

  • reduzindo linhas rapidamente

Mais rápido.


☕ Stage 2

Predicado processado depois:

  • mais CPU

  • mais linhas avaliadas

  • menos eficiência


🚀 Exemplo ruim

WHERE YEAR(DATA) = 2025

Função na coluna:

  • pode matar indexabilidade

  • virar stage 2


☕ Melhor abordagem

WHERE DATA BETWEEN '2025-01-01'
AND '2025-12-31'

🔥 LOCKING — O TERROR DOS BANCOS

Padawan geralmente aprende SELECT…

mas não aprende:

concorrência.

E no banco:

  • milhares de programas acessam a mesma tabela ao mesmo tempo.


☕ Lock errado gera:

  • timeout

  • deadlock

  • lentidão

  • aplicação travada

  • fila no CICS

  • caos operacional


🚀 LOCKSIZE

Db2 pode bloquear:

  • row

  • page

  • table space


☕ O perigo do PAGE LOCK

Uma página pode conter:

  • várias linhas

Então:

  • um lock pode bloquear muitos registros sem você perceber.


🔥 ISOLATION LEVEL

Outro tema CRÍTICO.


☕ CS — Cursor Stability

Mais comum no OLTP bancário.

Balanceia:

  • integridade

  • concorrência


☕ RR — Repeatable Read

Mais rígido.
Mais locks.
Mais contenção.


☕ UR — Uncommitted Read

O famoso:

dirty read

Excelente para:

  • relatórios

  • analytics

  • consultas não críticas

Péssimo para:

  • saldo bancário

  • movimentação financeira

😄


🚀 COMO EVITAR DEADLOCK

O curso mostrou algo IMPORTANTÍSSIMO:

Todos os programas devem atualizar na mesma sequência.


☕ Exemplo

Programa A:

CLIENTE → CONTA

Programa B:

CONTA → CLIENTE

🔥 Receita perfeita para deadlock.


🚀 ACCESS PATH — A ALMA DO Db2

Toda query possui um plano.

Db2 decide:

  • scan

  • index access

  • nested loop

  • merge scan

  • hybrid join

  • hash join


☕ TABLESPACE SCAN

Lê tudo.

Pode ser:

  • correto

  • ou desastre absoluto.


☕ INDEXED ACCESS

Busca seletiva.

Muito mais eficiente quando:

  • FF é baixo

  • índice é adequado


🚀 JOINS — O CAMPO DE BATALHA

Padawan normalmente só aprende:

INNER JOIN

Mas Db2 usa:

  • nested loop

  • merge scan

  • hybrid join

  • star join

dependendo:

  • tamanho

  • índices

  • cardinalidade


☕ MERGE SCAN JOIN

Excelente para:

  • tabelas grandes

  • sem índices úteis

  • dados ordenados


🔥 STATIC SQL vs DYNAMIC SQL

No banco:
isso é discussão séria.


☕ STATIC SQL

Pré-compilado.
Pré-otimizado.

Perfeito para:

  • CICS

  • OLTP

  • alta performance


☕ DYNAMIC SQL

Construído runtime.

Excelente para:

  • analytics

  • ferramentas

  • SQL variável


🚀 Por que bancos AMAM STATIC SQL?

Porque:

  • menos CPU

  • menos prepare

  • access path estável

  • melhor governança


☕ EXPLAIN — O RAIO-X DO OPTIMIZER

Se você não usa EXPLAIN…
você está programando no escuro.


🚀 EXPLAIN mostra:

  • índice usado

  • tipo de join

  • matching columns

  • prefetch

  • paralelismo

  • custo estimado


☕ PLAN_TABLE

É praticamente:

a Bíblia do tuning Db2.


🔥 UNION vs UNION ALL

Padawan frequentemente usa:

UNION

sem perceber:

  • Db2 faz SORT

  • remove duplicatas

  • aumenta CPU


🚀 UNION ALL

Muito mais rápido.

Use quando:

  • duplicatas não importam.


☕ FETCH FIRST

Outro segredo simples que salva CPU.


❌ Errado

SELECT *
FROM BIGTABLE

✅ Melhor

FETCH FIRST 10 ROWS ONLY

🚀 “PEÇA SOMENTE O NECESSÁRIO”

Essa é uma filosofia inteira do Db2.


☕ EVITE ESCREVER CÓDIGO

A aula falou algo brilhante:

“Avoid Writing Code”


🚀 O Db2 já sabe:

  • somar

  • converter

  • truncar

  • upper/lower

  • calcular datas

  • agregar

  • ordenar

  • paralelizar

Então:

  • use funções SQL

  • use set processing

  • use procedures

  • use triggers


☕ O COBOL NÃO DEVE FAZER O QUE O Db2 FAZ MELHOR

Essa frase muda carreiras.


🔥 O SEGREDO FINAL

No ambiente bancário:
o programador COBOL NÃO domina apenas COBOL.

Ele precisa entender:

  • SQL

  • optimizer

  • access path

  • locking

  • concurrency

  • CPU

  • I/O

  • clustering

  • statistics

  • utilities

Porque:

o verdadeiro programa executa dentro do Db2.


☕ O PADAWAN VIRA MESTRE QUANDO ENTENDE:

“SQL não é uma linguagem de acesso.
SQL é uma linguagem de processamento.”

🔥☕ Welcome to the real mainframe world, padawan.

quarta-feira, 6 de maio de 2026

🔥☕ COUPLING FACILITY — O “CÉREBRO COLETIVO” DOS MAINFRAMES IBM z/OS ☕🔥

Bellacosa Mainframe mergulha no sysplex e comenta sobre CF coupling facility

🔥☕ COUPLING FACILITY — O “CÉREBRO COLETIVO” DOS MAINFRAMES IBM z/OS ☕🔥

O QUE TODO PROGRAMADOR COBOL PADAWAN PRECISA ENTENDER SOBRE O CORAÇÃO DO SYSPLEX

Imagine o seguinte cenário, jovem Padawan do COBOL:

Você possui:

  • vários mainframes IBM zSeries
  • executando o mesmo sistema z/OS
  • compartilhando banco Db2
  • compartilhando filas CICS
  • compartilhando cache
  • compartilhando locks
  • compartilhando discos DASD

…e todos precisam conversar em tempo real sem virar caos.

🔥 É aí que nasce a Coupling Facility (CF).


☕ O QUE É A COUPLING FACILITY?

A Coupling Facility é um componente especializado do ambiente IBM Parallel Sysplex.

Ela funciona como:

  • memória compartilhada ultra rápida
  • coordenador de sincronismo
  • gerenciador de locks
  • cache compartilhado
  • controlador de estruturas compartilhadas

Pense nela como:

“o cérebro central que sincroniza vários mainframes ao mesmo tempo.”


🏛 ORIGEM HISTÓRICA

A IBM criou o conceito nos anos 90 para resolver um problema gigantesco:

❌ Problema antigo

Antes do Parallel Sysplex:

  • cada mainframe era praticamente isolado
  • escalabilidade era limitada
  • failover era complicado
  • compartilhamento de dados era lento

✅ Solução IBM

Criaram:

IBM Parallel Sysplex

com:

  • múltiplos LPARs
  • múltiplos z/OS
  • múltiplos CICS
  • múltiplos Db2
  • tudo operando como “um único supercomputador”.

E a Coupling Facility virou o coração disso tudo.


🧠 ANALOGIA ESTILO BELLACOSA

Imagine:

ElementoMundo Real
z/OSpessoas trabalhando
Db2arquivos/documentos
CICSatendentes
Coupling Facilitycentral de coordenação
Lock Structuresemáforo
Cache Structurememória compartilhada
List Structurefila organizada

🔥 O QUE A COUPLING FACILITY FAZ?

Ela trabalha principalmente com:

EstruturaFunção
Lock Structurecontrole de locks
Cache Structurecache compartilhado
List Structurefilas/listas
Serializationsincronismo
Signalingcomunicação entre sistemas

🔷 TIPOS DE ESTRUTURA

1️⃣ LOCK STRUCTURE

Usada por:

  • Db2
  • GRS
  • CICS

Ela evita:

  • deadlock
  • update simultâneo
  • corrupção de dados

2️⃣ CACHE STRUCTURE

Mantém dados em memória compartilhada.

Exemplo:

  • buffer pools do Db2
  • cache CICS
  • VSAM RLS

Isso reduz I/O em disco absurdamente.


3️⃣ LIST STRUCTURE

Funciona como fila compartilhada.

Muito usada em:

  • WebSphere MQ
  • CICS TS Queue
  • Workload balancing

⚡ COMO FUNCIONA NA PRÁTICA

Imagine dois Db2:

SistemaAção
DB2Aatualiza cliente
DB2Btenta ler mesmo cliente

A CF entra no meio:

  1. DB2A pega lock
  2. CF registra lock
  3. DB2B consulta CF
  4. CF responde:
    • “registro bloqueado”
  5. DB2B espera

🔥 Resultado:
consistência total.


🏗 COMPONENTES IMPORTANTES

ComponenteDescrição
CFRMCoupling Facility Resource Management
XCFCross-system Coupling Facility
IXLCONNconecta aplicações
IXLLISTmanipula listas
IXLCACHEcache compartilhado
IXLLOCKlock manager

🔥 XCF — O “WHATSAPP” DOS MAINFRAMES

O XCF:

  • conecta sistemas do sysplex
  • troca mensagens
  • detecta falhas
  • coordena membros

Sem XCF:
❌ não existe sysplex moderno.


📦 ONDE A CF EXISTE?

Pode existir:

TipoDescrição
Internal CFdentro do próprio CPC
External CFmáquina dedicada
Integrated CF (ICF)processador especializado

🧩 COMO O COBOL JÚNIOR “SENTE” A CF?

Mesmo sem perceber…

você usa CF quando:

  • roda Db2 Data Sharing
  • acessa CICS em sysplex
  • usa VSAM RLS
  • usa MQ Shared Queue

Ou seja:

🔥 praticamente todo ambiente enterprise moderno.


🔎 COMO VER INFORMAÇÕES DA CF?

COMANDO D XCF

D XCF,CF

Mostra:

  • CFs ativas
  • status
  • conectividade
  • estruturas

🔎 LISTAR ESTRUTURAS

D XCF,STR

🔎 VER SYSLEX

D XCF,SYSPLEX

🔎 NO SDSF

Painéis:

PainelUso
RMFperformance
SDSF LOGmensagens
DAdevices
ENCenclosures

📊 MONITORAMENTO

Ferramentas clássicas:

FerramentaUso
RMF Monitor IIIperformance CF
OMEGAMONanálise avançada
IBM Tivolimonitoramento
SMF 74métricas da CF

🔥 SMF 74 — O TESOURO ESCONDIDO

O record:

SMF Type 74

guarda:

  • uso de estruturas
  • tempo de resposta
  • lock contention
  • taxa de requests
  • rebuilds

Subtipos importantes:

SubtypeUso
74-4CF Activity
74-5CF Cache
74-7Lock info

🔥 COMANDOS IMPORTANTES

VER DETALHES

D XCF,CF,CFNAME=CF01

VER ESTRUTURA

D XCF,STR,STRNAME=DB2LOCK1

REBUILD

SETXCF START,REBUILD,STRNAME=DB2LOCK1

⚠️ ERROS CLÁSSICOS

1️⃣ STRUCTURE FULL

Mensagem:

IXL015I STRUCTURE FULL

Significa:

  • estrutura sem espaço
  • excesso de locks/cache/lista

COMO ANALISAR

Ver:

D XCF,STR

Checar:

  • INITSIZE
  • SIZE
  • uso %

CORREÇÃO

Aumentar no CFRM Policy:

SIZE(50000)

2️⃣ REBUILD PENDING

Estrutura precisa rebuild.

Causas:

  • falha CF
  • perda conectividade
  • overload

CORREÇÃO

SETXCF START,REBUILD

3️⃣ PATH FAILURE

Links ICA/IFB falhando.

Pode causar:

  • degradação
  • perda de sincronismo

VERIFICAR

D XCF,PATH

4️⃣ LOCK CONTENTION

Db2 “travando tudo”.

Sintomas:

  • timeout
  • deadlock
  • lentidão

ANALISAR

  • IFCID 172
  • IFCID 196
  • RMF
  • DISPLAY DATABASE LOCKS

🧠 COMO INTERPRETAR PERFORMANCE

Indicadores importantes

MétricaSignificado
Request Raterequisições
Service Timelatência
Lock Contentiondisputa
Rebuild Countrebuilds
CF CPUuso CPU

🔥 LATÊNCIA É TUDO

No sysplex:

microsegundos importam.

Porque:

  • Db2 faz milhões de requests
  • CICS faz milhares por segundo
  • MQ sincroniza filas

Se a CF atrasar:
🔥 o sysplex inteiro sofre.


⚡ CURIOSIDADES ABSURDAS

🔥 A CF NÃO RODA z/OS

Ela roda firmware especializado.

É quase um “mini sistema operacional secreto IBM”.


🔥 UMA CF PODE CONTROLAR VÁRIOS MAINFRAMES

Grandes bancos possuem:

  • dezenas de LPARs
  • múltiplas CFs
  • sysplex gigantescos

🔥 EXISTE FAILOVER DE CF

Se uma CF morrer:

outra assume.

Isso é chamado:

Duplexing / Rebuild


🥚 EASTER EGGS MAINFRAME

🥚 O nome “Coupling”

Vem da engenharia mecânica:

coupling = acoplamento

Ela “acopla” sistemas.


🥚 O sysplex já foi considerado “cloud antes da cloud”

Porque:

  • compartilhava recursos
  • balanceava carga
  • permitia failover automático

Anos antes da computação em nuvem moderna.


🔥 EXEMPLO REAL — DB2 DATA SHARING

Imagine:

SistemaTransações
DB2Ainternet banking
DB2BPIX
DB2CATM
DB2Dcartão

Todos compartilham:

  • mesmos dados
  • mesmos locks
  • mesmo cache

Tudo coordenado pela CF.

Sem ela:
💥 corrupção total.


🛠 PASSO A PASSO PARA INVESTIGAR PROBLEMAS

ETAPA 1 — Verificar estruturas

D XCF,STR

ETAPA 2 — Verificar CF

D XCF,CF

ETAPA 3 — Verificar paths

D XCF,PATH

ETAPA 4 — Analisar RMF

Ver:

  • latency
  • request rate
  • rebuild

ETAPA 5 — Verificar mensagens

No SDSF LOG:

Procure:

IXL
IXC
CF

ETAPA 6 — Verificar Db2

Comandos:

-DISPLAY GROUP
-DISPLAY DATABASE LOCKS

☕ RESUMO BELLACOSA MAINFRAME

Coupling Facility é:

✅ o coração do Parallel Sysplex
✅ sincronismo ultra rápido
✅ lock manager distribuído
✅ cache compartilhado
✅ coordenador do Db2 Data Sharing
✅ base do CICS moderno
✅ peça crítica da alta disponibilidade IBM


🔥 FRASE FINAL DO PADAWAN MAINFRAME

“Quando vários mainframes parecem um só…
existe uma Coupling Facility trabalhando silenciosamente nos bastidores.” ☕🔥

terça-feira, 5 de maio de 2026

IBM Sovereign Core : Quando Hercule Poirot Descobre que o Verdadeiro Criminoso Nunca Foi o Hacker

 

Bellacosa Mainframe ibm sovereign core 

☕ Um Café no Bellacosa Mainframe

IBM Sovereign Core sem Mistérios para Programadores COBOL

Quando Hercule Poirot Descobre que o Verdadeiro Criminoso Nunca Foi o Hacker… Mas a Falta de Controle Sobre Quem Controla o Sistema

"As pequenas células cinzentas nunca falham, meu amigo. O erro está quase sempre naquilo que ninguém resolveu investigar." — Hercule Poirot (adaptado)


Introdução – Um Crime Perfeito no Datacenter

Imagine que Hercule Poirot fosse contratado para investigar um grande banco.

Ninguém roubou dinheiro.

Nenhum servidor explodiu.

Nenhum disco queimou.

Nenhum programa COBOL apresentou ABEND.

Tudo parece absolutamente normal.

Mesmo assim...

Segredos desapareceram.

Credenciais privilegiadas foram utilizadas.

Bibliotecas desconhecidas chegaram à produção.

Uma Inteligência Artificial tomou decisões sem ninguém saber exatamente por quê.

Logs foram apagados.

E o mais intrigante:

Os dados jamais saíram do datacenter.

Poirot sorri.

Ele ajeita o bigode.

Observa cada detalhe.

E faz apenas uma pergunta.

"Mon ami... quem realmente controla esta aplicação?"

Silêncio.

É exatamente essa pergunta que o IBM Sovereign Core procura responder.

E ela é muito mais profunda do que parece.

Hoje vamos investigar esse mistério como verdadeiros detetives da computação corporativa.



Capítulo 1 — O Primeiro Suspeito Sempre é o Lugar Errado

Quando ouvimos falar em Soberania Digital, quase todo mundo pensa imediatamente em localização.

"Os servidores estão no Brasil."

"Os dados ficam em nosso datacenter."

"Nossa cloud é privada."

Caso encerrado?

Nem de longe.

Poirot jamais condenaria alguém apenas porque estava próximo da cena do crime.

Da mesma forma, um sistema não é soberano apenas porque está fisicamente dentro do prédio da empresa.

Imagine um castelo medieval.

As muralhas são enormes.

Os portões são reforçados.

Os guardas vigiam todas as entradas.

Mas...

Quem possui a chave da sala do tesouro?

Quem controla os guardas?

Quem decide quem entra?

Quem administra os cofres?

Quem entrega novas armas?

Se essas respostas pertencem a terceiros...

O castelo nunca foi realmente seu.


O Primeiro Easter Egg

Sherlock Holmes dizia:

"Quando eliminamos o impossível..."

Poirot discordaria.

Ele diria:

"Antes de eliminar qualquer hipótese, descubra quem possui as chaves."

Essa diferença resume perfeitamente o IBM Sovereign Core.


Capítulo 2 — O Control Plane: O Cérebro Invisível

O primeiro bloco do infográfico apresenta um termo que muitos iniciantes nunca ouviram:

Control Plane.

Vamos imaginar uma agência bancária.

Existe:

  • caixa

  • gerente

  • clientes

  • cofres

Esses são os trabalhadores.

Agora imagine outro departamento.

Lá ficam:

  • diretor

  • segurança

  • RH

  • auditoria

  • controle de acesso

Eles não atendem clientes.

Mas controlam absolutamente tudo.

Isso é o Control Plane.

No Kubernetes...

No OpenShift...

Na Cloud...

No IBM Sovereign Core...

O Control Plane decide:

Quem entra

↓

Quem sai

↓

Quem implanta

↓

Quem administra

↓

Quem altera configurações

↓

Quem possui privilégios

Sem ele existe apenas caos organizado.


Curiosidade Bellacosa

No mundo Mainframe isso não é novidade.

Desde décadas atrás o z/OS já separava claramente:

  • processamento

  • administração

  • segurança

Muito antes da palavra Cloud existir.



Capítulo 3 — IAM: O Grande Livro de Convidados

Poirot sempre perguntava:

"Quem esteve na mansão naquela noite?"

Na informática fazemos exatamente a mesma pergunta.

IAM significa:

Identity and Access Management.

Ou:

Quem é você?

O que pode fazer?

Até onde pode ir?

Quando pode entrar?

Imagine um banco.

Carlos trabalha no atendimento.

Maria é DBA.

João administra RACF.

A Inteligência Artificial responde clientes.

Todos possuem identidades diferentes.

Todos possuem permissões diferentes.

Isso parece simples.

Mas aqui nasce um dos maiores problemas da computação moderna.


O Erro Clássico

Programador iniciante:

Usuário

ADMIN

Senha

123456

Ou pior.

root

root

Ou ainda:

admin

admin

Poirot levantaria uma sobrancelha.

"O assassino praticamente deixou seu cartão de visitas."


Dica Bellacosa

Jamais utilize usuários compartilhados.

Cada pessoa.

Cada serviço.

Cada robô.

Cada IA.

Deve possuir sua própria identidade.


Capítulo 4 — O Mistério dos Secrets

Agora chegamos ao quarto suspeito.

Os famosos:

Secrets.

Senha.

Token.

API Key.

Certificado.

Connection String.

Muitos iniciantes fazem isso:

MOVE "SenhaDoBanco123" TO WS-PASSWORD.

Ou:

password="admin123"

Ou:

apikey=ABCDEFG12345

Tudo dentro do Git.

Tudo dentro do fonte.

Poirot nem precisaria investigar muito.

O culpado praticamente escreveu uma carta confessando.


Como funciona corretamente?

Hoje utilizamos cofres digitais.

Por exemplo:

Vault

IBM Secrets Manager

Hashicorp Vault

Key Protect

O programa nunca conhece a senha permanentemente.

Ela é entregue apenas durante a execução.

Terminou?

Ela desaparece.


Capítulo 5 — A Cadeia de Fornecimento do Crime

Uma frase do artigo merece destaque.

Um build bem sucedido não significa software seguro.

Que frase maravilhosa.

Imagine uma fábrica de automóveis.

O carro foi montado.

Funcionou.

Mas...

Os freios vieram de onde?

Os pneus são originais?

O airbag possui defeitos?

O parafuso veio de fornecedor confiável?

Software moderno funciona exatamente assim.


Software Supply Chain

Hoje um simples programa Java pode utilizar:

2 bibliotecas próprias

+

580 bibliotecas externas

+

Containers

+

Frameworks

+

Dependências transitivas

O desenvolvedor nem conhece metade delas.


Curiosidade

O ataque à SolarWinds mostrou ao mundo inteiro que não basta proteger seu sistema.

Também é preciso proteger quem entrega o software.

Foi um dos maiores marcos da história da segurança.


Capítulo 6 — SBOM: O Inventário do Crime

Poirot adorava listas.

Quem entrou?

Quem saiu?

Quem jantou?

Quem segurava a faca?

SBOM faz exatamente isso.

Software Bill of Materials.

Uma lista completa contendo:

Bibliotecas

↓

Versões

↓

Dependências

↓

Licenças

↓

Componentes

↓

Fabricantes

Imagine perguntar:

"Meu sistema utiliza Log4j?"

Sem SBOM...

Boa sorte.

Com SBOM...

Você descobre em segundos.


Easter Egg Mainframe

Sabe aqueles enormes inventários de Load Modules feitos há décadas?

A filosofia é surpreendentemente parecida.

Os conceitos mudam.

A necessidade permanece.


Capítulo 7 — Compliance: O Inspetor Japp Aprovaria

Compliance significa provar.

Não basta dizer.

É necessário demonstrar.

Quem compilou?

Quem aprovou?

Quem publicou?

Quem executou?

Quando?

Em qual ambiente?

Isso é investigação.

Isso é rastreabilidade.


Capítulo 8 — A IA Também é Suspeita

Aqui está talvez o trecho mais interessante de todo o IBM Sovereign Core.

Muita gente acredita:

"Minha IA roda localmente."

Então está segura.

Errado.

Imagine um agente de IA capaz de:

Consultar Db2.

Enviar PIX.

Ler e-mails.

Modificar contratos.

Atualizar clientes.

Excluir registros.

Tudo isso localmente.

Ela continua sendo perigosíssima.


Poirot faria apenas uma pergunta

Quem autorizou esse agente?

Quem aprovou?

Quem auditou?

Quem acompanha suas ações?


Agentes Precisam de Identidade

Hoje falamos muito sobre IA.

Mas esquecemos algo essencial.

Um agente é quase um funcionário digital.

Ele precisa possuir:

Identidade

↓

Permissões

↓

Limites

↓

Ferramentas autorizadas

↓

Logs

↓

Auditoria

Jamais:

Administrador Universal

Capítulo 9 — O Princípio do Menor Privilégio

Imagine uma copeira.

Ela possui acesso à cozinha.

Mas não ao cofre do banco.

Imagine o gerente.

Ele pode aprovar empréstimos.

Mas não alterar o sistema operacional.

Esse conceito chama-se:

Least Privilege.

No RACF ele existe há décadas.

No IBM Sovereign Core ele continua absolutamente essencial.


Capítulo 10 — Audit Logging: As Pegadas do Assassino

Poirot resolvia crimes observando pequenas pistas.

Na computação fazemos exatamente o mesmo.

Logs.

Muitos logs.

Imagine:

09:10

Agente IA acessou Db2

↓

09:11

Consultou CPF

↓

09:12

Chamou API

↓

09:13

Gerou contrato

↓

09:14

Enviou e-mail

Tudo registrado.

Sem logs...

Não existe investigação.


O Mainframe Sorri em Silêncio

Aqui está uma curiosidade fantástica.

Enquanto Cloud começa agora a falar sobre:

  • rastreabilidade

  • identidade

  • auditoria

  • governança

O Mainframe faz isso desde muito antes da internet comercial.

RACF.

SMF.

SAF.

ICSF.

Operlog.

SYSLOG.

RMF.

São décadas de experiência acumulada.


Comparando os Dois Mundos

IBM Sovereign CoreIBM Mainframe
IAMRACF
SecretsRACF Keyrings / ICSF
AuditSMF
CompliancezSecure
DeployEndevor, ISPW, DBB
GovernanceChange Management
Control Planez/OS + RACF + HMC
AI Governancewatsonx + IBM Z

Percebe?

Muitos conceitos considerados "novos" são, na verdade, uma evolução de práticas consolidadas no ambiente IBM Z.


Passo a Passo para um Programador COBOL Iniciante

Se você está começando no universo corporativo, este é um roteiro prático inspirado nos princípios do IBM Sovereign Core:

  1. Nunca grave senhas ou chaves diretamente no código-fonte.

  2. Aprenda os fundamentos de RACF e do conceito de IAM.

  3. Entenda o que é um pipeline CI/CD e como ele publica software.

  4. Estude SBOM e descubra como identificar dependências de um projeto.

  5. Conheça o princípio do menor privilégio e aplique-o em programas, usuários e serviços.

  6. Aprenda a interpretar logs e auditorias (SMF, SYSLOG, logs de aplicações e APIs).

  7. Entenda que um agente de IA deve ser tratado como um usuário corporativo, com identidade própria e permissões limitadas.

  8. Perceba que segurança não é uma etapa final do projeto; ela acompanha todo o ciclo de vida do software.


As Pequenas Células Cinzentas do Programador

Hercule Poirot sempre dizia que os maiores mistérios eram resolvidos observando detalhes aparentemente insignificantes.

No desenvolvimento corporativo acontece exatamente a mesma coisa.

O grande incidente raramente começa com um hacker digitando comandos em uma tela preta.

Ele costuma começar com uma pequena decisão aparentemente inocente:

  • uma senha gravada no código;

  • uma biblioteca sem verificação de origem;

  • um usuário compartilhado entre equipes;

  • um pipeline sem auditoria;

  • um agente de IA executando tarefas sem identidade própria.

Cada uma dessas decisões, isoladamente, parece inofensiva. Juntas, formam o cenário perfeito para um incidente difícil de investigar.

É por isso que o IBM Sovereign Core muda a pergunta tradicional de "Onde meus dados estão?" para uma questão muito mais inteligente:

"Quem controla identidades, segredos, componentes, implantações, auditorias e agentes de IA?"

Essa mudança de perspectiva representa a essência da soberania digital moderna.


Conclusão — O Último Caso de Hercule Poirot

Ao final da investigação, Poirot reúne todos na biblioteca do banco.

Há desenvolvedores.

Administradores.

Especialistas em segurança.

Auditores.

Arquitetos de cloud.

Operadores de mainframe.

E até um agente de Inteligência Artificial.

Todos esperam que ele revele o nome do culpado.

Poirot sorri discretamente.

Ajeita o bigode.

Olha para cada um dos presentes e diz:

"Mesdames et Messieurs... o verdadeiro criminoso nunca foi a cloud, a IA, o Kubernetes ou o IBM Z. O culpado sempre foi a ausência de governança."

Silêncio absoluto.

Ele continua:

"Quando identidades não são controladas, segredos ficam expostos, componentes não são rastreados, implantações não são reproduzíveis e agentes de IA agem sem limites, o crime já aconteceu antes mesmo do primeiro ataque."

É nesse momento que percebemos a verdadeira lição do IBM Sovereign Core: soberania digital não é um lugar, é um conjunto de responsabilidades continuamente verificadas.

Como diria Poirot, o caso nunca foi descobrir onde a aplicação executa. O verdadeiro enigma sempre foi descobrir quem realmente segura as chaves do castelo. E, no mundo moderno, essa resposta define se uma organização está apenas hospedando seus sistemas ou se, de fato, mantém o controle sobre seu próprio destino digital.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...