Bellacosa Mainframe analisando problemas no mainframe

☕ Um Café no Bellacosa Mainframe

💻 AKIRA SHIRASE E O PROGRAMA COBOL QUE NINGUÉM TINHA CORAGEM DE ALTERAR

COBOL, legibilidade, manutenção, performance, SMF, RMF, CICS, Db2, MQ, debugging, DevOps, IA, código legado — e o dia em que um Battle Programmer descobriu que fazer o programa funcionar era apenas o começo.

Sob a tutela de Akira Shirase, de Battle Programmer Shirase (BPS) — porque quando produção está parada às 03:17, não precisamos de alguém dizendo que “provavelmente é o COBOL”. Precisamos de alguém que encontre evidências.

---

🎬 PRÓLOGO — HÁ UM PROBLEMA NO MAINFRAME!

03:17.

O telefone toca.

Não é exatamente o horário em que um programador COBOL espera receber boas notícias.

— Produção está lenta.

Akira Shirase abre um olho.

Do outro lado da ligação alguém continua:

— A aplicação está demorando cinco segundos para responder. Achamos que é o COBOL.

Akira finalmente abre o segundo olho.

Essa última frase conseguiu acordá-lo.

— Acham?

Silêncio.

— Bem... o sistema é Mainframe.

Akira levanta da cadeira.

Se estivesse dentro de Battle Programmer Shirase, provavelmente cinco minutos depois estaria digitando em velocidades incompatíveis com a anatomia humana enquanto alguém explicava que a segurança nacional dependia daquele sistema.

Mas estamos no Bellacosa Mainframe.

Aqui nosso superpoder será outro:

método.

Antes de alterar uma única linha, Akira faz uma pergunta:

“Onde estão as evidências?”

Bem-vindo, jovem programador COBOL.

Hoje vamos descobrir que programar não significa simplesmente fazer o computador obedecer.

Vamos colocar na mesma War Room algumas ideias associadas a Martin Fowler, Kent Beck, Donald Knuth, Linus Torvalds e Grace Hopper e transportá-las para um ambiente com COBOL, JCL, CICS, Db2, VSAM, MQ, SMF, RMF, APIs e décadas de história.

E Akira Shirase será nosso guia.

Prepare o café.

Temos um incidente.

---

🧠 CAPÍTULO 1 — O COMPUTADOR NÃO É O LEITOR MAIS IMPORTANTE DO SEU COBOL

Comecemos com uma das ideias mais importantes da engenharia de software:

Um programa precisa ser compreendido por pessoas, não apenas executado por computadores.

O iniciante costuma pensar que o objetivo da programação é escrever algo que compile.

Depois descobre que precisa funcionar.

Mais tarde percebe algo muito mais assustador:

alguém precisará manter aquilo.

Imagine:

IF A = 'S'
    PERFORM 9000-X
END-IF.

Perfeitamente possível.

O computador não reclama.

O compilador não entra em crise existencial.

Akira, entretanto, olha para a tela:

— O que é A?

Você responde:

— Uma variável.

— Eu sei.

— E S?

— Um valor.

Akira respira fundo.

Agora veja:

IF WS-CLIENTE-BLOQUEADO = 'S'
    PERFORM 9000-REJEITAR-TRANSACAO
END-IF.

A lógica pode ser idêntica.

Mas existe uma diferença gigantesca.

No segundo exemplo, o programa começa a contar sua própria história.

COBOL nasceu com essa preocupação

Uma das características fascinantes do COBOL é justamente sua tentativa de ser relativamente próximo da linguagem humana.

Compare:

ADD WS-VALOR TO WS-TOTAL.

ou:

IF WS-SALDO < WS-VALOR-SAQUE
    MOVE 'S' TO WS-SALDO-INSUFICIENTE
END-IF.

Mesmo alguém começando COBOL consegue formar uma hipótese sobre o que está acontecendo.

Isso não é acidente.

COBOL nasceu em um contexto em que sistemas comerciais precisavam permanecer compreensíveis e mantíveis.

Décadas depois, essa característica tornou-se uma das razões pelas quais enormes sistemas continuaram evoluindo.

