 |
| Bellacosa Mainframe e o cobol um codigo de 65 anos que continua na ativa |
☕ Um Café no Bellacosa Mainframe
COBOL: O Mundo Depende de um Código de Quase 65 Anos que Ninguém Conhece Mais
Quando os programadores abriram o sarcófago do sistema legado, descobriram que o cadáver continuava processando a folha de pagamento
Naquela madrugada, o último programador COBOL da empresa recebeu uma ligação.
O sistema central havia parado.
Milhares de pagamentos estavam presos. As agências não conseguiam consultar contas. Os arquivos da compensação aguardavam processamento. Na sala de crise, dezenas de especialistas examinavam painéis modernos, APIs coloridas e dashboards brilhantes.
Mas ninguém sabia abrir o programa que controlava tudo.
O código havia sido escrito antes de muitos daqueles profissionais nascerem.
O telefone tocou novamente.
Do outro lado da linha, uma voz perguntou:
— Ainda existe alguém que entende COBOL?
O velho programador olhou para o terminal verde.
E respondeu:
— Existe. Mas vocês passaram trinta anos fingindo que não precisavam de nós.*
O monstro que deveria ter morrido
As revistas de terror dos anos 1950 adoravam histórias sobre criaturas que se recusavam a permanecer enterradas.
Um cientista encontrava um cadáver.
Aplicava eletricidade.
A criatura abria os olhos.
O laboratório pegava fogo.
E, na última página, o leitor descobria que o verdadeiro monstro não era o cadáver ressuscitado.
Era a arrogância do cientista.
A história do COBOL possui algo dessa atmosfera.
Durante décadas, consultorias, jornalistas, fornecedores e futuristas anunciaram sua morte. A cada nova geração tecnológica aparecia alguém disposto a escrever o epitáfio definitivo:
“Agora o COBOL será substituído.”
Vieram as linguagens estruturadas.
Vieram os computadores pessoais.
Vieram os sistemas cliente-servidor.
Veio a internet.
Vieram Java, .NET, os microsserviços, a computação em nuvem, os containers e a inteligência artificial.
O COBOL ouviu todos os discursos.
Depois voltou ao trabalho.
Em 2026, o COBOL não tem “quase 65 anos”. Sua criação começou em 1959, o que significa que sua história já atravessa aproximadamente 67 anos. A primeira versão da linguagem foi disponibilizada em 1960. Ela nasceu de um esforço colaborativo ligado ao CODASYL, inspirado parcialmente no FLOW-MATIC de Grace Hopper e voltado ao processamento comercial portátil entre diferentes computadores. (IBM)
Esse detalhe torna a história ainda mais impressionante.
O mundo não depende simplesmente de uma linguagem antiga.
Depende de uma linguagem criada quando:
computadores ocupavam salas inteiras;
programas eram frequentemente introduzidos por cartões perfurados;
não existiam microprocessadores;
a internet moderna não existia;
a chegada do homem à Lua ainda estava no futuro;
grande parte da população mundial jamais havia visto um computador.
E, apesar disso, inúmeros sistemas escritos ou evoluídos a partir dessa tradição continuam executando atividades críticas.
O cadáver não apenas abriu os olhos.
Ele continua fechando o movimento financeiro da madrugada.
Capítulo I — A cidade moderna construída sobre catacumbas
Imagine uma pessoa utilizando um aplicativo bancário.
Ela abre o celular.
Consulta o saldo.
Paga uma conta.
Faz uma transferência.
Compra uma passagem.
Contrata um seguro.
Recebe o salário.
Tudo parece novo.
A interface possui ícones modernos, animações suaves, reconhecimento biométrico e notificações instantâneas.
Mas a aparência do aplicativo não revela necessariamente onde a lógica central do negócio está sendo executada.
Por trás da tela pode existir uma cadeia semelhante a esta:
CLIENTE
│
▼
APLICATIVO MÓVEL
│
▼
API GATEWAY
│
▼
SERVIÇO JAVA / MICROSSERVIÇO
│
▼
IBM MQ OU OUTRA CAMADA DE INTEGRAÇÃO
│
▼
CICS OU IMS
│
▼
PROGRAMA COBOL
│
▼
DB2, VSAM OU IMS DB
│
▼
REGRA CENTRAL DO NEGÓCIO
O cliente enxerga apenas o andar mais recente do edifício.
O COBOL pode estar nas fundações.
Essa é a primeira grande revelação da nossa revista de horror: modernização visual não significa necessariamente substituição do núcleo transacional.
Uma empresa pode criar aplicativos modernos, APIs REST, portais Web, assistentes de inteligência artificial e experiências móveis sem remover imediatamente os programas que conhecem as regras mais profundas do negócio.
O aplicativo sabe exibir um botão.
O programa central sabe se aquela operação pode ou não acontecer.
Capítulo II — “Ninguém conhece mais” é verdade?
A frase é propositalmente assustadora:
“O mundo depende de um código que ninguém conhece mais.”
Mas ela precisa ser examinada com cuidado.
Não é verdade que literalmente ninguém conheça COBOL.
Existem milhares de profissionais, comunidades, empresas, universidades, cursos e iniciativas de capacitação. O Open Mainframe Project, por exemplo, mantém um curso aberto de programação COBOL com material educacional e experiências práticas utilizando ferramentas modernas. (Open Mainframe Project)
O problema real é mais sutil — e talvez mais perigoso.
Muitas organizações possuem sistemas que:
foram construídos durante décadas;
receberam alterações de centenas de profissionais;
incorporaram regras que não estão totalmente documentadas;
dependem de programas, arquivos, transações e rotinas interligadas;
perderam parte dos especialistas que acompanharam sua evolução;
são conhecidos profundamente por um grupo cada vez menor de pessoas.
Portanto, o horror não é a ausência total de programadores COBOL.
O horror é a perda do conhecimento contextual.
Conhecer a sintaxe da linguagem não significa conhecer o sistema.
Um estudante pode aprender rapidamente que este comando soma um valor:
ADD WS-VALOR TO WS-TOTAL.
Mas somente a experiência com a aplicação revelará:
de onde vem
WS-VALOR;o que representa
WS-TOTAL;quais exceções comerciais se aplicam;
se o valor está em reais ou centavos;
quais programas dependem desse resultado;
quais arquivos serão atualizados;
qual transação chamou o módulo;
quais controles de auditoria devem ser registrados;
o que acontece em caso de rollback;
quais consequências surgem se o cálculo estiver errado.
A sintaxe é o mapa da entrada.
O conhecimento do negócio é o mapa das catacumbas.
Capítulo III — O código não envelhece como um corpo humano
Existe uma ideia enganosa segundo a qual software envelhece exatamente como máquinas físicas.
Um automóvel de 1959 sofre ferrugem.
Peças se desgastam.
Mangueiras racham.
O motor perde compressão.
Código-fonte não envelhece dessa forma.
Uma instrução não se desgasta porque foi executada um bilhão de vezes.
Considere:
IF SALDO-DISPONIVEL >= VALOR-SOLICITADO
PERFORM AUTORIZAR-OPERACAO
ELSE
PERFORM RECUSAR-OPERACAO
END-IF.
Se essa regra está correta, testada e atende ao negócio, sua idade cronológica não a torna automaticamente defeituosa.
O que envelhece ao redor do código?
os requisitos;
as interfaces;
os formatos de dados;
os compiladores;
as práticas de desenvolvimento;
as dependências;
a documentação;
o conhecimento das equipes;
a facilidade de manutenção;
a arquitetura em que o programa está inserido.
Portanto, o problema não é simplesmente dizer:
“Este programa tem quarenta anos.”
A pergunta correta é:
“Este programa ainda atende ao negócio, pode ser mantido com segurança, está bem testado e possui uma arquitetura sustentável?”
Um programa antigo pode estar sólido.
Um microsserviço escrito na semana passada pode ser um desastre.
Juventude não é sinônimo de qualidade.
Idade não é sinônimo de obsolescência.
Capítulo IV — O segredo dentro do sarcófago: regras de negócio
Quando uma empresa observa milhões de linhas de COBOL, pode acreditar que está olhando apenas para código.
Não está.
Está olhando para história institucional condensada.
Dentro daqueles programas podem existir regras como:
cálculo de tarifas;
incidência de juros;
processamento de impostos;
critérios de elegibilidade;
limites de crédito;
períodos de carência;
contratos antigos;
exceções regulatórias;
tratamento de feriados;
arredondamentos financeiros;
regras específicas para determinados clientes;
mudanças legais acumuladas ao longo de décadas.
Imagine uma seguradora com um programa criado originalmente nos anos 1980.
Ao longo dos anos, ele foi alterado para acomodar:
1984 — nova categoria de contrato
1988 — mudança constitucional
1994 — nova moeda
1999 — alteração tributária
2002 — produto adicional
2008 — nova regra de risco
2015 — adequação regulatória
2020 — operação emergencial
2024 — integração com API
2026 — análise assistida por IA
Ao final desse processo, o sistema não contém apenas algoritmos.
Ele contém a arqueologia da empresa.
Substituí-lo exige mais do que converter comandos de uma linguagem para outra.
É necessário descobrir o significado de cada regra, inclusive daquelas que ninguém mais se lembra de ter solicitado.
Capítulo V — O programa que ninguém ousava apagar
Em algum ponto de toda grande aplicação existe uma rotina semelhante à sala proibida de uma mansão.
Todos sabem que ela existe.
Ninguém gosta de alterá-la.
A documentação diz apenas:
“Não modificar sem consultar a equipe responsável.”
O problema é que a equipe responsável deixou de existir em 1998.
O programa continua sendo executado.
Talvez ele tenha um nome como:
PGMCL093
Ninguém sabe exatamente por que o número 93 foi escolhido.
Dentro dele aparece:
IF WS-TIPO-CLIENTE = '7'
AND WS-CODIGO-ESPECIAL NOT = 'X'
AND WS-DATA-BASE < 19940701
MOVE 'S' TO WS-ISENCAO
END-IF.
O jovem programador pergunta:
— Por que clientes do tipo 7 recebem isenção antes de 1º de julho de 1994?
Silêncio.
Alguém responde:
— Sempre funcionou assim.
Esse é o momento em que a manutenção deixa de ser apenas programação e se transforma em investigação.
O código apresenta o que.
Nem sempre explica o porquê.
Remover aquela condição pode parecer uma limpeza.
Mas talvez ela proteja contratos antigos, decisões judiciais, benefícios adquiridos ou registros históricos.
Uma linha aparentemente inútil pode ser a última testemunha de uma regra que a organização esqueceu.
Capítulo VI — A maldição da reescrita total
Quando executivos encontram sistemas antigos, uma ideia surge como o plano perfeito do cientista ambicioso:
“Vamos reescrever tudo do zero.”
Em uma apresentação, o plano parece impecável:
COBOL ANTIGO
↓
ANÁLISE AUTOMÁTICA
↓
CONVERSÃO
↓
JAVA, C# OU NUVEM
↓
PROBLEMA RESOLVIDO
Mas sistemas críticos não são simples blocos de texto.
Uma reescrita precisa preservar:
resultados;
regras;
arredondamentos;
formatos;
tempos de processamento;
integrações;
sequências de atualização;
tratamento de falhas;
segurança;
auditoria;
recuperação;
compatibilidade com dados históricos;
comportamento em situações excepcionais.
Considere um cálculo financeiro:
COMPUTE VALOR-LIQUIDO ROUNDED =
VALOR-BRUTO - TAXA - IMPOSTO.
Uma tradução sintaticamente correta para outra linguagem não garante comportamento idêntico.
Pode haver diferenças em:
representação decimal;
precisão;
arredondamento;
overflow;
tratamento de sinal;
campos compactados;
conversão de caracteres;
ordenação;
datas;
valores ausentes.
O programa convertido compila.
Os testes básicos passam.
Mas uma diferença de um centavo aparece somente em determinada combinação de contrato, data e categoria.
Multiplique um centavo por milhões de operações.
O pequeno fantasma ganha corpo.
Capítulo VII — COBOL não trabalha sozinho
Outro erro comum é imaginar que preservar profissionais COBOL resolve todo o problema.
Não resolve.
Uma aplicação Mainframe costuma depender de uma stack inteira:
COBOL
├── JCL
├── CICS
├── IMS
├── Db2
├── VSAM
├── IBM MQ
├── RACF
├── SORT
├── JES2
├── SDSF
├── SMF
├── WLM
├── DFSMS
└── z/OS
O programador pode dominar a lógica COBOL e ainda assim precisar entender:
como o job foi submetido;
qual dataset foi utilizado;
qual versão do módulo está carregada;
qual package do Db2 foi associado;
qual plano está executando;
qual fila recebeu a mensagem;
qual transação CICS iniciou o programa;
qual autorização RACF foi negada;
qual step retornou código diferente de zero;
qual arquivo VSAM sofreu contenção;
qual política do WLM alterou a prioridade;
qual mudança de produção introduziu o problema.
COBOL é um cômodo da mansão.
O profissional precisa conhecer os corredores.
Capítulo VIII — O mundo depende do COBOL ou das aplicações?
Aqui precisamos separar a propaganda da engenharia.
O mundo não depende de cada programa COBOL existente.
Há programas desnecessários, duplicados, mal projetados, pouco utilizados ou prontos para aposentadoria.
Também existem sistemas COBOL que podem ser substituídos com segurança.
A afirmação mais correta é:
Partes importantes da economia e da administração corporativa ainda dependem de aplicações críticas construídas, mantidas ou evoluídas em COBOL.
A própria IBM descreve o COBOL como uma linguagem orientada aos negócios utilizada em operações econômicas cotidianas invisíveis e em processos de missão crítica. O Enterprise COBOL para z/OS continua sendo oferecido como compilador empresarial destinado à modernização de aplicações críticas. (@ibmdeveloper)
Essa distinção é importante.
Não devemos transformar COBOL em religião.
Também não devemos tratá-lo como sucata apenas por causa de sua idade.
A decisão precisa considerar:
custo;
risco;
criticidade;
capacidade de manutenção;
estratégia empresarial;
disponibilidade de profissionais;
qualidade dos testes;
acoplamento;
volume de processamento;
metas de modernização.
Em alguns casos, manter é sensato.
Em outros, modernizar gradualmente é melhor.
Em certos sistemas, substituir será necessário.
O erro está nas decisões automáticas.
Capítulo IX — Por que as novas gerações não aprenderam?
O desaparecimento gradual do conhecimento COBOL não aconteceu por acidente.
Durante anos, muitos estudantes ouviram:
“Não aprenda isso. Está morrendo.”
As universidades reduziram o espaço dedicado ao processamento corporativo clássico.
Os cursos rápidos preferiram tecnologias que produziam interfaces visuais em poucas aulas.
As empresas deixaram de formar profissionais internamente.
Especialistas experientes se aposentaram.
Documentações permaneceram desatualizadas.
Projetos de substituição foram anunciados, adiados e novamente anunciados.
O resultado foi um paradoxo:
EMPRESAS DIZEM QUE COBOL NÃO TEM FUTURO
+
EMPRESAS CONTINUAM EXECUTANDO COBOL
+
EMPRESAS DEIXAM DE TREINAR PESSOAS
=
FALTA DE PROFISSIONAIS
A escassez não prova que a linguagem seja impossível de aprender.
Prova que o pipeline de formação foi negligenciado.
Nenhuma tecnologia sobrevive apenas por possuir bons compiladores.
Ela precisa de pessoas.
Capítulo X — O último programador não é um feiticeiro
Existe uma tendência perigosa de transformar o especialista veterano em figura mística.
Ele é chamado quando:
o fechamento falha;
o arquivo não fecha;
o saldo fica inconsistente;
o batch ultrapassa a janela;
uma transação recebe ABEND;
ninguém entende determinada regra.
O veterano observa três mensagens, consulta um dump e identifica o problema.
Todos ficam impressionados.
Mas aquilo que parece magia geralmente é conhecimento acumulado:
convenções de nomes;
histórico de incidentes;
padrões recorrentes;
arquitetura;
regras comerciais;
relações entre programas;
comportamento do ambiente.
O objetivo de uma organização madura não deve ser manter um feiticeiro indispensável.
Deve ser transformar o conhecimento individual em capacidade coletiva.
Isso exige:
documentação;
revisão de código;
mentoria;
programação em pares;
mapas de dependências;
inventário de aplicações;
testes automatizados;
gravação de sessões técnicas;
rotação de responsabilidades;
comunidades internas;
formação contínua.
Quando apenas uma pessoa sabe como o sistema funciona, o problema não é o COBOL.
É a governança.
Capítulo XI — Inteligência artificial: o novo caçador de fantasmas
A inteligência artificial pode ajudar a investigar grandes bases COBOL.
Ela pode apoiar tarefas como:
explicar trechos de código;
resumir parágrafos;
sugerir documentação;
identificar dependências;
gerar casos de teste;
localizar padrões repetidos;
auxiliar conversões;
relacionar programas e copybooks;
produzir diagramas;
acelerar a integração de novos profissionais.
Mas existe uma diferença entre explicar a estrutura de uma rotina e compreender completamente sua intenção empresarial.
Uma IA pode observar:
IF DATA-CONTRATO < DATA-CORTE
MOVE TAXA-ANTIGA TO TAXA-APLICADA
ELSE
MOVE TAXA-NOVA TO TAXA-APLICADA
END-IF.
Ela provavelmente explicará:
“O programa seleciona uma taxa com base na data do contrato.”
Correto.
Mas ainda restam perguntas:
quem definiu a data de corte?
a regra decorre de uma lei?
existem exceções?
contratos renegociados mantêm a taxa antiga?
a data está em calendário local?
o comportamento foi validado pelo setor jurídico?
outros programas repetem a mesma lógica?
A IA acende uma lanterna poderosa.
Ela não substitui automaticamente o mapa do castelo.
Capítulo XII — Como impedir que o conhecimento desapareça
Uma organização que depende de COBOL precisa tratar conhecimento como ativo estratégico.
1. Inventariar
Descobrir:
quantos programas existem;
quais são executados;
quais estão abandonados;
quais são críticos;
quais copybooks compartilham;
quais tabelas e arquivos acessam;
quais sistemas os chamam.
2. Mapear dependências
Criar relações como:
JOB FATURA01
└── STEP010
└── PROGRAMA FATC100
├── COPYBOOK CLI001
├── DB2 TABELA CLIENTE
├── DB2 TABELA FATURA
└── MQ FILA NOTIFICACAO
3. Documentar regras
Não apenas:
“Este parágrafo calcula juros.”
Mas:
“Calcula juros para contratos anteriores à mudança regulatória de determinada data, preservando a metodologia prevista no produto original.”
4. Automatizar testes
Antes de alterar um programa, registrar seu comportamento esperado.
Casos comuns.
Casos extremos.
Valores nulos.
Datas críticas.
Limites.
Erros.
Reprocessamentos.
5. Formar sucessores
Um especialista sem aprendiz representa conhecimento com data de expiração.
6. Modernizar ferramentas
COBOL pode ser desenvolvido com:
editores modernos;
Git;
pipelines;
testes automatizados;
análise estática;
integração contínua;
APIs;
observabilidade.
Preservar a linguagem não exige preservar todos os métodos de trabalho de 1975.
Capítulo XIII — O estudante diante da porta proibida
Para um jovem universitário, COBOL pode parecer uma escolha estranha.
Seus colegas falam sobre:
inteligência artificial;
Python;
aplicações móveis;
jogos;
realidade virtual;
startups;
nuvem.
Então ele encontra uma vaga mencionando:
COBOL
JCL
CICS
DB2
VSAM
IBM MQ
z/OS
Parece uma mensagem enviada por outra época.
Mas ali existe uma oportunidade rara.
Aprender COBOL pode ensinar algo que muitos cursos rápidos não mostram:
processamento de grandes volumes;
precisão decimal;
estruturas de registros;
transações;
integridade;
recuperação;
batch;
segurança;
desempenho;
sistemas de missão crítica;
responsabilidade operacional.
O estudante não precisa abandonar tecnologias modernas.
Ele pode se tornar a ponte.
COBOL + APIs
COBOL + JAVA
COBOL + PYTHON
COBOL + CLOUD
COBOL + DEVOPS
COBOL + IA
O profissional mais valioso não será necessariamente aquele que vive apenas no passado.
Será aquele capaz de conectar décadas diferentes sem destruir o que mantém a empresa funcionando.
Arquivo secreto: três mitos enterrados no cemitério
Mito 1 — “COBOL é lento”
A velocidade de uma aplicação depende de diversos fatores:
algoritmo;
acesso a dados;
compilação;
arquitetura;
I/O;
SQL;
volume;
configuração;
contenção.
Uma aplicação mal projetada pode ser lenta em qualquer linguagem.
Mito 2 — “Migrar COBOL significa traduzir comandos”
Não.
Migrar envolve reconstruir comportamento, integrações, dados, operações, segurança e conhecimento de negócio.
Mito 3 — “Manter COBOL significa rejeitar inovação”
Também não.
Uma aplicação COBOL pode ser:
exposta por APIs;
integrada com eventos;
incluída em CI/CD;
observada por ferramentas modernas;
acessada por aplicações móveis;
conectada a serviços de IA.
Modernização não é sinônimo obrigatório de reescrita.
Easter egg — A lápide que errou o enterro
Durante o desenvolvimento do COBOL, o integrante Howard Bromberg produziu uma lápide humorística, antecipando que a linguagem não teria futuro. A peça tornou-se parte da coleção do Computer History Museum. O epitáfio falhou de maneira espetacular: décadas depois, COBOL continuava presente em sistemas críticos. (CHM)
Talvez essa seja a maior piada interna da história da programação.
A linguagem recebeu uma lápide antes mesmo de viver plenamente.
Depois sobreviveu a muitos dos sistemas que deveriam substituí-la.
Conclusão — O verdadeiro horror não está no código
Na última página da revista, a equipe finalmente desce ao subsolo do edifício.
Encontra armários, diagramas, fitas, manuais e milhares de programas.
No centro da sala existe um terminal ainda ligado.
Na tela, uma mensagem:
PROCESSAMENTO CONCLUÍDO COM SUCESSO
RETURN CODE = 0000
O jovem programador se aproxima.
— Então o sistema ainda funciona?
O veterano responde:
— Funciona.
— E por que todos estão com medo?
O velho profissional aponta para uma estante vazia.
— Porque ali ficava a documentação.
O terror do COBOL não está em sua idade.
Não está em sua sintaxe.
Não está nas colunas antigas, nos parágrafos ou nos nomes escritos em letras maiúsculas.
O verdadeiro horror nasce quando uma sociedade depende de sistemas que conhece apenas superficialmente.
Nasce quando empresas mantêm aplicações críticas, mas deixam de formar pessoas.
Quando substituem documentação por memória individual.
Quando confundem interface moderna com arquitetura moderna.
Quando acreditam que uma ferramenta automática pode reconstruir décadas de regras empresariais sem investigação, testes e participação humana.
O COBOL começou a ser desenvolvido em 1959 e continua sendo utilizado porque resolveu — e ainda resolve — problemas fundamentais do processamento corporativo. (IBM)
Ele não é um morto-vivo.
É uma linguagem que envelheceu junto com as instituições que ajudou a construir.
O problema nunca foi o código antigo.
O problema é o conhecimento que permitimos desaparecer ao redor dele.
Quando o último especialista apagar a luz e fechar a porta do CPD, o sistema provavelmente continuará funcionando.
Por algum tempo.
Executará jobs.
Atualizará contas.
Processará contratos.
Calculará valores.
Responderá transações.
Até a noite em que algo inesperado acontecer.
Então os telefones tocarão.
As telas ficarão vermelhas.
A sala de crise será aberta.
E alguém fará a pergunta que nenhuma empresa deveria esperar para responder:
“Quem ainda conhece este código?”
Do fundo da Torre Invisível, talvez venha apenas o ruído dos discos, o brilho verde de um terminal abandonado e uma última mensagem piscando na escuridão:
PROGRAMMER NOT FOUND.
--------------------------------------------------------------------------------------------
Sem comentários:
Enviar um comentário