Homens de Preto no Data Center — Quando o Agente J Encontrou uma GPU no LinuxONE e Perguntou: “Isso Aqui É CUDA ou o Igor Colou um RTX no PCIe?”

 

Bellacosa Mainframe e a possivel ponte em ibm z e nvidia sera????

☕ Um Café no Bellacosa Mainframe

Homens de Preto no Data Center — Quando o Agente J Encontrou uma GPU no LinuxONE e Perguntou: “Isso Aqui É CUDA ou o Igor Colou um RTX no PCIe?”

Ou: IBM colocou Arm dentro do futuro processador Z, NVIDIA já fala essa língua, o jovem padawan COBOL descobriu que uma placa gráfica não é um pendrive grande — e o Agente J precisou explicar DMA, IOMMU e LPAR antes que alguém chamasse o serviço de manutenção cósmica

---

Prólogo — uma luz estranha em Armonk

Agente J entrou na sala de máquinas com o Neuralyzer numa mão e um copo de café na outra.

— K, tem uma criatura de silício dizendo que o próximo IBM Z e LinuxONE pode executar Arm nativamente.

— Não a apague da memória, J. A IBM anunciou isso em 24 de agosto de 2026, durante o Hot Chips. É uma das notícias mais importantes para quem trabalha com mainframe desde que alguém resolveu chamar servidor de “legado” sem perceber que o legado estava pagando a conta do banco.

O anúncio descreve um futuro processador de dupla arquitetura para IBM Z e LinuxONE: em vez de haver um núcleo IBM de um lado e um núcleo Arm pendurado do outro, cada núcleo é projetado para executar instruções IBM e Arm de forma nativa. A meta é permitir ambientes Linux Arm ao lado de z/OS e do Linux que já vive em Z/LinuxONE. São planos de produto futuros, sujeitos a mudança; não existe, hoje, um menu da HMC com o botão “instalar CUDA e chamar a NVIDIA”. Mas o desenho muda a conversa inteira.

Para um programador COBOL iniciante, a notícia pode parecer distante. “Eu só quero meu READ, meu WRITE, um Db2 que não dê -911 e um CICS que não transforme a sexta-feira em incidente.” Justamente por isso ela importa. Mainframe não está virando PC gamer; está tentando deixar de ser uma ilha para uma parte maior da economia de software chegar perto daquilo que ele faz melhor: transações, dados críticos, disponibilidade e paranoia institucional bem aplicada.

Easter egg #1: o Agente J não disse “paranoia”. Ele disse “controle de acesso preventivo contra organismos com DMA”. O RACF aprovou a redação.

1. Primeiro: o que a IBM anunciou — e o que ela não anunciou

Vamos separar o café do conhaque.

A IBM anunciou uma direção arquitetural: processador futuro de 2 nm, 11 núcleos acima de 5,7 GHz, aceleradores de inferência e uma DPU de I/O no chip. O ponto realmente extraordinário é a implementação de AArch64/Arm em hardware, não por emulação. A IBM e a Arm dizem que a intenção é executar Linux Arm nativo simultaneamente com ambientes IBM tradicionais e herdar a escala, segurança e resiliência do Z/LinuxONE.

Ela não anunciou:

• uma GPU NVIDIA certificada para Z ou LinuxONE;

• CUDA em z/OS;

• um driver NVIDIA s390x;

• um DGX escondido dentro de um frame;

• compatibilidade automática com qualquer placa comprada numa promoção suspeita.

Essa distinção protege você de duas doenças profissionais: o entusiasmo que vende PowerPoint como produto e o ceticismo que chama de “marketing” qualquer coisa que ainda não chegou ao rack. A posição correta é mais interessante: existe agora uma ponte arquitetural plausível; atravessá-la exige engenharia, qualificação e acordo comercial.

2. Por que Arm muda o problema da NVIDIA

Historicamente, Linux no IBM Z usa a arquitetura s390x. É excelente no seu território, mas possui um custo invisível: cada fornecedor externo precisa decidir se mantém outra compilação, outro pipeline de testes, outro driver de kernel, outra equipe de suporte e outra matriz de versões para um mercado menor que x86 e Arm.

Imagine que você escreveu um programa COBOL para ler um arquivo VSAM. Não basta entregar o fonte a alguém: é preciso compilador, copybooks, JCL, permissões RACF, dataset correto, testes e alguém responsável quando o job abendar às 02h17. Com uma GPU é igual, só que o “copybook” envolve firmware, PCIe, memória, interrupções e DMA.

NVIDIA já mantém uma pilha madura para Linux AArch64: driver, CUDA Toolkit, compiladores, bibliotecas como cuDNN e NCCL, PyTorch, TensorFlow e uma multidão de aplicações que nasceram para Arm em nuvens e servidores. Grace, Graviton, Ampere e Cobalt ajudaram a transformar Arm server em destino comercial sério.

Assim, a pergunta deixa de ser “NVIDIA, você pode criar e sustentar s390x?” e passa a ser “IBM, o seu ambiente Arm parece suficientemente um servidor Arm convencional para a pilha existente funcionar e ser suportada?”.

É uma diferença brutal:

Problema antigo	Problema possível no novo cenário
Portar uma arquitetura inteira	Qualificar uma plataforma Arm
Criar cadeia de ferramentas	Reutilizar uma cadeia AArch64
Testar um mercado exótico	Testar uma variante enterprise de Arm
Manter driver específico s390x	Adaptar/validar driver Arm já existente

Não é garantia. É a troca de “construa uma estrada no oceano” por “a estrada chegou à fronteira; vamos inspecionar a ponte”.

3. Falar Arm não basta: o passaporte chamado SystemReady

Uma CPU saber executar instruções Arm é como o Agente J aprender um idioma alienígena. Útil, mas não informa em qual lado da rua ele deve dirigir, qual tomada existe no hotel ou se o passaporte abre a porta da alfândega.

Para Linux e drivers, o mundo abaixo da aplicação importa muito. Eles precisam reconhecer um ambiente previsível: firmware de boot, tabelas de hardware, relógios, controladores de interrupção, memória, PCIe, IOMMU, ACPI/UEFI e regras de descoberta de dispositivos. É isso que padrões como Arm SBSA, requisitos de boot e o programa Arm SystemReady tentam normalizar.

Relatos técnicos do Hot Chips indicam AArch64 v9.3, SVE/SVE2, operação little-endian do lado Arm e direção SystemReady. A consequência pretendida é preciosa: distribuições e binários Arm “de prateleira” teriam muito menos motivo para perguntar “que bicho é este?”. A própria NVIDIA construiu Grace mirando SBSA/SystemReady porque padrões reduzem o número de adaptações especiais que software precisa carregar.

Em linguagem de sala verde: SystemReady é a diferença entre receber um fonte COBOL e torcer para que compile, ou receber o fonte mais o padrão de dataset, o JCL, as PROCs, os parâmetros e a documentação de instalação. O primeiro funciona numa demo. O segundo tem chance de sobreviver à produção.

4. “Mas a GPU é PCIe; não é só encaixar?”

Não. E aqui o Agente J recolhe delicadamente a chave de fenda da mão do Igor.

PCIe é uma interconexão, não um contrato completo de convivência. A GPU precisa ser enumerada pelo sistema, expor regiões de memória mapeada (MMIO/BARs), gerar interrupções, ser reinicializada após falha, conversar com o driver e receber energia e refrigeração adequadas. O driver precisa enxergar topologia correta, páginas de memória, acesso DMA, recursos de virtualização e mecanismos de erro.

E uma GPU não fica esperando a CPU carregar cada byte como um garçom levando café de colher em colher. Ela usa DMA — Direct Memory Access. Simplificando, depois de autorizada, transfere dados diretamente entre sua memória e a memória do host. Isso é essencial para desempenho: modelos, tensores e lotes de inferência seriam ridiculamente lentos se cada movimento tivesse de passar pela CPU como um MOVE de bilhões de bytes.

No notebook de Igor, um driver malcomportado pode congelar a tela e produzir uma noite de palavrões. Em um LinuxONE, a máquina hospeda muitos clientes lógicos, com isolamento e disponibilidade que não podem depender de boa vontade de uma placa. Aí entra a IOMMU.

5. IOMMU: o segurança que não deixa a GPU passear pelo prédio

