Translate

Mostrar mensagens com a etiqueta IBM MQ. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta IBM MQ. Mostrar todas as mensagens

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




segunda-feira, 15 de junho de 2026

☕🚀 Os Maiores Bancos Digitais do Brasil Nasceram na Nuvem, Mas o Dinheiro Ainda Passa pelo Mainframe

 

Bellacosa Mainframe e uma visão do sistema bancario brasileiro

☕🚀 Os Maiores Bancos Digitais do Brasil Nasceram na Nuvem, Mas o Dinheiro Ainda Passa pelo Mainframe

Existe uma frase que se tornou quase um mantra no mercado financeiro moderno:

"O futuro está na nuvem."

E é verdade.

Nubank, Inter, Mercado Pago, PicPay, PagBank e dezenas de fintechs brasileiras nasceram em arquiteturas modernas, utilizando APIs, microsserviços, containers, Kubernetes, inteligência artificial e infraestrutura cloud.

Mas existe uma realidade pouco comentada fora dos bastidores da tecnologia bancária.

Uma realidade que surpreende estudantes, jornalistas, executivos recém-chegados ao setor financeiro e até muitos profissionais de TI.

O dinheiro que movimenta bilhões de reais diariamente no Brasil continua passando por sistemas centrais executados em plataformas que nasceram décadas antes da internet comercial.

Sim.

Enquanto o cliente faz um PIX em um smartphone equipado com processadores capazes de executar bilhões de operações por segundo, uma parte significativa da infraestrutura que garante que aquele dinheiro chegue ao destino continua rodando em ambientes IBM Z, CICS, DB2, MQ e COBOL.

E isso não acontece por nostalgia.

Acontece porque funciona.

Muito bem.


O mito do "banco 100% digital"

Quando um banco digital aparece na televisão, geralmente a propaganda mostra:

  • aplicativo moderno;

  • cartão colorido;

  • conta aberta em minutos;

  • chatbot inteligente;

  • investimentos com poucos cliques.

Tudo parece novo.

Tudo parece revolucionário.

Tudo parece distante do mundo dos grandes datacenters.

Mas existe uma diferença importante entre:

interface digital
e
infraestrutura financeira.

O cliente enxerga o aplicativo.

O sistema financeiro enxerga liquidação.

E são coisas completamente diferentes.

Um banco pode ter uma experiência totalmente digital e, ainda assim, depender de sistemas centrais extremamente robustos para realizar:

  • liquidação financeira;

  • compensação;

  • controle contábil;

  • reconciliação;

  • registro de operações;

  • cálculo de tarifas;

  • processamento de empréstimos;

  • integração com o Banco Central.

É nesse momento que entram os sistemas de missão crítica.


O que acontece quando você faz um PIX?

Vamos imaginar uma situação extremamente comum.

Você abre o aplicativo.

Transfere R$ 100 para um amigo.

A operação parece instantânea.

Na tela tudo ocorre em segundos.

Mas por trás dos bastidores existe uma verdadeira cadeia industrial de processamento.

O aplicativo envia a solicitação.

Uma API recebe o pedido.

Serviços de autenticação validam identidade.

Motores antifraude executam verificações.

Regras de compliance são avaliadas.

Sistemas de limites são consultados.

Dados cadastrais são verificados.

Mensagerias distribuem eventos.

Sistemas contábeis registram a operação.

Mecanismos de liquidação realizam o acerto financeiro.

Tudo isso antes que a mensagem "PIX realizado com sucesso" apareça na tela.

O usuário vê um clique.

O datacenter vê centenas de transações.


Onde entra o mainframe?

É aqui que muita gente se surpreende.

O mainframe raramente aparece na camada visual.

Ele normalmente opera na camada mais importante.

A camada onde não pode haver erro.

Imagine o seguinte cenário.

Se uma rede social ficar indisponível por 10 minutos, usuários reclamam.

Se um streaming cair durante uma série, pessoas ficam irritadas.

Mas se um banco perder o controle de saldos durante 10 minutos?

O problema pode atingir milhões de clientes.

Por isso os sistemas responsáveis pelos registros financeiros mais críticos precisam apresentar:

  • disponibilidade extrema;

  • consistência absoluta;

  • segurança rigorosa;

  • rastreabilidade completa;

  • recuperação imediata.

São justamente essas características que fizeram os mainframes permanecerem relevantes.


O paradoxo da fintech

As fintechs surgiram prometendo romper com os bancos tradicionais.

Em muitos aspectos conseguiram.

Mudaram a experiência do cliente.

Reduziram burocracias.

Popularizaram contas digitais.

Criaram novos modelos de negócio.

Mas descobriram rapidamente uma verdade do mercado financeiro.

Movimentar dinheiro é muito mais difícil do que movimentar dados.

Enviar uma foto errada em uma rede social gera um transtorno.

Transferir R$ 10 milhões para a conta errada gera uma crise.

Por isso a arquitetura financeira moderna acabou evoluindo para um modelo híbrido.

Na superfície:

  • cloud;

  • APIs;

  • microsserviços;

  • inteligência artificial.

No núcleo:

  • processamento transacional;

  • bancos de dados críticos;

  • mensageria corporativa;

  • sistemas centrais de liquidação.

É uma combinação extremamente poderosa.


A nuvem descobriu que precisa do mainframe

Durante alguns anos surgiu uma narrativa bastante agressiva.

Muitos especialistas afirmavam que o mainframe desapareceria rapidamente.

A computação em nuvem seria suficiente para tudo.

A realidade mostrou algo diferente.

O que ocorreu foi integração.

Hoje observamos ambientes híbridos onde:

  • Kubernetes conversa com CICS;

  • APIs REST acessam programas COBOL;

  • aplicações cloud consomem serviços do z/OS;

  • eventos trafegam através do IBM MQ;

  • microsserviços utilizam informações armazenadas em DB2.

Não houve substituição.

Houve convergência.

A nuvem não matou o mainframe.

A nuvem passou a conversar com ele.


O caso brasileiro

O Brasil possui um dos sistemas financeiros mais sofisticados do planeta.

Muitas vezes não percebemos isso.

PIX.

TED.

DOC.

Open Finance.

Cartões.

Boletos.

Débito automático.

Tudo isso precisa funcionar para centenas de milhões de contas.

Os números impressionam.

Bilhões de transações são processadas todos os meses.

Milhões de operações acontecem simultaneamente.

O sistema precisa funcionar:

  • de madrugada;

  • em feriados;

  • durante promoções;

  • na Black Friday;

  • durante a Copa do Mundo;

  • durante grandes eventos nacionais.

A infraestrutura necessária para suportar esse volume é gigantesca.

E boa parte dela continua baseada em tecnologias que nasceram décadas atrás, mas evoluíram continuamente.


O COBOL que ninguém vê

Poucas tecnologias sofreram tanto preconceito quanto o COBOL.

Para muitos profissionais jovens, COBOL parece uma relíquia.

Algo pertencente a museus de informática.

Mas existe um detalhe curioso.

Grande parte das pessoas que criticam COBOL utilizou sistemas processados por COBOL antes mesmo do café da manhã.

Salário.

PIX.

Cartão.

Financiamento.

Previdência.

Seguros.

Consórcios.

Tudo isso frequentemente passa por programas COBOL.

O motivo é simples.

Esses sistemas foram construídos ao longo de décadas.

Receberam investimentos bilionários.

Foram testados em condições extremas.

Acumularam conhecimento de negócio impossível de reproduzir rapidamente.

Muitas vezes o código representa mais valor do que a própria infraestrutura.


O banco invisível

Imagine um iceberg.

O cliente vê apenas a ponta.

Aplicativo.

Cartão.

Notificação.

Interface.

Mas abaixo da superfície existe uma massa gigantesca de tecnologia invisível.

Essa parte inclui:

  • motores contábeis;

  • sistemas regulatórios;

  • integração com Banco Central;

  • mecanismos de liquidação;

  • auditoria;

  • compliance;

  • segurança.

