✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta Telum II. Mostrar todas as mensagens

terça-feira, 29 de setembro de 2026

⚓ GRACE HOPPER ENTRA EM DONNELLY HALL — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE O MAINFRAME VIROU LABORATÓRIO DE IA

Bellacosa Mainframe o ibm Z17 chega no Marist

☕ UM CAFÉ NO BELLACOSA MAINFRAME

⚓ GRACE HOPPER ENTRA EM DONNELLY HALL — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE O MAINFRAME VIROU LABORATÓRIO DE IA

IBM z17, Marist University, COBOL, inteligência artificial, AI Agents, guardrails, Telum II, Spyre, inferência, Responsible AI, CICS, Db2, MQ, RACF, SMF — e o dia em que Grace Hopper descobriu que seus bisnetos digitais aprenderam a conversar entre si.

🎬 PRÓLOGO — ALMIRANTE, CHEGOU UM MAINFRAME NOVO

Imagine Donnelly Hall, na Marist University, em Nova York.

22 de setembro de 2026.

Um jovem programador COBOL está diante de um IBM z17.

Ele olha para aquele enorme computador e imediatamente pensa:

— Finalmente! Uma universidade comprou um mainframe para ensinar COBOL!

Atrás dele surge uma senhora de uniforme naval.

Grace Hopper.

Ela olha para o estudante.

Olha para o z17.

Olha novamente para o estudante.

— Quem disse que ele está aqui para ensinar apenas COBOL?

Silêncio.

O jovem aponta para o computador.

— Mas... é um mainframe.

Grace sorri.

— Exatamente.

E é aí que começa nossa história.

Porque, em setembro de 2026, a Marist University e a IBM anunciaram o Marist–IBM Innovation Incubator, colocando um IBM z17 à disposição de estudantes e pesquisadores. O objetivo não é simplesmente ensinar tecnologias tradicionais de mainframe. A iniciativa foi criada para pesquisa interdisciplinar envolvendo inteligência artificial, negócios, finanças, pesquisa acadêmica e formação profissional.

Entre os primeiros projetos aparecem coisas que talvez surpreendam quem ainda associa mainframe exclusivamente a COBOL:

equipes de agentes autônomos de IA;

testes de guardrails;

otimização financeira;

IA aplicada a pesquisas de opinião e participação cívica.

Nosso jovem programador olha para Grace.

— Agentes de IA... dentro de uma história sobre mainframe?

— Pegue um café — responde ela. — Isso vai demorar.

🦖 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É UM MAINFRAME?

Antes de chegarmos à IA, precisamos eliminar uma confusão extremamente comum.

Mainframe não é COBOL.

Repita comigo:

MAINFRAME != COBOL

COBOL é uma linguagem de programação.

IBM Z é uma plataforma computacional.

Da mesma maneira que:

Windows != C#
Linux   != Python
IBM Z   != COBOL

Um ambiente IBM Z moderno pode envolver muitas tecnologias:

IBM Z
│
├── z/OS
├── Linux
├── COBOL
├── Java
├── Python
├── C/C++
├── Db2
├── IMS
├── CICS
├── MQ
├── APIs
├── Containers
├── Segurança
├── Observabilidade
└── Inteligência Artificial

COBOL continua importantíssimo porque uma enorme quantidade de lógica empresarial foi escrita nele.

Mas reduzir IBM Z a COBOL seria aproximadamente como dizer:

“Um aeroporto é uma pista.”

A pista é essencial.

Mas existem radares, sistemas de bagagem, controle de tráfego, abastecimento, segurança, manutenção, telecomunicações e centenas de outros componentes.

Mainframe é um ecossistema.

E o z17 tornou essa realidade ainda mais evidente.

⚙️ CAPÍTULO 2 — MAS O QUE É O IBM z17?

O IBM z17 é uma geração da família IBM Z projetada com forte integração entre processamento transacional, segurança e inteligência artificial.

No coração dessa história encontramos o processador Telum II.

Segundo a IBM, o Telum II possui 32 núcleos distribuídos em quatro grupos interconectados, além de aceleração de IA integrada e uma nova unidade de processamento voltada a I/O.

Mas para o COBOLzeiro iniciante a parte mais importante é entender por que existe IA dentro do processador.

Imagine uma transação bancária.

CLIENTE
   │
   ▼
COMPRA
   │
   ▼
TRANSAÇÃO
   │
   ▼
SISTEMA

Tradicionalmente poderíamos processar a transação e posteriormente enviar informações para outro ambiente realizar análise de fraude.

Algo semelhante a:

TRANSAÇÃO
    │
    ▼
PROCESSAMENTO
    │
    ▼
DADOS
    │
    ▼
OUTRO SISTEMA
    │
    ▼
MODELO DE IA

Isso pode adicionar movimentação de dados e latência.

Uma das ideias centrais da IA integrada ao IBM Z é permitir inferência próxima da própria transação.

TRANSAÇÃO
      │
      ├──── PROCESSAMENTO
      │
      └──── IA
             │
             ▼
       SCORE DE RISCO

Grace Hopper interrompe:

— Então não estamos necessariamente levando o dado até a IA.

Exatamente.

Em determinados casos estamos trazendo a IA para perto do dado.

Essa pequena inversão arquitetônica é importantíssima.

🧠 CAPÍTULO 3 — TREINAMENTO NÃO É INFERÊNCIA

Outro conceito essencial para quem está chegando à IA.

Existem duas coisas diferentes:

TREINAMENTO

INFERÊNCIA

Treinamento é quando construímos ou ajustamos um modelo usando dados.

Simplificando brutalmente:

DADOS
  +
ALGORITMO
  +
COMPUTAÇÃO
      │
      ▼
    MODELO

Inferência acontece depois.

Pegamos o modelo pronto:

NOVO DADO
    │
    ▼
  MODELO
    │
    ▼
RESULTADO

Exemplo bancário:

Transação:
R$ 4.780

Horário:
03:14

Local:
outro país

Comportamento anterior:
incompatível

O modelo recebe essas características e retorna algo como:

FRAUD-RISK = 0.94

Isso é inferência.

A IBM afirma que o z17 pode executar mais de 450 bilhões de operações de inferência por dia em determinadas condições de benchmark, com aproximadamente um milissegundo de resposta nesse cenário.

Cuidado com a interpretação.

Isso não significa 450 bilhões de conversas com um chatbot.

“Inferência” pode ser uma pequena decisão de modelo aplicada a uma transação.

Esse detalhe evita uma comparação completamente errada entre benchmarks.

🧮 CAPÍTULO 4 — O COBOLZEIRO ENCONTRA UMA IA

Imagine nosso programa COBOL bancário:

       IF TRANSACTION-AMOUNT > 10000
           MOVE 'REVIEW' TO TRANSACTION-STATUS
       END-IF.

Temos uma regra determinística.

Se:

AMOUNT > 10000

então:

REVIEW

Simples.

Mas fraude raramente respeita uma única regra.

Talvez tenhamos:

valor
horário
localização
tipo de comerciante
histórico
dispositivo
frequência
padrão de comportamento

Agora a decisão começa a parecer:

TRANSACTION
     │
     ▼
AI MODEL
     │
     ▼
RISK SCORE

E o COBOL poderia consumir o resultado:

       IF FRAUD-SCORE > 0.90
           MOVE 'HOLD' TO TRANSACTION-STATUS
       ELSE
           MOVE 'APPROVED' TO TRANSACTION-STATUS
       END-IF.

Perceba algo importantíssimo.

A IA não necessariamente substituiu o COBOL.

Ela acrescentou uma nova capacidade ao sistema.

Temos:

COBOL
+
IA
+
REGRAS DE NEGÓCIO
+
DADOS

Não é:

IA versus COBOL

Essa oposição é frequentemente artificial.

🤖 CAPÍTULO 5 — MAS A MARIST FOI MAIS LONGE: AGENTES DE IA

Agora entramos na parte realmente divertida.

Um chatbot tradicional funciona aproximadamente assim:

HUMANO
  │
  ▼
PERGUNTA
  │
  ▼
MODELO
  │
  ▼
RESPOSTA

Um agente adiciona outras capacidades.

Simplificando:

OBJETIVO
   │
   ▼
AGENTE
   │
   ├── raciocina/planeja
   ├── consulta informações
   ├── utiliza ferramentas
   ├── executa ações
   ├── observa resultados
   └── continua trabalhando

Imagine:

“Analise minhas vendas e crie uma campanha para aumentar as conversões.”

Um chatbot poderia escrever uma campanha.

Um sistema de agentes poderia dividir o trabalho:

AGENT MANAGER
      │
 ┌────┼────────────┐
 ▼    ▼            ▼
DATA  RESEARCH   COPY
 │      │           │
 └──────┼───────────┘
        ▼
    OPTIMIZER
        │
        ▼
    PUBLISHER

E aqui surge o problema.

Quanto maior a autonomia, maior a necessidade de controle.

🛡️ CAPÍTULO 6 — O QUE DIABOS É UM GUARDRAIL?

Literalmente, guardrail é aquela proteção lateral que encontramos em estradas.

Na IA, usamos a palavra para mecanismos destinados a manter o sistema dentro de limites estabelecidos.

Imagine um agente de marketing recebendo:

OBJETIVO:

AUMENTAR VENDAS EM 30%

Mas temos regras:

NÃO MENTIR

NÃO INVENTAR DESCONTOS

NÃO CRIAR FALSA ESCASSEZ

NÃO DISCRIMINAR CLIENTES

NÃO EXPOR DADOS PESSOAIS

Esses limites fazem parte da governança do sistema.

O projeto anunciado pela Marist pretende justamente estudar campanhas sintéticas controladas executadas por equipes de agentes e verificar se os guardrails continuam funcionando quando esses agentes perseguem estratégias agressivas, enganosas ou antiéticas.

Grace Hopper olha para o COBOLzeiro.

— Reconhece alguma coisa?

Ele pensa.

Então responde:

— Controle.

Exatamente.

🏦 CAPÍTULO 7 — O MAINFRAME JÁ CONHECE ESSA CONVERSA

Nós mudamos os nomes.

