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

Translate

segunda-feira, 6 de julho de 2026

IA Generativa Muito Além do ChatGPT - Parte II

Bellacosa Mainfram apresenta ia generativa

☕ Um Café no Bellacosa Mainframe

IA Generativa Muito Além do ChatGPT

O Que Todo Programador COBOL Padawan Precisa Saber Sobre RAG, MCP, watsonx, IBM Z, CICS, Db2, APIs e Como a Inteligência Artificial Está Transformando os Sistemas Mais Críticos do Mundo (Parte 2)

"A tecnologia muda. Os princípios permanecem. Empresas não sobrevivem porque adotam modismos, mas porque conseguem evoluir preservando aquilo que já funciona."


Quando a IA Encontra o Mundo Real

Na primeira parte deste artigo vimos que a Inteligência Artificial não veio substituir o Mainframe.

Na verdade, ela depende dele.

Agora vamos responder uma pergunta ainda mais importante:

Como isso acontece dentro de uma grande instituição financeira?

Esqueça por um momento os chatbots públicos.

Imagine um banco que processa:

  • 150 milhões de transações por dia;

  • milhares de PIX por segundo;

  • milhões de cartões;

  • investimentos;

  • empréstimos;

  • seguros;

  • câmbio;

  • previdência.

Todo esse universo continua sendo coordenado por aplicações executando no IBM Z.

A IA entra como uma camada de inteligência.

Não como substituição.


Caso 1 — Atendimento Inteligente

Imagine que um cliente escreve:

"Meu cartão foi recusado. O que aconteceu?"

Sem IA:

  • abertura de chamado;

  • consulta manual;

  • operador verifica sistemas;

  • resposta alguns minutos depois.

Com IA integrada ao Mainframe:

Cliente

↓

Assistente IA

↓

RAG

↓

API REST

↓

CICS

↓

Programa COBOL

↓

Db2

↓

Regras de Negócio

↓

Resposta Personalizada

Resposta:

"Sua compra foi recusada porque ultrapassou o limite diário de segurança definido para transações internacionais. Você pode aumentar esse limite diretamente pelo aplicativo."

Nenhuma informação foi inventada.

Tudo veio do sistema corporativo.


Caso 2 — Explicando Programas COBOL

Imagine um programa com 25.000 linhas.

O desenvolvedor recém-chegado pergunta:

"Como esse programa calcula juros?"

Sem IA:

Dias analisando código.

Com IA:

Programa COBOL

↓

Parser

↓

Embedding

↓

Base Vetorial

↓

LLM

↓

Resumo Técnico

Resposta:

O cálculo de juros ocorre nos parágrafos CALC-JUROS e APLICA-TAXA. A taxa depende do tipo de contrato, perfil do cliente e índice econômico armazenado na tabela FIN_RATE.

O profissional continua responsável pela validação.

Mas economiza horas.


Caso 3 — Documentação Automática

Uma das maiores dores em sistemas legados é documentação desatualizada.

Hoje podemos construir pipelines que façam:

Git

↓

Programa COBOL

↓

Parser

↓

IA

↓

Markdown

↓

Wiki

↓

Confluence

Resultado:

Toda alteração gera documentação automaticamente.


Caso 4 — Geração de Casos de Teste

Imagine este trecho COBOL:

IF SALDO < VALOR-SAQUE
    MOVE "N" TO AUTORIZADO
ELSE
    MOVE "S" TO AUTORIZADO
END-IF

Uma IA pode sugerir automaticamente:

Caso 1

Saldo = 500

Saque = 300

Resultado esperado:

AUTORIZADO = S

Caso 2

Saldo = 300

Saque = 500

Resultado esperado:

AUTORIZADO = N

Caso 3

Saldo = 500

Saque = 500

Resultado esperado:

AUTORIZADO = S

Isso acelera significativamente testes unitários.


Agentes de IA

O próximo passo da evolução são os agentes.

Enquanto um chatbot apenas responde perguntas, um agente executa tarefas.

Imagine:

"Abra um chamado porque houve aumento de ABEND S0C7."

O agente poderá:

  • consultar o SDSF;

  • analisar logs;

  • pesquisar incidentes semelhantes;

  • abrir ticket;

  • notificar equipes;

  • sugerir solução.

Tudo automaticamente.


Arquitetura de um Agente Mainframe

                    Usuário

                       │

                       ▼

               Agente Inteligente

                       │

          ┌────────────┼────────────┐

          ▼            ▼            ▼

      MCP Tool     RAG Engine   Prompt Engine

          │            │            │

          └────────────┼────────────┘

                       ▼

             IBM API Connect

                       │

          ┌────────────┼────────────┐

          ▼            ▼            ▼

      z/OS Connect    MQ      REST APIs

          │

          ▼

      CICS

          │

          ▼

      COBOL

          │

          ▼

     Db2 / VSAM / IMS

Observe que o agente não substitui aplicações.

Ele coordena.


Observabilidade Inteligente

Ferramentas como:

  • OpenTelemetry

  • Grafana

  • Prometheus

  • Instana

  • IBM Z APM Connect

produzem milhões de métricas.

Uma IA consegue resumir tudo.

Exemplo:

Ao invés de mostrar:

CPU = 83%

I/O = 65%

Storage = 72%

Buffer Pool = 94%

Response Time = 1,8s

A IA apresenta:

Detectamos degradação iniciada às 14h23 causada por aumento nas leituras aleatórias do Db2. Existe forte correlação com o deploy realizado às 14h18.

Isso muda completamente a produtividade.


Segurança com IA

Fraudes evoluem diariamente.

A IA ajuda identificando padrões.

Exemplo:

Cliente normalmente utiliza:

São Paulo

09:00 às 20:00

Compras abaixo de R$ 500.

De repente:

Compra de US$ 8.000

Outro continente

03:17 da manhã.

O modelo identifica anomalias antes mesmo da autorização.


IA Não Pode Alucinar

Esse é um ponto crítico.

Em sistemas financeiros:

Não existe "quase certo".

Imagine responder:

Seu saldo é R$ 15.000

quando na verdade são R$ 1.500.

Por isso arquiteturas corporativas utilizam:

  • RAG

  • MCP

  • APIs oficiais

  • Catálogo de Dados

  • Governança

  • Logs

  • Auditoria

Toda resposta precisa ser rastreável.


Engenharia de Prompt para Mainframe