É nesse universo invisível que o mainframe continua brilhando.

E justamente por ser invisível, raramente recebe o reconhecimento merecido.


Quando tudo funciona ninguém percebe

Existe uma ironia interessante no mundo da infraestrutura.

Quanto melhor um sistema funciona, menos as pessoas falam sobre ele.

Ninguém elogia um elevador por funcionar.

Ninguém agradece à rede elétrica por fornecer energia.

Ninguém faz uma postagem comemorando que o saldo bancário apareceu corretamente.

Mas quando ocorre uma falha?

Todo mundo percebe.

Por isso os sistemas centrais são projetados para uma missão simples:

não chamar atenção.

O sucesso é a invisibilidade.


O futuro não é cloud versus mainframe

Uma das maiores lições da última década foi perceber que a discussão estava errada.

A pergunta nunca deveria ter sido:

"Cloud ou Mainframe?"

A pergunta correta é:

"Como integrar os dois da melhor forma possível?"

Os líderes do mercado entenderam isso.

Hoje as arquiteturas mais modernas utilizam o melhor dos dois mundos.

Cloud para:

  • inovação rápida;

  • elasticidade;

  • analytics;

  • inteligência artificial.

Mainframe para:

  • processamento massivo;

  • transações críticas;

  • consistência financeira;

  • segurança corporativa.

O resultado é uma arquitetura híbrida extremamente eficiente.


A verdadeira transformação digital

Muitas empresas acreditam que transformação digital significa abandonar tudo que veio antes.

Mas a história mostra outra coisa.

Transformação digital bem-sucedida raramente consiste em destruir.

Consiste em evoluir.

Os sistemas que sustentam o mercado financeiro brasileiro representam décadas de conhecimento acumulado.

Substituí-los completamente seria como demolir uma usina hidrelétrica para construir um gerador portátil.

Não faz sentido.

O caminho inteligente é modernizar.

Expor APIs.

Integrar plataformas.

Automatizar processos.

Conectar o legado ao futuro.


O que os estudantes precisam entender

Quem está começando carreira em tecnologia frequentemente busca apenas as ferramentas mais recentes.

Isso é natural.

Mas existe uma lição valiosa.

As tecnologias que movimentam bilhões nem sempre são as mais populares nas redes sociais.

Muitas vezes são as mais confiáveis.

As mais estáveis.

As mais resilientes.

O profissional que entende:

  • cloud;

  • APIs;

  • Kubernetes;

  • segurança;

  • mainframe;

  • integração corporativa;

torna-se extremamente valioso para o mercado.

Porque consegue enxergar a arquitetura completa.

Não apenas a camada visível.


Conclusão: o coração continua batendo

Os maiores bancos digitais do Brasil nasceram na nuvem.

Foram criados por uma geração que cresceu falando de APIs, microsserviços e aplicações móveis.

Mudaram completamente a forma como os brasileiros se relacionam com o dinheiro.

Mas, ao crescerem, descobriram algo que os bancos tradicionais já sabiam há décadas.

No mercado financeiro, velocidade é importante.

Experiência do usuário é importante.

Inovação é importante.

Mas nada é mais importante do que confiança.

E confiança se constrói com sistemas capazes de operar dia após dia, ano após ano, movimentando bilhões de reais sem perder o controle de um único centavo.

Por isso, enquanto milhões de brasileiros fazem PIX, pagam boletos, investem, financiam imóveis e utilizam aplicativos modernos, existe uma infraestrutura silenciosa trabalhando nos bastidores.

Uma infraestrutura que raramente aparece nas propagandas.

Que quase nunca vira manchete.

Mas que continua sustentando o sistema financeiro nacional.

A nuvem trouxe inovação.

As fintechs trouxeram agilidade.

Os aplicativos trouxeram conveniência.

Mas, no coração de boa parte dessa engrenagem, o velho gigante continua trabalhando.

Discreto.

Confiável.

Resiliente.

Processando bilhões.

Como faz há décadas.

E, ao que tudo indica, continuará fazendo por muitos anos.


☕🚀 Azure + IBM MQ + CICS + COBOL: Quando a Nuvem Descobre Que Ainda Precisa do Mainframe

Bellacosa Mainframe e uma visão da integração mainframe + nuvem


☕🚀 Azure + IBM MQ + CICS + COBOL: Quando a Nuvem Descobre Que Ainda Precisa do Mainframe

A arquitetura híbrida que responde em milissegundos e movimenta bilhões sem que ninguém perceba

Existe uma frase que escuto há mais de trinta e cinco anos:

"O Mainframe está morrendo."

A primeira vez que ouvi isso foi quando ainda existiam fitas magnéticas por todos os lados, terminais 3270 ocupavam salas inteiras e a internet comercial engatinhava.

Depois ouvi novamente quando surgiram os ERPs.

Depois quando surgiram os Data Centers distribuídos.

Depois quando vieram os smartphones.

Depois quando chegaram os containers.

Depois quando Kubernetes virou moda.

Depois quando a nuvem se tornou o assunto do momento.

E agora escuto novamente com a Inteligência Artificial.

Curiosamente, enquanto todos anunciavam o funeral do Mainframe, ele continuava processando cartões de crédito, transações bancárias, reservas aéreas, operações de seguradoras, sistemas governamentais e bilhões de dólares diariamente.

Talvez o erro nunca tenha sido tecnológico.

Talvez o erro tenha sido imaginar que inovação significa substituir tudo o que existe.

Na prática, a verdadeira inovação costuma acontecer quando conseguimos conectar mundos aparentemente incompatíveis.

E poucas arquiteturas representam isso melhor do que a integração entre Microsoft Azure e IBM Mainframe utilizando IBM MQ, CICS e COBOL.

Estamos falando de uma arquitetura capaz de unir o melhor dos dois universos:

  • Agilidade da nuvem

  • Robustez do Mainframe

  • Escalabilidade dos microsserviços

  • Consistência transacional do CICS

  • Segurança do IBM MQ

  • Décadas de regras de negócio escritas em COBOL

Tudo funcionando como uma única plataforma.


O Grande Equívoco Sobre Modernização

Quando alguém fala em modernização, muitas pessoas imaginam algo parecido com isto:

Sistema Antigo
      ↓
Apagar Tudo
      ↓
Reescrever Tudo
      ↓
Sistema Novo

Na teoria parece simples.

Na prática costuma ser um desastre.

Imagine um banco que possui:

  • 40 milhões de clientes

  • 30 anos de regras de negócio

  • milhares de programas COBOL

  • dezenas de sistemas satélites

  • integrações desconhecidas

Reescrever tudo pode levar anos.

Custar centenas de milhões.

E ainda introduzir novos erros.

Por isso os grandes bancos do mundo adotaram outro caminho.

Em vez de substituir o Mainframe, passaram a conectá-lo ao ecossistema digital.

É exatamente isso que esta arquitetura faz.


O Cliente Nem Imagina o Que Está Acontecendo

Imagine um cliente consultando saldo pelo aplicativo.

Ele toca um botão.

Em menos de um segundo recebe a resposta.

Para ele parece algo simples.

Mas nos bastidores ocorre uma verdadeira orquestra tecnológica.

O aplicativo chama uma API hospedada no Azure.

A API gera uma mensagem JSON.

Essa mensagem atravessa a rede.

Chega ao IBM MQ.

O MQ desperta uma transação CICS.

O CICS chama um programa COBOL.

O COBOL consulta DB2.

A resposta retorna pelo mesmo caminho.

Tudo isso em poucos milissegundos.

O usuário jamais perceberá.

E essa é justamente a beleza da arquitetura.


IBM MQ: O Carteiro Mais Confiável do Mundo Corporativo

Muitos profissionais mais jovens cresceram utilizando APIs REST.

Naturalmente surge a pergunta:

Por que usar MQ?

Porque sistemas críticos exigem garantias que HTTP sozinho não consegue fornecer.

Quando uma mensagem entra em uma fila MQ, ela não desaparece.

Ela permanece armazenada até ser processada.

