Translate

sexta-feira, 10 de julho de 2026

Capítulo 10 — Por Que Tantas Previsões Erraram?

Bellacosa Mainframe e por que tantas previsões erraram ?

☕ Um Café no Bellacosa Mainframe

Capítulo 10 — Por Que Tantas Previsões Erraram?

O Maior Erro Não Foi Subestimar o Hardware. Foi Esquecer que Empresas São Feitas de Regras de Negócio.

Uma análise sobre o verdadeiro patrimônio das organizações: décadas de regras de negócio implementadas em COBOL, CICS, Db2 e z/OS, muito além do hardware que as executa.

Por


As regras de negócio representam o verdadeiro patrimônio das empresas
Hardware pode ser substituído. Décadas de conhecimento corporativo embutidas em aplicações críticas não.

"Computadores podem ser comprados. Regras de negócio precisam ser construídas ao longo de décadas."

— Bellacosa Mainframe

O erro de análise

Grande parte das previsões sobre o desaparecimento do mainframe avaliava apenas desempenho, custo do hardware e evolução dos microcomputadores, ignorando o valor acumulado nas aplicações corporativas.

Sistemas bancários, fiscais, seguradoras, companhias aéreas e governos não armazenam apenas dados: armazenam conhecimento de negócio, conformidade regulatória e processos aperfeiçoados durante décadas.

Muito além do hardware

COBOL, CICS, Db2 e z/OS representam milhões de horas de engenharia, testes, auditorias e validações que dificilmente podem ser reproduzidas em novos sistemas sem elevados custos e riscos.

O verdadeiro ativo nunca foi o equipamento físico, mas sim o patrimônio intelectual implementado em suas aplicações.

A grande lição

Empresas evoluem plataformas tecnológicas continuamente, mas preservam aquilo que realmente gera valor: suas regras de negócio, sua experiência operacional e sua capacidade de processar transações críticas com segurança e disponibilidade.

Chegamos à pergunta mais importante deste artigo

Depois de viajar por quase quarenta anos de história, conhecemos as manchetes.

Lemos a Forbes.

Visitamos o New York Times.

Ouvimos Stewart Alsop na InfoWorld.

Acompanhamos a mudança de tom da Business Week.

Vimos o extraordinário trabalho do Professor Wolfgang Spruth preservando tudo isso para que futuras gerações aprendessem com a História.

Agora surge a pergunta inevitável.

Como tanta gente inteligente conseguiu errar ao mesmo tempo?

A resposta é muito mais interessante do que simplesmente dizer:

"Eles estavam errados."

Porque eles não eram incompetentes.

Muito pelo contrário.

Eram excelentes jornalistas.

Grandes pesquisadores.

Consultores respeitados.

Executivos experientes.

O problema foi outro.

Eles analisaram apenas uma parte do sistema.

Bellacosa Mainframe e os erros que ajudaram as previsões falharem

O primeiro erro:

Confundir Tecnologia com Negócio

Imagine um banco.

Quando olhamos para ele de fora vemos:

Agências.

Aplicativos.

Cartões.

PIX.

Caixas eletrônicos.

Internet Banking.

Mas isso é apenas a superfície.

Por baixo existe um universo gigantesco de regras.

Como calcular juros?

Como compensar um cheque?

Como liquidar uma TED?

Como tratar um financiamento?

Como calcular imposto?

Como detectar fraude?

Como atualizar um saldo?

Como desfazer uma operação?

Cada uma dessas perguntas representa centenas ou milhares de linhas de código.

Décadas de conhecimento.

A maioria escrita em COBOL.

O hardware pode mudar.

A regra de negócio continua válida.

Esse foi talvez o maior erro das previsões dos anos 90.

O segundo erro:

Ignorar o custo da mudança

Existe uma pergunta que todo arquiteto experiente faz antes de iniciar qualquer modernização.

"Quanto custa mudar?"

Curiosamente...

Essa pergunta aparecia muito pouco nas reportagens.

Trocar um servidor pode ser relativamente barato.

Trocar milhões de linhas de código...

Nem tanto.

Imagine uma seguradora.

Ela possui:

  • quarenta anos de sistemas;

  • vinte milhões de clientes;

  • centenas de integrações;

  • milhares de relatórios;

  • auditorias;

  • regulamentações;

  • histórico de operações.

Agora imagine reescrever tudo.

Mesmo com IA.

Mesmo com ferramentas modernas.

Ainda assim continua sendo um dos maiores projetos de engenharia que uma empresa pode enfrentar.

O terceiro erro:

Confundir Interface com Arquitetura

Nos anos 90 surgiram interfaces gráficas maravilhosas.

Windows.

Motif.

OS/2 Presentation Manager.

Macintosh.

Tudo parecia muito mais moderno do que um terminal 3270.

E realmente era.

Visualmente.

