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

Translate

quinta-feira, 9 de julho de 2026

Capítulo 9 — O Que Realmente Aconteceu

Bellacosa Mainframe o Mainframe como uma Phoenix renasce e obtem protagonismo

☕ Um Café no Bellacosa Mainframe

Capítulo 9 — O Que Realmente Aconteceu

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

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

Por

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

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

— Bellacosa Mainframe

A evolução que aconteceu longe das manchetes

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

Principais marcos tecnológicos

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

A verdadeira lição

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


O funeral foi cancelado. O trabalho continuou.

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

"Afinal... o que realmente aconteceu?"

A resposta curta é simples.

O mundo mudou profundamente.

Os computadores pessoais venceram.

A Internet revolucionou a sociedade.

O Linux conquistou os datacenters.

O Cloud Computing transformou a infraestrutura.

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

Tudo isso aconteceu.

Mas existe uma segunda resposta.

Muito mais interessante.

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

Ele participou de todas elas.


O maior erro das previsões

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

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

Hardware.

Velocidade do processador.

Preço.

Memória.

Arquitetura.

Quantidade de servidores.

Pouquíssimas perguntavam:

  • Quanto custa parar um banco por uma hora?

  • Quanto custa perder uma transação financeira?

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

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

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

O verdadeiro patrimônio sempre foi o conhecimento.


Bellacosa Mainframe e o ibm highlander

A IBM respondeu... trabalhando

Existe uma característica interessante da IBM.

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

Ela responde lançando produtos.

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

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

Sem alarde.

Sem discursos dramáticos.

Apenas engenharia.

Vamos percorrer rapidamente essa jornada.


Anos 90 — Parallel Sysplex

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

Parallel Sysplex.

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

Compartilhando dados.

Compartilhando carga.

Compartilhando disponibilidade.

Na prática, significava algo extraordinário.

Se um sistema apresentasse problemas...

Outro assumiria imediatamente.

Hoje chamamos isso de alta disponibilidade.

Na época...

Era engenharia de altíssimo nível.

Enquanto muitos ainda discutiam Client/Server...

A IBM discutia continuidade de negócios.


CMOS muda tudo

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

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

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

Era uma resposta elegante.

Sem debates.

Sem marketing agressivo.

Apenas evolução tecnológica.


O Linux chega ao IBM Z

Talvez uma das maiores ironias da história.

Durante anos disseram:

"O futuro é Linux."

A IBM respondeu:

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

E foi exatamente isso que aconteceu.

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

Muitos especialistas ficaram surpresos.

Outros ficaram confusos.

Mas o mercado adorou a ideia.

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

Em vez de combater o Linux...

O IBM Z o abraçou.


Java também chegou

Outra previsão famosa dizia:

"Java acabará com o legado."

Pouco tempo depois...

Java passou a executar no próprio IBM Z.

Mais uma vez a IBM fez algo curioso.

Ela não brigou contra a novidade.

Ela a incorporou.

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


Virtualização muito antes da moda

Hoje qualquer profissional conhece máquinas virtuais.

VMware.

Hyper-V.

KVM.

Cloud.

Mas existe um detalhe histórico importante.

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

LPARs.

PR/SM.

z/VM.

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

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

Os profissionais de IBM Z apenas sorriam discretamente.


Specialty Engines

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

Vieram:

  • zAAP;

  • zIIP;

  • IFL;

  • SAP;

  • ICF.

Cada um otimizado para determinados tipos de carga.

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

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


SOA, Web Services e APIs

Depois surgiu outro buzzword.

SOA — Service-Oriented Architecture.

Muitos acreditavam que seria o fim definitivo dos sistemas tradicionais.

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

Mais tarde vieram APIs REST.

JSON.

OpenAPI.

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

Não porque alguém reescreveu tudo.

Mas porque a arquitetura evoluiu.


Open Source no IBM Z

Outro mito dizia:

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

Então chegaram:

Git.

Python.

Node.js.

Go.

Zowe.

Ansible.

VS Code.

OpenShift.

Red Hat Enterprise Linux.

Containers.

Kubernetes.

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

A fronteira ficou cada vez menor.


O COBOL também evoluiu

Existe outro mito que merece aposentadoria.

"COBOL parou no tempo."

Não.

O COBOL de 2026 é muito diferente daquele de 1989.

Hoje encontramos recursos como:

  • UTF-8;

  • JSON PARSE e JSON GENERATE;

  • XML PARSE;

  • tipos modernos de dados;

  • desempenho otimizado;

  • integração com C e Java;

  • compiladores altamente inteligentes;

  • diagnósticos avançados;

  • otimizações automáticas.

O objetivo nunca foi transformar COBOL em outra linguagem.

Foi permitir que continuasse excelente naquilo que sempre fez.

Processamento de negócios.


Db2, CICS e z/OS também cresceram

O mesmo aconteceu com todo o ecossistema.

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

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

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

Nada ficou parado.


DevOps chegou ao IBM Z

Outro capítulo interessante.

Durante anos muita gente dizia:

"Mainframe não combina com DevOps."