---

🏺 CAPÍTULO 2 — SEU PROGRAMA COBOL É UM SÍTIO ARQUEOLÓGICO

Imagine um programa criado em 1993.

Ele sofreu alterações em:

1993 ─ programa original
1997 ─ nova regra fiscal
2001 ─ mudança monetária
2006 ─ integração
2011 ─ nova tabela Db2
2016 ─ alteração regulatória
2020 ─ API
2024 ─ antifraude
2026 ─ você

Você abre o programa.

Encontra:

IF WS-TIPO = '7'
   AND WS-ORIGEM NOT = 'X'
   AND WS-DATA < WS-DATA-LIMITE
    MOVE 'N' TO WS-PROCESSAR
END-IF.

Sua primeira reação pode ser:

“Que IF horroroso!”

Akira segura sua mão antes de você apagar.

— Você sabe por que ele existe?

Não.

— Então não sabe ainda se ele é lixo.

Essa é uma das grandes lições da manutenção de legado.

Código estranho pode ser um fóssil de incidente.

Talvez em 2009 uma determinada combinação tenha provocado duplicidade de pagamento.

Talvez tenha existido um APAR.

Talvez determinada instituição tenha enviado um formato incorreto.

Talvez aquele IF tenha sido a solução emergencial de um incidente milionário.

Isso não significa que código antigo seja sagrado.

Significa que:

antes de remover comportamento, precisamos compreender sua origem e provar as consequências.

Procure histórico no SCM/Git, documentação, tickets, incidentes, requisitos, comentários e testes.

Depois investigue dados reais.

Só então altere.

---

📝 CAPÍTULO 3 — COMENTÁRIO NÃO É TRADUÇÃO DE COBOL PARA PORTUGUÊS

Isto é um comentário inútil:

ADD 1 TO WS-CONTADOR
*> ADICIONA UM AO CONTADOR

Obrigado, Sherlock.

Agora:

*> ALTERAÇÃO PARA IMPEDIR REPROCESSAMENTO
*> DA MENSAGEM APÓS TIMEOUT NO MQ.
*> O CONSUMIDOR PODE RECEBER NOVAMENTE
*> A MESMA CHAVE DE NEGÓCIO.

Isso possui valor.

O código explica o que.

O comentário deve ajudar a explicar por quê.

Em sistemas mantidos durante décadas, registrar contexto de alteração pode ser extremamente valioso.

É quase uma pequena cápsula do tempo.

O programador de 2036 talvez nunca conheça você.

Mas poderá descobrir por que determinada decisão foi tomada.

---

🧪 CAPÍTULO 4 — KENT BECK ENTRA NA WAR ROOM

Agora chegamos ao princípio resumido no carrossel como:

faça funcionar, faça certo, faça rápido.

Para o iniciante, parece apenas uma frase elegante.

No Mainframe ela pode virar metodologia.

Imagine uma rotina bancária.

Primeira preocupação:

Ela funciona?

Entrada:

Conta origem
Conta destino
Valor
Data

Processamento:

validar contas
validar saldo
debitar origem
creditar destino
registrar operação

Saída:

sucesso ou erro

Excelente.

Mas funcionar uma vez não significa estar correta.

Agora entram perguntas mais difíceis.

E se o Db2 falhar depois do débito?

E se ocorrer ABEND?

E se duas transações tentarem alterar o mesmo saldo?

E se o MQ reenviar uma mensagem?

E se houver timeout?

E se o usuário clicar duas vezes?

Bem-vindo à engenharia de software corporativa.

---

💥 CAPÍTULO 5 — “FUNCIONOU” NÃO SIGNIFICA “ESTÁ CERTO”

Considere:

Conta A = R$ 1.000
Conta B = R$ 500

Transferência = R$ 100

Esperamos:

A = R$ 900
B = R$ 600

Mas imagine:

UPDATE CONTA_A
       ↓
débito realizado
       ↓
💥 ABEND
       ↓
UPDATE CONTA_B nunca executado

Parabéns.

Criamos dinheiro desaparecendo no ciberespaço.

