ABEND sem Mistérios — Parte II

 

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:

• início do JOB;

• alocação dos datasets;

• criação de arquivos temporários;

• início de cada STEP;

• mensagens do sistema;

• encerramento.

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:

• última instrução executada;

• registradores;

• call stack;

• variáveis;

• condições;

• traceback;

• offsets;

• informações do compilador.

É 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:

• IBM Fault Analyzer

• IBM Debug Tool

• IBM Application Performance Analyzer

• IBM File Manager

• Abend-AID (BMC)

• Xpediter

• IBM IPCS

• IBM Developer for z/OS (IDz)

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.