IOMMU significa, em essência, unidade que traduz e controla endereços de memória usados por dispositivos de I/O. Pense nela como o segurança de um edifício bancário. A GPU do LPAR A recebeu autorização para entrar na sala A-17; isso não lhe dá licença para testar todas as portas do corredor, muito menos alcançar a memória do LPAR B ou do ambiente de gestão.

Uma configuração segura precisa associar dispositivo, função virtual, LPAR e faixas de memória de maneira estrita. O driver pede uma operação; hardware e firmware garantem que o dispositivo veja apenas o que lhe foi atribuído. A ideia se parece com RACF: autenticar o usuário é apenas o começo; é a autorização de cada recurso que impede o desastre.

Mas atenção: “há IOMMU” não é uma frase mágica. Drivers NVIDIA têm requisitos e particularidades conforme GPU, kernel, topologia PCIe e virtualização. Há recursos de alta performance, como comunicação direta entre GPU e NIC, que podem depender de decisões de ACS, peer-to-peer e posicionamento físico. Em outras palavras: a placa pode funcionar para inferência simples e ainda não estar pronta para cada truque de HPC, NVLink ou multi-GPU.

6. LPAR, z/VM e a diferença entre dividir e bagunçar

Um LPAR é uma partição lógica: uma máquina dentro da máquina, separada por hardware e firmware. Para o iniciante, compare-o a uma região CICS muito séria, com seu próprio universo operacional — só que o isolamento não é mera convenção de software.

O caminho inicial mais sensato seria algo parecido com isto:

1. A IBM certifica um modelo específico de GPU e o respectivo drawer PCIe.

2. A HMC/firmware atribui a função física ou virtual a uma LPAR Arm Linux.

3. Esse Linux vê um dispositivo PCIe compatível, carrega driver NVIDIA Arm64 e o CUDA runtime.

4. O aplicativo usa a GPU; o IOMMU restringe o DMA à memória autorizada.

5. Telemetria, manutenção, falhas e troca de peça entram no modelo operacional IBM.

O primeiro alvo não precisa ser compartilhar uma placa com trinta tenants. Pass-through para uma LPAR, bem cercado, já seria uma vitória enorme. Depois vêm os chefes de fase: MIG, vGPU, SR-IOV, cobrança, reset seletivo, migração, isolamento multi-tenant e recuperação automática.

7. Spyre: o precedente que ajuda, sem virar atalho enganoso

A IBM já vende o Spyre Accelerator para z17 e LinuxONE Emperor 5. É uma placa PCIe orientada a inferência e fine-tuning, com runtime, driver, firmware e integração de software próprios. A solução suporta até 48 placas em sistemas Z/LinuxONE e foi desenhada com appliances de suporte, funções virtuais, monitoramento e redundância de caminhos.

Isso importa porque prova uma coisa concreta: IBM não está começando agora a discutir “como colocar um acelerador poderoso, que faz DMA, num mainframe particionado sem transformar o equipamento numa lan house cósmica”. Ela já tem práticas para atribuição, saúde do dispositivo, tolerância a falha e operação.

Mas Spyre não é uma GPU NVIDIA pintada de azul. Ele é uma solução vertical: IBM controla hardware, firmware, compilador, runtime e o suporte. CUDA traria outro ecossistema, outra cadência de drivers e outra responsabilidade dividida. Spyre diminui o risco de integração; não elimina a negociação com NVIDIA.

8. Telum, Spyre e CUDA não são três nomes para a mesma coisa

Tecnologia	Onde brilha	Exemplo
Telum	Inferência muito próxima da transação	Pontuar fraude durante a autorização
Spyre	IA empresarial integrada e eficiente	Servir modelos e fine-tuning controlado
GPU NVIDIA/CUDA	Ecossistema amplo e computação acelerada	PyTorch, visão, LLMs, analytics e bibliotecas CUDA

O desenho vencedor não é substituir um pelo outro. É usar cada peça onde tem vocação.

Uma transação chega pelo CICS. O programa COBOL executa regras, chama Db2 e precisa decidir agora: aprovar, bloquear ou pedir segundo fator. Telum pode atender a inferência ultrarrápida. Um serviço Arm Linux pode, assíncronamente ou numa etapa apropriada, executar análise mais pesada em CUDA: enriquecer evento, correlacionar fraude, gerar explicação para analista, fazer busca vetorial, analisar imagens de documento ou retreinar um modelo.

O COBOL não precisa aprender CUDA para participar. Ele precisa aprender a pedir serviço de forma confiável: API, MQ, eventos, timeouts, idempotência, commit e rollback. O padawan que entende isso não vira passageiro do futuro; vira o adulto na sala quando alguém propõe chamar um modelo de 70 bilhões de parâmetros no meio de uma transação de 80 milissegundos.

Easter egg #2: o Agente J proibiu CALL 'CHATGPT' dentro do caminho crítico. Igor perguntou se ao menos poderia fazer um GOTO 9999 para o modelo. O Agente K desligou o monitor.

9. O inimigo físico: potência, calor e topologia

É tentador imaginar oito B200 surgindo de um drawer como alienígenas de um ovo. Só que uma GPU de datacenter de ponta pode consumir centenas de watts; sistemas HGX/NVSwitch exigem potência, refrigeração, espaço e rede próprios. NVLink não é “PCIe com café forte”.

Portanto, mesmo que CUDA se torne viável, o primeiro produto provável seria uma GPU PCIe específica e homologada para inferência ou aceleração selecionada, entregue a uma LPAR Arm. Um superpod para treinar modelo de fronteira provavelmente continuará sendo infraestrutura dedicada, conectada ao Z/LinuxONE por rede rápida e governada como outro domínio.

Mainframe não precisa vencer um DGX no campeonato errado. O valor está em reduzir a distância entre dado crítico, transação, segurança e capacidade de IA — sem copiar meio banco para uma plataforma externa só para fazer uma pergunta ao modelo.

10. Roteiro prático para o programador COBOL iniciante

Você não precisa comprar uma GPU nem decorar registradores Arm amanhã. Faça esta trilha:

1. Domine transação. Entenda CICS, Db2, VSAM, unidade de trabalho, syncpoint, COMMIT e ROLLBACK. IA sem integridade transacional é Igor vendendo PIX por e-mail.

2. Aprenda a fronteira. Veja JSON, HTTP, APIs REST, MQ e eventos. Seu COBOL continuará sendo o coração de muitos processos; ele precisa conversar sem acoplamento burro.

3. Conheça Linux e containers. Não para abandonar Z, mas para entender onde os serviços Arm e IA vão viver. Um container não é uma LPAR; ambos isolam, mas em níveis diferentes.

4. Entenda os quatro D’s. Dados, DMA, dispositivos e dependências. Pergunte sempre: onde o dado nasce, quem pode movê-lo, quem o enxerga e como o processo se recupera?

5. Aprenda observabilidade. Latência, throughput, erro, saturação, logs e rastreamento. “A IA ficou lenta” não é diagnóstico; é o equivalente moderno a “deu ABEND”.

6. Pense em governança. Modelo pode errar, vazar, enviesar e mudar. Dados bancários ou pessoais não ganham permissão para viajar só porque a demo ficou bonita.

11. As perguntas que realmente importam agora

Quando surgirem detalhes, não pergunte primeiro “quantos teraflops?”. Pergunte:

• Qual nível de certificação SystemReady a IBM entregará?

• Quais distribuições Arm bootam sem alteração?

• Como PCIe e IOMMU aparecem para a LPAR Arm?

• Haverá GPU pass-through? Virtualização? MIG/vGPU?

• Quais modelos, drivers e versões CUDA serão homologados?

• Como são feitos reset, firmware update, diagnóstico e failover?

• Qual é a latência entre o dado em z/OS/Db2 e o serviço acelerado?

• O caso de uso justifica trazer a IA para perto, ou MQ/API para infraestrutura externa já resolve melhor?

Essas perguntas são mais maduras que “roda Doom?”. Embora, em nome da ciência, o Agente J tenha anotado a segunda numa planilha confidencial.

Epílogo — a ponte não é o destino

A IBM não entregou CUDA no mainframe em agosto de 2026. Entregou algo talvez mais estratégico: uma tentativa de tornar o próximo Z/LinuxONE um anfitrião Arm suficientemente padrão para que ecossistemas já existentes possam reconhecê-lo.