Mesmo que:

  • um servidor caia

  • a rede falhe

  • uma aplicação seja reiniciada

a mensagem continua lá.

Imagine uma transferência financeira de cem mil reais.

Você gostaria que ela dependesse exclusivamente de uma conexão HTTP momentânea?

Provavelmente não.

É por isso que bancos continuam apaixonados pelo MQ.

Ele foi criado para ambientes onde perder uma única mensagem pode significar prejuízo milionário.


Request-Reply: O Casamento Entre Dois Mundos

Existe um detalhe fascinante nessa arquitetura.

O mundo web é síncrono.

O mundo MQ é assíncrono.

São filosofias diferentes.

Quando um navegador faz uma requisição HTTP, ele espera uma resposta.

Quando uma aplicação grava uma mensagem em uma fila MQ, ela normalmente segue seu caminho.

Mas o usuário quer uma resposta imediata.

Surge então o padrão Request-Reply.

Funciona assim:

A aplicação envia uma mensagem para a fila REQUEST.

O Mainframe processa.

Depois envia uma resposta para uma fila REPLY.

A aplicação recupera a resposta e devolve ao usuário.

Parece simples.

Mas essa simplicidade esconde décadas de evolução arquitetural.


O Poder dos Identificadores

Aqui encontramos um dos elementos mais importantes de toda a solução.

O MsgId.

Cada mensagem recebe um identificador único.

Por exemplo:

A1B2C3D4E5

Quando a resposta é gerada, esse valor reaparece como CorrelId.

Dessa forma:

Request
MsgId = A1B2C3D4E5

Reply
CorrelId = A1B2C3D4E5

A aplicação consegue saber exatamente qual resposta pertence a qual requisição.

Sem isso seria impossível processar milhares de mensagens simultaneamente.

É como o número de protocolo de uma ligação para suporte.

Sem ele tudo viraria uma enorme confusão.


MQ Trigger: O Despertador do Mainframe

Uma das partes mais elegantes dessa arquitetura é o Trigger.

Imagine um operador sentado observando uma fila.

Sempre que chegasse uma mensagem ele iniciaria um programa.

Seria absurdo.

O MQ faz isso automaticamente.

Quando uma mensagem chega:

QUEUE DEPTH = 1

o Trigger entra em ação.

Instantaneamente ele inicia uma transação CICS.

Sem polling.

Sem scripts.

Sem agendadores.

Sem desperdício de CPU.

É uma solução extremamente elegante criada décadas antes do conceito moderno de eventos ganhar popularidade.

Na verdade, muitos sistemas chamados hoje de Event-Driven Architecture fazem algo conceitualmente muito parecido com o que MQ e CICS realizam há anos.


O Router Program: O Maestro da Orquestra

Após a ativação do Trigger entra em cena o Router Program.

Se eu tivesse que apontar o cérebro da arquitetura, seria ele.

Sua função é simples:

Receber.

Analisar.

Decidir.

Encaminhar.

Ele lê o payload.

Consulta tabelas de roteamento.

Avalia parâmetros.

E escolhe qual backend deverá executar o processamento.

Por exemplo:

CONSULTA_CLIENTE → CUST0001
PIX → PIX0001
CARTAO → CARD0001

Isso oferece enorme flexibilidade.

Novos serviços podem ser adicionados sem alterar toda a arquitetura.

Basta cadastrar uma nova regra.

É o equivalente corporativo de um controlador de tráfego aéreo.


Quando COBOL Encontra JSON

Muitos profissionais ainda acreditam que COBOL vive preso a arquivos sequenciais e layouts de 80 colunas.

A realidade atual é muito diferente.

O CICS moderno possui recursos nativos para trabalhar com JSON.

Isso significa que uma estrutura como:

{
  "cliente":"VAGNER",
  "saldo":1500
}

pode ser transformada diretamente em estruturas COBOL.

Sem parsers complexos.

Sem centenas de linhas de manipulação de texto.

Sem gambiarras.

Durante décadas, integrar COBOL com formatos modernos exigia muito esforço.

Hoje o próprio CICS faz grande parte desse trabalho.

Essa é uma das transformações menos conhecidas fora do universo Mainframe.


O Segredo da Performance

Quando alguém vê Azure, JSON e microsserviços, normalmente imagina dezenas de chamadas distribuídas.

Mas o processamento principal acontece dentro do CICS.

E isso muda tudo.

Após chegar ao Mainframe, a execução ocorre dentro de um ambiente extremamente otimizado.

Não existe:

  • startup de container

  • inicialização de JVM

  • criação de novos processos

  • overhead desnecessário

O programa já está carregado.

O ambiente já está pronto.

A transação apenas executa.

É por isso que muitas operações conseguem responder em poucos milissegundos.

Uma característica frequentemente subestimada por quem nunca trabalhou em ambientes de missão crítica.


DB2: O Guardião da Consistência

Toda essa velocidade seria inútil sem consistência.

É aqui que entra o DB2.

Quando o COBOL consulta ou atualiza dados, o DB2 garante:

  • integridade

  • atomicidade

  • isolamento

  • durabilidade

Os famosos princípios ACID.

Em outras palavras:

ou tudo acontece corretamente

ou nada acontece.

Em sistemas financeiros isso não é luxo.

É obrigação.

Ninguém quer descobrir que o débito ocorreu mas o crédito não.


O Valor das Transações

Um aspecto frequentemente ignorado é o gerenciamento transacional.

Quando MQ, CICS e DB2 trabalham juntos, formam um ecossistema extremamente robusto.

Imagine:

  • mensagem recebida

  • atualização realizada

  • resposta enviada

Tudo dentro de uma única unidade lógica de trabalho.

Se qualquer etapa falhar:

rollback.

Como se nada tivesse acontecido.

Esse é um dos motivos pelos quais Mainframes continuam dominando ambientes financeiros.

Confiabilidade não é um recurso opcional.

É parte fundamental do negócio.


Dead Letter Queue: A Sala de Quarentena

Nem toda mensagem nasce perfeita.

Erros acontecem.

Layouts incorretos.

Dados inválidos.

Problemas de roteamento.

Mensagens corrompidas.

Se elas bloqueassem a fila principal, toda a operação sofreria.

A solução é a Dead Letter Queue.

A famosa DLQ.

Ela funciona como uma área de isolamento.

Mensagens problemáticas são removidas do fluxo principal e armazenadas separadamente.

O processamento continua.

Os usuários continuam trabalhando.

A equipe técnica pode investigar posteriormente.

É um conceito simples.

Mas extremamente poderoso.


O Que os Jovens Arquitetos Podem Aprender Com Isso

Existe uma tendência atual de acreditar que tudo começou com APIs, Kubernetes e microsserviços.

Arquiteturas como esta mostram que muitos conceitos modernos possuem raízes muito mais antigas.

Observe:

Eventos.

Mensageria.

Roteamento dinâmico.

Processamento assíncrono.

Alta disponibilidade.

Escalabilidade.

Observabilidade.

Resiliência.

Tudo isso já existia em ambientes Mainframe décadas atrás.

A diferença é que hoje utilizamos novos nomes para ideias antigas.


O Futuro Não É Cloud ou Mainframe

A pergunta correta não é:

Cloud ou Mainframe?

A pergunta correta é:

Como combinar Cloud e Mainframe?

A resposta está justamente nesta arquitetura.

O Azure fornece velocidade para inovação.

O Mainframe fornece estabilidade para execução.

O MQ conecta os dois mundos.

O CICS orquestra as transações.

O COBOL preserva o conhecimento acumulado.

O DB2 protege os dados.

Juntos, eles formam uma plataforma capaz de atender milhões de usuários simultaneamente.


Considerações Finais

Ao observar esta arquitetura, não vejo apenas filas MQ, programas COBOL ou serviços Azure.

Vejo algo muito mais interessante.

Vejo a prova de que tecnologia não é uma disputa entre velho e novo.

É uma construção contínua.

Os sistemas que realmente movem o mundo raramente são os mais barulhentos.