Então apareceram:

  • Git;

  • Jenkins;

  • IBM Dependency Based Build (DBB);

  • IBM Build Open Builder (BOB);

  • UrbanCode Deploy;

  • Zowe CLI;

  • VS Code;

  • GitHub Actions;

  • Ansible.

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

O DevOps não substituiu o mainframe.

Ele passou a fazer parte dele.


Chegamos à Inteligência Artificial

E então chegamos a 2026.

Talvez a maior revolução desde a Internet.

A Inteligência Artificial.

Novamente surgiram manchetes dramáticas.

"Os programadores acabarão."

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

"O legado desaparecerá."

Curiosamente...

Já ouvimos esse roteiro antes.

Enquanto isso...

A IBM faz o que costuma fazer.

Integra a novidade.

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

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

A IA deixa de ser apenas um chatbot.

Passa a fazer parte do processamento corporativo.

Fraudes.

Análise de risco.

Observabilidade.

Automação operacional.

Tudo integrado ao ambiente transacional.


O Padawan encontra o velho Jedi

Nosso Padawan pergunta ao Mestre:

— Mestre... afinal quem venceu?

O velho engenheiro sorri.

Aponta para um smartphone.

Depois para um cluster Kubernetes.

Depois para uma API REST.

Depois para um programa COBOL.

Depois para um IBM z17.

E responde:

Todos.

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

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


O maior vencedor foi o cliente

No final das contas...

O usuário nunca perguntou:

  • O banco roda em COBOL?

  • O servidor utiliza Linux?

  • Existe um CICS por trás?

  • O Db2 está em Data Sharing?

  • A API foi escrita em Java ou Python?

O cliente pergunta apenas:

"Funciona?"

E continua funcionando.

Há décadas.

Essa talvez seja a maior vitória da engenharia.


A quinta grande lição

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

Quase todas as tecnologias que surgiram nesses anos permaneceram.

PCs.

Internet.

Linux.

Java.

Cloud.

Containers.

Kubernetes.

DevOps.

Open Source.

Inteligência Artificial.

E o IBM Mainframe.

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

Foi sobre evolução contínua.

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

Ela fez algo muito mais inteligente.

Aprendeu a fazer parte dele.

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

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

A engenharia pergunta:

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

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

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

O "dinossauro" não apenas sobreviveu.

Ele aprendeu a conversar com a Inteligência Artificial.

Bellacosa Mainframe e o Funeral que nunca aconteceu


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

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

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

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

README.TXT

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

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

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

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

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

quarta-feira, 8 de julho de 2026

Capítulo 8 — Business Week (1994)

Bellacosa mainframe e o dia que a impresna errou

☕ Um Café no Bellacosa Mainframe

Capítulo 8 — Business Week (1994)

O Dia em que a Imprensa Percebeu que Talvez Tivesse Enterrado o Mainframe Cedo Demais

Uma análise da reportagem publicada pela Business Week em 1994, mostrando como a indústria começou a reconhecer que as previsões sobre o fim do mainframe haviam sido exageradas e como o IBM Z continuou sua evolução tecnológica.

Por


Business Week reconhecendo em 1994 que o Mainframe continuava relevante
A reportagem da Business Week marcou um ponto de inflexão, mostrando que o mercado começava a reconsiderar o futuro dos mainframes.

"Quando os fatos mudam, a engenharia muda de direção. Quando o marketing muda de direção, normalmente muda também o discurso."

— Bellacosa Mainframe

Contexto histórico

Após anos de previsões sobre o desaparecimento dos grandes sistemas, empresas descobriram que migrar aplicações críticas era muito mais caro, complexo e arriscado do que parecia nas apresentações de marketing.

George Colony, da Forrester Research, sintetizou essa mudança ao afirmar que era "o fim do fim dos mainframes", reconhecendo que a plataforma continuava estratégica para grandes organizações.

A grande lição

A Business Week mostrou que tendências tecnológicas precisam ser avaliadas à luz dos resultados reais e não apenas das expectativas do mercado.

O IBM Mainframe continuou evoluindo nas décadas seguintes, incorporando Linux, Java, virtualização, DevOps, APIs, cloud híbrida, OpenShift, Inteligência Artificial e chegando ao IBM z17 como uma das plataformas mais resilientes da computação corporativa.


Janeiro de 1994

Estamos agora em um momento extremamente interessante da nossa história.

Até aqui vimos uma sequência de previsões pessimistas.

"O dinossauro."

"O último mainframe será desligado."

"O mainframe está correndo rumo à extinção."

Parecia que existia um consenso.

O funeral já estava marcado.

Faltava apenas escolher quem faria o discurso de despedida.

Mas então aconteceu algo curioso.

O mercado começou a olhar para os números.

E os números possuem um defeito terrível para quem vive de buzzwords.

Eles não ligam para apresentações em PowerPoint.


Alguma coisa não fechava

As vendas de servidores realmente cresciam.

Os PCs realmente dominavam os escritórios.

As redes locais realmente se expandiam.

Mas...

Os bancos continuavam comprando mainframes.

As seguradoras também.

As bolsas de valores igualmente.

As companhias aéreas não desligavam seus CPDs.

Os governos continuavam investindo em grandes sistemas.