É por isso que sistemas transacionais trabalham com conceitos como Unit of Work, COMMIT e ROLLBACK.

Conceitualmente:

BEGIN UOW
   │
   ├── validar
   ├── debitar
   ├── creditar
   └── registrar
   │
 COMMIT

Se algo falhar antes do ponto correto:

ROLLBACK

Então “faça certo” inclui muito mais do que produzir o resultado esperado no happy path.

Inclui:

• consistência;

• recuperação;

• concorrência;

• integridade;

• tratamento de erros;

• segurança;

• restart;

• idempotência.

Akira sorri.

Agora você começou a parecer perigoso.

No bom sentido.

---

⚡ CAPÍTULO 6 — AGORA PODEMOS FALAR DE VELOCIDADE

O gerente aparece:

— Precisamos otimizar o COBOL!

Akira pergunta:

— Por quê?

— Está lento.

— O quê está lento?

— O sistema.

— Qual sistema?

Começa o silêncio corporativo.

Esse diálogo é mais importante do que parece.

Porque:

“Sistema lento” não é diagnóstico.

É sintoma.

---

⚙️ CAPÍTULO 7 — DONALD KNUTH E A ARMADILHA DA OTIMIZAÇÃO PREMATURA

A ideia clássica associada a Knuth sobre otimização prematura é frequentemente mal interpretada como:

performance não importa.

Nada poderia ser mais errado no Mainframe.

Performance importa enormemente.

Imagine uma instrução desnecessária executada uma vez.

Irrelevante.

Agora imagine algo desnecessário dentro de uma rotina executada:

500.000.000 vezes por dia.

Mudou de figura.

No Mainframe, eficiência pode afetar:

• CPU;

• capacidade;

• janela batch;

• custo;

• throughput;

• SLA;

• experiência do cliente.

A questão não é não otimizar.

É:

não otimize por superstição.

---

🔬 CAPÍTULO 8 — AKIRA NÃO CHUTA: ELE MEDE

Nosso incidente apresenta:

Response time = 5,1 segundos

O desenvolvedor olha um PERFORM enorme e declara:

— Achei!

Akira:

— Como sabe?

— Parece lento.

Temos agora o equivalente técnico de diagnosticar um motor olhando a pintura do carro.

Precisamos medir.

No ecossistema Mainframe podemos encontrar evidências em diferentes fontes, dependendo do componente e da configuração:

• SMF;

• RMF;

• estatísticas CICS;

• Db2 accounting/traces;

• MQ statistics;

• logs;

• traces;

• monitores de performance;

• métricas da aplicação.

Imagine que a investigação produza:

Response time total      5,10 s

CPU                      0,08 s
Db2                      0,12 s
MQ                       0,03 s
API externa              4,71 s
Outros                   0,16 s

Surpresa.

O COBOL não é necessariamente o vilão.

Você poderia passar a madrugada inteira micro-otimizando o programa e talvez economizar alguns milissegundos.

O cliente continuaria esperando aproximadamente cinco segundos.

Regra Bellacosa:

Nunca confunda o lugar onde você encontrou o sintoma com o lugar onde nasceu a causa.

---

📊 CAPÍTULO 9 — CPU TIME NÃO É ELAPSED TIME

Essa diferença merece tatuagem temporária no braço de todo programador iniciante.

CPU time é o tempo de processamento efetivamente consumido pelo processador.

Elapsed time é quanto tempo passou do ponto de vista do relógio.

Um programa pode apresentar:

CPU     = 0,2 segundo
Elapsed = 12 segundos

Onde foram parar os outros 11,8?

Possivelmente esperando alguma coisa:

I/O
LOCK
Db2
MQ
rede
arquivo
serviço externo
fila
recurso

Portanto, quando alguém diz:

“O programa demora 12 segundos.”

A próxima pergunta deveria ser:

“Fazendo o quê?”

Essa pergunta separa troubleshooting de adivinhação.

---

🐧 CAPÍTULO 10 — LINUS TORVALDS: MOSTRE A EXECUÇÃO

Existe ainda outro problema clássico.

O documento de arquitetura diz:

CICS
 ↓