São os mais confiáveis.

Enquanto muitos discutem tendências, frameworks e modismos passageiros, arquiteturas híbridas como esta continuam processando pagamentos, movimentando recursos financeiros, autorizando cartões, executando operações críticas e sustentando economias inteiras.

Talvez essa seja a maior lição de todas.

O futuro não pertence exclusivamente à nuvem.

O futuro pertence às arquiteturas capazes de unir inovação e legado sem sacrificar desempenho, segurança ou confiabilidade.

E poucas combinações fazem isso tão bem quanto Azure, IBM MQ, CICS, COBOL e DB2 trabalhando em perfeita harmonia.

Porque, no final das contas, modernizar não significa destruir o passado.

Significa construir pontes entre o que já funciona e aquilo que ainda está por vir.

E essa arquitetura é uma dessas pontes.


sábado, 23 de maio de 2026

☕🔥 “O SEGREDO SUJO DA PERFORMANCE NO MAINFRAME” — POR QUE CACHE VALE MAIS QUE CPU NO MUNDO COBOL/CICS

 

Bellacosa Mainframe e a alta performance no mainframe

☕🔥 “O SEGREDO SUJO DA PERFORMANCE NO MAINFRAME” — POR QUE CACHE VALE MAIS QUE CPU NO MUNDO COBOL/CICS

Quando alguém fala em performance, a maioria pensa imediatamente em:

  • CPU,

  • MIPS,

  • zIIP,

  • upgrade de hardware.

Mas no mundo IBM Mainframe existe uma verdade brutal:

☕ O MAIOR INIMIGO DA PERFORMANCE É O I/O.

E por isso:

CACHE É UMA DAS COISAS MAIS IMPORTANTES DO UNIVERSO z/OS.

A imagem mostra 9 estratégias modernas de caching.

Agora vamos traduzir isso para:

  • COBOL,

  • CICS,

  • DB2,

  • VSAM,

  • MQ,

  • Batch,

  • Sysplex,

no puro estilo Bellacosa Mainframe.


☕ 1. CACHE-ASIDE — “BUSQUE SÓ QUANDO PRECISAR”

Na imagem:

  • aplicação procura primeiro no cache,

  • se não encontrar, busca no banco.


🔥 Isso é praticamente a filosofia clássica do CICS

Exemplo:

Programa COBOL/CICS

EXEC CICS READQ TS
END-EXEC.

Se o dado:

  • já estiver em TSQ,

  • COMMAREA,

  • ou memória temporária,

não precisa acessar:

  • DB2,

  • VSAM,

  • disco físico.


☕ Exemplo real

Consulta de cliente VIP:

  • primeira busca → DB2,

  • próximas buscas → memória CICS.


🔥 Resultado

Menos:

  • EXCP,

  • lock,

  • espera,

  • canal I/O.

Mais:

  • TPS,

  • resposta rápida,

  • estabilidade.


☕ 2. READ-THROUGH — “O CACHE BUSCA AUTOMATICAMENTE”


🔥 No mainframe isso aparece muito em DB2 Buffer Pool

O programa COBOL:

nem sabe se o dado veio da memória ou do disco

O DB2 decide.


☕ Fluxo real

SELECT → Buffer Pool → se miss → DASD

🔥 O detalhe importante

Boa parte da má performance em DB2:

NÃO é SQL ruim

mas:

  • buffer pool inadequado,

  • hit ratio baixo,

  • excesso de I/O físico.


☕ Frase clássica de performance analyst

“Seu SELECT talvez esteja ótimo.

Seu disco é que está sofrendo.”


☕ 3. WRITE-THROUGH — “GRAVAR NO CACHE E NO BANCO AO MESMO TEMPO”


🔥 Aqui entra o lado paranoico do mainframe

O IBM Z odeia inconsistência.


☕ Exemplo bancário

PIX:

  • atualiza saldo,

  • atualiza log,

  • atualiza auditoria,

  • confirma persistência.

Tudo sincronizado.


☕ No DB2 isso lembra:

  • commit controlado,

  • logging,

  • buffer synchronization.


🔥 Benefício

Maior consistência.


☕ Problema

Mais latência.


🔥 Mainframe frequentemente escolhe:

CONSISTÊNCIA > VELOCIDADE

porque banco prefere:

“mais lento”

a:

“saldo corrompido”.

☕ 4. WRITE-BEHIND (WRITE-BACK) — “GRAVA DEPOIS”


🔥 Estratégia perigosamente poderosa

Primeiro:

  • grava em memória,

  • depois persiste assíncrono.


☕ No Mainframe aparece em:

  • buffers VSAM,

  • deferred write,

  • MQ persistence strategies,

  • DFSORT spill optimization.


☕ Benefício monstruoso

Reduz I/O físico.


🔥 Risco brutal

Se houver falha antes da persistência:

dado pode sumir.


☕ Por isso no mundo financeiro:

  • write-back é cuidadosamente controlado,

  • logging vira obrigatório,

  • recovery é crítico.


☕ 5. REFRESH-AHEAD — “ATUALIZE ANTES DE EXPIRAR”


🔥 Mainframe faz isso há décadas

Exemplo:

DB2 Prefetch

O sistema prevê páginas futuras.


☕ Outro exemplo

Batch COBOL:

  • pré-carrega tabelas,

  • carrega parâmetros em memória,

  • evita lookup repetitivo.


🔥 Filosofia do z/OS

“Se você SABE que vai precisar…

carregue antes.”


☕ 6. INVALIDATION — “JOGUE FORA O QUE FICOU VELHO”


🔥 Aqui mora um dos maiores pesadelos corporativos

DADO STALE


☕ Exemplo real

Usuário altera endereço.

Mas:

  • cache ainda possui dado antigo.

Resultado:

  • sistema A mostra endereço novo,

  • sistema B mostra antigo.


🔥 No Mainframe isso é gravíssimo

Porque:

  • múltiplos sistemas compartilham informação,

  • inconsistência pode virar problema legal.


☕ Técnicas usadas

  • cache invalidation,

  • commit synchronization,

  • DB2 coherency,

  • Sysplex cache coherence.


☕ 7. CACHE WARMING — “ESQUENTAR O CACHE”


🔥 Todo operador experiente conhece isso

Após IPL:

  • tudo está “frio”.


☕ Resultado clássico

Primeiros minutos:

  • I/O explode,

  • disco sofre,

  • response time piora.


🔥 Então muitos ambientes:

  • executam jobs de preload,

  • aquecem buffer pools,

  • pré-carregam tabelas críticas.


☕ Exemplo Bellacosa

Banco antes da abertura:

pré-carrega contas mais acessadas.

☕ 8. CACHE SHARDING — “DIVIDIR O CACHE”


🔥 Aqui entra Parallel Sysplex

Vários nós:

  • compartilham workload,

  • dividem memória,

  • reduzem contenção.


☕ Exemplo real

Cada região CICS:

  • mantém cache local,

  • mas sincroniza estado global.


🔥 Benefício

Escalabilidade monstruosa.


☕ Desafio

Coerência.


🔥 Porque o pesadelo é:

nó A sabe algo
nó B não sabe

☕ 9. TTL (TIME TO LIVE) — “TUDO TEM PRAZO DE VALIDADE”


🔥 No Mainframe isso é filosofia operacional

Nem todo dado pode viver eternamente no cache.


☕ Exemplos

Taxa de câmbio

TTL pequeno.


Tabela de estados brasileiros

TTL enorme.


🔥 O segredo

Equilibrar:

  • frescor,

  • performance,

  • consistência.


☕ O ERRO CLÁSSICO DOS INICIANTES

Pensar:

“Mais cache = sempre melhor”

🔥 NÃO.

Cache ruim pode gerar:

  • inconsistência,

  • stale data,

  • contenção,

  • explosão de memória,

  • recovery complexo.


☕ O QUE O MAINFRAME ENSINA SOBRE CACHE

Cache não é só velocidade.