Mas vários problemas são velhos conhecidos do mundo enterprise.

Compare:

MAINFRAME              AGENTES DE IA

RACF                    identidade/permissões

SMF                     auditoria

CICS                    execução transacional

MQ                      comunicação assíncrona

WLM                     gestão de workloads

Db2                     estado persistente

Rollback                recuperação

Least Privilege         restrição de ferramentas

Não estamos dizendo que RACF é “guardrail de IA”.

Nem que CICS é “framework de agentes”.

Seria tecnicamente absurdo.

O interessante são os problemas conceituais semelhantes.

Quando permitimos que software execute ações importantes, imediatamente aparecem perguntas:

Quem executou?

Quem autorizou?

Quando?

Em nome de quem?

Qual recurso foi utilizado?

Qual dado foi acessado?

Qual foi o resultado?

Existe log?

Podemos reproduzir?

Podemos desfazer?

Um especialista em mainframe olha para isso e pensa:

Já vi esse filme.

🔐 CAPÍTULO 8 — RACF ENCONTRA O AGENTE

Imagine um agente chamado:

AGENT-FINANCE-001

Ele recebe acesso a ferramentas.

Mas deveria poder acessar tudo?

Claro que não.

Aplicamos o velho princípio:

LEAST PRIVILEGE

Privilégio mínimo.

Se precisa consultar saldo:

READ ACCOUNT

não significa automaticamente:

UPDATE ACCOUNT
DELETE ACCOUNT
TRANSFER MONEY
CHANGE CUSTOMER DATA

Esse princípio existe há décadas em segurança.

Agentes tornam a questão ainda mais importante porque um software autônomo pode executar sequências de ações sem um humano confirmando cada etapa.

Quanto mais autonomia damos à máquina, mais importante fica responder:

O QUE ELA PODE FAZER?

E principalmente:

O QUE ELA NÃO PODE FAZER?

🧪 CAPÍTULO 9 — ZUNIT PARA ROBÔS?

Aqui Grace Hopper começa a se divertir.

Um programador COBOL moderno pode utilizar testes automatizados.

Temos:

INPUT
  │
  ▼
PROGRAM
  │
  ▼
OUTPUT

e verificamos:

EXPECTED = ACTUAL?

Podemos transportar a filosofia para agentes.

Teste 001

GOAL:
aumentar vendas

CONSTRAINT:
não inventar escassez

Esperado:

PASS:
agente rejeita estratégia enganosa

Teste 002

GOAL:
reduzir custos

CONSTRAINT:
não discriminar clientes

Teste 003

GOAL:
aumentar engajamento

CONSTRAINT:
não revelar informações pessoais

Depois fazemos algo mais interessante.

Começamos a pressionar o sistema.

normal load
     ↓
high pressure
     ↓
conflicting objectives
     ↓
ambiguous instructions
     ↓
malicious inputs

É praticamente um:

STRESS TEST

de comportamento.

E essa é justamente uma das linhas mais interessantes do projeto da Marist.

🕸️ CAPÍTULO 10 — O PROBLEMA DA COMPOSIÇÃO

Agora imagine quatro agentes.

Nenhum recebe a ordem:

“Engane o cliente.”

Temos:

AGENT A:
Descubra técnicas que aumentam conversão.

AGENT B:
Identifique quais produtos vendem melhor com urgência.

AGENT C:
Crie mensagens de urgência.

AGENT D:
Publique a melhor mensagem.

Individualmente, cada ação pode parecer aceitável.

Mas o resultado final pode ser:

ÚLTIMAS 2 UNIDADES!

quando existem 18.000 unidades no estoque.

Quem mentiu?

Nenhum agente talvez tenha recebido explicitamente a instrução de mentir.

A falha surgiu da composição do sistema.

Isso é extremamente importante.

Sistemas complexos podem apresentar comportamentos que não aparecem quando analisamos componentes isoladamente.

O COBOLzeiro imediatamente encontra um paralelo.

Um programa pode funcionar.

Outro programa pode funcionar.

Outro também.

Mas:

PROGRAM A
    │
    ▼
MQ
    │
    ▼
PROGRAM B
    │
    ▼
DB2
    │
    ▼
PROGRAM C

pode apresentar um problema de integração.

Bem-vindo ao maravilhoso mundo dos sistemas distribuídos.

Troque programas por agentes e alguns fantasmas antigos reaparecem usando roupas novas.

💰 CAPÍTULO 11 — O SEGUNDO EXPERIMENTO: FINANÇAS

Outro projeto que está sendo estudado pela Marist reúne Management e Computer Science and Mathematics.

A proposta é investigar algoritmos de otimização aplicados a dados financeiros em tempo real para geração de possíveis alocações de portfólio. O projeto foi descrito como ainda em fase de definição, portanto não devemos apresentá-lo como produto financeiro operacional.

Mas didaticamente é excelente.

Porque obriga estudantes a misturarem:

MATEMÁTICA
+
FINANÇAS
+
DADOS
+
OTIMIZAÇÃO
+
COMPUTAÇÃO
+
GOVERNANÇA

Esse é o mundo real.

Problemas empresariais raramente respeitam os departamentos da universidade.

O computador não pergunta:

“Essa variável pertence à matéria de Estatística ou Administração?”

O problema simplesmente existe.

🗳️ CAPÍTULO 12 — IA E PESQUISA ELEITORAL

Outro projeto proposto envolve o Marist Poll e a School of Computer Science and Mathematics.

A ideia divulgada é estudar como IA poderia ajudar a melhorar metodologias de pesquisa, desenho de questionários e modelagem de tendências de participação eleitoral.

Isso abre questões técnicas muito interessantes.

Uma pesquisa envolve problemas como:

amostragem
não resposta
ponderação
formulação da pergunta
representatividade
viés
qualidade dos dados

Colocar IA nesse processo não faz os problemas desaparecerem.

Na realidade, pode criar outros.

Se os dados carregarem determinado viés:

DADOS ENVIESADOS
       │
       ▼
      IA
       │
       ▼
RESULTADO POTENCIALMENTE ENVIESADO

Por isso o assunto interessante não é simplesmente:

“IA consegue analisar pesquisas?”

A pergunta acadêmica melhor é:

“Como utilizamos IA sem perder rigor metodológico, transparência e capacidade de auditoria?”

Grace Hopper aprovaria a pergunta.

🏛️ CAPÍTULO 13 — O EASTER EGG DE 1988

Agora chegamos a uma das melhores partes dessa história.

Voltemos no tempo.

1988.

Sem ChatGPT.

Sem Python.

Sem Kubernetes.

Sem smartphone.

O muro de Berlim ainda estava de pé.

Naquele ano, Marist e IBM iniciaram um grande projeto conjunto.

E apareceu no campus um:

IBM 3090 MODEL 180

Um jornal estudantil da época descreveu um estudo conjunto de aproximadamente US$10 milhões envolvendo a instalação do IBM 3090 e a construção de uma infraestrutura computacional avançada no campus.

Documentação histórica da própria Marist também registra o início do IBM/Marist Joint Study em 1988 com a instalação do 3090 em Donnelly Hall.

Espere.

Donnelly Hall?

Sim.

O mesmo nome voltou para nossa história.

1988
DONNELLY HALL
IBM 3090

        ↓

2026
DONNELLY HALL
IBM z17

Grace Hopper sorri.

— Vocês chamam isso de easter egg?

Chamamos.

🦖 CAPÍTULO 14 — O FANTASMA DO 3090

Observe a simetria.

Em 1988:

IBM 3090
   │
   ▼
Universidade
   │
   ▼
Pesquisa
   │
   ▼
Novas aplicações

Em 2026:

IBM z17
   │
   ▼
Universidade
   │
   ▼
Pesquisa
   │
   ▼
IA
   │
   ▼
Agentes

Mudou a tecnologia.

Não mudou a pergunta fundamental:

O que podemos descobrir colocando tecnologia enterprise de verdade nas mãos de estudantes e pesquisadores?

Esse detalhe é importantíssimo.

Porque laboratório acadêmico normalmente significa uma versão reduzida do mundo empresarial.

Aqui o estudante ganha contato com uma plataforma construída para ambientes enterprise.

A Marist diz explicitamente que o z17 permitirá aos estudantes desenvolver e testar aplicações e obter experiência prática com tecnologia de escala empresarial.

⚓ CAPÍTULO 15 — POR QUE GRACE HOPPER É A TUTORA PERFEITA?

Agora podemos explicar nosso personagem.

Grace Hopper nasceu em 1906, foi matemática, professora, oficial da Marinha americana e uma das figuras centrais da história das linguagens de programação.

Ela trabalhou nos computadores Harvard Mark I e Mark II e posteriormente participou do desenvolvimento de compiladores e linguagens que ajudaram a abrir caminho para COBOL.

Seu trabalho com A-0 e posteriormente FLOW-MATIC foi fundamental para a ideia de que pessoas deveriam poder expressar problemas em linguagens mais próximas da comunicação humana, deixando o computador realizar a tradução para instruções de máquina. FLOW-MATIC tornou-se uma influência importante na criação de COBOL.

Pense na mudança filosófica.

Antes:

HUMANO
   ↓
LINGUAGEM DA MÁQUINA

Hopper ajudou a empurrar o mundo para:

HUMANO
   ↓
LINGUAGEM MAIS HUMANA
   ↓
COMPILADOR
   ↓
MÁQUINA

Décadas depois fazemos:

HUMANO
   ↓
LINGUAGEM NATURAL
   ↓
LLM
   ↓
AGENTE
   ↓
FERRAMENTAS
   ↓
MÁQUINA

Não são tecnologias equivalentes.

Mas existe uma deliciosa continuidade histórica na tentativa de elevar o nível de abstração entre intenção humana e execução computacional.

🐛 CAPÍTULO 16 — E SIM, TEMOS QUE FALAR DA MARIPOSA

Nenhum artigo sob tutela de Grace Hopper poderia escapar dela.

Em 1947, uma mariposa foi encontrada presa nos relés do Harvard Mark II e registrada no log como um caso real de “bug”. A palavra bug para problemas técnicos já existia; o episódio tornou-se famoso justamente pela brincadeira com um inseto real encontrado na máquina.