COBOL
 ↓
Db2

Todo mundo acredita nisso.

Até Akira começar a seguir a transação.

Na realidade:

Cliente
   ↓
API Gateway
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
Db2
   ↓
MQ
   ↓
serviço antifraude
   ↓
cloud

A arquitetura documentada e a arquitetura executada não são necessariamente iguais.

Isso acontece especialmente em sistemas que evoluíram durante muitos anos.

Alguém adicionou uma integração.

Depois outra.

Depois uma chamada.

Depois uma exceção.

O PowerPoint continuou bonito.

A produção continuou evoluindo.

Por isso existe uma máxima extremamente útil:

documentação informa; execução comprova.

Não abandone a documentação.

Use-a como mapa.

Mas quando mapa e território discordarem, investigue o território.

---

🧑‍✈️ CAPÍTULO 11 — GRACE HOPPER E O PERIGO DE ENTENDER UMA FRASE PELA METADE

A ideia de ser mais fácil pedir desculpas do que permissão representa muito bem uma cultura de iniciativa.

Mas cuidado ao transportar isso literalmente para produção.

Não significa:

17:59 sexta-feira

ALTERAR PROGRAMA
      ↓
SEM TESTE
      ↓
SEM CHANGE
      ↓
SEM BACKOUT
      ↓
“Grace Hopper mandou.”

Não.

Grace não será aceita como justificativa no relatório de incidente.

😂

A interpretação útil para engenharia moderna é:

crie espaços seguros onde experimentar seja fácil.

DEV.

Sandbox.

Ambientes de teste.

Automação.

Feature flags quando aplicáveis.

Dados apropriados de teste.

Pipeline.

Rollback.

Testes automatizados.

A inovação não precisa destruir governança.

A boa automação permite experimentar sem transformar produção em laboratório.

---

🏭 CAPÍTULO 12 — O PIPELINE DOS CINCO MESTRES

Agora conseguimos juntar as ideias do carrossel.

Akira desenha no quadro:

        PROBLEMA
           │
           ▼
    FAÇA FUNCIONAR
       Kent Beck
           │
           ▼
    FAÇA COMPREENSÍVEL
      Martin Fowler
           │
           ▼
    TESTE E DEMONSTRE
     “Show me code”
           │
           ▼
         MEÇA
      Donald Knuth
           │
           ▼
       OTIMIZE
           │
           ▼
 EXPERIMENTE COM SEGURANÇA
      Grace Hopper
           │
           ▼
       PRODUÇÃO
           │
           ▼
     OBSERVABILIDADE

Observe a última etapa.

Produção não termina o ciclo.

Ela produz novas evidências.

Portanto:

DEV → TEST → PROD → OBSERVE
 ↑                    │
 └────── APRENDA ─────┘

Isso é engenharia contínua.

---

🏦 CAPÍTULO 13 — O CASO DA TRANSAÇÃO TRN1

Vamos fazer o exercício completo.

Temos:

TRN1
 ↓
PROG001
 ↓
Db2
 ↓
MQ

Usuários relatam lentidão.

Passo 1 — reproduzir

Não altere nada ainda.

Determine:

• qual transação;

• qual horário;

• quais usuários;

• frequência;

• entrada;

• resposta esperada;

• resposta obtida.

Passo 2 — delimitar

A lentidão acontece sempre?

Somente no pico?

Somente para certos clientes?

Somente após determinado deploy?

Passo 3 — medir

Procure:

CPU
elapsed
I/O
locks
SQL
fila MQ
rede
serviços chamados

Passo 4 — seguir a transação

Construa o caminho real:

Request
 ↓
CICS
 ↓
PROG001
 ↓
Db2
 ↓
MQ
 ↓
serviço externo
 ↓
Response

Passo 5 — localizar espera

Encontramos:

API externa = 4,71 s

Agora existe uma hipótese fundamentada.

Passo 6 — testar

Execute novamente isolando componentes quando possível.

Passo 7 — corrigir

Talvez o problema esteja em:

• timeout;

• conexão;

• serviço remoto;

• serialização;

• rede;

• fila;

• processamento remoto.

