⚽A Copa do Mundo Explica Melhor a Engenharia de Software do que Muitos Livros

 

Bellacosa Mainframe e os ensinamentos da Copa para a gestão de projetos

☕ Um Café no Bellacosa Mainframe: 

⚽A Copa do Mundo Explica Melhor a Engenharia de Software do que Muitos Livros

---

O Mainframe e a Copa do Mundo

Imagine por um instante.

Uma empresa possui um ambiente IBM Z responsável por bilhões de reais em transações.

Durante quatro anos toda a equipe trabalha.

Desenvolvem sistemas.
Corrigem defeitos.
Treinam.
Criam processos.
Modernizam aplicações.

Então chega um único dia.

O Black Friday.
O fechamento anual.
A migração crítica.
O IPL planejado.
A auditoria internacional.

O dia de pagamento dos velhinhos aposentados.

É exatamente isso que a Copa representa.

Quatro anos de preparação para poucas partidas onde o mundo inteiro está assistindo.

No futebol existe a Copa.

No mainframe existem os grandes projetos.

---

1. A convocação

Nem todo jogador vai para a Copa.

Nem todo programador participa dos projetos estratégicos.

Ser escolhido significa que alguém acredita que você suporta pressão.

Isso muda completamente a carreira.

No futebol:

"Convocado para a Seleção Brasileira."

No mainframe:

"Ele vai liderar a migração para o COBOL 6.5."

Ou

"Ele ficará responsável pelo projeto PIX."

Ou

"Ele participará do Disaster Recovery."

Esses projetos ficam para sempre no currículo.

---

2. A camisa pesa

Existe uma frase famosa:

"A camisa pesa."

Vestir a camisa da Seleção Brasileira significa carregar décadas de história.

Vestir a camisa de um grande banco também.

Quando alguém trabalha em um grande banco, seguradora ou governo, ele representa muito mais do que seu próprio trabalho.

Ele representa:

• confiança

• estabilidade

• disponibilidade

• bilhões de transações

Existe responsabilidade.

---

3. A vitrine mundial

Na Copa todos estão olhando.

Na produção acontece exatamente igual.

Enquanto o sistema funciona...

ninguém percebe.

Quando ele para...

jornais noticiam.

Clientes reclamam.

Executivos aparecem.

Auditores chegam.

Assim como um atacante pode decidir uma Copa em um único chute, um desenvolvedor pode decidir um projeto inteiro com uma única alteração.

---

4. O desempenho muda uma carreira

Após uma boa Copa.

Um jogador pode:

• triplicar salário

• mudar para um grande clube

• tornar-se ídolo

• receber patrocínios

• crianças sendo batizadas com o nome do craque

Depois de um grande projeto ocorre o mesmo.

Quem resolve incidentes críticos normalmente passa a ser lembrado.

Não apenas pelo gerente.

Mas por outras áreas.

Outras empresas.

Consultorias.

Clientes.

Grandes carreiras costumam nascer em grandes desafios.

---

5. O fracasso também fica registrado

Infelizmente também acontece o contrário.

Um erro em uma final permanece por décadas.

O mesmo acontece na TI.

Existe uma enorme diferença entre:

"Cometeu um erro."

e

"Escondeu o erro."

Profissionais maduros assumem responsabilidade.

Aprendem.

Melhoram.

---

6. O ego destrói equipes

Talvez seja uma das maiores lições.

Alguns atletas tornam-se milionários muito cedo.

Passam a acreditar que são maiores que:

• treinador

• comissão técnica

• grupo

• disciplina

Na tecnologia isso também existe.

O desenvolvedor que acredita saber tudo.

Que não aceita revisão.

Que ignora padrões.

Que despreza documentação.

Que não participa das cerimônias.

Que não ajuda iniciantes.

Esse profissional pode ser tecnicamente excelente.

Mas prejudica a equipe.

---

7. Talento não vence sozinho

A história da Copa mostra isso diversas vezes.

Times repletos de estrelas já foram eliminados cedo.

Enquanto equipes organizadas chegaram muito longe.

No desenvolvimento acontece igual.

Uma equipe composta por profissionais "nota 8" que colaboram normalmente supera uma equipe formada por "gênios" que trabalham isoladamente.

---

8. O técnico existe por um motivo

O treinador enxerga o campo inteiro.

O jogador vê apenas sua posição.

O arquiteto de software faz exatamente isso.

O gerente técnico também.

O Tech Lead também.

Às vezes uma decisão parece ruim para um desenvolvedor.

Mas excelente para o projeto inteiro.

Quem vê somente uma classe Java ou um programa COBOL não enxerga toda a arquitetura.

---

9. O empresário não deveria escalar o time

Você citou um ponto delicado.

Quando interesses externos influenciam decisões técnicas...

o projeto sofre.

No futebol:

patrocínio

marketing

pressão política

Na TI:

• tecnologia da moda

• fornecedor pressionando

• gerente querendo atalhos

• decisões baseadas em ego

Boas arquiteturas são escolhidas porque resolvem problemas.

Não porque estão na moda.

---

10. A estrela depende do time

Messi.

Maradona.

Pelé.

Zidane.

Nenhum ganhou sozinho.

Mesmo os maiores precisavam de:

• goleiro

• zagueiros

• laterais

• meio-campo

No mainframe:

o melhor programador depende de:

• operadores

• DBA

• Sysprog

• segurança

• redes

• storage

• analistas

• testes

• negócio

Sem eles nada funciona.

---

11. O elo mais fraco determina a corrente

Talvez seja sua melhor analogia.

Em engenharia existe um conceito parecido.

A disponibilidade de um sistema costuma ser limitada pelo componente menos confiável.

Em equipes ocorre o mesmo.

Imagine cinco profissionais.

Um domina COBOL.

Outro Db2.

Outro CICS.