Para NVIDIA, isso pode converter um port caro e exclusivo para s390x em uma qualificação de plataforma Arm. Para IBM, é uma maneira ousada de reduzir o isolamento histórico de sua arquitetura. Para clientes, pode significar aproximar software moderno e aceleradores dos dados mais críticos sem abandonar as qualidades que fizeram o mainframe sobreviver a cada funeral prematuro anunciado desde os anos 1980.

E para nós, do COBOL, a lição é confortavelmente simples: o futuro não exige que você esqueça o que sabe. Exige que você entenda onde seu programa termina, onde o serviço começa, como o dado atravessa a fronteira e quem responde quando a GPU, o driver ou o universo resolve dar ABEND.

O Agente K guardou o Neuralyzer.

— Então não apagamos a memória do anúncio?

— Não, J. Só colocamos uma nota no rodapé: “promissor, tecnicamente difícil, comercialmente aberto e absolutamente incapaz de ser instalado pelo Igor numa sexta-feira às 17h58”.

E, por uma vez, até o RACF concordou.

---

Fontes para continuar a investigação

• IBM — anúncio do processador dual-architecture, 24 de agosto de 2026

• Arm — contexto da colaboração com IBM

• NVIDIA — Grace e padrões SBSA/SystemReady

• IBM — arquitetura operacional do Spyre Accelerator

• IBM Research — construção e software do Spyre

 

Bellacosa Mainframe apresenta o bootcamp DIO da IBM e seu agente BOB

👋 Boas-vindas ao IBM Bob Bootcamp

IA de Nível Empresarial para Desenvolvedores e Tech Leaders

Olá, pessoal!

Meu nome é Vagner Bellacosa, sou Analista de Sistemas IBM Mainframe, IBM Champion e, acima de tudo, um apaixonado por tecnologia, compartilhamento de conhecimento e aquele tradicional café que acompanha toda boa sessão de aprendizado.

É um enorme prazer fazer parte desta turma do IBM Bob Bootcamp.

Vivemos um momento raro na história da computação. Durante décadas ouvimos que a Inteligência Artificial era "o futuro". Pois bem... o futuro resolveu aparecer mais cedo do que imaginávamos, bater na porta e perguntar:

"Posso ajudar no seu código?"

A resposta, obviamente, foi:

"Pode... mas primeiro passa pelo Code Review!" 😄

---

Afinal... o que estamos fazendo aqui?

Estamos reunidos porque entendemos que IA não é moda.

É ferramenta.

É produtividade.

É aceleração.

É uma nova forma de pensar soluções.

Se você desenvolve software, administra ambientes, lidera equipes ou trabalha com arquitetura, provavelmente percebeu que a pergunta deixou de ser:

"Vou usar IA?"

e passou a ser

"Como posso utilizá-la melhor que os outros?"

---

Um recado para quem vem do Mainframe

Eu sou suspeito para falar...

Venho do universo IBM Z, COBOL, CICS, Db2 e z/OS.

Aquele ambiente que muitos juram que é "velho"...

...até descobrirem que movimenta boa parte do dinheiro do planeta.

Então, quando alguém pergunta:

"Mainframe combina com Inteligência Artificial?"

Minha resposta é sempre:

Combina tanto quanto café combina com madrugada de implantação.

Ou seja...

É praticamente obrigatório. ☕😂

Hoje a IA conversa com APIs REST, z/OS Connect, Watsonx, OpenShift, GitHub Copilot, Assistentes Inteligentes e, cada vez mais, com aplicações corporativas que executam justamente em IBM Z.

---

Minha expectativa

Espero aprender muito com todos vocês.

Cada participante chega com experiências diferentes.

Uns dominam Cloud.

Outros conhecem Kubernetes.

Alguns vivem em Java, Python ou JavaScript.

Outros, como eu, passaram anos escrevendo COBOL e fazendo milhões de transações passarem silenciosamente por um Data Center.

No fim das contas...

Todos estamos aprendendo a conversar com uma nova ferramenta.

E isso é fantástico.

---

Minha filosofia

Sempre gostei de uma frase simples:

Quem compartilha conhecimento nunca perde espaço; cria novos lugares para todos crescerem.

Então contem comigo durante o Bootcamp.

Se eu puder ajudar em alguma dúvida, trocar experiências ou simplesmente conversar sobre tecnologia, será um prazer.

---

Um pequeno aviso (com humor Bellacosa)

Caso durante o Bootcamp você apresente algum dos sintomas abaixo...

• conversar com IA como se fosse um colega de equipe;

• pedir para o Copilot escrever aquele método "rapidinho";

• descobrir que um prompt bem escrito vale mais que cinquenta pesquisas;

• começar a enxergar automação em absolutamente tudo;

...não se preocupe.

É perfeitamente normal.

Os efeitos costumam ser irreversíveis. 😄

---

https://web.dio.me/track/ibm-bob-ia-nivel-empresarial-para-desenvolvedores?

Boa sorte a todos!

Que este Bootcamp seja uma excelente oportunidade para aprender, compartilhar experiências, fazer novas amizades e descobrir como utilizar a Inteligência Artificial de forma prática e responsável.

Como diria o Bellacosa Mainframe:

"Prepare o café, abra a mente e mantenha o Git atualizado. Porque a IA pode até sugerir o código... mas a responsabilidade pelo commit continua sendo nossa!"

Nos vemos durante o Bootcamp!

☕🤖🚀

IBM: Uma Odisseia de 1911 à Inteligência Artificial Quando um Programador COBOL Descobre que o Mainframe Não é um Monólito Esquecido,

 

Bellacosa Mainframe e uma odisseia da IBM

☕ Um Café no Bellacosa Mainframe

IBM: Uma Odisseia de 1911 à Inteligência Artificial

Quando um Programador COBOL Descobre que o Mainframe Não é um Monólito Esquecido, mas o Computador de Bordo de uma Civilização Digital

No princípio, não havia nuvem.

Não havia Kubernetes, APIs REST, modelos fundacionais, agentes de inteligência artificial ou pipelines de integração contínua. Não existiam smartphones, redes sociais nem reuniões em que alguém dissesse, com absoluta convicção, que bastava “colocar tudo na cloud”.

Havia papel.

Havia engrenagens.

Havia cartões perfurados.

Havia máquinas eletromecânicas que contavam, classificavam e registravam informações com uma disciplina quase alienígena para uma sociedade que ainda descobria como administrar grandes volumes de dados.

Em 1911, diferentes empresas de tecnologia de registro e processamento foram reunidas em uma organização que, alguns anos depois, adotaria o nome International Business Machines: IBM.

Mais de um século se passou.

A humanidade pousou na Lua, construiu redes globais, criou computadores de bolso, armazenou bilhões de documentos em centros de dados e começou a conversar com inteligências artificiais. Durante todo esse percurso, a IBM não permaneceu imóvel como um artefato abandonado em órbita.

Ela se transformou.

Mudou de máquinas de tabulação para computadores eletrônicos. De computadores isolados para famílias compatíveis. De hardware para software. De software para serviços. De serviços para consultoria. De data centers fechados para nuvem híbrida. De sistemas determinísticos para inteligência artificial empresarial.

E, no centro dessa odisseia, permanece uma plataforma que muitos consideraram antiga, mas que continua processando algumas das operações mais importantes da civilização moderna:

o mainframe IBM Z.

Para um programador COBOL iniciante, compreender o chamado “Império IBM” é perceber que seu programa não vive sozinho dentro de uma tela verde. Ele faz parte de uma nave gigantesca, composta por infraestrutura, sistemas operacionais, bancos de dados, mensageria, segurança, automação, nuvem híbrida, consultoria e inteligência artificial.

Aperte os cintos.

O café está servido.

A viagem vai começar.

---

Capítulo I — O monólito de 1911

Imagine um jovem programador observando um enorme monólito negro.

Ele não sabe exatamente para que serve. Apenas percebe que aquela estrutura representa alguma coisa antiga, poderosa e fundamental.

A IBM ocupa posição semelhante na história da computação.

Ela não inventou todos os computadores, todas as linguagens ou todos os sistemas operacionais. Entretanto, participou de algumas das mudanças que definiram como a computação empresarial seria construída.

Antes dos computadores eletrônicos, grandes organizações precisavam processar censos, folhas de pagamento, estoques, seguros e registros financeiros. Fazer isso manualmente exigia milhares de pessoas e produzia atrasos gigantescos.

As máquinas de tabulação ajudaram a mecanizar esse trabalho.