Mas existe uma diferença enorme entre:

A interface.

E o sistema que processa a transação.

Trocar a tela é relativamente simples.

Trocar o motor do banco é outra história.

Muitos confundiram essas duas coisas.

O quarto erro:

Subestimar a confiabilidade

Existe uma pergunta que raramente aparecia nos artigos.

Quanto custa ficar parado?

Imagine:

Uma bolsa de valores indisponível durante duas horas.

Um banco fora do ar.

Uma companhia aérea sem reservas.

Uma operadora de cartões indisponível.

Um sistema de arrecadação nacional parado.

Essas situações custam milhões.

Às vezes bilhões.

Confiabilidade não aparece em propagandas.

Mas aparece imediatamente no balanço financeiro.

O quinto erro:

Ignorar a Economia da Escala

Na década de 1990 dizia-se:

"Vamos substituir um computador enorme por centenas de pequenos."

Na teoria parecia excelente.

Na prática surgiram novos custos.

Mais sistemas operacionais.

Mais administradores.

Mais backups.

Mais antivírus.

Mais monitoramento.

Mais atualizações.

Mais energia.

Mais refrigeração.

Mais licenciamento.

Mais pontos de falha.

Descobriu-se algo curioso.

Administrar mil computadores não custa o mesmo que administrar um.

O sexto erro:

O fascínio pela novidade

Existe um comportamento humano extremamente conhecido.

Chamamos de:

Viés da novidade.

Sempre acreditamos que aquilo que acabou de surgir resolverá todos os problemas existentes.

Aconteceu com:

Client/Server.

Internet.

Java.

SOA.

XML.

Cloud.

Blockchain.

Metaverso.

Agora acontece com Inteligência Artificial.

Não significa que essas tecnologias sejam ruins.

Muito pelo contrário.

Todas trouxeram contribuições importantes.

O erro está em acreditar que inovação exige apagar tudo o que veio antes.

A História mostra exatamente o contrário.

A computação evolui por camadas.

O sétimo erro:

A engenharia não segue manchetes

Um jornalista trabalha com notícias.

Um engenheiro trabalha com disponibilidade.

São profissões diferentes.

Uma reportagem dura um dia.

Um sistema bancário precisa funcionar durante décadas.

Isso muda completamente a forma de pensar.

Enquanto uma manchete procura impacto...

A engenharia procura estabilidade.

O oitavo erro:

O software passou a valer mais do que o hardware

Nos anos 1960 e 1970 o computador era o ativo mais caro.

Nos anos 1990 isso começou a mudar.

O software tornou-se muito mais valioso.

Hoje podemos comprar servidores poderosos com relativa facilidade.

Mas ninguém compra cinquenta anos de regras de negócio.

Elas precisam ser construídas.

Testadas.

Validadas.

Auditadas.

Melhoradas.

Essa riqueza invisível nunca apareceu completamente nas análises da época.

O nono erro:

Confundir Plataforma com Produto

Um computador é um produto.

IBM Z é uma plataforma.

Existe uma enorme diferença.

Uma plataforma evolui.

Recebe novas linguagens.

Novos compiladores.

Novos bancos.

Novas APIs.

Novos frameworks.

Novas interfaces.

Foi exatamente isso que aconteceu.

O IBM Mainframe de 1989 não é o IBM Z de 2026.

Assim como um smartphone moderno não é um telefone de 1990.

A plataforma permaneceu.

A tecnologia evoluiu completamente.

O décimo erro:

Achar que integração é derrota

Talvez este tenha sido o erro mais interessante.

Durante muito tempo parecia existir apenas duas opções.

Ou o Mainframe venceria.

Ou o Client/Server venceria.

A realidade mostrou outro caminho.

Integração.

Hoje convivem naturalmente:

  • COBOL

  • Java

  • Python

  • Node.js

  • Go

  • CICS

  • Db2

  • Kafka

  • REST

  • GraphQL

  • Kubernetes

  • OpenShift

  • Linux

  • watsonx

  • IBM Z

Ninguém venceu.

Todos passaram a colaborar.

O Padawan faz uma pergunta difícil

Nosso Padawan olha para o velho mestre.

Pergunta:

— Mestre...

Então os jornalistas estavam errados?

O mestre sorri.

Pensa alguns segundos.

Responde:

— Não completamente.

Eles enxergaram corretamente que a computação mudaria.

Erraram apenas uma pequena coisa.

— Qual?

— Acharam que evolução significa destruição.

Na verdade...

Engenharia quase sempre significa integração.

A maior ironia de todas

Se voltássemos para 1993 e mostrássemos um IBM z17 para aqueles analistas...

Eles provavelmente ficariam impressionados.

Veriam:

  • Linux.

  • Containers.

  • Kubernetes.

  • OpenShift.

  • APIs REST.

  • Inteligência Artificial.

  • Python.

  • Git.

  • DevOps.

  • VS Code.

  • watsonx.

  • COBOL moderno.