As empresas mais críticas da economia simplesmente... não estavam abandonando o IBM Mainframe.

Isso começou a chamar atenção.


O Business Week muda o tom

Em 10 de janeiro de 1994, a Business Week, uma das revistas de negócios mais respeitadas do mundo, publicou uma reportagem que destoava da narrativa predominante.

Em vez de insistir na ideia da morte inevitável do mainframe, a matéria citava George Colony, fundador da Forrester Research, com uma frase que se tornaria histórica:

"It's the end of the end for the mainframes."

Em tradução livre:

"É o fim do fim dos mainframes."

Parece um jogo de palavras.

E é exatamente isso.

Mas também representa uma mudança profunda de percepção.

Pela primeira vez, uma publicação de grande circulação reconhecia que talvez a indústria tivesse exagerado nas previsões anteriores. Essa mudança de tom foi registrada por Wolfgang Spruth em The Death of the Mainframe como um marco importante na evolução do debate sobre a plataforma IBM.


Traduzindo o economês

Vamos simplificar.

George Colony estava dizendo algo parecido com:

"Talvez tenhamos exagerado."

Ou ainda:

"Talvez o problema nunca tenha sido o mainframe."

Ou, numa tradução Bellacosa Mainframe:

"Pessoal... acho que enterramos o paciente antes de confirmar o óbito."


A realidade começou a aparecer

Entre 1991 e 1994 muitas empresas iniciaram grandes projetos de migração.

Alguns deram certo.

Outros...

Nem tanto.

Sistemas previstos para serem reescritos em dezoito meses completavam quatro anos de projeto.

Os custos disparavam.

A complexidade aparecia.

Regras de negócio esquecidas voltavam a assombrar as equipes.

Interfaces que ninguém conhecia surgiam do nada.

Programas COBOL escritos quinze anos antes continuavam funcionando perfeitamente.

Descobriu-se algo que nenhum folder de marketing mencionava.

Legado não significa velho.

Significa importante.


O verdadeiro patrimônio da empresa

Imagine uma seguradora.

Ela possui vinte milhões de clientes.

Cada contrato depende de dezenas de regras.

Regras legais.

Regras fiscais.

Regras atuariais.

Regras internas.

Agora imagine alguém dizendo:

— Vamos reescrever tudo.

A pergunta não é:

"Conseguimos?"

A pergunta é:

"Vale a pena?"

Essa simples mudança de perspectiva transformou completamente a discussão.


Bellacosa Mainframe e o Cobol como o vilão favorito

O COBOL virou o vilão favorito

Durante anos, COBOL foi apresentado como um símbolo do passado.

Parecia existir uma competição para descobrir quem faria a manchete mais dramática.

"O fim do COBOL."

"A última geração de programadores."

"Ninguém mais aprende COBOL."

Enquanto isso...

Universidades deixavam de ensinar COBOL.

Mas bancos continuavam contratando especialistas.

Governos continuavam executando milhões de linhas de código.

Seguradoras ampliavam seus sistemas.

Era uma situação curiosa.

Todo mundo dizia que COBOL estava morrendo.

Mas ninguém queria desligar o sistema que pagava salários.


O humor do velho operador

Imagine um operador de CPD lendo aquela reportagem da Business Week.

Ele olha para o relógio.

Depois para o console.

Mais um JOB termina normalmente.

Outro começa.

Ele comenta com o colega:

— Parece que cancelaram meu funeral.

O colega responde:

— Ainda bem.

Temos o fechamento contábil às oito.


A IBM não ficou parada

Existe um detalhe frequentemente esquecido.

Muitas análises daquela época tratavam o mainframe como se fosse uma tecnologia congelada.

Como se a IBM tivesse parado de inovar.

Isso simplesmente não era verdade.

Enquanto o mercado discutia Client/Server...

A IBM continuava investindo bilhões em pesquisa.

Novos processadores.

Mais memória.

Melhores canais de entrada e saída.

Virtualização cada vez mais sofisticada.

Novos sistemas operacionais.

Ferramentas de desenvolvimento.

Integração com redes abertas.

A plataforma evoluía continuamente.

A diferença é que evolução incremental raramente vira manchete.


O mercado aprendeu uma palavra nova

Na metade da década de 1990 começou a surgir um conceito importante.

Integração.

Até então o debate parecia binário.

Ou era Mainframe.

Ou era Client/Server.

Com o amadurecimento dos projetos, as empresas descobriram que poderiam ter os dois.

O front-end poderia rodar em PCs.

As aplicações departamentais em servidores distribuídos.

E o processamento crítico permanecer no mainframe.

Hoje isso parece óbvio.

Na época foi quase revolucionário.


O Padawan visita uma reunião de diretoria

Nosso Padawan COBOL entra discretamente na sala.

Um consultor termina sua apresentação.

— Precisamos substituir completamente o mainframe.

O diretor financeiro faz apenas uma pergunta.

— Quanto custará?

O consultor responde.

— Aproximadamente cinquenta milhões de dólares.

O diretor permanece em silêncio.

Depois pergunta novamente.

— E se não substituirmos?

Outro silêncio.

Nesse momento o arquiteto da empresa comenta:

— Podemos integrar os novos sistemas ao ambiente existente.