Os dados eram representados por perfurações em cartões. Cada posição do cartão possuía significado. Um furo poderia representar um número, uma letra ou uma categoria.

Para um programador COBOL, esse detalhe histórico não é apenas uma curiosidade.

A preocupação quase obsessiva do mainframe com formatos, posições e estruturas de dados nasceu nesse universo. Quando você encontra um arquivo com registros de comprimento fixo, campos posicionais e códigos cuidadosamente definidos, está vendo uma descendência direta daquela forma de processamento.

Um registro como:

00012345VAGNER BELLACOSA        00000125000A

pode parecer primitivo, mas carrega uma filosofia poderosa:

• cada campo possui posição definida;

• cada byte possui significado;

• cada registro segue um contrato;

• qualquer desvio pode ser detectado.

No COBOL, essa estrutura poderia ser descrita assim:

01  REGISTRO-CLIENTE.
    05 CLIENTE-ID          PIC 9(8).
    05 CLIENTE-NOME        PIC X(25).
    05 CLIENTE-SALDO       PIC 9(9)V99.
    05 CLIENTE-STATUS      PIC X.

Não é apenas uma declaração de variáveis.

É o mapa estrutural de uma informação de negócio.

O primeiro ensinamento da odisseia IBM é este:

Antes de existir inteligência artificial, já existia a necessidade de representar corretamente a realidade.

---

Capítulo II — O System/360 e a grande mudança de órbita

Durante os primeiros anos da computação eletrônica, muitos computadores eram incompatíveis entre si.

Uma empresa comprava uma máquina. Depois, ao adquirir um modelo maior, descobria que seus programas precisavam ser reescritos. O hardware, o sistema operacional, os dispositivos e os formatos podiam mudar completamente.

Era como construir uma nave cuja tripulação precisasse reaprender todas as operações sempre que o motor fosse substituído.

Em 1964, a IBM apresentou o System/360.

O nome não era casual. A ideia era oferecer uma família de computadores capaz de atender a um círculo completo de necessidades empresariais e científicas.

Modelos menores e maiores deveriam compartilhar princípios arquitetônicos. O cliente poderia crescer sem abandonar todo o seu investimento em software.

Essa foi uma mudança profunda.

O valor já não estava apenas na máquina. Estava na compatibilidade, na continuidade e no ecossistema.

Para o programador COBOL iniciante, isso explica por que aplicações escritas décadas atrás ainda podem continuar relevantes. Elas não sobreviveram por acidente. Sobreviveram porque foram construídas em uma plataforma que valoriza compatibilidade.

Isso não significa que o mesmo executável de 1965 esteja rodando sem alterações em 2026. Significa que a arquitetura evoluiu tentando preservar investimentos, linguagens, dados e comportamentos.

O COBOL foi padronizado no final dos anos 1950 e se tornou uma linguagem fundamental para aplicações comerciais. Sua sintaxe foi pensada para expressar regras empresariais de forma relativamente legível:

IF SALDO-DISPONIVEL >= VALOR-SOLICITADO
    PERFORM AUTORIZAR-TRANSACAO
ELSE
    PERFORM RECUSAR-TRANSACAO
END-IF

Esse código não descreve pixels, animações ou jogos.

Ele descreve uma decisão de negócio.

É por isso que COBOL permaneceu importante em bancos, seguradoras, governos, indústrias e grandes corporações. O coração dessas organizações não é composto apenas por telas modernas. É composto por regras.

Quem pode receber?

Quanto deve pagar?

Qual contrato está vigente?

Qual taxa será aplicada?

A transação é válida?

O COBOL vive onde a organização transforma regras em execução.

---

Capítulo III — IBM Z: o computador de bordo da economia

Na imagem do “Império IBM”, a área de infraestrutura apresenta IBM Z, Power Systems, Storage e software z/OS.

Para quem está começando, é comum pensar que IBM Z é apenas um servidor muito grande.

Essa definição é insuficiente.

O IBM Z é uma plataforma desenvolvida para cargas de trabalho empresariais críticas. Seu objetivo não é somente executar programas rapidamente. É executar volumes gigantescos de trabalho com segurança, previsibilidade, isolamento e alta disponibilidade.

Pense em um banco durante um dia comum.

Milhões de clientes:

• consultam saldos;

• usam cartões;

• fazem transferências;

• pagam contas;

• recebem salários;

• sacam dinheiro;

• contratam empréstimos;

• acessam aplicativos;

• realizam operações empresariais.

Cada ação pode atravessar diferentes componentes.

Uma transferência, por exemplo, pode envolver:

1. autenticação do usuário;

2. validação da conta;

3. verificação de saldo;

4. análise de limites;

5. prevenção contra fraude;

6. registro contábil;

7. atualização de dados;

8. geração de mensagens;

9. auditoria;

10. comunicação com outros sistemas.

Tudo isso precisa acontecer sem duplicar valores, perder registros ou deixar o saldo em estado inconsistente.

Em um sistema crítico, “quase correto” é completamente errado.

O papel do z/OS

O z/OS é o principal sistema operacional da plataforma IBM Z.

Mas chamá-lo apenas de sistema operacional também simplifica demais sua função. Ele coordena um vasto ecossistema de processamento.

Dentro dele encontramos tecnologias como:

• JES2, responsável pelo gerenciamento de trabalhos batch;

• CICS, voltado ao processamento transacional online;

• Db2, banco de dados relacional;

• IMS, plataforma transacional e banco hierárquico;

• IBM MQ, mensageria confiável;

• RACF, segurança e controle de acesso;

• DFSMS, gerenciamento de armazenamento;

• WLM, gerenciamento inteligente de cargas;

• SMF, registros de atividade e auditoria;

• USS, ambiente UNIX dentro do z/OS.

Cada componente é como um subsistema da nave.

O programador COBOL normalmente não controla tudo isso diretamente, mas seu programa interage com essas áreas.

Um batch COBOL pode ser iniciado por JCL, ler um arquivo VSAM, consultar uma tabela Db2, produzir um relatório e gerar informações para outra aplicação.

Um programa online pode ser chamado pelo CICS, receber uma solicitação, consultar dados e responder em frações de segundo.

---

Capítulo IV — Batch e CICS: os dois ritmos da nave

No mainframe, dois modelos de processamento aparecem frequentemente: batch e online.

Processamento batch

Batch é o processamento de conjuntos de trabalhos.

Imagine o fechamento financeiro de uma empresa. Durante a noite, milhares de registros precisam ser consolidados. Juros devem ser calculados, extratos produzidos e arquivos enviados.

Um JCL poderia iniciar o programa:

//FECHAMENTO JOB (ACCT),'BELLACOSA',CLASS=A,MSGCLASS=X
//STEP01     EXEC PGM=CBLFECHA
//ENTRADA    DD DSN=BANCO.MOVIMENTO.DIARIO,DISP=SHR
//SAIDA      DD DSN=BANCO.RELATORIO.FECHAMENTO,
//              DISP=(NEW,CATLG,DELETE),
//              SPACE=(CYL,(10,5)),
//              DCB=(RECFM=FB,LRECL=200,BLKSIZE=0)
//SYSOUT     DD SYSOUT=*

Aqui, cada declaração ajuda o sistema a localizar programas, arquivos e saídas.

O batch é excelente para processar grandes volumes de forma controlada.

Processamento online com CICS

Já o CICS trabalha com transações interativas.

Quando um cliente consulta uma conta, não pode esperar o fechamento noturno. A resposta precisa ocorrer imediatamente.

O CICS gerencia:

• execução de transações;

• concorrência;

• comunicação;

• recuperação;

• recursos;

• controle de tarefas;

• integração com bancos e filas.

Para o iniciante, a diferença essencial é:

• o batch processa conjuntos de trabalho;

• o CICS responde a solicitações individuais em tempo quase imediato.

A organização moderna precisa dos dois.

O online recebe os eventos do dia.

O batch consolida, reconcilia, calcula e fecha os ciclos.

---

Capítulo V — O IBM Z não está sozinho no espaço

Um dos grandes equívocos sobre mainframes é imaginar que eles ficam isolados em uma sala, comunicando-se apenas com terminais antigos.

Isso não corresponde à realidade atual.

Aplicações COBOL podem participar de arquiteturas modernas por meio de APIs, mensageria, eventos, integração com nuvem e automação.

z/OS Connect

O z/OS Connect permite expor ativos do mainframe como APIs REST e também facilitar o consumo de serviços externos.

