 |
| Bellacosa Mainframe e o misterioso caso da queda de 42% do lucro da ibm em 2026 |
☕ Um Café no Bellacosa Mainframe
IBM em o Mistério dos 42%: Inspetor Bellacoseau e o Estranho Caso do Mainframe que “Morreu” Outra Vez
Quando um programador COBOL iniciante descobre que uma queda trimestral pode ser apenas uma pista colocada ao contrário sobre a mesa
Era uma manhã aparentemente tranquila no Centro de Processamento de Dados.
Os operadores acompanhavam as filas do JES2. Os programas batch encerravam com CC 0000. O CICS respondia dentro dos acordos de nível de serviço. O Db2 trabalhava silenciosamente, protegendo milhões de registros. As unidades de armazenamento piscavam com aquela serenidade característica das máquinas que processam fortunas sem nunca aparecer nas fotografias das reuniões executivas.
Então aconteceu.
Uma manchete entrou no ambiente como um homem de sobretudo atravessando uma porta de vidro que julgava estar aberta:
“Receitas do IBM Z caem 42%.”
O silêncio tomou conta da sala.
Um jovem programador COBOL, ainda aprendendo a diferença entre COMP, COMP-3 e um campo alfanumérico que alguém decidiu usar para armazenar valores monetários, arregalou os olhos.
— Monsieur Bellacosa! O mainframe está morrendo!
Nesse instante, entrou em cena o Inspetor Bellacoseau, investigador especial de anomalias estatísticas, desaparecimentos de contexto e assassinatos prematuros de tecnologias corporativas.
Ele usava um sobretudo amassado, carregava uma lupa, três relatórios impressos e uma listagem COBOL de 1987 que ninguém ousava remover de produção.
Tropeçou no tapete, apoiou-se acidentalmente no botão de emergência, derrubou o café sobre o gráfico e declarou:
— Naturalmente! O culpado é evidente.
Todos esperaram.
— Só preciso descobrir quem ele é.
E assim começou o estranho caso dos 42% desaparecidos.
Capítulo I — A cena do crime
O número parecia incontestável:
IBM Z: queda de 42% em determinado trimestre.
Era grande, vermelho e suficientemente assustador para provocar cliques, debates e funerais simbólicos do mainframe nas redes sociais.
Mas o Inspetor Bellacoseau conhecia uma regra fundamental da investigação financeira:
Nenhum percentual deve ser interrogado sem a presença de sua base de comparação.
Uma queda de 42% em relação a quê?
Ao trimestre imediatamente anterior?
Ao mesmo trimestre do ano passado?
À média dos últimos quatro trimestres?
Ao pico extraordinário provocado pelo lançamento de uma nova geração?
Ao período em que os maiores bancos, governos, seguradoras e processadores de cartões realizaram suas migrações?
Essa pergunta muda tudo.
Considere dois valores hipotéticos:
Trimestre excepcional de lançamento: R$ 1 bilhão
Trimestre posterior de normalização: R$ 580 milhões
A queda é de 42%.
Matematicamente:
(R$ 580 milhões - R$ 1 bilhão) / R$ 1 bilhão × 100
= -42%
O cálculo está correto.
A interpretação, porém, pode estar completamente errada.
O trimestre de R$ 1 bilhão talvez não representasse o nível normal do negócio. Poderia ser um pico provocado pelo lançamento de uma nova geração do IBM Z.
Comparar o trimestre seguinte diretamente com esse pico é como comparar o movimento de uma agência bancária em um dia comum com o movimento do pagamento do décimo terceiro salário.
O movimento diminuiu?
Sim.
O banco perdeu seus clientes?
Não necessariamente.
O sistema entrou em colapso?
Provavelmente não.
O calendário operacional apenas mudou.
O Inspetor aproximou a lupa do relatório.
— Aha! Temos aqui uma vítima que talvez não esteja morta.
— O mainframe?
— Não. O contexto.
Capítulo II — O IBM Z não é vendido como pão quente
Para compreender o mistério, o programador COBOL iniciante precisa abandonar temporariamente a lógica dos produtos de consumo.
Um smartphone é vendido continuamente.
Um serviço de streaming recebe assinaturas todos os meses.
Um aplicativo pode conquistar milhares de usuários em poucos dias.
Um mainframe IBM Z pertence a outra categoria.
Estamos falando de uma plataforma empresarial de missão crítica, adquirida por organizações que normalmente possuem:
grandes volumes de transações;
aplicações desenvolvidas durante décadas;
exigências rígidas de disponibilidade;
regras regulatórias;
necessidades de criptografia e segurança;
contratos de suporte;
planejamento plurianual de capacidade;
ambientes com CICS, Db2, IMS, MQ, VSAM e milhares de jobs batch;
equipes inteiras responsáveis por arquitetura, infraestrutura e aplicações.
Uma instituição financeira não acorda numa terça-feira e decide:
“Hoje parece um bom dia para comprar um mainframe.”
A aquisição pode envolver meses ou anos de planejamento.
A empresa analisa:
crescimento do volume transacional;
consumo de CPU;
capacidade instalada;
necessidades de memória;
consolidação de servidores;
licenciamento de software;
eficiência energética;
continuidade de negócios;
recuperação de desastres;
segurança;
inteligência artificial;
modernização de aplicações;
integração com nuvem híbrida.
Quando surge uma nova geração, parte dos grandes clientes decide migrar relativamente cedo. Essas aquisições concentram receita no lançamento e nos trimestres imediatamente seguintes.
Depois disso, ocorre uma redução natural.
Não porque o produto tenha deixado de ser útil, mas porque muitos clientes que pretendiam migrar já fizeram seus pedidos.
É um ciclo.
O Inspetor Bellacoseau escreveu no quadro:
LANÇAMENTO
↓
ADOÇÃO INICIAL
↓
PICO DE RECEITA
↓
NORMALIZAÇÃO
↓
EXPANSÕES E ATUALIZAÇÕES
↓
PRÓXIMA GERAÇÃO
Então se afastou para admirar o diagrama, tropeçou na cadeira e apagou a palavra “normalização”.
— Curioso — disse ele. — Era justamente a palavra mais importante.
Capítulo III — O ciclo de lançamento visto como um processamento batch
Para um programador COBOL, a melhor maneira de compreender o ciclo do IBM Z é compará-lo com o calendário batch.
Imagine uma empresa que execute os seguintes volumes:
Dia comum: 20.000 jobs
Fechamento semanal: 45.000 jobs
Fechamento mensal: 110.000 jobs
Fechamento anual: 300.000 jobs
Dia seguinte: 22.000 jobs
Depois do fechamento anual, alguém publica:
“Volume de processamento cai 92,6% em apenas 24 horas.”
O cálculo seria tecnicamente verdadeiro:
(22.000 - 300.000) / 300.000 × 100
= -92,67%
Mas a conclusão de que a empresa perdeu 92% dos negócios seria absurda.
O volume de 300 mil jobs foi um evento excepcional.
O dia seguinte retornou ao comportamento normal.
É precisamente por isso que profissionais de produção não analisam apenas um ponto isolado. Eles conhecem:
Um especialista em desempenho também não observa um pico de CPU às duas horas da manhã e imediatamente conclui que o sistema está mal dimensionado.
Primeiro ele pergunta:
Qual job estava executando?
Houve fechamento?
Foi iniciado um reorganizador de banco?
Houve geração de relatórios?
O pico durou quanto tempo?
O WLM conseguiu atender às prioridades?
Os acordos de serviço foram afetados?
O comportamento se repete?
A base de comparação é apropriada?
O mesmo raciocínio deve ser aplicado aos resultados financeiros.
Um percentual sem contexto é como uma mensagem IEC141I sem o JCL, sem o catálogo e sem a informação do dataset envolvido.
Ela parece dramática.
Mas ainda não resolveu o incidente.
Capítulo IV — Tendência estrutural e oscilação cíclica não são a mesma coisa
Este é um dos pontos mais importantes da investigação.
Uma queda cíclica ocorre dentro de um comportamento esperado.
Uma queda estrutural indica deterioração persistente do negócio.
A diferença não aparece necessariamente em um único trimestre.
Para identificar uma tendência estrutural, seria preciso observar vários elementos ao longo do tempo:
redução contínua da demanda;
abandono da plataforma por grandes clientes;
diminuição persistente da base instalada;
ausência de novos workloads;
incapacidade de renovar a tecnologia;
queda prolongada da receita;
enfraquecimento do ecossistema;
perda de competitividade;
redução do investimento do fabricante;
diminuição da relevância operacional.
Já uma oscilação cíclica pode mostrar o comportamento oposto:
forte lançamento;
rápida adoção;
concentração de receita;
trimestre excepcional;
retorno posterior a níveis normais;
nova expansão com upgrades e capacidade;
preparação para o próximo ciclo.
Logo, observar “-42%” não é suficiente para declarar uma crise estrutural.
É apenas uma pista.
E uma pista deve ser examinada junto às outras.
O Inspetor Bellacoseau colocou duas fichas sobre a mesa:
FICHA A — QUEDA CÍCLICA
Produto segue relevante
Clientes continuam investindo
Receita oscila após o lançamento
Plataforma continua evoluindo
FICHA B — QUEDA ESTRUTURAL
Demanda desaparece
Clientes abandonam a plataforma
Inovação diminui
Ecossistema encolhe continuamente
Depois perguntou:
— Qual delas corresponde ao caso?
O jovem programador respondeu:
— Ainda não temos evidências suficientes.
O Inspetor sorriu.
— Excelente! Você já está mais qualificado que metade das manchetes.
Capítulo V — O estranho fenômeno da base alta
Existe uma armadilha estatística conhecida informalmente como efeito de base.
Quando um período anterior foi excepcionalmente forte, o período seguinte pode parecer muito fraco, mesmo continuando saudável.
Imagine uma empresa que normalmente venda R$ 100 milhões por trimestre.
Em razão do lançamento de um novo produto, ela vende R$ 180 milhões.
No trimestre seguinte, vende R$ 110 milhões.
Comparando com o pico:
(R$ 110 milhões - R$ 180 milhões) / R$ 180 milhões × 100
= -38,9%
A manchete poderia anunciar:
“Receita despenca quase 39%.”
Mas comparando com o nível normal anterior:
(R$ 110 milhões - R$ 100 milhões) / R$ 100 milhões × 100
= +10%
Agora a história seria:
“Receita permanece 10% acima do nível anterior ao lançamento.”
As duas frases derivam dos mesmos números.
Nenhuma precisa ser matematicamente falsa.
O que muda é o enquadramento.
Por isso o Inspetor Bellacoseau repetia:
“Diga-me o denominador e eu lhe direi o tamanho do escândalo.”
Nos sistemas mainframe, conhecemos problema semelhante.
Uma CPU a 80% pode ser excelente ou preocupante, dependendo do contexto.
Se o sistema processa toda a carga dentro do SLA, com WLM equilibrado e margem planejada, 80% pode ser sinal de boa utilização.
Se as transações CICS apresentam atrasos, as filas aumentam, há contenção de recursos e o batch invade a janela online, os mesmos 80% contam outra história.
O número não fala sozinho.
Nós o interrogamos.
Capítulo VI — O gráfico é um mapa, não o território
A imagem apresentada possui uma observação essencial:
O gráfico é uma ilustração pedagógica e não representa as vendas reais, pois a IBM não publica esse detalhamento completo por geração na forma mostrada.
Essa honestidade metodológica merece destaque.
Um gráfico conceitual serve para explicar uma ideia.
Ele não deve ser confundido com uma série histórica oficial.
As curvas ilustram um padrão:
pico
/\
/ \
_______/ \_______
Lançamento, aceleração, pico e normalização.
Porém, a realidade não forma ondas tão perfeitas. Ela sofre influência de:
condições econômicas;
orçamento dos clientes;
datas de fechamento de contratos;
disponibilidade de componentes;
câmbio;
decisões regulatórias;
expansão de capacidade;
consolidação de datacenters;
fusões bancárias;
estratégias de nuvem híbrida;
alterações de preço;
mudanças de licenciamento;
adoção de recursos específicos.
Portanto, o gráfico deve ser lido como um modelo mental.
Em engenharia de software fazemos isso constantemente.
Um diagrama simplificado pode mostrar:
Aplicação COBOL → CICS → Db2
Mas o ambiente real talvez inclua:
Cliente
↓
Balanceador
↓
API Gateway
↓
z/OS Connect
↓
CICS TOR
↓
CICS AOR
↓
Programa COBOL
↓
Db2 / VSAM / MQ
↓
SMF / RACF / WLM / Logs / Monitoramento
O primeiro diagrama não é falso.
É apenas uma simplificação com objetivo didático.
O perigo começa quando confundimos simplificação com medição.
Capítulo VII — O z17 entra no salão
Segundo a publicação analisada, o z17 estaria apresentando desempenho acumulado superior ao de seu predecessor no mesmo estágio do programa, sendo descrito como um lançamento excepcional.
Esse dado muda a natureza do mistério.
Se uma nova geração alcança forte adoção inicial, apresenta recursos valorizados pelos clientes e supera o ritmo de seu predecessor, uma queda posterior ao trimestre de lançamento pode ser compatível com normalização.
Não prova sozinho que tudo esteja perfeito.
Mas enfraquece bastante a interpretação superficial de que o produto estaria “morrendo”.
É necessário separar duas perguntas:
A receita caiu em comparação com determinado período?
A plataforma está perdendo relevância estrutural?
A resposta à primeira pode ser “sim”.
A resposta à segunda não decorre automaticamente da primeira.
Essa distinção é vital.
É possível ter:
Queda trimestral: sim
Produto malsucedido: não
Ciclo encerrado: não
Plataforma irrelevante: não
Necessidade de acompanhamento: sim
O programador COBOL iniciante deve aprender a trabalhar com afirmações precisas.
Em vez de dizer:
“O IBM Z caiu 42%, portanto está em colapso.”
Uma formulação melhor seria:
“A receita trimestral do IBM Z apresentou retração na base de comparação informada. Para determinar se isso representa normalização do ciclo ou deterioração estrutural, precisamos analisar o estágio do lançamento, o acumulado do programa, o histórico, a adoção dos clientes e outros indicadores.”
É menos espetacular.
Porém, é muito mais profissional.
Capítulo VIII — Inteligência artificial perto dos dados
Outro elemento mencionado na publicação é o interesse dos clientes nas capacidades de inteligência artificial do z17.
Para compreender a importância disso, precisamos lembrar onde os dados críticos vivem.
Em muitos grandes bancos, seguradoras e órgãos governamentais, o mainframe armazena ou processa informações como:
transações de cartões;
movimentações bancárias;
cadastros;
apólices;
sinistros;
pagamentos;
registros fiscais;
benefícios;
reservas;
inventários;
autenticações;
históricos financeiros.
Tradicionalmente, uma organização poderia extrair dados desses sistemas, copiá-los para outra plataforma e executar modelos analíticos ou de IA fora do ambiente transacional.
Isso cria desafios:
Executar determinadas inferências próximas do local onde a transação ocorre pode oferecer vantagens.
Imagine uma autorização de cartão.
O fluxo simplificado pode ser:
Compra
↓
Autorização
↓
Consulta de conta
↓
Avaliação de regras
↓
Análise de risco
↓
Aprovação ou recusa
Se um modelo puder ajudar a avaliar fraude durante esse fluxo, sem exigir uma longa viagem dos dados até outra plataforma, a decisão pode ocorrer com menor latência e melhor integração operacional.
Isso não significa que toda IA será executada no mainframe.
O cenário mais provável é híbrido.
Alguns modelos serão treinados em ambientes especializados.
Outras cargas serão executadas em nuvens ou clusters distribuídos.
Determinadas inferências críticas poderão ocorrer perto dos sistemas de registro.
A arquitetura torna-se uma colaboração entre plataformas, não uma guerra religiosa entre servidores.
O Inspetor Bellacoseau tentou demonstrar isso com três caixas de papelão rotuladas “Mainframe”, “Nuvem” e “IA”.
Entrou acidentalmente na caixa da nuvem, caiu sobre a caixa do mainframe e concluiu:
— Voilà! Integração híbrida.
Capítulo IX — O mainframe não precisa vencer todas as batalhas
Um erro recorrente nas discussões tecnológicas é imaginar que uma plataforma só permanece relevante se substituir todas as outras.
O IBM Z não precisa executar todos os sites, todos os aplicativos móveis, todos os modelos de linguagem e todos os sistemas empresariais do planeta.
Sua relevância depende de continuar excelente nas cargas para as quais foi projetado e de integrar-se bem ao restante do ecossistema.
Entre essas cargas estão:
processamento transacional em grande escala;
alta disponibilidade;
consolidação;
segurança;
consistência;
batch crítico;
grandes bancos de dados;
sistemas de registro;
operações com exigência regulatória;
aplicações cuja interrupção possui grande impacto financeiro.
É semelhante ao COBOL.
COBOL não precisa se tornar a linguagem dominante para aplicativos de realidade virtual.
Ele precisa continuar adequado aos sistemas empresariais que manipulam regras de negócio, registros estruturados, valores monetários e processamento de grandes volumes.
A pergunta madura não é:
“Qual tecnologia vence?”
A pergunta correta é:
“Qual tecnologia atende melhor a esta carga, neste contexto, com estes requisitos?”
Esse pensamento é arquitetura.
O restante é torcida organizada com teclados mecânicos.
Capítulo X — Passo a passo para investigar um número chocante
Sempre que encontrar uma manchete espetacular, siga o método Bellacoseau de investigação estatística.
Passo 1 — Descubra a métrica exata
“Receita” pode significar muitas coisas.
Pergunte:
Receita de hardware?
Receita de toda a divisão?
Receita reconhecida no trimestre?
Pedidos assinados?
Receita acumulada?
Crescimento em moeda constante?
Crescimento nominal?
Comparação anual ou sequencial?
Não aceite uma palavra genérica quando o relatório oferece uma definição específica.
Passo 2 — Identifique a base de comparação
Procure expressões como:
Uma queda de 42% comparada ao pico de lançamento possui significado diferente de uma queda de 42% contra um trimestre normal da geração anterior.
Passo 3 — Localize o produto dentro do ciclo
Pergunte:
A geração acabou de ser lançada?
Estamos nos primeiros trimestres?
A maioria dos grandes clientes já migrou?
O período anterior foi excepcional?
Há renovação prevista?
Existem expansões futuras de capacidade?
Passo 4 — Observe vários períodos
Nunca conclua uma tendência com um único ponto.
Analise:
T-4 → T-3 → T-2 → T-1 → T atual
Melhor ainda, compare ciclos equivalentes entre gerações.
Por exemplo:
Segundo trimestre após z16
versus
segundo trimestre após z17
Essa comparação pode ser mais útil do que confrontar um trimestre normal com o pico inicial.
Passo 5 — Procure indicadores complementares
Receita é importante, mas não é a única pista.
Observe também:
Passo 6 — Leia as observações metodológicas
Notas de rodapé costumam conter as informações que impedem conclusões precipitadas.
No gráfico analisado, a observação de que as curvas não representam vendas reais é indispensável.
Ignorá-la seria tratar uma maquete como fotografia aérea.
Passo 7 — Separe fato, interpretação e opinião
Exemplo:
Fato informado:
A receita caiu 42% segundo determinada comparação.
Interpretação:
A queda pode refletir a normalização após um trimestre de lançamento.
Opinião:
O mercado exagerou ao interpretar o resultado como sinal de colapso.
As três camadas podem coexistir, mas não devem ser misturadas.
Capítulo XI — Curiosidades para o padawan COBOL
Curiosidade 1 — O mainframe já “morreu” muitas vezes
A morte do mainframe é anunciada há décadas.
Surgiram minicomputadores, Unix, cliente-servidor, PCs, internet, Java, servidores x86, virtualização, nuvem e microsserviços.
O IBM Z não permaneceu vivo por magia ou nostalgia.
Permaneceu porque evoluiu e porque determinadas organizações ainda possuem problemas que ele resolve muito bem.
Curiosidade 2 — A plataforma moderna não é uma fotografia dos anos 1970
O imaginário popular costuma associar mainframes a cartões perfurados e terminais verdes.
Entretanto, o ecossistema atual pode envolver:
APIs REST;
containers;
Linux;
Git;
pipelines de CI/CD;
IDEs modernas;
automação;
observabilidade;
integração híbrida;
inteligência artificial;
criptografia avançada.
O terminal 3270 continua importante, mas não define sozinho toda a plataforma.
Curiosidade 3 — Receita de hardware não conta toda a história
A presença de uma plataforma pode gerar receitas em várias áreas:
software;
manutenção;
serviços;
consultoria;
armazenamento;
integração;
suporte;
modernização;
assinaturas.
Analisar apenas uma linha pode não revelar todo o valor econômico associado ao ecossistema.
Curiosidade 4 — Um cliente pode comprar capacidade sem substituir tudo
Nem toda aquisição representa uma instalação completamente nova.
Clientes podem expandir:
O ciclo real é mais complexo que “compra uma máquina e espera três anos”.
Capítulo XII — Easter eggs do caso
Em algum ponto da investigação, o Inspetor Bellacoseau encontrou uma mensagem misteriosa dentro de um relatório:
01 WS-PERCENTUAL PIC S9(3)V99 COMP-3.
01 WS-CONTEXTO PIC X(100).
IF WS-PERCENTUAL < ZERO
AND WS-CONTEXTO = SPACES
DISPLAY 'ERRO: MANCHETE SEM CONTEXTO'
END-IF.
O programa compilava.
Mas em produção gerava o misterioso abend:
ABEND S0C7 — INVALID NUMERIC CONTEXT
Após horas de investigação, descobriu-se que alguém havia movimentado a palavra "COLAPSO" para um campo numérico compactado.
Uma metáfora perfeita.
Quando colocamos opinião dentro de um campo que deveria conter medida, o resultado costuma ser um erro de dados.
Outro easter egg estava escondido no nome do job:
//PINK042 JOB (CAFE),'INVESTIGA',
// CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//STEP01 EXEC PGM=CONTEXT
//REPORT DD DSN=IBM.Z.CYCLE.REPORT,DISP=SHR
//HEADLINE DD SYSOUT=*
//SYSIN DD *
COMPARE BASE=LAUNCH
CHECK CYCLE=YES
AVOID PANIC=YES
/*
O job terminou com:
MAXCC=0000
Mas a manchete foi publicada antes do fim da execução.
Capítulo XIII — O que ainda precisa ser acompanhado
Contextualizar a queda não significa ignorá-la.
Este é um ponto crucial.
Defender uma análise equilibrada não consiste em afirmar que qualquer queda é irrelevante.
Um profissional sério continuará acompanhando:
desempenho dos próximos trimestres;
força do ciclo completo do z17;
ritmo de expansão após a adoção inicial;
participação dos recursos de IA;
comportamento das receitas de software;
adoção por clientes existentes;
conquista de novas cargas;
integração com nuvem híbrida;
competitividade econômica;
custos de licenciamento;
disponibilidade de profissionais especializados;
modernização das aplicações legadas.
Uma queda cíclica pode ser normal.
Uma sequência prolongada de quedas, combinada com outros sinais negativos, exigiria revisão da hipótese.
É assim que funciona uma investigação.
Criamos uma hipótese.
Buscamos evidências.
Tentamos refutá-la.
Atualizamos a conclusão quando surgem novos dados.
Não nos apaixonamos pela primeira explicação.
Nem mesmo quando ela usa um gráfico muito bonito em azul neon.
Capítulo XIV — A lição para a carreira do programador COBOL
O caso dos 42% ensina algo muito maior que análise financeira.
Ele ensina a pensar como profissional de sistemas críticos.
Um programador iniciante frequentemente olha apenas para a linha onde o erro apareceu.
O profissional experiente procura:
o fluxo anterior;
os dados de entrada;
o estado da transação;
as dependências;
os logs;
as mensagens;
o histórico;
o ambiente;
as mudanças recentes;
a regra de negócio.
O mesmo acontece na análise de métricas.
O iniciante vê:
-42%
O especialista vê:
Métrica
Base
Período
Ciclo
Sazonalidade
Evento excepcional
Histórico
Metodologia
Indicadores complementares
Essa capacidade de enxergar contexto é uma das maiores diferenças entre alguém que apenas escreve código e alguém que compreende sistemas.
COBOL ensina isso todos os dias.
Um campo não existe isoladamente.
Ele pertence a um registro.
O registro pertence a um arquivo.
O arquivo pertence a um processo.
O processo pertence a uma cadeia de negócio.
A cadeia atende clientes, contratos, regulações e operações reais.
Da mesma forma, um percentual pertence a um relatório, a uma comparação, a um ciclo e a uma estratégia.
Conclusão — O mainframe estava vivo na biblioteca
Ao final da investigação, todos se reuniram na sala de operações.
O Inspetor Bellacoseau caminhou diante dos suspeitos:
Ele apontou dramaticamente para o culpado.
— Foi o número!
O jovem programador interrompeu:
— Mas o número estava correto.
O Inspetor hesitou.
— Exatamente. Então foi a comparação!
— A comparação também estava matematicamente correta.
— Nesse caso… foi a ausência de contexto!
Finalmente, o mistério estava resolvido.
A queda de 42% não deveria ser ignorada, mas também não poderia ser transformada automaticamente em prova da morte do IBM Z.
Ela precisava ser interpretada dentro de um negócio marcado por lançamentos geracionais, grandes contratos, migrações concentradas e normalização posterior.
O z17 poderia ter um lançamento recorde e, ainda assim, apresentar queda depois de um trimestre extraordinário.
Essas duas coisas não são contraditórias.
São partes do mesmo ciclo.
A lição final ficou registrada no mural do CPD:
Nunca faça COMPUTE antes de verificar o VALUE OF CONTEXT.
Ou, em linguagem menos COBOL:
Quando um número chocante aparecer, não pergunte apenas quanto ele subiu ou caiu. Pergunte de onde veio, com o que foi comparado e em qual momento do ciclo foi medido.
O Inspetor Bellacoseau ergueu sua xícara.
— Caso encerrado!
Nesse instante, encostou-se no console, cancelou o job errado e apagou as luzes do corredor.
Ao fundo, uma melodia misteriosa começou a tocar.
O mainframe continuou processando.
Como sempre.
