 |
| Bellacosa Mainframe e a guerra ao Goto e uma visão da IA |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🚨 DIJKSTRA CONTRA A CRISE DO COBOL: O HOMEM QUE DECLAROU GUERRA AO GOTO VOLTA PARA JULGAR A INTELIGÊNCIA ARTIFICIAL!
Em 1968, Edsger W. Dijkstra desafiou os programadores a abandonarem o código desestruturado. Em 2026, a inteligência artificial promete traduzir sistemas COBOL que movimentam bilhões. Mas quem garante que o programa traduzido continua correto? Uma investigação sobre 67 anos de COBOL, programação estruturada, IBM Z e o perigo de entregar a lógica bancária às máquinas sem compreender o que elas fazem.
Bellacosa Mainframe — Arqueologia da Computação, COBOL, IBM Z, Inteligência Artificial e os Mistérios da Engenharia de Software.
🎬 Prólogo — 03h17: o fantasma de Dijkstra apareceu no CPD
São três horas e dezessete minutos da madrugada.
Em algum lugar do planeta, um mainframe IBM Z continua trabalhando.
No seu interior, milhares de programas COBOL executam cálculos financeiros, atualizam registros, processam pagamentos e alimentam sistemas que não podem simplesmente parar.
Numa das salas do Centro de Processamento de Dados, um jovem programador observa uma mensagem recém-produzida por uma inteligência artificial:
MIGRAÇÃO COBOL PARA JAVA CONCLUÍDA COM SUCESSO.
O programa original possui 18.432 linhas.
A versão produzida pela IA contém 7.216.
O processo levou poucos minutos.
O jovem sorri.
— Acabamos de modernizar quarenta anos de tecnologia!
De repente, uma voz surge atrás dele.
— Modernizar? Interessante. E como você demonstrou que o novo programa está correto?
O rapaz se vira.
Diante de um terminal 3270 está um senhor de óculos, expressão severa e uma folha de papel coberta de símbolos matemáticos.
— Quem é o senhor?
— Meu nome é Edsger W. Dijkstra.
— O famoso inimigo do GOTO?
— Prefiro pensar que sou amigo dos programas que podemos compreender.
Dijkstra aponta para o relatório da inteligência artificial.
— Quantos testes foram executados?
— Quatrocentos e vinte.
— E quantas possibilidades de comportamento existem?
Silêncio.
— O sistema possui registros redefinidos? Campos decimais compactados? Transações concorrentes? Processos batch? Regras de arredondamento? Dependências externas?
— Sim...
— Então por que você acredita que quatrocentos e vinte testes demonstram a equivalência de quarenta anos de regras empresariais?
O jovem olha novamente para a tela.
Pela primeira vez naquela madrugada, a palavra SUCESSO parece assustadora.
Nota: este prólogo é uma dramatização fictícia. Dijkstra faleceu em 2002. Suas intervenções neste artigo são reconstruções literárias inspiradas em suas ideias, não declarações históricas.
🧠 Capítulo I — Quem foi Edsger W. Dijkstra, o homem que queria ensinar computadores a obedecer à razão?
Edsger Wybe Dijkstra nasceu em 11 de maio de 1930, em Roterdã, nos Países Baixos.
Estudou matemática e física, tornando-se um dos pioneiros da ciência da computação numa época em que programar computadores ainda parecia uma atividade experimental.
Naqueles primeiros anos, computadores eram caros, difíceis de operar e muito limitados.
A memória era pequena. O processamento era lento. Os programadores precisavam administrar cuidadosamente cada recurso.
Mas Dijkstra percebeu algo extraordinário.
O maior obstáculo ao desenvolvimento de software complexo não seria apenas a velocidade dos computadores.
Seria a incapacidade humana de compreender sistemas excessivamente complicados.
Essa percepção atravessaria toda a sua carreira.
Entre suas contribuições mais conhecidas estão:
O algoritmo de Dijkstra para encontrar caminhos de custo mínimo em grafos.
Trabalhos fundamentais sobre programação estruturada.
O desenvolvimento do conceito de semáforos para sincronização de processos.
Estudos sobre concorrência, exclusão mútua e deadlocks.
Métodos de raciocínio matemático sobre a correção dos programas.
Contribuições à programação baseada em invariantes e condições formais.
Em 1972, recebeu o Prêmio Turing da ACM, uma das maiores distinções da computação.
Dijkstra não acreditava que a engenharia de software pudesse evoluir indefinidamente apenas escrevendo mais instruções e corrigindo defeitos posteriormente.
Para ele, construir um programa significava desenvolver um raciocínio cujo comportamento pudesse ser compreendido e justificado.
Essa perspectiva é especialmente importante no mundo de 2026.
Porque, quando uma inteligência artificial produz milhares de linhas de código em segundos, o problema humano deixa de ser somente escrever instruções.
Passa a ser compreender, controlar e validar o resultado.
🔎 Curiosidade: Dijkstra não foi apenas o homem do GOTO
Muitos estudantes conhecem Dijkstra exclusivamente por sua crítica ao comando GOTO.
Isso é como estudar Albert Einstein e acreditar que sua contribuição científica foi apenas escrever uma equação famosa.
Dijkstra ajudou a estabelecer fundamentos de engenharia para programas concorrentes e algoritmos.
Suas ideias continuam relevantes em bancos de dados, sistemas operacionais, redes, computação distribuída e ambientes transacionais.
Inclusive no IBM Z.
📜 Capítulo II — 1959: nasce o COBOL, a linguagem que se recusou a desaparecer
Nossa aventura precisa voltar a 1959.
Os computadores empresariais estavam começando a transformar organizações.
Bancos, seguradoras, governos e grandes empresas precisavam automatizar atividades administrativas.
Folhas de pagamento, faturamento, estoques, contabilidade e registros financeiros exigiam processamento confiável.
A maioria das linguagens de programação disponíveis estava fortemente associada às características técnicas dos computadores.
Surgia, então, um desafio.
Era necessário desenvolver uma linguagem mais apropriada ao processamento empresarial, capaz de representar registros, valores monetários e operações administrativas de maneira relativamente legível.
Assim nasceu o COBOL, sigla para Common Business-Oriented Language.
Sua origem está associada ao comitê CODASYL e ao trabalho de diversos pioneiros. Grace Hopper teve influência importante por seus trabalhos anteriores sobre linguagens comerciais, embora não tenha sido a única criadora do COBOL.
A proposta era ambiciosa.
Permitir que programas empresariais fossem escritos numa linguagem menos dependente de uma máquina específica.
Veja um exemplo simples:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "BELLACOSA MAINFRAME"
GOBACK.
Mesmo uma pessoa sem experiência em programação consegue perceber que o programa exibirá uma mensagem.
Essa legibilidade aproximada da língua inglesa foi uma das características marcantes do COBOL.
Mas a facilidade aparente de ler instruções não elimina a complexidade de compreender um sistema inteiro.
E foi justamente nesse ponto que Dijkstra teria uma crítica profunda a oferecer.
⚔️ Capítulo III — 1968: Dijkstra declara guerra ao GOTO
Em março de 1968, Dijkstra publicou uma carta na revista Communications of the ACM que se tornaria histórica:
Go To Statement Considered Harmful.
Em português: O comando GOTO considerado prejudicial.
Seu argumento não era simplesmente uma preferência estética.
Ele examinava a relação entre a estrutura textual de um programa e a capacidade humana de acompanhar seu comportamento durante a execução.
Considere este exemplo didático de COBOL com saltos desnecessários:
PROCEDURE DIVISION.
INICIO.
MOVE 100 TO WS-VALOR
GO TO CALCULO.
FINAL.
GOBACK.
CALCULO.
COMPUTE WS-VALOR =
WS-VALOR * 2
GO TO FINAL.
Um programa pequeno como esse é fácil de acompanhar.
Mas imagine milhares de parágrafos, centenas de saltos e condições capazes de alterar a ordem de execução.
O programador precisaria construir mentalmente um mapa de todas as rotas possíveis.
Agora considere a mesma ideia organizada de maneira estruturada:
PROCEDURE DIVISION.
MOVE 100 TO WS-VALOR
PERFORM CALCULO
GOBACK.
CALCULO.
COMPUTE WS-VALOR =
WS-VALOR * 2.
O código agora apresenta uma sequência mais evidente.
Existe um fluxo principal e uma rotina chamada explicitamente.
A diferença parece pequena.
Entretanto, em sistemas grandes, estruturas previsíveis ajudam a reduzir a quantidade de caminhos de execução que o programador precisa compreender simultaneamente.
📚 O que significa programação estruturada?
A programação estruturada organiza algoritmos principalmente por três mecanismos fundamentais:
Sequência: executar instruções numa ordem determinada.
Seleção: escolher caminhos por meio de condições, como IF e EVALUATE.
Repetição: executar operações repetidamente por meio de estruturas como PERFORM UNTIL.
Esses mecanismos permitem construir programas complexos sem depender de saltos arbitrários entre diferentes regiões do código.
Isso não significa que todo programa estruturado esteja correto.
Significa que sua organização facilita o raciocínio sobre o comportamento.
🥚 Easter egg histórico
Existe uma ironia maravilhosa envolvendo o artigo de 1968.
O título original proposto por Dijkstra era A Case against the GO TO Statement.
Foi o editor Niklaus Wirth quem alterou o título para Go To Statement Considered Harmful.
Décadas depois, Dijkstra relatou essa história no documento EWD1308.
A expressão Considered Harmful acabaria se tornando um dos modelos de títulos mais imitados na história da informática.
Eis uma proposta de título que provavelmente caberia perfeitamente em 2026:
Blind AI Code Generation Considered Harmful.
Ou, em português:
Geração cega de código por inteligência artificial considerada prejudicial.
Não é um artigo real de Dijkstra, mas resume uma crítica que podemos construir a partir de seus princípios.
💣 Capítulo IV — A surpresa: Dijkstra também atacou o COBOL!
Aqui encontramos um detalhe histórico que seria desonesto esconder.
Dijkstra não era exatamente um admirador da linguagem COBOL.
Em 1975, no texto How do we tell truths that might hurt?, ele fez uma crítica extraordinariamente severa ao ensino e ao uso da linguagem.
Sua formulação chegou a classificar o ensino de COBOL como algo que deveria ser tratado como uma infração criminosa.
A declaração era deliberadamente provocativa.
Dijkstra criticava várias linguagens que, na sua avaliação, dificultavam o desenvolvimento de bons hábitos intelectuais de programação.
Isso inclui também críticas a BASIC, PL/I e APL.
Portanto, apresentar Dijkstra como defensor histórico do COBOL seria incorreto.
Mas existe algo muito interessante nessa oposição.
Podemos utilizar os princípios de Dijkstra para melhorar programas COBOL, mesmo que ele próprio rejeitasse a linguagem.
A crítica histórica também precisa ser colocada em seu contexto.
O COBOL de 1975 não representa todas as possibilidades dos compiladores e padrões modernos.
A linguagem evoluiu. Ganhou recursos estruturados, novas funcionalidades, integração com bancos de dados, orientação a objetos em determinados ambientes e ferramentas de desenvolvimento mais sofisticadas.
Dijkstra provavelmente continuaria exigente quanto à qualidade do raciocínio envolvido.
E essa exigência é exatamente o que torna sua filosofia útil para discutir a atual crise dos sistemas legados.
🏦 Capítulo V — 2026: a crise do COBOL invade os bancos
No dia 8 de novembro de 2026, o Canaltech publicou uma reportagem sobre a chamada crise do COBOL e o papel da inteligência artificial na modernização de sistemas.
O problema envolve três fenômenos interligados.
Primeiro, organizações continuam dependendo de aplicações desenvolvidas durante décadas.
Segundo, muitos profissionais responsáveis por sua construção e manutenção estão se aposentando.
Terceiro, parte considerável do conhecimento empresarial está incorporada ao próprio código, sem documentação suficientemente atualizada.
Imagine um sistema de financiamento criado em 1988.
Originalmente, sua função era calcular prestações, registrar pagamentos e produzir demonstrativos.
Durante os anos seguintes, recebeu modificações para atender diferentes produtos, mudanças tributárias, procedimentos regulatórios e exigências operacionais.
Em 2026, talvez o programa original ainda esteja executando sua função.
O problema é que ninguém consegue explicar completamente por que ele contém determinadas condições.
Uma variável chamada WS-FATOR-ANTIGO pode guardar uma regra empresarial importante.
Um parágrafo denominado AJUSTE-1997 pode representar uma exceção contratual que permanece válida para determinados clientes.
Um processamento noturno pode depender da ordem exata em que três arquivos são atualizados.
O conhecimento existe.
Mas está distribuído pelo sistema.
E essa é uma forma particularmente perigosa de dependência tecnológica.
📊 A crise não é apenas falta de programadores COBOL
O levantamento de modernização de mainframes da Kyndryl, publicado em 2025, aponta dificuldades relevantes de contratação e capacitação.
Entretanto, modernizar não exige somente conhecer sintaxe COBOL.
Exige compreender bancos de dados, segurança, integração, aplicações distribuídas, operações e arquitetura empresarial.
A falta de especialistas capazes de integrar tecnologias tradicionais com ferramentas modernas pode ser tão importante quanto a escassez de programadores da linguagem original.
A crise, portanto, é também uma crise de transferência de conhecimento.
🤖 Capítulo VI — Outubro de 2026: a inteligência artificial aprende a traduzir COBOL
Em 19 de outubro de 2026, a OpenAI divulgou resultados de pesquisas envolvendo linguagens de programação com menor disponibilidade pública de código e documentação, incluindo COBOL, Fortran e Visual Basic.
Uma das avaliações investigou a capacidade de migrar programas COBOL para linguagens como Java, Python, C++, Kotlin e Rust.
Os resultados foram impressionantes.
No benchmark específico de migração COBOL, o GPT-5.6 Sol obteve 5,4% de precisão em baixo esforço de raciocínio.
O GPT-6.1 Sol alcançou 86,6% nas mesmas condições gerais de esforço e chegou a 97,9% com maior esforço de raciocínio.
Isso demonstra uma evolução importante na capacidade dos modelos de lidar com programas em linguagens historicamente menos representadas nos materiais utilizados para treinamento.
Mas existe uma distinção essencial.
Um benchmark de migração não equivale à migração certificada de um sistema bancário inteiro.
Um sistema real pode reunir COBOL, JCL, CICS, Db2, IMS, VSAM, RACF, filas MQ, interfaces externas e procedimentos operacionais.
O comportamento depende de muito mais do que uma sequência de instruções.
Dijkstra provavelmente faria a pergunta fundamental:
Como sabemos que o comportamento do programa resultante corresponde àquilo que foi especificado?
Essa é a questão que separa uma demonstração tecnológica de um processo seguro de engenharia.
💰 Capítulo VII — O centavo que colocou a inteligência artificial no banco dos réus
Vamos construir nosso primeiro laboratório.
Você é um programador COBOL iniciante trabalhando no processamento de uma taxa bancária.
A empresa utiliza uma taxa de 2,5% aplicada sobre R$ 100,60.
O programa original contém:
IDENTIFICATION DIVISION.
PROGRAM-ID. TAXABANCO.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-VALOR PIC 9(5)V99.
01 WS-TAXA PIC 9V999.
01 WS-RESULTADO PIC 9(5)V99.
PROCEDURE DIVISION.
MOVE 100.60 TO WS-VALOR
MOVE 0.025 TO WS-TAXA
COMPUTE WS-RESULTADO =
WS-VALOR * WS-TAXA
DISPLAY WS-RESULTADO
GOBACK.
Vamos compreender cada etapa.
IDENTIFICATION DIVISION identifica o programa.
DATA DIVISION contém as definições de dados.
WORKING-STORAGE SECTION declara variáveis utilizadas durante a execução.
PIC 9(5)V99 representa cinco dígitos inteiros e dois decimais. O V é uma posição decimal implícita, não um caractere armazenado.
COMPUTE realiza uma operação aritmética.
DISPLAY apresenta o resultado.
GOBACK encerra a execução do programa principal e retorna o controle ao ambiente chamador.
O cálculo matemático produz:
100,60 × 0,025 = 2,515
Mas o campo de destino aceita somente duas casas decimais.
Sem ROUNDED, o resultado armazenado será 2,51.
Agora imagine que uma IA converta o programa para Java e utilize um arredondamento convencional para duas casas decimais.
A nova versão pode produzir 2,52.
Os dois programas compilam.
Os dois executam.
Os dois parecem corretos.
Mas são diferentes.
Uma diferença de apenas R$ 0,01, repetida em um milhão de operações que produzam divergência no mesmo sentido, representa R$ 10.000.
É uma situação hipotética, naturalmente. Na prática, diferenças podem ocorrer nos dois sentidos.
Entretanto, o exemplo revela por que preservar o comportamento é fundamental.
🔧 Como corrigir o exemplo?
Depende da regra empresarial.
Se a especificação exigir arredondamento ao centavo segundo a regra suportada pelo compilador, podemos utilizar:
COMPUTE WS-RESULTADO ROUNDED =
WS-VALOR * WS-TAXA
Nesse caso, para os valores apresentados, o resultado será 2,52.
Entretanto, acrescentar ROUNDED a um programa existente não é apenas uma melhoria estética.
É uma mudança funcional.
Pode alterar resultados financeiros, conciliações e registros históricos.
Dica Bellacosa: nunca altere uma regra aritmética em produção porque a nova implementação parece matematicamente mais elegante. Confirme antes a especificação empresarial.
🧮 Capítulo VIII — Dijkstra apresenta seu maior argumento: programas precisam de propriedades verificáveis
Um dos fundamentos da abordagem de Dijkstra é a necessidade de raciocinar sobre o comportamento dos programas.
Considere uma rotina que transfere dinheiro de uma conta para outra.
Antes da operação, temos:
Conta A: R$ 1.000
Conta B: R$ 500
Total: R$ 1.500
Agora vamos transferir R$ 200 da conta A para a conta B.
O resultado esperado é:
Conta A: R$ 800
Conta B: R$ 700
Total: R$ 1.500
Observe que uma propriedade permanece verdadeira.
A soma dos saldos não mudou.
Podemos expressar isso matematicamente:
Saldo A + Saldo B = constante
Essa propriedade é um exemplo de invariante.
Um invariante é uma condição que deve permanecer verdadeira durante determinadas etapas ou ao final de uma operação, conforme sua especificação.
Em uma transferência bancária simples entre duas contas, a conservação do valor transferido é uma propriedade importante.
Contudo, sistemas reais também precisam considerar tarifas, tributos, lançamentos contábeis, reversões e outras movimentações.
Por isso, os invariantes precisam ser definidos de acordo com o domínio empresarial.
💻 Laboratório: transferência bancária em COBOL
O exemplo abaixo é exclusivamente didático e não implementa uma transação bancária real.
IDENTIFICATION DIVISION.
PROGRAM-ID. TRANSFER.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-CONTA-A PIC S9(7)V99 COMP-3.
01 WS-CONTA-B PIC S9(7)V99 COMP-3.
01 WS-VALOR PIC S9(7)V99 COMP-3.
01 WS-TOTAL-INI PIC S9(9)V99 COMP-3.
01 WS-TOTAL-FIM PIC S9(9)V99 COMP-3.
PROCEDURE DIVISION.
MOVE 1000 TO WS-CONTA-A
MOVE 500 TO WS-CONTA-B
MOVE 200 TO WS-VALOR
COMPUTE WS-TOTAL-INI =
WS-CONTA-A + WS-CONTA-B
IF WS-VALOR > ZERO AND
WS-CONTA-A >= WS-VALOR
SUBTRACT WS-VALOR
FROM WS-CONTA-A
ADD WS-VALOR
TO WS-CONTA-B
ELSE
DISPLAY "TRANSFERENCIA INVALIDA"
END-IF
COMPUTE WS-TOTAL-FIM =
WS-CONTA-A + WS-CONTA-B
IF WS-TOTAL-INI = WS-TOTAL-FIM
DISPLAY "INVARIANTE PRESERVADO"
ELSE
DISPLAY "ERRO DE CONSISTENCIA"
END-IF
GOBACK.
O que aprendemos?
Primeiro, declaramos os valores monetários usando COMP-3, uma representação decimal compactada comum em aplicações COBOL empresariais.
Depois, calculamos a soma dos saldos antes da operação.
Verificamos se o valor da transferência é positivo e se existe saldo suficiente.
Executamos débito e crédito.
Finalmente, comparamos os totais.
Mas atenção: essa verificação não demonstra que o programa está totalmente correto.
Por exemplo, ela não verifica se cada saldo individual corresponde exatamente ao esperado.
Também não trata persistência em banco de dados, concorrência, falhas intermediárias ou rollback.
Uma aplicação bancária real exige mecanismos transacionais apropriados.
Ainda assim, o exercício apresenta uma ideia importante.
Podemos verificar propriedades do programa, em vez de observar apenas algumas saídas isoladas.
Essa é uma conexão direta entre o pensamento de Dijkstra e a modernização de software com inteligência artificial.
🕵️ Capítulo IX — O mistério dos 360 dias: um erro que talvez seja uma regra bancária
Imagine que uma IA encontre o seguinte trecho:
COMPUTE WS-JUROS =
(WS-SALDO * WS-TAXA * WS-DIAS)
/ 360
A IA poderia perguntar:
Por que o programa utiliza 360 dias se o ano normalmente possui 365?
Um programador sem experiência financeira talvez respondesse:
— É um erro antigo. Vamos corrigir.
Dijkstra provavelmente interromperia a discussão.
Antes de corrigir, precisamos saber o que o programa deveria fazer.
A utilização de uma base anual de 360 dias pode corresponder a uma convenção financeira contratual.
A base 365 também existe, assim como diferentes convenções de contagem de dias.
Isso significa que o divisor correto depende do produto e de sua especificação.
Agora imagine que o sistema tenha milhões de contratos antigos.
Modificar 360 para 365 pode alterar valores que deveriam continuar obedecendo às condições originalmente acordadas.
O código pode estar feio.
Pode estar mal documentado.
Pode ser antigo.
Mas isso não significa que sua lógica esteja incorreta.
💡 A grande lição
Existem pelo menos três perguntas diferentes:
O programa faz aquilo que foi programado para fazer?
O programa faz aquilo que a especificação exige?
A especificação ainda representa corretamente a necessidade empresarial?
Uma IA pode ajudar a responder à primeira pergunta.
Pode auxiliar muito na investigação da segunda.
Mas a terceira exige conhecimento do negócio, documentação, responsabilidade e decisões humanas.
🏰 Capítulo X — O castelo IBM Z: por que o COBOL não vive sozinho?
Imagine um castelo medieval.
O programador COBOL trabalha na sala principal.
Mas o castelo possui muralhas, arquivos, mensageiros, guardas e depósitos.
Algo semelhante acontece no mainframe.
O COBOL representa parte da lógica da aplicação.
O CICS administra ambientes de processamento transacional.
O Db2 oferece recursos de banco de dados relacional.
O VSAM gerencia determinadas organizações de arquivos e métodos de acesso.
O JCL descreve trabalhos batch e recursos necessários à execução.
O JES2 participa do gerenciamento e processamento de jobs.
O RACF fornece recursos de identificação, autenticação, controle de acesso e auditoria.
O IBM MQ permite comunicação assíncrona entre aplicações.
E ferramentas como Zowe, VS Code e z/OS Connect ajudam a integrar esse ambiente com práticas e plataformas modernas.
Um programa COBOL pode depender de vários desses componentes simultaneamente.
Por isso, migrar seu código-fonte não significa migrar toda a aplicação.
Considere um programa que recebe uma transação pelo CICS, consulta tabelas Db2, atualiza um arquivo VSAM e envia uma mensagem MQ.
Se uma IA converter o COBOL para Python, ainda precisaremos decidir como preservar:
Os limites transacionais.
O tratamento de falhas.
O controle de concorrência.
A recuperação de operações interrompidas.
As autorizações de acesso.
As integrações externas.
Os formatos e a integridade dos dados.
Os requisitos de disponibilidade e desempenho.
O desafio é arquitetural.
Dijkstra, que estudou profundamente problemas de concorrência, sincronização e correção, seria um excelente guia intelectual para investigar essas dependências.
🧪 Capítulo XI — Passo a passo: como um iniciante pode investigar COBOL com inteligência artificial
Chegou a hora de construir um método prático.
Vamos imaginar que você acaba de entrar numa equipe responsável por manter aplicações COBOL.
Seu primeiro trabalho consiste em compreender um programa desconhecido.
Passo 1 — Não comece pedindo uma tradução
A primeira reação pode ser copiar o programa e solicitar:
Converta tudo para Python.
Resista à tentação.
Comece identificando o problema que o software resolve.
Pergunte quais dados ele recebe, quais regras aplica, quais arquivos modifica e quais resultados produz.
A tradução será muito mais segura quando houver compreensão prévia.
Passo 2 — Separe as divisões do COBOL
Procure compreender:
IDENTIFICATION DIVISION: identidade do programa.
ENVIRONMENT DIVISION: definições relacionadas ao ambiente e aos recursos externos.
DATA DIVISION: estruturas de dados.
PROCEDURE DIVISION: lógica executável.
Nem todos os programas apresentam exatamente a mesma organização, mas essas divisões constituem uma base excelente para o aprendizado.
Passo 3 — Investigue os tipos de dados
Observe especialmente:
PIC 9: campos numéricos.
PIC X: campos alfanuméricos.
COMP-3: armazenamento decimal compactado.
COMP e COMP-5: representações binárias com particularidades que dependem do ambiente.
REDEFINES: diferentes interpretações de uma mesma área de armazenamento.
OCCURS: repetição de estruturas.
Esses recursos frequentemente determinam como a aplicação representa dados externos e calcula resultados.
Passo 4 — Identifique dependências
Pesquise instruções como:
CALL
COPY
EXEC SQL
EXEC CICS
READ
WRITE
REWRITE
START
Essas instruções podem revelar relações com outros programas, copybooks, bancos de dados, arquivos e serviços transacionais.
Passo 5 — Solicite explicações com evidências
Um prompt útil seria:
Analise este programa COBOL sem modificar seu conteúdo. Identifique entradas, saídas, regras de negócio, dependências, tipos de dados, cálculos e possíveis riscos. Separe os fatos observados das hipóteses. Para cada conclusão, indique o trecho do código que a sustenta. Quando houver informação insuficiente, declare a incerteza.
Esse último requisito é muito importante.
Inteligências artificiais podem apresentar interpretações plausíveis que não correspondem ao verdadeiro propósito empresarial do código.
Passo 6 — Construa testes de caracterização
Um teste de caracterização registra o comportamento existente de um sistema.
Ele ajuda a descobrir como a aplicação funciona antes da alteração.
Inclua valores normais, situações extremas, números negativos, limites de campos, condições de erro e formatos inesperados.
Documente também quais comportamentos precisam ser preservados e quais defeitos conhecidos devem ser corrigidos.
Passo 7 — Compare versões
Execute o programa original e a versão modificada utilizando entradas controladas.
Compare resultados, formatos, códigos de erro e efeitos colaterais.
Quando houver divergência, investigue sua origem.
Nunca considere que a implementação nova está automaticamente correta porque utiliza uma linguagem mais recente.
Passo 8 — Só então considere a modernização
Após compreender e testar o comportamento, avalie se é melhor:
Manter e otimizar o COBOL.
Refatorar componentes internos.
Expor serviços por APIs.
Substituir módulos específicos.
Ou realizar uma migração maior.
A decisão deve considerar riscos, custos e benefícios reais.
🧰 Capítulo XII — As ferramentas modernas que Dijkstra encontraria no mainframe
Em 2026, o desenvolvimento COBOL pode utilizar recursos muito diferentes daqueles encontrados nos terminais dos anos 1970 e 1980.
Ambientes modernos permitem integração com editores, repositórios de código, pipelines e ferramentas de análise.
O Visual Studio Code, com extensões apropriadas, pode ser utilizado para editar COBOL e interagir com recursos do z/OS.
O Zowe facilita diversas formas de acesso e automação.
O Git permite controlar versões, comparar alterações e organizar o desenvolvimento colaborativo.
Ferramentas de compilação, testes e integração contínua ajudam a produzir evidências de qualidade.
O IBM watsonx Code Assistant for Z oferece recursos voltados à compreensão, explicação, geração, refatoração e transformação de código, conforme a versão e os componentes disponíveis.
Essas tecnologias podem reduzir atividades repetitivas.
Mas nenhuma delas elimina a necessidade de engenharia.
Uma ferramenta capaz de produzir código rapidamente não demonstra, por si só, que o código está correto.
A automação precisa ser acompanhada de critérios verificáveis.
E aqui existe uma ligação fundamental com a filosofia de Dijkstra.
A qualidade de um programa não deve ser medida apenas pela facilidade com que ele foi escrito.
Precisamos considerar sua clareza, suas propriedades e a capacidade de demonstrar que atende às exigências estabelecidas.
🔐 Capítulo XIII — Quando a IA recebe acesso ao código bancário: surge um novo perigo
Até agora discutimos erros de lógica.
Mas existe outro problema.
Para analisar um sistema COBOL empresarial, uma inteligência artificial pode precisar acessar código-fonte, documentação, configurações e informações operacionais.
Esses materiais podem conter detalhes sensíveis.
Imagine um agente de IA conectado a um repositório de aplicações financeiras.
Ele recebe autorização para consultar programas.
Depois, ganha acesso a pipelines de desenvolvimento.
Em seguida, alguém permite que modifique arquivos e execute tarefas automaticamente.
De repente, uma ferramenta originalmente utilizada para explicar código possui capacidades de alterar componentes críticos.
Isso exige governança.
As boas práticas incluem controle de privilégios, segregação de funções, rastreabilidade de alterações, avaliação de ferramentas, revisão humana e mecanismos de aprovação.
Credenciais e dados pessoais não devem ser enviados indiscriminadamente para serviços externos.
Ambientes de testes também precisam ser separados dos ambientes produtivos.
Dijkstra não estudou os modelos de linguagem atuais, mas sua preocupação com sistemas complexos e comportamentos controláveis fornece um excelente ponto de partida para essa discussão.
Quanto maior a autonomia concedida ao agente, maior a necessidade de verificar suas ações e limitar seus efeitos.
⏳ Capítulo XIV — 2030: o futuro pertence ao programador COBOL ou ao fiscal da inteligência artificial?
Vamos imaginar o mercado de trabalho daqui a alguns anos.
Em uma organização, existem milhares de programas COBOL.
Boa parte deles foi desenvolvida antes do nascimento dos profissionais mais jovens da equipe.
Agora, agentes de IA conseguem explicar rotinas, localizar dependências, produzir documentação e sugerir transformações.
Isso pode reduzir a quantidade de trabalho manual exigida em determinadas tarefas.
Mas também pode aumentar a capacidade de profissionais experientes de cuidar de aplicações maiores.
O mercado poderá valorizar novas combinações de competências.
O programador COBOL tradicional compreende a linguagem e o ambiente.
O engenheiro de modernização compreende o sistema, suas dependências e as alternativas arquiteturais.
O especialista em validação compreende como estabelecer requisitos e demonstrar propriedades importantes.
O profissional que combina essas habilidades com o uso responsável da IA poderá assumir funções particularmente relevantes.
Entretanto, não devemos transformar essa possibilidade numa promessa de estabilidade profissional garantida.
A automação pode alterar a demanda por determinadas atividades e mudar a forma de contratação das empresas.
O melhor caminho para quem está começando é construir fundamentos sólidos e desenvolver competências complementares.
Aprender COBOL não precisa significar ignorar Python, Java, APIs, Git ou inteligência artificial.
Da mesma forma, aprender IA não deveria significar abandonar o estudo de algoritmos, estruturas de dados e engenharia de software.
📚 O currículo que eu recomendaria para um aprendiz
Comece compreendendo variáveis, condições, repetição e arquivos em COBOL.
Depois avance para JCL, TSO/ISPF e execução de programas no z/OS.
Estude Db2, CICS e VSAM para compreender como aplicações empresariais armazenam e movimentam dados.
Aprenda testes, depuração, documentação e controle de versões.
Finalmente, explore integração por APIs e uso de IA para apoiar análise e desenvolvimento.
Durante todo o processo, faça uma pergunta inspirada por Dijkstra:
Como posso demonstrar que este programa está fazendo aquilo que deveria fazer?
Essa pergunta vale mais do que decorar centenas de instruções.
🥚 Capítulo XV — Cinco curiosidades que Dijkstra deixou para os arqueólogos do software
1. O algoritmo de Dijkstra não nasceu para encontrar rotas de GPS
Seu famoso algoritmo de caminhos mínimos antecede os sistemas modernos de navegação.
A ideia é encontrar caminhos de custo mínimo em grafos com pesos não negativos.
Hoje, conceitos semelhantes aparecem em redes, logística, transportes e planejamento.
2. Dijkstra trabalhou com os fundamentos da concorrência
Muito antes dos atuais sistemas distribuídos, ele investigou problemas de sincronização, exclusão mútua e coordenação de processos.
Esses temas são fundamentais para compreender por que aplicações transacionais precisam controlar corretamente operações simultâneas.
3. Ele não gostava de complexidade desnecessária
A programação estruturada não elimina toda a complexidade.
Mas pode organizar melhor o raciocínio e reduzir a dificuldade de acompanhar o fluxo de execução.
É uma lição que continua válida para software produzido por humanos ou por IA.
4. Ele realmente criticou o COBOL
Essa é talvez a maior ironia de nossa investigação.
Estamos utilizando as ideias de um crítico da linguagem para ensinar como construir programas COBOL melhores.
Não existe contradição obrigatória nisso.
Boas ideias científicas podem ser aplicadas em contextos que seus autores não apreciavam.
5. O maior perigo da IA pode ser tornar fácil demais produzir código
Durante décadas, escrever programas exigia tempo e esforço consideráveis.
Agora, produzir código pode ser muito mais rápido.
Mas a rapidez de geração não reduz automaticamente a dificuldade de compreender o comportamento.
Talvez estejamos entrando numa época em que escrever software se torna progressivamente mais barato, enquanto demonstrar sua correção permanece um dos grandes desafios da engenharia.
⚖️ Capítulo XVI — O julgamento final: COBOL, inteligência artificial e o legado de Dijkstra
Voltamos ao Centro de Processamento de Dados.
São quatro horas e cinquenta e dois minutos.
O jovem programador ainda observa a migração realizada pela inteligência artificial.
Na primeira tentativa, o sistema havia informado sucesso.
Agora, depois de uma investigação mais cuidadosa, surgiram diferenças importantes.
Alguns valores decimais foram arredondados de maneira diferente.
Um campo redefinido não foi interpretado corretamente.
Um fluxo de exceção não recebeu tratamento equivalente.
Uma rotina utilizava um calendário financeiro que não estava documentado.
O jovem compreende que o código produzido pela IA pode representar um excelente ponto de partida.
Mas ainda não é suficiente para substituir o sistema original em produção.
Ele prepara novos testes.
Consulta a documentação.
Conversa com os especialistas de negócio.
Investiga dependências.
E começa a construir uma justificativa técnica para cada alteração.
O visitante observa em silêncio.
— Professor, então o problema não é a inteligência artificial?
Na nossa dramatização, Dijkstra responde:
— O problema é acreditar que produzir instruções equivale a compreender um programa.
O jovem olha novamente para o terminal.
Durante quase sete décadas, os computadores ficaram mais rápidos.
As linguagens evoluíram.
Os sistemas operacionais se transformaram.
A capacidade de armazenamento cresceu em proporções extraordinárias.
E agora as máquinas conseguem produzir programas com uma velocidade que os pioneiros da computação dificilmente imaginariam.
Mas uma pergunta permanece.
Como sabemos que o programa está correto?
Essa pergunta existia antes do COBOL.
Continuou importante durante a expansão dos mainframes.
Sobreviveu à revolução dos computadores pessoais.
Acompanhou a chegada da internet e da computação em nuvem.
E continua fundamental na era da inteligência artificial.
☕ Epílogo — O COBOL não precisa ser salvo da idade. Precisa ser protegido da incompreensão.
A crise do COBOL é frequentemente apresentada como uma disputa entre tecnologias antigas e modernas.
Mas essa interpretação é superficial.
Não estamos simplesmente diante de uma linguagem de 1959 tentando sobreviver em 2026.
Estamos diante de décadas de conhecimento empresarial incorporado a sistemas que continuam executando funções críticas.
A inteligência artificial oferece ferramentas extraordinárias para investigar, explicar, documentar, testar e transformar essas aplicações.
Entretanto, também introduz novos riscos quando resultados aparentemente convincentes são aceitos sem verificação suficiente.
A filosofia de Edsger W. Dijkstra nos ajuda a compreender essa diferença.
A engenharia de software não pode depender exclusivamente da confiança no autor do programa.
E isso vale quando o autor é um programador de 1986, um engenheiro de 2026 ou um agente de inteligência artificial.
É preciso compreender o problema.
Definir o comportamento esperado.
Organizar o raciocínio.
Identificar propriedades importantes.
Construir evidências de correção.
E assumir responsabilidade pelas mudanças.
Talvez o futuro do COBOL não seja determinado por quantas linhas de código uma inteligência artificial consegue traduzir por minuto.
Talvez seja determinado pela nossa capacidade de preservar corretamente os processos empresariais que essas linhas representam.
Porque uma máquina pode escrever um milhão de instruções. Mas ainda precisamos saber se são as instruções certas.
E, no universo Bellacosa Mainframe, essa é a diferença entre simplesmente programar e compreender o que se está construindo.
📚 Referências e leituras recomendadas
André Lourenti Magalhães, Canaltech. O que é a chamada Crise do COBOL e como a IA pode ajudar a resolver? — 8 de novembro de 2026.
OpenAI. Advancing coding in low-resource programming languages — 19 de outubro de 2026.
Edsger W. Dijkstra. Go To Statement Considered Harmful. Communications of the ACM — março de 1968.
Edsger W. Dijkstra. How do we tell truths that might hurt? — EWD498, 1975.
Edsger W. Dijkstra. What led to Notes on Structured Programming — EWD1308, 2001.
IBM Documentation. Enterprise COBOL for z/OS.
IBM Documentation. watsonx Code Assistant for Z.
Kyndryl. State of Mainframe Modernization Report 2025.
Bellacosa Mainframe — Onde os programas antigos contam suas histórias, a inteligência artificial encontra novos desafios e o conhecimento continua sendo o recurso mais importante de todos.
Fim da investigação. O mainframe continua trabalhando.