Imagine que uma empresa possui um programa COBOL confiável para calcular condições de financiamento.

Em vez de reescrever toda a regra em outra linguagem, a organização pode disponibilizá-la por meio de uma API.

Um aplicativo móvel envia:

{
  "cliente": 123456,
  "valor": 50000,
  "parcelas": 48
}

A camada de integração transforma a solicitação, chama o programa no mainframe e devolve uma resposta:

{
  "aprovado": true,
  "taxa": 1.79,
  "valorParcela": 1548.32
}

O usuário vê um aplicativo moderno.

Por trás da interface, o cálculo pode ser realizado por uma regra COBOL testada durante anos.

Modernização, portanto, não significa obrigatoriamente apagar o passado. Significa tornar ativos existentes acessíveis, governáveis e integrados.

IBM MQ

O IBM MQ permite a troca confiável de mensagens entre aplicações.

Em vez de o sistema A depender de uma resposta instantânea do sistema B, ele pode colocar uma mensagem em uma fila.

Por exemplo:

PEDIDO DE PAGAMENTO
        |
        V
FILA MQ
        |
        V
PROCESSADOR COBOL
        |
        V
FILA DE RESULTADO

Se o processador estiver temporariamente indisponível, a mensagem pode permanecer na fila até ser tratada.

Isso reduz acoplamento e aumenta resiliência.

---

Capítulo VI — Red Hat: o corredor entre mundos

A aquisição da Red Hat representou uma mudança estratégica na trajetória da IBM.

A IBM percebeu que o futuro empresarial não estaria em uma única nuvem ou em um único data center.

As organizações teriam ambientes mistos:

• mainframes;

• servidores distribuídos;

• nuvens públicas;

• nuvens privadas;

• sistemas de borda;

• aplicações antigas;

• microsserviços;

• contêineres.

Esse cenário é chamado de nuvem híbrida.

Red Hat Enterprise Linux

O Red Hat Enterprise Linux fornece uma base Linux corporativa para aplicações empresariais.

Linux também pode ser executado em plataformas IBM Z, permitindo que workloads Linux convivam próximos aos dados e serviços do mainframe.

OpenShift

O OpenShift é uma plataforma empresarial baseada em Kubernetes.

Kubernetes orquestra contêineres. Ele ajuda a distribuir, reiniciar, escalar e gerenciar aplicações.

O OpenShift acrescenta recursos corporativos de:

• segurança;

• desenvolvimento;

• operação;

• observabilidade;

• automação;

• governança;

• integração.

Imagine uma aplicação de seguros.

O cálculo central permanece em COBOL no z/OS.

Uma camada Java executa no OpenShift.

Um aplicativo web utiliza JavaScript.

Um modelo de IA analisa documentos.

O IBM MQ integra etapas assíncronas.

Tudo isso compõe uma única solução de negócio.

Ansible Automation Platform

O Ansible automatiza tarefas operacionais.

Em vez de um profissional realizar manualmente dezenas de comandos, um playbook descreve o estado desejado.

Exemplo conceitual:

- name: Implantar aplicação COBOL
  hosts: zos
  tasks:
    - name: Copiar fonte
      zos_copy:
        src: programa.cbl
        dest: USER.COBOL.SOURCE(PROGRAMA)

    - name: Executar compilação
      zos_job_submit:
        src: USER.JCL(COMPILA)
        location: DATA_SET
        wait_time_s: 120

O valor não está apenas em economizar digitação.

A automação oferece repetibilidade.

O mesmo procedimento pode ser executado em desenvolvimento, teste e produção, respeitando controles e aprovações.

É como substituir uma sequência improvisada de botões por um protocolo de voo documentado.

---

Capítulo VII — watsonx: quando a nave começa a conversar

A inteligência artificial se tornou uma das grandes prioridades da IBM.

O watsonx representa uma plataforma voltada à criação, operação e governança de soluções de IA empresarial.

O ponto mais importante é a palavra empresarial.

Uma demonstração de IA pode gerar um poema ou resumir um texto. Uma IA usada por um banco precisa atender outras exigências:

• proteger dados;

• explicar decisões;

• registrar versões;

• controlar acessos;

• evitar vazamento de informações;

• monitorar resultados;

• respeitar regulamentações;

• identificar desvios;

• permitir auditoria.

IA generativa no ambiente corporativo

Imagine uma equipe de suporte mainframe.

Durante um incidente, ela recebe:

• mensagens de ABEND;

• logs do JES;

• registros do CICS;

• consultas Db2;

• documentação operacional;

• históricos de incidentes.

Uma solução com IA poderia reunir esses materiais e ajudar a responder:

• Qual componente provavelmente falhou?

• Já ocorreu incidente semelhante?

• Qual procedimento foi usado?

• Quais riscos existem?

• Quem deve ser acionado?

A IA não deveria executar mudanças críticas sem controles. Ela atuaria como copiloto.

E aqui encontramos um belo paralelo com 2001: Uma Odisseia no Espaço.

Um sistema inteligente pode ser extremamente útil, mas precisa possuir objetivos claros, governança e limites.

O problema não é somente construir uma máquina capaz de responder.

É garantir que ela responda dentro das regras da missão.

Easter egg nº 1

Em vez de perguntar:

“HAL, abra a porta do compartimento.”

O operador mainframe talvez diga:

“RACF, autorize o acesso ao dataset.”

E o RACF responderá, metaforicamente:

“Sinto muito, operador. Seu usuário não possui a permissão necessária.”

Diferentemente do cinema, essa recusa é uma excelente notícia.

---

Capítulo VIII — Apptio: quanto custa manter a nave em órbita?

Em grandes organizações, tecnologia envolve custos difíceis de compreender.

Uma aplicação pode utilizar:

• processamento de mainframe;

• armazenamento;

• licenças;

• nuvem pública;

• clusters OpenShift;

• serviços de consultoria;

• suporte;

• redes;

• bancos de dados.

A Apptio ajuda a relacionar despesas tecnológicas com serviços e resultados empresariais.

Considere uma aplicação de cartões.

O gestor deseja saber:

• Quanto custa processar cada transação?

• Qual ambiente consome mais recursos?

• A migração reduziu custos?

• O crescimento de consumo corresponde ao crescimento do negócio?

• Qual produto utiliza determinada infraestrutura?

Sem visibilidade financeira, a empresa pode tomar decisões ruins.

Ela pode tentar remover um sistema considerado caro e descobrir tarde demais que ele processava milhões de operações com eficiência.

Custo absoluto não é suficiente.

É preciso avaliar custo por unidade de trabalho, risco, disponibilidade, segurança e impacto empresarial.

Um mainframe pode parecer caro como equipamento, mas ser competitivo quando analisado pelo volume de transações, pela consolidação e pela confiabilidade oferecida.

---

Capítulo IX — IBM Consulting: os arquitetos da missão

Tecnologia sozinha não transforma uma empresa.

Comprar servidores, contratar uma nuvem ou instalar uma plataforma de IA não resolve automaticamente processos ruins.

É aí que entra a IBM Consulting.

Ela trabalha com estratégia, transformação de negócios, implantação tecnológica e operações.

Imagine uma seguradora com centenas de sistemas.

A direção quer permitir que um sinistro seja analisado em minutos.

O problema não será resolvido apenas com um novo aplicativo.

Será necessário entender:

1. como o processo funciona hoje;

2. quais departamentos participam;

3. quais dados são necessários;

4. quais sistemas contêm esses dados;

5. quais regras devem ser preservadas;

6. quais etapas podem ser automatizadas;

7. onde a IA pode ajudar;

8. quais decisões exigem revisão humana;

9. como monitorar erros;

10. como medir o resultado.

A consultoria ajuda a organizar essa jornada.

Depois, especialistas podem implementar:

• integrações;

• APIs;

• plataformas;

• automações;

• modelos de dados;

• processos operacionais;

• controles de segurança.

Para um programador COBOL, isso ensina que uma alteração de código nunca existe isoladamente.

A solicitação “adicione um campo” pode envolver:

• copybooks;

• arquivos;

• telas;

• tabelas;

• relatórios;

• interfaces;

• mensagens;

• programas consumidores;

• documentação;

• testes;

• auditoria.

O código é apenas uma parte da missão.

---

Capítulo X — IBM Research e Quantum: o próximo monólito

A IBM mantém uma longa tradição de pesquisa.

