 |
| Bellacosa Mainframe por que aprender cobol? |
☕ Um Café no Bellacosa Mainframe
Por que um Dev deveria aprender COBOL — explicado com a ajuda de Dick Tracy
🕵️♂️ Porque manter sistemas legados é menos “programar do zero” e muito mais investigar um crime ocorrido em 1987
Imagine Dick Tracy entrando numa sala.
Sobre a mesa:
um dump;
três copybooks;
um JCL que ninguém mexe desde 2004;
uma tabela Db2;
uma mensagem
S0C7;um comentário escrito por alguém chamado CARLOS 17/08/1993;
e um gerente dizendo:
“Isso sempre funcionou.”
Dick Tracy coloca o chapéu.
Olha para o terminal.
E diz:
“Temos um caso.”
É exatamente por isso que um desenvolvedor moderno deveria aprender COBOL.
🔎 COBOL ensina você a investigar software
O desenvolvedor iniciante costuma imaginar programação assim:
REQUISITO
↓
CÓDIGO
↓
TESTE
↓
DEPLOY
Bonito.
Organizado.
Quase ficção científica.
No mundo real de sistemas corporativos antigos, frequentemente temos:
PROBLEMA EM PRODUÇÃO
↓
NINGUÉM SABE POR QUÊ
↓
PROCURE O PROGRAMA
↓
DESCUBRA QUEM O CHAMA
↓
PROCURE O COPYBOOK
↓
DESCUBRA O ARQUIVO
↓
ACHE O JCL
↓
PROCURE O DB2
↓
LEIA UM COMENTÁRIO DE 1998
↓
“AHHHHHHH!”
Isso não é apenas programação.
Isso é investigação forense de software.
Dick Tracy aprovaria.
🕵️ Caso nº 1 — O misterioso S0C7
Produção caiu.
O programa:
ADD WS-VALOR TO WS-TOTAL
Simples.
Mas morreu com S0C7.
O programador Java olha:
“Mas é só um ADD!”
Dick Tracy acende a luminária sobre a mesa.
— Vamos verificar a vítima.
WS-VALOR deveria ser:
PIC 9(07)V99.
Mas alguém recebeu:
00012A45
Encontramos a arma do crime.
Dado inválido.
Mas ainda falta descobrir o assassino.
Quem escreveu aquilo?
Outro programa?
Um arquivo VSAM?
Db2?
MQ?
Uma conversão?
Um sistema distribuído?
Agora começou a investigação.
🧩 Caso nº 2 — O copybook que estava em todos os lugares
Em linguagens modernas você pode abrir uma classe e imaginar que está olhando para o objeto inteiro.
No COBOL:
COPY CLIENTE.
Dick Tracy olha para aquilo.
— Onde está CLIENTE?
Biblioteca A?
B?
C?
Produção usa qual versão?
O compilador usou qual?
Quem alterou?
Quando?
E de repente você percebe uma coisa importante.
Código não existe isoladamente.
Ele vive dentro de um ecossistema.
Essa é uma das grandes lições do mainframe.
🧠 COBOL ensina contexto
Um programa pode receber informação de:
JCL
↓
Arquivo
↓
COBOL
↓
DB2
↓
CICS
↓
MQ
↓
Outro COBOL
Encontrar o programa é apenas encontrar uma testemunha.
Você ainda precisa reconstruir o crime.
💰 Caso nº 3 — O programa aparentemente insignificante
Você encontra:
IF SALDO > LIMITE
MOVE 'S' TO BLOQUEIO
END-IF
Quatro linhas.
Um desenvolvedor desavisado pensa:
“Código velho.”
Dick Tracy pergunta:
“Quanto dinheiro passa por aqui?”
Silêncio.
Resposta:
alguns bilhões por mês.
Agora aquelas quatro linhas parecem um pouco diferentes.
Esse é um dos grandes motivos para estudar COBOL.
Ele ensina algo que cursos modernos frequentemente demoram para mostrar:
Quantidade de código não é igual a importância do código.
Uma rotina minúscula pode representar uma regra de negócio extremamente valiosa.
🏦 COBOL é arqueologia de negócio
Quando você abre um programa COBOL de banco, seguradora, governo ou grande empresa, muitas vezes não está apenas lendo código.
Está lendo decisões tomadas durante décadas.
IF IDADE > 65
...
Por quê?
Talvez exista legislação.
Talvez política comercial.
Talvez uma regra criada depois de algum incidente ocorrido há vinte anos.
Dick Tracy não apagaria imediatamente a linha.
Perguntaria:
“Por que isso está aqui?”
Esse é um excelente hábito para qualquer desenvolvedor.
🚨 E então chega o jovem desenvolvedor armado com IA
Agora ficou ainda mais interessante.
O sujeito copia 800 linhas de COBOL para uma IA e pergunta:
“Modernize isso.”
A IA responde alegremente:
Claro! 😊
Dick Tracy entra correndo pela porta:
NÃO TOQUE NA CENA DO CRIME!
Porque antes de transformar alguma coisa você precisa entender:
entradas;
saídas;
dependências;
regras;
arquivos;
tabelas;
transações;
comportamento histórico;
tratamento de erro;
contratos implícitos.
Pesquisas recentes continuam apontando justamente essa dificuldade: sistemas COBOL permanecem críticos, enquanto compreender grandes bases antigas e transferir conhecimento para novos desenvolvedores continua sendo um problema relevante. (arXiv)
Até modelos de IA especializados em COBOL estão sendo pesquisados justamente porque modelos genéricos ainda apresentam dificuldades consideráveis com geração e tradução correta de código COBOL. (arXiv)
📟 Dick Tracy ensinaria debugging melhor que muito bootcamp
O método seria praticamente:
1. O que aconteceu?
2. Onde aconteceu?
3. Quando aconteceu?
4. Quem chamou?
5. Quais dados chegaram?
6. O que deveria acontecer?
7. O que realmente aconteceu?
8. O que mudou?
9. Quem depende disso?
10. Consigo reproduzir?
Isso serve para:
COBOL.
Java.
Python.
C#.
Node.
Microservices.
Cloud.
IA.
Qualquer coisa.
🧬 Aprender COBOL melhora você em outras linguagens
Essa é talvez a parte menos compreendida.
Você não precisa aprender COBOL necessariamente para passar os próximos quarenta anos escrevendo:
PERFORM CALCULA-JUROS.
Você pode estudá-lo porque COBOL obriga você a pensar em:
dados.
tipos.
layout.
registros.
estado.
transações.
I/O.
processamento batch.
integração.
regras empresariais.
Depois disso algumas abstrações modernas ficam muito menos mágicas.
Você começa a perguntar:
Onde o dado realmente está?
Quem persiste isso?
Quem inicia essa execução?
Qual o contrato?
O que acontece se falhar no meio?
Dick Tracy sorri.
Agora temos um investigador.
🦖 O dinossauro não está morto
Existe uma piada recorrente:
“COBOL vai morrer.”
Dick Tracy abre o arquivo do caso.
Primeiro registro:
1960.
Depois:
Ele fecha a pasta lentamente.
“Curioso cadáver.”
A razão é simples.
Sistemas não sobrevivem décadas apenas porque alguém esqueceu de desligá-los.
Muitos sobrevivem porque fazem alguma coisa importante.
🏛️ O verdadeiro legado não é COBOL
Aqui está o ponto Bellacosa.
COBOL não é interessante simplesmente porque é velho.
É interessante porque coloca o desenvolvedor diante de uma pergunta extremamente adulta:
Como você muda algo que já funciona, é crítico, possui décadas de conhecimento acumulado e não pode parar?
Essa pergunta vale muito mais que decorar sintaxe.
🕵️ Dick Tracy contra o desenvolvedor cowboy
O cowboy olha:
PERFORM 9000-ROTINA.
E diz:
“Vou refatorar.”
Dick Tracy pergunta:
“Quem chama?”
Cowboy:
“Não sei.”
Tracy:
“Quem depende?”
Cowboy:
“Não sei.”
Tracy:
“Existe teste?”
Cowboy:
“Não.”
Tracy:
“Produção?”
Cowboy:
“Banco.”
Dick Tracy recolhe o teclado.
A investigação terminou.
☕ Conclusão — aprenda COBOL para aprender a fazer perguntas
Talvez o maior motivo para um desenvolvedor aprender COBOL não seja COBOL.
É desenvolver uma mentalidade.
Diante de um programa antigo, Dick Tracy não perguntaria:
“Como posso reescrever isto?”
Primeiro perguntaria:
“Por que isto existe?”
Depois:
“Quem depende disso?”
Depois:
“O que acontece se eu estiver errado?”
E somente então colocaria a mão no teclado.
Essa é uma habilidade extraordinariamente valiosa.
Porque frameworks desaparecem.
Bibliotecas mudam.
Clouds mudam.
Linguagens entram e saem de moda.
Mas sistemas complexos continuarão deixando pistas.
E alguém terá que investigá-las.
Então vista o sobretudo.
Abra o dump.
Entre no ISPF.
Temos um ABEND esperando.
🕵️♂️💻🦖
Dick Tracy acaba de entrar no mainframe.
https://eljefemidnightlunch.blogspot.com/2026/07/os-tres-bugs-invisiveis-do-padawan.html
https://eljefemidnightlunch.blogspot.com/2026/07/20-anos-depois-da-bolha-da-internet-o.html
Aprenda COBOL