Passo 8 — validar

Depois da alteração:

antes = 5,10 s
depois = 0,62 s

Excelente.

Mas ainda falta uma coisa.

Passo 9 — garantir que não quebramos nada

Performance melhorou.

Mas:

• resultado continua correto?

• transação continua íntegra?

• erros são tratados?

• segurança permanece?

• throughput melhorou?

• apareceu novo gargalo?

Agora podemos comemorar.

---

🤖 CAPÍTULO 14 — AKIRA ENCONTRA UMA IA ESCREVENDO COBOL

Em 2026 surge uma variável nova.

IA generativa.

Você pede:

“Crie um programa COBOL que leia CUSTOMER e atualize ACCOUNT.”

Poucos segundos depois existe código.

Impressionante.

Mas Akira pergunta:

— Você entendeu o código?

— Mais ou menos.

— Testou?

— Ainda não.

— Conhece as regras de negócio?

— Não todas.

Akira fecha o notebook.

Fim da aula.

IA reduz dramaticamente o custo de produzir texto que parece código.

Ela não elimina a responsabilidade de provar que aquele código está correto.

O fluxo saudável é:

PROMPT
  ↓
GERAÇÃO
  ↓
REVISÃO HUMANA
  ↓
COMPREENSÃO
  ↓
BUILD
  ↓
TESTES
  ↓
ANÁLISE
  ↓
SEGURANÇA
  ↓
PERFORMANCE
  ↓
EVIDÊNCIAS
  ↓
DEPLOY
  ↓
OBSERVABILIDADE

Nunca:

PROMPT → CTRL+C → CTRL+V → PROD

A IA pode escrever uma rotina elegante que viola uma regra de negócio estabelecida em 1998.

Pode inventar comportamento.

Pode usar uma técnica incompatível com seu ambiente.

Pode criar SQL funcional, porém terrível sob volume real.

Pode não conhecer aquela exceção misteriosa:

IF WS-ORIGEM = 'X'

que existe porque vinte anos atrás aconteceu algo que ninguém quer repetir.

É aí que o profissional experiente continua indispensável.

---

🏰 CAPÍTULO 15 — O MAINFRAME É UMA CATEDRAL

Há uma imagem que combina perfeitamente com tudo isso.

Pense num grande sistema Mainframe como uma catedral construída durante décadas.

Um profissional construiu a fundação.

Outro levantou uma parede.

Outro colocou vitrais.

Outro reforçou uma coluna depois de um terremoto.

Décadas depois você chega.

Olha para uma coluna estranha e pensa:

“Isso está atrapalhando a arquitetura. Vou remover.”

Akira aparece:

— Descubra primeiro se o teto está apoiado nela.

Essa é a essência da manutenção responsável.

Modernizar não significa preservar tudo.

Muito pelo contrário.

Podemos:

• refatorar;

• substituir;

• modularizar;

• encapsular;

• criar APIs;

• automatizar;

• eliminar código morto;

• melhorar testes;

• modernizar interfaces.

Mas devemos conhecer as dependências antes.

---

🥚 EASTER EGG — 03:17

Nosso jovem programador finalmente corrige o incidente.

03:16.

Deploy concluído.

Métricas normais.

Ele olha para Akira:

— Terminamos?

O relógio muda.

03:17.

Akira responde:

— Ainda não.

— O que falta?

— Backout.

O jovem olha assustado.

— Mas funcionou!

Akira sorri:

“Todo mundo acredita no deploy enquanto ele está funcionando. Engenharia começa quando você sabe como voltar.”

Em algum lugar distante, um job termina:

IEF142I STEP01 - STEP WAS EXECUTED - COND CODE 0000

O café finalmente pode ser tomado.

---

🎓 CAPÍTULO 16 — O CHECKLIST DO BATTLE PROGRAMMER COBOL

Quando receber um programa desconhecido, não comece alterando.

Faça uma investigação estruturada:

1. descubra a função de negócio;

2. identifique entradas e saídas;

3. encontre arquivos, tabelas e filas;

4. identifique CALLs e programas relacionados;

5. procure EXEC SQL e EXEC CICS;