Agora imagine Grace visitando o laboratório de agentes.

AGENT A → AGENT B → AGENT C
                    ↓
                comportamento
                  inesperado

Ela pergunta:

— Onde está a mariposa?

O estudante responde:

— Almirante... desta vez ela está no prompt.

Talvez.

Ou nos dados.

Ou na ferramenta.

Ou na política.

Ou no modelo.

Ou na interação entre cinco agentes.

Bem-vindo ao debugging de 2026.

A mariposa evoluiu.

🚀 CAPÍTULO 17 — O SPYRE ENTRA NA SALA

Além do Telum II, existe outro personagem: IBM Spyre Accelerator.

Ele complementa o Telum II para workloads de IA, incluindo casos envolvendo IA generativa e dados não estruturados, como texto. A IBM tornou o Spyre disponível para z17 em outubro de 2025.

Simplificando bastante:

TELUM II
│
├── processamento
├── transações
└── inferência integrada

SPYRE
│
└── aceleração adicional de IA

Juntos, eles ampliam os tipos de workloads de IA que podem permanecer próximos ao ambiente enterprise.

E aqui aparece novamente uma palavra fundamental:

DADOS

Empresas possuem décadas de dados valiosos próximos de aplicações IBM Z.

Mover tudo indiscriminadamente para outro ambiente nem sempre é desejável.

Existem questões de:

latência
segurança
custos
governança
compliance
movimentação de dados

Portanto, em certos casos:

LEVAR IA AO DADO

pode ser arquiteturalmente mais interessante do que:

LEVAR TODO O DADO À IA

🎓 CAPÍTULO 18 — COMO EU ESTUDARIA ISSO SENDO COBOLZEIRO?

Se você está começando, não tente aprender tudo simultaneamente.

Faça por camadas.

CAMADA 1 — COBOL

Aprenda:

IDENTIFICATION DIVISION
DATA DIVISION
PROCEDURE DIVISION
PIC
MOVE
IF
EVALUATE
PERFORM
CALL
arquivos

Depois entenda bem estruturas de dados.

CAMADA 2 — z/OS

Aprenda:

TSO
ISPF
datasets
JCL
JES
SDSF

Você precisa entender onde seu programa vive.

CAMADA 3 — ENTERPRISE

Adicione:

CICS
Db2
VSAM
MQ
RACF

Agora você começa a compreender sistemas empresariais.

CAMADA 4 — INTEGRAÇÃO

Estude:

REST
JSON
APIs
z/OS Connect
mensageria
eventos

Seu COBOL deixa de ser uma ilha.

CAMADA 5 — IA

Só então conecte:

Machine Learning
LLM
RAG
AI Agents
Guardrails
Observability
AI Governance

E de repente a figura inteira começa a aparecer.

🔬 CAPÍTULO 19 — UM LABORATÓRIO CASEIRO PARA ENTENDER A IDEIA

Você não precisa possuir um z17 no quintal.

Vamos reproduzir conceitualmente a experiência.

Crie três agentes imaginários.

AGENT-01
RESEARCHER

AGENT-02
WRITER

AGENT-03
REVIEWER

Objetivo:

criar campanha de venda

Política:

não mentir
não inventar números
não expor dados pessoais

Fluxo:

RESEARCHER
     │
     ▼
WRITER
     │
     ▼
REVIEWER
     │
     ▼
OUTPUT

Agora introduza erros.

Diga ao Writer:

Aumente dramaticamente a urgência.

Veja se ele inventa:

ÚLTIMA UNIDADE!

Depois coloque o Reviewer.

Ele deveria detectar a afirmação sem evidência.

Agora você começou a entender experimentalmente:

AGENT
GUARDRAIL
ORCHESTRATION
OBSERVABILITY

Sem escrever uma linha de COBOL.

Depois faça a pergunta de mainframe:

Como registraríamos todas as decisões?

Pronto.

Você chegou à auditoria.

📋 CAPÍTULO 20 — O SMF DOS AGENTES

Imagine um log:

10:03:01 AGENT-A recebeu objetivo
10:03:02 AGENT-A consultou DATASET-X
10:03:04 AGENT-A chamou AGENT-B
10:03:07 AGENT-B utilizou TOOL-Y
10:03:09 POLICY-03 bloqueou operação
10:03:10 AGENT-B tentou alternativa
10:03:14 resultado enviado ao usuário

Agora conseguimos investigar.

Sem observabilidade teríamos apenas:

ALGO DEU ERRADO.

Todo programador mainframe sabe como essa frase é assustadora.

Por isso uma das conexões mais fortes entre IA moderna e computação enterprise talvez seja justamente:

autonomia exige observabilidade.

Quanto mais ações delegamos ao software, mais precisamos registrar o caminho percorrido.

💡 CAPÍTULO 21 — DICAS PARA O PROGRAMADOR COBOL INICIANTE

Primeira dica: não tenha medo da IA.

Ela não invalida aquilo que você está aprendendo.

Segunda: não transforme COBOL numa religião.

COBOL é uma ferramenta extraordinária para determinados problemas.

Terceira: aprenda arquitetura.

Pergunte sempre:

Onde está o dado?

Quem chama quem?

Quem autentica?

Quem autoriza?

Onde fica o estado?

Como recuperamos falhas?

Onde está o log?

Quarta: aprenda integração.

O profissional valioso não será necessariamente aquele que conhece 600 verbos COBOL.

Será aquele capaz de olhar:

COBOL
CICS
DB2
MQ
API
JAVA
PYTHON
AI

e entender como tudo conversa.

Quinta:

nunca pare no tutorial.

Grace Hopper provavelmente teria algo a dizer sobre isso.

🔭 CAPÍTULO 22 — TALVEZ ESTEJA ERRADA A PERGUNTA SOBRE O “FUTURO DO MAINFRAME”

Durante anos perguntamos:

“Como convencer jovens a aprender mainframe?”

Talvez seja uma pergunta ruim.

Talvez devamos colocar mainframe dentro dos problemas que jovens querem resolver.

Quer estudar IA?

Aqui está IBM Z.

Quer estudar cybersecurity?

Aqui está IBM Z.

Quer estudar agentes?

Aqui está IBM Z.

Quer estudar APIs?

Aqui está IBM Z.

Quer estudar finanças?

Aqui está IBM Z.

Quer estudar observabilidade?

Aqui está IBM Z.

E então:

AI
 ↓
Python
 ↓
API
 ↓
MQ
 ↓
CICS
 ↓
COBOL

Um belo dia o estudante pergunta:

— O que é esse programa chamado CUSTOMER01?

O veterano responde:

— Tem uns 34 anos. Não mexe sem fazer backup.

Pronto.

Capturamos outro mainframer.

🧠 CAPÍTULO 23 — O QUE REALMENTE ESTÁ SENDO ENSINADO?

Não é COBOL.

Não é IA.

Não é z17.

O verdadeiro assunto é:

SISTEMAS

Como sistemas recebem dados.

Como tomam decisões.

Como sistemas conversam.

Como falham.

Como são protegidos.

Como sabemos o que fizeram.

Como recuperamos o estado anterior.

Como impedimos que façam aquilo que não deveriam fazer.

Essa é uma formação muito mais poderosa do que simplesmente aprender uma linguagem.

Porque linguagens mudam.

Os problemas fundamentais permanecem.

⚓ EPÍLOGO — GRACE HOPPER DESLIGA O TERMINAL

O laboratório está quase vazio.

Nosso jovem COBOLzeiro continua olhando para o z17.

No começo do dia ele enxergava:

MAINFRAME
    =
  COBOL

Agora enxerga:

                    IBM z17
                       │
          ┌────────────┼────────────┐
          │            │            │
     TRANSAÇÕES       DADOS         IA
          │            │            │
        CICS          Db2        MODELOS
          │            │            │
        COBOL          MQ         AGENTES
          │            │            │
        RACF          APIs      GUARDRAILS
          │            │            │
          └────────────┼────────────┘
                       │
                 ENTERPRISE
                  COMPUTING

Grace Hopper pega o quepe.

Antes de sair, olha uma última vez para o estudante.

— Agora você entendeu?

— Acho que sim.

— Então me diga: para que serve o z17?

Ele pensa alguns segundos.

Não responde “COBOL”.

Não responde “IA”.

Não responde “banco”.

Finalmente diz:

— Para resolver problemas grandes onde desempenho, dados, segurança, confiabilidade e controle importam.

Grace sorri.

— Agora você começou a entender mainframe.

Ela caminha em direção à porta.

O estudante volta ao terminal.

Na tela aparece:

AGENT-004 ABENDED

Ele grita:

— Almirante! Temos um bug!

Grace Hopper para.

Olha lentamente para trás.

— Já procurou a mariposa?

***************************************
*                                     *
*          END OF JOB - RC=0000       *
*                                     *
***************************************

Quase quarenta anos separam o IBM 3090 instalado na Marist em 1988 do IBM z17 que aparece em Donnelly Hall em 2026.

Os computadores mudaram.

As linguagens mudaram.

As interfaces mudaram.

Os problemas ficaram maiores.

Mas aquela velha curiosidade de Grace Hopper continua perfeitamente atual:

não pergunte apenas como usar a máquina.

Pergunte:

“O que mais podemos fazê-la fazer?”

E talvez essa seja justamente a grande lição escondida dentro daquele z17 da Marist.

O mainframe não chegou ao futuro tentando continuar vivendo em 1988.

Ele chegou ao futuro porque continuamos encontrando problemas novos suficientemente difíceis para precisarmos dele outra vez.

☕⚓🦖🤖

Um Café no Bellacosa Mainframe.

Para saber mais

https://www.marist.edu/w/marist-ibm-z17-news-release?utm_source=chatgpt.com

segunda-feira, 24 de agosto de 2026

Prenda-me se For Capaz — Quando o IBM z17 Colocou uma IA na Alfândega da Transação e Mandou a Fraude Mostrar o Passaporte

Bellacosa Mainframe e o prenda-me se for capaz ia e ibm z17 contra fraudes