Talvez perguntassem:

— Onde está o mainframe?

A resposta seria divertida.

Está bem na frente de vocês.

Só que evoluiu tanto que deixou de parecer o estereótipo criado pelas manchetes de 1989.

O Professor Spruth nos deixou uma última lição

Ao preservar aquelas reportagens, Wolfgang Spruth fez muito mais do que arquivar previsões equivocadas.

Ele criou um estudo sobre comportamento humano.

As manchetes revelam algo que continua acontecendo em 2026.

Toda nova tecnologia passa pelas mesmas fases:

  1. Surge uma inovação real.

  2. O mercado se entusiasma.

  3. Aparecem previsões exageradas.

  4. Alguém decreta a morte da tecnologia anterior.

  5. Alguns anos depois...

  6. As duas tecnologias convivem.

A História da Computação parece gostar de repetir seus algoritmos.

A lição para quem está começando

Se você é um Padawan COBOL...

Guarde este capítulo.

Sempre que ouvir alguém dizer:

"Essa tecnologia morreu."

Faça cinco perguntas.

Ela ainda resolve problemas importantes?

Empresas continuam investindo nela?

Os maiores bancos ainda a utilizam?

Ela continua evoluindo?

Existe uma alternativa claramente superior em todos os aspectos?

Se alguma resposta for "não"...

Desconfie.

Talvez você esteja ouvindo apenas mais um buzzword.

A maior herança do Mainframe

Depois de quarenta anos de previsões, existe uma conclusão inevitável.

O maior legado do IBM Mainframe nunca foi o hardware.

Nem o COBOL.

Nem o CICS.

Nem o Db2.

Nem o JCL.

Nem mesmo o z/OS.

Sua maior herança foi ensinar uma filosofia de engenharia.

Disponibilidade antes da moda.

Confiabilidade antes do marketing.

Compatibilidade antes da ruptura.

Evolução antes da substituição.

É exatamente essa filosofia que permitiu ao System/360 de 1964 evoluir, geração após geração, até chegar ao IBM z17, ao watsonx, ao BOB, ao OpenShift e à Inteligência Artificial corporativa.

As manchetes tentaram prever o fim do mainframe.

A engenharia preferiu construir o futuro.

E, como costuma acontecer na computação, foi o código executando em produção — e não os títulos dos jornais — que escreveu o capítulo final dessa história.

Bellacosa Mainframe e o Funeral que nunca aconteceu


C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
▼ DIRETÓRIO DE CAPÍTULOS ▼

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , , ,

quinta-feira, 9 de julho de 2026

O Guia Definitivo para um Programador COBOL Padawan Entender por que a Nova Revolução da Inteligência Artificial Parece Muito Mais um Sistema Bancário do IBM Z do que um Chatbot

 

Bellacosa Mainframe ai agents sem misterios

☕ Um Café no Bellacosa Mainframe

AI Agents sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender por que a Nova Revolução da Inteligência Artificial Parece Muito Mais um Sistema Bancário do IBM Z do que um Chatbot

"No Mainframe aprendemos uma lição que o mercado de IA está redescobrindo apenas agora: inteligência nunca esteve em uma única aplicação. Ela sempre surgiu da integração disciplinada entre diversos componentes especializados."

Durante os últimos anos, muito se falou sobre GPT, Llama, Claude, Gemini, DeepSeek e inúmeros outros modelos de linguagem. Para quem observa de fora, parece que a evolução da Inteligência Artificial consiste simplesmente em criar modelos cada vez maiores.

Mas existe uma mudança silenciosa acontecendo.

A próxima revolução não é sobre modelos.

É sobre arquitetura.

E essa talvez seja a melhor notícia que um programador COBOL pode receber.

Enquanto boa parte da indústria acredita que a IA nasceu em 2022, profissionais de Mainframe podem olhar para praticamente qualquer diagrama moderno de AI Agents e dizer:

"Curioso... já vi algo muito parecido funcionando em bancos há décadas."

Obviamente, as tecnologias são diferentes.

Os problemas também.

Mas os princípios da engenharia permanecem surpreendentemente familiares.

A maior ilusão sobre IA

Quando alguém pensa em Inteligência Artificial normalmente imagina algo assim:

Usuário
     │
     ▼
   ChatGPT
     │
     ▼
 Resposta

Isso funciona.

Mas isso não é um agente.

É apenas uma conversa.

Um verdadeiro AI Agent parece muito mais com isto:

Objetivo

↓

Planejamento

↓

Memória

↓

Recuperação de Conhecimento

↓

Raciocínio

↓

Ferramentas

↓

Execução

↓

Avaliação

↓

Nova decisão

Perceba um detalhe extremamente importante.

O modelo de linguagem aparece apenas como um componente.