Nem toda pesquisa produz um produto imediato. Algumas investigações levam anos até se tornarem úteis comercialmente.

É nesse ambiente que aparecem avanços relacionados a:

• semicondutores;

• materiais;

• armazenamento;

• inteligência artificial;

• criptografia;

• computação quântica.

Computação quântica

Computadores quânticos não são mainframes mais rápidos.

Eles operam com princípios diferentes e são estudados para categorias específicas de problemas.

Possíveis áreas de aplicação incluem:

• simulação molecular;

• descoberta de materiais;

• otimização;

• pesquisa científica;

• problemas matemáticos especializados.

Eles não substituirão o COBOL no fechamento bancário da próxima madrugada.

Um programa quântico não será chamado para imprimir um extrato ou atualizar um cadastro.

A expectativa mais realista é de cooperação entre diferentes arquiteturas:

• computadores clássicos executam o fluxo empresarial;

• aceleradores tratam cargas de IA;

• sistemas quânticos investigam problemas específicos;

• mainframes preservam dados e transações críticas.

Cada tecnologia ocupa um papel.

Nenhuma nave utiliza o motor principal para preparar o café da tripulação.

---

Capítulo XI — Um passo a passo para o iniciante compreender o ecossistema

Ao observar todas essas tecnologias, um programador iniciante pode sentir que precisa aprender tudo ao mesmo tempo.

Não precisa.

A jornada pode ser dividida em órbitas.

Primeira órbita: fundamentos do COBOL

Aprenda:

• divisions;

• níveis de dados;

• cláusula PIC;

• condições;

• PERFORM;

• tabelas;

• arquivos;

• tratamento de códigos de retorno.

Pratique programas pequenos.

IDENTIFICATION DIVISION.
PROGRAM-ID. ODYSSEY1.

DATA DIVISION.
WORKING-STORAGE SECTION.

01  WS-VALOR-A       PIC 9(5) VALUE 100.
01  WS-VALOR-B       PIC 9(5) VALUE 250.
01  WS-TOTAL         PIC 9(6).

PROCEDURE DIVISION.
    ADD WS-VALOR-A WS-VALOR-B
        GIVING WS-TOTAL

    DISPLAY 'TOTAL DA MISSAO: ' WS-TOTAL

    STOP RUN.

Segunda órbita: JCL e batch

Aprenda:

• JOB;

• EXEC;

• DD;

• DISP;

• datasets;

• SYSOUT;

• códigos de retorno;

• leitura de spool.

O objetivo é entender como seu programa chega até o processador e como localizar sua saída.

Terceira órbita: dados

Estude:

• arquivos sequenciais;

• VSAM;

• Db2;

• chaves;

• índices;

• transações;

• commit e rollback.

Um programa empresarial existe para manipular dados de negócio. Sem compreender os dados, você estará navegando sem mapa estelar.

Quarta órbita: ambiente online

Conheça o CICS:

• transações;

• programas;

• COMMAREA;

• canais e containers;

• mapas BMS;

• códigos de resposta;

• pseudo-conversação.

Quinta órbita: integração

Avance para:

• IBM MQ;

• APIs;

• JSON;

• z/OS Connect;

• eventos;

• serviços.

Nesse ponto, você começará a enxergar o mainframe como participante de uma arquitetura distribuída.

Sexta órbita: automação e DevOps

Explore:

• Git;

• pipelines;

• testes automatizados;

• Ansible;

• ferramentas modernas de desenvolvimento;

• implantação controlada.

O objetivo não é abandonar ISPF. É saber trabalhar em mais de uma cabine de comando.

Sétima órbita: IA e observabilidade

Somente depois dos fundamentos, investigue:

• IA generativa;

• RAG;

• agentes;

• análise de logs;

• governança;

• monitoramento;

• explicabilidade.

A inteligência artificial amplifica conhecimento. Ela não substitui fundamentos inexistentes.

---

Capítulo XII — Dicas do comandante Bellacosa

1. Não confunda antigo com obsoleto

Uma ponte construída há décadas pode continuar essencial se for mantida, reforçada e integrada à cidade.

O mesmo vale para aplicações.

Pergunte:

• O sistema ainda oferece valor?

• Ele é confiável?

• Pode ser mantido?

• Está documentado?

• Pode ser integrado?

• O risco é conhecido?

A idade, sozinha, não responde.

2. Leia mensagens como evidências

No mainframe, uma mensagem de erro raramente é mero ruído.

Observe:

• código do ABEND;

• step;

• programa;

• offset;

• dataset;

• return code;

• mensagens anteriores;

• contexto da execução.

O erro final pode ser apenas a última consequência de uma falha iniciada muito antes.

3. Respeite os contratos de dados

Alterar um PIC de X(10) para X(12) pode parecer simples.

Porém, a mudança pode afetar:

• tamanho do registro;

• copybook;

• arquivo;

• programa produtor;

• programa consumidor;

• tabela;

• interface;

• relatório.

Dois bytes podem iniciar uma viagem interplanetária de incidentes.

4. Automatize depois de compreender

Automatizar um processo ruim apenas permite que o erro aconteça mais rapidamente.

Primeiro entenda.

Depois padronize.

Só então automatize.

5. Faça perguntas de negócio

Não pergunte apenas:

“Qual linha deve ser alterada?”

Pergunte:

“Qual comportamento empresarial precisa mudar?”

Essa pergunta separa o digitador de código do engenheiro de sistemas.

---

Curiosidades encontradas durante a viagem

A IBM atravessou diferentes eras da computação e teve participação em inúmeros ambientes tecnológicos. Sua marca esteve ligada a tabulação, mainframes, armazenamento, pesquisa, inteligência artificial e serviços empresariais.

O nome “Big Blue”, usado informalmente para se referir à IBM, possui origem discutida. Algumas explicações relacionam o apelido à identidade visual azul da companhia; outras, aos grandes computadores e ao dress code tradicional de seus profissionais. Independentemente da origem exata, o nome se tornou parte do folclore tecnológico.

O mainframe moderno pode executar não apenas COBOL, mas também Java, C, C++, Python, assembler, PL/I e workloads Linux.

Isso significa que o computador que muitos imaginam preso aos anos 1970 pode participar de arquiteturas de APIs, contêineres, inteligência artificial e automação.

Outro detalhe interessante: em ambientes críticos, estabilidade não significa ausência de inovação.

Significa que a inovação precisa acontecer sem interromper a missão.

Trocar uma aplicação que processa milhões de operações não é como atualizar um aplicativo doméstico. A nova solução deve preservar dados, comportamentos, auditoria, desempenho e continuidade.

A dificuldade não está apenas em construir o novo.

Está em garantir que o novo compreenda tudo o que o antigo aprendeu.

---

Easter egg final — O verdadeiro HAL do mainframe

Em 2001: Uma Odisseia no Espaço, HAL 9000 observa, conversa, interpreta e controla sistemas da nave.

No mainframe, não existe um único HAL.

Existe uma tripulação de subsistemas:

• o JES recebe e organiza os trabalhos;

• o WLM decide prioridades;

• o RACF controla identidades;

• o CICS gerencia transações;

• o Db2 protege dados relacionais;

• o MQ entrega mensagens;

• o SMF registra o que aconteceu;

• o z/OS coordena a missão.

Quando um job falha às 3h17 da manhã, o sistema deixa rastros.

A tarefa do programador é reconstruir a sequência.

O dataset foi encontrado?

O programa recebeu os parâmetros corretos?

O arquivo possuía o formato esperado?

A consulta retornou SQLCODE?

Houve falta de espaço?

O código de retorno de um step anterior foi ignorado?

Essa investigação é quase arqueologia espacial.

Cada mensagem é um fragmento.

Cada log é uma coordenada.

Cada dump é uma caixa-preta.

---

Conclusão — Além do infinito, existe produção

A IBM não permaneceu viva por mais de um século apenas por fabricar boas máquinas.

Ela sobreviveu porque mudou de forma diversas vezes.

De tabuladores para computadores.

De máquinas individuais para arquiteturas compatíveis.

De hardware para software.

De software para serviços.

De serviços para consultoria.

De data centers para nuvem híbrida.

De automação tradicional para inteligência artificial empresarial.

No entanto, existe uma linha que conecta todas essas eras:

o processamento confiável de informações importantes.