Prompt ruim:

Explique esse programa.

Prompt profissional:

Você é um arquiteto IBM Z.

Analise este programa COBOL.

Explique:

• regras de negócio

• dependências

• tabelas Db2

• transações CICS

• arquivos VSAM

• riscos

• complexidade

• sugestões de testes

Não invente informações.
Indique apenas aquilo identificado no código.

A qualidade muda completamente.


DevOps + IA

Imagine um pipeline.

Git

↓

Pull Request

↓

SonarQube

↓

COBOL Check

↓

IA

↓

Resumo

↓

Code Review

↓

Deploy

Antes mesmo do revisor abrir o código, a IA já produziu:

  • resumo;

  • riscos;

  • impacto;

  • módulos afetados;

  • documentação.


O Papel do Desenvolvedor

Existe medo.

"IA vai substituir programadores."

A história mostra outra coisa.

Quando surgiram:

  • compiladores;

  • IDEs;

  • Git;

  • Java;

  • frameworks;

  • Cloud;

  • DevOps.

Disseram exatamente a mesma coisa.

O profissional mudou.

Não desapareceu.


O Novo Desenvolvedor Mainframe

Nos próximos anos veremos um perfil diferente.

Além de COBOL, ele entenderá:

✓ APIs

✓ JSON

✓ Python

✓ Engenharia de Prompt

✓ RAG

✓ MCP

✓ IA Generativa

✓ DevOps

✓ Observabilidade

✓ Segurança

✓ Arquitetura

Esse profissional será extremamente valorizado.


O Que Ainda Não Será Substituído

A IA pode escrever código.

Mas ela não conhece:

  • estratégia do banco;

  • legislação;

  • decisões executivas;

  • riscos jurídicos;

  • compliance;

  • auditoria;

  • cultura organizacional.

Quem conhece isso?

As pessoas.


Um Possível Futuro

Imagine daqui a alguns anos.

Você chega ao trabalho.

Pergunta:

"Existe algum problema crítico hoje?"

Resposta:

Foram detectadas três degradações.

Corrigi automaticamente duas.

A terceira envolve alteração de regra de negócio.

Já preparei documentação.

Seguem possíveis soluções.

Isso não é ficção.

É exatamente para onde estamos caminhando.


Arquitetura Completa de IA Corporativa para IBM Z

                    ┌──────────────────────────────────────────────┐
                    │              Usuário Final                   │
                    └──────────────────┬───────────────────────────┘
                                       │
                                       ▼
                        Web │ Mobile │ Chatbot │ Teams │ Slack
                                       │
                                       ▼
                  ┌────────────────────────────────────────┐
                  │        Gateway de APIs / WAF           │
                  └────────────────┬───────────────────────┘
                                   │
                    ┌──────────────┼──────────────┐
                    ▼              ▼              ▼
               Autenticação     Auditoria     Rate Limit
                                   │
                                   ▼
                      ┌────────────────────────────┐
                      │      Modelo Generativo     │
                      │        (watsonx.ai)        │
                      └────────────┬───────────────┘
                                   │
                  ┌────────────────┼────────────────┐
                  ▼                ▼                ▼
              Prompt           RAG Engine       MCP Server
             Orchestrator        Vetores        Ferramentas
                  │                │                │
                  └────────────────┼────────────────┘
                                   ▼
                    ┌──────────────────────────────────┐
                    │ APIs Corporativas / z/OS Connect │
                    └────────────────┬─────────────────┘
                                     │
              ┌──────────────────────┼──────────────────────┐
              ▼                      ▼                      ▼
           CICS                 IBM MQ                Batch
              │                      │                      │
              └──────────────┬───────┴──────────────────────┘
                             ▼
                     Aplicações COBOL
                             │
        ┌────────────────────┼────────────────────┐
        ▼                    ▼                    ▼
      Db2                  VSAM                 IMS
                             │
                             ▼
                    Fonte Oficial da Verdade

Considerações Finais

Durante décadas, ouvimos previsões sobre o fim do Mainframe. Entretanto, a realidade mostrou algo diferente: os sistemas que sustentam bancos, seguradoras, governos e grandes empresas continuam evoluindo porque concentram o ativo mais valioso de qualquer organização — seus dados e suas regras de negócio.

A Inteligência Artificial Generativa amplia esse cenário ao adicionar novas capacidades de interpretação, automação e interação. Tecnologias como RAG, MCP, watsonx, APIs, z/OS Connect e modelos privados permitem que aplicações modernas dialoguem com décadas de conhecimento implementado em COBOL, CICS e Db2, sem abrir mão de segurança, governança ou desempenho.

Não estamos testemunhando a substituição do Mainframe, mas o surgimento de uma nova geração de arquiteturas corporativas em que IA e IBM Z trabalham lado a lado. Para os profissionais da área, isso representa uma oportunidade única: dominar tanto os fundamentos dos sistemas críticos quanto as novas ferramentas de Inteligência Artificial.

O futuro pertence aos profissionais capazes de conectar esses dois mundos. Afinal, a inovação mais duradoura não nasce da ruptura, mas da integração inteligente entre o legado que funciona e as tecnologias que apontam para o amanhã.


☕ Continua a conversa no Bellacosa Mainframe

https://eljefemidnightlunch.blogspot.com/2026/07/ia-generativa-muito-alem-do-chatgpt.html




domingo, 5 de julho de 2026

Capítulo 5 — The New York Times (1989)

Bellacosa Mainframe deu no the new york times

☕ Um Café no Bellacosa Mainframe

Capítulo 5 — The New York Times (1989)

Quando o "Dinossauro" Virou Manchete Mundial

Uma análise histórica da reportagem do The New York Times que ajudou a popularizar mundialmente a ideia da morte do mainframe e como essa previsão se mostrou equivocada diante da evolução do IBM Z.

Por

A reportagem do The New York Times de 1989 sobre o futuro do Mainframe
A cobertura do The New York Times ampliou mundialmente o debate sobre o suposto fim do mainframe e marcou a história da computação corporativa.


☕ Um Café no Bellacosa Mainframe

Capítulo 5 — The New York Times (1989)

Quando o "Dinossauro" Virou Manchete Mundial

"Uma previsão publicada em uma revista influencia especialistas. A mesma previsão publicada na primeira página de um grande jornal influencia o mundo inteiro."
— Bellacosa Mainframe


4 de abril de 1989