Ele deixou de ser o protagonista.

Passou a ser apenas uma peça do sistema.

Isso muda completamente a forma de pensar.

Curiosidade nº 1

Os primeiros grandes sistemas corporativos já funcionavam como "agentes", embora ninguém utilizasse esse nome.

Pense em um processamento bancário.

O cliente solicita uma transferência.

O programa COBOL não resolve tudo sozinho.

Ele:

  • consulta o Db2;

  • verifica limites;

  • conversa com CICS;

  • envia mensagens MQ;

  • registra auditoria;

  • grava logs;

  • dispara novos processos.

No final, dezenas de componentes participaram daquela simples operação.

A IA Agêntica está redescobrindo exatamente esse conceito.

O verdadeiro cérebro do agente

Existe uma frase interessante na Engenharia de Software:

"Software complexo não é construído escrevendo funções enormes.

É construído coordenando pequenas funções muito bem organizadas."

Com agentes acontece exatamente isso.

O LLM não controla tudo.

Quem controla é a arquitetura.

Imagine um maestro.

O maestro não toca violino.

Não toca piano.

Não toca trompete.

Mas coordena todos.

O Agent Runtime faz exatamente isso.

Easter Egg nº 1

Se você já escreveu um PERFORM UNTIL em COBOL, já entende melhor um AI Agent do que imagina.

Veja:

PERFORM UNTIL PROCESSO-CONCLUIDO

    LER-DADOS

    VALIDAR

    PROCESSAR

    EXECUTAR

    VERIFICAR-RESULTADO

END-PERFORM

Agora compare com um agente moderno:

Observe

↓

Think

↓

Evaluate

↓

Execute

↓

Observe novamente

São praticamente o mesmo padrão arquitetural.

A única diferença é que agora algumas decisões são tomadas por modelos estatísticos.

Memória não significa banco de dados

Outro erro muito comum.

Quando falamos em memória, muita gente pensa imediatamente em um banco de dados.

Não é isso.

Os agentes modernos possuem diversos tipos de memória.

Isso lembra bastante a organização interna de um programa COBOL.

Working Memory

Equivale às variáveis da Working-Storage.

01 WS-NOME.

01 WS-SALDO.

01 WS-CPF.

Essas informações existem apenas durante o processamento.

Quando o programa termina...

Desaparecem.

Episodic Memory

Guarda experiências anteriores.

Imagine um operador que lembra:

"Ontem essa API ficou indisponível."

Ou:

"O cliente sempre prefere receber PDF."

Essa memória melhora decisões futuras.

Procedural Memory

Talvez seja a mais interessante.

Ela não guarda conhecimento.

Guarda procedimentos.

Exatamente como um programador COBOL.

Você talvez não memorize todos os comandos do SORT.

Mas sabe quando utilizá-los.

Esse conhecimento é procedural.

Easter Egg nº 2

Uma PROCEDURE DIVISION inteira pode ser vista como uma forma primitiva de memória procedural.

Isso mostra que COBOL sempre foi muito mais sofisticado do que muitos imaginam.

O MCP explicado para quem conhece Mainframe

Muita gente acredita que MCP é uma IA.

Não é.

Também não é um banco.

Nem um framework.

MCP é um protocolo.

Pense nele como:

  • JDBC

  • ODBC

  • MQ

  • TCP/IP

  • HTTP

  • REST

Seu trabalho é padronizar comunicação.

Nada mais.

Nada menos.

Sem ele, cada ferramenta precisaria conversar de uma forma diferente.

Com ele:

LLM

↓

MCP

↓

GitHub

↓

SAP

↓

Jira

↓

Mainframe

↓

Banco

↓

Filesystem

Tudo segue uma mesma linguagem.

Curiosidade nº 2

O sucesso do TCP/IP não aconteceu porque era o protocolo mais rápido.

Aconteceu porque todo mundo resolveu falar a mesma língua.

MCP caminha exatamente nessa direção.

Ferramentas são os novos EXEC CICS

Existe uma comparação extremamente divertida.

No COBOL temos:

EXEC SQL

CALL

EXEC CICS

LINK

XCTL

MQPUT

MQGET

Na IA temos:

Tool()

API()

Database()

Search()

Filesystem()

Email()

Calendar()

O conceito é idêntico.

A lógica continua sendo apenas um orquestrador.

O ciclo infinito da inteligência

A figura mostra algo fantástico.

O agente nunca para de observar.

Ele vive em um ciclo permanente.

Observar

↓

Interpretar

↓

Planejar

↓

Executar

↓

Observar novamente

Isso lembra outro velho conhecido.

O monitor CICS.

Recebe transação

↓

Processa

↓

Envia resposta

↓

Espera próxima transação

É um ciclo eterno.

Easter Egg nº 3

