 |
| Bellacosa Mainframe e o caso do mips comilao |
☕ Um Café no Bellacosa Mainframe
O Caso dos MIPS que Cresceram Três Vezes Mais Rápido
Quando Dick Tracy entra no CPD para investigar o assassinato do COBOL — e descobre que a vítima continua processando milhões de transações
A madrugada havia engolido a cidade.
Do lado de fora, a chuva desenhava linhas tortas nas janelas do edifício. Do lado de dentro, no vigésimo andar de um banco que jamais dormia, milhares de transações atravessavam silenciosamente um IBM Z.
Cartões eram autorizados.
Pagamentos eram compensados.
Contas eram atualizadas.
Fraudes eram avaliadas.
Arquivos eram classificados.
Jobs eram executados.
E, em uma sala iluminada apenas pelo brilho verde de um terminal 3270, um programador COBOL iniciante observava uma mensagem inquietante no monitor:
A INTELIGÊNCIA ARTIFICIAL VAI MATAR O COBOL.
Ele afastou as mãos do teclado.
Naquele instante, a porta se abriu.
Entrou um homem de sobretudo amarelo, chapéu inclinado sobre os olhos e um estranho relógio-comunicador preso ao pulso.
— Meu nome não importa — disse o detetive. — O que importa é descobrir quem inventou essa história.
Sobre a mesa havia três objetos:
uma queda de 13% nas ações da IBM;
uma ferramenta chamada watsonx Code Assistant for Z;
uma declaração afirmando que clientes usuários da ferramenta estavam aumentando sua capacidade em MIPS três vezes mais rapidamente.
Parecia um caso simples.
Mas, no mainframe, como em toda boa investigação, o primeiro suspeito raramente é o verdadeiro culpado.
Capítulo 1 — A manchete que assustou Wall Street
Em fevereiro de 2026, a Anthropic anunciou recursos de inteligência artificial voltados à compreensão e modernização de sistemas escritos em COBOL. A reação do mercado foi imediata: as ações da IBM caíram aproximadamente 13,2% em um único pregão.
A interpretação de muitos investidores foi direta:
IA compreende COBOL
↓
IA converte COBOL
↓
Empresas abandonam o mainframe
↓
IBM perde clientes
↓
Fim do IBM Z
A Reuters registrou que a queda ocorreu após o mercado interpretar o anúncio como uma possível ameaça ao negócio de modernização de aplicações legadas e ao ecossistema de mainframe da IBM. (Reuters)
Para quem observa o mainframe apenas de fora, o raciocínio parece razoável.
Existem milhões de programas COBOL em bancos, seguradoras, governos, indústrias, empresas de telecomunicações e companhias aéreas. Se uma inteligência artificial puder converter tudo isso para Java, Python ou outra linguagem, então bastaria apertar um botão, esperar algumas horas e desligar o mainframe.
Caso encerrado.
O detetive, porém, olhou para a manchete e comentou:
— Rápido demais. Quando alguém apresenta uma migração corporativa como se fosse um MOVE, procure as provas que desapareceram.
Porque transformar um sistema corporativo não é isto:
MOVE PROGRAMA-COBOL TO PROGRAMA-JAVA.
A sintaxe pode ser convertida.
O significado do negócio, não necessariamente.
Capítulo 2 — O COBOL não trabalha sozinho
Um programador iniciante pode imaginar que uma aplicação COBOL seja apenas um arquivo-fonte contendo algumas centenas de linhas.
Em um exercício de treinamento, talvez seja assim:
IDENTIFICATION DIVISION.
PROGRAM-ID. CALCULA-SALDO.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-SALDO PIC S9(9)V99 COMP-3.
01 WS-CREDITO PIC S9(9)V99 COMP-3.
01 WS-DEBITO PIC S9(9)V99 COMP-3.
PROCEDURE DIVISION.
COMPUTE WS-SALDO =
WS-CREDITO - WS-DEBITO
DISPLAY 'SALDO: ' WS-SALDO
GOBACK.
Entretanto, uma aplicação real pode envolver:
Programa COBOL
│
├── COPYBOOKS
├── arquivos sequenciais
├── VSAM
├── tabelas Db2
├── transações CICS
├── mensagens IBM MQ
├── chamadas IMS
├── serviços REST
├── programas Assembler
├── rotinas PL/I
├── JCL
├── PROCs catalogadas
├── Control-M, IWS ou outro scheduler
├── regras RACF
└── procedimentos operacionais
O programa não vive isolado.
Ele pertence a uma teia operacional.
Considere um simples campo:
01 WS-TIPO-CLIENTE PIC X(01).
Uma ferramenta automática pode reconhecer que se trata de um caractere.
Mas o que significa A?
Pode significar:
cliente ativo;
cliente antigo;
cliente especial;
conta de alto risco;
agência;
pessoa autorizada;
produto categoria A.
E o valor B?
Talvez não exista em nenhum manual. Pode ter sido criado em 1997 para atender uma resolução temporária que, por alguma razão, tornou-se permanente.
É aí que começa o verdadeiro mistério.
Código não é apenas código. Código corporativo é história empresarial executável.
Capítulo 3 — O cadáver que nunca apareceu
O mercado procurava o corpo do COBOL.
Não encontrou.
Cinco meses depois da queda provocada pelo temor de que a IA aceleraria a saída do mainframe, a própria IBM voltou a mencionar um dado curioso: clientes que implantaram o watsonx Code Assistant for Z estariam aumentando sua capacidade em MIPS três vezes mais rapidamente do que clientes que não o utilizavam.
A afirmação apareceu nos comentários financeiros da IBM já no primeiro trimestre de 2026 e foi repetida posteriormente. Nos comentários preparados do primeiro trimestre, a empresa declarou que os clientes que haviam implantado a solução apresentavam crescimento de capacidade três vezes superior. (IBM)
O mesmo indicador foi novamente citado na conferência de resultados de julho de 2026, associado à expansão de cargas, modernização e adoção de inteligência artificial no IBM Z. (Roic AI)
O detetive colocou duas fotografias sobre a mesa.
Na primeira:
FEVEREIRO DE 2026
IA PARA COBOL
↓
MERCADO IMAGINA MIGRAÇÃO
↓
AÇÃO DA IBM CAI
Na segunda:
MESES DEPOIS
IA PARA COBOL
↓
APLICAÇÕES SE TORNAM MAIS FÁCEIS DE EVOLUIR
↓
NOVOS PROJETOS ENTRAM EM PRODUÇÃO
↓
CAPACIDADE CRESCE
— Temos uma contradição — disse o programador.
— Não — respondeu o detetive. — Temos uma hipótese errada.
A inteligência artificial pode ajudar uma empresa a migrar partes de uma aplicação. Mas também pode tornar o ambiente existente mais compreensível, produtivo e modernizável.
Nesse segundo cenário, a IA não esvazia o mainframe.
Ela o destrava.
Capítulo 4 — O que são MIPS?
Antes de prosseguir, precisamos examinar uma das principais pistas.
MIPS significa:
Millions of Instructions Per Second
Milhões de instruções por segundo.
Historicamente, o termo foi usado como uma forma de representar a capacidade de processamento de um computador. No universo mainframe, ele também se tornou uma maneira informal de falar sobre o tamanho da capacidade instalada ou consumida.
Entretanto, para um profissional iniciante, é importante não transformar MIPS em uma medida mágica.
MIPS não responde sozinho a perguntas como:
o sistema está eficiente?
o programa está bem escrito?
o custo está controlado?
o tempo de resposta está adequado?
a carga está sendo executada no processador correto?
o crescimento corresponde a novas receitas?
houve aumento de desperdício?
No licenciamento e no gerenciamento de capacidade do IBM Z também aparecem conceitos como:
MSU;
R4HA;
rolling four-hour average;
capacidade contratada;
subcapacity;
Tailored Fit Pricing;
zIIP eligibility;
consumo por workload;
métricas de WLM e SMF.
Portanto, quando a IBM afirma que determinado grupo está crescendo capacidade em MIPS três vezes mais rapidamente, a leitura correta não é:
“A IA deixou o processador três vezes mais veloz.”
A leitura mais razoável é:
“As organizações que usam a ferramenta estão adicionando ou consumindo capacidade em ritmo significativamente maior.”
A IA não colocou nitroglicerina na CPU.
Ela pode ter acelerado o ciclo de desenvolvimento, análise e modernização.
Capítulo 5 — Correlação não é confissão
Todo bom detetive precisa desconfiar das evidências fáceis.
A declaração dos três vezes mais MIPS vem da IBM, fabricante tanto do mainframe quanto da ferramenta de inteligência artificial. Portanto, deve ser tratada como um indicador comercial relevante, não como uma prova científica independente.
Existem várias explicações possíveis.
Hipótese A — A ferramenta provoca crescimento
O watsonx Code Assistant for Z reduz o esforço de compreensão e modernização. Com isso, mais projetos são concluídos e mais cargas entram em produção.
Hipótese B — Empresas que já cresciam compraram a ferramenta
Organizações que adotam soluções avançadas de IA talvez já estivessem ampliando seus ambientes, aumentando transações e modernizando aplicações.
Nesse caso, o crescimento não teria sido causado exclusivamente pela ferramenta.
Hipótese C — Os dois fatores trabalham juntos
Clientes em expansão adotam a IA; a IA aumenta a produtividade; a produtividade permite ainda mais expansão.
Provavelmente, a realidade contém uma combinação dessas hipóteses.
A estatística é interessante, mas não demonstra sozinha causalidade. Ela não nos informa, por exemplo:
quantos clientes foram analisados;
qual foi o período exato;
quais setores estavam representados;
quanto do crescimento veio de novas aplicações;
quanto veio de crescimento orgânico;
quanto foi capacidade geral ou consumo específico;
como os clientes foram comparados.
Por isso, não devemos transformar o “3x” em religião.
Mas também não devemos ignorá-lo.
Em uma investigação, uma pegada não condena o suspeito. Porém, mostra onde ele esteve.
Capítulo 6 — O que o watsonx Code Assistant for Z realmente faz?
Aqui está uma das maiores confusões sobre IA e COBOL.
Muita gente imagina que a ferramenta possua apenas uma função:
COBOL → Java
Na realidade, a proposta é muito mais ampla.
A IBM descreve o watsonx Code Assistant for Z como uma solução que apoia diferentes fases do ciclo de vida: descoberta e análise de aplicações, explicação de código, refatoração, geração, otimização, transformação para linguagens mais novas e testes. (IBM)
Entre suas possibilidades estão:
1. Descoberta da aplicação
Antes de modernizar, é necessário saber o que existe.
A ferramenta pode ajudar a identificar:
programas;
chamadas;
COPYBOOKS;
arquivos;
tabelas;
jobs;
transações;
dependências;
fluxos de dados.
É o equivalente digital a espalhar fotografias, endereços e linhas vermelhas sobre a parede da delegacia.
PGM-A
│
├── CALL PGM-B
│ └── DB2.TBCLIENTE
│
├── READ ARQVSAM
│
└── CALL PGM-C
└── MQ.PUT
Sem esse mapa, uma alteração aparentemente pequena pode atingir dezenas de componentes.
2. Explicação de código
O desenvolvedor pode pedir uma explicação de determinada rotina ou fluxo.
Isso é particularmente útil quando encontramos algo assim:
IF WS-COD-OPERACAO = '17'
AND WS-TIPO-CONTA NOT = '9'
AND WS-FLAG-ESP = 'S'
PERFORM 4300-TRATA-LIMITE
ELSE
PERFORM 4500-TRATA-EXCECAO
END-IF.
A IA pode resumir a lógica:
Quando a operação for do tipo 17, a conta não pertencer à categoria 9 e estiver marcada como especial, o programa processa o limite; caso contrário, executa o tratamento de exceção.
Isso ajuda.
Mas ainda precisamos perguntar:
O que é operação 17?
Por que a conta 9 foi excluída?
Quem define o indicador especial?
Essa regra continua válida?
Existe uma exigência regulatória?
O comportamento está coberto por testes?
A IA explica o que está escrito.
O especialista descobre o que aquilo significa para a empresa.
3. Descoberta de regras de negócio
A interface Z Understand foi criada para ajudar arquitetos e desenvolvedores a analisar aplicações e descobrir regras de negócio usando uma abordagem conversacional. (IBM)
Essa capacidade pode revelar que uma regra importante está espalhada entre:
3 programas COBOL
2 COPYBOOKS
1 tabela Db2
1 parâmetro em arquivo
1 passo de JCL
É muito comum que a regra real não esteja concentrada em um único lugar.
4. Documentação
Sistemas antigos nem sempre possuem documentação atualizada.
Na verdade, existe uma piada clássica no CPD:
“A documentação está perfeita. Só não corresponde mais ao programa.”
A IA pode auxiliar na produção de:
resumo funcional;
descrição técnica;
fluxo de execução;
inventário de componentes;
explicação de parágrafos;
documentação de interfaces;
identificação de entradas e saídas.
Em um caso divulgado pela IBM, a NOSI utilizou o produto para obter visibilidade sobre código e integrações não documentadas e automatizar parte da documentação. A IBM afirma que houve redução de 94% no tempo necessário para analisar código COBOL considerado supérfluo naquele contexto específico. É um estudo de caso do fornecedor, portanto deve ser interpretado dentro dessas condições. (IBM)
5. Refatoração
Refatorar não significa necessariamente trocar de linguagem.
Pode significar:
dividir um programa gigantesco;
isolar uma regra de negócio;
reduzir duplicações;
remover código morto;
separar acesso a dados;
transformar uma função em serviço;
melhorar nomes;
facilitar testes;
preparar uma API.
Imagine um programa de 40 mil linhas chamado:
PGM0001
Ele calcula tarifas, consulta clientes, atualiza contas, gera relatórios e talvez prepare café.
A modernização pode começar separando responsabilidades:
PGM0001
│
├── SERVICO-CLIENTE
├── SERVICO-TARIFA
├── SERVICO-LIMITE
└── SERVICO-AUDITORIA
O programa continua em COBOL, mas torna-se mais modular.
6. Transformação seletiva
Em alguns casos, uma parte da aplicação pode ser transformada em Java ou outra tecnologia. A própria IBM apresenta a transformação como seletiva e incremental, não como uma conversão automática indiscriminada de todo o ambiente. (IBM Mediacenter)
Essa diferença é crucial.
Modernização séria não pergunta:
“Como removemos todo o COBOL?”
Ela pergunta:
“Qual componente deve permanecer, qual deve ser refatorado, qual deve ser exposto por API e qual realmente precisa ser substituído?”
Capítulo 7 — O teste é a testemunha principal
Suponha que a IA converta o seguinte cálculo:
COMPUTE WS-JUROS ROUNDED =
WS-SALDO * WS-TAXA / 100.
A versão gerada em Java pode parecer correta.
Mas precisamos investigar:
o COBOL utiliza decimal empacotado?
qual é a precisão?
onde ocorre o arredondamento?
existe truncamento intermediário?
o sinal está preservado?
quais valores máximos são permitidos?
existe
ON SIZE ERROR?o Java está usando
doubleouBigDecimal?como os valores nulos são tratados?
existe diferença na representação da data?
como ocorre o commit?
Uma tradução sintaticamente bonita pode produzir resultados financeiramente errados.
COBOL: R$ 1.245,37
JAVA: R$ 1.245,36
Um centavo parece pouco.
Multiplique por dez milhões de operações.
Agora temos uma ocorrência para a divisão de crimes financeiros.
Pesquisas sobre transformação automática de COBOL mostram que a validação da equivalência funcional continua sendo um dos pontos mais difíceis. Um trabalho publicado por pesquisadores ligados ao desenvolvimento de testes para o watsonx Code Assistant for Z observa que código transformado por modelos de linguagem não deve ser considerado correto sem validação, tornando necessários testes de equivalência entre o COBOL original e o código gerado. (arXiv)
Outro relato anterior de migração real de COBOL para Java também identificou os testes como uma das partes mais problemáticas do projeto, além da transferência do conhecimento do domínio. (arXiv)
Essa é a pista decisiva:
Converter código é uma atividade. Demonstrar que o negócio continua correto é outra completamente diferente.
Capítulo 8 — Como a IA pode aumentar os MIPS?
Agora conseguimos reconstruir o crime.
Imagine um banco com 120 solicitações de modernização.
Sem assistência de IA, cada equipe gasta grande parte do tempo tentando localizar componentes, interpretar código e mapear impactos.
120 solicitações
↓
análise lenta
↓
fila crescente
↓
poucas entregas
↓
aplicação congelada
Com ferramentas de descoberta, explicação e documentação:
120 solicitações
↓
análise mais rápida
↓
melhor compreensão
↓
mais testes preparados
↓
mais entregas
↓
mais serviços em produção
Essas entregas podem gerar:
novas transações CICS;
consultas adicionais ao Db2;
mensagens MQ;
chamadas de APIs;
processamento antifraude;
integração com aplicativos móveis;
novos lotes noturnos;
uso de IA próximo aos dados;
novos produtos bancários;
expansão da base de clientes.
O consumo de capacidade cresce não porque a IA tornou um ADD mais pesado, mas porque a organização conseguiu colocar mais funcionalidades em operação.
A equação é esta:
MAIOR COMPREENSÃO DO LEGADO
+
MENOR TEMPO DE MODERNIZAÇÃO
+
MAIOR VELOCIDADE DE ENTREGA
=
MAIS CARGAS EXECUTADAS
O aumento de MIPS pode ser consequência de crescimento do negócio, modernização bem-sucedida ou novas cargas.
Isso não significa necessariamente desperdício.
Também não significa automaticamente economia.
Significa que o ambiente está evoluindo.
Capítulo 9 — Um roteiro prático para o programador COBOL iniciante
O detetive abriu o caderno.
— Chega de teoria. Vamos ao procedimento operacional.
Passo 1 — Aprenda COBOL antes de delegá-lo à IA
Não use a inteligência artificial como substituta dos fundamentos.
Você precisa compreender:
divisões do programa;
níveis de dados;
cláusula
PIC;USAGE;COMP,COMP-3e binários;MOVE;COMPUTE;IF;EVALUATE;PERFORM;tabelas;
arquivos;
tratamento de erros;
chamadas;
SQL embutido;
conceitos de CICS.
Sem conhecimento básico, você não consegue avaliar a resposta recebida.
A IA pode afirmar algo incorreto com aparência impecável.
Passo 2 — Peça explicações pequenas
Em vez de entregar um programa inteiro com 30 mil linhas, selecione uma rotina.
Exemplo:
Explique o objetivo deste parágrafo COBOL.
Identifique entradas, saídas, condições e possíveis erros.
Não invente o significado comercial dos códigos.
Essa última frase é importante.
A ferramenta deve separar:
o que pode observar;
o que está inferindo;
o que não sabe.
Passo 3 — Confirme no código
Se a IA disser que um campo recebe dados de uma tabela Db2, procure:
EXEC SQL
SELECT ...
END-EXEC
Se afirmar que um programa é chamado, procure:
CALL 'PROGRAMA'
ou uma chamada dinâmica:
CALL WS-NOME-PROGRAMA
A resposta da IA é uma pista.
O código é a cena do crime.
Passo 4 — Consulte especialistas
Converse com:
analista de negócios;
programador experiente;
DBA;
administrador CICS;
equipe de produção;
segurança;
operação;
suporte;
usuário-chave.
Um operador pode saber que determinado job não deve executar antes das 2 horas porque depende de um arquivo externo que chega por transmissão.
Essa regra talvez não esteja no COBOL.
Passo 5 — Gere documentação revisável
Produza um documento contendo:
Nome do programa
Objetivo
Entradas
Saídas
Arquivos
Tabelas
Chamadas
Regras identificadas
Pontos de dúvida
Riscos
Testes necessários
Marque claramente o que foi:
confirmado;
inferido;
informado por especialista;
ainda não investigado.
Passo 6 — Crie testes antes de alterar
Antes de modernizar, capture o comportamento atual.
Inclua:
caso normal;
valores mínimos;
valores máximos;
zero;
negativo;
campo vazio;
dado inválido;
data de virada de mês;
ano bissexto;
duplicidade;
falha de arquivo;
erro SQL;
rollback;
timeout.
O programa antigo pode conter comportamentos estranhos.
Alguns são defeitos.
Outros são regras do negócio que ninguém documentou.
Não corrija aquilo que você ainda não compreendeu.
Passo 7 — Faça mudanças incrementais
Evite a estratégia:
Converter tudo
Desligar tudo
Torcer
Prefira:
Descobrir
↓
Documentar
↓
Testar
↓
Isolar
↓
Refatorar
↓
Comparar
↓
Implantar gradualmente
↓
Monitorar
Em mainframe, coragem sem controle de mudança recebe outro nome:
incidente de produção.
Capítulo 10 — O que a IA não consegue fazer sozinha
Mesmo uma ferramenta avançada não possui automaticamente:
conhecimento completo do negócio;
responsabilidade jurídica;
autoridade para alterar produção;
compreensão de acordos informais;
conhecimento de exceções históricas;
garantia absoluta de equivalência;
contexto de todos os sistemas externos;
discernimento político da organização;
memória dos incidentes antigos;
responsabilidade pelo resultado.
Ela também pode:
interpretar incorretamente uma condição;
ignorar uma chamada dinâmica;
não perceber dados montados em tempo de execução;
confundir código morto com código raramente usado;
sugerir tipos inadequados;
gerar testes insuficientes;
explicar com confiança uma regra que não existe.
Portanto:
IA SEM ESPECIALISTA
=
SUSPEITO INTERROGANDO A SI MESMO
A inteligência artificial deve atuar como assistente.
O profissional continua responsável pela decisão.
Capítulo 11 — Curiosidades encontradas no arquivo confidencial
Curiosidade 1 — COBOL não sobreviveu por acidente
Ele permanece porque milhões de regras empresariais foram codificadas, testadas e refinadas durante décadas.
Um programa pode parecer antigo, mas ter sobrevivido a:
mudanças de moeda;
fusões bancárias;
novas regulamentações;
crises econômicas;
mudanças tributárias;
milhões de execuções diárias.
Idade não é prova de qualidade.
Mas também não é prova de inutilidade.
Curiosidade 2 — “Legado” não significa “abandonado”
Legado é aquilo que foi herdado.
Uma aplicação pode ser antiga e continuar recebendo manutenção, integração, atualização de compilador, APIs e recursos de segurança.
O problema não é ser legado.
O problema é ser legado incompreendido.
Curiosidade 3 — A melhor modernização pode preservar o COBOL
Uma empresa pode:
manter o núcleo transacional em COBOL;
expor serviços por APIs;
integrar com aplicações móveis;
usar eventos e mensageria;
incorporar análises de IA;
modernizar a experiência do desenvolvedor;
automatizar testes e pipelines.
Modernização não exige obrigatoriamente remoção da linguagem.
Curiosidade 4 — Código morto pode estar apenas dormindo
Uma rotina pode não ser chamada há meses e ainda representar um processo anual, uma contingência ou um procedimento de recuperação.
Antes de removê-la, investigue:
scheduler;
JCL;
chamadas dinâmicas;
transações;
procedimentos manuais;
execução de fechamento anual;
planos de continuidade.
Como diria o detetive:
“Ausência de execução recente não é atestado de óbito.”
Easter egg — O comunicador de pulso
O jovem programador observou o relógio do detetive.
— Isso é uma espécie de smartphone?
— Smartphone? — respondeu ele. — Em 1946 eu já usava rádio de pulso nas histórias em quadrinhos.
O programador sorriu.
A ideia parecia futurista décadas antes de relógios inteligentes se tornarem produtos comuns.
O detetive então apontou para o terminal 3270:
— A tecnologia adora anunciar como novidade aquilo que alguém imaginou muito antes.
No canto da tela apareceu:
READY
Era o TSO aguardando o próximo comando.
Ou talvez fosse o próprio mainframe respondendo à notícia de sua morte.
Capítulo 12 — A sentença do caso
Depois de examinar programas, relatórios, declarações financeiras, diagramas e testes, o detetive reuniu todos na sala de operações.
— Já sei quem tentou matar o COBOL.
O programador arregalou os olhos.
— Foi a IA?
— Não.
— Java?
— Também não.
— A nuvem?
— Inocente neste caso.
O detetive escreveu no quadro:
CULPADO:
A SIMPLIFICAÇÃO EXCESSIVA
A narrativa de que uma IA converterá milhões de linhas COBOL e eliminará instantaneamente o mainframe ignora quase tudo o que torna uma aplicação corporativa complexa:
dados;
regras;
integrações;
segurança;
operação;
testes;
desempenho;
disponibilidade;
auditoria;
conhecimento humano;
risco empresarial.
A IA pode facilitar migrações? Sim.
Pode ajudar a transformar COBOL em Java? Sim.
Pode auxiliar na remoção de partes do legado? Sim.
Mas também pode:
documentar aplicações;
acelerar novos profissionais;
encontrar dependências;
preparar testes;
melhorar código COBOL;
isolar serviços;
aumentar a velocidade de entrega;
prolongar a vida econômica do IBM Z.
A tecnologia não possui uma única direção obrigatória.
Ela amplia a capacidade de quem a utiliza.
Conclusão — O COBOL não precisa de um coveiro; precisa de investigadores
A pergunta inicial era:
E se a inteligência artificial não fosse inimiga do COBOL, mas sua melhor aliada?
Depois de examinar as evidências, a resposta mais honesta é:
Ela pode ser uma grande aliada, desde que seja utilizada com conhecimento, governança, testes e responsabilidade humana.
O dado dos clientes que ampliaram MIPS três vezes mais rapidamente é uma declaração da própria IBM e não deve ser tratado como prova independente de causalidade. Ainda assim, ele oferece uma pista importante: aparentemente, pelo menos em parte do mercado, a adoção de IA para modernização não está sendo acompanhada por uma fuga imediata do mainframe.
Ao contrário, organizações capazes de compreender melhor suas aplicações podem encontrar novas razões para investir nelas.
O verdadeiro gargalo nunca foi simplesmente escrever COBOL.
O verdadeiro gargalo era entrar em um sistema com 30 ou 40 anos de história e responder com segurança:
O que este programa faz?
Quem o chama?
Quais dados ele altera?
Que regra empresarial está escondida aqui?
O que acontece se modificarmos esta condição?
Como provamos que nada foi quebrado?
Ferramentas como o watsonx Code Assistant for Z podem reduzir o tempo necessário para investigar essas perguntas. Elas não eliminam a necessidade do programador COBOL. Na realidade, tornam o profissional que conhece COBOL, negócio, testes, dados e arquitetura ainda mais valioso.
O iniciante não deve temer a IA.
Também não deve ajoelhar-se diante dela.
Deve aprender a interrogá-la.
Deve exigir evidências.
Deve comparar respostas com o código.
Deve verificar os dados.
Deve construir testes.
Deve conversar com especialistas.
Deve registrar as conclusões.
E, sobretudo, deve desconfiar de qualquer relatório que termine com:
RC=0000
sem explicar exatamente o que foi executado.
A chuva parou.
O detetive vestiu o sobretudo, ajustou o chapéu e caminhou em direção à porta.
Antes de partir, olhou uma última vez para o programador.
— Então o COBOL está salvo? — perguntou o jovem.
O detetive respondeu:
— Linguagens não são salvas por discursos. São salvas quando continuam resolvendo problemas.
No terminal, uma nova transação foi processada.
Depois outra.
Depois mais dez mil.
O relógio marcou duas da manhã.
O mainframe não estava morto.
Ele estava apenas começando o próximo batch.
Sem comentários:
Enviar um comentário