É:

  • engenharia de previsibilidade,

  • redução de I/O,

  • estabilidade operacional,

  • proteção contra gargalos.


🔥 Porque no IBM Z:

DISCO É O INIMIGO NATURAL DA PERFORMANCE.


☕ RESUMO BELLACOSA MAINFRAME

EstratégiaNo IBM Mainframe
Cache-AsideTSQ/COMMAREA/lookup local
Read-ThroughDB2 Buffer Pool
Write-ThroughCommit síncrono
Write-BehindDeferred write
Refresh-AheadPrefetch
InvalidationCache coherency
Cache WarmingPreload pós IPL
Cache ShardingSysplex distribution
TTLExpiração controlada

☕🔥 Frase final no estilo Bellacosa Mainframe

“Muita gente acha que Mainframe é rápido por causa da CPU.

Veterano de z/OS sabe:

o segredo quase sempre está em evitar I/O.”

 

segunda-feira, 29 de dezembro de 2025

💥 MQ NÃO É FILA — É O SEGURO DE VIDA DO SEU COBOL

 

Bellacosa Mainframe conheça MQ 

💥 MQ NÃO É FILA — É O SEGURO DE VIDA DO SEU COBOL

O guia definitivo de IBM MQ Fundamentals para quem vive no z/OS

Se você é um dev COBOL experiente, já sabe:
👉 o problema nunca foi o código…
👉 o problema sempre foi integração.

E é exatamente aí que entra o IBM MQ — o componente que transformou o mainframe de “ilha isolada” em coração da arquitetura moderna.


🕰️ ORIGEM — POR QUE O MQ EXISTE?

Antes do MQ:

  • Sistemas conversavam via sockets, arquivos, chamadas diretas
  • Tudo era síncrono
  • Se o destino caía → 💥 tudo quebrava

👉 A IBM criou o MQ (antigo WebSphere MQ) para resolver:

✔ Desacoplamento
✔ Confiabilidade
✔ Escalabilidade
✔ Integração heterogênea

💡 Tradução Bellacosa:

“MQ nasceu para impedir que um sistema derrube o outro.”


🧠 CONCEITO CENTRAL (O QUE MUDA TUDO)

👉 Aplicações não se falam diretamente

Elas falam com filas.


📦 MODELO MENTAL

COBOL A → MQ → COBOL B

✔ A envia
✔ MQ guarda
✔ B consome

👉 Simples… e revolucionário


💥 O TRIO QUE VOCÊ NUNCA ESQUECE

ConceitoPapel
MessageUnidade de dados
QueueArmazenamento
Queue ManagerCérebro

🧠 FRASE DE OURO

“Sem Queue Manager… não existe MQ.”


⚙️ COMO ISSO FUNCIONA (PASSO A PASSO REAL)

🔹 1. Aplicação COBOL envia mensagem

CALL 'MQPUT' USING ...

👉 Não importa:

  • Se o destino está online
  • Onde ele está
  • Qual linguagem usa

🔹 2. MQ armazena na fila

✔ Persistente (disco)
✔ Seguro
✔ Ordenado


🔹 3. Outra aplicação consome

CALL 'MQGET' USING ...

👉 Pode ser:

  • COBOL
  • Java
  • .NET
  • SAP

🔄 ASSÍNCRONO — O PODER REAL

👉 Diferente de CICS sync:

✔ Envia → continua
✔ Não bloqueia
✔ Alta performance

💡 Isso muda tudo em batch + online


💾 PERSISTENT vs NON-PERSISTENT

🔥 Persistent

✔ Gravado em disco
✔ Não perde
✔ Entrega garantida

👉 Use em:

  • Financeiro
  • Débito
  • Liquidação

⚡ Non-persistent

✔ Mais rápido
❌ Pode perder

👉 Use em:

  • Consulta
  • Logs
  • Eventos leves

🔄 UOW — TRANSAÇÃO DE VERDADE

👉 Unit of Work = grupo de mensagens

✔ Tudo ou nada

💡 Exemplo:

  • 4 mensagens
  • 1 falha

👉 MQ faz rollback de todas


💀 DLQ — DEAD LETTER QUEUE

👉 Quando dá ruim:

✔ Mensagem vai para DLQ
✔ Com motivo + código

💡 Easter egg de produção:

DLQ cheia = sistema gritando socorro


🔐 SEGURANÇA (NÍVEL ENTERPRISE)

🧠 OAM (Object Authority Manager)

✔ Controla acesso
✔ Quem pode PUT/GET


🔒 SSL / TLS

✔ Criptografia
✔ Autenticação


🔄 CONVERSÃO DE DADOS (A MÁGICA)

👉 COBOL (EBCDIC) ↔ Java (ASCII)

✔ MQ converte automaticamente

💡 Você nem vê acontecer


⚙️ CUSTOM CONVERSION

👉 Quer regra própria?

✔ Use exits

💡 Muito usado em legado


🧩 PADRÕES DE ARQUITETURA (OURO)


📦 Point-to-Point

✔ 1 → 1
✔ Request/Reply

👉 Clássico COBOL ↔ COBOL


💻 Client/Server

✔ Muitos → 1

👉 Centralização (ex: core bancário)


⚖️ Workload Sharing

✔ 1 fila → vários consumidores

👉 Paralelismo brutal

💡 Padrão:

Competing Consumers


📡 Publish/Subscribe

✔ 1 → muitos
✔ Desacoplado

👉 Base de Event-Driven Architecture


💣 PEGADINHAS QUE DERRUBAM SENIOR

❌ MQ é síncrono → ERRADO
❌ Aplicações se conectam direto → ERRADO
❌ Remote queue armazena mensagem → ERRADO
❌ MQ garante non-persistent → ERRADO


🧠 CENÁRIO REAL (BANCO)

👉 Fluxo típico:

  1. COBOL envia transação (MQPUT)
  2. MQ armazena (persistent)
  3. Workers processam (workload)
  4. Evento dispara (pub/sub)

💥 Tudo via MQ


🔥 CURIOSIDADES (EASTER EGGS)

  • MQ existe desde os anos 90 e ainda domina bancos
  • DLQ handler pode automatizar correções
  • MQ roda em:
    • z/OS
    • Linux
    • Windows
  • Pode transportar até 100MB por mensagem

💥 FRASES QUE DEFINEM MQ

“MQ desacopla no tempo, no espaço e na tecnologia.”

“Se caiu, MQ segura. Se voltou, MQ entrega.”

“COBOL não morreu… ele só ganhou MQ.”


🚀 CONCLUSÃO

Se você domina MQ:

✔ Seus sistemas não quebram fácil
✔ Integração deixa de ser dor
✔ Você pensa como arquiteto


💣 VERDADE FINAL

“MQ não é só middleware…
é o que separa sistemas frágeis de sistemas resilientes.”

 

quarta-feira, 11 de junho de 2025

Laboratório Prático de Java para IBM Mainframe 20 Labs para Transformar um Programador COBOL em um Desenvolvedor Java para IBM Z

 

Bellacosa Mainframe e um laboratorio java para mainframers

☕ Um Café no Bellacosa Mainframe

Laboratório Prático de Java para IBM Mainframe

Metodologia do Laboratório

Este laboratório foi desenvolvido para programadores COBOL iniciantes no ecossistema IBM Z, utilizando uma metodologia prática baseada no conceito learning by doing (aprender fazendo). Em vez de ensinar Java de forma isolada, cada conceito é apresentado em paralelo com tecnologias já conhecidas pelo desenvolvedor Mainframe, como COBOL, JCL, CICS, DB2, VSAM e z/OS. Dessa forma, o aluno estabelece uma associação natural entre os dois ambientes, reduzindo a curva de aprendizado e compreendendo como ambas as linguagens coexistem na arquitetura corporativa moderna.

Os vinte laboratórios evoluem gradualmente, começando pelos fundamentos da linguagem Java, passando por orientação a objetos, tratamento de exceções, coleções, acesso ao DB2 via JDBC, processamento Batch, APIs REST, WebSphere Liberty, IBM MQ, z/OS Connect, automação com Ansible, DevOps, LinuxONE e containers. Cada exercício apresenta objetivos claros, arquitetura, código comentado, desafios práticos e solução completa.