O famoso laço de controle OODA (Observe, Orient, Decide, Act), criado pelo estrategista militar John Boyd, é frequentemente comparado ao ciclo de agentes modernos.

Curiosamente, muitos sistemas transacionais corporativos já implementavam ciclos semelhantes muito antes da popularização da IA.

O agente não pensa sozinho

Esta talvez seja a maior descoberta da IA moderna.

Pensar custa caro.

Consultar custa barato.

Por isso surgiu o RAG.

Ao invés de decorar tudo...

O agente consulta.

Isso lembra muito um programa COBOL.

Um sistema bancário não possui todos os clientes em memória.

Ele consulta o Db2.

Sempre que necessário.

Curiosidade nº 3

Quanto maior o agente, menos ele depende da memória interna.

Parece contraditório.

Mas faz sentido.

Grandes sistemas preferem consultar fontes oficiais do que confiar apenas na memória.

Os bancos fazem isso há décadas.

Planejamento lembra um velho conhecido...

JCL.

Antes do programa executar:

STEP001

↓

STEP002

↓

STEP003

↓

STEP004

Tudo já foi planejado.

Os agentes fazem exatamente isso.

Antes de responder.

Eles decompõem o problema.

Easter Egg nº 4

O conceito moderno chamado Task Decomposition é praticamente o equivalente filosófico ao particionamento de um grande JOB em múltiplos STEP's reutilizáveis.

O maior erro de um iniciante

Quem está começando em IA normalmente pergunta:

"Qual é o melhor modelo?"

Essa pergunta equivale a perguntar:

"Qual é o melhor compilador COBOL?"

Não é a pergunta correta.

A pergunta correta seria:

Como toda a arquitetura foi construída?

O verdadeiro diferencial

Os agentes realmente impressionantes possuem:

✔ memória

✔ ferramentas

✔ planejamento

✔ logs

✔ recuperação

✔ auditoria

✔ monitoramento

✔ controle

✔ validação

✔ observabilidade

Parece familiar?

Claro.

É exatamente assim que sistemas críticos são construídos.

Curiosidade nº 4

Os bancos nunca confiaram apenas no programa COBOL.

Sempre confiaram na arquitetura inteira.

A IA está aprendendo essa mesma lição.

O papel da avaliação

Uma diferença enorme entre um chatbot simples e um agente corporativo está na etapa de avaliação.

Depois de executar uma ação, o agente pergunta:

  • A API respondeu?

  • O banco confirmou?

  • O arquivo foi criado?

  • O usuário recebeu?

  • O resultado faz sentido?

No Mainframe fazemos isso desde sempre.

IF SQLCODE = ZERO

IF FILE-STATUS = "00"

IF RETURN-CODE = ZERO

A validação é parte da lógica.

Nunca um detalhe.

Easter Egg nº 5

Um dos padrões mais modernos em agentes é chamado Reflection.

Depois de responder...

O agente analisa sua própria resposta.

Curiosamente, isso lembra bastante um programador experiente revisando o próprio código antes do code review.

Observabilidade: a grande esquecida

Um agente sem logs é como um programa batch sem SYSOUT.

Quando algo dá errado...

Ninguém sabe por quê.

Por isso arquiteturas modernas utilizam:

  • Telemetria

  • Métricas

  • Traces

  • Logs

  • Auditoria

  • Eventos

No IBM Z temos equivalentes extremamente maduros:

  • SMF

  • RMF

  • SYSLOG

  • SDSF

  • JESMSGLG

  • JESYSMSG

Mais uma vez, o Mainframe já praticava esses conceitos há muito tempo.

A verdadeira autonomia

Existe uma frase que merece ser lembrada.

Um agente não é inteligente porque executa muitas ações.

Ele é inteligente porque sabe quando não executar.

Essa é a diferença entre automação e autonomia responsável.

É por isso que governança, políticas de acesso, autenticação, autorização e auditoria são componentes indispensáveis em ambientes corporativos.

O maior Easter Egg de todos

Talvez o aspecto mais curioso dessa nova geração de IA seja perceber que muitos dos conceitos considerados "inovadores" já existiam, com outros nomes, no universo Mainframe.

IA AgênticaIBM Z / Mainframe
Working MemoryWorking-Storage
Procedural MemoryProcedure Division
Tool CallingEXEC CICS / EXEC SQL / CALL
PlannerJCL / Scheduler
RetrievalDb2 / VSAM / IMS
ReflectionValidação de RC, SQLCODE, FILE STATUS
OrchestratorCICS, JES2, Control-M, OPC
ObservabilitySMF, RMF, SDSF, SYSLOG
Agent RuntimeMonitor transacional + lógica de negócio
GovernanceRACF, SAF, Auditoria

É claro que não são tecnologias equivalentes em implementação, mas os princípios arquiteturais apresentam paralelos notáveis.

Conselho final para um Padawan COBOL

