 |
| Bellacosa Mainframe abend sem misterios parte II |
☕ Um Café no Bellacosa Mainframe
ABEND sem Mistérios — Parte II
Como um Programador Padawan Aprende a Investigar Dumps, Mensagens e Descobrir a Verdadeira Causa de um ABEND
"O ABEND nunca é o verdadeiro problema. Ele é apenas o último grito do sistema antes de interromper a execução."
Introdução
No primeiro artigo vimos o que é um ABEND, como ele nasce e conhecemos os principais códigos encontrados no dia a dia de um programador COBOL.
Mas existe uma pergunta que diferencia um programador iniciante de um profissional experiente.
Não é:
"Qual foi o ABEND?"
A pergunta correta é:
"Por que ele aconteceu?"
É aqui que começa o verdadeiro trabalho.
O ABEND é apenas o sintoma.
A causa quase sempre aconteceu vários segundos — ou milhares de instruções — antes.
Aprender a investigar um ABEND é muito parecido com o trabalho de um perito criminal.
O investigador nunca chega ao local perguntando:
"Quem é o culpado?"
Ele primeiro coleta evidências.
No IBM Z acontece exatamente a mesma coisa.
O que realmente acontece quando um programa falha?
Imagine uma execução simples.
JES2
↓
Initiator
↓
Language Environment
↓
Programa COBOL
↓
OPEN CLIENTES
↓
READ
↓
PROCESSA
↓
WRITE
↓
END
Agora imagine que durante um cálculo acontece um S0C7.
O sistema imediatamente interrompe tudo.
Mas antes de encerrar, ele registra uma enorme quantidade de informações.
É exatamente isso que usamos na investigação.
O IBM Z deixa pistas
Quando ocorre um ABEND, normalmente encontramos diversas evidências.
Entre elas:
JESMSGLG
JESYSMSG
SYSOUT
SYSPRINT
SYSUDUMP
SYSMDUMP
CEEDUMP
CEEMSG
mensagens IEC
mensagens IEF
mensagens DFH (CICS)
Cada uma responde perguntas diferentes.
O primeiro erro do iniciante
O Padawan normalmente faz isto:
ABEND=S0C7
↓
Corrige uma variável
↓
Executa novamente
O profissional faz diferente.
ABEND
↓
Mensagens
↓
JCL
↓
Dump
↓
Código
↓
Dados
↓
Correção
A diferença parece pequena.
Mas economiza horas de trabalho.
Entendendo o JESMSGLG
O JESMSGLG é praticamente um diário da execução.
Ele informa:
Muitas vezes a causa aparece ali mesmo.
Exemplo:
IEC141I 013-20
Nesse momento você já sabe que provavelmente existe um problema na abertura de arquivos.
Nem precisa olhar o COBOL ainda.
O papel do JESYSMSG
Enquanto o JESMSGLG conta a história,
o JESYSMSG mostra as mensagens produzidas pelo sistema operacional.
Ali aparecem mensagens como:
IEF142I
IEC141I
IGD
IDC
CSV
IEA
ICH
Cada prefixo pertence a um componente do z/OS.
Com o tempo, o programador começa a reconhecê-los automaticamente.
O que é o SYSOUT?
Toda instrução
DISPLAY
vai parar no SYSOUT.
Muitos bancos utilizam DISPLAY apenas durante testes.
Mas programas bem escritos produzem mensagens extremamente úteis.
Exemplo:
Cliente
123456
Saldo
250.00
Calculando Juros...
Se logo depois aparece um S0C7...
Já sabemos exatamente onde procurar.
DISPLAY é seu amigo
Nunca tenha medo de utilizar DISPLAY durante o desenvolvimento.
Exemplo:
DISPLAY 'ENTROU NO PARAGRAFO A'
DISPLAY WS-CLIENTE
DISPLAY WS-SALDO
DISPLAY SQLCODE
Depois de homologado...
Eles podem ser removidos ou controlados por parâmetros.
O famoso CEEDUMP
Se existe um documento que todo programador COBOL deveria aprender,
é o CEEDUMP.
Ele é produzido pelo Language Environment.
Nele encontramos:
É praticamente uma fotografia completa do programa no momento da falha.
O Call Stack
Imagine o programa abaixo.
PROGRAMA A
↓
CALL B
↓
CALL C
↓
CALL D
↓
S0C4
O CEEDUMP mostra exatamente esse caminho.
A
↓
B
↓
C
↓
D
Agora sabemos onde investigar.
O Traceback
O traceback mostra:
Programa
↓
Seção
↓
Parágrafo
↓
Offset
Por exemplo:
CLIENTE
↓
CALCULA-JUROS
↓
0000A8
Esse offset permite localizar a instrução responsável.
O que são Offsets?
Um executável não trabalha com número de linhas.
Ele trabalha com endereços.
Imagine:
Linha 100
↓
Offset 00A2
O compilador gera um mapa relacionando:
offset
↓
linha COBOL
Ferramentas como Fault Analyzer, Abend-AID e Debug Tool fazem essa conversão automaticamente.
Registradores
Durante a execução o processador utiliza registradores.
No IBM Z temos registradores gerais.
Quando ocorre um dump, normalmente vemos algo parecido com:
R0
R1
R2
...
R15
Eles informam:
parâmetros;
endereços;
retorno de CALL;
ponteiros;
áreas de memória.
Para quem trabalha com LE e Assembler, esses registradores são ouro puro.
O famoso PSW
Outra informação importante é o:
Program Status Word
Ele informa:
endereço atual;
estado do processador;
modo de execução;
condição.
Quando alguém diz:
"Veja o PSW"
Está dizendo:
"Descubra exatamente onde a CPU estava quando tudo parou."
Dumps
Existem vários tipos.
SYSUDUMP
Mais compacto.
Muito utilizado para aplicações.
SYSMDUMP
Muito mais completo.
Contém grandes regiões de memória.
É excelente para análise profunda.
CEEDUMP
Voltado ao Language Environment.
É o favorito dos desenvolvedores COBOL.
Como investigar um S0C7
Imagine:
COMPUTE
TOTAL = VALOR * TAXA
Resultado:
S0C7
Primeira pergunta:
VALOR
é numérico?
Segunda:
TAXA
é válida?
Terceira:
Quem carregou essas variáveis?
A origem do erro pode estar dezenas de linhas antes.
Como investigar um S0C4
Perguntas clássicas:
Existe índice fora do OCCURS?
↓
Existe tabela sem inicialização?
↓
Existe ponteiro inválido?
↓
CALL recebeu parâmetros errados?
↓
LINKAGE está correta?
↓
O programa acessou memória liberada?
Como investigar um S013
Antes de abrir o COBOL...
Verifique:
DDNAME
↓
RECFM
↓
LRECL
↓
BLKSIZE
↓
DISP
↓
Dataset correto
↓
Catalogado?
↓
Existe?
Muitas vezes o COBOL está perfeito.
O erro está no JCL.
A importância do JCL
Programadores iniciantes tendem a pensar:
"Meu trabalho termina no COBOL."
Na prática,
bons programadores COBOL conhecem muito bem:
JCL;
IDCAMS;
SORT;
IEBGENER;
DFSORT;
GDGs;
VSAM;
Catalog.
Quanto melhor você entender o ambiente,
menos ABENDs terá.
O papel do CICS
Quando aparece:
ASRA
O erro raramente começa no CICS.
O CICS apenas detectou que algo deu errado dentro do programa.
A investigação continua:
ASRA
↓
DFH Messages
↓
Trace
↓
Dump
↓
Programa
Ferramentas utilizadas pelos grandes bancos
Pouquíssimos profissionais analisam dumps manualmente o tempo todo.
Grandes instituições normalmente utilizam ferramentas como:
Essas ferramentas aceleram a análise ao transformar endereços, offsets e registradores em informações mais fáceis de interpretar.
Mesmo assim, elas não substituem o conhecimento. Um bom analista sabe interpretar as evidências e confirmar se a ferramenta está apontando a causa correta.
Um roteiro de investigação profissional
Sempre que receber um chamado de produção, siga uma sequência lógica:
Receber o chamado
↓
Anotar o ABEND
↓
Identificar STEP
↓
Consultar JESMSGLG
↓
Consultar JESYSMSG
↓
Verificar SYSOUT
↓
Ler CEEDUMP
↓
Localizar o traceback
↓
Encontrar o offset
↓
Relacionar com o código COBOL
↓
Analisar os dados de entrada
↓
Reproduzir o erro
↓
Corrigir
↓
Testar novamente
Essa abordagem evita "chutes" e torna a investigação repetível.
Os erros mais comuns dos Padawans
Corrigir o código sem ler as mensagens do sistema.
Ignorar o JCL e assumir que o COBOL está errado.
Não validar dados antes de cálculos e conversões.
Usar índices ou subscritos fora dos limites de tabelas.
Não conferir SQLCODE, FILE STATUS ou RESP/RESP2 após operações críticas.
Descartar o CEEDUMP sem analisá-lo.
Não reproduzir o problema em ambiente de testes antes de aplicar uma correção.
O perfil de um excelente investigador de ABEND
Os profissionais mais respeitados em grandes bancos raramente são aqueles que escrevem mais código.
São aqueles que conseguem responder rapidamente perguntas como:
O erro veio do programa ou do ambiente?
O problema é de dados, lógica ou infraestrutura?
O ABEND é a causa ou apenas a consequência?
Qual foi a primeira mensagem relevante?
É possível reproduzir o problema?
Eles tratam cada incidente como uma investigação técnica, baseada em evidências.
Conclusão
Dominar ABENDs não significa decorar centenas de códigos. Significa desenvolver uma forma estruturada de pensar.
O IBM Z sempre deixa pistas: mensagens, dumps, registradores, traceback, offsets e logs. Quem aprende a reuni-las deixa de agir por tentativa e erro e passa a trabalhar como um verdadeiro engenheiro de software.
Todo programador passa pelo primeiro S0C7, pelo primeiro S0C4 ou pelo primeiro ASRA. A diferença está em como reage. O iniciante vê apenas um erro. O profissional enxerga uma oportunidade de compreender melhor o funcionamento interno do sistema.
No fim, os melhores desenvolvedores COBOL não são aqueles que nunca encontram ABENDs. São aqueles que conseguem transformá-los em conhecimento, experiência e sistemas cada vez mais confiáveis.
