 |
| Bellacosa Mainframe e uma analise forense aos abends em mainframe |
☕ Um Café no Bellacosa Mainframe
ABEND sem Mistérios para Programadores COBOL
Quando um Programa Morre em Produção, o Código do Erro é Apenas a Primeira Evidência Encontrada na Cena do Crime
O telefone toca às 2h17 da madrugada.
Do outro lado da linha, uma voz cansada anuncia:
— O fechamento noturno parou.
No monitor, dezenas de jobs aguardam processamento. Arquivos não foram atualizados. Relatórios não foram produzidos. O sistema responsável por calcular pagamentos, atualizar saldos ou consolidar transações encerrou de maneira inesperada.
Na tela do SDSF, uma mensagem chama a atenção:
IEF450I PAGTO01 STEP010 - ABEND=S0C7
Para o programador COBOL iniciante, aquelas letras parecem uma inscrição encontrada em uma tumba antiga:
S0C7
Seria um problema no JCL?
Um erro de banco de dados?
Um campo numérico corrompido?
Uma falha do sistema operacional?
Um usuário digitou algo errado?
Ou o programa simplesmente decidiu abandonar o turno da madrugada?
No laboratório do CSI Las Vegas, ninguém olha para uma evidência isolada e imediatamente acusa o mordomo. Um fio de cabelo não resolve sozinho um homicídio. Uma impressão digital precisa de contexto. Uma mancha precisa ser analisada. Um objeto fora do lugar pode ser causa, consequência ou apenas coincidência.
No IBM Mainframe, o raciocínio deve ser exatamente o mesmo.
O ABEND não é necessariamente a causa do incidente. Ele é a primeira evidência encontrada na cena do crime.
O bom profissional não se limita a decorar que S0C7 significa “erro de dados”. Ele investiga:
qual instrução falhou;
qual programa estava em execução;
qual registro estava sendo processado;
qual era o conteúdo real do campo;
quem gravou aquele dado;
qual versão do copybook foi usada;
quais alterações entraram recentemente;
por que as validações anteriores não detectaram o problema;
e, principalmente, como impedir que ele aconteça novamente.
Coloque as luvas, acenda a luminária ultravioleta e abra o SDSF.
A investigação começou.
 |