Se você acredita que a Inteligência Artificial substituirá completamente os profissionais de Mainframe, talvez esteja olhando apenas para a superfície.

Os melhores arquitetos de agentes precisarão entender muito mais do que prompts. Eles precisarão dominar orquestração, governança, integração, confiabilidade, observabilidade, recuperação de falhas e regras de negócio — exatamente os pilares sobre os quais os grandes sistemas IBM Z foram construídos ao longo de décadas.

Enquanto muitos enxergam um AI Agent como um "chatbot com ferramentas", um programador COBOL experiente reconhece algo muito mais profundo: um ecossistema de componentes cooperando de forma disciplinada para atingir um objetivo comum.

No fim das contas, a grande lição é quase poética. A indústria da IA está descobrindo que inteligência não nasce de um modelo gigantesco, mas da engenharia cuidadosa que conecta memória, planejamento, raciocínio, execução, auditoria e controle. E para quem passou anos desenvolvendo aplicações críticas em bancos, seguradoras e governos, isso soa surpreendentemente familiar.

Como diria um velho Mestre Jedi do IBM Z:

"Os modelos impressionam nas demonstrações. Mas são as arquiteturas bem projetadas que sobrevivem por décadas."


Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , ,

Capítulo 9 — O Que Realmente Aconteceu

Bellacosa Mainframe o Mainframe como uma Phoenix renasce e obtem protagonismo

☕ Um Café no Bellacosa Mainframe

Capítulo 9 — O Que Realmente Aconteceu

Trinta Anos de Evolução Enquanto o Mercado Ainda Esperava o Funeral

Uma viagem pela evolução real do IBM Mainframe, do Parallel Sysplex e dos processadores CMOS ao Linux on Z, Java, APIs, DevOps, OpenShift, watsonx e IBM z17.

Por

Trinta anos de evolução do IBM Mainframe até o IBM z17
Enquanto o mercado esperava o funeral do mainframe, a plataforma incorporava virtualização, Linux, APIs, DevOps, cloud híbrida, OpenShift e Inteligência Artificial.

“Enquanto alguns discutiam se o mainframe sobreviveria à próxima década, os engenheiros da IBM já estavam projetando a década seguinte.”

— Bellacosa Mainframe

A evolução que aconteceu longe das manchetes

As previsões sobre o fim do mainframe concentravam-se no preço dos servidores distribuídos e no crescimento do modelo Client/Server. Enquanto isso, a IBM continuava modernizando processadores, virtualização, armazenamento, canais de entrada e saída, segurança, disponibilidade e gerenciamento de workloads.

Principais marcos tecnológicos

  • Parallel Sysplex e alta disponibilidade.
  • Processadores CMOS e redução do consumo energético.
  • Linux on IBM Z e consolidação de servidores.
  • Java, Web Services, APIs REST e integração moderna.
  • zAAP, zIIP, IFL e processadores especializados.
  • Git, Jenkins, DBB, BOB, Zowe e pipelines DevOps.
  • Ansible, OpenShift, containers e cloud híbrida.
  • watsonx, aceleração de IA e IBM z17.

A verdadeira lição

O mainframe não sobreviveu por rejeitar novas tecnologias. Ele permaneceu relevante porque incorporou Linux, Java, open source, APIs, automação, cloud híbrida, containers e Inteligência Artificial sem abandonar compatibilidade, segurança e continuidade operacional.

O funeral foi cancelado. O trabalho continuou.

Depois de acompanhar as manchetes da Forbes, do New York Times, da InfoWorld e da Business Week, um Padawan COBOL inevitavelmente faz a seguinte pergunta:

"Afinal... o que realmente aconteceu?"

A resposta curta é simples.

O mundo mudou profundamente.

Os computadores pessoais venceram.

A Internet revolucionou a sociedade.

O Linux conquistou os datacenters.

O Cloud Computing transformou a infraestrutura.

A Inteligência Artificial iniciou uma nova revolução.

Tudo isso aconteceu.

Mas existe uma segunda resposta.

Muito mais interessante.

O IBM Mainframe não ficou parado assistindo a essas mudanças.

Ele participou de todas elas.

O maior erro das previsões

As reportagens da década de 1990 tinham algo em comum.

Quase todas analisavam apenas um componente da equação.

Hardware.

Velocidade do processador.

Preço.

Memória.

Arquitetura.

Quantidade de servidores.

Pouquíssimas perguntavam:

  • Quanto custa parar um banco por uma hora?

  • Quanto custa perder uma transação financeira?

  • Quanto custa reescrever cinquenta milhões de linhas de COBOL?

  • Quanto custa validar novamente décadas de regras de negócio?

Porque, na computação corporativa, o computador representa apenas uma pequena parte do patrimônio.

O verdadeiro patrimônio sempre foi o conhecimento.

Bellacosa Mainframe e o ibm highlander