A reunião muda completamente de direção.

Porque, no mundo corporativo, arquitetura sempre precisa conversar com orçamento.


O início da convivência

Foi justamente nessa época que a indústria começou a abandonar uma visão extremamente simplista.

Não era mais uma guerra.

Não existia vencedor absoluto.

Cada plataforma possuía seu espaço.

Mainframe para grandes volumes transacionais.

Servidores distribuídos para aplicações departamentais.

PCs para produtividade.

Mais tarde chegariam Linux.

Java.

Web Services.

Cloud.

Containers.

OpenShift.

Todos convivendo.

Essa mudança de mentalidade talvez tenha sido muito mais importante do que qualquer evolução de hardware.


O "fim do fim"

A frase de George Colony continua brilhante porque resume perfeitamente aquele momento.

Não significava que o mainframe venceria todas as disputas.

Também não significava que nada mudaria.

Significava apenas que a narrativa da morte inevitável começava a perder força.

A indústria finalmente compreendia algo essencial.

Uma tecnologia pode deixar de ser a única solução.

Sem deixar de ser uma solução excelente.


Trinta e dois anos depois

Estamos em 2026.

O IBM z17 integra Inteligência Artificial diretamente na plataforma.

O watsonx fornece modelos corporativos.

O BOB automatiza pipelines modernos.

O Zowe aproxima desenvolvedores open source.

O Ansible automatiza operações.

O COBOL continua recebendo novas versões.

O Db2 continua evoluindo.

O CICS continua sendo um dos monitores transacionais mais eficientes do mundo.

A grande surpresa?

Nada disso exigiu abandonar a arquitetura construída ao longo de décadas.

A plataforma simplesmente evoluiu.


A quarta grande lição

A reportagem da Business Week representa um momento raro na história da tecnologia.

O instante em que parte da imprensa começou a perceber que previsões muito otimistas também precisam ser revisadas.

Esse talvez seja o maior ensinamento deste capítulo.

Boa engenharia não se apaixona por modismos.

Ela mede.

Testa.

Observa.

Corrige.

E muda de opinião quando os fatos mudam.

Foi exatamente isso que começou a acontecer em 1994.

O mercado percebeu que a pergunta nunca deveria ter sido:

"Quem vai substituir o mainframe?"

A pergunta correta era:

"Como integrar novas tecnologias ao que já funciona extraordinariamente bem?"

Essa mudança de pergunta moldou praticamente toda a computação corporativa das três décadas seguintes.

E talvez explique por que, em vez de um túmulo...

Encontramos em 2026 um IBM z17 executando COBOL, Db2, CICS, Linux, OpenShift, APIs REST, DevOps, watsonx e Inteligência Artificial.

O funeral foi cancelado.

A evolução, não.


Fonte histórica

Business Week, 10 de janeiro de 1994, citando George Colony (Forrester Research) com a frase "It's the end of the end for the mainframes." O artigo, preservado por Wolfgang Spruth em The Death of the Mainframe, marcou uma inflexão importante no discurso da indústria: pela primeira vez, uma grande publicação reconhecia que as previsões sobre a extinção do mainframe talvez tivessem sido precipitadas.

Bellacosa Mainframe e o Funeral que nunca aconteceu


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

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

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

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

README.TXT

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

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

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

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

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

DevOps no Mainframe: O Guia Definitivo para Quem Programa em COBOL e Quer Entrar no Mundo da Entrega Contínua

 

Bellacosa Mainframe e o guia do devops para mainframe

☕ Um Café no Bellacosa Mainframe

DevOps no Mainframe: O Guia Definitivo para Quem Programa em COBOL e Quer Entrar no Mundo da Entrega Contínua

"DevOps não é instalar uma ferramenta. É mudar a forma como pensamos sobre desenvolvimento, testes, implantação e operação. E sim... isso também vale para COBOL."

Se você trabalha com IBM Mainframe há alguns anos, provavelmente já ouviu alguém dizer:

"Mainframe não precisa de DevOps."

Ou então:

"DevOps é coisa de Java, Kubernetes e Cloud."

Nada poderia estar mais distante da realidade.

Hoje, os maiores bancos, seguradoras, empresas de cartão de crédito, telecomunicações e governos do mundo utilizam práticas de DevOps justamente nos ambientes mais críticos: os sistemas IBM Z.

A verdade é simples:

O código COBOL continua excelente. O processo de desenvolvimento é que evoluiu.

Neste café vamos entender, de maneira prática, o que é DevOps, como funciona, quais ferramentas existem, como começar do zero e como implantar esse modelo em uma fábrica de software Mainframe.

Pegue seu café.

Vamos conversar.


Antes de tudo: o que é DevOps?

A palavra DevOps vem da união de duas áreas:

  • Development (Desenvolvimento)

  • Operations (Operação)

Durante décadas essas equipes trabalharam separadas.

O desenvolvedor escrevia código.

O operador implantava.

O suporte resolvia problemas.

Quando dava errado...

Todo mundo culpava o outro.

DevOps nasceu justamente para eliminar esse conflito.

O objetivo é fazer todos trabalharem juntos durante todo o ciclo de vida do software.


