✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe e o custo medio de uso do mainframe 4HRA
🔥💣 “O MAINFRAME NÃO FICOU CARO — VOCÊ É QUE DEIXOU O R4HA VIRAR UM INCÊNDIO” ☕💾
Rolling 4HRA no IBM Z: A Verdade Brutal que Todo Sysprog Junior Descobre Quando o CPU Começa a Derreter
Padawan…
Existe um momento sombrio na vida de todo SYSprog junior.
Um momento em que:
o CPU começa a subir,
o RMF vira filme de terror,
o DBA começa a suar frio,
o gerente pergunta sobre custos,
e alguém pronuncia uma sigla maldita dentro da sala de guerra:
🚨 R4HA
Ou:
🔥 Rolling 4-Hour Average
Nesse instante…
Você deixa de ser apenas “o cara que olha JES2 e IPL”.
E começa a entender a realidade brutal do mundo IBM Z moderno:
O maior inimigo do mainframe não é a falta de potência.
É workload mal otimizado queimando MSU como se CPU fosse lenha.
☕ O GRANDE MITO: “MAINFRAME É CARO”
Padawan…
O IBM Z não ficou caro por acaso.
O problema é que muita empresa roda:
SQL desastroso,
batch sem controle,
SORT monstruoso,
loops infinitos,
CICS mal desenhado,
e workloads completamente desequilibrados.
Depois olha para a conta mensal e diz:
“o mainframe custa caro”.
É como culpar a usina elétrica porque alguém deixou um forno industrial ligado dentro da garagem.
Bellacosa Mainframe e o rolling 4hra
🔥 O QUE É O ROLLING 4HRA?
O Rolling 4HRA é:
uma média móvel de consumo de CPU/MSU das últimas 4 horas.
Mas dizer só isso é simplificar demais.
Na prática ele é:
💀 O SENSOR FINANCEIRO DO DATACENTER
Porque ele mede:
consumo sustentado,
pressão operacional,
tendência de carga,
risco financeiro,
e eficiência arquitetural do ambiente.
💾 O MAINFRAME NÃO TEM MEDO DE PICOS
Esse é o detalhe genial do modelo IBM Z.
O sistema foi construído para absorver:
explosões de workload,
fechamento bancário,
Black Friday,
processamento massivo,
milhões de transações.
O problema nunca foi:
o pico curto.
O problema é:
🔥 O INCÊNDIO CONTÍNUO
É aí que o R4HA entra.
☕ A FILOSOFIA POR TRÁS DO R4HA
Imagine um motor Ferrari.
Uma acelerada rápida:
não destrói o motor.
Mas manter:
giro máximo,
temperatura extrema,
pressão contínua,
por horas…
Aí o sistema começa a sofrer.
O Rolling 4HRA existe justamente para medir:
desgaste sustentado.
🚨 POR QUE A IBM USA ISSO?
Porque seria injusto cobrar:
pelo pico de alguns minutos.
Então o ecossistema IBM criou:
média móvel de 4 horas.
Isso suaviza:
explosões temporárias,
spikes pequenos,
ruídos operacionais.
Mas também revela:
workloads persistentemente ruins.
🔥 E É AQUI QUE O SYSprog PADAWAN ACORDA PARA A VIDA
Você percebe que:
CPU não é apenas CPU.
Ela virou:
dinheiro,
licensing,
SLA,
capacidade,
reputação operacional.
No IBM Z moderno:
💰 MSU = DINHEIRO
💣 QUANDO O DESASTRE COMEÇA
Tudo parece normal.
Até que alguém sobe:
um SQL sem índice,
um tablespace scan monstruoso,
um batch paralelo sem controle,
um SORT insano,
um COBOL looping,
um CICS runaway task.
Aí…
O CPU começa a subir.
Mas o verdadeiro terror ainda nem começou.
☕ O “EFEITO VENENO” DO R4HA
Esse conceito separa:
o junior do veterano.
Porque mesmo depois de corrigir o problema:
o R4HA continua alto.
E o padawan pergunta:
“Mas já cancelamos o job… por que continua ruim?”
Porque o Rolling 4HRA:
ainda está carregando o histórico do desastre.
🔥 O R4HA TEM MEMÓRIA
Ele funciona como:
uma onda de calor.
Mesmo após apagar o incêndio:
o ambiente continua quente.
Isso gera:
impacto financeiro,
impacto operacional,
pressão no capacity planning.
💾 O ERRO CLÁSSICO DOS JUNIORS
Confundir:
CPU instantânea com
Rolling 4HRA.
São coisas completamente diferentes.
Você pode ter:
CPU baixa AGORA,
mas R4HA altíssimo.
Porque a média móvel ainda está contaminada pelas horas anteriores.
🚨 O QUE MAIS INCENDIA O R4HA?
🔥 DB2
Aqui mora um dos maiores vilões do datacenter.
Um único SQL ruim pode:
destruir cache,
explodir SORT,
aumentar GETPAGE,
saturar CPU,
gerar scan absurdo.
E tudo isso:
alimenta o R4HA.
🔥 CICS
Quando mal desenhado:
vira um triturador de MSU.
Problemas clássicos:
pseudo-conversational ruim,
polling excessivo,
loops de transação,
runaway tasks,
filas gigantes.
🔥 BATCH
O batch mal otimizado é um clássico.
Especialmente:
DFSORT gigantesco,
JOINKEYS abusivo,
I/O thrashing,
múltiplos jobs concorrentes.
O resultado:
💀 tempestade de CPU
☕ O WLM TENTA SALVAR O AMBIENTE
O WLM funciona como:
o maestro do caos.
Ele tenta:
priorizar workloads,
proteger online,
equilibrar recursos,
manter SLA.
Mas quando:
tudo começa a consumir demais…
Nem o WLM faz milagre.
🔥 SOFT CAPPING: A FACA DE DOIS GUMES
Então alguém diz:
“Vamos limitar MSU!”
Aí nasce o:
💣 Soft Capping
Objetivo:
evitar explosão financeira.
Mas se configurado errado:
batch atrasa,
online degrada,
filas explodem,
SLA morre.
💾 O PARADOXO DO SYSprog
Se libera CPU: 💰 custo explode.
Se limita demais: 💀 produção explode.
Esse equilíbrio delicado é uma das artes mais difíceis do IBM Z.
🚨 O QUE O SYSprog EXPERIENCED APRENDE
Ele aprende que performance tuning não é:
“deixar rápido”.
É:
🔥 impedir o datacenter de sangrar dinheiro
☕ O MAINFRAME MODERNO É UMA MÁQUINA DE EFICIÊNCIA
O IBM Z moderno:
processa milhões de TPS,
roda bancos inteiros,
suporta cloud híbrida,
executa IA,
integra APIs,
conversa com Kubernetes,
roda Linux massivamente.
O hardware é absurdamente poderoso.
O problema normalmente está:
no workload.
💣 O MAINFRAME NÃO ESTÁ LENTO
Na maioria dos casos:
o ambiente está sendo sabotado por software ruim.
E o Rolling 4HRA:
apenas revela isso de forma cruel.
🔥 O DIA EM QUE O PADAWAN EVOLUI
A evolução acontece quando ele entende:
tuning não é estética
Não é:
“ganhar benchmark”.
É:
sobrevivência financeira,
estabilidade operacional,
sustentabilidade do ambiente.
☕ RMF: O ORÁCULO DO IBM Z
O SYSprog veterano aprende a ler:
RMF,
SMF 70,
SMF 72,
OMEGAMON,
MXG,
IntelliMagic.
Porque nesses relatórios está:
a verdade do ambiente.
O R4HA conta uma história.
E essa história normalmente aponta:
quem está incendiando CPU.
🔥 O MAINFRAME CONTINUA SENDO O REI
E aqui está a ironia maravilhosa.
Mesmo sob caos:
milhões de transações continuam funcionando,
ATM continua online,
PIX continua passando,
cartão continua autorizando,
folha continua fechando.
Enquanto isso…
o IBM Z aguenta pancada absurda silenciosamente.
💾 A GRANDE VERDADE
O problema nunca foi:
a potência do mainframe.
O problema é:
arquitetura ruim,
SQL ruim,
falta de governança,
tuning inexistente,
e desconhecimento sobre workload management.
☕ LIÇÃO FINAL DO PADAWAN IBM Z
Quando você olha um Rolling 4HRA:
você não está vendo apenas CPU.
Você está vendo:
comportamento do ambiente,
disciplina operacional,
maturidade técnica,
eficiência arquitetural,
e o custo real das decisões ruins.
🔥 FRASE FINAL ESTILO BELLACOSA MAINFRAME
“O IBM Z não cobra caro por existir. Ele apenas expõe, em MSU e R4HA, todas as decisões ruins que alguém colocou em produção.” ☕💾🔥
🔥 Rollinf 4HRA
O Rolling 4HRA (Rolling 4-Hour Average) é a média móvel de consumo de capacidade do mainframe IBM Z durante as últimas quatro horas. Ele mede o uso sustentado de CPU e MSU, sendo utilizado pelo WLM, RMF e modelos de licenciamento IBM para calcular custos e avaliar performance do ambiente. Diferente do uso instantâneo de CPU, o 4HRA continua elevado mesmo após um pico terminar, refletindo impactos anteriores no workload. Por isso, SQL ruim, batch pesado e loops podem aumentar custos significativamente.
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:
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.
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:
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?”
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.
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.
Bellacosa Mainframe falando sobre performance e custo de processamento
💣🔥 10 MIL SEGUNDOS ROUBADOS POR DIA: O ASSASSINO SILENCIOSO DO SEU MAINFRAME 🔥💣
Por que cada milissegundo no z/OS pode ser a diferença entre lucro e caos
🧠 Performance na veia, sem anestesia
No mundo do processamento de transações em alto volume, “rápido o suficiente” é uma mentira confortável.
Quando você roda milhões (ou bilhões) de transações por dia em um ambiente como z/OS, qualquer ineficiência — mesmo microscópica — vira um monstro financeiro.
Não importa se você escreve em COBOL, PL/I ou Java.
Se o seu código desperdiça tempo, o mainframe cobra — e cobra caro.
👉 Performance tuning não é “nice to have”.
👉 É sobrevivência corporativa.
⚙️ O Efeito Multiplicador (ou: como 10ms viram uma conta absurda)
Vamos ao ponto crítico:
Você otimiza um trecho e economiza 10 milissegundos.
Agora multiplica isso:
1.000.000 execuções por dia
Resultado:
👉 10.000 segundos economizados/dia (~2h46min de CPU)
Agora entra o mundo real:
Menos CPU → menos consumo de MSU
Menos MSU → menor custo de licenciamento
Menos contenção → mais throughput
Mais throughput → mais negócio rodando
💣 Resumo estilo Bellacosa:
“Você não economizou milissegundos… você salvou dinheiro REAL.”
🧨 Onde isso explode na prática
💥 Cenário clássico (batch assassino)
Um JOB COBOL com loop:
PERFORM VARYING WS-I FROM 1 BY 1 UNTIL WS-I > 1000000 EXEC SQL SELECT * INTO :HOST-VAR FROM CLIENTES WHERE ID = :WS-I END-EXEC END-PERFORM
💀 Problemas:
SELECT * (crime hediondo)
1 milhão de chamadas SQL
Possível table scan
🔧 Cirurgia de performance (passo a passo)
1️⃣ Reduzir dados (SQL cirúrgico)
SELECT NOME, STATUS FROM CLIENTES WHERE ID = ?
✔ Menos I/O
✔ Menos CPU
✔ Menos transporte de dados
2️⃣ Garantir acesso via índice
Use EXPLAIN no DB2:
Evite:
TABLE SCAN 😱
Busque:
INDEX SEEK 😎
3️⃣ Trocar loop por processamento em bloco
💡 Em vez de 1 milhão de SELECTs:
Use cursor
Ou fetch em lote
4️⃣ Buffer Pool tuning (ouro puro)
Se seu dado é acessado frequentemente:
Ajuste buffer pools
Evite I/O físico
💣 Easter Egg:
Em muitos ambientes, só ajustar buffer pool já deu ganho de 30%+ sem mexer em uma linha de código.
🚀 Quick Wins que parecem pequenos… mas NÃO são
🧩 1. SQL eficiente
Nunca use SELECT *
Sempre valide acesso via índice
Use EXPLAIN como religião
⚡ 2. Compiler moderno (COBOL v6+)
Se você ainda usa compilador antigo:
💀 Você está ignorando otimizações do hardware moderno
Ganhos comuns:
Melhor uso de CPU
Otimização automática de loops
Instruções mais eficientes
💾 3. Movimento de dados (I/O mata performance)
Regra de ouro:
“Disco é lento. Memória é rei.”
Faça:
Cache inteligente
Sort interno (quando adequado)
Evite leituras repetidas
🧠 Curiosidade de guerra (história real de bastidor)
Em um banco:
Um único SELECT mal indexado
Executado milhões de vezes/dia
Resultado após correção:
👉 Redução de MSU suficiente para economizar dezenas de milhares por mês
💣 O código tinha 10 anos em produção
💣 Ninguém questionava
💣 Até alguém olhar com lupa
🔍 Análise profunda (nível arquiteto)
Performance no mainframe não é só código.
É um ecossistema:
CPU (MIPS/MSU)
I/O (disco vs memória)
Locking (DB2)
Concorrência (CICS)
Batch window
👉 Uma otimização local pode gerar ganho global
👉 Ou causar efeito colateral (cuidado!)
🧨 Anti-patterns que destroem performance
SELECT *
Loop com SQL dentro
Falta de índice
Reprocessamento de dados
Leitura repetida de VSAM/DB2
Uso de compilador legado
🏆 O verdadeiro “modernizar o mainframe”
Não é só:
API
Cloud
Microservices
💣 Isso é maquiagem se o core estiver ineficiente
Modernizar de verdade é:
✔ Código otimizado
✔ Banco bem indexado
✔ CPU bem utilizada
✔ I/O sob controle
🔥 Conclusão (estilo Bellacosa raiz)
“Mainframe não é lento.
Código ruim é.”
Um sistema bem ajustado não é só estável —
👉 Ele vira vantagem competitiva.
🛠️ Provocação final
Qual foi aquele “fix ridiculamente simples” que você fez e:
Derrubou consumo de CPU?
Salvou batch window?
Ou evitou um caos em produção?
Se cavar… todo ambiente tem um “vilão escondido” esperando alguém enxergar.
MIPS, MSU e o Mistério da Conta que Cresce Mais Rápido que o Banco
Ou: como um programador COBOL iniciante descobre que um PERFORM inocente pode terminar numa reunião com o CFO
Se você está começando em COBOL, provavelmente alguém já lhe contou a versão resumida da história.
O mainframe é grande.
O mainframe é caro.
MIPS é alguma coisa relacionada a capacidade.
MSU é alguma coisa relacionada a cobrança.
E se você mexer num programa errado, algum senhor de barba grisalha aparecerá atrás de você com uma planilha impressa e uma expressão que significa:
— Filho… o que exatamente você colocou em produção ontem?
Essa versão não está completamente errada.
Mas está longe de contar a história inteira.
Porque existe um detalhe fascinante no universo IBM Z: uma linha de código pode ser tecnicamente correta, produzir exatamente o resultado esperado, passar nos testes, não gerar ABEND, não provocar S0C7, não derrubar CICS, não assustar RACF e ainda assim ser economicamente horrível.
E é aqui que nosso jovem gafanhoto COBOL entra no dojo.
Imagine o Sr. Miyagi diante de um terminal 3270.
Ele olha para você e diz:
— Bellacosa-san… programa bom não é programa que apenas funciona.
Você pergunta:
— Então o que é?
Ele aponta para o SMF.
— Programa bom trabalha certo, trabalha rápido e não põe fogo na fatura.
A aula começa.
🥋 1. Primeiro golpe: MIPS não é MSU
Antes de continuar, precisamos desmontar uma confusão muito comum.
MIPS e MSU aparecem frequentemente na mesma conversa, mas não são a mesma coisa.
MIPS significa, historicamente:
Millions of Instructions Per Second.
É uma forma tradicional de falar de capacidade computacional.
Só que em mainframe moderno isso precisa ser tratado com cuidado, porque uma “instrução” não é simplesmente uma moedinha universal que vale a mesma coisa em qualquer processador, geração ou workload.
Duas máquinas podem ter características diferentes.
Dois workloads podem exercitar partes diferentes do processador.
Uma aplicação matemática pesada se comporta de uma forma.
Um workload de transações CICS de outra.
Um batch COBOL gigante de outra.
Por isso, MIPS virou muito mais uma linguagem de capacidade e planejamento — e também, em muitos casos, uma unidade comercial usada por fornecedores de software — do que uma medida física absoluta.
MSU significa:
Million Service Units.
E aqui entramos diretamente no mundo de pricing e capacidade do software IBM Z.
A primeira regra do dojo é esta:
MIPS é normalmente uma conversa sobre capacidade. MSU pode ser uma conversa sobre capacidade, licenciamento e custo.
Mas cuidado.
Não saia por aí tentando converter:
1 MSU = 7,3 MIPS
como se estivesse convertendo quilômetros em milhas.
Não funciona assim.
Não existe uma conversão universal simples.
Se algum colega lhe entregar uma tabela mágica dizendo:
MSU × número secreto = MIPS
faça aquilo que todo programador COBOL experiente faz diante de uma planilha duvidosa:
olhe desconfiado.
Depois peça a fonte.
🧠 2. CPU também não é custo
Aqui vem a segunda rasteira.
O iniciante pensa:
“Se meu programa gastou 10% mais CPU, a empresa pagará 10% mais.”
Não necessariamente.
Você pode gastar mais CPU sem aumentar determinada parte do custo.
Pode gastar a mesma CPU e aumentar a conta.
Pode diminuir CPU e ter pouco impacto financeiro.
Pode simplesmente mudar o horário de execução e alterar completamente o efeito econômico.
Você acabou de conhecer uma das verdades mais importantes do mainframe:
Performance e custo são parentes, mas não são gêmeos.
Isso explica um fenômeno aparentemente absurdo.
Um banco pode crescer 8% em volume de negócio.
O consumo pode crescer 15%.
E a conta de software subir 30%.
O CFO olha para aquilo e pergunta:
— Quem roubou os outros 22%?
Nesse momento todos olham para o mainframe.
O mainframe olha para o teto.
O COBOL olha para o Db2.
O Db2 olha para o batch.
E o batch diz:
— Eu só estava seguindo o JCL.
⏰ 3. Conheça o monstro chamado R4HA
Agora o Sr. Miyagi pega quatro pedras e coloca sobre a mesa.
Cada pedra representa uma hora.
Ele diz:
— Quatro horas. Observe.
Em vários modelos tradicionais de subcapacity pricing existe um conceito muito importante:
Em determinados modelos tradicionais de cobrança, o pico relevante dessa média móvel pode influenciar a capacidade faturável.
E então acontece a tragédia clássica.
Durante o dia:
CICS 70
Db2 40
APIs 20
online geral 15
Tudo administrável.
Às 17h alguém dispara:
fechamento
relatório regulatório
batch contábil
extração de dados
reconciliação
backup lógico
Todos juntos.
Porque sempre foi assim.
Desde 1998.
Ninguém sabe exatamente por quê.
Mas existe um comentário no JCL:
//* NAO ALTERAR - PRODUCAO
E isso, no mainframe, às vezes tem o mesmo poder psicológico de uma placa escrita:
TUMBA DO FARAÓ — NÃO ABRIR.
O consumo dispara.
O banco não ficou três vezes maior.
O mundo não começou a fazer três vezes mais PIX.
Apenas vários workloads decidiram executar simultaneamente.
E aquela concentração pode produzir impacto econômico.
Esse é um dos motivos pelos quais scheduling pode ser tão importante quanto programação.
🎯 4. Primeira lição de ouro: deslocar não é otimizar
Imagine um batch que consome:
60 CPU seconds
Você executa às 17h.
Depois desloca para 02h.
Ele continua consumindo:
60 CPU seconds
Tecnicamente você não otimizou o código.
Não reduziu nenhuma instrução.
Não mexeu no COBOL.
Não mudou Db2.
Não alterou VSAM.
Mas pode ter melhorado a economia do ambiente dependendo do modelo de cobrança.
Isso é lindo porque destrói uma ideia muito comum:
otimização = mexer no programa.
Não.
Você pode otimizar:
código;
SQL;
scheduling;
arquitetura;
classificação de workload;
uso de processadores especializados;
política de capacidade;
configuração;
contrato.
Programador COBOL iniciante costuma enxergar apenas o programa.
Engenheiro mainframe experiente começa a enxergar o sistema inteiro.
Essa é a evolução.
🧾 5. Antes de mexer em qualquer coisa, descubra o contrato
Aqui está uma frase que deveria ser impressa em canecas:
Antes de otimizar o mainframe, descubra como o mainframe está sendo cobrado.
Porque não existe “a conta do mainframe”.
Existem várias contas.
Você pode ter:
hardware
software IBM
software ISV
storage
suporte
DR
licenças por capacidade
licenças por consumo
licenças por MIPS
modelos tradicionais
Tailored Fit Pricing
contratos especiais
E cada parte pode reagir de maneira diferente.
Imagine que você passe uma semana reduzindo um batch em 20%.
Excelente.
Mas descubra depois que aquele componente específico não altera o custo relevante do contrato atual.
Você melhorou performance.
Ótimo.
Só não economizou o que esperava.
Agora faça o contrário.
Você move um workload, altera uma janela de execução e reduz um pico economicamente relevante.
Nenhuma linha COBOL mudou.
E o financeiro percebe o efeito.
Bem-vindo ao mainframe.
🐍 6. O segundo monstro está dentro do seu COBOL
Agora finalmente chegamos à parte que interessa diretamente ao jovem programador.
Imagine este código:
PERFORM UNTIL WS-EOF = 'Y'
READ ARQUIVO-CLIENTES
...
END-PERFORM.
Em 2001 o arquivo tinha:
500.000 registros
Em 2026:
40.000.000 registros
O código não piorou.
Ele é exatamente o mesmo.
Mas o mundo ao redor cresceu.
Isso ensina uma coisa importante:
Código velho pode ficar economicamente pior sem mudar uma única linha.
Quantas execuções?
Quantos registros?
Quantas transações?
Qual crescimento mensal?
Passo 3 — observe o custo por unidade
Não pense apenas:
programa gastou 200 CPU seconds
Pergunte:
200 CPU seconds para quantos registros?
Passo 4 — procure regressões
Compare versões.
Antes:
10 ms por transação
Depois:
18 ms
Alguma coisa mudou.
Passo 5 — veja SQL
Se usa Db2:
qual access path?
qual frequência?
quantas rows examinadas?
quantas retornadas?
Passo 6 — olhe scheduling
Seu job executa quando?
Ele compete com quem?
Existe motivo?
Passo 7 — pergunte sobre WLM
Qual service class?
Qual prioridade?
Qual objetivo?
Passo 8 — correlacione com negócio
Essa aplicação atende:
PIX?
cartões?
clientes?
folha?
fraude?
Passo 9 — documente
Porque seis meses depois alguém perguntará.
E talvez esse alguém seja você.
🕵️ 19. Um exemplo completo
O CFO diz:
— Conta de mainframe subiu 30%.
O time investiga.
Descobre:
crescimento normal do negócio +8%
novo antifraude +5%
nova observabilidade +3%
SQL regressivo +7%
batch concentrado em pico +4%
processo duplicado +2%
outros +1%
----
30%
Agora a conversa mudou.
Dos 30%:
16% = crescimento + capacidade nova
13% = problemas investigáveis/otimizáveis
1% = ainda desconhecido
Isso é infinitamente melhor do que:
— Mainframe ficou caro.
Agora temos ações.
SQL regressivo?
Corrigir.
Batch?
Reagendar se fizer sentido no modelo econômico.
Processo duplicado?
Eliminar.
Antifraude?
Manter.
Porque aquilo protege o banco.
🧩 20. Easter egg para quem chegou até aqui
Existe uma velha tendência em computação de tentar transformar tudo numa métrica simples.
MIPS.
CPU.
TPS.
latência.
custo.
Mas sistemas complexos odeiam métricas isoladas.
É quase um princípio de Douglas Adams aplicado ao datacenter:
A resposta pode ser 42. O problema é descobrir qual era a pergunta.
Se alguém chegar na reunião dizendo:
— O sistema usa 12.000 MIPS.
A pergunta correta é:
— E daí?
12.000 MIPS pode ser excelente.
Pode ser horrível.
Pode ser barato.
Pode ser caro.
Pode estar processando milhões de transações com eficiência fantástica.
Ou pode estar queimando CPU lendo o mesmo arquivo quinze vezes.
A métrica sem contexto é apenas um número muito bem vestido.
🥋 21. A última lição do dojo
O jovem programador começa querendo aprender:
MOVE
PERFORM
IF
EVALUATE
READ
WRITE
CALL
Depois aprende:
JCL
VSAM
Db2
CICS
Depois entende:
SMF
RMF
WLM
R4HA
zIIP
pricing
capacity
E então acontece uma mudança interessante.
Ele deixa de pensar:
“Meu programa funciona?”
E começa a perguntar:
“Meu programa funciona bem dentro do sistema?”
Depois:
“Meu sistema usa recursos de maneira eficiente?”
E finalmente:
“O custo computacional produzido por esse workload faz sentido para o negócio?”
Nesse ponto você deixou de ser apenas programador COBOL.
Começou a pensar como engenheiro de plataforma.
☕ Epílogo — O CFO, o COBOL e a conta de luz
Voltemos à primeira cena.
Sala de reunião.
CFO na ponta da mesa.
Gráfico na tela.
Ele pergunta:
— Por que o custo do mainframe subiu 30% se o negócio cresceu 8%?
Silêncio.
Antigamente alguém responderia:
— Houve aumento de capacidade.
Hoje uma equipe madura deveria responder:
— Dos 30 pontos, oito correspondem ao crescimento do negócio. Cinco vieram do antifraude novo. Três da observabilidade. Sete são uma regressão Db2 já identificada. Quatro vieram de concentração de workloads numa janela economicamente desfavorável. Dois correspondem a processos redundantes em eliminação. Um ainda estamos investigando.
Agora o CFO entende.
E o mais importante:
confia.
Porque ninguém está defendendo mainframe com religião.
Está defendendo com dados.
Essa é talvez a grande diferença entre o velho discurso:
“Mainframe é caro, mas confiável.”
e o discurso moderno:
“Eu sei exatamente quanto custa, quem consome, por que consome e o que recebemos em troca.”
No fundo, MIPS e MSU não são apenas unidades técnicas.
São pistas.
SMF é a cena do crime.
RMF é o perito.
WLM organiza o trânsito.
Db2 às vezes é o suspeito.
O batch jura inocência.
O COBOL diz que só cumpriu ordens.
O CFO quer saber quem vai pagar.
E em algum canto escuro do datacenter existe um job de 1997 executando toda terça-feira às 02h13 porque alguém escreveu no JCL:
//* NAO REMOVER
Ninguém sabe quem.
Ninguém sabe por quê.
Mas ele continua lá.
Consumindo CPU.
Silenciosamente.
À espera de um jovem gafanhoto suficientemente curioso para perguntar:
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