Outro MQ.

Outro começou há três meses.

O erro seria dizer:

"Ele que se vire."

O correto é:

"Vamos treiná-lo."

Porque no dia da implantação...

se ele falhar...

todos falham.

---

12. Mentoria é investimento

Grandes seleções possuem veteranos.

Eles ensinam.

Orientam.

Protegem os jovens.

No mainframe isso é ouro.

O profissional sênior não perde tempo ensinando.

Ele reduz futuros incidentes.

Cada hora investida em treinamento economiza dezenas de horas em produção.

---

13. O banco de reservas importa

Na Copa existem reservas.

No mainframe também deveria existir.

Se apenas uma pessoa conhece determinado sistema...

o risco é enorme.

Chamamos isso de fator ônibus (Bus Factor):

Quantas pessoas poderiam deixar a equipe antes que o projeto ficasse comprometido?

Quanto menor esse número, maior o risco operacional.

---

14. O treino invisível vence o jogo

O torcedor vê apenas noventa minutos.

Não vê:

• preparação física

• alimentação

• fisioterapia

• análise de vídeos

• treinos táticos

No desenvolvimento acontece igual.

O cliente vê apenas:

"O sistema funcionou."

Mas por trás existiram:

• testes

• code review

• documentação

• planejamento

• homologação

• automação

• monitoramento

• rollback

• backups

O sucesso quase sempre nasce do trabalho invisível.

---

15. O verdadeiro campeão faz o companheiro jogar melhor

Existe uma diferença enorme entre:

um craque

e

um líder.

O craque resolve jogadas.

O líder melhora o time inteiro.

No desenvolvimento isso é ainda mais importante.

O melhor profissional não é necessariamente aquele que escreve o código mais complexo.

É aquele que faz todos ao redor crescerem.

Que compartilha conhecimento.

Que revisa código com respeito.

Que documenta.

Que orienta.

Que inspira confiança.

---

A maior lição para um Programador COBOL Padawan

No universo do mainframe, não existem Copas do Mundo anuais. Existem projetos que, pela sua criticidade e visibilidade, equivalem a uma final diante de bilhões de "torcedores": uma migração de versão do COBOL, a implantação de um novo sistema de pagamentos, um Disaster Recovery ou a abertura de um grande banco em um dia de pico.

Quando esse momento chega, ninguém se lembra apenas de quem escreveu o algoritmo mais sofisticado. Lembram-se da equipe que entregou estabilidade, confiabilidade e colaboração.

Assim como no futebol, o talento individual chama atenção, mas são a disciplina, o treinamento constante, a humildade para aprender, o respeito às decisões coletivas e a disposição para fortalecer o colega com mais dificuldade que transformam um grupo de bons profissionais em um time campeão.

No fim das contas, um mainframe em produção e uma seleção em campo compartilham o mesmo princípio: o objetivo não é que um integrante brilhe sozinho, mas que o sistema inteiro — ou o time inteiro — funcione de forma harmoniosa até alcançar a vitória. É essa mentalidade que diferencia um bom programador de um verdadeiro profissional preparado para os maiores desafios da carreira.

 

Bellacosa Mainframe em Lab TPS 

💣🔥 LAB DE GUERRA — FINTECH NO z/OS: TPS REAL, LEDGER CONSISTENTE E MULTI-REGIÃO SEM ILUSÃO 🔥💣

Aqui não é slide. Aqui é produção simulada.
Você vai montar um fluxo que separa quem roda código de quem segura banco no ar.

---

⚙️ VISÃO DO LAB (ARQUITETURA)

👉 Dois mundos:

🔴 Região BR (CICS AOR)

• Entrada da transação
• Validação
• Débito local (ledger consistente)

🔵 Região MX (CICS AOR)

• Recebe evento assíncrono
• Aplica crédito

⚫ TOR (Terminal Owning Region)

• Entrada de carga (simulação TPS)

---

🧠 OBJETIVO DO LAB

Você vai provar na prática:

• 💰 Ledger consistente localmente
• ♻️ Idempotência salvando sua vida
• 🔁 Assíncrono dominando multi-região
• 📊 TPS ≠ Throughput (medido, não teórico)

---

📦 COMPONENTES

• COBOL (CICS)
• VSAM KSDS (ledger)
• DB2 (controle/idempotência)
• TSQ/TDQ (fila assíncrona simulando Kafka)
• JCL (carga batch TPS)

---

🧾 1. LEDGER CONSISTENTE (COBOL + VSAM)

💣 Aqui não tem brincadeira: saldo é consistência forte local

Estrutura VSAM

ACCOUNT-ID     PIC X(10)
BALANCE        PIC S9(15)V99
LAST-UPDATE    PIC X(26)

COBOL (CICS - débito)

EXEC CICS READ
  FILE('LEDGER')
  INTO(WS-ACCOUNT)
  RIDFLD(WS-ACCOUNT-ID)
END-EXEC

IF WS-BALANCE < WS-AMOUNT
   MOVE 'INSUFFICIENT' TO WS-STATUS
   EXEC CICS ABEND END-EXEC
END-IF

SUBTRACT WS-AMOUNT FROM WS-BALANCE

EXEC CICS REWRITE
  FILE('LEDGER')
  FROM(WS-ACCOUNT)
END-EXEC

🔥 Isso aqui é o seu TPS real
👉 Só conta se COMMITOU

---

♻️ 2. IDEMPOTÊNCIA (DB2 — ANTI-DUPLICAÇÃO)

💣 Sem isso, retry vira fraude.

Tabela DB2

CREATE TABLE TX_CONTROL (
  TX_ID        VARCHAR(36) PRIMARY KEY,
  STATUS       VARCHAR(10),
  CREATED_AT   TIMESTAMP
);

Lógica COBOL