O ciclo tradicional

Durante muitos anos o fluxo era parecido com isto:

Analista
      ↓
Programador COBOL
      ↓
Testes
      ↓
Homologação
      ↓
Mudança
      ↓
Produção

Tudo manual.

Muito e-mail.

Planilhas.

Checklist.

JCL executado manualmente.

Libraries copiadas.

Muitas chances de erro humano.


O ciclo DevOps

Agora imagine outro cenário.

Programador
      ↓
Git
      ↓
Build automático
      ↓
Testes automáticos
      ↓
Deploy automático
      ↓
Homologação
      ↓
Produção
      ↓
Monitoramento

Tudo rastreado.

Tudo versionado.

Tudo auditável.

Esse é o objetivo do DevOps.


DevOps não é uma ferramenta

Este talvez seja o maior erro dos iniciantes.

DevOps não é:

  • Jenkins

  • Git

  • GitHub

  • Azure DevOps

  • GitLab

Essas são ferramentas.

DevOps é uma cultura.

As ferramentas apenas ajudam.


Bellacosa Mainframe e o devops para iniciante mainframe

Os pilares do DevOps

Podemos resumir DevOps em seis grandes pilares.

1. Planejamento

Toda mudança começa aqui.

Exemplo:

  • Nova funcionalidade

  • Correção de bug

  • Mudança legal

  • Novo produto

Ferramentas:

  • Jira

  • Azure Boards

  • Trello

  • ServiceNow


2. Desenvolvimento

Aqui entra o programador COBOL.

Ele escreve código.

Exemplo:

Programa COBOL

+
JCL

+
PROC

+
Copybooks

+
DB2

+
CICS

Tudo precisa ficar versionado.


3. Integração Contínua (CI)

Sempre que alguém altera o código...

O sistema automaticamente:

  • compila

  • executa testes

  • verifica qualidade

  • gera relatórios

Sem intervenção humana.


4. Testes

Não basta compilar.

É necessário testar.

Tipos comuns:

  • teste unitário

  • teste funcional

  • teste integração

  • teste regressão

  • teste performance

No Mainframe isso pode envolver:

  • ZUnit

  • IBM Debug

  • File Manager

  • stubs

  • dados mascarados


5. Deploy

Depois da aprovação:

o sistema promove automaticamente os artefatos entre ambientes.

DEV

↓

QA

↓

HML

↓

PRD

Sem copiar datasets manualmente.


6. Monitoramento

Depois da implantação...

O trabalho continua.

Monitoramos:

  • CPU

  • tempo de resposta

  • erros

  • logs

  • abends

  • consumo

  • throughput


Bellacosa Mainframe e ferramentas para implementar o devops

O famoso CI/CD

Você verá muito essa sigla.

CI

Continuous Integration

CD

Continuous Delivery

ou

Continuous Deployment.

A diferença é simples.

Continuous Delivery

O deploy fica pronto.

Mas alguém aprova.

Continuous Deployment

O deploy acontece automaticamente.


Como isso funciona no Mainframe?

Imagine um programa COBOL.

Você altera uma linha.

Ao salvar:

Git

↓

Pipeline

↓

Compilação

↓

Link-edit

↓

Testes

↓

Deploy

↓

Homologação

Tudo automático.


Ferramentas mais usadas

Vamos conhecer as principais.

Git

O coração do DevOps.

Ele controla versões.

Permite:

  • histórico

  • branches

  • merge

  • rollback

Hoje praticamente todo projeto moderno usa Git.

Inclusive Mainframe.


GitHub

Hospeda repositórios Git.

Possui:

  • Pull Request

  • Code Review

  • Actions

  • Issues

Muito usado em projetos open source.


GitLab

Além do Git...

Possui pipeline integrada.

Muito utilizado em empresas.


Azure DevOps

Muito comum em bancos.

Possui:

  • Boards

  • Repos

  • Pipelines

  • Artifacts

  • Test Plans

Integra muito bem com ambientes corporativos.


Jenkins

Uma das ferramentas de automação mais famosas.

Ele executa:

  • compilação

  • testes

  • deploy

  • scripts

Tudo automaticamente.


IBM Dependency Based Build (DBB)

Ferramenta criada pela IBM para Mainframe.

Ela entende:

  • COBOL

  • PL/I

  • Assembler

  • JCL

  • Copybooks

Excelente para pipelines IBM Z.


IBM Developer for z/OS (IDz)

Substitui boa parte do ISPF.

Integra:

  • Git

  • Debug

  • Build

  • Pipeline


Zowe

Talvez a maior revolução dos últimos anos.

Permite acessar o Mainframe usando:

  • VS Code

  • APIs

  • CLI

  • Explorer

É praticamente uma ponte entre o mundo distribuído e o IBM Z.


VS Code

Hoje muitos programadores COBOL utilizam VS Code.

Com extensões adequadas é possível:

  • editar COBOL

  • enviar código

  • acessar datasets

  • executar comandos


Ansible

Automação de infraestrutura.

Pode automatizar:

  • configuração

  • deploy

  • instalação

  • tarefas repetitivas


SonarQube

Analisa qualidade do código.