A história da computação mudou naquele dia.

Não porque surgiu uma nova tecnologia.

Não porque a IBM lançou um novo processador.

Nem porque apareceu um sistema operacional revolucionário.

Mudou porque um dos jornais mais respeitados do planeta resolveu contar uma história.

Essa história dizia, em essência, que o reinado dos grandes computadores estava chegando ao fim.

O veículo era o The New York Times.

Quando um jornal desse porte fala sobre política, economia ou tecnologia, milhões de pessoas prestam atenção.

E quando ele chama uma tecnologia de "dinossauro", essa imagem deixa de ser apenas uma metáfora técnica e passa a fazer parte do imaginário coletivo.

A reportagem descrevia os mainframes como uma tecnologia gigantesca, cara e cada vez mais ameaçada pela rápida evolução dos computadores pessoais, das workstations e das redes locais. A narrativa refletia o entusiasmo crescente em torno da computação distribuída, vista como o caminho natural para substituir os grandes sistemas centrais.


Bellacosa Mainframe afinal o mainframe nao morreu

A diferença entre uma revista e um jornal

Existe um detalhe importante que muitos esquecem.

A Forbes era lida principalmente por executivos e investidores.

A InfoWorld era voltada para profissionais de tecnologia.

Mas o New York Times era diferente.

Ele conversava com toda a sociedade.

Empresários.

Políticos.

Economistas.

Professores.

Estudantes.

Diretores financeiros.

Acionistas.

Ou seja...

Quando o New York Times dizia que uma tecnologia estava envelhecendo...

Essa ideia ultrapassava os limites do departamento de TI.

Ela chegava às salas de reunião.


O nascimento de uma narrativa

Pouco a pouco começou a surgir uma história aparentemente perfeita.

Os computadores pessoais estavam ficando mais rápidos.

As workstations da Sun eram impressionantes.

As redes Ethernet cresciam.

O UNIX ganhava espaço.

As empresas queriam reduzir custos.

Logo...

Os grandes computadores desapareceriam.

Perceba uma coisa interessante.

Cada uma dessas afirmações era verdadeira.

O erro estava apenas na última conclusão.

Na engenharia, uma sequência de fatos verdadeiros pode produzir uma conclusão completamente errada.


A computação estava realmente mudando

É importante sermos honestos.

Os jornalistas não inventaram aquela transformação.

Ela existia.

Os departamentos começaram a comprar servidores próprios.

Os usuários deixaram de depender exclusivamente do CPD.

Aplicações passaram a ser distribuídas.

Novos fabricantes surgiam todos os anos.

As empresas finalmente podiam comprar servidores relativamente baratos.

Tudo isso aconteceu.

O problema foi acreditar que descentralizar parte do processamento significava eliminar completamente o processamento central.

Hoje sabemos que uma coisa não implica necessariamente a outra.


O CPD parecia um castelo medieval

Existe também um aspecto cultural.

Para um jovem engenheiro de 1989, entrar em um Centro de Processamento de Dados era quase uma experiência cinematográfica.

Portas pesadas.

Controle de acesso.

Piso elevado.

Ar-condicionado constante.

Operadores.

Grandes unidades de disco.

Robôs de fitas.

Luzes piscando.

Consoles.

Tudo parecia gigantesco.

Enquanto isso...

No escritório ao lado...

Um PC colorido executava planilhas em poucos segundos.

Era impossível não pensar:

"O futuro está aqui."

O curioso é que ambos estavam certos.

O PC representava o futuro da computação pessoal.

O mainframe continuava representando o futuro da computação transacional.

Esses futuros apenas eram diferentes.


O erro da fotografia

Imagine que alguém fotografe uma cidade.

Na imagem aparecem centenas de carros elétricos.

A partir dessa foto ele conclui:

"Os caminhões desapareceram."

Parece absurdo.

Mas foi exatamente esse tipo de raciocínio que contaminou muitas análises da época.

Os jornalistas observavam o crescimento dos PCs.

O crescimento era real.

Depois concluíam que os mainframes desapareceriam.

Só que estavam fotografando apenas uma parte da cidade.

Os caminhões continuavam trabalhando.

Longe dos holofotes.


O que o jornalista não via

Enquanto a reportagem era escrita...

Dentro das empresas acontecia outra realidade.

Os caixas eletrônicos continuavam conectados ao mainframe.

As reservas de companhias aéreas continuavam centralizadas.

As seguradoras processavam milhões de contratos.

Governos arrecadavam impostos.

Bolsas de valores liquidavam operações.

Hospitais processavam contas médicas.

Grandes varejistas atualizavam estoques nacionais.

Nada disso aparecia na mesa do usuário final.

Era infraestrutura.

E infraestrutura raramente ganha manchetes.

Ninguém escreve um artigo chamado:

"Hoje milhões de transações funcionaram normalmente."

Mas basta uma falhar...

Ela vira notícia mundial.


O invisível nunca parece moderno

Existe uma curiosidade interessante.

Quanto mais importante uma tecnologia se torna...

Mais invisível ela fica.

Ninguém pensa na rede elétrica ao acender a luz.

Ninguém pensa no sistema de abastecimento ao abrir a torneira.

Da mesma forma...

Pouquíssimos clientes de um banco pensam no IBM Z quando fazem um pagamento.

Isso faz parte do sucesso da plataforma.

Ela funciona tão bem que desaparece da percepção das pessoas.

Talvez esse tenha sido um dos maiores problemas do mainframe.

Ele sempre trabalhou nos bastidores.

Enquanto os computadores pessoais ficavam sobre a mesa.


O Padawan visita uma redação em 1989

Vamos imaginar nosso Padawan COBOL entrando na redação do New York Times.

Um jornalista pergunta:

— Você trabalha com computadores?

Ele responde:

— Sim.

— Então você deve estar preocupado. Dizem que o mainframe vai desaparecer.

Nosso Padawan sorri.

Pergunta educadamente:

— Quantas transações bancárias seu jornal processa por dia?

Silêncio.

— Quantos cartões de crédito vocês autorizam?

Silêncio.

— Quantas folhas de pagamento nacionais vocês executam?

Mais silêncio.

Então ele conclui:

— Talvez vocês estejam olhando para o computador errado.


O verdadeiro patrimônio nunca foi o hardware

Existe uma palavra que quase nunca aparecia nas manchetes.

Conhecimento.