EXEC SQL
  SELECT STATUS INTO :WS-STATUS
  FROM TX_CONTROL
  WHERE TX_ID = :WS-TX-ID
END-EXEC

IF SQLCODE = 0
   MOVE 'DUPLICATE' TO WS-STATUS
   GOBACK
END-IF

EXEC SQL
  INSERT INTO TX_CONTROL VALUES (:WS-TX-ID, 'NEW', CURRENT TIMESTAMP)
END-EXEC

🔥 Resultado:

• Retry seguro
• Zero duplicação
• TPS protegido

---

🔁 3. FLUXO ASSÍNCRONO (TSQ/TDQ)

💣 Aqui nasce a escalabilidade.

Após débito (BR)

EXEC CICS WRITEQ TS
  QUEUE('TXQUEUE')
  FROM(WS-EVENT)
END-EXEC

Consumidor (MX)

EXEC CICS READQ TS
  QUEUE('TXQUEUE')
  INTO(WS-EVENT)
END-EXEC

🔥 Tradução moderna:

Você acabou de simular Kafka no mainframe raiz.

---

🌍 4. MULTI-REGIÃO (SIMULADO)

💣 Não existe commit distribuído aqui.

Fluxo:

1. BR debita (consistente)
2. Evento vai para fila
3. MX processa depois
4. Reconciliação se falhar

👉 Isso evita:

• lock global
• latência absurda
• TPS morto

---

📊 5. SIMULAÇÃO REAL — TPS vs THROUGHPUT

JCL de carga

//LOADTPS JOB ...
//STEP1 EXEC PGM=TXGEN
//SYSIN DD *
  TPS=10000
  DURATION=60