Detecta:

  • duplicação

  • complexidade

  • bugs

  • vulnerabilidades

Inclusive existem plugins para COBOL.


JFrog Artifactory

Gerencia artefatos.

Armazena:

  • builds

  • binários

  • versões


Um pipeline simples

Imagine este fluxo.

Programador

↓

Git Commit

↓

Pipeline

↓

Compilar COBOL

↓

Executar testes

↓

Quality Gate

↓

Deploy DEV

↓

Deploy QA

↓

Deploy HML

↓

Produção

Sem copiar datasets manualmente.

Sem FTP.

Sem e-mail.


Como implantar DevOps em um sistema Mainframe?

Aqui está um roteiro simples.

Etapa 1

Mapeie o processo atual.

Pergunte:

Como o programa chega em produção?

Quem aprova?

Quem compila?

Quem faz bind?

Quem copia load modules?

Quem altera CICS?

Quem agenda o Job?


Etapa 2

Versione tudo.

Não apenas programas COBOL.

Também:

  • JCL

  • PROC

  • Copybooks

  • SQL

  • DDL

  • Scripts

  • Documentação


Etapa 3

Padronize.

Todos devem usar:

Mesmo padrão.

Mesmo fluxo.

Mesmo processo.


Etapa 4

Automatize a compilação.

Em vez de:

Editar

Compilar

Link

Testar

Faça:

Commit

↓

Pipeline

↓

Compilação automática

Etapa 5

Automatize testes.

Quanto mais testes...

Maior a confiança.


Etapa 6

Automatize deploy.

Reduza:

  • intervenção humana

  • erros

  • esquecimentos


Etapa 7

Monitore.

Depois do deploy acompanhe:

  • SMF

  • RMF

  • JES

  • SDSF

  • logs

  • CICS

  • DB2


Roadmap para quem está começando

Nível 1

Aprenda:

  • Git

  • GitHub

  • Branch

  • Merge

  • Pull Request


Nível 2

Aprenda:

  • Jenkins

  • Azure DevOps

  • GitLab CI


Nível 3

Aprenda:

  • Pipeline

  • YAML

  • Build


Nível 4

Aprenda:

  • Zowe CLI

  • VS Code

  • REST APIs


Nível 5

Aprenda:

  • DBB

  • IDz

  • SonarQube


Nível 6

Aprenda:

  • Docker (conceitos)

  • Kubernetes (conceitos)

  • OpenShift

Mesmo trabalhando apenas com Mainframe.


Nível 7

Aprenda observabilidade.

Conheça:

  • Grafana

  • Prometheus

  • Elastic

  • OpenTelemetry

Mesmo que parte do monitoramento do IBM Z utilize soluções específicas da IBM.


Quanto custa implantar?

A resposta depende do ambiente.

Há soluções gratuitas e corporativas.

Gratuitas

  • Git

  • GitHub (planos gratuitos)

  • VS Code

  • Jenkins

  • Zowe

  • SonarQube Community

O investimento principal será tempo de implantação, treinamento e adaptação dos processos.

Corporativas

Dependendo da empresa podem existir licenças para:

  • IBM Dependency Based Build

  • IBM Developer for z/OS

  • Azure DevOps

  • GitHub Enterprise

  • GitLab Enterprise

  • JFrog Artifactory

  • UrbanCode Deploy (ou soluções equivalentes)

  • ferramentas de testes automatizados

Além das licenças, considere:

  • infraestrutura

  • treinamento

  • consultoria

  • integração com RACF, CICS, DB2 e sistemas legados

  • manutenção contínua

Apesar do investimento inicial, a redução de retrabalho e de falhas costuma compensar em projetos de médio e grande porte.


Quais são os riscos?

Toda mudança traz desafios.

Os principais são:

Resistência cultural

O maior obstáculo raramente é técnico.

É comum ouvir:

"Sempre fizemos assim."

Sem apoio da liderança, a adoção perde força.

Automação mal planejada

Automatizar um processo ruim apenas faz o erro acontecer mais rápido.

Primeiro simplifique.

Depois automatize.

Falta de testes

Um pipeline sem testes é apenas um "copiador automático" de problemas.

Invista em testes desde o início.

Controle de acesso

Automações precisam respeitar políticas de segurança.

Integração com RACF, auditoria e segregação de funções são indispensáveis.

Dependência de poucas pessoas

Evite que apenas um especialista conheça o pipeline. Documente, treine a equipe e compartilhe conhecimento.


As grandes vantagens

Os benefícios aparecem rapidamente.

  • Menos erros manuais.

  • Entregas mais rápidas.

  • Maior rastreabilidade.

  • Rollback simplificado.

  • Melhor colaboração entre desenvolvimento e operações.

  • Qualidade de código mais alta.

  • Testes executados com frequência.

  • Auditoria facilitada.

  • Processos padronizados.

  • Redução do tempo de implantação.

  • Mais confiança para liberar novas versões.

  • Maior integração entre Mainframe e plataformas distribuídas.

Para ambientes regulados, como bancos e seguradoras, isso também significa maior conformidade e facilidade em auditorias.


E as desvantagens?