Quando falamos em um sistema COBOL de um grande banco...

Não estamos falando apenas de milhões de linhas de código.

Estamos falando de décadas de regras de negócio.

Leis.

Normas.

Tributação.

Auditoria.

Processos internos.

Integrações.

Experiência acumulada.

Trocar um servidor é relativamente simples.

Reescrever quarenta anos de conhecimento empresarial é um dos projetos mais caros que uma organização pode enfrentar.

Essa dimensão raramente aparecia nas reportagens.


A diferença entre moda e missão crítica

Em 1989, muitas aplicações realmente migraram para plataformas distribuídas.

Correio eletrônico.

Ferramentas de escritório.

Planilhas.

Documentos.

Aplicações departamentais.

Isso fazia todo sentido.

Mas sistemas de missão crítica obedecem outras regras.

Eles precisam funcionar:

  • 24 horas por dia;

  • sete dias por semana;

  • com alta disponibilidade;

  • segurança;

  • auditoria;

  • recuperação;

  • consistência transacional.

Esses requisitos nunca deixaram de existir.

E continuam sendo exatamente os motivos pelos quais plataformas IBM Z permanecem estratégicas em 2026.


O tempo respondeu silenciosamente

O New York Times publicou sua reportagem.

A indústria continuou discutindo.

Os analistas continuaram prevendo.

Os consultores continuaram vendendo projetos.

Enquanto isso...

O mainframe fez algo extremamente ousado.

Continuou trabalhando.

Não respondeu aos jornalistas.

Não publicou cartas abertas.

Não iniciou campanhas publicitárias.

Apenas continuou processando bilhões de dólares todos os dias.

Existe uma elegância quase japonesa nisso.

Quando um samurai domina completamente sua arte...

Ele não precisa discutir.

A excelência fala por ele.


A segunda grande lição

A reportagem do New York Times é um documento histórico precioso.

Ela não representa apenas uma previsão sobre computadores.

Ela representa uma característica humana.

Nossa enorme dificuldade em distinguir:

  • crescimento de substituição;

  • inovação de destruição;

  • evolução de obsolescência.

A computação realmente mudou.

Mudou profundamente.

Mas a História mostrou que ela não caminhou eliminando tudo o que existia.

Ela caminhou integrando tecnologias.

Em 2026 convivem naturalmente:

  • IBM Z;

  • Linux;

  • Kubernetes;

  • OpenShift;

  • COBOL;

  • Java;

  • Python;

  • APIs REST;

  • Db2;

  • PostgreSQL;

  • CICS;

  • Kafka;

  • watsonx;

  • Inteligência Artificial.

O mundo corporativo descobriu algo que as manchetes de 1989 ainda não conseguiam enxergar.

A inovação mais poderosa não é aquela que destrói o passado.

É aquela que consegue conversar com ele.


Fonte histórica

The New York Times, 4 de abril de 1989, citado pelo Professor Wolfgang Spruth em The Death of the Mainframe. A reportagem ajudou a popularizar mundialmente a imagem do mainframe como um "dinossauro tecnológico", refletindo o entusiasmo da época com PCs, workstations e arquiteturas cliente-servidor. Décadas depois, tornou-se um importante registro histórico sobre como a indústria enxergava o futuro da computação no final dos anos 1980.

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.

Kubernetes Autoscaling Muito Além do HPA

 

Bellacosa Mainframe e o kubernetes autoscaling

☕ Um Café no Bellacosa Mainframe

Kubernetes Autoscaling Muito Além do HPA

O Que Todo Programador COBOL Padawan Precisa Saber Sobre HPA, VPA, Cluster Autoscaler e Como os Grandes Bancos Escalam Milhões de Transações Sem Desperdiçar Recursos

"No Mainframe aprendemos que desempenho nunca foi apenas velocidade. Sempre foi equilíbrio entre capacidade, disponibilidade, custo e confiabilidade. Kubernetes apenas reinventou esse conceito para a era da nuvem."


Introdução

Existe uma pergunta que praticamente todo desenvolvedor faz quando começa a estudar Kubernetes:

"Se meu sistema receber mais acessos, o Kubernetes cria novos Pods automaticamente?"

A resposta é:

Depende.

E é justamente esse "depende" que confunde milhares de profissionais todos os anos.

Quando um Programador COBOL começa a estudar Kubernetes, normalmente imagina que existe apenas um mecanismo responsável por aumentar a capacidade da aplicação.

Na prática, isso está longe da realidade.

Na verdade, Kubernetes possui diversos mecanismos diferentes de escalabilidade, cada um resolvendo um problema específico.

Alguns aumentam a quantidade de Pods.

Outros aumentam CPU e memória.

Outros adicionam novos servidores inteiros ao cluster.

Cada um trabalha em uma camada diferente da infraestrutura.

É exatamente como acontece em um grande banco.

Quando o Internet Banking começa a ficar lento, ninguém simplesmente compra um novo servidor.

Antes disso existem diversas decisões:

  • aumentar regiões CICS?

  • criar novos servidores WebSphere?

  • ajustar WLM?

  • aumentar memória?

  • ativar Capacity on Demand?

  • adicionar uma nova LPAR?

No Kubernetes acontece exatamente a mesma filosofia.

Neste artigo vamos entender profundamente como funcionam:

  • Horizontal Pod Autoscaler (HPA)

  • Vertical Pod Autoscaler (VPA)

  • Cluster Autoscaler (CA)

Sempre fazendo paralelos com IBM Z, COBOL, CICS, Batch, WLM e arquitetura corporativa.


Antes de falar sobre Autoscaling...

Precisamos entender um conceito fundamental.

O verdadeiro objetivo não é aumentar recursos.

É utilizar exatamente os recursos necessários.

Essa diferença parece pequena.

Mas muda completamente a forma de projetar sistemas.

Imagine um supermercado.

Às 3 horas da manhã existem apenas cinco clientes.

Às 18 horas existem dois mil clientes.

Você contrataria:

  • 200 caixas funcionando o dia inteiro?

Claro que não.

Também não deixaria apenas dois caixas funcionando às 18 horas.

A solução inteligente é adaptar a quantidade de caixas conforme o movimento.

É exatamente isso que Kubernetes faz.


O grande problema dos sistemas tradicionais

Durante décadas o modelo foi simples.

Comprar servidores suficientes para suportar o pior cenário.

Imagine uma aplicação bancária.