/*

---

Resultado esperado

Métrica	Valor
Requests/s	10.000
TPS real	2.500–4.000
Latência	50–300ms
Retry	5–15%

---

💣 Interpretação Bellacosa:

• Throughput alto = sistema ocupado
• TPS alto = sistema fazendo dinheiro acontecer

---

⚠️ TESTES DE CAOS (OBRIGATÓRIO)

👉 Derrube o consumidor (MX)

• TPS local continua alto
• Fila cresce

👉 Simule duplicação

• Idempotência segura

👉 Force latência

• TPS cai se você errar arquitetura

---

☠️ LIÇÃO FINAL

Sistema financeiro NÃO escala com tecnologia.
Escala com decisão arquitetural consciente.

---

🔥 FECHAMENTO (NÍVEL PRODUÇÃO)

Se você entendeu esse LAB, você já sabe:

• Por que Kafka não salva arquitetura ruim
• Por que consistência custa TPS
• Por que assíncrono é obrigatório
• Por que ledger não negocia

 

Bellacosa Mainframe apresenta o CICS TS versão 6.3

💥 CICS Não é Legado: Como o CICS TS 6.3 Está Processando Milhões de Transações por Segundo (Enquanto o Mundo Ainda Subestima o Mainframe)

🧠 CICS Transaction Server – visão geral atual

O produto que manda no jogo é o
👉 IBM CICS Transaction Server for z/OS

• Middleware transacional de altíssimo volume
• Base de praticamente todos os bancos, seguradoras e governos
• Arquitetura cooperativa de multitarefa (quase um “mini-OS dentro do z/OS”)

---

🚀 Versão mais recente (estado da arte)

👉 Versão atual: CICS TS 6.3
👉 Data de GA: 05 de setembro de 2025

📌 Importante:

• A linha 6.x segue modelo continuous delivery
• Atualizações continuam saindo (inclusive em 2026)

---

🧬 Evolução recente (6.1 → 6.2 → 6.3)

🟢 CICS TS 6.1 (2022)

• Base da nova geração
• Foco:
  • APIs modernas
  • Cloud enablement
  • Melhor governança operacional

---

🟡 CICS TS 6.2 (2024)

• Performance tuning pesado
• Melhorias operacionais reais (não só dev)
• Consolidação da documentação (6.x unificado)

💡 Destaque Bellacosa:

Aqui o CICS começou a “respirar DevOps de verdade”

---

🔵 CICS TS 6.3 (2025 – atual)

• Foco forte em:
  • Observabilidade (OpenTelemetry)
  • Segurança
  • Automação operacional
  • Integração com APIs modernas

Exemplo prático:

• Flush automático de dados de telemetria (SMF + observabilidade moderna)

---

🔐 Segurança evoluída

• HSTS (HTTP Strict Transport Security)
• Melhor visibilidade de login (tentativas, timestamps)

---

⚙️ Limites operacionais (o que ninguém te explica direito)

Agora vem o ouro 👇 (estilo Bellacosa raiz)

👥 Limite de usuários

👉 Não existe limite fixo definido pelo CICS

Depende de:

• Região (QR TCB)
• Storage (EDSAs / GDSA / RDSA)
• Tuning de SIT

💡 Na prática:

• Milhares de usuários simultâneos são comuns
• Bancos operam com dezenas de milhares

---

🧵 Limite de tasks (TCLASS / MAXTASKS)

👉 Controlado por:

• MXT (Max Tasks global da região)
• TCLASS (limite por tipo de workload)

💥 Valores típicos:

• MXT: 500 até 2000+ (ou mais em ambientes modernos)
• Pode escalar dependendo de CPU e tuning

📌 Importante:

• Cada transação = 1 TASK
• CICS é cooperativo (não preemptivo)

---

🔁 Limite de transações por segundo (TPS)

👉 Não existe limite fixo no produto

Depende de:

• CPU (MSU / MIPS)
• I/O (VSAM / DB2 / MQ)
• Locking
• Design da aplicação

💥 Casos reais:

• 10.000+ TPS → comum
• 50.000+ TPS → ambientes financeiros pesados

---

🧠 Limite de memória (Storage)

Controlado por:

• DSAs:
  • CDSA
  • EDSA
  • RDSA
• 31-bit vs 64-bit storage

💡 Tendência moderna:
👉 mover tudo possível para 64-bit storage (above the bar)

---

🧬 Limite de regiões CICS

👉 Ilimitado na prática (depende do z/OS)

Arquiteturas modernas usam:

• CICSPlex SM
• TOR / AOR / FOR separation

---

🏗️ Arquitetura operacional (visão de campo)

🧩 Componentes chave

• QR TCB → coração da região
• Open TCBs → paralelismo real (DB2, MQ, Java)
• Dispatcher CICS → controla multitarefa
• Program Control (PC)
• Task Control (TC)

---

🔄 Modelo de execução

1. Terminal / API chama transação
2. CICS cria TASK
3. Dispatcher gerencia CPU
4. TASK usa serviços:
   • VSAM
   • DB2
   • MQ
5. Commit (syncpoint)

---

🔥 O que realmente mudou (visão prática)

Antes (CICS clássico)

• 3270
• COBOL puro
• VSAM pesado
• Transação síncrona

---

Agora (CICS moderno)

• REST via z/OS Connect
• APIs JSON
• Observabilidade (OpenTelemetry)
• Integração cloud
• DevOps pipeline

💥 Em resumo:
👉 CICS virou Application Server corporativo de missão crítica

---

📊 Pontos fortes atuais

• Escalabilidade absurda (vertical + horizontal)
• Resiliência (quase zero downtime)
• Integração híbrida (legacy + cloud)
• Segurança nível bancário

---

⚠️ Gargalos reais (sem romantizar)

• Aplicação mal escrita = gargalo (não o CICS)
• Lock em VSAM/DB2
• TASK segurando CPU (não liberando)
• Storage mal dimensionado
• Falta de paralelismo (Open TCB subutilizado)

---

🧠 Conclusão estilo Bellacosa

CICS hoje não é legado.

👉 É core digital escondido atrás de APIs modernas

E a versão 6.3 consolida isso:

• Mais observável
• Mais seguro
• Mais integrado
• Mais preparado para cloud

 

Bellacosa Mainframe e o poder do CICS no Mundo Mainframe

💥 SEU COBOL NÃO RODA — ELE ORQUESTRA O MUNDO: CICS Structure & Intercommunication no IBM z17 para Quem Vive de Produção

Se você é dev COBOL sênior, já sabe: CICS não é “mais um runtime”.
Ele é o cérebro transacional que sustenta bancos, companhias aéreas, telecoms — e agora, APIs modernas no IBM z17.

Mas aqui vai a provocação:

👉 Se você não entende profundamente a estrutura e a intercomunicação do CICS, você está programando “cego” em produção.

Vamos desmontar isso com história, prática, arquitetura real, “easter eggs” e insights que só aparecem quando você vive CICS de verdade. 🚀

---

🧠 1. CICS NÃO É UM SISTEMA — É UM ECOSSISTEMA

📜 Origem (rapidinho, mas essencial)

O CICS nasceu nos anos 60/70 para resolver um problema brutal:

👉 processar milhares de transações simultâneas com consistência absoluta

Enquanto o mundo fazia batch…

👉 o CICS já fazia online transacional em escala global.

---

🧩 Estrutura interna (o que realmente roda seu COBOL)

Dentro de uma CICS Region:

• Kernel (DFHKERN) → coordena tudo
• Dispatcher → agenda tasks
• Storage Manager → gerencia memória
• Program Control → carrega e executa programas
• File Control → acessa VSAM/DB2
• Task Control → gerencia execução

💡 Easter egg:

O prefixo DFH (DFHxxxx) vem de Data Facility Hypervisor — legado histórico da IBM.

---

💼 2. CICS APPLICATION — SEU COBOL NÃO ESTÁ SOZINHO

Uma aplicação CICS:

👉 é um conjunto de programas cooperando.

🏦 Exemplo real (transferência bancária)

VALIDA-CONTA
→ CHECK-SALDO
→ CALC-TAXA
→ UPDATE-DB
→ LOG-AUDIT
→ RETORNO-USUARIO

Você escreve um programa…

👉 mas o CICS orquestra todo o fluxo transacional.

---

⚙️ O segredo que muita gente ignora

Você não controla:

• Threads
• Memória direta
• I/O direto

👉 O CICS controla tudo.

E isso é o que garante:

✔ Integridade
✔ Escala
✔ Segurança
✔ Performance

---

🏢 3. CICS REGION — ONDE A MÁGICA ACONTECE

Uma CICS Region = um address space no z/OS.

Ela é iniciada como:

S CICSPROD

Ou via JCL com DFHSIP.

---

🧠 Recursos dentro da region

• Programas
• Transações
• BMS maps
• Arquivos VSAM
• TSQ / TDQ
• Journals
• Usuários

👉 Tudo controlado como uma única entidade.

---

💡 Curiosidade (produção real)

Em bancos:

• Uma única região pode processar milhares de TPS
• Um ambiente pode ter dezenas de regiões

---

🌐 4. CICSPLEX — QUANDO UM CICS NÃO É SUFICIENTE

👉 CICSPlex = várias regiões funcionando como uma só

Gerenciado por:

👉 CICSPlex System Manager (SM)

---

⚖️ O que ele resolve

• Balanceamento automático
• Failover
• Administração centralizada
• Visão global

---

🧠 Insight de arquiteto

👉 Isso é o “Kubernetes” do mainframe… décadas antes do Kubernetes existir.

---

🔗 5. INTERCOMMUNICATION — O VERDADEIRO PODER

Agora vem o ponto onde muita gente “perde o jogo”:

👉 como as regiões conversam

---

🟢 MRO — O CAMINHO MAIS RÁPIDO DO UNIVERSO CICS

👉 Comunicação dentro da mesma LPAR ou Sysplex

🔧 Usa:

➡️ IRC — Interregion Communication

---

⚡ Por que isso importa

• Sem TCP/IP
• Sem SNA
• Sem rede
• Latência mínima

👉 É praticamente memória → memória

---

🏗️ Exemplo clássico

USER → TOR → AOR → FOR

Tudo via MRO + IRC.

---

🧪 Easter egg de produção

👉 Você pode rodar uma AOR de teste usando dados reais

Sem impactar produção.

---

🔵 ISC — QUANDO O MUNDO FICA MAIOR

👉 Comunicação entre hosts diferentes

Usa:

• SNA
• VTAM
• APPC (LU 6.2)

---

🏦 Exemplo real

• CICS (canal digital)
  → ISC
  → IMS (core bancário)

---

💡 Curiosidade

ISC ainda roda em ambientes críticos…

👉 mesmo em 2026.

---

🟣 IPIC — A EVOLUÇÃO

👉 ISC moderno via TCP/IP

Benefícios:

• Configuração simples
• TLS nativo
• Integração com cloud
• Performance alta

👉 Hoje é o padrão recomendado.

---

🌉 6. CICS TRANSACTION GATEWAY — O PORTAL PARA O MUNDO

👉 O TG conecta o CICS com:

• Java / Java EE
• .NET
• APIs REST
• Microservices

---

🌐 Fluxo moderno

App → API → Java → CICS TG → CICS → DB2

👉 Seu COBOL está rodando por trás de apps mobile.

---

🚀 7. IBM z17 — O TURBO NO CICS

O CICS continua o mesmo conceito…

Mas o z17 traz:

• ⚡ Mais throughput
• 🔐 Criptografia massiva
• 🌐 Integração cloud-native
• 🧠 Observabilidade avançada

👉 Resultado: o mesmo CICS… em outro nível

---

💎 8. RESUMO DE GUERRA (GUARDE ISSO)

👉 CICS Application = negócio
👉 CICS Region = runtime
👉 CICSPlex = escala
👉 MRO = comunicação interna (IRC)
👉 ISC = comunicação entre hosts (SNA)
👉 IPIC = comunicação moderna (TCP/IP)
👉 CTG = integração com o mundo externo

---

🧠 FRASE FINAL (NÍVEL SÊNIOR)

👉 CICS não executa programas — ele coordena um sistema distribuído transacional de altíssima performance que atravessa regiões, sistemas e até o mundo digital moderno.

 

Bellacosa Mainframe e o poder do CICS dominando ecosistemas no Mundo Mainframe

💥 SEU CICS NÃO ESCALA — ELE DOMINA ECOSSISTEMAS: O GUIA DEFINITIVO DE CICS no z16/z17 PARA ARQUITETOS QUE PENSAM GRANDE

Se você ainda enxerga CICS como “onde roda COBOL”, você está vendo só a superfície.

👉 No IBM Z moderno (z16/z17), o CICS virou uma plataforma transacional distribuída, integrada e híbrida, capaz de orquestrar desde VSAM até APIs REST consumidas por milhões de usuários.

Este guia é direto para quem já vive produção — e quer pensar como arquiteto. 🚀

---

🧠 1. CICS: DE MONITOR TRANSACIONAL A PLATAFORMA DIGITAL

📜 Origem (o DNA que ainda manda)

CICS nasceu para resolver:

👉 processamento massivo de transações com consistência absoluta

Isso continua igual.

O que mudou:

👉 o alcance.

Hoje o CICS:

• Atende mobile
• Expõe APIs REST
• Integra microservices
• Participa de arquiteturas híbridas

---

💡 Easter egg histórico

O prefixo DFH (mensagens DFHxxxx) vem de:

👉 Data Facility Hypervisor

Décadas depois… ainda está lá. 😄

---

🏗️ 2. ESTRUTURA — COMO UM ARQUITETO ENXERGA O CICS

🧩 O modelo mental correto

Um arquiteto não vê “programas COBOL”.

Ele vê:

🔹 Application Layer

• Programas (COBOL, PL/I, Java)
• Fluxos de negócio

🔹 Transaction Layer

• Tasks
• Syncpoints
• Controle ACID

🔹 Resource Layer

• DB2
• VSAM
• TSQ/TDQ
• MQ

🔹 Infrastructure Layer

• Regions
• CICSPlex
• Sysplex

---

🧠 Insight importante

👉 CICS é um application server transacional altamente otimizado.

---

🏢 3. REGIONS — O DESIGN DISTRIBUÍDO DENTRO DO Z

🔥 Arquitetura clássica (e ainda dominante)

TOR → AOR → FOR

🖥️ TOR

• Entrada (3270, web, APIs)
• Roteamento

⚙️ AOR

• Processamento de negócio
• Escala horizontal

💾 FOR

• Dados
• Locks e integridade

---

💡 Curiosidade real

Em bancos grandes:

👉 dezenas de AORs
👉 múltiplos TORs
👉 FORs centralizados

---

🧠 Insight de arquiteto

👉 Isso é microservices antes do microservices existir.

---

🌐 4. CICSPLEX — O “CLUSTER” DO MAINFRAME

🧩 Componentes

• CMAS → cérebro
• MAS → regiões
• WLM → balanceamento

---

⚖️ O que isso resolve

• Escala massiva
• Alta disponibilidade
• Failover automático
• Administração centralizada

---

💡 Easter egg moderno

👉 CICSPlex SM = “Kubernetes do mainframe” (sem hype, com SLA real)

---

🔗 5. INTERCOMMUNICATION — ONDE A ARQUITETURA GANHA VIDA

Aqui está o ponto mais crítico para arquitetos.

---

🟢 MRO + IRC — O FAST PATH

👉 Comunicação interna (mesma LPAR/Sysplex)

🔧 Usa:

➡️ IRC (Interregion Communication)

⚡ Resultado:

• Sem rede
• Latência mínima
• Throughput absurdo

---

🧠 Insight

👉 Esse é o motivo do CICS escalar tanto.

---

🔵 ISC — O LEGADO QUE AINDA RESPIRA

👉 Comunicação entre hosts via SNA.

Ainda usado em:

• Core banking
• Integrações antigas
• Sistemas críticos

---

🟣 IPIC — O PRESENTE

👉 Comunicação via TCP/IP

• Simples
• Segura (TLS)
• Cloud-ready

👉 Padrão atual

---

🌉 6. CICS TG — O PORTAL PARA O DIGITAL

🌐 O que ele faz

Conecta:

• Java / Jakarta EE
• .NET
• APIs REST
• Microservices

---

🚀 Fluxo moderno real

Mobile → API → Java → CICS TG → CICS → DB2

👉 Seu COBOL vira backend de apps globais.

---

⚡ 7. z16 vs z17 — O QUE MUDA PARA ARQUITETOS

🚀 Performance

• Mais throughput
• Melhor paralelismo

🔐 Segurança

• Criptografia pervasive
• TLS acelerado

🌐 Integração

• Melhor suporte a APIs
• Hybrid cloud real

🧠 Observabilidade

• SMF avançado
• Integração com AIOps

---

💡 Insight crítico

👉 O CICS não mudou — o contexto dele mudou completamente.

---

🛠️ 8. PASSO A PASSO — COMO PENSAR UMA ARQUITETURA CICS MODERNA

1️⃣ Defina entrada

• 3270?
• API?
• Mobile?

2️⃣ Separe regiões

• TOR (entrada)
• AOR (processamento)
• FOR (dados)

3️⃣ Defina comunicação

• MRO (interno)
• IPIC (externo)

4️⃣ Planeje escala

• CICSPlex + WLM

5️⃣ Integre com digital

• CICS TG
• APIs REST

6️⃣ Planeje HA

• Sysplex
• Failover

---

💎 9. RESUMO DE ARQUITETO

👉 CICS não é legado
👉 Não é monolito
👉 Não é “COBOL runtime”

👉 É uma plataforma transacional distribuída, resiliente e integrada ao mundo moderno

---

🧠 FRASE FINAL (GUARDE ISSO)

👉 No z16/z17, o CICS não executa aplicações — ele sustenta ecossistemas digitais inteiros com consistência, escala e zero margem para erro.

Os 6 Inimigos Invisíveis da Inteligência Artificial: Por que Dados Ruins Destroem até o Melhor Modelo do Mundo

 

Bellacosa Mainframe e os 6 inimigos da inteligencia artificial

☕ Um Café no Bellacosa Mainframe

Os 6 Inimigos Invisíveis da Inteligência Artificial: Por que Dados Ruins Destroem até o Melhor Modelo do Mundo

"A Inteligência Artificial aprende padrões. Quem ensina esses padrões são os dados. Se o professor ensina errado, não espere um aluno genial."

---

Existe uma cena que acontece praticamente todos os dias em empresas que estão iniciando projetos de Inteligência Artificial.

A reunião começa animada.

— Vamos usar GPT.

— Vamos usar Llama.

— Vamos usar Claude.

— Vamos colocar um agente inteligente para responder nossos clientes.

— Vamos fazer IA prever falhas.

— Vamos usar Machine Learning.

Todo mundo discute qual modelo é melhor.

Qual possui mais bilhões de parâmetros.

Qual responde mais rápido.

Qual custa menos.

E quase ninguém faz a pergunta mais importante de todas.

"Como estão nossos dados?"

Essa única pergunta vale milhões de reais.

E normalmente ela só aparece quando o projeto começa a falhar.

Hoje vamos tomar mais um café e conversar sobre aquilo que realmente faz uma IA funcionar.

Spoiler:

Não é o modelo.

É o dado.

---

A maior mentira da IA

Quando vemos notícias sobre Inteligência Artificial, tudo parece girar em torno dos modelos.

GPT-5.

Gemini.

Claude.

Llama.

Mistral.

DeepSeek.

Qwen.

Parece que basta trocar um modelo pelo outro para tudo melhorar.

Na prática, isso raramente acontece.

Imagine dois cozinheiros.

O primeiro possui uma panela simples.

O segundo possui uma panela caríssima.

Mas ambos recebem ingredientes estragados.

Quem fará uma boa comida?

Nenhum.

Na Engenharia de IA acontece exatamente a mesma coisa.

O modelo é apenas a panela.

Os dados são os ingredientes.

---

A regra mais antiga da computação continua viva

Quem programa COBOL conhece um velho princípio.

Garbage In → Garbage Out

Ou simplesmente:

"Lixo entra.

Lixo sai."

Esse conceito surgiu décadas antes da Inteligência Artificial.

E continua absolutamente verdadeiro.

Um modelo moderno apenas consegue produzir respostas tão boas quanto os dados que recebeu.

---

O iceberg da Inteligência Artificial

Quando alguém fala em IA, normalmente imagina isto:

Modelo

Mas a realidade parece muito mais com isto:

Aplicação

Agentes

LLM

Machine Learning

Feature Engineering

Data Engineering

Governança

Qualidade

Dados

Perceba algo interessante.

Quanto mais descemos...

Mais importante fica.

Não existe IA sem dados.

---

Problema 1 — Poor Data Quality

Dados ruins

Este é o campeão absoluto.

Imagine construir um modelo para prever inadimplência.

Seu banco de dados possui:

São Paulo

SP

S.P.

Sao Paulo

São paulo

Cinco cidades?

Não.

Uma única cidade.

Para a IA?

Cinco categorias diferentes.

Agora imagine um cadastro de clientes.

Idade

35

NULL

999

-10

O modelo não possui bom senso.

Ele não sabe que idade negativa não existe.

Ele apenas aprende aquilo.

---

No Mainframe acontece igual

Quem trabalha com COBOL já encontrou coisas como:

Sexo

M

Masculino

Masc

1

X

Todos representam praticamente a mesma informação.

Mas para um algoritmo de Machine Learning...

São mundos completamente diferentes.

---

Outro clássico

Datas.

2026-07-07

07/07/2026

07-JUL-26

20260707

Para um humano...

Tudo igual.

Para uma IA...

Quatro formatos diferentes.

---

Como resolver?

Antes de pensar em IA devemos pensar em:

✔ Padronização

✔ Deduplicação

✔ Normalização

✔ Validação

✔ Catálogo de Dados

✔ Governança

---

Curiosidade ☕

Estima-se que cientistas de dados gastem entre 60% e 80% do tempo preparando dados, e não treinando modelos.

Treinar o modelo normalmente é a parte fácil.

---

Problema 2 — Data Drift

Imagine ensinar um adolescente a dirigir.

Depois colocá-lo para dirigir vinte anos depois.

Sem nenhuma atualização.

Difícil, não?

É exatamente isso que acontece com modelos de IA.

---

O mundo muda

Clientes mudam.

Mercado muda.

Inflação muda.

Fraudes mudam.

Golpes mudam.

Tecnologias mudam.

As pessoas mudam.

Mas...

O modelo continua preso ao passado.

---

Um exemplo histórico

Durante a pandemia.

Modelos de previsão de demanda simplesmente enlouqueceram.

Por quê?

Porque eles aprenderam isto:

Normalidade

Mas passaram a enfrentar:

Home Office

Lockdown

Mudança de hábitos

Explosão do e-commerce

Os dados mudaram.

O modelo não.

---

No Mainframe

Imagine um sistema treinado para prever utilização da CPU.

Durante anos tudo funcionou.

Então chega:

• novos microsserviços;

• APIs REST;

• OpenShift;

• z/OS Connect;

• novos horários de processamento.

O perfil de carga muda completamente.

Seu modelo começa lentamente a errar.

Sem ninguém perceber.

Isso é Data Drift.

---

Dica Bellacosa ☕

Nunca confie em um modelo que ninguém monitora.

IA também precisa de manutenção.

---

Problema 3 — Falta de Dados Relevantes

Ter muitos dados...

Não significa possuir informação.

Imagine ensinar medicina usando apenas livros de culinária.

Muito conteúdo.

Pouca utilidade.

---

Exemplo

Você deseja criar um chatbot jurídico.

Mas possui milhões de tweets.

Fotos.

Vídeos.

Posts do Instagram.

Só esqueceu das leis.

Resultado?

Um excelente especialista em memes.

Um péssimo advogado.

---

No IBM Z

Quer prever ABENDs.

Treina usando apenas:

SMF.

Mas ignora:

RMF

JES2

SDSF

LOGREC

OMEGAMON

WLM

RACF

O modelo enxerga apenas metade da realidade.

---

Easter Egg Mainframe 🥚

Existe um velho ditado entre SysProgs:

"Quem olha apenas o SMF enxerga a sombra do problema."

Os melhores diagnósticos normalmente cruzam diversas fontes simultaneamente.

---

Problema 4 — Data Silos

Imagine um hospital.

O laboratório conhece o exame.

A farmácia conhece os medicamentos.

O convênio conhece as autorizações.

O pronto-socorro conhece os atendimentos.

Cada sistema conhece um pedaço.

Ninguém conhece o paciente inteiro.

---

É exatamente isso que acontece nas empresas.

SAP

Oracle

DB2

IMS

VSAM

CRM

Salesforce

AWS

Azure

Todos armazenam informação.

Poucos conversam entre si.

---

No Mainframe

Este problema existe há décadas.

Dados espalhados em:

VSAM

IMS

DB2

MQ

Arquivos Flat

Kafka

REST

Cloud

Criar uma IA sem integrar tudo isso é como montar um quebra-cabeça faltando metade das peças.

---

Curiosidade ☕

É justamente por isso que arquiteturas modernas falam tanto em:

• Data Fabric

• Data Mesh

• Lakehouse

• Catálogo

• APIs

• MCP

• RAG

Não são modismos.

São tentativas de unir informações espalhadas.

---

Problema 5 — Dados Desbalanceados

Imagine um detector de fraude.

99,9% das operações são normais.

0,1% são fraude.

O algoritmo aprende algo genial...

"Basta responder NORMAL."

Parabéns.

Você conseguiu 99,9% de precisão.

E não encontrou nenhuma fraude.

---

Precisão alta...

Nem sempre significa modelo bom.

---

Outro exemplo

Diagnóstico médico.

100.000 exames

99.800 saudáveis

200 doentes

O algoritmo praticamente esquece que a doença existe.

---

Como resolver?

Oversampling.

SMOTE.

Class Weight.

Balanced Loss.

Data Augmentation.

São técnicas que equilibram o aprendizado.

---

Bellacosa Mainframe ☕

Em ambientes corporativos, os eventos mais importantes costumam ser justamente os mais raros.

ABENDs.

Falhas.

Ataques.

Corrupções.

E exatamente por serem raros...

São difíceis de aprender.

---

Problema 6 — Data Leakage

Este talvez seja o mais traiçoeiro.

Imagine criar um modelo para prever cancelamento.

Entre as colunas utilizadas...

DATA_CANCELAMENTO

O modelo acerta praticamente tudo.

Porque ele viu a resposta antes da prova.

---

Outro exemplo.

Prever média final utilizando...

Média Final

Excelente precisão.

Zero utilidade.

---

Em IA Generativa

Data Leakage ganha outra dimensão.

Pode significar:

• contratos

• código-fonte

• CPF

• LGPD

• segredos industriais

• documentos internos

Todos enviados sem cuidado para um modelo.

Agora o problema deixa de ser apenas estatístico.

Passa a ser jurídico.

---

Existe um sétimo problema...

Na minha opinião...

Existe algo que deveria estar em todos os infográficos.

Data Freshness

Dados envelhecem.

Muito rápido.

Imagine perguntar a uma IA:

"Qual é a versão atual do COBOL?"

Se ela foi treinada anos atrás...

Responderá algo ultrapassado.

Por isso surgiram arquiteturas como:

• MCP

• RAG

• Vetores

• Busca Híbrida

• Knowledge Graph

• Agentes

Elas permitem consultar informações atualizadas em vez de depender apenas do treinamento original.

---

E existe um oitavo...

Governança

Quem é dono do dado?

Quem alterou?

Quando?

Qual versão?

Está criptografado?

Está mascarado?

Existe LGPD?

Existe auditoria?

Sem governança...

Não existe IA corporativa.

Existe apenas um experimento.

---

O que tudo isso tem a ver com COBOL?

Mais do que parece.

COBOL nasceu para processar dados.

Não telas bonitas.

Não animações.

Dados.

Durante décadas aprendemos algo fundamental:

Integridade dos dados vale mais do que velocidade.

Essa filosofia continua sendo uma das maiores contribuições do mundo Mainframe para a era da Inteligência Artificial.

Quando um programa COBOL valida campos, verifica códigos de retorno, trata exceções, garante consistência transacional e protege a integridade das informações, ele está fazendo exatamente o que uma IA moderna precisa para aprender corretamente.

Em outras palavras, a experiência acumulada em ambientes IBM Z continua extremamente relevante. Os princípios mudaram pouco; o volume de dados e as ferramentas evoluíram.

---

As Empresas Estão Descobrindo Isso Agora

Depois da corrida pelos LLMs, muitas organizações perceberam que comprar um modelo poderoso não resolve problemas estruturais.

Os projetos que realmente geram valor investem em:

• Engenharia de Dados (Data Engineering)

• Qualidade de Dados (Data Quality)

• Governança de Dados (Data Governance)

• Observabilidade (Observability)

• DataOps

• MLOps

• Catálogo de Dados

• Monitoramento de Drift

• Segurança e Privacidade

• Integração entre sistemas legados e modernos

O modelo de IA é apenas uma peça dessa engrenagem.

---

Para o Programador Júnior

Se você está começando agora, existe uma excelente notícia: dominar apenas prompts ou APIs de modelos não será suficiente nos próximos anos. Os profissionais mais valorizados serão aqueles que entendem como os dados nascem, são transformados, validados, protegidos e disponibilizados para consumo.

Aprenda SQL. Entenda modelagem de dados. Estude ETL e ELT. Descubra como funcionam Data Lakes, Data Warehouses e Lakehouses. Explore RAG, bancos vetoriais e arquiteturas de agentes. E, se tiver oportunidade, mergulhe no universo IBM Z. Você perceberá que muitos dos conceitos considerados "novos" na IA já eram praticados há décadas em ambientes de missão crítica.

---

Curiosidades do Café ☕

☕ O termo "Garbage In, Garbage Out (GIGO)" surgiu na década de 1950 e continua sendo uma das leis fundamentais da computação.

☕ Cerca de 80% do tempo em muitos projetos de IA é consumido preparando, limpando e organizando dados, não treinando modelos.

☕ Grandes modelos de linguagem não "sabem" que um dado está errado; eles apenas detectam padrões estatísticos e reproduzem o que aprenderam.

☕ Bancos, seguradoras, companhias aéreas e governos ainda dependem fortemente de sistemas IBM Z, que processam alguns dos dados mais críticos do planeta — um terreno fértil para aplicações de IA quando a qualidade e a governança dos dados são tratadas com rigor.

---

Easter Eggs para os Padawans 🥚

🥚 Easter Egg #1: Se você entendeu por que um NULL pode ser mais perigoso do que um ABEND S0C7, já começou a pensar como um engenheiro de dados.

🥚 Easter Egg #2: Toda vez que ouvir alguém dizer "é só conectar um GPT ao banco de dados", faça uma pergunta simples: "Quem garante a qualidade desses dados?" A resposta costuma revelar a maturidade do projeto.

🥚 Easter Egg #3: Os profissionais que mais rapidamente se adaptam à IA costumam ser aqueles que vieram de ambientes onde consistência, auditoria e integridade sempre foram prioridades. Parece familiar? Sim, estamos falando do universo Mainframe.

---

Um Último Café...

Existe uma frase muito repetida no mundo da Inteligência Artificial:

"Data is the new oil."

Eu prefiro outra.

"Dados não são o novo petróleo. São o novo oxigênio."

Petróleo é importante.

Oxigênio é indispensável.

Sem dados confiáveis, não existe Machine Learning eficiente. Não existe IA Generativa útil. Não existe RAG consistente. Não existe agente inteligente confiável.

Existe apenas um sistema produzindo respostas com aparência de inteligência.

No fim das contas, a maior revolução da IA não está nos bilhões de parâmetros dos modelos, mas na disciplina silenciosa de coletar, validar, integrar, governar e proteger informações. É exatamente essa base que transforma algoritmos impressionantes em soluções confiáveis para o mundo real.

E talvez aí esteja a maior lição desta conversa: os modelos evoluirão todos os anos, mas os princípios da boa engenharia de dados permanecem. Assim como acontece no Mainframe, tecnologias mudam, linguagens evoluem, arquiteturas se reinventam… porém a qualidade dos dados continua sendo o alicerce sobre o qual toda a inteligência é construída.

Porque, no final, a IA não pensa melhor do que os dados que recebe. E dados bem cuidados sempre foram — e continuarão sendo — a maior especialidade dos bons engenheiros de software.