Nem tudo são flores.

  • Curva de aprendizado inicial.

  • Mudança cultural pode gerar resistência.

  • Necessidade de treinamento.

  • Tempo para configurar pipelines.

  • Investimento em ferramentas corporativas, quando necessário.

  • Ajustes em processos antigos.

  • Necessidade de governança para evitar pipelines desorganizados.

A boa notícia é que esses desafios diminuem à medida que a equipe ganha experiência.


Um exemplo prático

Imagine que uma alteração fiscal exige mudanças em um programa COBOL.

Sem DevOps:

  1. Desenvolvedor altera o código.

  2. Envia por e-mail.

  3. Outro profissional compila.

  4. Um terceiro faz o BIND.

  5. Alguém copia o módulo para homologação.

  6. Os testes são executados manualmente.

  7. A documentação é atualizada depois (ou esquecida).

  8. A implantação depende de uma janela operacional.

Com DevOps:

  1. O desenvolvedor cria uma branch.

  2. Implementa a alteração.

  3. Abre um Pull Request.

  4. O código passa por revisão.

  5. O pipeline compila automaticamente.

  6. Testes unitários e de integração são executados.

  7. A qualidade é validada pelo SonarQube.

  8. Após aprovação, o deploy é promovido para homologação.

  9. Com a autorização final, a mesma pipeline promove a versão para produção.

  10. Todo o processo fica registrado para auditoria.

Perceba que o COBOL continua sendo COBOL. O que mudou foi a forma de entregar software.


Conclusão

Durante muito tempo, DevOps foi visto como algo exclusivo do mundo Linux, Java e Cloud. Hoje sabemos que essa visão ficou no passado.

O IBM Z evoluiu. Ferramentas como Git, Zowe, IBM Dependency Based Build, Azure DevOps, Jenkins e pipelines de CI/CD permitem que aplicações COBOL participem do mesmo ciclo moderno de desenvolvimento utilizado nas demais plataformas da empresa.

Se você é um Padawan COBOL, não tente aprender tudo de uma vez. Comece pelo essencial: Git, versionamento, revisão de código e conceitos de integração contínua. Em seguida, avance para pipelines, automação de testes e deploy. Com essa base, ferramentas específicas do Mainframe farão muito mais sentido.

Lembre-se: DevOps não substitui o conhecimento de COBOL, JCL, CICS ou DB2. Ele potencializa esse conhecimento, reduzindo erros, aumentando a qualidade e permitindo que sistemas críticos evoluam com segurança.

No fim das contas, o maior legado do DevOps não é uma ferramenta nem um pipeline. É uma mudança de mentalidade: desenvolver, testar, implantar e operar como um único time, entregando valor continuamente para o negócio.

E esse, meu amigo Padawan, é um princípio que nunca ficará obsoleto.


PERFORM Recursivo em COBOL: O Warning que Todo Padawan Ignora (Até o Job Estourar o TIME e o REGION)

 

Bellacosa e o perigo do perform recursivo

☕ Um Café no Bellacosa Mainframe

PERFORM Recursivo em COBOL: O Warning que Todo Padawan Ignora (Até o Job Estourar o TIME e o REGION)

"Recursão é uma ferramenta fantástica... exceto quando você tenta usá-la como estrutura de repetição dentro de um programa COBOL Batch."

Quem vem de Java, C#, Python ou C costuma achar natural escrever funções recursivas.

Quem cresceu no COBOL aprende rapidamente uma regra quase sagrada:

Nunca faça um PERFORM recursivo em um parágrafo ou seção.

Mas por quê?

Vamos abrir o capô do compilador.


Primeiro: o que é um PERFORM recursivo?

Imagine algo assim:

0000-PRINCIPAL.

    PERFORM 1000-PROCESSA

    STOP RUN.

1000-PROCESSA.

    DISPLAY "PROCESSANDO"

    PERFORM 1000-PROCESSA.

O programa chama...

...que chama...

...que chama...

...que chama novamente...

Nunca termina.


O warning da compilação

O Enterprise COBOL consegue detectar algumas formas óbvias de recursão.

Durante a compilação pode surgir mensagens semelhantes a:

IGYPSxxxx-W

Recursive PERFORM detected.

ou

Possible recursive PERFORM.

O compilador está dizendo:

"Existe um caminho onde este PERFORM pode executar novamente antes do anterior terminar."

Nem sempre é erro.

Mas quase sempre indica problema de projeto.


Por que isso é perigoso?

Porque PERFORM não foi criado para funcionar como chamada infinita de procedimentos.

Cada PERFORM precisa guardar informações como:

  • endereço de retorno

  • contexto de execução

  • pilha de controle

  • informações internas do runtime

A cada nova chamada tudo isso cresce.

PERFORM A
    ↓
PERFORM A
    ↓
PERFORM A
    ↓
PERFORM A
    ↓
PERFORM A

A pilha nunca é liberada.


O que acontece durante a execução?

Enquanto houver memória:

Stack

+----------------+
| retorno        |
+----------------+
| retorno        |
+----------------+
| retorno        |
+----------------+
| retorno        |
+----------------+
| retorno        |
+----------------+

Cada PERFORM adiciona um novo frame.

Quando acaba a pilha...

Boom.


O programa pode terminar com