Ao final do treinamento, espera-se que o desenvolvedor compreenda o papel estratégico do Java no IBM Z e no LinuxONE, saiba como a JVM é executada nessas plataformas, desenvolva aplicações Batch e Online, integre serviços Java com programas COBOL e DB2, automatize processos utilizando ferramentas modernas e participe de projetos de modernização sem abandonar os sólidos fundamentos do Mainframe. O objetivo não é substituir o COBOL, mas formar profissionais capazes de transitar com segurança por todo o ecossistema IBM Z.

20 Labs para Transformar um Programador COBOL em um Desenvolvedor Java para IBM Z

Objetivo: Capacitar um programador COBOL Junior a compreender como o Java funciona dentro do ecossistema IBM Z, sempre relacionando os novos conceitos com aquilo que ele já conhece em COBOL, JCL, CICS e DB2.


Filosofia do Laboratório

Este não é um curso tradicional de Java.

É um curso pensado para quem já conhece Mainframe.

Durante todos os exercícios faremos comparações entre:

  • COBOL × Java

  • JCL × JVM

  • CICS × Liberty

  • SQL Embutido × JDBC

  • VSAM × Collections

  • Batch × Java Batch

  • Online CICS × REST APIs

O objetivo é diminuir o choque entre os dois mundos.


Ambiente sugerido

Desenvolvimento

  • VS Code

  • IBM Z Open Editor

  • Java 21 LTS

  • Maven

  • Git

  • Zowe CLI

Mainframe

  • IBM z/OS

  • USS (Unix System Services)

  • Enterprise COBOL

  • DB2

  • CICS TS

  • z/OS Connect

  • IBM MQ

  • WebSphere Liberty

Opcional

  • LinuxONE

  • Docker

  • OpenShift

  • Ansible


LAB 01 — Primeiro Programa Java

Objetivo

Criar o famoso Hello World.

O que aprender

  • Classe

  • Método main()

  • JVM

  • Compilação

Exercício

Criar

HelloMainframe.java

Executar

javac HelloMainframe.java

java HelloMainframe

Solução

Exibir

Olá IBM Z

LAB 02 — Comparando COBOL e Java

Objetivo

Criar um programa que recebe nome e idade.

Comparar com

WORKING-STORAGE
DISPLAY
ACCEPT

Aprender

  • Scanner

  • Variáveis

  • String

  • int

Solução

Programa imprime

Olá João

Você possui 30 anos

LAB 03 — Estruturas de Decisão

Comparar

COBOL

IF
ELSE
END-IF

com

Java

if

else

Exercício

Calcular maioridade.


LAB 04 — Estruturas de Repetição

Comparar

PERFORM UNTIL

com

for

while

Exercício

Exibir números de 1 a 100.


LAB 05 — Métodos

Comparar

SECTION

PARAGRAPH

com

Métodos Java

Criar método

calcularIR()

LAB 06 — Orientação a Objetos

Primeiro contato.

Criar

Cliente
Conta

Banco

Aprender

  • classe

  • objeto

  • atributos

  • métodos


LAB 07 — Collections

Comparar

Tabela OCCURS

com

ArrayList

Exercício

Cadastrar clientes.


LAB 08 — Tratamento de Exceções

Comparar

IF SQLCODE

IF FILE STATUS

com

try

catch

Gerar erro proposital.

Capturar erro.


LAB 09 — Leitura de Arquivos

Comparar

Sequential File

com

BufferedReader

Ler arquivo

CLIENTES.TXT

LAB 10 — Escrevendo Arquivos

Criar

RELATORIO.TXT

Comparar

WRITE

com

FileWriter.


LAB 11 — JDBC + DB2

Objetivo

Primeira conexão com DB2.

Aprender

  • Driver JDBC

  • Connection

  • Statement

  • ResultSet

Consulta

SELECT *

CLIENTE

Solução

Exibir registros na tela.


LAB 12 — PreparedStatement

Comparar

EXEC SQL

com

PreparedStatement

Inserir cliente.

Depois atualizar.

Depois excluir.


LAB 13 — Java Batch

Criar um processamento Batch.

Fluxo

Ler Arquivo

↓

Validar

↓

Atualizar DB2

↓

Gerar Relatório

Executar usando JCL.


LAB 14 — Java no USS

Entrar no Unix System Services.

Executar

java

javac

jar

Aprender

  • PATH

  • JAVA_HOME

  • CLASSPATH


LAB 15 — WebSphere Liberty

Criar primeira aplicação.

Executar

localhost:9080

Primeira API REST.


LAB 16 — Java + MQ

Criar

Produtor

Consumidor

Enviar mensagens.

Comparar com Batch desacoplado.


LAB 17 — Java + CICS

Criar aplicação Java.

Consumir programa COBOL.

Fluxo

Java

↓

CICS

↓

COBOL

Entender integração.


LAB 18 — Java + z/OS Connect

Criar API REST.

Consumir programa COBOL.

Resultado

GET

/clientes

Retorna

JSON.


LAB 19 — Deploy Automatizado

Criar Pipeline.

Ferramentas

  • Git

  • Maven

  • Jenkins

  • Zowe

  • Ansible

Deploy automático.


LAB 20 — Projeto Final

Sistema Bancário Completo

Arquitetura

Cliente

↓

REST API

↓

Spring Boot

↓

Liberty

↓

MQ

↓

CICS

↓

COBOL

↓

DB2

O Projeto

Cadastrar clientes.

Consultar clientes.

Atualizar clientes.

Excluir clientes.

Gerar relatório Batch.

Consultar API REST.

Executar deploy automático.


Estrutura sugerida

MainframeJavaLabs

│

├── Lab01_HelloJava

├── Lab02_Variaveis

├── Lab03_IF

├── Lab04_FOR

├── Lab05_Metodos

├── Lab06_OO

├── Lab07_Collections

├── Lab08_Exceptions

├── Lab09_Arquivos

├── Lab10_FileWriter

├── Lab11_JDBC

├── Lab12_PreparedStatement

├── Lab13_JavaBatch

├── Lab14_USS

├── Lab15_Liberty

├── Lab16_MQ

├── Lab17_CICS

├── Lab18_zOSConnect

├── Lab19_Ansible

└── Lab20_ProjetoFinal

O que cada laboratório deve conter

Para que o aprendizado seja realmente prático, todos os 20 laboratórios devem seguir a mesma estrutura:

  • Objetivo: o que será aprendido e por que isso é importante no IBM Z.

  • Conceitos COBOL equivalentes: comparação direta entre os conceitos de COBOL e Java.

  • Arquitetura: diagrama do fluxo da aplicação.

  • Pré-requisitos: softwares, datasets, tabelas DB2 ou configurações necessárias.

  • Passo a passo: instruções detalhadas de implementação.

  • Código comentado: explicando cada linha e sua função.

  • Compilação e execução: tanto no ambiente local quanto no z/OS, quando aplicável.

  • Análise dos resultados: como validar se tudo funcionou corretamente.

  • Desafios extras: exercícios para expandir o laboratório.

  • Solução completa: código-fonte, JCL, scripts Maven/Gradle, SQL e arquivos de configuração.

Competências desenvolvidas

Ao concluir os 20 laboratórios, o programador COBOL Junior terá desenvolvido competências para:

  • Escrever aplicações Java orientadas a objetos.

  • Compreender a execução da JVM no IBM Z.

  • Criar programas Batch em Java executados por JCL.

  • Desenvolver APIs REST com Spring Boot e WebSphere Liberty.

  • Integrar aplicações Java com programas COBOL via CICS e z/OS Connect.

  • Acessar tabelas DB2 utilizando JDBC e PreparedStatement.

  • Utilizar IBM MQ para comunicação assíncrona.

  • Trabalhar com USS (Unix System Services).

  • Automatizar builds e deploys com Maven, Git, Jenkins, Zowe e Ansible.

  • Entender o papel do LinuxONE, Docker e OpenShift na modernização do ecossistema IBM Z.