| Bellacosa Mainframe e os abends mais comuns no ambiente mainframe |
1. O que é realmente um ABEND?
ABEND é uma abreviação de:
ABnormal END
Ou seja, fim anormal.
Significa que um programa, uma etapa de job, uma transação ou algum componente do processamento terminou de maneira diferente da esperada.
Em um cenário normal, o programa COBOL chega ao final de sua execução e devolve um código de retorno:
MOVE 0 TO RETURN-CODE
GOBACK.
Nesse caso, tudo indica que o processamento terminou normalmente.
Mas um término anormal pode ocorrer quando:
o processador tenta executar uma instrução inválida;
o programa acessa uma região de memória não permitida;
uma operação decimal encontra dados incompatíveis;
o tempo de execução excede o limite;
um módulo chamado não é encontrado;
um arquivo não pode ser aberto;
o espaço em disco se esgota;
uma transação CICS entra em loop;
um comando SQL recebe timeout ou deadlock;
a aplicação decide interromper voluntariamente o processamento.
Portanto, dizer apenas “o programa deu ABEND” é semelhante a dizer:
“A vítima morreu.”
A frase informa o resultado, mas não explica o mecanismo, a causa, a sequência dos acontecimentos nem a responsabilidade.
2. A primeira regra da investigação: não altere a cena do crime
Um erro muito comum durante incidentes é tentar resolver o problema rápido demais.
O programador vê um S0C7, imagina que algum campo numérico está inválido e acrescenta uma inicialização:
MOVE ZEROS TO WS-VALOR
O programa deixa de cair.
Caso encerrado?
Não necessariamente.
Talvez o campo estivesse sendo sobrescrito por outro módulo. Talvez o copybook estivesse divergente. Talvez um arquivo tivesse registros com layouts diferentes. Talvez o programa anterior estivesse gravando lixo. Talvez a alteração apenas escondesse o sintoma.
No CSI, limpar a mesa antes de coletar impressões digitais seria um desastre.
No mainframe, sobrescrever datasets, excluir dumps, recompilar sem guardar evidências ou reiniciar o processamento sem documentar o estado original pode destruir pistas fundamentais.
Antes de alterar qualquer coisa, preserve:
Código do ABEND
Nome do job
Nome do step
Programa em execução
Data e horário
JOBLOG
JESMSGLG
JESJCL
JESYSMSG
SYSOUT
CEEDUMP
SYSUDUMP
Relatório do compilador
Versão do load module
Arquivo ou registro em processamento
SQLCODE e SQLSTATE
Mensagens CICS ou IMS
Essa é a cadeia de custódia digital do incidente.
3. As famílias de ABENDs
O universo do IBM Z possui diferentes categorias de falhas. A classificação ajuda a decidir onde iniciar a busca.
3.1 System ABENDs
Normalmente aparecem no formato:
Sxxx
Exemplos:
S0C1
S0C4
S0C7
S0CB
S322
S806
Esses códigos indicam condições detectadas pelo sistema, pelo processador ou por componentes do ambiente de execução.
O primeiro caractere é a letra S, de System ABEND.
Entretanto, atenção a uma curiosidade que confunde muitos iniciantes: em códigos como S0C7, o caractere depois do zero é a letra C, e não o número zero.
O código correto é:
S0C7
e não:
SOC7
Visualmente são parecidos, especialmente em algumas fontes, mas tecnicamente são diferentes.
Esse pequeno detalhe é um verdadeiro easter egg da tipografia mainframe: durante décadas, muita documentação informal escreveu “SOC7”, embora a representação correta seja “S-zero-C-sete”.
3.2 User ABENDs
Aparecem no formato:
Uxxxx
Exemplos:
U0016
U0999
U3000
U4038
São geralmente provocados deliberadamente pela aplicação, por um utilitário ou pelo Language Environment.
Um User ABEND não significa necessariamente defeito do sistema. Pode representar uma decisão controlada:
“Uma condição de negócio ou técnica tornou inseguro continuar.”
Por exemplo, uma aplicação pode interromper o processamento ao detectar que o total de controle do arquivo não coincide com o total informado no trailer.
Em vez de continuar e corromper milhares de registros, ela termina com:
U3000
Nesse caso, o ABEND é parte da proteção do sistema.
3.3 Erros de JCL e alocação
Alguns incidentes ocorrem antes mesmo de o programa COBOL executar sua primeira instrução.
Exemplos:
erro de sintaxe no JCL;
DDNAME ausente;
dataset não catalogado;
disposição incompatível;
volume indisponível;
DCB incorreto;
espaço insuficiente;
membro inexistente na biblioteca.
A mensagem mais importante pode estar no JESYSMSG ou em mensagens IEC, IEF e IGD, e não no código COBOL.
3.4 Erros DB2
No ambiente DB2, muitas falhas são identificadas por:
SQLCODE
SQLSTATE
REASON CODE
RESOURCE NAME
Exemplos conhecidos:
-805
-818
-904
-911
-913
-922
Esses códigos podem aparecer antes de um User ABEND gerado pela própria aplicação. Portanto, o Uxxxx pode ser apenas a embalagem; a causa verdadeira está no SQLCODE.
3.5 ABENDs CICS
No CICS, encontramos códigos como:
ASRA
AICA
APCT
AEY9
AEI0
AKCP
Eles dizem respeito a transações, programas, comandos EXEC CICS, proteção de storage, tempo de execução, recursos e outras condições do ambiente online.
3.6 Condições IMS
No IMS, a investigação pode envolver:
status codes DL/I;
PSB;
PCB;
DBD;
ACB;
região IMS;
mensagem de entrada;
checkpoint;
chamadas GU, GN, ISRT, REPL ou DLET.
Em outras palavras, cada família possui seu próprio laboratório criminalístico.
4. S0C1 — a instrução que não deveria existir
O S0C1 significa, em termos gerais, Operation Exception.
O processador tentou executar uma sequência de bytes que não representa uma instrução válida naquele contexto.
Imagine que o programa deveria saltar para o endereço de uma rotina:
ENDEREÇO 000A3000
Mas, devido a um ponteiro corrompido ou retorno inválido, ele salta para uma área contendo dados:
F1F2F3F4
Esses bytes podem representar os caracteres “1234” em EBCDIC, mas o processador tenta interpretá-los como instruções de máquina.
O resultado é uma operação inválida.
Possíveis causas:
endereço de retorno destruído;
CALL para módulo incorreto;
incompatibilidade de parâmetros;
load module corrompido;
execução desviada para área de dados;
armazenamento sobrescrito;
uso incorreto de ponteiros;
versão errada de programa carregada.
O S0C1 costuma exigir análise de PSW, registradores e offset.
Não é um ABEND que se resolve apenas procurando uma variável com valor estranho.
5. S0C4 — invasão de propriedade digital
O S0C4 está associado a condições como Protection Exception ou outros problemas de endereçamento, dependendo do código de razão.
Em linguagem simples, o programa tentou acessar uma área de memória de maneira inválida.
Imagine um hotel em Las Vegas.
O programa possui a chave do quarto 3270, mas tenta entrar no quarto 0, em um andar inexistente ou numa área restrita do hotel.
O sistema operacional funciona como o segurança:
“Você não tem permissão para acessar esse endereço.”
Entre as causas mais comuns estão:
índice ou subscrito fora dos limites;
parâmetro ausente em um CALL;
definição errada na LINKAGE SECTION;
ponteiro nulo ou inválido;
diferença de layout entre programa chamador e chamado;
sobreposição de storage;
tabela acessada além da quantidade de ocorrências;
endereço de arquivo ou área de comunicação corrompido.
Considere:
01 WS-TABELA.
05 WS-ITEM OCCURS 10 TIMES.
10 WS-CODIGO PIC X(05).
01 WS-INDICE PIC 99.
MOVE 15 TO WS-INDICE
MOVE 'ABCDE' TO WS-CODIGO(WS-INDICE)
A tabela possui dez posições, mas o programa tenta acessar a posição quinze.
Dependendo do compilador, das opções de runtime e da organização do storage, o programa pode:
gerar uma condição detectável;
sobrescrever outra variável;
continuar silenciosamente;
cair mais tarde em outro ponto;
produzir S0C4;
provocar um S0C7 aparentemente sem relação.
Esse é um detalhe fundamental: o local onde o programa cai pode não ser o local onde o problema começou.
A vítima pode ter sido encontrada no cassino, mas o crime ocorreu no estacionamento.
6. S0C7 — o famoso dado decimal inválido
O S0C7 é provavelmente o ABEND mais conhecido entre programadores COBOL.
Ele ocorre quando uma instrução decimal tenta operar sobre um conteúdo que não possui representação decimal válida.
Considere:
01 WS-VALOR PIC S9(05)V99 COMP-3.
Esse campo utiliza formato decimal compactado, também chamado packed decimal.
Em COMP-3, cada dígito ocupa meio byte, e o último nibble contém o sinal.
Um valor válido poderia estar representado internamente como:
12 34 56 7C
O nibble C representa sinal positivo.
Se a área contiver algo como:
12 3A 56 7C
o nibble A apareceu em uma posição onde deveria existir um dígito de zero a nove.
Ao executar uma operação aritmética, o hardware detecta que aquilo não é um decimal válido e provoca uma data exception: S0C7.
De onde vem o dado inválido?
As causas mais comuns incluem:
campo não inicializado;
arquivo com layout diferente;
registro curto;
MOVE de campo alfanumérico para área redefinida;
REDEFINES incorreto;
copybook divergente;
parâmetro enviado com tamanho errado;
sobrescrita de memória;
processamento de header ou trailer como detalhe;
conteúdo hexadecimal incompatível;
arquivo convertido de ASCII para EBCDIC de maneira inadequada.
Exemplo clássico:
01 REGISTRO-ENTRADA.
05 TP-REGISTRO PIC X.
05 VALOR PIC 9(07).
READ ARQ-ENTRADA
ADD VALOR TO WS-TOTAL
O programa pressupõe que todos os registros possuem o mesmo layout.
Mas o arquivo contém:
H20260725ARQUIVO DE PAGAMENTOS
D0001250
D0003300
TTOTAL=0000002
Quando o programa tenta somar o campo VALOR do trailer, pode encontrar letras no lugar de dígitos.
A solução correta não é simplesmente substituir tudo por zero. É interpretar o tipo de registro:
EVALUATE TP-REGISTRO
WHEN 'H'
PERFORM TRATAR-HEADER
WHEN 'D'
PERFORM TRATAR-DETALHE
WHEN 'T'
PERFORM TRATAR-TRAILER
WHEN OTHER
PERFORM TRATAR-REGISTRO-INVALIDO
END-EVALUATE
7. S0CB — divisão por zero
O S0CB representa uma exceção decimal associada, frequentemente, à divisão por zero.
Exemplo:
COMPUTE WS-MEDIA =
WS-TOTAL / WS-QUANTIDADE
Se:
WS-QUANTIDADE = 0
a operação não possui resultado matemático definido.
A prevenção é simples:
IF WS-QUANTIDADE > ZERO
COMPUTE WS-MEDIA =
WS-TOTAL / WS-QUANTIDADE
ELSE
MOVE ZERO TO WS-MEDIA
DISPLAY 'QUANTIDADE INVALIDA PARA CALCULO'
END-IF
Mas existe uma pergunta mais profunda:
Por que a quantidade chegou a zero?
Talvez o arquivo estivesse vazio. Talvez nenhum registro tenha passado pelas validações. Talvez o contador não tenha sido incrementado. Talvez o programa tenha lido o arquivo errado.
Evitar o ABEND é importante. Entender o cenário de negócio é indispensável.
8. S0CC e overflow decimal
Um overflow ocorre quando o resultado excede a capacidade do campo de destino.
Exemplo:
01 WS-TOTAL PIC 9(05).
MOVE 99999 TO WS-TOTAL
ADD 1 TO WS-TOTAL
O campo suporta, no máximo:
99999
O resultado:
100000
precisaria de seis dígitos.
Dependendo da instrução gerada, opções do compilador e contexto, poderá ocorrer uma exceção decimal ou truncamento.
A defesa COBOL inclui:
ADD WS-VALOR TO WS-TOTAL
ON SIZE ERROR
DISPLAY 'OVERFLOW NO TOTAL'
MOVE 12 TO RETURN-CODE
NOT ON SIZE ERROR
CONTINUE
END-ADD
A cláusula ON SIZE ERROR é como o detector de fumaça do programa. Ela não impede que o calor aumente, mas permite reagir antes que o edifício inteiro pegue fogo.
9. S322 — o programa que nunca voltou
O S322 geralmente indica que o tempo permitido para execução foi excedido.
Causas comuns:
loop infinito;
arquivo gigantesco;
algoritmo ineficiente;
parâmetro TIME muito baixo;
espera excessiva;
leitura repetida do mesmo registro;
cursor DB2 mal controlado;
condição de saída impossível.
Exemplo perigoso:
PERFORM UNTIL WS-FIM = 'S'
READ ARQ-ENTRADA
AT END
MOVE 'S' TO WS-FIM
END-READ
PERFORM PROCESSAR-REGISTRO
END-PERFORM
Parece correto.
Mas suponha que PROCESSAR-REGISTRO mova acidentalmente espaço para WS-FIM. O programa poderá continuar tentando ler após o fim do arquivo ou entrar em comportamento imprevisível.
Outro clássico:
PERFORM VARYING WS-I FROM 1 BY 1
UNTIL WS-I = 10
Nesse caso, o loop processa de 1 a 9. Porém, se o incremento ou a condição estiverem incorretos:
PERFORM VARYING WS-I FROM 1 BY 2
UNTIL WS-I = 10
os valores serão:
1, 3, 5, 7, 9, 11, 13...
A condição WS-I = 10 nunca será verdadeira.
Esse é o tipo de detalhe que faria Gil Grissom observar calmamente:
“O problema não está no corpo. Está no padrão.”
10. S806 — o módulo desaparecido
O S806 indica que o sistema não conseguiu localizar ou carregar o módulo solicitado.
Exemplo:
CALL 'CALCJURO' USING AREA-CALCULO
O programa CALCJURO precisa estar disponível em uma biblioteca acessível ao carregador.
No batch, isso normalmente envolve:
//STEPLIB DD DSN=EMPRESA.LOADLIB,DISP=SHR
Possíveis causas:
membro não existe;
nome incorreto no CALL;
STEPLIB ausente;
JOBLIB incorreta;
biblioteca não catalogada;
módulo foi compilado, mas não link-editado;
versão instalada em outro ambiente;
biblioteca concatenada na ordem errada;
alias inexistente;
módulo deletado ou renomeado.
Um detalhe importante: a ordem de concatenação importa.
//STEPLIB DD DSN=EMPRESA.LOAD.TESTE,DISP=SHR
// DD DSN=EMPRESA.LOAD.PROD,DISP=SHR
Se o mesmo módulo existir nas duas bibliotecas, a primeira ocorrência encontrada será carregada.
Você pode pensar que está executando a versão de produção, enquanto o sistema está carregando uma versão antiga de teste.
Essa é a versão mainframe do suspeito com identidade falsa.
11. Os ABENDs de espaço: SB37, SD37 e SE37
Arquivos sequenciais, temporários, relatórios e operações de SORT podem exigir mais espaço do que o previsto.
Um JCL pode conter:
//SAIDA DD DSN=EMPRESA.RELATORIO,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(5,2)),
// DCB=(RECFM=FB,LRECL=200,BLKSIZE=0)
O sistema aloca cinco cilindros primários e permite extensões secundárias de dois cilindros.
Se o arquivo crescer demais, poderá ocorrer um ABEND relacionado a espaço.
De maneira simplificada:
SB37: não foi possível obter mais espaço;
SD37: não havia especificação secundária suficiente ou disponível;
SE37: o dataset atingiu limite de extensões ou não conseguiu expandir adequadamente.
A correção pode envolver:
aumentar espaço primário;
aumentar espaço secundário;
rever unidade de alocação;
utilizar
RLSE;avaliar
DATACLAS;permitir volumes adicionais;
usar dataset estendido;
melhorar estimativa;
excluir dados desnecessários;
revisar a lógica que está produzindo volume excessivo.
Mas cuidado: aumentar espaço sem investigar pode apenas alimentar um programa em loop que está gravando registros infinitamente.
Nunca entregue um armazém maior ao suspeito antes de descobrir por que ele acumulou cinco milhões de caixas.
12. CICS: quando o crime acontece online
No batch, temos jobs e steps. No CICS, temos transações e tasks.
ASRA
O ASRA normalmente indica que um programa de aplicação sofreu uma exceção, como S0C4 ou S0C7, dentro do ambiente CICS.
A investigação deve considerar:
programa em execução;
offset;
comando EXEC CICS anterior;
COMMAREA;
channels e containers;
dados de tela;
mapa BMS;
recursos acessados;
dump da transação.
APCT
O APCT geralmente está relacionado a programa não encontrado, não habilitado ou problema na definição do programa.
É o primo online do S806.
Verifique:
definição
PROGRAM;nome solicitado;
CSD;
estado ENABLED;
NEWCOPY ou PHASEIN;
biblioteca DFHRPL;
região correta.
AICA
O AICA indica que a task excedeu o tempo permitido sem devolver controle adequadamente ao CICS.
Causa comum:
PERFORM UNTIL CONDICAO-FINAL
PERFORM PROCESSAMENTO
END-PERFORM
sem comandos CICS que permitam gerenciamento adequado da task ou com condição de saída incorreta.
AEY9
Frequentemente relacionado à indisponibilidade de uma conexão, especialmente em cenários envolvendo DB2, dependendo do contexto.
O código isolado nunca é suficiente. Consulte mensagens associadas e estado dos recursos.
13. DB2: o ABEND pode ser apenas o envelope
Considere um programa COBOL-DB2:
EXEC SQL
SELECT SALDO
INTO :WS-SALDO
FROM CONTA
WHERE NUM_CONTA = :WS-CONTA
END-EXEC
Depois do comando, o programa precisa verificar:
EVALUATE SQLCODE
WHEN 0
CONTINUE
WHEN 100
DISPLAY 'CONTA NAO ENCONTRADA'
WHEN OTHER
DISPLAY 'ERRO SQL: ' SQLCODE
PERFORM TRATAR-ERRO-DB2
END-EVALUATE
Alguns códigos importantes:
SQLCODE -805
Package não encontrado ou combinação de localização, coleção, package e consistência incompatível.
Investigue:
BIND;
COLLECTION;
PACKAGE;
PLAN;
DBRM;
versão implantada.
SQLCODE -818
Timestamp de consistência do programa não corresponde ao DBRM ou package.
É o famoso caso em que programa e package parecem casados, mas o exame de DNA revela que pertencem a compilações diferentes.
SQLCODE -911 e -913
Relacionados a deadlock ou timeout.
Pode haver rollback. A aplicação precisa entender o estado da unidade de trabalho antes de simplesmente repetir o processamento.
SQLCODE -904
Recurso indisponível.
A mensagem contém reason code e resource name, fundamentais para a investigação.
SQLCODE -922
Problema de autorização.
Pode envolver RACF, privilégios DB2, plano, package ou identidade de execução.
14. O dump: a autópsia digital
Quando o programa termina anormalmente, o dump pode registrar o estado do processo no momento da falha.
Dependendo da configuração, você pode encontrar:
SYSUDUMP
SYSABEND
SYSMDUMP
CEEDUMP
IPCSDUMP
CICS Transaction Dump
No dump, procure:
nome do programa;
código da condição;
PSW;
registradores;
endereço da falha;
offset;
traceback;
cadeia de chamadas;
parâmetros;
conteúdo das áreas;
mensagens do Language Environment.
O que é o PSW?
PSW significa Program Status Word.
Ele contém informações sobre o estado do processador, incluindo o endereço da instrução associada à interrupção.
Pode ser comparado à última coordenada registrada pelo GPS da vítima.
O que são os registradores?
A arquitetura IBM Z possui registradores de uso geral. Durante a execução, eles podem conter:
endereços;
contadores;
parâmetros;
ponteiros;
resultados intermediários.
Em análises de S0C4, observar registradores pode revelar que o programa tentou acessar endereço zero, um endereço muito baixo ou uma área incompatível.
O que é o offset?
O offset indica a distância entre o início do módulo e a instrução problemática.
Exemplo:
Programa: PAGTO001
Offset: X'00001A7C'
Com o listing da compilação, é possível relacionar esse offset à instrução COBOL correspondente.
Esse processo é uma das competências mais valiosas em suporte mainframe.
15. Passo a passo de investigação
Aqui está um procedimento prático para programadores iniciantes.
Passo 1 — Identifique o incidente
Registre:
Job
Step
Procstep
Programa
Código do ABEND
Horário
Ambiente
Exemplo:
JOB: FATU001
STEP: STEP030
PROGRAMA: PGMFAT03
ABEND: S0C7
AMBIENTE: PRODUÇÃO
Passo 2 — Leia o JOBLOG inteiro
Não procure apenas a linha contendo o ABEND.
Mensagens anteriores podem informar:
falha de abertura;
dataset incorreto;
SQLCODE;
warning;
arquivo vazio;
registro rejeitado;
módulo carregado;
condição LE.
Passo 3 — Localize o ponto da falha
Use:
offset;
traceback;
listing;
compilação com opções adequadas;
ferramentas de debugging;
Fault Analyzer, Abend-AID ou equivalentes, quando disponíveis.
Passo 4 — Examine os dados
Descubra:
qual registro estava sendo lido;
qual chave estava sendo processada;
qual campo estava inválido;
qual era o conteúdo hexadecimal;
se o layout corresponde ao arquivo.
Passo 5 — Verifique entradas e dependências
Analise:
JCL;
PROC;
PARM;
SYSIN;
datasets;
GDGs;
tabelas DB2;
módulos chamados;
copybooks;
versões instaladas.
Passo 6 — Consulte alterações recentes
Pergunte:
houve mudança no programa?
no copybook?
no arquivo?
na tabela DB2?
no BIND?
na segurança?
no agendamento?
no processo anterior?
Passo 7 — Reproduza controladamente
Monte um teste com:
mesmo registro;
mesma versão;
mesmo layout;
dados reduzidos;
ambiente seguro;
dumps habilitados.
Passo 8 — Corrija a causa
Não apenas o sintoma.
Passo 9 — Execute regressão
Teste:
cenário que falhou;
cenário normal;
limites;
arquivo vazio;
valores máximos;
dados inválidos;
retorno de chamadas;
erros de SQL.
Passo 10 — Documente
Registre:
Sintoma
Causa raiz
Evidência
Correção
Teste
Prevenção
Procedimento de recuperação
Essa documentação transforma um incidente em conhecimento institucional.
16. Como prevenir ABENDs
Um programa robusto não é aquele que nunca encontra erros. É aquele que detecta condições anormais antes que elas se transformem em corrupção ou interrupção descontrolada.
Use validações:
IF CAMPO-NUMERICO IS NUMERIC
COMPUTE WS-RESULTADO = CAMPO-NUMERICO * 10
ELSE
DISPLAY 'CAMPO INVALIDO: ' CAMPO-NUMERICO
PERFORM TRATAR-REGISTRO-INVALIDO
END-IF
Verifique file status:
SELECT ARQ-CLIENTE
ASSIGN TO CLIENTE
ORGANIZATION IS SEQUENTIAL
FILE STATUS IS WS-FILE-STATUS.
Após operações:
OPEN INPUT ARQ-CLIENTE
IF WS-FILE-STATUS NOT = '00'
DISPLAY 'ERRO NO OPEN: ' WS-FILE-STATUS
MOVE 12 TO RETURN-CODE
GOBACK
END-IF
Use ON SIZE ERROR, avalie SQLCODE, valide limites de tabelas, inicialize estruturas e trate retornos de programas chamados.
Também utilize opções de compilação e ferramentas de teste que ajudem a detectar:
subscritos inválidos;
dados não inicializados;
incompatibilidade de parâmetros;
problemas de storage;
caminhos não testados.
17. Curiosidades da sala de evidências
Curiosidade 1 — Um S0C7 pode ser causado por um erro de tabela
O programa acessa uma posição inexistente, sobrescreve um campo COMP-3 e só cai minutos depois, quando tenta somá-lo.
O ABEND é decimal, mas a causa raiz é endereçamento.
Curiosidade 2 — Reiniciar pode mudar o sintoma
Depois de um restart, o programa pode processar registros diferentes, usar outro volume, encontrar locks distintos ou carregar outra versão.
O fato de funcionar após reinício não prova que o problema desapareceu.
Curiosidade 3 — Um User ABEND pode ser sinal de maturidade
Aplicações críticas preferem encerrar de maneira controlada a continuar com dados inconsistentes.
Curiosidade 4 — O registro culpado pode ter sido criado meses antes
Um dado inválido pode permanecer armazenado até que uma nova rotina tente utilizá-lo numericamente.
Curiosidade 5 — O programa que caiu pode ser inocente
Ele apenas recebeu dados corrompidos de um sistema anterior.
No CSI, isso seria o equivalente a encontrar a arma na mão de alguém que apenas a recolheu do chão.
18. O easter egg do laboratório
Em determinado episódio imaginário de CSI z/OS: Las Vegas Batch Unit, a equipe encontra um cartão perfurado escondido atrás de um terminal 3270.
No cartão, está escrito:
IDENTIFICATION DIVISION.
PROGRAM-ID. GILGRISS.
Ao lado, uma mensagem:
THE EVIDENCE NEVER LIES.
THE DATA SOMETIMES DOES.
A primeira frase homenageia a filosofia investigativa da série.
A segunda pertence ao mundo COBOL.
Porque bytes não possuem intenção, mas podem possuir:
layout errado;
sinal inválido;
codificação inesperada;
origem desconhecida;
tamanho incompatível;
histórico comprometido.
O dado não “mente” no sentido humano. Porém, quando interpretado por um layout incorreto, ele pode contar uma história completamente falsa.
Conclusão — O ABEND não é o fim
Para o iniciante, o ABEND parece uma parede.
Para o profissional experiente, ele é uma porta.
Atrás dela estão:
a arquitetura do z/OS;
a representação de dados COBOL;
o funcionamento do processador;
o Language Environment;
a alocação de datasets;
a integração com DB2;
a execução transacional no CICS;
os mecanismos do IMS;
a segurança RACF;
os processos de compilação, link-edit e implantação.
Aprender ABENDs não significa decorar listas.
Significa aprender a investigar sistemas.
Quando aparecer um S0C7, não pergunte apenas:
“Qual campo está inválido?”
Pergunte também:
“Como ele ficou inválido?”
Quando aparecer um S806, não pergunte apenas:
“Onde está o módulo?”
Pergunte:
“Qual biblioteca deveria fornecer esse módulo e por que a cadeia de implantação não o disponibilizou?”
Quando surgir um S322, não aumente imediatamente o parâmetro TIME.
Pergunte:
“O volume realmente cresceu ou o programa deixou de avançar?”
O programador comum procura uma correção rápida.
O investigador mainframe procura a sequência completa dos acontecimentos.
E quando as luzes do data center diminuem, os jobs aguardam na fila e um código hexadecimal aparece no monitor, lembre-se:
O ABEND não é a conclusão da história. É o momento em que o sistema começa a contar o que aconteceu.
No laboratório Bellacosa Mainframe, cada byte deixa uma marca.
Cada dump preserva uma cena.
Cada registrador guarda uma posição.
Cada mensagem possui um horário.
E cada programa que terminou de forma anormal ainda tem muito a dizer — desde que o investigador saiba onde procurar.