Segunda-feira:

CPU: 12%

Terça-feira:

CPU: 18%

Quarta-feira:

CPU: 22%

Na Black Friday:

CPU: 98%

O servidor foi comprado pensando apenas nesse último dia.

Resultado:

Durante praticamente todo o ano:

  • CPU parada

  • memória parada

  • discos subutilizados

  • energia desperdiçada

  • dinheiro desperdiçado

Cloud Computing mudou completamente essa lógica.

Agora infraestrutura pode crescer e diminuir automaticamente.


Elasticidade x Escalabilidade

Esses conceitos costumam ser confundidos.

Escalabilidade

É a capacidade do sistema suportar mais carga.

Exemplo:

Um servidor suporta:

500 usuários

Depois de melhorias:

5.000 usuários

Ele ficou mais escalável.


Elasticidade

É a capacidade de crescer e diminuir automaticamente.

Hoje:

2 Pods

Daqui cinco minutos:

20 Pods

Mais tarde:

4 Pods

Tudo sem intervenção humana.

Isso é elasticidade.

É justamente o coração do Kubernetes.


Os três tipos de escalabilidade

A maioria das pessoas acredita que existe apenas um tipo.

Na realidade existem três.

Escalabilidade Horizontal

Adicionar mais instâncias.

Exemplo:

Antes

2 Pods

Depois

8 Pods

Cada Pod continua igual.

Apenas existem mais deles.


Escalabilidade Vertical

Não aumenta quantidade.

Aumenta potência.

Antes

CPU 500m

Memória 512Mi

Depois

CPU 2

Memória 4Gi

Mesmo Pod.

Mais poderoso.


Escalabilidade da Infraestrutura

Agora nem estamos falando da aplicação.

Estamos falando do próprio cluster.

Antes

3 Workers

Depois

10 Workers

Agora existe espaço para muito mais Pods.


HPA — Horizontal Pod Autoscaler

Este é o autoscaler mais famoso.

Seu trabalho é extremamente simples.

Responder uma única pergunta.

Existem Pods suficientes?

Observe o que ele NÃO pergunta.

  • Existe CPU suficiente?

  • Existe memória suficiente?

  • Existem servidores suficientes?

Nada disso.

Ele pensa apenas em quantidade de Pods.


Como o HPA funciona?

Imagine uma API.

Ela começou o dia assim.

2 Pods

CPU média:

20%

Tudo funcionando.

Então começa uma campanha de marketing.

A CPU sobe para:

92%

O HPA verifica que sua meta era:

70%

Então ele faz um cálculo.

Simplificando:

Novos Pods =
Pods atuais ×
(CPU Atual / CPU Desejada)

Se havia:

4 Pods

CPU:

84%

Meta:

70%

Resultado:

4 × 84 ÷ 70

≈ 4,8

O Kubernetes arredonda.

Agora teremos:

5 Pods

Se a carga continuar aumentando:

6

8

12

20 Pods

Tudo automático.


Mas o HPA não olha apenas CPU

Esse é um erro muito comum.

Na realidade ele pode observar praticamente qualquer métrica.

Exemplos.

CPU

Memória

Requests por segundo

Tempo médio de resposta

Fila Kafka

RabbitMQ

Prometheus

Número de usuários

Sessões abertas

Mensagens pendentes

Quantidade de pedidos

Pix aguardando processamento

Fila de cartões

Custom Metrics

Isso significa que o HPA pode crescer baseado na necessidade real do negócio.

Imagine um banco.

Talvez CPU nem seja importante.

O importante pode ser:

Fila PIX > 2000

Nesse momento:

Criar novos Pods.

Muito mais inteligente.


Como o HPA conversa com Kubernetes?

O fluxo é relativamente simples.

Usuário

Ingress

Service

Pods

Kubelet mede CPU

Metrics Server coleta

API Server publica

HPA consulta

ReplicaSet aumenta Pods

Deployment cria novas réplicas

Tudo acontece continuamente.

Sem intervenção humana.


HPA não fica escalando o tempo todo

Imagine esta situação.

CPU:

69%

71%

69%

70%

71%

69%

Sem mecanismos de estabilização.

Teríamos:

8 Pods

9 Pods

8 Pods

9 Pods

8 Pods

Isso seria um desastre.

Por isso existem diversos mecanismos internos.

Cooldown.

Stabilization Window.

Tolerance.

Scale Policies.

Esses mecanismos evitam oscilações desnecessárias.


HPA possui limitações

Ele não faz milagres.

Imagine.

Seu cluster possui apenas:

2 Workers

Cada Worker possui:

8 CPUs

Todos estão completamente ocupados.

O HPA decide criar:

30 Pods

Mas onde eles serão executados?

Resposta.

Em lugar nenhum.

Eles ficam:

Pending

É aqui que entra outro personagem.


VPA — Vertical Pod Autoscaler

Agora o problema mudou completamente.

Não queremos mais criar novos Pods.

Queremos melhorar os Pods existentes.

Imagine.

Seu Deployment foi criado assim.

requests:
 cpu: 100m
 memory: 128Mi

Na prática ele utiliza:

CPU

850m

Memória

950Mi

Resultado.

CPU Throttling.

OOMKilled.

Baixo desempenho.

O VPA observa isso.


Como o VPA aprende?

Ao contrário do HPA.

Ele analisa histórico.

Dias.

Semanas.

Meses.

Depois calcula recomendações.

Exemplo.

Atual.

CPU

100m

Recomendado.

900m

Atual.

256Mi

Recomendado.

1Gi

Isso reduz desperdício.

E melhora desempenho.


Os modos do VPA

Off

Apenas recomenda.

Muito usado em produção.

Você recebe um relatório.

Mas nenhuma alteração acontece.


Auto

Atualiza automaticamente.

Se necessário reinicia Pods.

É extremamente poderoso.


Initial

Aplica apenas durante a criação.

Excelente para aplicações críticas.


Por que o VPA reinicia Pods?

Muitos iniciantes estranham isso.

O motivo é simples.

CPU e memória fazem parte da especificação do Pod.

Depois que o container está em execução.

Esses parâmetros normalmente não podem ser alterados.

Então o Kubernetes cria um novo Pod.

Com os novos valores.


O que o VPA não faz?

Não cria novos Pods.

Não cria servidores.

Não aumenta Workers.

Não substitui HPA.