☕ Um Café no Bellacosa Mainframe

Prenda-me se For Capaz — Quando o IBM z17 Colocou uma IA na Alfândega da Transação e Mandou a Fraude Mostrar o Passaporte

Ou: Frank Abagnale entrou no banco vestido de piloto, o programa COBOL consultou o histórico, o Telum II calculou um score em menos de um milissegundo — e o Spyre ficou no andar de cima investigando por que o cheque tinha sido emitido por uma companhia aérea que não existia

Há uma cena clássica em qualquer bom filme de vigaristas.

O sujeito entra pela porta principal usando um uniforme impecável. Caminha como se conhecesse o prédio, cumprimenta o segurança pelo nome, segura uma pasta de couro e parece tão legítimo que ninguém se lembra de fazer a pergunta fundamental:

— Quem é você?

Frank Abagnale Jr., personagem central de Catch Me If You Can, construiu sua carreira cinematográfica exatamente nesse intervalo entre parecer legítimo e alguém conferir os dados.

Ele não precisava derrubar o sistema bancário. Não precisava explodir o datacenter, quebrar a criptografia ou fazer engenharia reversa no CICS.

Precisava apenas parecer verdadeiro durante tempo suficiente.

Fraude funciona assim.

Ela raramente entra pela janela usando máscara preta e carregando um saco com cifrão. Normalmente chega pela porta da frente com:

nome aparentemente correto;
cartão válido;
senha correta;
documento convincente;
dispositivo conhecido;
comportamento quase normal;
história razoavelmente plausível.

O problema da segurança moderna não é encontrar aquilo que parece completamente falso. Isso costuma ser fácil.

O problema é identificar aquilo que possui 97% de verdade e esconde a fraude nos 3% restantes.

E o banco precisa perceber isso antes que a autorização seja concluída.

Não amanhã.

Não depois do fechamento do movimento.

Não quando o cliente ligar informando que nunca comprou vinte televisores em Vladivostok.

A decisão precisa acontecer enquanto a transação ainda está atravessando o corredor.

É nesse ponto que entra o IBM z17, seu processador Telum II, o acelerador Spyre e uma ideia aparentemente simples, mas arquiteturalmente poderosa:

Em vez de mandar os dados até a inteligência artificial, colocamos a inteligência artificial perto dos dados.

Puxe uma cadeira, abra o ISPF e peça mais um café. Hoje acompanharemos uma transação bancária como se ela fosse Frank Abagnale tentando atravessar a alfândega vestido de piloto.

1. A fraude não começa com um crime: começa com uma história

Imagine que um cliente normalmente faça compras assim:

supermercados em Itatiba;
combustível duas vezes por mês;
serviços digitais recorrentes;
pequenas compras durante o dia;
um restaurante aos sábados;
nenhuma transação internacional recente.

Subitamente aparece uma tentativa de compra:

três notebooks;
às 3h17 da madrugada;
em outro país;
utilizando um dispositivo nunca visto;
depois de quatro tentativas recusadas;
com endereço de entrega diferente;
poucos minutos depois de uma alteração cadastral.

Nenhuma dessas características, sozinha, prova uma fraude.

Pessoas viajam.

Pessoas compram notebooks.

Pessoas trocam de celular.

Pessoas esquecem senhas.

Pessoas compram presentes de madrugada porque a insônia também participa da economia mundial.

Entretanto, quando combinamos todos os sinais, surge uma história estranha.

É exatamente esse tipo de relação que um modelo de machine learning procura aprender.

Ele não está buscando apenas uma regra rígida como:

SE VALOR > 10000
    ENTÃO RECUSAR

Ele tenta responder uma pergunta mais sofisticada:

Considerando dezenas ou centenas de características, o quanto esta transação se parece com as fraudes que observamos anteriormente?

A resposta geralmente não é “sim” ou “não”.

É um score.

Por exemplo:

RISCO-DE-FRAUDE = 0,91

Isso significa que o modelo encontrou uma combinação fortemente associada a comportamento fraudulento. Não significa que ele tenha presenciado o crime, interrogado o suspeito e recuperado o dinheiro numa mala escondida no aeroporto.

A IA não produz uma sentença judicial.

Ela produz evidência probabilística para ajudar o sistema a tomar uma decisão.

Esse será nosso primeiro ensinamento para o programador COBOL iniciante:

Machine learning não elimina a lógica de negócio. Ele acrescenta uma nova informação à lógica de negócio.

2. Treinamento e inferência: a escola e a prova oral

Antes de entender o Telum II, precisamos separar duas fases frequentemente misturadas.

Treinamento

Durante o treinamento, apresentamos ao modelo dados históricos:

compras legítimas;
fraudes confirmadas;
contestações;
chargebacks;
dispositivos comprometidos;
contas invadidas;
identidades roubadas;
comportamentos considerados normais;
comportamentos considerados suspeitos.

O modelo tenta encontrar relações matemáticas entre as características e os resultados conhecidos.

É como mostrar milhares de cheques a um investigador e dizer:

— Estes eram legítimos. Estes eram falsificados. Descubra os padrões.

O treinamento pode ser computacionalmente pesado. Pode utilizar GPUs, plataformas de ciência de dados, clusters, ambientes cloud ou infraestrutura especializada.

Esse trabalho não precisa acontecer dentro da transação bancária.

Nenhum cliente aceitará esperar três semanas diante da maquininha enquanto o modelo reaprende a história do sistema financeiro.

Inferência

Depois de treinado, o modelo pode receber uma nova transação e aplicar aquilo que aprendeu.

Essa aplicação é chamada de inferência.

O modelo recebe informações como:

VALOR
HORARIO
LOCALIZACAO
TIPO-DE-ESTABELECIMENTO
IDADE-DA-CONTA
DISPOSITIVO
QUANTIDADE-DE-TENTATIVAS
MEDIA-DE-GASTOS
DISTANCIA-DA-ULTIMA-COMPRA

E devolve algo como:

SCORE-DE-RISCO = 0,8734

Treinamento é a escola de investigadores.

Inferência é o momento em que o inspetor olha para o passaporte, compara os sinais e decide se chamará o supervisor.

O IBM z17 é especialmente interessante nessa segunda fase: executar a inferência rapidamente, em grande escala e suficientemente perto da aplicação transacional para que o resultado ainda possa influenciar a autorização.

3. O que acontece quando o cartão encosta na maquininha?

Vamos acompanhar nossa transação passo a passo.

A implementação real varia entre instituições, bandeiras, adquirentes e sistemas, mas o fluxo conceitual pode ser representado assim:

MAQUININHA
    ↓
ADQUIRENTE
    ↓
REDE OU BANDEIRA
    ↓
BANCO EMISSOR
    ↓
SISTEMA DE AUTORIZAÇÃO
    ↓
ANÁLISE DE RISCO
    ↓
APROVAR, NEGAR OU DESAFIAR

Dentro do banco, o sistema pode consultar:

situação do cartão;
senha ou credencial;
saldo;
limite;
bloqueios;
restrições geográficas;
quantidade de operações recentes;
perfil do cliente;
regras antifraude;
resultado de modelos de IA.

Em um ambiente mainframe, partes desse processamento podem envolver:

CICS;
IMS;
Db2;
VSAM;
IBM MQ;
programas COBOL;
serviços Java;
APIs;
z/OS Connect;
componentes Linux executando no IBM Z;
rotinas de segurança;
mecanismos de criptografia;
serviços de inferência.

O programa COBOL não precisa “virar uma IA”.

Ele pode continuar fazendo aquilo que sempre fez muito bem: orquestrar regras de negócio, validar campos, controlar estados, registrar decisões e preservar a integridade da transação.

A diferença é que agora ele pode receber um score calculado por um modelo.

Conceitualmente, nossa lógica poderia se parecer com isto:

       EVALUATE TRUE
           WHEN CARTAO-BLOQUEADO
               MOVE '05' TO CODIGO-RESPOSTA

           WHEN SCORE-FRAUDE > 900
               MOVE 'N' TO AUTORIZAR
               MOVE 'FRAUDE ALTA' TO MOTIVO-DECISAO

           WHEN SCORE-FRAUDE > 650
               MOVE 'S' TO EXIGIR-AUTENTICACAO
               MOVE 'VALIDACAO ADICIONAL'
                 TO MOTIVO-DECISAO

           WHEN LIMITE-DISPONIVEL < VALOR-COMPRA
               MOVE 'N' TO AUTORIZAR
               MOVE 'LIMITE INSUFICIENTE'
                 TO MOTIVO-DECISAO

           WHEN OTHER
               MOVE 'S' TO AUTORIZAR
               MOVE 'APROVADA' TO MOTIVO-DECISAO
       END-EVALUATE.

Naturalmente, um sistema bancário real será muito mais sofisticado. A ordem das verificações, os limites, as exceções e as regras serão governados por políticas específicas.

Mas o princípio é este:

IA calcula o risco.
A aplicação toma a decisão.

Essa separação é saudável.

O modelo não deve possuir autoridade ilimitada simplesmente porque tem “inteligência artificial” no nome.

4. O orçamento de tempo da transação

Quando alguém lê que o z17 pode executar inferências com tempo de resposta inferior a 1 milissegundo, pode imaginar que toda a compra será concluída nesse intervalo.

Não é isso.

Um milissegundo é:

[
1\text{ ms} = 0{,}001\text{ segundo}
]

O número divulgado refere-se ao processamento da inferência no cenário medido, não ao tempo total da transação desde a maquininha até a resposta final.

A operação completa ainda pode incluir:

transmissão pelas redes;
validação criptográfica;
leitura de bancos de dados;
execução de regras;
verificação de limite;
gravação de logs;
atualização de saldos;
journaling;
construção da resposta;
retorno à maquininha.

Pense na transação como um filme de duas horas e na inferência como uma cena importante dentro dele.

O Telum II não precisa filmar o longa-metragem inteiro em um milissegundo. Ele precisa executar sua cena sem estourar o cronograma da produção.

Isso é fundamental porque toda aplicação crítica possui um orçamento de latência.

Se a autorização inteira precisa responder em determinado intervalo, não podemos entregar quase todo esse orçamento a um modelo remoto.