Dependendo do ambiente:

  • S0C1

  • S0C4

  • S0CB

  • S878

  • S80A

Ou simplesmente:

ABEND

Tudo depende de onde ocorreu a falha.


O erro de TIME no JCL

Muito antes da memória acabar...

o Job pode morrer por tempo.

Exemplo:

//STEP1 EXEC PGM=MEUPROG,TIME=1

ou

TIME=1440

Mesmo com TIME=1440...

o programa nunca termina.

O JES percebe que o tempo máximo foi atingido.

Resultado:

S322

Ou mensagens semelhantes indicando limite de CPU excedido.

Não foi o COBOL.

Foi o JCL protegendo o sistema.


O erro de REGION

Outro clássico.

Cada PERFORM recursivo consome mais memória.

Em algum momento:

REGION=0M

não resolve.

Porque memória infinita não existe.

O resultado costuma ser:

S878

ou

S80A

Falta de armazenamento.


"Mas REGION=0M não é infinito?"

Não.

É apenas o máximo permitido pela instalação.

Existe limite de:

  • memória virtual

  • stack

  • storage abaixo da linha

  • storage acima da linha

  • política do sistema

Nada disso é infinito.


O maior problema: lógica

Suponha:

1000-ROTINA.

    IF WS-FIM = 'N'
       PERFORM 1000-ROTINA
    END-IF.

Quem altera:

WS-FIM

Se ninguém alterar...

Nunca haverá saída.

É um loop infinito disfarçado.


Por que não usar recursão em parágrafos e seções?

Porque COBOL foi projetado para outro paradigma.

A linguagem nasceu para processamento sequencial.

Ela possui comandos próprios para repetição.

Como:

PERFORM UNTIL
PERFORM VARYING
SEARCH
SEARCH ALL

Essas estruturas:

  • são previsíveis

  • ocupam pouca memória

  • facilitam depuração

  • têm melhor desempenho


"Mas COBOL suporta recursão."

Sim.

Desde o Enterprise COBOL moderno existe:

RECURSIVE PROGRAM-ID.

ou

PROGRAM-ID. MEUPROG RECURSIVE.

Isso significa que o programa pode chamar a si próprio.

Exemplo clássico:

  • árvore binária

  • parsing

  • algoritmos matemáticos

  • estruturas hierárquicas

Mesmo assim...

Não significa que seja recomendado para processamento batch tradicional.


A diferença importante

Errado

Parágrafo
↓

PERFORM

↓

Mesmo parágrafo

Recursão interna.

Difícil de manter.


Correto

Programa A

CALL Programa A

Novo contexto

Retorna

Quando realmente houver necessidade de recursão.


Curiosidade

Os compiladores antigos praticamente desencorajavam qualquer tipo de recursão.

O foco sempre foi:

  • velocidade

  • previsibilidade

  • baixo consumo de memória

A maioria dos sistemas bancários jamais precisou de recursão.


Como um sênior resolveria?

Em vez disso:

PERFORM UNTIL WS-FIM = 'S'

    ...

END-PERFORM

ou

PERFORM VARYING IDX FROM 1 BY 1
        UNTIL IDX > TOTAL

Muito mais claro.

Muito mais rápido.

Muito mais seguro.


Boas práticas

✅ Prefira PERFORM UNTIL para laços controlados.

✅ Use PERFORM VARYING para contadores.

✅ Evite PERFORM chamando o próprio parágrafo.

✅ Revise IFs que nunca alteram a condição de saída.

✅ Analise os warnings do compilador; eles frequentemente apontam defeitos reais de lógica.

✅ Monitore consumo de CPU e storage no SDSF durante testes.

✅ Se precisar de recursão, utilize programas declarados RECURSIVE e valide cuidadosamente profundidade máxima e condição de parada.

✅ Sempre tenha uma condição de saída claramente identificável.


Dicas de depuração

Se um Job "não termina":

  1. Verifique se a CPU continua aumentando no SDSF.

  2. Procure PERFORMs que retornam ao mesmo parágrafo.

  3. Confirme se a variável de controle realmente muda.

  4. Ative SSRANGE em ambiente de teste para detectar erros relacionados a índices e referências inválidas.

  5. Gere um compile listing (LIST, MAP, XREF) para acompanhar o fluxo de chamadas.

  6. Revise mensagens do compilador; um warning ignorado hoje pode virar um ABEND amanhã.


Caminho para o Padawan COBOL

Antes de pensar em recursão, domine completamente:

  1. PERFORM

  2. PERFORM THRU

  3. PERFORM UNTIL

  4. PERFORM VARYING

  5. Estrutura de parágrafos e seções

  6. Escopo explícito (END-IF, END-PERFORM)

  7. Fluxo estruturado sem GO TO

  8. Subprogramas com CALL

  9. Programas RECURSIVE apenas quando o problema realmente exigir

Quando você entender por que o COBOL prefere estruturas iterativas, começará a enxergar o sistema como os arquitetos do IBM Z enxergam: programas previsíveis, eficientes e fáceis de manter. Em ambientes que processam milhões de transações por dia, previsibilidade vale muito mais do que elegância acadêmica.


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

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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

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