São ferramentas complementares.


Cluster Autoscaler

Agora chegamos à infraestrutura.

Imagine.

Seu HPA criou:

50 Pods

Mas existem apenas:

3 Workers

Todos lotados.

Resultado.

Pods Pending

O Scheduler tenta.

Não consegue.

Agora entra o Cluster Autoscaler.


O trabalho do Cluster Autoscaler

Ele pergunta.

Existe algum Pod que não consegue ser agendado?

Se existir.

Ele conversa com o provedor de nuvem.

AWS.

Azure.

Google.

OpenShift.

VMware.

E solicita novos Workers.

Depois que os novos servidores entram no cluster.

O Scheduler distribui os Pods.


Fluxo completo

Usuários aumentam.

CPU aumenta.

HPA cria Pods.

Pods ficam Pending.

Cluster Autoscaler detecta.

Cloud cria Workers.

Workers entram.

Scheduler agenda Pods.

Aplicação volta ao normal.

Tudo automático.


Como o Cluster Autoscaler decide remover servidores?

Ele também reduz custos.

Imagine.

Domingo.

Pouquíssimos acessos.

Existem:

15 Workers

Mas apenas:

3

são necessários.

O Cluster Autoscaler verifica.

Os Pods podem ser movidos?

Se sim.

Executa.

Drain.

Eviction.

Delete Node.

Resultado.

Economia de infraestrutura.


Comparando HPA, VPA e Cluster Autoscaler

Imagine um supermercado.

HPA

Contrata mais caixas.

Mais pessoas atendendo clientes.


VPA

Entrega computadores mais rápidos para cada caixa.

Cada funcionário trabalha melhor.


Cluster Autoscaler

Constrói uma nova loja.

Agora existe espaço para muito mais caixas.

São três problemas diferentes.


Um exemplo real de um grande banco

Imagine um aplicativo bancário.

Às 8h da manhã.

Começam os acessos.

Primeiro.

O HPA aumenta.

6 Pods

↓

20 Pods

Depois percebe-se que cada Pod está consumindo muito mais memória.

O VPA recomenda.

512Mi

↓

2Gi

Agora não existe mais capacidade física.

O Cluster Autoscaler adiciona.

8 Workers

↓

16 Workers

O usuário final nem percebe.

Essa é a magia da elasticidade.


Analogia com IBM Mainframe

Quem trabalha com IBM Z perceberá rapidamente várias semelhanças.

HPA

Lembra aumentar regiões CICS.

Ou criar mais servidores Liberty.

Mais instâncias.

Mesmo programa COBOL.


VPA

Lembra ajustar REGION.

Heap Java.

Parâmetros WLM.

Mais recursos para uma região existente.


Cluster Autoscaler

Lembra.

Adicionar novas LPARs.

Capacity on Demand.

Expandir Parallel Sysplex.

Mais infraestrutura.

A filosofia é praticamente idêntica.


Quando utilizar cada um?

Use HPA.

Quando existem picos de acesso.

APIs REST.

Microsserviços.

Front-end.

Aplicações stateless.


Use VPA.

Quando deseja otimizar CPU e memória.

Eliminar desperdício.

Evitar OOMKilled.

Melhorar desempenho.


Use Cluster Autoscaler.

Quando a infraestrutura precisa crescer automaticamente.

Principalmente em Cloud.

AWS.

Azure.

Google Cloud.

OpenShift.


O futuro: KEDA e Event-Driven Autoscaling

Os mecanismos que estudamos são apenas a base. Em arquiteturas modernas, surge um quarto componente importante: o KEDA (Kubernetes Event-Driven Autoscaling).

Enquanto o HPA reage principalmente a métricas como CPU e memória, o KEDA reage a eventos.

Imagine um sistema de processamento de boletos. Não importa a CPU; o importante é saber quantos boletos aguardam processamento em uma fila do IBM MQ ou do Kafka.

Se houver 10 mensagens, um Pod é suficiente.

Se houver 10.000 mensagens, o KEDA pode solicitar ao HPA dezenas de Pods para processar a fila rapidamente.

Esse modelo aproxima o Kubernetes dos conceitos de processamento orientado a filas, muito conhecidos por profissionais de Mainframe que trabalham com IBM MQ, CICS Trigger Transactions e Batch.


Conclusão

Quando começamos a estudar Kubernetes, é comum acreditar que autoscaling significa apenas "criar mais Pods". Porém, vimos que a realidade é muito mais rica. O ecossistema foi projetado para atacar diferentes gargalos de forma especializada:

  • HPA responde ao aumento da carga criando ou removendo Pods.

  • VPA ajusta CPU e memória para que cada Pod tenha os recursos ideais.

  • Cluster Autoscaler adiciona ou remove nós do cluster conforme a capacidade física necessária.

  • KEDA amplia essa inteligência ao escalar aplicações com base em eventos e filas.

Para um Programador COBOL Padawan, essa arquitetura não deve ser vista como algo completamente novo. Ela representa a evolução de princípios que sempre existiram no mundo corporativo: distribuir carga, otimizar recursos, garantir disponibilidade e controlar custos.

No IBM Z, esses objetivos eram alcançados com WLM, Parallel Sysplex, Capacity on Demand, regiões CICS, tuning de DB2 e planejamento de capacidade. No Kubernetes, os mesmos princípios são implementados de forma declarativa, automática e integrada à nuvem.

A tecnologia mudou. As ferramentas evoluíram. Mas a missão continua exatamente a mesma: entregar sistemas resilientes, escaláveis e eficientes, capazes de atender milhões de usuários sem desperdiçar recursos. É essa mentalidade de engenharia que transforma um desenvolvedor em um verdadeiro arquiteto de soluções modernas.


IA Generativa Muito Além do ChatGPT

 

Bellacosa Mainframe e a ia generativa muito alem do chatgpt

☕ Um Café no Bellacosa Mainframe

IA Generativa Muito Além do ChatGPT

O Que Todo Programador COBOL Padawan Precisa Saber Sobre RAG, MCP, watsonx, IBM Z, CICS, Db2, APIs e Como a Inteligência Artificial Está Transformando os Sistemas Mais Críticos do Mundo (Parte 1)

"A Inteligência Artificial não substituirá o Mainframe. Ela tornará o Mainframe ainda mais indispensável."


Introdução

Se você acompanha as notícias sobre tecnologia, provavelmente já ouviu centenas de vezes que a Inteligência Artificial mudará tudo.