6. entenda COMMIT e ROLLBACK;

7. encontre tratamentos de erro;

8. examine histórico de alterações;

9. procure dependências externas;

10. execute testes;

11. meça comportamento;

12. somente depois modifique.

E antes de promover:

☑ Compila?
☑ Funciona?
☑ Está correto?
☑ É compreensível?
☑ Trata erros?
☑ Recupera?
☑ É seguro?
☑ Performance está adequada?
☑ Temos evidências?
☑ Temos testes?
☑ Temos rollback/backout?
☑ Conseguimos observar em produção?

Se a única evidência disponível for:

“Na minha máquina funcionou.”

Akira provavelmente ainda não autorizaria você a ir tomar café.

---

☕ EPÍLOGO — O VERDADEIRO BATTLE PROGRAMMER

Battle Programmer Shirase brinca com a fantasia do programador extraordinário capaz de resolver problemas impossíveis diante de um teclado.

No mundo real, porém, existe uma versão muito mais interessante desse personagem.

Não é necessariamente quem digita mais rápido.

Não é quem decora mais comandos.

Não é quem escreve o COBOL mais compacto.

É aquele que diante de um incidente consegue manter uma sequência lógica:

O QUE DEVERIA ACONTECER?
          ↓
O QUE ACONTECEU?
          ↓
ONDE ESTÁ A EVIDÊNCIA?
          ↓
CONSIGO REPRODUZIR?
          ↓
QUAL COMPONENTE FALHOU?
          ↓
QUAL É A CAUSA?
          ↓
QUAL É A MENOR CORREÇÃO SEGURA?
          ↓
COMO TESTO?
          ↓
COMO PROVO?
          ↓
COMO VOLTO SE DER ERRADO?

Esse profissional compreendeu Fowler: código também é comunicação.

Compreendeu Beck: funcionar, corrigir e otimizar são problemas diferentes.

Compreendeu Knuth: performance exige medição, não superstição.

Compreendeu a provocação associada a Torvalds: afirmações técnicas precisam encontrar a realidade do código e da execução.

Compreendeu Hopper: experimentação é poderosa quando criamos condições para aprender sem transformar produção numa roleta.

E finalmente compreendeu algo que nenhum slogan sozinho consegue ensinar:

Mainframe não é apenas COBOL.

É COBOL conversando com CICS.

CICS conversando com Db2.

COBOL lendo VSAM.

Aplicações publicando MQ.

APIs chegando pelo z/OS Connect.

JCL movimentando processamento batch.

RACF controlando identidades e acessos.

WLM administrando prioridades.

SMF registrando acontecimentos.

RMF mostrando comportamento da infraestrutura.

Sistemas distribuídos entrando e saindo dessa arquitetura.

E pessoas tentando compreender tudo isso anos depois de seus autores originais terem ido embora.

Por isso existe uma enorme diferença entre escrever código e praticar engenharia.

O iniciante pergunta:

“Como faço esse programa funcionar?”

O desenvolvedor começa a perguntar:

“Como faço corretamente?”

O profissional experiente pergunta:

“Como sei que está correto?”

E o Battle Programmer Mainframe olha para as evidências, toma mais um gole de café e acrescenta:

“Se der errado às 03:17, como eu volto?”

Essa pergunta aparentemente simples contém décadas de experiência.

Porque talvez o maior ensinamento de todos seja este:

💻 Não tenha medo do código legado.

Tenha medo de alterar aquilo que você ainda não compreendeu.

Investigue.

Leia.

Meça.

Teste.

Documente.

Questione.

Refatore quando houver evidência.

Otimize quando souber onde está o gargalo.

Automatize quando entender o processo.

Use IA, mas continue pensando.

E nunca confunda:

COMPILOU

com:

FUNCIONOU

nem:

FUNCIONOU

com:

ESTÁ CORRETO

muito menos:

ESTÁ CORRETO

com:

ESTÁ PRONTO PARA PRODUÇÃO

Porque entre essas quatro mensagens existe praticamente toda a carreira de um engenheiro Mainframe.

☕🖥️ Bem-vindo à batalha, Padawan.