O IBM Z representa essa continuidade. O Red Hat OpenShift conecta ambientes. O Ansible automatiza operações. O IBM MQ transporta mensagens. O watsonx leva inteligência artificial ao mundo empresarial. A IBM Consulting ajuda a transformar estratégia em execução. O IBM Research investiga aquilo que ainda parece ficção científica.

Para o programador COBOL iniciante, a principal revelação é libertadora:

Você não entrou em um museu.

Você entrou em uma nave que está em operação há décadas, foi modernizada diversas vezes e continua viajando.

Seu primeiro programa talvez seja pequeno.

Talvez leia um arquivo, valide um campo e produza uma saída. Mas ele já ensinará os mesmos princípios que sustentam os grandes sistemas:

• dados precisam de estrutura;

• regras precisam de clareza;

• erros precisam ser tratados;

• resultados precisam ser verificáveis;

• mudanças precisam ser controladas;

• sistemas precisam conversar;

• operações precisam deixar evidências.

A linguagem COBOL é apenas a primeira porta.

Depois dela existem JCL, CICS, Db2, VSAM, MQ, RACF, APIs, Linux, OpenShift, Ansible, cloud, IA e todo o ecossistema IBM.

Diante desse universo, o iniciante pode perguntar:

“Até onde essa jornada pode chegar?”

A resposta está piscando no painel da nave, em letras verdes:

READY

O mainframe está pronto.

A missão aguarda.

E, em algum lugar silencioso do data center, enquanto milhões de transações atravessam a madrugada, uma luz permanece acesa.

Não é o olho vermelho de HAL 9000.

É o indicador de um job que terminou com:

MAXCC=0000

Missão cumprida.

MCP Design Patterns: O Manual Definitivo para Construir Agentes de IA Inteligentes (e por que Arquitetura Vale Muito Mais que Prompt)

 

Bellacosa Mainframe mcp design patterns

☕ Um Café no Bellacosa Mainframe

MCP Design Patterns: O Manual Definitivo para Construir Agentes de IA Inteligentes (e por que Arquitetura Vale Muito Mais que Prompt)

"Todo desenvolvedor júnior se encanta pelo agente. O desenvolvedor sênior se preocupa com a arquitetura. O arquiteto sabe que um agente inteligente sobre uma arquitetura ruim apenas toma decisões erradas mais rapidamente."

Durante muitos anos nós, programadores, aprendemos que desenvolver software significava criar classes, funções, APIs e bancos de dados.

Depois vieram os microsserviços.

Depois Kubernetes.

Depois Serverless.

Agora chegou a vez da Inteligência Artificial.

Mas existe um erro que praticamente todo iniciante comete.

Ele acredita que construir um sistema baseado em IA significa apenas conectar o ChatGPT a uma API.

Não significa.

Na verdade, isso representa apenas uma pequena parte da arquitetura.

É exatamente aqui que entra um conceito que provavelmente será tão importante quanto REST foi para os sistemas distribuídos:

Model Context Protocol (MCP).

Mas existe uma segunda descoberta que poucos fazem no início da jornada.

O MCP resolve a comunicação.

Os Design Patterns resolvem o problema real.

Hoje vamos entender profundamente por quê.

Pegue seu café.

Porque esta conversa pode mudar completamente sua forma de enxergar agentes inteligentes.

---

O que realmente é o MCP?

Imagine um programador COBOL chegando ao escritório.

Ele precisa consultar:

• CICS

• Db2

• IMS

• RACF

• VSAM

• MQ

• arquivos JCL

• documentação

• APIs REST

Cada tecnologia possui uma interface diferente.

Agora imagine um engenheiro de IA.

Ele possui exatamente o mesmo problema.

Só que o usuário é um LLM.

O LLM não sabe conversar com Db2.

Não entende CICS.

Nunca ouviu falar em JES2.

Muito menos em um dataset PDS.

Então alguém precisava criar um idioma universal.

Esse idioma recebeu o nome de Model Context Protocol (MCP).

Pense nele como um USB-C.

Você não precisa mais fabricar um cabo diferente para cada dispositivo.

Todos falam o mesmo protocolo.

O mesmo acontece com IA.

Ao invés de ensinar cada modelo a conversar com milhares de APIs diferentes...

Criamos um protocolo único.

---

MCP não é um Framework

Esse é outro erro comum.

MCP não substitui:

• Spring Boot

• FastAPI

• Express

• ASP.NET

Ele também não substitui:

• REST

• GraphQL

• gRPC

Na verdade...

Ele vive acima deles.

Usuário

↓

LLM

↓

MCP Client

↓

MCP Server

↓

REST
SOAP
GraphQL
SQL
MQ
Filesystem
Mainframe

Perceba que o MCP não elimina tecnologias existentes.

Ele apenas organiza o acesso a elas.

---

O maior erro dos iniciantes

Quase todo mundo faz isso.

"Vou criar um MCP."

Mas ninguém pergunta:

Meu fluxo realmente funciona como?

Essa pergunta vale milhões.

Porque existem dezenas de maneiras diferentes de organizar um sistema baseado em IA.

É exatamente para isso que servem os Design Patterns.

---

Pense como um arquiteto

Um arquiteto não começa desenhando portas.

Ele pergunta:

Será uma escola?

Hospital?

Shopping?

Casa?

Prédio?

O mesmo vale para MCP.

Não existe um único padrão.

Existe o padrão correto para determinado problema.

Vamos conhecer cada um deles.

---

Pattern 1 — Local Resource Access

É o padrão mais simples.

Mas também um dos mais utilizados.

Imagine um agente que precisa responder perguntas usando documentos internos.

PDFs.

Excel.

TXT.

CSV.

Imagens.

JCL.

COBOL.

PL/I.

Datasets.

Não faz sentido enviar tudo para a nuvem.

Então o MCP acessa diretamente o sistema de arquivos.

LLM

↓

Servidor MCP

↓

Filesystem

Simples.

Seguro.

Rápido.

---

Exemplo no Mainframe

Imagine perguntar:

"Liste todos os JOBs que utilizam SORT."

O MCP poderia analisar:

SYS1.PROCLIB

SYS2.PROCLIB

USER.JCL

PRODUCTION.JOBS

Sem copiar absolutamente nada para fora do ambiente z/OS.

Esse padrão é fantástico para ambientes regulados.

---

Curiosidade

Empresas financeiras dificilmente aceitam que seus documentos internos sejam enviados para provedores externos de IA.

Por isso, o Local Resource Pattern provavelmente será um dos mais utilizados nos próximos anos.

---

Pattern 2 — Hierarchical MCP

Agora o sistema começou a crescer.

Imagine uma fintech.

Ela possui:

Clientes.

Pagamentos.

PIX.

Cartões.

Fraude.

CRM.

Cobrança.

Tudo misturado.

Um caos.

Então surge um roteador principal.

Agente

↓

Router MCP

↓

Clientes

↓

Pagamentos

↓

PIX

↓

Fraudes

Cada servidor conhece apenas seu domínio.

Exatamente como microsserviços.

---

Analogia Mainframe

Pense em um Sysplex.

Cada LPAR executa determinadas cargas.

Existe coordenação.

Mas ninguém tenta fazer tudo sozinho.

O mesmo acontece aqui.

---

Pattern 3 — Event Driven

Esse padrão muda completamente a filosofia.

Nem tudo precisa acontecer imediatamente.

Às vezes basta gerar um evento.

Pedido recebido

↓

MQ

↓

Servidor MCP

↓

Worker

↓

Resposta futura

Isso lembra bastante:

• IBM MQ

• Kafka

• RabbitMQ

• Event Streams

---

Exemplo corporativo

Recebeu uma nota fiscal.

↓

Extrair dados.

↓

Classificar.

↓

Enviar ao ERP.

↓

Gerar relatório.

↓

Enviar e-mail.

Tudo isso pode acontecer sem bloquear o usuário.

---

Exemplo IBM Z

CICS

↓

MQ

↓

MCP

↓

Análise

↓

Atualiza Db2

↓

Notifica operador

É exatamente a filosofia dos sistemas orientados a eventos.

---

Pattern 4 — MCP-to-Agent

Agora chegamos onde a IA realmente fica interessante.

Imagine um único agente tentando responder tudo.

Financeiro.

Jurídico.

RH.

Infraestrutura.

Banco de dados.

Não parece uma boa ideia.

Então fazemos exatamente o contrário.

Criamos especialistas.

Supervisor

↓

Especialista COBOL

Especialista Db2

Especialista CICS