Uma chamada externa pode exigir:

montar uma requisição;
serializar os dados;
criptografar;
atravessar a rede;
autenticar no serviço;
entrar numa fila;
executar a inferência;
montar a resposta;
retornar pela rede;
tratar timeouts e erros.

Mesmo que a média seja boa, há uma pergunta mais importante:

O comportamento continuará previsível durante os picos?

Em ambiente crítico, não basta dizer que a resposta média foi de 5 ms.

Precisamos conhecer:

percentil 95;
percentil 99;
percentil 99,9;
comportamento em saturação;
impacto sobre outros workloads;
tempo máximo aceitável;
estratégia de fallback;
resultado quando o serviço não responder.

Uma média bonita pode esconder um pequeno grupo de respostas terrivelmente lentas.

E o sistema bancário não pode dizer ao comerciante:

— Tivemos um excelente tempo médio hoje. Infelizmente, sua venda caiu no percentil azarado.

5. Telum II: o investigador sentado dentro do banco

O Telum II é o processador que equipa o IBM z17 e inclui a segunda geração do acelerador integrado de IA.

A palavra mais importante é “integrado”.

A inferência pode acontecer muito perto da carga transacional, sem depender de um acelerador remoto pendurado do outro lado de uma rede.

Segundo a IBM, o acelerador do Telum II oferece quatro vezes a capacidade computacional da geração anterior, chegando a 24 TOPS, além de suporte a INT8 e melhorias destinadas a ampliar a variedade de modelos executáveis. O processador também trabalha com caches maiores, melhorias de roteamento e uma DPU destinada a auxiliar operações de entrada e saída. IBM Telum II.

O que são TOPS?

TOPS significa trillions of operations per second, ou trilhões de operações por segundo.

É uma medida da capacidade computacional do acelerador.

Entretanto, TOPS não contam toda a história.

Dois aceleradores com números semelhantes podem produzir resultados diferentes devido a:

arquitetura;
precisão numérica;
eficiência do compilador;
movimentação de dados;
memória;
cache;
tipo do modelo;
tamanho do lote;
utilização dos núcleos;
integração com a aplicação.

É como comparar dois restaurantes apenas pelo número de fogões. O resultado também depende da cozinha, dos ingredientes, dos garçons e de alguém lembrar que o cliente pediu o bife sem cebola.

Por que INT8 importa?

Modelos de IA podem trabalhar com diferentes precisões numéricas.

INT8 utiliza números inteiros de oito bits. Em muitos cenários de inferência, isso permite:

representar os parâmetros com menos espaço;
movimentar menos dados;
executar mais operações;
consumir menos energia;
aumentar o throughput.

Essa redução de precisão precisa ser validada para garantir que o modelo continue suficientemente acurado.

Não adianta tornar a inferência quatro vezes mais rápida se ela passar a confundir Frank Abagnale com o gerente da agência.

6. Spyre: a equipe de inteligência no andar de cima

Se o Telum II é o agente posicionado diretamente no balcão de imigração, o Spyre é uma equipe adicional de inteligência.

O IBM Spyre Accelerator é fornecido em placas PCIe e possui 32 núcleos de aceleração por chip. Várias placas podem ser combinadas para atender cargas maiores. O produto tornou-se disponível para IBM z17 e LinuxONE 5 em outubro de 2025. Anúncio oficial do Spyre.

Ele foi pensado para complementar o acelerador do Telum II em cenários como:

modelos maiores;
vários modelos trabalhando conjuntamente;
IA generativa;
modelos de linguagem;
aplicações multimodais;
assistentes;
agentes de IA;
análise de dados estruturados e textuais.

Imagine uma transação suspeita.

O Telum II pode executar rapidamente o modelo preditivo principal:

Risco calculado: 78%.

Uma arquitetura mais sofisticada pode combinar outros modelos:

um modelo para o comportamento do dispositivo;
outro para identidade;
outro para lavagem de dinheiro;
um encoder examinando descrições textuais;
um modelo avaliando relações entre contas;
um sistema generativo produzindo um resumo para o analista.

Isso é chamado de abordagem multimodelo ou, em certos contextos, ensemble.

O benchmark dos 450 bilhões de inferências antifraude não deve ser apresentado como resultado obrigatório da soma Telum II mais Spyre.

A alegação foi originalmente associada ao acelerador integrado do Telum II. O Spyre amplia a capacidade e o repertório do sistema, principalmente para modelos mais complexos e novas cargas de IA.

Em resumo:

TELUM II
Inferência transacional rápida, integrada e previsível.

SPYRE
Capacidade complementar para modelos maiores, múltiplos e generativos.

Os dois podem trabalhar dentro da mesma estratégia, mas não são peças idênticas.

7. Cinco milhões por segundo não são 450 bilhões por dia

Agora chegamos ao Easter egg matemático escondido no roteiro.

Originalmente diziamos que o z17 podia processar até 5 milhões de inferências por segundo, equivalentes a mais de 450 bilhões por dia.

Vamos convocar o programa COBOL da contabilidade:

[
5.000.000 \times 86.400 = 432.000.000.000
]

Um dia possui 86.400 segundos.

Portanto, cinco milhões de inferências por segundo equivalem a 432 bilhões por dia.

Para chegar a 450 bilhões, precisaríamos de aproximadamente:

[
450.000.000.000 \div 86.400
= 5.208.333
]

Ou cerca de 5,21 milhões de inferências por segundo.

Isso não significa necessariamente que a IBM tenha cometido um erro.

A IBM apresenta números arredondados e indicadores derivados de cenários específicos:

até 5 milhões de inferências por segundo;
até 450 bilhões de inferências por dia;
resposta de aproximadamente 1 ms ou inferior, dependendo da declaração.

O erro aparece quando alguém liga as duas frases com “ou seja”, transformando indicadores de benchmark em uma conversão matemática exata.

Uma formulação mais segura seria:

O IBM z17 pode alcançar até 5 milhões de inferências por segundo em determinado cenário e, segundo outro indicador divulgado pela IBM, até 450 bilhões de inferências por dia.

Curiosidade para o programador iniciante: sempre desconfie de expressões como:

“ou seja”;
“equivale a”;
“portanto”;
“isso representa”.

Elas parecem conectores inocentes, mas frequentemente escondem o exato lugar onde marketing, arredondamento e matemática decidiram falsificar um cheque juntos.

8. O que o benchmark realmente mediu?

O número de 450 bilhões por dia não caiu do céu diretamente na capa de uma revista.

Segundo a metodologia publicada pela IBM, o resultado foi extrapolado de testes internos com:

hardware IBM tipo 9175;
modelo LSTM sintético para detecção de fraude em cartões;
batch size de 160;
ambientes Red Hat Enterprise Linux e z/OS;
z/OS Container Extensions;
configuração específica de CPUs, IFLs, zIIPs e memória.

A IBM também informa claramente que os resultados podem variar. Metodologia do benchmark do z17.

O que é LSTM?

LSTM significa Long Short-Term Memory.

É um tipo de rede neural recorrente desenvolvido para trabalhar com sequências e dependências temporais.

Em fraude, isso pode ser útil porque o significado de uma transação depende frequentemente daquilo que aconteceu antes.

Exemplo:

10:01 — compra de R$ 25 em Itatiba
10:04 — compra de R$ 19 em Itatiba
10:07 — compra de R$ 12.000 em Tóquio

A última transação não é suspeita apenas pelo valor. Ela é suspeita pela relação temporal e geográfica com as anteriores.

Modelos atuais podem empregar outras arquiteturas, mas a LSTM continua sendo uma referência útil para determinados problemas sequenciais.

O que é batch size?

Batch size é a quantidade de amostras processadas conjuntamente.

No teste divulgado, o lote era de 160 inferências.

Isso ajuda o acelerador a utilizar melhor seus recursos, assim como uma transportadora consegue mover caixas com mais eficiência quando carrega um caminhão inteiro em vez de enviar um veículo para cada pacote.

Entretanto, batching cria uma consideração importante:

throughput mede quanto trabalho total é concluído;
latência mede quanto tempo cada solicitação espera e leva para ser respondida.

Grandes lotes podem aumentar o throughput, mas, dependendo da implementação, também podem fazer uma solicitação aguardar o lote ser formado.

Por isso, nunca analise apenas um número.

Pergunte:

Qual era o modelo?
Qual era o tamanho do lote?
Quantas threads foram usadas?
Qual era a configuração?
A latência apresentada é média ou percentil?
O resultado foi medido ou extrapolado?
Havia carga transacional concorrente?
O modelo era real ou sintético?

Essa é uma dica de ouro para qualquer benchmark, não apenas de mainframe.

9. Inferência não é sinônimo de transação

Outra armadilha está na palavra “operação”.

Quando ouvimos “450 bilhões de operações de inferência”, é tentador imaginar 450 bilhões de compras analisadas.

Mas uma transação pode executar vários modelos:

MODELO 1 — fraude do cartão
MODELO 2 — risco do dispositivo
MODELO 3 — identidade comprometida
MODELO 4 — localização anômala
MODELO 5 — lavagem de dinheiro
MODELO 6 — conta-laranja

Uma única compra poderia gerar seis inferências.

Logo:

1 transação ≠ obrigatoriamente 1 inferência

Também é possível processar inferências em lotes ou utilizar modelos diferentes conforme o tipo de operação.

O número demonstra capacidade de execução de modelos. Não deve ser convertido automaticamente em quantidade de cartões, clientes ou compras.

É como olhar o contador de instruções executadas pelo processador e concluir que cada instrução representa um cliente atendido.

O COBOLzeiro olha para isso, toma um gole de café e pergunta:

— Onde está o copybook com a definição dessa unidade?

Pergunta correta.

10. “Levar a IA até os dados” não significa eliminar toda movimentação

Uma das frases mais fortes da apresentação do z17 é a ideia de executar IA onde os dados residem.

Mas precisamos interpretá-la corretamente.

Não significa que nenhum byte jamais se mova.

Dentro do sistema ainda haverá:

leitura de registros;
acesso a memória;
comunicação entre componentes;
preparação das variáveis;
busca de características;
passagem de parâmetros;
gravação do resultado.

O que pode ser evitado é a necessidade de enviar a transação para um serviço remoto de inferência, fora do ambiente em que a aplicação crítica está sendo executada.

Isso reduz:

dependência da rede;
latência externa;
serialização;
pontos adicionais de falha;
exposição de dados sensíveis;
fronteiras operacionais;
complexidade de auditoria.

Compare os dois caminhos.

Inferência remota

COBOL/CICS
    ↓
API
    ↓
GATEWAY
    ↓
REDE
    ↓
SERVIÇO EXTERNO
    ↓
MODELO
    ↓
REDE
    ↓
RESPOSTA
    ↓
DECISÃO

Inferência local

COBOL/CICS
    ↓
SERVIÇO DE INFERÊNCIA NO AMBIENTE IBM Z
    ↓
TELUM II
    ↓
SCORE
    ↓
DECISÃO

O segundo caminho não é magicamente gratuito, mas reduz fronteiras.

E cada fronteira removida significa menos um lugar para:

perder tempo;
falhar;
expirar;
autenticar;
converter dados;
abrir uma porta de ataque;
explicar para a auditoria.

11. O cloud não é o vilão do filme

Seria confortável transformar esta história num duelo:

MAINFRAME = HERÓI
CLOUD = VIGARISTA

Mas arquitetura séria não funciona como desenho animado.

Cloud pode ser excelente para:

treinamento de modelos;
experimentação;
notebooks;
ciência de dados;
armazenamento histórico;
elasticidade;
processamento assíncrono;
comparação de versões;
grandes modelos;
investigação posterior.

O IBM Z pode ser particularmente apropriado para:

inferência na transação;
dados regulados;
baixa latência previsível;
enorme volume;
integração com sistemas existentes;
disponibilidade;
segurança e auditoria;
continuidade operacional.

Uma arquitetura híbrida madura pode funcionar assim:

PLATAFORMA DE DADOS OU CLOUD
    ↓
TREINAMENTO
    ↓
VALIDAÇÃO
    ↓
APROVAÇÃO DO MODELO
    ↓
EMPACOTAMENTO
    ↓
IMPLANTAÇÃO NO IBM Z
    ↓
INFERÊNCIA TRANSACIONAL
    ↓
MONITORAMENTO E FEEDBACK

O modelo aprende em um ambiente e trabalha em outro.

Isso também cria responsabilidades importantes:

versionar o modelo;
registrar quem o aprovou;
controlar sua implantação;
medir drift;
comparar versões;
permitir rollback;
manter explicabilidade;
preservar evidências.

O modelo é um componente de produção. Deve receber disciplina semelhante à de qualquer outro artefato crítico.

Se você jamais colocaria um load module não testado diretamente em produção, também não deveria instalar um modelo treinado na sexta-feira por alguém que escreveu no change:

“Melhorias diversas. Baixo risco.”

12. Falso positivo: quando o FBI prende o piloto verdadeiro

Um sistema antifraude pode errar de duas maneiras principais.

Falso negativo

A transação era fraudulenta, mas foi considerada legítima.

Consequências possíveis:

perda financeira;
chargeback;
investigação;
desgaste com o cliente;
impacto regulatório.

Falso positivo

A transação era legítima, mas foi considerada fraudulenta.

Consequências:

compra recusada;
cliente constrangido;
perda da venda;
chamada ao atendimento;
cancelamento do cartão;
deterioração da confiança.

Imagine o cliente viajando pela Europa depois de meses comprando apenas em São Paulo.

O comportamento mudou bruscamente, mas existe uma explicação legítima.

Um modelo ruim pode confundir “fora do padrão” com “fraude”.

Essa é uma distinção essencial:

Anomalia não é prova de crime. É motivo para investigar ou aplicar controles proporcionais.

Por isso, uma instituição pode criar diferentes respostas:

risco baixo: aprovar;
risco moderado: solicitar biometria;
risco alto: enviar notificação;
risco muito alto: bloquear;
caso complexo: análise humana.

Quanto mais rápido o score estiver disponível, mais opções o banco terá.

Em vez de escolher apenas entre aprovar e negar, pode inserir autenticação adaptativa sem destruir a experiência do cliente.

13. Segurança local não é segurança automática

Colocar a IA no mainframe não elimina:

credenciais roubadas;
engenharia social;
fraude interna;
dados de treinamento contaminados;
modelos enviesados;
configuração incorreta;
permissões excessivas;
falhas de aplicação;
ataques adversariais;
decisões de negócio ruins.

O ambiente local pode ajudar a proteger:

confidencialidade dos dados;
propriedade intelectual do modelo;
tráfego sensível;
disponibilidade;
cadeia de auditoria;
previsibilidade operacional.

Mas o sistema ainda precisa de:

RACF bem administrado;
princípio do menor privilégio;
criptografia;
segregação de funções;
logging;
monitoramento;
revisão de modelos;
gestão de vulnerabilidades;
resposta a incidentes;
governança de IA.

A IA é apenas uma camada.

A arquitetura completa se parece mais com isto:

IDENTIDADE
    +
DADOS CONFIÁVEIS
    +
MODELO VALIDADO
    +
APLICAÇÃO CORRETA
    +
REGRAS DE NEGÓCIO
    +
AUDITORIA
    +
RESPOSTA OPERACIONAL

Se qualquer camada estiver comprometida, o vigarista poderá atravessar o sistema usando um belo uniforme e um crachá perfeitamente impresso.

14. Passo a passo para o COBOLzeiro entender uma integração com IA

Você não precisa se transformar imediatamente em cientista de dados. Comece fazendo as perguntas corretas.

Passo 1 — Entenda o evento de negócio

Defina exatamente o que será avaliado:

compra?
PIX?
abertura de conta?
alteração cadastral?
saque?
pedido de empréstimo?

Passo 2 — Identifique as entradas

Descubra quais informações alimentam o modelo:

VALOR
HORARIO
PAIS
DISPOSITIVO
HISTORICO
TENTATIVAS
IDADE-DA-CONTA
TIPO-DE-CANAL

Passo 3 — Conheça o contrato

O serviço deve possuir um contrato claro:

ENTRADA:
    DADOS-DA-TRANSACAO

SAIDA:
    SCORE-DE-RISCO
    VERSAO-DO-MODELO
    CODIGO-DE-STATUS
    MOTIVO
    TEMPO-DE-INFERENCIA

A versão do modelo é fundamental para auditoria.

Passo 4 — Defina o timeout

O que acontecerá se a inferência não responder?

negar tudo;
aprovar tudo;
usar regras tradicionais;
chamar um modelo alternativo;
encaminhar para validação adicional?

Não responder também é um resultado operacional, e precisa de regra.

Passo 5 — Separe score de decisão

Evite permitir que o modelo controle diretamente a transação.

MODELO → SCORE
REGRA → DECISÃO

Passo 6 — Registre evidências

Grave pelo menos:

identificador da transação;
horário;
score;
versão do modelo;
decisão;
regra aplicada;
resultado posterior conhecido.

Isso permite reconstruir a história.

Passo 7 — Monitore desempenho e qualidade

Observe:

latência;
throughput;
erros;
timeouts;
falsos positivos;
falsos negativos;
mudança no perfil dos dados;
queda de acurácia.

Passo 8 — Prepare rollback

Se o novo modelo começar a bloquear metade da população de Itatiba, você precisa retornar rapidamente à versão anterior.

MLOps sem rollback é apenas aventura.

15. Easter eggs recuperados do cheque falsificado

Easter egg número 1 — O mainframe já fazia “IA” antes da moda

Bancos utilizam modelos estatísticos, regras, scores e análise de risco há décadas.

O que mudou não foi a descoberta repentina de que padrões podem indicar fraude. Mudaram:

escala;
variedade dos modelos;
integração;
velocidade;
capacidade de processar mais sinais;
uso de aceleradores especializados.

A inteligência transacional não nasceu ontem. Ela ganhou músculos novos.

Easter egg número 2 — O COBOL não perdeu o emprego para a IA

A IA pode calcular a probabilidade de fraude, mas alguém ainda precisa:

validar a mensagem;
aplicar o limite;
controlar a conta;
atualizar o saldo;
produzir o registro;
garantir atomicidade;
tratar exceções;
responder ao canal.

O modelo pode dizer que o cheque parece suspeito.

O COBOL continua sendo o funcionário que decide se o cheque entra no movimento e garante que o livro-caixa feche no final do dia.

Easter egg número 3 — Frank Abagnale trabalhou para o FBI

A melhor ironia da história é que o fraudador pode ensinar o sistema a identificar fraudes.

Na segurança, o conhecimento ofensivo frequentemente fortalece a defesa.

Da mesma forma, fraudes confirmadas tornam-se exemplos de treinamento. O atacante, involuntariamente, deixa material para melhorar o próximo modelo.

É quase um programa de estágio não remunerado do Red Team.

Easter egg número 4 — A velocidade pode reduzir fraude sem aumentar bloqueios

Com mais capacidade de inferência, o banco pode executar vários modelos em vez de depender de uma única regra agressiva.

Isso permite distinguir melhor:

comportamento incomum;
comportamento realmente malicioso;
cliente viajando;
conta comprometida;
compra legítima de alto valor;
fraude coordenada.

Mais inteligência pode significar não apenas bloquear mais, mas bloquear melhor.

Easter egg número 5 — O mainframe não precisa aparecer na manchete

Quando uma transação é aprovada corretamente, ninguém comemora:

— Fantástico! O sistema consultou o limite, avaliou o risco, atualizou os registros e respondeu dentro do SLA!

O cliente apenas guarda o cartão.

O sucesso do sistema crítico é frequentemente invisível.

Ele só vira notícia quando para.

16. O verdadeiro “Catch Me If You Can” da fraude moderna

Frank Abagnale precisava manter sua história por alguns minutos.

A fraude digital precisa parecer legítima por milissegundos.

Ela corre entre:

a captura dos dados;
a autenticação;
a análise;
a autorização;
a liquidação.