A IBM respondeu... trabalhando

Existe uma característica interessante da IBM.

Ela raramente responde a previsões por meio de campanhas publicitárias.

Ela responde lançando produtos.

Enquanto a indústria discutia o "fim do mainframe"...

A IBM continuava investindo bilhões de dólares em pesquisa e desenvolvimento.

Sem alarde.

Sem discursos dramáticos.

Apenas engenharia.

Vamos percorrer rapidamente essa jornada.

Anos 90 — Parallel Sysplex

Em vez de aceitar a limitação tradicional de um único grande computador, a IBM apresentou uma ideia revolucionária.

Parallel Sysplex.

Vários mainframes trabalhando juntos como um único sistema lógico.

Compartilhando dados.

Compartilhando carga.

Compartilhando disponibilidade.

Na prática, significava algo extraordinário.

Se um sistema apresentasse problemas...

Outro assumiria imediatamente.

Hoje chamamos isso de alta disponibilidade.

Na época...

Era engenharia de altíssimo nível.

Enquanto muitos ainda discutiam Client/Server...

A IBM discutia continuidade de negócios.

CMOS muda tudo

Outro marco foi a adoção da tecnologia CMOS.

Durante anos existia o argumento de que mainframes consumiam energia demais.

Os novos processadores CMOS reduziram consumo elétrico, dissipação térmica e custos operacionais, ao mesmo tempo em que aumentavam o desempenho.

Era uma resposta elegante.

Sem debates.

Sem marketing agressivo.

Apenas evolução tecnológica.

O Linux chega ao IBM Z

Talvez uma das maiores ironias da história.

Durante anos disseram:

"O futuro é Linux."

A IBM respondeu:

"Ótimo. Então vamos executar Linux no mainframe."

E foi exatamente isso que aconteceu.

No início dos anos 2000 nasceu o Linux on IBM Z.

Muitos especialistas ficaram surpresos.

Outros ficaram confusos.

Mas o mercado adorou a ideia.

Agora era possível consolidar centenas ou milhares de servidores Linux dentro de uma única plataforma altamente confiável.

Em vez de combater o Linux...

O IBM Z o abraçou.

Java também chegou

Outra previsão famosa dizia:

"Java acabará com o legado."

Pouco tempo depois...

Java passou a executar no próprio IBM Z.

Mais uma vez a IBM fez algo curioso.

Ela não brigou contra a novidade.

Ela a incorporou.

Essa estratégia se repetiria diversas vezes ao longo das décadas.

Virtualização muito antes da moda

Hoje qualquer profissional conhece máquinas virtuais.

VMware.

Hyper-V.

KVM.

Cloud.

Mas existe um detalhe histórico importante.

O IBM Mainframe trabalhava com virtualização muito antes de ela se tornar um assunto popular.

LPARs.

PR/SM.

z/VM.

Essas tecnologias permitiam executar múltiplos ambientes isolados com eficiência extraordinária.

Enquanto muitos acreditavam ter inventado a virtualização...

Os profissionais de IBM Z apenas sorriam discretamente.

Specialty Engines

Outro passo inteligente foi a criação dos processadores especializados.

Vieram:

  • zAAP;

  • zIIP;

  • IFL;

  • SAP;

  • ICF.

Cada um otimizado para determinados tipos de carga.

Isso permitiu reduzir custos de licenciamento, melhorar desempenho e ampliar a flexibilidade da plataforma.

Era mais uma demonstração de que o "dinossauro" continuava evoluindo.

SOA, Web Services e APIs

Depois surgiu outro buzzword.

SOA — Service-Oriented Architecture.

Muitos acreditavam que seria o fim definitivo dos sistemas tradicionais.

A IBM respondeu expondo aplicações COBOL e CICS como Web Services.

Mais tarde vieram APIs REST.

JSON.

OpenAPI.

Hoje uma aplicação escrita em React pode conversar naturalmente com um programa COBOL criado décadas atrás.

Não porque alguém reescreveu tudo.

Mas porque a arquitetura evoluiu.

Open Source no IBM Z

Outro mito dizia:

"O mundo open source nunca funcionará em mainframe."

Então chegaram:

Git.

Python.

Node.js.

Go.

Zowe.

Ansible.

VS Code.

OpenShift.

Red Hat Enterprise Linux.

Containers.

Kubernetes.

Hoje o desenvolvedor pode utilizar praticamente as mesmas ferramentas modernas tanto em ambientes distribuídos quanto no IBM Z.

A fronteira ficou cada vez menor.

O COBOL também evoluiu

Existe outro mito que merece aposentadoria.

"COBOL parou no tempo."

Não.

O COBOL de 2026 é muito diferente daquele de 1989.