Especialista RACF

Especialista MQ

Cada um conhece profundamente sua área.

Depois alguém junta as respostas.

Isso é arquitetura Multi-Agent.

---

Imagine isso

Usuário pergunta:

"Por que meu JOB terminou com RC=12?"

O supervisor encaminha a pergunta para:

• Especialista JCL

• Especialista SORT

• Especialista Db2

• Especialista JES2

Todos analisam simultaneamente.

Depois entregam um diagnóstico consolidado.

Muito mais eficiente.

---

Pattern 5 — Composite Service

Agora o MCP vira um maestro.

Ele coordena vários serviços.

Consulta Cliente

↓

Consulta Crédito

↓

Consulta Receita

↓

Consulta ERP

↓

Consulta Open Finance

↓

Resposta

Para o usuário parece uma única ferramenta.

Mas internamente dezenas de APIs trabalharam juntas.

---

Exemplo Mainframe

Abrir uma conta.

O MCP pode chamar:

• CICS

• Db2

• MQ

• RACF

• z/OS Connect

• API do CRM

Tudo automaticamente.

---

Pattern 6 — Direct API Wrapper

É o mais simples.

Você já possui APIs.

Só precisa expô-las.

REST

↓

MCP

↓

LLM

Não existe necessidade de reinventar nada.

Esse padrão é excelente para:

• MVP

• Provas de conceito

• Hackathons

• Integrações rápidas

---

Comparando todos os padrões

Pattern	Complexidade	Escala	Quando usar
Local Resource	Muito baixa	Média	Arquivos locais
Direct API	Baixa	Alta	APIs existentes
Composite	Média	Alta	Integrações
Event Driven	Alta	Muito alta	Processamentos longos
Hierarchical	Alta	Muito alta	Grandes empresas
MCP-to-Agent	Muito alta	Extremamente alta	IA especializada

---

Como isso conversa com RAG?

Muita gente confunde.

RAG não substitui MCP.

MCP não substitui RAG.

Eles trabalham juntos.

Imagine:

Pergunta

↓

Agente

↓

RAG procura conhecimento

↓

MCP executa ação

↓

Resposta

Um encontra informação.

O outro executa tarefas.

São complementares.

---

E onde entra o Prompt Engineering?

Outro mito.

Prompt Engineering não desapareceu.

Na verdade ficou ainda mais importante.

Agora temos:

• Prompt do usuário

• Prompt do agente

• Prompt das ferramentas

• Prompt dos especialistas

• Prompt do supervisor

É uma arquitetura inteira de prompts.

---

Observabilidade: o detalhe que todo mundo esquece

Quem respondeu?

Qual ferramenta foi utilizada?

Quanto tempo demorou?

Qual API falhou?

Qual agente tomou determinada decisão?

Sem observabilidade...

Você nunca conseguirá depurar um sistema baseado em IA.

Da mesma forma que usamos:

• SMF

• RMF

• SDSF

• JES2

para monitorar o z/OS,

precisaremos monitorar agentes.

Provavelmente surgirão verdadeiros "SDSFs para IA".

---

Segurança

Este talvez seja o assunto mais importante.

Imagine um agente com acesso irrestrito.

Ele poderia:

Excluir arquivos.

Cancelar JOBs.

Criar usuários.

Alterar tabelas.

Assustador.

Por isso o MCP precisa respeitar princípios como:

• Menor privilégio (Least Privilege)

• Zero Trust

• Autenticação forte

• Autorização por função

• Auditoria completa

• Logs imutáveis

No mundo IBM Z, isso conversa diretamente com RACF, ACF2 e Top Secret.

---

O futuro: agentes especializados

Hoje temos um único chatbot.

Daqui a alguns anos teremos verdadeiras equipes virtuais.

Imagine um ambiente de desenvolvimento onde coexistem:

• um Arquiteto de Software virtual;

• um Especialista COBOL;

• um DBA Db2;

• um Especialista CICS;

• um Analista de Segurança RACF;

• um Especialista em Performance WLM;

• um Engenheiro DevOps;

• um Especialista em Observabilidade.

Você faz uma única pergunta, e um agente supervisor distribui automaticamente as tarefas para cada especialista. Essa visão, que parecia ficção científica há poucos anos, já começa a aparecer nas arquiteturas corporativas mais modernas.

---

Dicas para o Programador Júnior

Se você está começando agora, não tente aprender tudo de uma vez. Construa sua base de forma incremental:

1. Aprenda primeiro o que é o MCP e como ele expõe ferramentas.

2. Crie um pequeno servidor MCP acessando arquivos locais.

3. Envolva uma API REST existente usando o padrão Direct API Wrapper.

4. Evolua para um Composite Service, orquestrando duas ou três APIs.

5. Estude filas e processamento assíncrono com IBM MQ, Kafka ou RabbitMQ.

6. Experimente arquiteturas multiagentes, separando especialistas por domínio.

7. Documente tudo. Um bom diagrama vale tanto quanto um bom código.

8. Pense sempre em segurança, observabilidade e governança desde o primeiro dia.

Lembre-se: a melhor arquitetura é aquela que continua simples mesmo quando o sistema cresce.

---

Curiosidades

☕ O conceito de protocolos padronizados não é novo. Assim como HTTP revolucionou a Web e JDBC padronizou o acesso a bancos de dados, o MCP busca padronizar a comunicação entre modelos de IA e ferramentas.

☕ Muitas empresas estão reutilizando APIs que já existiam há anos. Em vez de reescrever sistemas, apenas criam uma camada MCP sobre elas.

☕ Um servidor MCP pode conversar com sistemas escritos em COBOL, Java, Python, C#, Go ou Node.js. O protocolo não depende da linguagem de implementação.

☕ Ambientes IBM Z são candidatos naturais para o uso de MCP, pois concentram processos críticos, regras de negócio consolidadas e décadas de conhecimento corporativo.

---

Easter Eggs para os apaixonados por tecnologia

🥚 Easter Egg #1: Se você conhece o padrão Facade da programação orientada a objetos, já entendeu parte da ideia do Composite Service Pattern: esconder a complexidade de vários serviços atrás de uma interface simples.

🥚 Easter Egg #2: O Hierarchical MCP Pattern lembra a organização de um Sysplex: vários componentes especializados coordenados por uma camada superior.

🥚 Easter Egg #3: O Event-Driven Pattern conversa naturalmente com IBM MQ, Kafka e até mesmo com os tradicionais batch triggers do z/OS. O conceito muda, mas a filosofia continua a mesma.

🥚 Easter Egg #4: Um agente supervisor distribuindo tarefas para especialistas lembra muito o escalonamento de workloads feito pelo Workload Manager (WLM): cada recurso executa aquilo para o qual foi projetado.

🥚 Easter Egg #5: Se você percebeu que um servidor MCP funciona como uma espécie de "3270 inteligente" para a IA, parabéns! Em ambos os casos existe uma camada intermediária que traduz comandos e controla o acesso aos sistemas corporativos.

---

Conclusão

O entusiasmo em torno da Inteligência Artificial faz muita gente acreditar que basta escolher o melhor modelo de linguagem para resolver qualquer problema. A prática mostra o contrário. Modelos excelentes podem fracassar quando são colocados sobre arquiteturas mal planejadas, enquanto modelos mais modestos entregam resultados impressionantes quando sustentados por uma boa engenharia.

O Model Context Protocol (MCP) representa um passo importante nessa evolução porque padroniza a comunicação entre agentes e sistemas. No entanto, o protocolo é apenas a fundação. O verdadeiro diferencial está na escolha do Design Pattern adequado ao fluxo de trabalho, ao domínio de negócio, aos requisitos de segurança e à estratégia de escalabilidade.

Para quem trabalha com IBM Mainframe, a boa notícia é que muitos dos princípios utilizados há décadas — modularização, separação de responsabilidades, processamento assíncrono, governança, auditoria e alta disponibilidade — continuam absolutamente válidos. O cenário mudou, mas os fundamentos permanecem.

No fim das contas, construir soluções com IA não é muito diferente de construir sistemas corporativos de qualidade: o protocolo conecta, a arquitetura organiza e a experiência do engenheiro transforma tecnologia em valor para o negócio.

Porque, como gostamos de dizer aqui no Bellacosa Mainframe:

"A IA pode escrever código em segundos. Mas somente uma boa arquitetura garante que esse código continuará útil daqui a dez anos."