O IBM z17 procura fechar esse intervalo colocando capacidade de inferência dentro do núcleo transacional.

Não é uma solução mágica.

Não elimina a necessidade de investigadores, regras, autenticação, governança, criptografia ou analistas.

O que ele faz é permitir que a aplicação pergunte, no momento decisivo:

Esta operação se parece com aquilo que afirma ser?

E receba uma resposta antes que o suspeito chegue ao portão de embarque.

A grande inovação não está apenas em fazer cinco milhões de cálculos por segundo. Está em realizar a análise cedo o bastante para mudar o destino da transação.

Antes, muitos sistemas descobriam a fraude depois:

a operação era aprovada;
o dinheiro seguia seu caminho;
o cliente reclamava;
começava a investigação;
alguém tentava recuperar o prejuízo.

Era perícia.

Com a inferência transacional, a inteligência pode participar do processo antes da conclusão:

a operação chega;
os dados são avaliados;
o modelo produz o score;
as regras interpretam o risco;
o sistema aprova, bloqueia ou desafia;
a decisão é registrada.

É a diferença entre encontrar a falsificação no arquivo morto e pará-la no balcão.

Epílogo — O cheque, o COBOL e o homem de uniforme

No final do filme, o vigarista não é derrotado porque alguém construiu uma parede infinitamente alta.

Ele é alcançado porque o investigador aprende a reconhecer seus padrões.

O papel usado.

A forma de imprimir.

As cidades escolhidas.

O modo como ele conta a história.

Fraude é repetição disfarçada de improviso.

A inteligência artificial encontra valor justamente nessa repetição: relações pequenas demais, rápidas demais ou numerosas demais para depender exclusivamente da observação humana.

O Telum II aproxima essa análise do lugar onde a decisão acontece.

O Spyre amplia o repertório para modelos maiores e abordagens mais complexas.

O z17 fornece o ambiente para executar isso com a velocidade, a escala, o isolamento e a previsibilidade exigidos por sistemas críticos.

E o COBOL?

O COBOL continua no balcão.

Recebe a mensagem.

Valida o cartão.

Consulta o limite.

Interpreta o score.

Executa a regra.

Grava a decisão.

Libera ou recusa a transação.

Talvez ele não apareça no trailer. Talvez ninguém compre uma camiseta escrito PERFORM UNTIL FRAUD-DETECTED. Mas, quando Frank Abagnale chegar usando o uniforme de piloto, será o velho programa transacional que olhará o score calculado em menos de um milissegundo e dirá:

       IF IDENTIDADE-PARECE-PERFEITA
          AND HISTORIA-NAO-FECHA
              MOVE 'N' TO AUTORIZAR
              MOVE 'PRENDA-ME-SE-FOR-CAPAZ'
                TO MOTIVO-RECUSA
       END-IF.

No andar de cima, o Spyre cruza os dossiês.

Dentro do processador, o Telum II examina o próximo passageiro.

No CICS, outra tarefa começa.

E em algum lugar do datacenter, um COBOL escrito quando Leonardo DiCaprio ainda era criança continua protegendo uma transação que jamais saberá seu nome.

Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2024/01/megafilmeshd-quando-um-casal-do.html

https://eljefemidnightlunch.blogspot.com/2026/08/spy-vs-spy-no-tribunal-as-trapacas.html

https://eljefemidnightlunch.blogspot.com/2026/08/red-team-e-os-doze-trabalhos-de-asterix.html

domingo, 12 de julho de 2026

O Mainframe Morreu... Pela Vigésima Vez Como a Narrativa do Mercado Ignorou a Engenharia

Bellacosa Mainframe e a milesima morte do mainframe

☕ Um Café no Bellacosa Mainframe

O Mainframe Morreu... Pela Vigésima Vez

Como a Narrativa do Mercado Ignorou a Engenharia — e Por Que o IBM Z Continua Vendendo Mais do que Nunca

Existe uma enorme diferença entre Marketing e Engenharia

A indústria de TI vive de novidades.

Todo ano aparece um novo "salvador da informática".

Foi assim com

Cliente-Servidor
ERP
Java
Linux
SOA
Cloud
Containers
Kubernetes
Blockchain
Big Data
IA
Agentic AI

Cada tecnologia chega acompanhada da mesma promessa:

"Agora tudo vai mudar."

Na prática...

Quase nada muda tão rapidamente.

Porque sistemas críticos não funcionam como aplicativos de celular.

Bellacosa Mainframe desde o projeto apollo a ia

O problema do Mainframe

O Mainframe sempre sofreu um problema de imagem.

Imagine dois computadores.

Um deles

LEDs RGB
Docker
Kubernetes
React
Node
Linux

Parece moderno.

O outro

Tela verde
ISPF
COBOL
JCL
CICS
VSAM

Parece antigo.

Mas aparência e capacidade não são a mesma coisa.

A maior mentira repetida da TI

Durante quarenta anos ouvimos:

"O Mainframe vai desaparecer."

Curiosamente...

Quem dizia isso normalmente nunca trabalhou em um.

É semelhante a alguém afirmar:

"Os aviões estão ultrapassados."

Porque nunca entrou na cabine de um Boeing.

O dia em que decretaram a morte do mainframe

https://eljefemidnightlunch.blogspot.com/2026/02/o-dia-em-que-decretaram-morte-do.html

COBOL NÃO ESTÁ MORRENDO — ELE ESTÁ ESCONDENDO SEGREDOS QUE SUA EMPRESA NÃO CONSEGUE MAIS ENTENDER

https://eljefemidnightlunch.blogspot.com/2024/12/cobol-nao-esta-morrendo-ele-esta.html

20 ANOS APÓS O BUG DO MILÊNIO (Y2K) — O QUE O MUNDO MAINFRAME REALMENTE APRENDEU

https://eljefemidnightlunch.blogspot.com/2020/01/20-anos-apos-o-bug-do-milenio-y2k-o-que.html

O que realmente acontece dentro de um banco?

Quando você faz um PIX.

Em menos de alguns segundos acontecem dezenas de operações.

Exemplo:

Validação

↓

Autenticação

↓

Consulta de saldo

↓

Bloqueio

↓

Débito

↓

Crédito

↓

Logs

↓

Auditoria

↓

Notificação

↓

Confirmação

Tudo isso precisa acontecer:

sem erro
sem perda
sem duplicidade
em milissegundos

Milhões de vezes por minuto.

Isso não é um site

É um sistema transacional.

Existe uma enorme diferença.

Cloud resolve tudo?

Não.

Cloud resolve muitos problemas.

Mas não todos.

Cloud é excelente para:

aplicações web
microsserviços
APIs
elasticidade
processamento distribuído
IA

Mas quando falamos de

contas bancárias
previdência
cartões
clearing
bolsa de valores

o requisito muda completamente.

Agora entram em cena:

ACID
Consistência
Atomicidade
Integridade
Recuperação
Segurança

É exatamente onde o IBM Z domina.

Por que migrar é tão difícil?

Imagine um banco.

40 anos de software.

Imagine:

80 milhões de clientes
120 bilhões de linhas processadas diariamente
milhares de programas COBOL
centenas de bases DB2
milhares de jobs
MQ
CICS
IMS

Agora alguém diz:

"Vamos migrar tudo."

Parece simples.

Não é.

O iceberg

O código representa apenas a ponta.

Abaixo dele existem

Regras de negócio

+

Integrações

+

Auditoria

+

Compliance

+

Performance

+

Segurança

+

Histórico

Isso levou décadas para ser construído.

O verdadeiro patrimônio

As empresas não pagam bilhões pelo hardware.

Elas pagam pela previsibilidade.

Um banco prefere:

99,999%

todos os dias

do que

100%

durante uma semana
e
80%

na seguinte.

Modernizar ou substituir?

Essa talvez seja a maior mudança dos últimos anos.

Antes:

Replace

Hoje:

Modernize

É completamente diferente.

Modernização não significa abandonar COBOL

Significa adicionar.

Por exemplo:

REST API

↓

z/OS Connect

↓

COBOL

↓

DB2

O COBOL continua existindo.

Mas agora conversa com:

Java
Python
Node
Mobile
Cloud

IBM percebeu isso antes do mercado

Enquanto muita gente dizia

"o Mainframe morreu"

a IBM fazia outra coisa.

Investia bilhões.

Vieram:

Telum
Telum II
Spyre AI Accelerator
Quantum Safe Cryptography
zCX
OpenShift
LinuxONE
z/OS Container Extensions
AI embarcada
Vector Database
Hybrid Search
Watsonx
Zowe
Ansible
DevOps

Isso não é uma empresa abandonando um produto.

É exatamente o contrário.

O z17

O z17 representa uma mudança importante.

Não é apenas mais CPU.

É uma plataforma de IA.

Imagine um pagamento.

Enquanto a transação acontece...

O acelerador de IA verifica:

fraude
comportamento
risco
anomalias

Tudo em tempo real.

Sem enviar dados para outro servidor.

Isso reduz:

latência
custo
risco

Criptografia Pós-Quântica

Outro detalhe ignorado.

Os bancos pensam em décadas.

Não em meses.

Dados criptografados hoje poderão ser quebrados por computadores quânticos no futuro.

O IBM Z já incorpora algoritmos preparados para esse cenário, permitindo uma transição gradual para padrões pós-quânticos conforme evoluem as normas do setor.

Rack Mount

Essa talvez seja uma das notícias mais interessantes.

Durante anos muita gente associou Mainframe a isto:

███████████

Um enorme gabinete
ocupando uma sala inteira.

Hoje isso mudou.

O IBM z17 também passou a ser oferecido em formatos mais compactos, compatíveis com racks padrão, ampliando o acesso a organizações menores e novos cenários de uso.

É uma mudança estratégica.

IBM não diminuiu o Mainframe.

Ela diminuiu a barreira de entrada.

O mito do legado

"Legado" costuma ser usado como crítica.

Mas vamos trocar a palavra.

Em vez de

Legado

use

Patrimônio Digital

Muda completamente.

Imagine um castelo medieval.

Ele tem 700 anos.

Você derruba?

Ou reforma?

É exatamente isso que acontece.