Hoje encontramos recursos como:

  • UTF-8;

  • JSON PARSE e JSON GENERATE;

  • XML PARSE;

  • tipos modernos de dados;

  • desempenho otimizado;

  • integração com C e Java;

  • compiladores altamente inteligentes;

  • diagnósticos avançados;

  • otimizações automáticas.

O objetivo nunca foi transformar COBOL em outra linguagem.

Foi permitir que continuasse excelente naquilo que sempre fez.

Processamento de negócios.

Db2, CICS e z/OS também cresceram

O mesmo aconteceu com todo o ecossistema.

O Db2 ganhou novos otimizadores, compressão avançada, inteligência analítica e integração com aplicações modernas.

O CICS tornou-se uma plataforma completa para APIs REST, microsserviços e aplicações híbridas.

O z/OS recebeu automação, segurança reforçada, integração com cloud híbrida, ferramentas modernas de desenvolvimento e gerenciamento simplificado.

Nada ficou parado.

DevOps chegou ao IBM Z

Outro capítulo interessante.

Durante anos muita gente dizia:

"Mainframe não combina com DevOps."

Então apareceram:

  • Git;

  • Jenkins;

  • IBM Dependency Based Build (DBB);

  • IBM Build Open Builder (BOB);

  • UrbanCode Deploy;

  • Zowe CLI;

  • VS Code;

  • GitHub Actions;

  • Ansible.

Hoje pipelines CI/CD podem compilar COBOL, executar testes automatizados, realizar análise estática, promover artefatos e implantar aplicações no IBM Z com a mesma filosofia utilizada em outras plataformas.

O DevOps não substituiu o mainframe.

Ele passou a fazer parte dele.

Chegamos à Inteligência Artificial

E então chegamos a 2026.

Talvez a maior revolução desde a Internet.

A Inteligência Artificial.

Novamente surgiram manchetes dramáticas.

"Os programadores acabarão."

"O código será totalmente gerado por IA."

"O legado desaparecerá."

Curiosamente...

Já ouvimos esse roteiro antes.

Enquanto isso...

A IBM faz o que costuma fazer.

Integra a novidade.

O IBM z17 incorpora aceleração para Inteligência Artificial diretamente na plataforma.

O watsonx fornece um ambiente corporativo para IA generativa, governança e modelos especializados.

A IA deixa de ser apenas um chatbot.

Passa a fazer parte do processamento corporativo.

Fraudes.

Análise de risco.

Observabilidade.

Automação operacional.

Tudo integrado ao ambiente transacional.

O Padawan encontra o velho Jedi

Nosso Padawan pergunta ao Mestre:

— Mestre... afinal quem venceu?

O velho engenheiro sorri.

Aponta para um smartphone.

Depois para um cluster Kubernetes.

Depois para uma API REST.

Depois para um programa COBOL.

Depois para um IBM z17.

E responde:

— Todos.

Porque a computação nunca foi uma competição para decidir quem elimina quem.

Ela sempre foi uma longa história de integração.

O maior vencedor foi o cliente

No final das contas...

O usuário nunca perguntou:

  • O banco roda em COBOL?

  • O servidor utiliza Linux?

  • Existe um CICS por trás?

  • O Db2 está em Data Sharing?

  • A API foi escrita em Java ou Python?

O cliente pergunta apenas:

"Funciona?"

E continua funcionando.

Há décadas.

Essa talvez seja a maior vitória da engenharia.

A quinta grande lição

Ao olhar para a linha do tempo entre 1989 e 2026 percebemos algo extraordinário.

Quase todas as tecnologias que surgiram nesses anos permaneceram.

PCs.

Internet.

Linux.

Java.

Cloud.

Containers.

Kubernetes.

DevOps.

Open Source.

Inteligência Artificial.

E o IBM Mainframe.

A história da computação nunca foi sobre substituição absoluta.

Foi sobre evolução contínua.

A plataforma IBM Z sobreviveu porque nunca tentou impedir o futuro.

Ela fez algo muito mais inteligente.

Aprendeu a fazer parte dele.

E talvez essa seja a maior diferença entre uma moda tecnológica e uma plataforma de engenharia.

A moda tenta convencer você de que tudo precisa mudar imediatamente.

A engenharia pergunta:

"Como podemos evoluir sem interromper aquilo que já funciona?"

É exatamente essa pergunta que o IBM Z vem respondendo há mais de sessenta anos.

E, observando o z17, o watsonx, o BOB, o OpenShift, o Zowe e todo o ecossistema moderno da plataforma, fica difícil imaginar um desfecho mais elegante para uma tecnologia que tantos insistiram em declarar morta.

O "dinossauro" não apenas sobreviveu.

Ele aprendeu a conversar com a Inteligência Artificial.

Bellacosa Mainframe e o Funeral que nunca aconteceu


C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
▼ DIRETÓRIO DE CAPÍTULOS ▼

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , ,
Subscrever: Mensagens (Atom)