Empresas anunciam novos modelos quase diariamente. LLMs (Large Language Models), Agentes Inteligentes, Copilots, IA Generativa, RAG, MCP, Engenharia de Prompt... os nomes surgem em um ritmo tão acelerado que muitos profissionais começam a acreditar que tudo o que aprenderam nos últimos anos ficou obsoleto.

Mas existe uma pergunta que raramente aparece nas manchetes:

Onde estão os dados que realmente importam?

A resposta continua sendo a mesma há décadas.

Nos grandes bancos.

Nas seguradoras.

Nas bolsas de valores.

Nas empresas aéreas.

Nos governos.

Nas operadoras de cartão.

E, principalmente, dentro do IBM Z.

É justamente por isso que a próxima revolução da IA não será construída apenas na nuvem. Ela acontecerá onde os dados mais valiosos já vivem.

Bem-vindo ao futuro do Mainframe.


A Grande Mudança de Paradigma

Durante muito tempo acreditou-se que toda inovação exigia substituir sistemas antigos.

Era comum ouvir frases como:

"Vamos migrar tudo para a nuvem."

"COBOL morreu."

"Mainframe é legado."

Entretanto, o mercado mostrou uma realidade completamente diferente.

Os sistemas considerados "legados" continuam processando bilhões de transações diariamente.

Enquanto isso, empresas descobriram algo importante:

Mover petabytes de dados custa muito dinheiro.

Mais do que isso.

Pode aumentar riscos de segurança, criar problemas regulatórios e reduzir a performance.

Assim nasceu uma nova filosofia.

Não levar os dados para a IA.

Levar a IA até os dados.


O Mainframe Nunca Foi Apenas um Computador

Quando pensamos em IBM Z, muita gente imagina apenas enormes racks pretos.

Na prática, ele é muito mais do que isso.

Ele representa décadas de conhecimento empresarial.

Imagine um banco.

O saldo da sua conta não existe "na internet".

Existe dentro de regras cuidadosamente escritas ao longo de décadas.

Essas regras determinam:

  • como calcular juros;

  • como validar empréstimos;

  • como impedir fraudes;

  • como processar PIX;

  • como liquidar operações financeiras;

  • como calcular tarifas;

  • como registrar auditorias.

Grande parte desse conhecimento está codificado em programas COBOL, PL/I, CICS e Db2.

Isso significa que a IA não pode simplesmente "inventar" respostas.

Ela precisa consultar essas regras.


IA Generativa Não É um Banco de Dados

Esse é um dos maiores equívocos atuais.

Um LLM não "sabe" quanto dinheiro existe em sua conta.

Ele também não sabe:

  • limite do cartão;

  • última transação;

  • saldo do FGTS;

  • número da apólice;

  • posição dos investimentos.

Essas informações vivem em sistemas transacionais.

O papel da IA é diferente.

Ela interpreta.

Resume.

Explica.

Conversa.

Traduz.

Mas quem fornece a verdade continua sendo o sistema corporativo.

É exatamente por isso que IBM Z e IA trabalham tão bem juntos.


O Papel do RAG

Uma das tecnologias mais importantes da IA moderna chama-se Retrieval-Augmented Generation (RAG).

Em vez de confiar apenas no conhecimento aprendido durante o treinamento do modelo, o RAG consulta informações atualizadas antes de responder.

Imagine este fluxo.

Usuário
    │
    ▼
Pergunta
    │
    ▼
Modelo de IA
    │
    ▼
Consulta Base Corporativa
    │
    ▼
Db2
VSAM
Documentos
COBOL
CICS
APIs
    │
    ▼
Contexto Recuperado
    │
    ▼
Resposta Inteligente

Agora imagine um cliente perguntando:

"Por que meu financiamento foi recusado?"

Sem RAG, o modelo poderia apenas explicar genericamente como funcionam financiamentos.

Com RAG:

  • consulta o cadastro;

  • verifica políticas;

  • identifica pendências;

  • acessa documentação;

  • monta uma resposta personalizada.

A diferença é enorme.


O Que é MCP?

Nos últimos meses surgiu um termo que promete mudar completamente a forma como agentes inteligentes trabalham.

MCP.

Model Context Protocol.

Pense nele como um padrão para conectar modelos de IA a ferramentas externas.

Sem MCP:

IA

↓

Resposta baseada apenas
no treinamento

Com MCP:

IA

↓

Ferramentas

↓

Banco de Dados

↓

Mainframe

↓

APIs

↓

Documentos

↓

Resposta muito mais precisa

Isso permite que um agente converse naturalmente enquanto consulta sistemas reais.

Não é mais apenas um chatbot.

É um assistente corporativo.


IBM watsonx e o IBM Z

Quando se fala em IA na IBM, um nome aparece constantemente.

watsonx.

Diferentemente de plataformas voltadas apenas para geração de texto, o watsonx foi concebido pensando no ambiente corporativo.

Seu foco inclui:

  • governança;

  • segurança;

  • compliance;

  • modelos customizados;

  • dados privados;

  • integração empresarial.

Isso faz enorme diferença.

Imagine um banco.

Ele dificilmente enviará informações sigilosas para um serviço público de IA.

Em vez disso, utilizará modelos privados, treinados dentro de sua própria infraestrutura.

É exatamente aí que soluções como o watsonx ganham destaque.


IA e COBOL Não Competem

Essa talvez seja a maior surpresa para quem está começando.

A IA não veio substituir COBOL.

Na verdade, ela depende dele.

Imagine um sistema bancário.

Cliente

↓

Chatbot

↓

Modelo Generativo

↓

API REST

↓

CICS

↓

Programa COBOL

↓

Db2

↓

Resposta Oficial

Perceba algo importante.

Quem decide se o cliente possui saldo suficiente?

COBOL.

Quem verifica regras de negócio?

COBOL.

Quem calcula juros?

COBOL.

Quem registra a transação?

COBOL.

A IA apenas transforma tudo isso em uma conversa mais natural.


APIs: A Ponte Entre Dois Mundos

Nos anos 80, aplicações conversavam usando protocolos proprietários.

Hoje, o cenário é outro.

REST.

JSON.

GraphQL.

gRPC.

OpenAPI.

Essas tecnologias tornaram possível integrar sistemas modernos com aplicações escritas décadas atrás.

Exemplo simplificado.