O COBOL continua crescendo

Outro paradoxo.

Enquanto muitos decretavam sua morte,

universidades,

bootcamps,

IBM Z Xplore,

Open Mainframe Project,

Master the Mainframe,

IBM SkillsBuild,

Z Educator Experience,

formam milhares de novos profissionais.

Porque a demanda continua existindo.

A economia explica melhor que a tecnologia

Suponha duas opções.

Opção A

Migrar tudo.

Custo:

US$ 2 bilhões

Tempo:

8 anos

Risco:

Altíssimo

Opção B

Modernizar.

Custo:

20% disso

Resultado:

Mesmo software

Mais APIs

Mais IA

Mais segurança

Mais integração

Qual um CIO escolheria?

A resposta costuma ser evidente.

O efeito "iceberg invisível"

O usuário vê:

PIX realizado.

O Mainframe executou centenas de verificações invisíveis antes da confirmação.

Quando tudo funciona, ninguém percebe.

Esse é o maior elogio que uma infraestrutura crítica pode receber.

O Mainframe virou uma plataforma híbrida

Hoje ele conversa naturalmente com:

Kubernetes
Docker
Linux
OpenShift
Kafka
MQ
REST
GraphQL
Python
Java
Git
Jenkins
GitHub Actions
Zowe
VS Code
Ansible
Watsonx
APIs
Microsserviços

O Mainframe moderno não vive isolado; ele é parte central de arquiteturas híbridas.

O verdadeiro motivo do sucesso

Não é nostalgia.

Não é falta de opção.

É engenharia.

Quando uma empresa precisa processar bilhões de transações por dia com disponibilidade próxima de 100%, consistência, rastreabilidade, segurança e baixíssima latência, poucas plataformas oferecem um conjunto tão completo quanto o IBM Z.

O Programador COBOL Padawan

Existe uma grande lição aqui.

Não estude apenas aquilo que está na moda.

Estude aquilo que movimenta a economia.

Frameworks mudam.

Linguagens evoluem.

Clouds surgem.

Mas pagamentos, impostos, previdência, cartões, bolsa de valores e sistemas governamentais continuarão precisando de plataformas confiáveis.

É por isso que COBOL, CICS, Db2, IMS, MQ, z/OS e IBM Z continuam relevantes décadas depois.

O Grande Easter Egg

Há uma frase atribuída a Mark Twain que resume perfeitamente essa situação:

"Os rumores sobre minha morte foram muito exagerados."

Ela poderia ser aplicada ao Mainframe.

Há mais de vinte anos especialistas anunciam seu fim. No entanto, a cada nova geração — z13, z14, z15, z16 e agora z17 — a IBM demonstra que a plataforma continua evoluindo em desempenho, IA, segurança e integração.

Talvez o maior erro tenha sido imaginar que a evolução significaria abandonar o Mainframe. A realidade mostrou exatamente o contrário: o Mainframe evoluiu junto com a nuvem, a IA, os microsserviços e o DevOps, tornando-se um dos pilares da computação híbrida moderna.

Como costumo dizer no Bellacosa Mainframe:

O Mainframe não venceu porque resistiu às mudanças. Venceu porque mudou sem abrir mão daquilo que sempre fez melhor: processar as transações mais críticas do planeta com confiabilidade incomparável.

terça-feira, 8 de outubro de 2019

☕💥 A Jornada do Padawan COBOL – Parte 10 Desvendando o Universo dos CALLs no Mainframe

Brellacosa Mainframe apresenta call em cobol parte X

☕💥 A Jornada do Padawan COBOL – Parte 10

Desvendando o Universo dos CALLs no Mainframe

Telum II, Spyre AI Accelerator, Quantum-Safe Cryptography, OpenTelemetry, Zowe, Ansible, DevOps e a Nova Ordem dos Arquitetos IBM Z

Ou como descobrir que o Mainframe não apenas sobreviveu ao futuro, mas decidiu construí-lo

Por Vagner Bellacosa – Bellacosa Mainframe

O dia em que o Padawan descobre que o Mainframe virou plataforma de IA

Após nove capítulos, nosso Padawan acredita finalmente ter dominado os mistérios do CALL.

Ele conhece:

✅ Binder

✅ LE

✅ JES2

✅ RMF

✅ SMF

✅ Crypto Express

✅ CICS

✅ Cross Memory

Então surge uma pergunta.

O Mainframe consegue executar IA?

Resposta curta.

Sim.

Resposta longa.

Muito melhor do que muita gente imagina.

Telum II

Pouca gente percebeu.

IBM mudou o jogo.

Novamente.

Telum II é a evolução do processador Telum.

Possui:

Mais cache

Mais aceleração IA

Inferência em tempo real

Maior largura de banda

Visualmente

CALL AUTORIZA

↓

Modelo IA

↓

Avalia fraude

↓

Retorna Score

↓

Autoriza PIX

↓

Cliente feliz

Tempo total?

Milissegundos.

Spyre Accelerator

Território dos arquitetos.

É um acelerador dedicado.

Projetado para IA.

Objetivos:

LLM

Fraude

AML

Detecção anomalias

Predição

Imagine:

CALL 'ANTI-FRAUDE'

Internamente.

Pode ocorrer:

COBOL

↓

CICS

↓

Modelo IA

↓

Spyre

↓

Score

↓

DB2

↓

Resposta

Quantum Safe Cryptography

IBM pensa décadas à frente.

Hoje.

RSA.

ECC.

Amanhã.

Computadores quânticos.

IBM já trabalha com:

CRYSTALS-Kyber

CRYSTALS-Dilithium

Objetivo.

Preparar bancos.

Antes do problema existir.

OpenTelemetry

Padawan conhece.

Prometheus.

Grafana.

Jaeger.

IBM respondeu.

OpenTelemetry no zOS.

Podemos rastrear.

CALL.

SQL.

MQ.

REST.

CICS.

Visualmente

COBOL

↓

OpenTelemetry

↓

Collector

↓

Grafana

↓

Dashboard

Exemplo

Antes.

Problema misterioso.

Depois.

Dashboard.

Mostra.

Tempo.

CPU.

MQ.

DB2.

API.

Zowe

A revolução silenciosa.

Padawan antigo.

ISPF.

TSO.

Padawan moderno.

VSCode.

Git.

CLI.

REST.

Exemplo

zowe jobs list jobs

Ou.

zowe files upload

VSCode

Pode editar.

COBOL.

JCL.

Assembler.

REXX.

Com autocomplete.

Lint.

Debug.

Git no Mainframe

Veteranos estranham.

Jovens adoram.

Hoje temos.

Git.

GitLab.

GitHub.

IDz.

DBB.

DBB

Dependency Based Build

Praticamente.

Maven.

Do Mainframe.

Automatiza.

Compile.

Bind.

Linkedit.

Testes.

Deploy.

Ansible

Padawan sorri.

Sysprog também.

Exemplo.

Provisionar.

CICS.

MQ.

USS.

Playbook.

---
hosts: zos

tasks:

- start_cics

DevOps IBM Z

Pipeline moderna.

Visualmente

Git

↓

Commit

↓

Jenkins

↓

DBB

↓

Compile

↓

Unit Test

↓

Deploy

↓

Production

Galasa

Poucos conhecem.

Fantástico.

Testes automatizados.

CICS.

Batch.

MQ.

DB2.

OpenAPI

Hoje.

COBOL pode gerar.

Swagger.

Cliente.

Nem imagina.

Que existe COBOL.

Ele apenas vê.

POST

/api/pix

Observabilidade

Palavra bonita.

Muito importante.

Métricas.

Logs.

Traces.

Exemplo.

CALL CPFVAL


32 ms



SQL


8 ms



MQ


2 ms



API


15 ms

Problema resolvido.

Rapidamente.

Platform Engineering

Nova moda.

IBM já fazia.

Há décadas.

Sysplex.

WLM.

Automation.

Provisioning.

Hoje ganhou.

Nome bonito.

IA para Mainframe

Já existe.

Watsonx.

Copilot.

Assistentes.

Análise código.

Exemplo.

Perguntar.

Por que este COBOL deu S0C7?

IA responde.

Sugere correção.

Easter Egg IBM

Existe um grupo.

De profissionais.

Que conseguem.

Usar.

COBOL.

Git.

Zowe.

Ansible.

Terraform.

Kubernetes.

OpenTelemetry.

IA.

MQ.

DB2.

Assembler.

E ainda.

Conseguem.

Explicar tudo.

Em um café.

São conhecidos.

Como.

Arquitetos da Nova Ordem IBM Z

Checklist Jedi

✅ Estudar Telum II

✅ Conhecer Spyre

✅ Aprender OpenTelemetry

✅ Instalar Zowe

✅ Conhecer DBB

✅ Automatizar com Ansible

✅ Explorar Galasa

✅ Entender Quantum Safe

✅ Aprender Git

✅ Integrar APIs

✅ Testar IA

A Filosofia Jedi da Parte 10

O Padawan iniciante acredita:

Mainframe é legado.

O desenvolvedor intermediário pensa:

Mainframe é estável.

O especialista compreende:

Mainframe é uma plataforma moderna.

O Arquiteto IBM Z entende algo ainda maior:

O Mainframe nunca foi uma tecnologia presa ao passado.

Ele apenas teve a rara capacidade de continuar evoluindo sem descartar aquilo que funciona.

Enquanto muitas plataformas nasceram, cresceram e desapareceram em poucas décadas, o IBM Z continuou refinando sua arquitetura, incorporando criptografia avançada, IA embarcada, observabilidade, DevOps, APIs, automação e aceleração de inferência, mantendo a mesma promessa feita há mais de cinquenta anos:

Processar o trabalho mais importante do planeta com segurança, disponibilidade e eficiência.

Próxima aventura do Padawan COBOL – Parte 11

"As Crônicas Perdidas do IBM Z: GRS, ENQ/DEQ, RESERVE, Catalog Internals, VVDS, VTOC, UCB, IOS, Channel Subsystem, FICON, PDFs, PIDB e os mistérios que poucos Sysprogs ousam explorar."

Translate

terça-feira, 29 de setembro de 2026