Resultado esperado

Ao final desse laboratório, o aluno deixará de enxergar Java como uma tecnologia "concorrente" do COBOL. Em vez disso, compreenderá como ambas as linguagens coexistem no IBM Z, cada uma exercendo um papel específico na arquitetura corporativa moderna. Esse conhecimento amplia significativamente as oportunidades profissionais e prepara o desenvolvedor para atuar em projetos de modernização, integração por APIs e DevOps, mantendo o COBOL como o coração das regras de negócio e o Java como a ponte entre o Mainframe e o restante do mundo.


quarta-feira, 28 de maio de 2025

Java no IBM Mainframe: Quando o Programador COBOL Descobre que a JVM Também Mora no z/OS

 

Bellacosa Mainframe e o java no mundo mainframe

☕ Um Café no Bellacosa Mainframe

Java no IBM Mainframe: Quando o Programador COBOL Descobre que a JVM Também Mora no z/OS

"O futuro do Mainframe nunca foi COBOL ou Java. Sempre foi COBOL e Java trabalhando juntos."


Durante muitos anos surgiu um mito que assustou milhares de programadores COBOL.

"O Java vai substituir o COBOL."

O tempo mostrou exatamente o contrário.

Hoje, praticamente todos os grandes bancos, seguradoras, operadoras de cartão, bolsas de valores e órgãos governamentais utilizam COBOL e Java lado a lado, cada um fazendo aquilo em que é melhor.

Na realidade, aprender Java não significa abandonar o COBOL.

Significa entender como funciona o restante do ecossistema moderno do IBM Z.

Se você é um programador COBOL Junior, este artigo é praticamente um mapa mostrando onde o Java entra na arquitetura Mainframe e por que ele pode transformar sua carreira.

Pegue seu café.

Hoje vamos conhecer um dos moradores mais importantes do IBM Z.


O dia em que o Java chegou ao Mainframe

Quando a Sun Microsystems lançou o Java em 1995, sua proposta era revolucionária.

Write Once, Run Anywhere.

Escreva uma vez.

Execute em qualquer lugar.

Enquanto isso, o Mainframe continuava executando milhões de linhas de COBOL.

A IBM rapidamente percebeu que aquela linguagem seria importante.

Ao invés de ignorá-la, fez algo típico da empresa:

levou o Java para dentro do z/OS.

Poucos anos depois surgiu a JVM para Mainframe.

Desde então, cada geração do IBM Z recebeu melhorias específicas para acelerar Java.

Hoje existem instruções de hardware dedicadas para execução da JVM.

Ou seja:

O Java não está "rodando emulado" no Mainframe.

Ele roda utilizando otimizações do próprio processador IBM Z.


Onde o Java aparece no Mainframe?

Muito mais lugares do que imaginamos.

Você provavelmente já utiliza sistemas Java sem perceber.

Exemplos:

  • Internet Banking

  • Aplicativos Mobile

  • APIs REST

  • Microserviços

  • IBM MQ

  • WebSphere Liberty

  • CICS Java

  • Batch Java

  • z/OS Connect

  • IBM Z Open Automation Utilities

  • Ansible

  • Jenkins

  • Zowe

  • Eclipse

  • IBM Developer for z/OS

  • Spring Boot para z/OS

Em muitos ambientes, o COBOL continua sendo o responsável pelas regras de negócio.

O Java apenas conversa com ele.


A arquitetura moderna

Imagine um banco.

Cliente
     │
Internet
     │
API REST
     │
Spring Boot
     │
z/OS Connect
     │
CICS
     │
Programa COBOL
     │
DB2

Perceba algo interessante.

O Java raramente substitui o COBOL.

Ele funciona como uma ponte.


Java Batch

Quando pensamos em Mainframe normalmente lembramos de processamento Batch.

A boa notícia é que Java também executa Batch.

Por exemplo:

Leitura de arquivos

↓

Validação

↓

Processamento

↓

Atualização DB2

↓

Geração de Relatórios

A execução ocorre através do JCL.

Exemplo simplificado:

//JAVAJOB JOB
//STEP01 EXEC PGM=JVMLDM86
//STDENV DD *
JAVA_HOME=/usr/lpp/java
CLASSPATH=/u/apps/meuapp.jar
/*

Na prática, o JCL prepara o ambiente.

Quem executa o processamento é a JVM.


Um pequeno programa Java

public class HelloMainframe {

    public static void main(String[] args){

        System.out.println("Olá IBM Z!");

    }

}

Compilação:

javac HelloMainframe.java

Execução:

java HelloMainframe

No z/OS funciona praticamente da mesma forma.

A diferença está no ambiente preparado pelo JCL.


Java Online

Agora imagine uma aplicação bancária.

O cliente faz um PIX.

O aplicativo envia uma requisição.

Essa requisição chega ao Mainframe.

Quem recebe?

Pode ser um programa Java.

Ou um serviço REST.

Depois disso:

Java

↓

CICS

↓

COBOL

↓

DB2

↓

Resposta JSON

Tudo ocorre em poucos milissegundos.


Java dentro do CICS

Muitos desenvolvedores não sabem.

O CICS executa programas Java.

Isso permite:

  • APIs REST

  • SOAP

  • JSON

  • XML

  • JMS

  • MQ

Tudo dentro do ambiente transacional.

O COBOL continua executando a lógica principal.

O Java cuida da integração.


Java e DB2

Uma das maiores vantagens do Java é sua integração com bancos relacionais.

O acesso normalmente ocorre através do JDBC.

Exemplo:

Connection conn =
DriverManager.getConnection(url,user,password);

PreparedStatement ps =
conn.prepareStatement(
"SELECT NOME FROM CLIENTES");

ResultSet rs = ps.executeQuery();

No Mainframe ocorre exatamente o mesmo conceito.

A diferença está no driver utilizado.

Normalmente utiliza-se o IBM Data Server Driver.


JDBC ou SQL Embutido?

Programadores COBOL costumam perguntar:

"Se existe SQL Embutido, por que usar JDBC?"

Porque são tecnologias diferentes.

COBOL

EXEC SQL
SELECT ...
END-EXEC

Java

PreparedStatement

O resultado final é semelhante.

Ambos acessam o DB2.


Vantagens do PreparedStatement

Nunca monte SQL concatenando Strings.

Ruim:

"SELECT * FROM CLIENTES WHERE ID="+id;

Correto:

PreparedStatement

Além de mais rápido, evita SQL Injection.


Java e Stored Procedures

Outra integração muito comum.

Java

↓

Stored Procedure DB2

↓

SQL

↓

Resultado

Muitos bancos utilizam esse modelo.


Java conversando com COBOL

Existem diversas formas.

Por exemplo:

  • CICS LINK

  • MQ

  • REST

  • SOAP

  • z/OS Connect

  • JNI

  • Arquivos

  • Stored Procedures

Na maioria dos projetos modernos, REST e MQ são os campeões.


Java e IBM MQ

Imagine dezenas de sistemas conversando.

Ao invés de chamadas diretas, utiliza-se filas.

Java

↓

MQ

↓

COBOL

Se o COBOL estiver ocupado...

A mensagem continua aguardando.

Isso aumenta a disponibilidade.


Java e z/OS Connect

Talvez esta seja a tecnologia que mais mudou o Mainframe.

Antes:

Aplicações externas precisavam conhecer CICS.

Hoje:

REST

↓

JSON

↓

z/OS Connect

↓

COBOL

Quem desenvolve a API geralmente utiliza Java.


WebSphere Liberty

O Liberty tornou-se praticamente o servidor Java padrão do IBM Z.

Leve.

Moderno.

Compatível com Jakarta EE.

Executa:

  • REST

  • MicroProfile

  • JWT

  • OAuth

  • OpenAPI

Tudo muito integrado ao z/OS.


Java e LinuxONE

Aqui surge uma dúvida.

LinuxONE é Mainframe?

Sim.

É a mesma arquitetura IBM Z.

A diferença é que executa Linux como sistema operacional principal.

Nesse ambiente podemos instalar:

  • Java

  • Spring Boot

  • Docker

  • Kubernetes

  • Kafka

  • PostgreSQL

  • MongoDB

  • Redis

Tudo rodando sobre hardware IBM.

É comum encontrar arquiteturas híbridas:

LinuxONE

↓

Java

↓

API

↓

MQ

↓

z/OS

↓

COBOL

Java e Containers

Hoje o Java roda perfeitamente em containers.

Exemplo:

Docker

↓

Java

↓

Spring Boot

No IBM Z isso normalmente acontece utilizando:

  • Red Hat OpenShift

  • Kubernetes

  • LinuxONE


Java e OpenShift

Imagine centenas de APIs.

Em vez de dezenas de servidores, utiliza-se OpenShift.

Cada API Java roda em um container.

Quando aumenta o acesso...

O OpenShift cria novos containers automaticamente.


Java e Ansible

Aqui está uma surpresa para muitos programadores COBOL.

O Ansible também administra aplicações Java.

Por exemplo:

  • Deploy

  • Atualização

  • Reinício

  • Configuração

  • Instalação

  • Coleta de logs

Tudo automatizado.

Um Playbook simples:

- hosts: zos

  tasks:

    - name: Reiniciar Liberty

      command: server stop liberty

    - name: Iniciar Liberty

      command: server start liberty

Java e Zowe

O Zowe aproximou muito o Mainframe do mundo Open Source.

Com ele podemos:

  • enviar JCL

  • consultar Jobs

  • acessar datasets

  • acessar USS

  • automatizar builds

Tudo usando JavaScript, Node.js ou Java.


Java e USS

O UNIX System Services é praticamente um Linux dentro do z/OS.

É nele que encontramos:

/usr/lpp/java

Ali estão instalados:

  • JVM

  • Bibliotecas

  • Ferramentas

  • Scripts

Grande parte das aplicações Java vive dentro do USS.


Java e Git

Hoje é comum encontrar projetos Java armazenados no GitHub.

Fluxo típico:

Git

↓

Jenkins

↓

Compilação

↓

Testes

↓

Deploy

↓

Liberty

Tudo automático.


Java e DevOps

Mainframe moderno faz DevOps.

Ferramentas comuns:

  • Git

  • GitHub

  • GitLab

  • Jenkins

  • UrbanCode Deploy

  • Ansible

  • Zowe CLI

  • Maven

  • Gradle

  • SonarQube


Maven

Quase todo projeto Java utiliza Maven.

Arquivo:

pom.xml

Ali ficam:

  • dependências

  • plugins

  • versão

  • compilação

É o equivalente ao gerenciamento de bibliotecas do projeto.


Gradle

Outro gerenciador bastante utilizado.

Mais flexível.

Mais rápido em projetos grandes.


Java e APIs REST

Hoje praticamente toda integração passa por APIs.

Exemplo simples:

GET

/clientes/123

Resposta:

{
 "id":123,
 "nome":"João"
}

Quem produz esse JSON?

Na maioria das vezes:

Java.

Quem consulta o DB2?

COBOL.


Curiosidades

Pouca gente sabe que:

  • O IBM Z possui otimizações específicas para Java.

  • Existe JIT Compiler dedicado.

  • A JVM recebe melhorias a cada geração do processador.

  • Grande parte das ferramentas IBM modernas utiliza Java.

  • O IBM Developer for z/OS é baseado em Eclipse, escrito em Java.

  • O IBM Installation Manager é Java.

  • Diversos componentes do IBM MQ possuem módulos Java.

  • O z/OS Explorer e o CICS Explorer também são baseados em Eclipse.

Ou seja...

Mesmo sem programar Java, você provavelmente já utiliza softwares escritos nessa linguagem todos os dias.


Dicas para quem vem do COBOL

1. Aprenda Orientação a Objetos

É a maior mudança de mentalidade.

COBOL organiza programas.

Java organiza objetos.


2. Domine Collections

Aprenda:

  • List

  • Set

  • Map

  • Queue

Você utilizará essas estruturas constantemente.


3. Entenda Exceptions

Em COBOL temos:

IF SQLCODE

Em Java temos:

try{

}
catch(Exception e){

}

É outra forma de tratar erros.


4. Não tenha medo do Garbage Collector

COBOL trabalha muito com controle explícito de memória.

Java possui coleta automática.

Isso reduz vazamentos de memória, mas exige entender como o Garbage Collector funciona para escrever aplicações eficientes.


5. Aprenda SQL antes de JDBC

Quem domina SQL aprende JDBC muito mais rapidamente.

O banco continua sendo o mesmo.


6. Conheça o ecossistema

Não estude apenas a linguagem.

Conheça também:

  • Spring Boot

  • Maven

  • Gradle

  • Git

  • Docker

  • OpenShift

  • Ansible

  • Zowe

  • Liberty

  • MQ

  • z/OS Connect


Um roteiro de estudos para o Programador COBOL Junior

Uma boa sequência é:

  1. Fundamentos da linguagem Java (variáveis, classes, objetos e herança).

  2. Coleções, exceções, entrada/saída e programação funcional com Streams.

  3. JDBC e acesso ao DB2.

  4. Maven ou Gradle para gerenciamento de dependências.

  5. Git e GitHub.

  6. Spring Boot e criação de APIs REST.

  7. IBM MQ para mensageria.

  8. WebSphere Liberty e implantação de aplicações Java no z/OS.

  9. z/OS Connect para expor programas COBOL como APIs.

  10. LinuxONE, Docker e OpenShift.

  11. Zowe CLI para integração com o ambiente Mainframe.

  12. Ansible para automação de deploy, configuração e administração.

Essa jornada amplia sua visão do ecossistema IBM Z e faz de você um profissional muito mais versátil.

O que muda na carreira?

Há vinte anos, um programador COBOL precisava conhecer principalmente JCL, CICS e DB2.

Hoje isso continua importante, mas o cenário mudou.

O profissional mais valorizado é aquele que entende o fluxo completo da aplicação:

  • O aplicativo móvel envia uma requisição.

  • Uma API Java recebe a chamada.

  • O z/OS Connect faz a integração.

  • O CICS executa a transação.

  • O COBOL aplica as regras de negócio.

  • O DB2 armazena e recupera os dados.

  • O MQ garante comunicação assíncrona quando necessário.

  • O Liberty hospeda os serviços.

  • O OpenShift escala os containers.

  • O Ansible automatiza o ambiente.

  • O Zowe integra tudo ao pipeline de DevOps.

Perceba que o COBOL continua no centro da operação. O Java amplia as possibilidades de integração, modernização e entrega contínua.

Conclusão

Existe uma frase muito conhecida no universo Mainframe:

"As regras de negócio ficam onde elas sempre estiveram; o que muda é a forma de acessá-las."

É exatamente isso que aconteceu com o Java no IBM Z.

Ele não chegou para substituir o COBOL, mas para conectar o Mainframe ao restante do mundo: aplicações web, dispositivos móveis, microsserviços, nuvem híbrida, APIs, automação e DevOps. Enquanto o COBOL continua executando com confiabilidade as transações críticas, o Java oferece a flexibilidade necessária para construir novas interfaces e integrar tecnologias modernas.

Para o programador COBOL Junior, aprender Java significa entender como as aplicações corporativas são construídas hoje. Você continuará valorizando conceitos clássicos como JCL, CICS, DB2 e VSAM, mas também passará a dominar ferramentas como Maven, Spring Boot, Liberty, MQ, Zowe, OpenShift e Ansible.

No fim das contas, o mercado não procura especialistas em uma única linguagem. Procura profissionais capazes de navegar por todo o ecossistema IBM Z. E, nesse ecossistema, COBOL e Java não são rivais — são parceiros que, juntos, mantêm funcionando alguns dos sistemas mais importantes do planeta.