 |
| Bellacosa Mainframe emtemdemdo erros |
☕ Um Café no Bellacosa Mainframe
Muito Além da Sintaxe
O Que Todo Programador COBOL Padawan Precisa Saber Sobre Erros de Programação, Git, Extensões de Arquivos e Inteligência Artificial para Construir Sistemas que Sobrevivem ao Tempo
"Aprender uma linguagem é importante. Aprender como os computadores pensam é o que realmente transforma um programador em um engenheiro de software."
Existe uma frase muito conhecida entre desenvolvedores experientes:
"Programar não é escrever código. Programar é resolver problemas."
E, curiosamente, quanto mais experiência um profissional adquire, menos tempo ele passa escrevendo código e mais tempo ele dedica a entender erros, interpretar logs, analisar requisitos, versionar alterações, revisar código, automatizar processos e estudar novas tecnologias.
Esse é um choque para muitos iniciantes.
O Programador COBOL Padawan costuma imaginar que a carreira será composta principalmente por escrever comandos MOVE, IF, PERFORM, READ, WRITE e EXEC SQL.
Mas basta entrar em um grande banco, uma seguradora ou uma empresa aérea para descobrir uma realidade completamente diferente.
Ali existem milhares de programas.
Milhões de linhas de código.
Centenas de desenvolvedores.
Diversas linguagens convivendo lado a lado.
COBOL.
PL/I.
Assembler.
Java.
Python.
JavaScript.
Go.
Rust.
SQL.
JCL.
REXX.
E, cada vez mais, Inteligência Artificial auxiliando todas essas equipes.
Nesse ambiente, conhecer apenas a sintaxe de uma linguagem é como saber dirigir um carro sem entender placas de trânsito, mecânica ou regras de circulação.
É por isso que as cinco listas apresentadas anteriormente representam muito mais do que simples curiosidades.
Na prática, elas resumem alguns dos pilares da Engenharia de Software moderna.
Vamos conversar sobre cada um deles.
Pegue seu café.
O computador nunca faz "o que você quis"
Uma das maiores descobertas de todo programador é perceber que computadores não possuem bom senso.
Eles fazem exatamente aquilo que foi programado.
Nem mais.
Nem menos.
Se existir uma pequena falha lógica, o computador executará essa falha com perfeição matemática.
É por isso que um erro aparentemente insignificante pode movimentar milhões de reais incorretamente.
No IBM Z isso acontece diariamente.
Não porque o mainframe seja ruim.
Muito pelo contrário.
Ele é extremamente confiável.
O problema sempre foi — e sempre será — o ser humano.
Existem erros... e existem erros
Quando alguém começa a aprender programação, normalmente acredita que erro significa apenas aquela mensagem vermelha que aparece na tela.
Na realidade existem diversas categorias.
Cada uma possui causas completamente diferentes.
Cada uma exige uma forma diferente de investigação.
É exatamente isso que diferencia um programador júnior de um engenheiro de software.
Syntax Error
O primeiro erro da carreira.
O compilador simplesmente não consegue entender o que você escreveu.
Imagine escrever em português:
Eu mercado fui ontem.
As palavras existem.
Mas a estrutura está incorreta.
O compilador pensa exatamente assim.
Em COBOL:
IF SALDO > 100
DISPLAY "OK"
Faltou o END-IF.
O compilador interrompe tudo.
Nada será executado.
Esse tipo de erro normalmente é simples.
O compilador informa linha, coluna e descrição.
Runtime Error
Agora a situação muda.
O programa compilou perfeitamente.
Foi para produção.
Começou a executar.
Depois...
ABEND.
No universo Mainframe, poucos termos assustam tanto quanto esse.
Um ABEND (Abnormal End) significa que alguma condição inesperada ocorreu durante a execução.
Alguns exemplos clássicos:
S0C1
S0C4
S0C7
S0CB
S322
SB37
SE37
SD37
Cada um deles conta uma história diferente.
Por exemplo...
Dividir por zero em Python gera:
ZeroDivisionError
No COBOL, dependendo do contexto, isso normalmente resulta em um S0CB.
Já acessar memória inválida pode gerar um S0C4, um dos ABENDs mais conhecidos entre programadores COBOL.
Por isso, aprender apenas a programar não basta.
É necessário aprender a investigar.
Ler dumps.
Interpretar mensagens.
Consultar SYSOUT.
Analisar o JES.
Entender SDSF.
Essa habilidade vale ouro.
O erro mais perigoso não gera mensagem
Esse é o famoso Logical Error.
O programa funciona.
Não apresenta erro.
Não gera dump.
Não gera ABEND.
Mas calcula errado.
Imagine um banco calculando juros de 1,59% quando deveria calcular 1,95%.
O programa executa normalmente.
Nenhum operador percebe.
Nenhum monitor dispara alerta.
Somente semanas depois alguém descobre um prejuízo milionário.
Esse tipo de erro explica por que testes automatizados, revisão de código e homologação são tão importantes.
Tipos de dados existem por um motivo
Quando o COBOL foi criado, muitos acreditavam que sua enorme quantidade de definições era exagerada.
Hoje entendemos que não era.
Cada tipo de dado existe para evitar erros.
Em Python podemos escrever:
idade = "30"
Visualmente parece correto.
Mas...
idade + 5
gera erro.
Em COBOL:
PIC 9(03)
é completamente diferente de
PIC X(03)
Essa rigidez é justamente o que torna sistemas bancários tão confiáveis.
Overflow e Underflow
Imagine um campo:
PIC 999
Ele aceita apenas três dígitos.
Se alguém tentar gravar:
1000
algo precisa acontecer.
Dependendo da situação ocorrerá truncamento, exceção ou erro de execução.
Já o Underflow acontece principalmente em cálculos científicos quando números extremamente pequenos perdem precisão.
Embora seja raro em aplicações comerciais, ele é muito comum em computação de alto desempenho e modelos de Inteligência Artificial.
Arquivos são muito mais importantes do que parecem
Outro assunto frequentemente ignorado pelos iniciantes são as extensões de arquivos.
".py"
".java"
".json"
".xml"
".sql"
Muitos acreditam que isso serve apenas para organizar arquivos.
Na realidade, cada extensão representa um ecossistema inteiro.
Quando você vê um arquivo ".java", imediatamente sabe que existe uma JVM envolvida.
Ao encontrar um ".sql", entende que haverá interação com um banco de dados.
Um ".json" normalmente representa troca de informações entre sistemas.
No IBM Mainframe a situação é um pouco diferente.
Grande parte do código está armazenada em membros de PDS ou PDSE.
Não existe necessariamente uma extensão visível.
Mesmo assim, cada biblioteca possui um propósito muito bem definido.
Um membro pode conter COBOL.
Outro JCL.
Outro PROC.
Outro REXX.
Outro COPYBOOK.
Outro DCLGEN.
A organização continua existindo.
Apenas mudou de formato.
O mundo moderno conversa em JSON
Durante décadas o XML dominou integrações corporativas.
SOAP.
Web Services.
Mensagens estruturadas.
Hoje a maior parte das APIs REST utiliza JSON.
Exemplo:
{
"cliente":"Maria",
"saldo":3500.90
}
É simples.
Leve.
Legível.
O COBOL moderno já possui suporte para JSON PARSE e JSON GENERATE, permitindo que programas tradicionais conversem diretamente com aplicações web e microsserviços.
Isso demonstra como o ecossistema IBM Z continua evoluindo.
Git mudou a Engenharia de Software
Antigamente, equipes compartilhavam código copiando arquivos.
Imagine dez programadores alterando o mesmo programa COBOL.
Caos.
Hoje isso seria impensável.
O Git resolveu esse problema.
Na prática, o Git funciona como uma máquina do tempo.
Cada Commit registra exatamente o que mudou.
Quem mudou.
Quando mudou.
E por quê.
Se um erro aparecer meses depois, basta consultar o histórico.
Essa rastreabilidade é indispensável em ambientes regulados, como bancos e seguradoras.
Commit não é backup
Esse é um erro comum entre iniciantes.
Commit significa registrar uma alteração lógica.
Um bom commit deve representar uma unidade de trabalho.
Exemplo ruim:
Correções
Exemplo excelente:
Corrige cálculo de IOF para operações acima de R$ 50.000
Percebe a diferença?
O histórico passa a contar uma história.
Branches são universos paralelos
Imagine que a produção está funcionando.
Você precisa desenvolver uma nova funcionalidade.
Não faz sentido quebrar o código principal.
Então cria-se uma Branch.
Ali você trabalha livremente.
Quando tudo estiver pronto, ocorre o Merge.
Essa ideia revolucionou o desenvolvimento colaborativo.
Conflitos fazem parte da profissão
Todo desenvolvedor, cedo ou tarde, encontrará um Merge Conflict.
Isso acontece quando duas pessoas alteram a mesma região do mesmo arquivo.
O Git não consegue decidir automaticamente.
Então pergunta ao ser humano.
Resolver conflitos é uma habilidade importante.
Não é um sinal de incompetência.
É consequência natural do trabalho em equipe.
O Git também chegou ao Mainframe
Durante décadas o versionamento em ambientes IBM Z foi realizado por ferramentas como Endevor, Changeman, Librarian, Panvalet e SCLM.
Hoje o cenário mudou.
Zowe.
Git.
GitHub.
GitLab.
Azure DevOps.
Pipeline CI/CD.
Tudo isso já faz parte da realidade do IBM Z.
O desenvolvedor COBOL moderno trabalha tanto no ISPF quanto no VS Code.
Inteligência Artificial começa pelos dados
Quando ouvimos falar em IA, pensamos imediatamente em ChatGPT.
Mas antes de existir qualquer modelo existe algo muito mais importante.
Dados.
Sem dados não existe aprendizado.
É por isso que Machine Learning começa pelo Dataset.
Imagine ensinar uma criança a reconhecer gatos.
Você mostra milhares de fotografias.
Ela aprende padrões.
Modelos de IA fazem exatamente isso.
Features são as pistas
Suponha um sistema bancário que detecta fraude.
Cada operação possui informações como:
Valor.
Cidade.
Horário.
Dispositivo.
Cliente.
Canal.
Cada uma dessas características recebe o nome de Feature.
Quanto melhores forem as Features, melhor tende a ser o modelo.
Labels representam a resposta correta
Em aprendizado supervisionado existe um professor.
Cada exemplo já possui a resposta.
Operação fraudulenta?
Sim.
Não.
Essas respostas são chamadas de Labels.
O algoritmo tenta aprender a relação entre Features e Labels.
Treinar não é decorar
Aqui surge um dos conceitos mais importantes da IA.
Overfitting.
Imagine um aluno que decorou todas as respostas da apostila.
Na prova, qualquer pergunta diferente o confunde.
Foi exatamente isso que aconteceu com o modelo.
Ele decorou.
Não aprendeu.
No extremo oposto está o Underfitting.
O aluno nem conseguiu compreender o conteúdo.
O modelo é simples demais.
Também falha.
O objetivo sempre é encontrar o equilíbrio.
Accuracy nem sempre significa qualidade
Imagine um banco com um milhão de operações.
Apenas mil são fraudulentas.
Um algoritmo responde sempre:
Não é fraude.
Resultado:
999 mil acertos.
Accuracy de 99,9%.
Parece excelente.
Mas encontrou exatamente zero fraudes.
Por isso profissionais utilizam outras métricas.
Precision.
Recall.
F1-Score.
ROC-AUC.
Cada métrica responde uma pergunta diferente.
Redes neurais não pensam
Esse é um dos maiores equívocos atuais.
Uma Rede Neural não possui consciência.
Ela ajusta milhões ou bilhões de pesos matemáticos.
O comportamento impressionante dos grandes modelos de linguagem surge da enorme quantidade de dados, parâmetros e capacidade computacional.
Ainda assim, continuam sendo modelos estatísticos.
O futuro do COBOL não é competir com a IA
É trabalhar junto dela.
Hoje um desenvolvedor pode utilizar IA para:
explicar programas COBOL antigos;
gerar documentação técnica;
criar testes automatizados;
sugerir refatorações;
converter layouts de arquivos;
produzir exemplos em Java ou Python;
revisar SQL;
explicar ABENDs;
auxiliar na escrita de JCL e REXX;
acelerar a compreensão de sistemas legados.
A IA não substitui o conhecimento do negócio.
Ela amplia a produtividade de quem já conhece o ambiente.
O verdadeiro diferencial continua sendo o raciocínio
Ferramentas mudam.
Linguagens surgem.
Frameworks desaparecem.
Mas alguns fundamentos permanecem praticamente inalterados desde os primórdios da computação.
Entender algoritmos.
Conhecer estruturas de dados.
Interpretar erros.
Versionar corretamente.
Escrever código legível.
Documentar alterações.
Testar antes de entregar.
Compreender o domínio do negócio.
Esses princípios continuam válidos para COBOL, Java, Python, Go, Rust, JavaScript ou qualquer outra tecnologia.
O Programador COBOL Padawan e a Jornada para se Tornar um Mestre
Todo grande profissional já foi iniciante.
Ninguém nasce sabendo interpretar um S0C4, resolver um conflito de Git, entender uma métrica de Machine Learning ou projetar uma arquitetura distribuída.
Essas habilidades são construídas com estudo, prática e curiosidade.
O Programador COBOL Padawan deve enxergar cada erro como uma oportunidade de aprendizado, cada commit como um registro da sua evolução, cada extensão de arquivo como a porta de entrada para um novo ecossistema e cada conceito de Inteligência Artificial como uma ferramenta que amplia sua capacidade de resolver problemas.
No Bellacosa Mainframe, costumamos dizer que o objetivo não é formar apenas programadores que saibam escrever código. Queremos formar profissionais capazes de compreender sistemas inteiros, conversar com equipes multidisciplinares, integrar tecnologias clássicas e modernas e tomar decisões técnicas conscientes.
A jornada começa com um simples DISPLAY "HELLO WORLD".
Depois evolui para programas COBOL, JCLs, consultas SQL, integrações REST, pipelines DevOps, versionamento com Git, observabilidade, automação e, mais recentemente, Inteligência Artificial aplicada ao desenvolvimento.
O segredo nunca foi decorar comandos.
O segredo é compreender os fundamentos que atravessam gerações de tecnologias.
Quem domina esses fundamentos consegue aprender qualquer linguagem, adaptar-se a qualquer plataforma e continuar relevante mesmo quando novas ferramentas surgem.
E talvez essa seja a maior lição desta conversa: o COBOL Padawan que aprende a pensar como engenheiro de software não fica preso ao passado; ele usa a solidez do legado para construir o futuro.
Porque, no fim das contas, linguagens mudam, frameworks envelhecem, bibliotecas são substituídas e paradigmas evoluem. Mas a capacidade de analisar problemas, entender sistemas complexos e entregar soluções confiáveis continuará sendo o maior patrimônio de qualquer profissional de tecnologia.
Então, da próxima vez que encontrar uma mensagem de erro, criar uma nova branch, analisar um arquivo JSON ou ouvir falar de Machine Learning, lembre-se: você não está estudando assuntos isolados. Está construindo a base que sustentará toda a sua carreira como desenvolvedor.
E essa é uma jornada que vale cada linha de código.