Aplicativo Mobile

↓

REST API

↓

IBM z/OS Connect

↓

CICS

↓

COBOL

↓

Db2

O usuário acredita estar falando com um aplicativo moderno.

Na realidade, o coração da operação continua sendo o Mainframe.


Exemplo Prático: Consulta de Saldo com IA

Imagine o seguinte diálogo.

Cliente:

Quanto tenho disponível para investir?

Fluxo interno:

Usuário

↓

LLM

↓

API

↓

COBOL

↓

Db2

↓

Saldo

↓

Perfil Financeiro

↓

IA gera resposta

Resposta:

"Você possui R$ 18.450 disponíveis. Considerando seu perfil conservador e seus investimentos atuais, existem alternativas de baixo risco compatíveis com seu histórico."

Quem calculou o saldo?

Db2.

Quem aplicou regras financeiras?

COBOL.

Quem transformou isso em linguagem natural?

A IA.


CICS Continua Sendo o Maestro

Durante décadas, o CICS foi responsável por coordenar milhões de transações.

Hoje ele ganha uma nova função.

Ser o elo entre aplicações modernas e sistemas críticos.

Imagine uma transferência PIX.

Aplicativo

↓

API

↓

CICS

↓

COBOL

↓

Db2

↓

Confirmação

↓

IA explica resultado

Em vez de substituir o CICS, a IA torna sua utilização ainda mais relevante.


Por Que Bancos Não Trocam Tudo?

Essa pergunta aparece constantemente.

A resposta é simples.

Porque funciona.

Mas existe outro motivo.

Imagine reescrever milhões de linhas de COBOL.

Quanto tempo levaria?

Quantos erros seriam introduzidos?

Quanto custaria?

Quanto risco financeiro seria criado?

Agora compare com outra abordagem.

Adicionar APIs

+

Adicionar IA

+

Adicionar Observabilidade

+

Adicionar Automação

=

Modernização gradual

Essa estratégia preserva décadas de conhecimento acumulado enquanto incorpora recursos modernos.

É muito mais segura e economicamente viável.


Primeira Arquitetura Completa

A seguir, uma visão simplificada de como uma arquitetura moderna pode integrar IA Generativa ao IBM Z:

                           ┌─────────────────────────────┐
                           │       Cliente Web/App       │
                           └─────────────┬───────────────┘
                                         │ HTTPS
                                         ▼
                           ┌─────────────────────────────┐
                           │   Chatbot / Assistente IA   │
                           └─────────────┬───────────────┘
                                         │
                              Prompt + Contexto
                                         │
                                         ▼
                      ┌─────────────────────────────────────┐
                      │      Modelo Generativo (LLM)        │
                      └─────────────┬───────────────────────┘
                                    │
                    RAG             │             MCP
                                    │
                                    ▼
          ┌───────────────────────────────────────────────────────┐
          │           Camada de Integração Inteligente            │
          │ APIs │ Ferramentas │ Documentos │ Catálogo │ Vetores  │
          └─────────────┬─────────────────────────────────────────┘
                        │
                REST / JSON / MQ
                        │
                        ▼
              ┌─────────────────────────┐
              │    IBM z/OS Connect     │
              └──────────┬──────────────┘
                         │
        ┌────────────────┼─────────────────┐
        ▼                ▼                 ▼
   CICS Online       Batch COBOL       MQ / Eventos
        │                │                 │
        └────────────┬───┴─────────────────┘
                     ▼
              ┌───────────────┐
              │ Programas COBOL│
              └──────┬────────┘
                     ▼
          ┌─────────────────────┐
          │ Db2 │ VSAM │ IMS DB │
          └─────────────────────┘

Essa arquitetura demonstra que a IA não elimina os sistemas existentes. Ela adiciona uma camada inteligente de interação, recuperação de contexto e geração de respostas, preservando o Mainframe como sistema de registro e fonte oficial da verdade.


Conclusão da Parte 1

Nos últimos anos, o debate sobre Inteligência Artificial concentrou-se em modelos cada vez maiores e mais sofisticados. No entanto, o verdadeiro diferencial competitivo das empresas não está apenas no modelo utilizado, mas na capacidade de conectar esses modelos aos dados corretos, com segurança, governança e desempenho.

É justamente nesse ponto que o IBM Z se destaca. Em vez de representar um obstáculo à inovação, ele se torna o alicerce sobre o qual soluções modernas de IA podem ser construídas. Tecnologias como RAG, MCP, APIs e o ecossistema watsonx mostram que a evolução dos sistemas corporativos não depende de substituir décadas de conhecimento, mas de integrá-las de forma inteligente.

Na Parte 2, vamos aprofundar essa jornada explorando casos reais do setor financeiro, arquiteturas de agentes de IA, observabilidade, DevOps para IBM Z, segurança, exemplos práticos de integração com COBOL, CICS e Db2, além de discutir como a Inteligência Artificial está transformando o papel do desenvolvedor Mainframe na próxima década.




   FAQ

  •  O Mainframe pode utilizar IA Generativa?
 Sim. 

  • A IA pode ser integrada ao IBM Z por meio de APIs, z/OS Connect, IBM MQ, RAG e plataformas como watsonx, permitindo que modelos consultem dados corporativos com segurança. O COBOL será substituído pela IA?
Não. 

A IA complementa aplicações COBOL, automatizando documentação, testes e atendimento, enquanto o COBOL continua executando as regras críticas de negócio. 

  •  O que é RAG? 

 Retrieval-Augmented Generation é uma técnica que permite ao modelo consultar bases de dados e documentos antes de responder, reduzindo alucinações e aumentando a precisão.

  • O que é MCP? 

Model Context Protocol é um protocolo aberto que padroniza a comunicação entre modelos de IA e ferramentas externas, como APIs, bancos de dados e sistemas corporativos. 

  •  O IBM watsonx funciona com Mainframe?
 Sim.

 O ecossistema watsonx foi desenvolvido para integração corporativa, oferecendo governança, segurança e suporte a modelos privados, podendo trabalhar em conjunto com aplicações IBM Z. 

  •  IA pode acessar Db2 e CICS? 
 Sim. 

Normalmente essa integração ocorre por meio de APIs REST, IBM z/OS Connect, IBM MQ ou serviços específicos que expõem funcionalidades do Mainframe de forma segura.

.



Vagner Bellacosa

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

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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

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