 |
| Bellacosa Mainframe em abend sem misterio parte III |
☕ Um Café no Bellacosa Mainframe
ABEND sem Mistérios — Parte III
Como Pensam os Especialistas em Mainframe: Engenharia de Diagnóstico, Dumps, IPCS e a Arte de Encontrar a Causa Raiz
"Um bom programador corrige um ABEND. Um grande engenheiro descobre por que ele nunca deveria ter acontecido."
Introdução
Até aqui, aprendemos duas grandes lições.
Na Parte 1 entendemos:
o que é um ABEND;
como ele nasce;
quais são os principais códigos encontrados no dia a dia.
Na Parte 2 aprendemos:
como investigar;
quais mensagens analisar;
como utilizar JESMSGLG, JESYSMSG, CEEDUMP e SYSOUT.
Agora chegamos ao terceiro nível.
Aqui deixamos de ser apenas programadores COBOL.
Passamos a pensar como verdadeiros engenheiros de software para IBM Z.
É exatamente essa mudança de mentalidade que diferencia um desenvolvedor comum de um profissional extremamente valorizado pelos grandes bancos.
O maior erro durante uma investigação
Imagine que um programa termina com:
S0C7
O iniciante pensa:
"Preciso corrigir este S0C7."
O profissional pensa diferente.
"O S0C7 é apenas consequência.
O que gerou os dados inválidos?"
Essa diferença muda completamente a investigação.
O conceito de Causa Raiz
Todo problema possui duas causas.
Sintoma
É aquilo que aparece.
S0C4
S0C7
ASRA
U4038
Causa
É o verdadeiro problema.
Exemplo:
Arquivo recebido com dados inválidos
↓
Campo não validado
↓
ADD
↓
S0C7
O ABEND não começou no ADD.
Começou quando alguém permitiu que dados incorretos chegassem até ali.
O pensamento em camadas
Especialistas enxergam uma aplicação como diversas camadas.
Usuário
↓
Tela
↓
CICS
↓
Programa COBOL
↓
COPYBOOK
↓
Db2
↓
VSAM
↓
MQ
↓
JCL
↓
z/OS
O erro pode nascer em qualquer uma delas.
O princípio dos "Cinco Porquês"
Uma técnica extremamente utilizada em engenharia é o 5 Whys, criado dentro do Sistema Toyota de Produção.
Exemplo.
Programa terminou em S0C7.
Por quê?
Porque tentou somar caracteres.
Por quê?
Porque recebeu "ABCDE".
Por quê?
Porque o arquivo veio corrompido.
Por quê?
Porque o sistema fornecedor alterou o layout.
Por quê?
Porque não existia contrato de interface.
Agora encontramos a verdadeira causa.
O ABC da investigação
Todo incidente pode ser dividido em três perguntas.
A
O que aconteceu?
ABEND S0C4
B
Onde aconteceu?
Programa
Parágrafo
Offset
C
Por que aconteceu?
Essa é a parte difícil.
O conceito de Timeline
Um erro nunca aparece instantaneamente.
Existe uma sequência.
08:00
Arquivo recebido
↓
08:03
Programa inicia
↓
08:05
Registro inválido
↓
08:05
Campo carregado
↓
08:06
Cálculo
↓
08:06
S0C7
Perceba que o problema nasceu seis minutos antes do ABEND.
O poder do CEEDUMP
O CEEDUMP é praticamente uma fotografia.
Mas imagine que você possui uma fotografia de um acidente.
Ela mostra:
onde ocorreu;
quem estava presente;
posição dos veículos.
Mas ela não mostra o momento da colisão.
Por isso precisamos combinar várias evidências.
Entrando no mundo do IPCS
Poucos iniciantes conhecem esta ferramenta.
IPCS significa:
Interactive Problem Control System
É uma das ferramentas mais importantes do z/OS.
Ela permite analisar:
dumps completos;
memória;
registradores;
módulos carregados;
PSW;
TCB;
ASCB;
cadeias de controle do sistema.
Na prática,
é o laboratório forense do IBM Z.
O que um Dump realmente contém?
Muitos imaginam um dump como um arquivo de texto.
Na realidade ele contém praticamente toda a memória capturada.
Por exemplo:
Endereços
Buffers
Variáveis
Registradores
Storage
TCBs
RBs
LSQA
CSA
ECSA
PSA
Núcleo
É literalmente uma fotografia da memória.
O famoso PSW
O Program Status Word é uma das primeiras informações analisadas.
Ele responde:
onde a CPU estava;
em qual instrução;
qual modo de execução;
qual estado do processador.
Por isso um SysProg costuma perguntar:
"Qual é o PSW?"
Registradores: a mochila do processador
O IBM Z possui registradores gerais.
Imagine um pedreiro.
Antes de subir uma escada,
ele coloca ferramentas na mochila.
A CPU faz exatamente isso.
Antes de executar instruções,
ela guarda informações temporárias nos registradores.
Quando ocorre um ABEND,
essa mochila continua exatamente como estava.
É por isso que os registradores são tão importantes.
O papel da Language Environment (LE)
Praticamente todo programa COBOL moderno executa sobre o Language Environment.
Ele fornece:
gerenciamento de memória;
tratamento de exceções;
traceback;
serviços comuns;
interoperabilidade entre COBOL, C, C++ e PL/I.
Sem o LE, muitos diagnósticos seriam muito mais difíceis.
Quando um U4038 esconde outro erro
Muitos iniciantes acreditam que:
U4038
↓
Erro encontrado
Na realidade,
muitas vezes acontece isto.
S0C7
↓
Language Environment
↓
U4038
Ou seja,
o U4038 pode ser apenas uma "embalagem" para outro problema.
Sempre investigue além do código retornado.
O papel do Fault Analyzer
Hoje muitos bancos utilizam o IBM Fault Analyzer.
Ele transforma um dump complexo em algo muito mais amigável.
Por exemplo.
Em vez de mostrar:
Offset
00003A8F
Ele mostra:
Programa
CLIENTES
Linha
538
Campo
WS-SALDO
Economiza horas de investigação.
Abend-AID
Outra ferramenta extremamente popular.
Ela apresenta:
variáveis;
CALL Stack;
conteúdo dos registros;
SQLCA;
áreas de memória;
File Status;
tabelas.
É praticamente um "Google Maps" do dump.
O valor de um bom Log
Imagine um programa sem nenhum DISPLAY.
Agora imagine outro com mensagens como:
Iniciando cálculo...
Cliente 12345
Saldo encontrado
Calculando juros
Atualizando Db2
Commit realizado
Qual será mais fácil de investigar?
A resposta é óbvia.
Logs bem escritos reduzem drasticamente o tempo de diagnóstico.
Engenharia defensiva
Programadores experientes evitam ABENDs antes mesmo que eles aconteçam.
Como?
Validando tudo.
IF NUMERIC
IF FILE STATUS
IF SQLCODE
IF RESP
IF RESP2
IF LENGTH
IF EOF
IF RETURN-CODE
Quem valida dados produz programas muito mais robustos.
Os três níveis da depuração
Nível 1
Corrigir o erro.
Nível 2
Descobrir a causa.
Nível 3
Modificar o sistema para impedir que volte a acontecer.
Esse terceiro nível é onde nasce a excelência técnica.
O pensamento dos grandes bancos
Em ambientes críticos,
a pergunta raramente é:
"Quem escreveu o programa?"
A pergunta costuma ser:
"Por que nossos processos permitiram que isso chegasse à produção?"
Perceba a diferença.
Sai o culpado.
Entra a melhoria contínua.
O custo de um ABEND
Um único ABEND pode provocar:
atraso em milhares de transações;
indisponibilidade de canais digitais;
bloqueio de filas MQ;
rollback de atualizações no Db2;
atraso em processamentos batch;
impacto financeiro;
horas de investigação.
Por isso bancos investem tanto em observabilidade, monitoramento e prevenção.
Checklist profissional antes de corrigir um ABEND
Nunca altere o código antes de responder:
Qual foi o primeiro erro registrado?
O ABEND é causa ou consequência?
Houve mudança recente de layout, JCL ou copybook?
O problema é reproduzível?
Existe CEEDUMP ou SYSMDUMP?
O SQLCODE, FILE STATUS ou RESP indicavam falha antes do ABEND?
A correção elimina apenas o sintoma ou resolve a origem?
A evolução de um Programador Padawan
Todo profissional passa por estágios.
1
Tenho medo do ABEND.
↓
2
Consigo identificar o código.
↓
3
Aprendo a usar o SDSF.
↓
4
Entendo CEEDUMP.
↓
5
Interpreto mensagens do z/OS.
↓
6
Analiso offsets.
↓
7
Leio dumps.
↓
8
Descubro causas raiz.
↓
9
Evito novos ABENDs.
↓
10
Ensino outras pessoas.
É exatamente assim que surgem os especialistas.
Conclusão
A verdadeira maturidade técnica não está em decorar centenas de códigos de ABEND, mas em desenvolver uma forma estruturada de investigar problemas.
No IBM Z, praticamente nada acontece por acaso. Cada mensagem do JES2, cada registro do SDSF, cada CEEDUMP, cada offset e cada registrador contam parte da história. O papel do engenheiro é reunir essas peças até reconstruir a sequência completa dos acontecimentos.
Quando você deixa de perguntar "qual foi o ABEND?" e passa a perguntar "qual decisão, dado ou processo tornou esse ABEND inevitável?", seu modo de pensar muda para sempre.
É nesse momento que você deixa de ser apenas um programador COBOL e passa a enxergar o IBM Z como ele realmente é: um dos sistemas computacionais mais sofisticados, observáveis e resilientes já construídos. E essa é a habilidade que transforma um simples solucionador de erros em um verdadeiro especialista em Mainframe.
