 |
| Bellacosa Mainframe e a logica de validação |
☕ Um Café no Bellacosa Mainframe
Lógica de Validação sem Mistérios para Programadores COBOL
Quando um Programador COBOL Descobre que o Campo Obrigatório Não Foi Criado para Irritar Usuários... Mas para Evitar que um Banco Inteiro Exploda às 23h59
"Meu nome é COBOL. Enterprise COBOL."
Imagine a cena clássica de um filme de James Bond.
Em algum lugar de Londres, M entrega uma missão.
— Bond, encontramos um programa escrito em RPG III em 1989. Um desenvolvedor júnior pretende remover algumas validações porque "atrapalham a experiência do usuário". Se ele conseguir... centenas de sistemas financeiros poderão produzir dados incorretos durante meses sem que ninguém perceba.
Bond responde calmamente.
— Então o problema não é o código.
— Exatamente. O problema é que ninguém sabe por que aquele código existe.
...
Bem-vindo ao mundo dos sistemas corporativos.
E curiosamente...
Essa história acontece praticamente todos os dias: validações aparentemente simples escondem regras de negócio extremamente sofisticadas.
Para um programador COBOL iniciante, isso representa uma das maiores mudanças de mentalidade da carreira.
O grande erro dos iniciantes
Todo iniciante pensa parecido.
Ele abre um programa COBOL.
Encontra:
IF CLIENTE = SPACES
DISPLAY "CLIENTE OBRIGATORIO"
GO TO TELA
END-IF
Primeira reação:
"Isso é simples."
Segunda reação:
"Posso melhorar."
Terceira reação:
"Nem precisa existir."
...
E é exatamente aí que começam os problemas.
Porque talvez esse IF esteja protegendo:
faturamento
integração
impostos
compliance
auditoria
relatórios
processamento batch
fechamento mensal
Ou seja...
o verdadeiro trabalho nunca foi impedir campo vazio.
O verdadeiro trabalho era proteger todo o restante do sistema.
O efeito James Bond
Nos filmes do 007 existe um detalhe interessante.
Quase nunca o vilão destrói Londres usando uma bomba gigante.
Ele altera uma pequena peça.
Troca um satélite.
Muda um código.
Rouba uma chave.
Troca uma senha.
Depois observa o caos acontecer sozinho.
Nos sistemas corporativos acontece exatamente igual.
Você altera uma validação aparentemente insignificante.
Nada acontece.
Durante dias.
Durante semanas.
Depois...
o fechamento financeiro falha.
O usuário vê uma mensagem.
O sistema vê um contrato.
O artigo explica algo extremamente importante.
Para o usuário existe apenas isto:
Campo obrigatório.
Fim.
Mas internamente aquela mensagem significa:
"Não permita que este registro siga adiante porque cinquenta processos dependem dele."
Essa diferença de perspectiva muda completamente a forma como analisamos software legado.
O iceberg das validações
A tela é apenas a ponta.
Debaixo dela existem dezenas de dependências.
Imagine:
Tela
↓
Programa COBOL
↓
VSAM
↓
DB2
↓
MQ
↓
Interface REST
↓
Batch Noturno
↓
Relatórios
↓
BI
↓
Auditoria
↓
Banco Central
O usuário enxerga:
Campo obrigatório.
O arquiteto enxerga:
Uma cadeia inteira de dependências.
Por que sistemas antigos fazem tantas validações?
Porque durante décadas não existiam:
APIs
Microservices
Gateway
Event Broker
Kafka
Camadas REST
Tudo acontecia dentro do programa.
Logo...
a validação morava exatamente onde os dados entravam.
Na tela.
Esse padrão tornou-se extremamente comum em RPG, COBOL, Natural e PL/I.
O verdadeiro inimigo chama-se "dados ruins"
Programadores novos costumam pensar:
"Erro de compilação é ruim."
Não.
Muito pior é dado errado.
Porque código errado normalmente explode imediatamente.
Dado errado...
pode sobreviver anos.
Imagine:
Cliente cadastrado sem CPF.
Hoje nada acontece.
Amanhã:
batch ignora.
Depois:
faturamento não encontra cliente.
Depois:
impostos errados.
Depois:
auditoria encontra inconsistência.
Depois:
advogados entram.
Tudo começou porque alguém retirou um IF.
O paradoxo da modernização
Outro ponto excelente discutido no artigo.
Modernizar NÃO significa preservar tudo.
Nem apagar tudo.
Modernizar significa entender primeiro.
Depois decidir.
A sequência correta é:
Descobrir a regra.
Entender a regra.
Descobrir quem usa.
Descobrir quem depende.
Só então alterar.
Jamais o contrário.
Um dos maiores perigos: o efeito dominó
Imagine uma peça de dominó.
Você derruba apenas uma.
As outras caem sozinhas.
Validações funcionam exatamente assim.
Uma alteração pequena pode atingir:
relatórios
integração SAP
emissão fiscal
XML
APIs
Data Warehouse
Analytics
Nenhuma dessas equipes estava olhando aquela tela.
Mas todas dependiam dela.
James Bond e o Mainframe
Se James Bond trabalhasse num banco...
Q provavelmente lhe entregaria um gadget chamado:
Validator Scanner 9000
Funções:
✓ localizar IF esquecidos
✓ encontrar PERFORM misteriosos
✓ rastrear GO TO perigosos
✓ identificar programas batch impactados
Infelizmente...
na vida real esse gadget chama-se:
Conhecimento.
A IA entra em cena
O artigo mostra um uso extremamente inteligente da IA.
Não para substituir o desenvolvedor.
Mas para acelerar investigação.
Por exemplo.
A IA pode responder rapidamente:
Qual campo é validado?
Qual mensagem aparece?
Qual arquivo recebe update?
Qual status muda?
Quais programas são chamados?
Quais SQL executam?
Quais interfaces dependem?
Ela reduz dias de investigação para minutos em muitos casos.
Mas cuidado...
A IA enxerga código.
Ela não enxerga história.
Ela pode dizer:
"Campo obrigatório."
Mas não sabe que:
Em 1997 um cliente perdeu milhões porque esse campo ficou vazio.
Quem sabe isso?
O analista veterano.
O método Bellacosa de investigação
Sempre ensine seu cérebro a pensar nesta sequência:
Etapa 1
Onde está a validação?
Etapa 2
Quem chama?
Etapa 3
Quem grava?
Etapa 4
Quem lê?
Etapa 5
Quem depende?
Etapa 6
O que quebra?
Etapa 7
Ainda faz sentido?
Só depois:
Modificar.
A importância da documentação
Outro excelente ponto.
Quando finalmente descobrimos o motivo daquela validação...
não podemos guardar isso apenas na cabeça.
Transforme em:
Wiki
Confluence
Markdown
Obsidian
Teste
Caso de Uso
Conhecimento que permanece apenas em pessoas desaparece quando elas mudam de projeto ou se aposentam.
O prompt apresentado
O artigo também fornece um excelente modelo para IA.
Ele pede análise sobre:
campo
condição
mensagem
regra
arquivos
programas
SQL
interfaces
batch
riscos
QA
suporte
testes
Na prática é quase um checklist de engenharia reversa moderna.
Os cinco agentes secretos da modernização
Desenvolvedor
Descobre como funciona.
Analista
Descobre por quê.
QA
Prova que continua funcionando.
Suporte
Conta todas as tragédias já ocorridas.
Arquiteto
Decide onde essa regra deverá viver daqui para frente.
Cada um possui uma parte da missão.
Curiosidade histórica
Nos anos 1970 e 1980 era comum concentrar praticamente toda a inteligência do negócio dentro do programa COBOL ou RPG.
Não porque fosse "bonito".
Mas porque era o local natural onde os dados entravam.
Décadas depois, APIs, microsserviços e arquiteturas em camadas redistribuíram muitas dessas responsabilidades, mas inúmeras regras continuam preservadas no legado por razões históricas e operacionais.
Easter Egg 007
Existe um paralelo curioso.
Nos filmes do James Bond, M frequentemente diz:
"Confie em seus instintos."
No mainframe existe uma versão melhor:
"Nunca remova um IF antes de descobrir quem escreveu aquele IF."
Porque talvez quem escreveu já tenha resolvido um desastre que nunca foi documentado.
Licença para Refatorar
Bond tinha licença para matar.
O programador moderno deveria possuir outra licença:
Licença para perguntar.
Antes de remover qualquer validação:
Quem pediu?
Quando surgiu?
Qual incidente originou?
Existe documento?
Existe chamado?
Existe histórico?
Existe auditoria?
Se ninguém souber responder...
o IF merece respeito.
Conclusão — O verdadeiro agente secreto é a regra de negócio
Todo iniciante imagina que programas COBOL são grandes coleções de IFs antigos, mensagens em maiúsculas e GO TO espalhados pelo código.
Com o tempo, porém, descobre uma verdade muito mais fascinante: cada validação é um pequeno agente secreto infiltrado no sistema. Ela trabalha silenciosamente, impedindo que dados inconsistentes atravessem fronteiras invisíveis e provoquem efeitos em cadeia em faturamento, relatórios, integrações, processamento batch e auditorias.
Modernizar não é eliminar essas sentinelas indiscriminadamente. É investigar sua missão, entender o contexto histórico, confirmar se ainda fazem sentido e decidir o melhor lugar para que continuem protegendo o negócio. A inteligência artificial pode acelerar essa investigação, resumir código e sugerir perguntas relevantes, mas ela ainda depende da experiência humana para interpretar o significado de cada regra e validar seu impacto no mundo real.
No universo Bellacosa Mainframe, a maior lição é simples: um IF aparentemente banal pode valer mais do que milhares de linhas de código moderno, porque ele representa conhecimento acumulado ao longo de décadas. Assim como James Bond salva o mundo antes que a maioria perceba que havia perigo, uma boa validação impede desastres que nunca aparecerão nos relatórios de incidentes justamente porque jamais chegaram a acontecer.
Da próxima vez que encontrar um antigo IF CAMPO = SPACES, não pense apenas em removê-lo. Pense que talvez ele seja o 007 do seu sistema: discreto, elegante, quase invisível... e responsável por impedir que uma catástrofe silenciosa aconteça todos os dias.
