Translate

Mostrar mensagens com a etiqueta CEEDUMP. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta CEEDUMP. Mostrar todas as mensagens

segunda-feira, 13 de março de 2023

Os Holocrons Esquecidos do Tratamento de Erros no IBM Z – O Lado Sombrio das Exceções - Parte III

 

Bellacosa Mainframe e o tratamento de erros em cobol parte III



EXCEPTION/ERROR Procedures em COBOL

Os Holocrons Esquecidos do Tratamento de Erros no IBM Z

Parte 3 – O Lado Sombrio das Exceções

LE, CICS HANDLE CONDITION, ON EXCEPTION, CEEHDLR, Dumps, Fault Analyzer, IPCS e os Monstros do S0C4

Por Bellacosa Mainframe


"Um Padawan trata FILE STATUS. Um Cavaleiro domina DECLARATIVES. Um Mestre Bellacosa sabe conversar com o Language Environment enquanto observa um CEEDUMP às três horas da manhã."

Mestre Bellacosa Sysprog Jedi


Introdução

Na Parte 1 aprendemos:

  • DECLARATIVES

  • USE AFTER ERROR PROCEDURE

  • Tratamento centralizado

Na Parte 2 aprendemos:

  • FILE STATUS

  • VSAM

  • Retry

  • Logging

  • Frameworks corporativos

Mas existe um outro universo.

Muito mais sombrio.

Muito mais antigo.

Muito mais poderoso.

O universo chamado:

Language Environment

Ou simplesmente.

LE


O que é LE?

LE significa.

Language Environment.


É o runtime comum.

De várias linguagens.

No z/OS.

Suporta.

COBOL

PL/I

C

C++

Metal C

Assembler


Visualmente.

Programa COBOL

↓

Language Environment

↓

z/OS

↓

Hardware

O que acontece quando ocorre um erro?

Exemplo.

DIVIDE A

BY B

B.

Vale.

Zero.


Resultado.

Exceção.


LE detecta.


Avalia.

Condition Handler.


Decide.

Continuar.

Terminar.

Gerar dump.


Condition Handling

LE trabalha.

Com condições.


Exemplos.

CEE3207S

CEE0813S

CEE0198S

CEE3250C


Muito conhecidos.


Exemplo

Overflow.

COMPUTE TOTAL

=

99999999999999

*

99999999999999

LE.

Captura.


Mensagem.

CEE3207S

ON SIZE ERROR

Primeira linha.

De defesa.


Exemplo.

ADD A TO B

ON SIZE ERROR

DISPLAY 'ERRO'

Muito elegante.


ON EXCEPTION

Outro mecanismo.


JSON.

JSON PARSE

WS-JSON


ON EXCEPTION


DISPLAY 'ERRO'

XML.

Também.


STRING.

Também.


CEEHDLR

Aqui começa.

A magia.


Pouquíssimos conhecem.


CEEHDLR.

Permite.

Criar.

Condition Handlers.

Personalizados.


Arquitetura.

Erro


↓

LE


↓

CEEHDLR


↓

Handler


↓

Aplicação

Muito sofisticado.


CEESGL

Outra API.


Sinalização.

Condições.


Pouco usada.


Muito poderosa.


Exemplo conceitual

CALL 'CEEHDLR'

Handler.

Registrado.


Toda exceção.

Passa.

Por ele.


CICS HANDLE CONDITION

Outro Holocron.

Muito famoso.


Exemplo.

EXEC CICS

HANDLE CONDITION

NOTFND(ERRO1)

ENDFILE(ERRO2)

END-EXEC

Muito elegante.


CICS.

Intercepta.

Condição.


Transfere.

Controle.


HANDLE ABEND

Mais poderoso.


Exemplo.

EXEC CICS

HANDLE ABEND

LABEL(ABEND1)

END-EXEC

Padawan.

Protegido.


S0C4

O rei.

Dos monstros.


Endereço inválido.


Overlay.


Heap.

Corrompido.


Pointer.

Errado.


Resultado.

SOC4.


SOC7

Muito comum.


Decimal inválido.


Exemplo.

Campo.

COMP-3.

Corrompido.


SOC7.


S0CB

Divide.

Por zero.


Muito clássico.


S878

Storage.

Exhausted.


Leak.

Heap.


Muito desagradável.


Dumps

O arqueólogo.

Do IBM Z.

Ama.

Dumps.


Tipos.

SYSUDUMP

CEEDUMP

SYSABEND

SNAP


CEEDUMP

Excelente.

Mostra.

Heap.

Stack.

Pointers.

Condition Handlers.


Muito útil.


Fault Analyzer

Fantástico.


Exemplo.

Mostra.

Linha COBOL.

Offset.

Variável.

Registradores.


Tempo.

Economizado.

Enorme.


Abend-AID

Outro clássico.


Muito amado.

Por bancos.


IPCS

O Holocron Supremo.


Ferramenta.

Dos sysprogs.


Comandos.

VERBX

IPCS

LIST

TRACE


Pouco amigável.


Muito poderosa.


Como funciona na memória?

LE mantém.

Stack.

Heap.

Tabela.

Condition Handlers.


Visualmente.

Stack


↓


Programa



↓


LE



↓


Handler

Erro.


LE consulta.

Tabela.


Executa.

Handler.


Performance

Excelente.


Handlers.

Quase.

Zero overhead.


Só atuam.

Quando necessário.


Segurança

Importante.


Permite.

Mascarar.

Informações.

Sensíveis.


Evita.

Expor.

Dados.

No dump.


Muito útil.

LGPD.

PCI.

SOX.


Framework Bellacosa

Arquitetura.

Erro


↓

LE


↓

CEEHDLR


↓

Logger


↓

MQ


↓

Splunk


↓

OpenTelemetry


↓

SOC Team

Muito moderna.


Curiosidades

Muitos bancos.

Possuem.

Condition Handlers.

Criados.

Há décadas.


Funcionam.

Até hoje.


Curiosidade 2

Grande parte.

Dos SOC4.

Não acontece.

Em teste.


Aparece.

Produção.


Sexta-feira.


23h58.


Naturalmente.


Curiosidade 3

Muitos desenvolvedores.

Nunca.

Viram.

CEEHDLR.


Mesmo após.

20 anos.

COBOL.


Bellacosa Best Practices

Sempre.

ON EXCEPTION.


Sempre.

ON SIZE ERROR.


Sempre.

Fault Analyzer.


Sempre.

CEEDUMP.


Sempre.

Logging.


Nunca.

Ignorar.

SOC7.


Nunca.

Ignorar.

SOC4.


Documente.

Tudo.


O Conselho do Mestre Bellacosa

Os erros mais perigosos do IBM Z raramente são aqueles previstos nos requisitos.

Eles vivem escondidos.

Nos registradores.

Nos heaps.

Nas pilhas.

Nos ponteiros esquecidos.

Nos buffers corrompidos.

E aguardam pacientemente o fechamento contábil do mês para se manifestar.

O jovem Padawan aprende FILE STATUS.

O Cavaleiro domina DECLARATIVES.

Mas o Mestre Bellacosa conversa com o Language Environment, lê um CEEDUMP como quem consulta um antigo manuscrito e utiliza CEEHDLR para interceptar exceções antes que elas se transformem em monstros capazes de derrubar uma galáxia inteira de jobs batch.

Porque talvez a maior lição desta jornada seja simples.

Um programa COBOL verdadeiramente robusto não é aquele que nunca falha.

É aquele que sabe exatamente o que fazer quando inevitavelmente a falha decide aparecer.


Continua na Parte 4

O Mestre Bellacosa – Frameworks Corporativos de Tratamento de Erros, MQ Dead Letter Queue, APIs JSON, OpenTelemetry, Splunk, Elastic, Observabilidade e a Arte Jedi de Transformar Falhas em Conhecimento.


sexta-feira, 26 de novembro de 2021

ABEND sem Mistérios

 

Bellacosa Mainframe conheça a serie Abends sem misterios na Stack Mainframe

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios

A Série Definitiva para Todo Programador COBOL Padawan Entender Como os Grandes Bancos Investigam, Corrigem e Evitam Falhas no IBM Z

Existe um momento na carreira de praticamente todo programador COBOL em que aparece uma mensagem inesperada no SDSF:

ABEND=S0C7

Ou talvez um S0C4, um S013, um ASRA ou um misterioso U4038.

Para quem está começando, essas siglas parecem códigos secretos do Mainframe. Mas, na realidade, elas representam um dos maiores mecanismos de proteção, diagnóstico e confiabilidade já criados na computação corporativa.

Foi pensando nisso que nasceu a série ABEND sem Mistérios, publicada no Um Café no Bellacosa Mainframe.

Ao longo de oito capítulos, percorremos uma jornada que começa na explicação dos conceitos básicos e termina mostrando como os maiores bancos do mundo utilizam observabilidade, Inteligência Artificial, engenharia de confiabilidade e boas práticas de desenvolvimento para reduzir drasticamente a ocorrência de ABENDs em produção.

Mais do que ensinar códigos de erro, esta série procura desenvolver uma forma de pensar. O objetivo é transformar um Programador Padawan em um profissional capaz de investigar problemas de maneira estruturada, compreender o funcionamento interno do IBM Z e construir aplicações cada vez mais robustas.

☕ Parte I — O que é um ABEND?

O primeiro capítulo apresenta os conceitos fundamentais.

Você entenderá o papel do programa COBOL, do JCL, do JES2, do SDSF e do z/OS durante a execução de um JOB, além de conhecer os principais ABENDs encontrados no dia a dia, como S0C1, S0C4, S0C7, S013, S322, S806, SB37, SD37, SE37, U4038, ASRA, AICA, APCT e muitos outros.

É a base necessária para compreender toda a série.

https://eljefemidnightlunch.blogspot.com/2021/03/o-guia-definitivo-para-um-programador.html


☕ Parte II — Como Investigar um ABEND

Depois de entender o que é um ABEND, chega a hora de aprender a investigá-lo.

Neste capítulo mostramos como utilizar JESMSGLG, JESYSMSG, SYSOUT, CEEDUMP, SYSMDUMP, offsets, traceback e outras ferramentas essenciais para localizar a verdadeira origem de um problema.

Você aprenderá que o ABEND quase nunca representa a causa, mas apenas o sintoma.

https://eljefemidnightlunch.blogspot.com/2021/04/abend-sem-misterios-parte-2.html


☕ Parte III — Engenharia de Diagnóstico

Aqui o foco deixa de ser apenas corrigir erros.

Você aprenderá técnicas de investigação utilizadas por especialistas, incluindo Root Cause Analysis (RCA), os Cinco Porquês, análise de dumps com IPCS, IBM Fault Analyzer, Abend-AID e a importância da engenharia baseada em evidências.

É o momento em que o programador começa a pensar como um analista de produção.,

https://eljefemidnightlunch.blogspot.com/2021/05/abend-sem-misterios-parte-3.html


☕ Parte IV — O que Acontece Dentro do IBM Z

Um dos capítulos mais técnicos da série.

Entramos na arquitetura interna do IBM Z para entender como a CPU executa instruções, o papel do PSW, dos registradores, da Storage, dos TCBs, RBs, Address Spaces e do Supervisor do z/OS quando um Program Interrupt ocorre.

Depois dessa leitura, um ABEND deixa de ser um mistério e passa a fazer parte de uma arquitetura extremamente sofisticada.

https://eljefemidnightlunch.blogspot.com/2021/06/abend-sem-misterios-parte-iv.html



☕ Parte V — O Estado da Arte da Investigação

O Mainframe moderno vai muito além de dumps.

Neste capítulo mostramos como os grandes bancos utilizam Observabilidade, SMF, Workload Manager (WLM), Site Reliability Engineering (SRE), ChatOps, automação e Inteligência Artificial para detectar, correlacionar e prevenir incidentes antes que eles afetem os clientes.

É uma visão atual da engenharia de software no IBM Z.

https://eljefemidnightlunch.blogspot.com/2021/07/abend-sem-misterios-parte-v.html


☕ Parte VI — O Grande Laboratório de ABENDs

A teoria dá lugar à prática.

Você encontrará uma sequência de laboratórios para reproduzir, investigar e corrigir os principais ABENDs em ambiente controlado.

São exercícios envolvendo S0C7, S0C4, S013, S806, SB37, S322, além de boas práticas para construir um ambiente de aprendizado semelhante ao utilizado em treinamentos profissionais.

https://eljefemidnightlunch.blogspot.com/2021/08/abend-sem-misterios-parte-vi.html


☕ Parte VII — Os Erros Mais Comuns dos Programadores COBOL

Quase nenhum ABEND nasce por acaso.

Neste capítulo reunimos os erros mais frequentes encontrados em projetos corporativos envolvendo validação de dados, FILE STATUS, SQLCODE, RESP, índices, REDEFINES, integração entre programas, JCL, infraestrutura e processos.

Também mostramos como os grandes bancos evitam esses problemas por meio de programação defensiva, revisão de código, testes automatizados e padrões de desenvolvimento.

https://eljefemidnightlunch.blogspot.com/2021/09/abend-sem-misterios-parte-vii.html


☕ Parte VIII — Muito Além do ABEND

A série termina mostrando que dominar ABENDs é apenas uma etapa da evolução profissional.

Discutimos como pensam os grandes especialistas em Mainframe, a importância da curiosidade técnica, da documentação, da melhoria contínua, da observabilidade, da integração com tecnologias modernas e da formação de novos profissionais.

Mais do que aprender a resolver erros, o objetivo passa a ser construir sistemas onde eles se tornem cada vez mais raros.

https://eljefemidnightlunch.blogspot.com/2021/10/abend-sem-misterios-parte-viii.html


Conclusão

Ao final desta série, fica claro que um ABEND nunca deve ser encarado apenas como uma mensagem de erro.

Ele representa uma oportunidade para compreender melhor a aplicação, aprimorar processos, fortalecer a qualidade do software e evoluir como profissional.

Se você está iniciando sua jornada no universo IBM Z ou deseja aprofundar seus conhecimentos em COBOL, JCL, CICS, z/OS e engenharia de software corporativa, esta coleção foi escrita para servir como um guia permanente de consulta.

Prepare seu café, abra o SDSF, acompanhe cada capítulo e descubra que, por trás de cada ABEND, existe uma das maiores lições que o Mainframe pode oferecer.


sexta-feira, 24 de setembro de 2021

ABEND sem Mistérios — Parte VII

 

Bellacosa Mainframe em abend sem misterio parte vii

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios — Parte VII

Os 100 Erros Mais Comuns dos Programadores COBOL que Acabam Gerando ABENDs (e Como os Grandes Bancos Evitam Cada Um Deles)

"Quase nenhum ABEND nasce de um único erro. Ele costuma ser o resultado de pequenas decisões aparentemente inocentes que foram se acumulando até encontrar o momento perfeito para falhar."


Introdução

Depois de entender:

  • o que é um ABEND;

  • como investigá-lo;

  • como analisar dumps;

  • como funciona a arquitetura do IBM Z;

  • como utilizar observabilidade;

  • como criar laboratórios de treinamento;

chegamos a uma pergunta extremamente importante.

Por que tantos ABENDs continuam acontecendo?

A resposta surpreende muita gente.

Na maioria das vezes, não é por causa do compilador.

Nem do JCL.

Nem do z/OS.

Nem do CICS.

Muito menos do hardware IBM Z.

Na prática, a maior parte dos incidentes nasce de pequenos erros de desenvolvimento que poderiam ter sido evitados.

É exatamente por isso que grandes bancos investem tanto em padrões de programação, revisões técnicas, testes automatizados e engenharia preventiva.

Neste artigo reunimos os erros mais frequentes encontrados em projetos COBOL corporativos e as práticas utilizadas para evitá-los.


O verdadeiro custo de um pequeno erro

Imagine uma variável.

01 WS-SALDO PIC 9(09)V99.

Agora imagine que um arquivo carregue:

12A4500

Nenhum cliente percebe.

Nenhum operador percebe.

Nenhum batch falha imediatamente.

Horas depois...

COMPUTE

↓

S0C7

↓

Rollback

↓

Fila parada

↓

Chamado de Produção

O problema começou muito antes do ABEND.


Os cinco grupos de erros

Praticamente todos os incidentes podem ser classificados em cinco categorias.

Dados

↓

Lógica

↓

Integração

↓

Infraestrutura

↓

Processos

Vamos explorar cada uma delas.


Grupo 1 — Erros de Dados

São disparadamente os mais comuns.


Erro 1

Não validar campos numéricos.

Resultado.

S0C7.

Boa prática.

Sempre utilizar:

IF campo NUMERIC

Erro 2

Assumir que um arquivo sempre virá correto.

Arquivos mudam.

Layouts evoluem.

Campos chegam em branco.

Sistemas fornecedores falham.

Nunca confie cegamente na entrada.


Erro 3

Ignorar FILE STATUS.

Uma simples instrução OPEN pode falhar.

Sem tratamento adequado,

o programa continua executando até produzir consequências mais graves.


Erro 4

Ignorar SQLCODE.

O SELECT pode não encontrar registros.

O UPDATE pode falhar.

O COMMIT pode ser rejeitado.

Sempre teste SQLCODE.


Erro 5

Ignorar RESP e RESP2 no CICS.

Esses códigos são equivalentes ao SQLCODE do ambiente transacional.

Não tratá-los significa dirigir sem painel de instrumentos.


Grupo 2 — Erros de Lógica


Erro 6

PERFORM infinito.

Resultado.

S322

Boa prática.

Toda repetição deve possuir condição clara de encerramento.


Erro 7

Índices fora do OCCURS.

Principal causa de inúmeros S0C4.

Sempre valide limites.


Erro 8

Variáveis não inicializadas.

Nunca suponha que memória contém zeros.

Use INITIALIZE quando fizer sentido e inicialize explicitamente áreas críticas.


Erro 9

REDEFINES utilizado sem documentação.

REDEFINES é poderoso.

Mas também é uma das maiores fontes de confusão em sistemas antigos.


Erro 10

Uso excessivo de GO TO.

Quanto maior o número de desvios,

mais difícil torna-se reproduzir problemas.


Grupo 3 — Integração


Erro 11

Copybooks incompatíveis.

Programa A espera:

100 bytes

Programa B envia:

120 bytes

Resultado.

S0C4.


Erro 12

CALL USING incompatível.

Mudança em parâmetros sem recompilar todos os módulos.

Problema extremamente comum em aplicações legadas.


Erro 13

Layouts de arquivos desatualizados.

Uma alteração aparentemente simples pode afetar dezenas de programas.


Erro 14

Interfaces sem versionamento.

Grandes bancos tratam contratos de interface como código-fonte.


Grupo 4 — Infraestrutura


Erro 15

STEPLIB incorreta.

Resultado.

S806

Erro 16

DCB incompatível.

Resultado.

S013

Erro 17

Datasets pequenos.

Resultado.

SB37

SD37

SE37

Erro 18

TIME insuficiente.

Resultado.

S322

Erro 19

Catálogo inconsistente.

Nem sempre o problema está na aplicação.


Grupo 5 — Engenharia de Software

Aqui aparecem os erros mais caros.


Erro 20

Falta de logs.

Sem informações,

investigar torna-se muito mais difícil.


Erro 21

Ausência de documentação.

Quando apenas uma pessoa entende um programa,

o risco operacional aumenta significativamente.


Erro 22

Não reproduzir o incidente.

Corrigir "no escuro" costuma gerar novos problemas.


Erro 23

Não escrever testes.

A correção resolve o incidente atual,

mas ninguém garante que outro desenvolvedor não reintroduzirá o mesmo defeito.


Erro 24

Não documentar a causa raiz.

Todo incidente importante deveria gerar conhecimento.


Os erros que quase nunca aparecem nos livros

Alguns problemas são extremamente frequentes na vida real.

Por exemplo.

Alteração de layout sem avisar outras equipes.

Mudança de copybook.

Programa recompilado parcialmente.

Ambiente inconsistente.

Produção.

ABEND.

Tecnicamente,

ninguém escreveu código errado.

O problema foi comunicação.


O perigo das suposições

Um excelente programador desconfia de tudo.

Pergunta:

O arquivo realmente existe?

O retorno foi validado?

A variável foi inicializada?

O parâmetro chegou corretamente?

A transação ainda está instalada?

Essa postura reduz enormemente os incidentes.


Como pensam os grandes bancos

Muitas empresas utilizam listas de verificação antes do deploy.

Exemplo.

  • SQLCODE tratado?

  • FILE STATUS tratado?

  • RESP tratado?

  • Índices validados?

  • Logs suficientes?

  • Testes executados?

  • Revisão realizada?

  • Plano de rollback pronto?

Esse checklist evita inúmeros problemas.


O princípio da programação defensiva

Programação defensiva significa assumir que algo pode dar errado.

Em vez de escrever:

ADD WS-VALOR TO TOTAL

O profissional escreve:

IF WS-VALOR NUMERIC
    ADD WS-VALOR TO TOTAL
ELSE
    PERFORM TRATAR-ERRO
END-IF

O objetivo não é tornar o código maior.

É torná-lo mais confiável.


A importância da revisão de código

Um desenvolvedor acostuma-se com seu próprio código.

Por isso revisões entre colegas são tão valiosas.

Muitas falhas simples são descobertas antes mesmo dos testes.

Revisar código não é fiscalizar pessoas.

É proteger o sistema.


Testes automatizados no Mainframe

Cada vez mais equipes utilizam:

  • IBM Developer for z/OS;

  • IBM Test Accelerator;

  • ZUnit;

  • Jenkins;

  • GitHub Actions;

  • UrbanCode Deploy;

  • Ansible.

A ideia é simples.

Sempre que uma alteração ocorrer,

os principais cenários são executados automaticamente.

Assim, regressões são identificadas antes da produção.


Os dez mandamentos do Programador COBOL

  1. Nunca confie nos dados de entrada.

  2. Sempre trate retornos do sistema.

  3. Valide limites de tabelas.

  4. Documente alterações importantes.

  5. Escreva logs úteis.

  6. Faça revisões de código.

  7. Teste cenários de erro, não apenas os de sucesso.

  8. Automatize sempre que possível.

  9. Investigue antes de corrigir.

  10. Compartilhe conhecimento com a equipe.


O ciclo dos incidentes

Os sistemas mais maduros seguem um ciclo contínuo.

Erro

↓

ABEND

↓

Investigação

↓

Root Cause

↓

Correção

↓

Teste

↓

Documentação

↓

Automação

↓

Novo Padrão

↓

Menos ABENDs

Cada incidente fortalece a organização.


O Programador Padawan e o Especialista

O Padawan pergunta:

"Como elimino este S0C7?"

O especialista pergunta:

"Como impedir que qualquer programa desta empresa gere esse mesmo S0C7 novamente?"

Essa diferença de perspectiva muda completamente a qualidade do software.


Construindo uma cultura de qualidade

As organizações mais bem-sucedidas não dependem de heróis que resolvem incidentes às três da manhã.

Elas constroem processos que tornam esses incidentes cada vez mais raros.

Isso inclui:

  • padrões de codificação;

  • revisão por pares;

  • integração contínua;

  • testes automatizados;

  • observabilidade;

  • documentação;

  • treinamento constante.

Quando essas práticas amadurecem, o número de ABENDs em produção tende a cair de forma consistente.


Conclusão

Os ABENDs não surgem do nada. Eles são o reflexo da qualidade das decisões tomadas ao longo do ciclo de desenvolvimento.

Cada variável validada, cada SQLCODE tratado, cada FILE STATUS verificado, cada revisão de código e cada teste automatizado representam pequenas barreiras que impedem que um erro simples evolua para um incidente crítico.

Os grandes bancos sabem disso há décadas. Por essa razão, investem muito mais em prevenção do que em correção. A investigação continua sendo importante, mas seu verdadeiro objetivo é produzir aprendizado, melhorar processos e reduzir a probabilidade de novos incidentes.

O Programador Padawan que compreender essa filosofia deixará de ver o ABEND como um inimigo. Passará a enxergá-lo como um indicador da saúde do sistema e uma oportunidade de tornar suas aplicações mais seguras, previsíveis e resilientes.

Porque, no fim das contas, a melhor investigação é aquela que um dia deixa de ser necessária.


terça-feira, 24 de agosto de 2021

ABEND sem Mistérios — Parte VI

 

Bellacosa Mainframe em abend sem misterios parte vi

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios — Parte VI

O Grande Laboratório de ABENDs: Como Reproduzir, Investigar e Corrigir os Principais Erros do Mainframe Passo a Passo

"O conhecimento começa quando entendemos um ABEND. A experiência começa quando conseguimos reproduzi-lo. A maestria nasce quando sabemos evitá-lo."


Introdução

Até aqui, percorremos uma longa jornada.

Aprendemos:

  • o que é um ABEND;

  • como investigá-lo;

  • como analisar dumps;

  • como funciona a arquitetura do IBM Z;

  • como os grandes bancos utilizam observabilidade e Inteligência Artificial para prevenir incidentes.

Agora chegou a hora de colocar a mão na massa.

Existe uma diferença enorme entre ler sobre um ABEND e vê-lo acontecer diante dos seus olhos.

É exatamente assim que os grandes especialistas aprendem.

Eles não estudam apenas teoria.

Eles criam laboratórios.

Provocam erros.

Quebram programas.

Analisam dumps.

Corrigem.

Repetem.

Depois de algum tempo, passam a reconhecer um S0C7 da mesma forma que um médico reconhece uma doença comum.

Esta parte apresenta uma metodologia de treinamento que pode ser utilizada tanto em ambientes educacionais quanto em laboratórios corporativos.

O objetivo não é apenas reproduzir erros, mas compreender profundamente o motivo pelo qual eles acontecem.


Por que criar ABENDs de propósito?

Parece estranho.

Durante toda a carreira tentamos evitar erros.

Então por que provocá-los?

Porque um ambiente de testes é o lugar mais seguro para aprender.

Imagine um piloto de avião.

Antes de transportar passageiros ele treina:

  • falha hidráulica;

  • pane elétrica;

  • incêndio;

  • perda de motor.

No Mainframe fazemos o mesmo.

Treinamos quando ninguém está sendo afetado.


Como montar um laboratório de ABENDs

Você não precisa de um ambiente gigantesco.

Um pequeno sistema já é suficiente.

Por exemplo:

TSO

↓

ISPF

↓

Enterprise COBOL

↓

JCL

↓

SDSF

↓

VSAM

↓

Arquivos Sequenciais

Se houver CICS e Db2, melhor ainda.

Mas não são obrigatórios.


Regra número um

Nunca provoque ABENDs em Produção.

Parece óbvio.

Mas vale repetir.

Ambientes de treinamento existem exatamente para isso.


Exercício 1 — O primeiro S0C7

Objetivo:

Compreender Data Exception.

Crie uma variável:

01 WS-VALOR PIC 9(5).

Depois carregue:

12A45

Agora execute:

ADD 1 TO WS-VALOR.

Resultado esperado:

S0C7

O que observar?

Antes de corrigir.

Analise:

  • JESMSGLG;

  • SYSOUT;

  • CEEDUMP;

  • Offset;

  • Linha COBOL.

Depois responda:

Por que aconteceu?


Correção

Validação.

IF WS-VALOR NUMERIC
    ADD 1 TO WS-VALOR
ELSE
    DISPLAY 'DADO INVALIDO'
END-IF

Observe que o objetivo nunca foi "tirar o S0C7".

Foi impedir que dados inválidos chegassem ao cálculo.


Exercício 2 — O clássico S0C4

Monte uma tabela.

OCCURS 10 TIMES

Agora faça:

Índice = 25

Resultado.

Muito provavelmente.

S0C4

Investigação

Perguntas importantes.

O índice foi validado?

Quem alterou seu valor?

Existe PERFORM VARYING correto?

Existe INITIALIZE?


Exercício 3 — S013

Altere propositalmente:

  • LRECL

  • RECFM

Ou utilize um DDNAME incorreto.

Resultado.

IEC141I

S013

Agora investigue:

O problema está no COBOL?

Ou no JCL?

Essa diferença é fundamental.


Exercício 4 — S806

Compile normalmente.

Depois altere a STEPLIB.

Ou remova o Load Module.

Resultado.

S806

Aprendizado.

Nem todo ABEND vem do programa.


Exercício 5 — SB37

Crie um arquivo pequeno.

Depois grave milhares de registros.

O dataset ficará sem espaço.

Agora observe:

  • mensagens IEC;

  • SMS;

  • SYSOUT.


Exercício 6 — S322

Crie um loop infinito.

Exemplo.

PERFORM A
UNTIL 1 = 2

Configure TIME no JOB.

Resultado.

S322

Agora analise:

Quanto tempo demorou?

Como o sistema detectou?


Exercício 7 — FILE STATUS

Este talvez seja o exercício mais importante.

Leia um arquivo inexistente.

Sem verificar:

FILE STATUS

Depois repita verificando.

Perceba como muitos ABENDs desaparecem quando tratamos corretamente o retorno das operações.


Exercício 8 — SQLCODE

Mesmo sem gerar ABEND.

Faça:

SELECT

UPDATE

DELETE

ignorando SQLCODE.

Depois implemente tratamento.

É assim que sistemas robustos são construídos.


Exercício 9 — RESP no CICS

Execute comandos CICS.

Ignore RESP.

Depois implemente.

Você perceberá como muitos problemas são detectados antes de se transformarem em ASRA.


Exercício 10 — CEEDUMP

Escolha qualquer ABEND.

Agora tente responder apenas utilizando o CEEDUMP.

Onde ocorreu?

Qual variável estava errada?

Qual programa chamou aquele módulo?

Qual era o conteúdo da memória?

Esse exercício desenvolve enorme capacidade de investigação.


O Diário de ABENDs

Uma prática comum entre especialistas é manter um diário técnico.

Por exemplo.

DataABENDCausaSoluçãoComo evitar
10/07S0C7Campo inválidoValidaçãoIF NUMERIC
11/07S013LRECL erradoCorrigir JCLRevisão

Depois de alguns anos,

esse documento torna-se uma verdadeira biblioteca de conhecimento.


Aprendendo a formular hipóteses

Quando um incidente acontece,

não saia alterando o programa.

Primeiro formule hipóteses.

Por exemplo.

Hipótese 1

O arquivo veio corrompido.

Hipótese 2

O índice saiu do OCCURS.

Hipótese 3

O parâmetro foi passado incorretamente.

Depois procure evidências.

Esse é exatamente o método científico.


A regra de ouro da depuração

Nunca altere duas coisas ao mesmo tempo.

Imagine:

Você modifica:

  • JCL;

  • COBOL;

  • Copybook;

  • Parâmetros.

Depois funciona.

Qual alteração resolveu?

Você nunca saberá.

Faça mudanças pequenas.

Teste.

Observe.

Repita.


Simule incidentes completos

Depois de dominar os exercícios individuais,

crie cenários.

Exemplo.

O arquivo chega com layout errado.

Programa gera S0C7.

Batch seguinte não executa.

Relatório não é produzido.

Usuário abre chamado.

Agora reproduza toda a cadeia.

Essa abordagem aproxima o treinamento da realidade.


Automatizando laboratórios

Grandes empresas possuem ambientes capazes de:

  • executar centenas de testes;

  • gerar dumps automaticamente;

  • validar RC;

  • comparar resultados;

  • produzir relatórios.

Hoje isso pode ser integrado com:

  • Git;

  • Jenkins;

  • GitHub Actions;

  • IBM Dependency Based Build;

  • UrbanCode Deploy;

  • Ansible;

  • Zowe CLI.

Quanto mais automatizado o laboratório, mais rapidamente regressões são detectadas.


Como um mentor ensina ABENDs

Observe a diferença.

Professor comum:

"Esse é um S0C7."

Mentor experiente:

"Vamos provocar um S0C7, analisar o dump, descobrir a causa, corrigir o código e escrever um teste para garantir que ele nunca volte."

A segunda abordagem produz conhecimento duradouro.


O desafio dos grandes bancos

Os melhores programas não são aqueles que nunca falham.

São aqueles que:

  • detectam problemas rapidamente;

  • registram informações úteis;

  • facilitam o diagnóstico;

  • recuperam-se quando possível;

  • protegem os dados.

É exatamente esse pensamento que diferencia aplicações críticas.


Monte seu próprio catálogo

Ao longo da carreira, registre:

  • mensagens IEC;

  • mensagens IEF;

  • mensagens DFH;

  • SQLCODEs frequentes;

  • FILE STATUS;

  • RESP/RESP2;

  • ABENDs;

  • soluções.

Com o tempo você construirá um material que nenhum curso consegue fornecer.


Um roteiro de treinamento de 30 dias

Semana 1

  • S0C7

  • S0C4

  • S013

Semana 2

  • S806

  • SB37

  • S322

Semana 3

  • CEEDUMP

  • SYSMDUMP

  • JESMSGLG

  • JESYSMSG

Semana 4

  • IPCS

  • Fault Analyzer

  • Abend-AID

  • Root Cause Analysis

Ao final do mês, um Padawan terá experimentado dezenas de cenários que muitos profissionais só encontram após anos de trabalho.


Os cinco hábitos dos especialistas

  1. Nunca ignoram uma mensagem do sistema.

  2. Reproduzem o erro antes de corrigi-lo.

  3. Documentam tudo o que aprendem.

  4. Automatizam testes sempre que possível.

  5. Transformam cada incidente em conhecimento compartilhado.


Conclusão

Um ABEND não é um inimigo. Ele é um professor extremamente exigente.

Cada S0C7 ensina a validar dados. Cada S0C4 reforça a importância da memória e dos limites das tabelas. Cada S013 lembra que uma aplicação depende tanto do JCL quanto do código COBOL. Cada S806 mostra que uma compilação bem-sucedida não garante uma execução correta.

Os profissionais mais respeitados do mundo Mainframe não nasceram sabendo interpretar dumps ou localizar offsets em poucos minutos. Eles desenvolveram essa habilidade por meio de prática deliberada, repetindo investigações, registrando descobertas e aprendendo com cada incidente.

É exatamente por isso que um laboratório de ABENDs vale tanto. Nele, o erro deixa de representar um risco para o negócio e passa a ser uma ferramenta de aprendizado. E quando um Programador Padawan aprende a provocar, investigar, corrigir e prevenir os principais ABENDs em um ambiente controlado, ele chega muito mais preparado para enfrentar os desafios da produção.

No IBM Z, experiência não significa apenas tempo de carreira. Significa quantidade de problemas compreendidos, causas identificadas e conhecimento compartilhado. É assim que se forma um verdadeiro especialista em Mainframe.


sexta-feira, 18 de junho de 2021

ABEND sem Mistérios — Parte IV

 

Bellacosa Mainframe e o abend sem misterios parte IV

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios — Parte IV

O que Acontece Dentro do IBM Z Quando um ABEND Ocorre: Registradores, Memória, TCB, RB e a Jornada de uma Instrução até a CPU

"Para o programador, um ABEND acontece quando o programa para. Para o processador, ele acontece quando uma única instrução viola uma regra da arquitetura."


Introdução

Até agora aprendemos:

  • o que é um ABEND;

  • como investigá-lo;

  • como descobrir sua causa raiz.

Agora vamos entrar em um território que poucos programadores COBOL exploram.

Vamos olhar o problema pelo ponto de vista do próprio IBM Z.

Imagine que você pudesse entrar dentro do processador durante um S0C4.

O que estaria acontecendo?

Quem decidiu interromper seu programa?

Quem chamou o dump?

Como a CPU sabe exatamente qual instrução falhou?

Por que o sistema consegue informar o endereço exato onde tudo aconteceu?

A resposta está na arquitetura do IBM Z.


O IBM Z nunca executa COBOL

Essa é uma das primeiras grandes descobertas.

O processador IBM Z não conhece COBOL.

Nem PL/I.

Nem C.

Nem Java.

Muito menos JCL.

A CPU conhece apenas uma linguagem:

Machine Instructions

Ou seja,

milhões de instruções binárias.


O caminho de um programa

Quando escrevemos:

ADD WS-VALOR
 TO WS-TOTAL.

O compilador transforma isso em dezenas de instruções de máquina.

O fluxo verdadeiro é:

COBOL

↓

Enterprise COBOL Compiler

↓

Assembler

↓

Objeto

↓

Binder

↓

Load Module

↓

Machine Instructions

↓

CPU IBM Z

Quando ocorre um S0C7,

não foi a instrução ADD que falhou.

Foi uma instrução de máquina gerada pelo compilador.


A CPU trabalha uma instrução por vez

Imagine:

READ

MOVE

ADD

WRITE

Para nós parecem quatro comandos.

Para o processador,

podem representar centenas de instruções.

Cada instrução passa por etapas.

Buscar

↓

Decodificar

↓

Executar

↓

Gravar Resultado

Esse processo acontece bilhões de vezes por segundo.


Quando nasce um S0C4

Imagine uma instrução tentando acessar um endereço inexistente.

A CPU verifica:

Endereço

↓

Área permitida?

↓

SIM

↓

Executa

ou

Endereço

↓

Área permitida?

↓

NÃO

↓

Program Interrupt

Nesse instante,

o S0C4 começa a nascer.


O Program Interrupt

O processador possui dezenas de tipos de interrupções.

Algumas delas:

  • Protection Exception

  • Addressing Exception

  • Operation Exception

  • Data Exception

  • Overflow

  • Fixed Point Divide

Quando ocorre uma dessas situações,

a CPU interrompe imediatamente a instrução.

Ela não pergunta ao programa se deseja continuar.


O papel do PSW

O Program Status Word é um dos componentes mais importantes da arquitetura IBM Z.

Ele contém informações como:

  • endereço da próxima instrução;

  • modo de execução;

  • chave de proteção;

  • condição da CPU;

  • máscara de interrupções.

É praticamente o "painel de controle" do processador.

Sempre que ocorre um ABEND,

o PSW é salvo.

É por isso que conseguimos descobrir exatamente onde tudo aconteceu.


Registradores: a mesa de trabalho da CPU

Imagine um marceneiro.

Sobre sua bancada existem:

  • régua;

  • lápis;

  • parafusos;

  • martelo.

A CPU possui algo parecido.

São os registradores.

Ela utiliza esses espaços para guardar:

  • endereços;

  • parâmetros;

  • resultados;

  • ponteiros;

  • contadores.

Quando um dump é produzido,

todos eles são preservados.


O famoso R15

Quem trabalha com COBOL logo aprende sobre o registrador R15.

Ele normalmente contém:

  • endereço inicial de programas;

  • códigos de retorno;

  • informações importantes durante CALLs.

Em muitas análises,

o primeiro registrador observado é justamente ele.


O que é Storage?

Quando dizemos:

WS-NOME

PIC X(30)

Essa variável ocupa memória.

No IBM Z essa memória recebe o nome de:

Storage

É nela que vivem:

  • variáveis COBOL;

  • buffers;

  • tabelas;

  • áreas de comunicação;

  • parâmetros.

Um S0C4 quase sempre está relacionado ao uso incorreto dessa Storage.


O conceito de Address Space

Uma dúvida comum dos iniciantes é:

"O programa acessa toda a memória do computador?"

Não.

Cada JOB ou região CICS executa em um Address Space.

Pense em um apartamento.

Cada morador possui:

  • sala;

  • cozinha;

  • quarto.

Um apartamento não invade o outro.

Da mesma forma,

um programa não pode acessar livremente a memória de outro Address Space.


O que é um TCB?

Agora chegamos a um dos componentes mais importantes do z/OS.

TCB significa:

Task Control Block

Toda tarefa possui um.

Ele contém informações fundamentais sobre a execução:

  • registradores;

  • PSW;

  • prioridade;

  • estado;

  • ponteiros;

  • RB atual.

Sem o TCB,

o sistema não saberia quem está executando.


Imagine um crachá

Imagine uma empresa.

Cada funcionário possui um crachá.

No IBM Z,

o TCB funciona exatamente assim.

Ele identifica aquela tarefa perante o sistema operacional.


O RB (Request Block)

Durante uma chamada de serviço,

o sistema cria um RB.

Ele registra:

  • quem chamou;

  • qual serviço foi solicitado;

  • qual rotina será executada;

  • para onde retornar.

Em uma investigação profunda,

a sequência de RBs ajuda a reconstruir a história da execução.


O Dispatcher

Quem decide qual programa utilizará a CPU?

Não é o JES2.

Não é o COBOL.

É o Dispatcher do z/OS.

Ele distribui tempo de processamento entre milhares de tarefas.

Imagine um maestro regendo uma orquestra.

Cada músico toca por alguns instantes.

Depois outro assume.

Tudo acontece tão rapidamente que parece simultâneo.


O papel do Supervisor

Quando ocorre um Program Interrupt,

a CPU entrega o controle ao Supervisor do sistema operacional.

Ele analisa:

  • tipo da exceção;

  • PSW;

  • registradores;

  • TCB;

  • RB;

  • contexto da tarefa.

Depois decide:

  • gerar dump;

  • emitir mensagens;

  • encerrar a tarefa.

É nesse momento que nasce oficialmente o ABEND.


Como nasce um Dump

O Dump não aparece por mágica.

O sistema percorre diversas estruturas.

Ele salva:

  • registradores;

  • memória;

  • TCB;

  • RB;

  • PSA;

  • LSQA;

  • CSA;

  • pilhas;

  • módulos carregados;

  • áreas do LE.

Tudo isso permite que o problema seja investigado posteriormente.


A pilha de chamadas

Quando fazemos:

Programa A

↓

CALL B

↓

CALL C

↓

CALL D

O sistema mantém uma pilha.

Ela registra:

  • quem chamou;

  • quem foi chamado;

  • para onde retornar.

O CEEDUMP utiliza essa pilha para montar o famoso Traceback.


Por que um Offset é tão importante?

Quando o compilador gera o Load Module,

as linhas do COBOL deixam de existir.

O executável conhece apenas endereços.

Por isso o dump mostra:

Offset

0000A3F2

Ferramentas como IBM Fault Analyzer, Abend-AID e IDz fazem o caminho inverso: relacionam esse offset ao programa-fonte, permitindo localizar a instrução COBOL correspondente.


O papel do Binder

Muitos iniciantes acreditam que a compilação termina quando o compilador gera o objeto.

Na verdade,

existe outra etapa fundamental.

O Binder (antigo Link-Editor) reúne:

  • módulos objeto;

  • bibliotecas;

  • sub-rotinas;

  • Language Environment.

O resultado é o Load Module, que será executado pelo z/OS.

Sem essa etapa,

não existe programa executável.


E no CICS?

Dentro do CICS tudo continua acontecendo.

A diferença é que existe outra camada.

Terminal

↓

Task CICS

↓

Dispatcher CICS

↓

Programa COBOL

↓

Language Environment

↓

CPU

Quando ocorre um ASRA,

o CICS captura o Program Interrupt,

gera suas mensagens

e encerra a Task.


O que realmente vê um SysProg?

Enquanto o desenvolvedor observa:

S0C7

O SysProg costuma enxergar algo muito maior.

Ele analisa:

  • PSW;

  • TCB;

  • RB;

  • ASCB;

  • SRB;

  • Dispatcher;

  • WLM;

  • armazenamento;

  • interrupções;

  • módulos do sistema.

São duas perspectivas diferentes do mesmo problema.


Curiosidades da arquitetura IBM Z

  • O IBM Z possui mecanismos de proteção de memória extremamente sofisticados, fundamentais para executar milhares de workloads simultaneamente com segurança.

  • Um único sistema pode manter milhares de Tasks ativas, cada uma com seu próprio contexto de execução.

  • O PSW é salvo e restaurado continuamente durante trocas de contexto entre tarefas.

  • Grande parte da confiabilidade do IBM Z vem justamente da capacidade de detectar exceções e interromper apenas a tarefa problemática, preservando o restante do sistema.


O caminho completo de um ABEND

Programa COBOL

↓

Compilador

↓

Load Module

↓

CPU executa instrução

↓

Program Interrupt

↓

Supervisor z/OS

↓

Análise do contexto

↓

Dump

↓

Mensagens

↓

ABEND

↓

SDSF

↓

Investigação

↓

Correção

↓

Aprendizado

Conclusão

Quando compreendemos a arquitetura interna do IBM Z, os ABENDs deixam de ser mensagens misteriosas e passam a ser eventos perfeitamente explicáveis.

Um S0C4 não é "azar". Um S0C7 não é "capricho do compilador". Eles são a consequência direta de mecanismos de proteção cuidadosamente projetados para preservar a integridade do sistema.

Essa é uma das grandes diferenças do Mainframe: cada interrupção, cada registrador salvo, cada PSW capturado e cada dump gerado fazem parte de uma arquitetura construída para ser observável, previsível e extremamente resiliente.

O Programador Padawan que entende essa jornada deixa de enxergar apenas o código COBOL e passa a compreender como hardware, sistema operacional, compilador e aplicação trabalham em perfeita sintonia. É nesse momento que ele começa a pensar como um verdadeiro especialista em IBM Z.


quarta-feira, 26 de maio de 2021

ABEND sem Mistérios — Parte III

 

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.

segunda-feira, 19 de abril de 2021

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.

domingo, 10 de março de 2019

☕💥 A Jornada do Padawan COBOL – Parte 3 Desvendando o Universo dos CALLs no Mainframe

 

Bellacosa Mainframe apresenta o CALL em Cobol Pàrte III

☕💥 A Jornada do Padawan COBOL – Parte 3

Desvendando o Universo dos CALLs no Mainframe

RETURN-CODE, GOBACK, Dumps, CEEDUMP, IPCS e os Segredos Jedi do Troubleshooting

Ou como descobrir que um simples S0C4 pode transformar uma madrugada tranquila em uma aventura digna de um RPG de nível 99

Por Vagner Bellacosa – Bellacosa Mainframe


O momento em que o Padawan encontra seu primeiro ABEND

Todo desenvolvedor Mainframe possui uma história.

Normalmente começa assim:

Segunda-feira.

02h47.

Janela de produção.

Telefone toca.

Gerente pergunta:

O batch das contas correntes caiu.

Você responde:

Qual erro?

Resposta:

S0C4.

Silêncio.

Você pega café.

Abre SDSF.

Começa a aventura.


O universo do RETURN-CODE

Uma das coisas mais elegantes do COBOL é a comunicação entre programas.

Nem tudo precisa explodir com um ABEND.

Podemos retornar informações.

Exemplo:

Programa Chamador

CALL 'VALIDA'

USING WS-CLIENTE


IF RETURN-CODE NOT = 0

DISPLAY "ERRO"

END-IF

Subprograma

IF CPF-INVALIDO

MOVE 8 TO RETURN-CODE

GOBACK

END-IF

Convenção mais utilizada

RCSignificado
0Sucesso
4Aviso
8Erro
12Erro Grave
16Fatal

Exemplo elegante

Subprograma

EVALUATE TRUE


WHEN CLIENTE-INATIVO

MOVE 4 TO RETURN-CODE


WHEN CPF-INVALIDO

MOVE 8 TO RETURN-CODE


WHEN SALDO-NEGATIVO

MOVE 12 TO RETURN-CODE


WHEN OTHER

MOVE 0 TO RETURN-CODE


END-EVALUATE

Por que isso é importante?

Evita ABEND.

Permite tratamento.

Sistema continua vivo.


GOBACK vs EXIT PROGRAM

Padawan adora copiar.

Mestre entende diferença.


STOP RUN

STOP RUN

Finaliza tudo.

Acabou.

Batch morre.


GOBACK

GOBACK

Retorna.

Educado.

Seguro.


EXIT PROGRAM

Muito usado em subprogramas.

EXIT PROGRAM

Volta ao chamador.


O preferido da IBM

GOBACK

Sempre.


O grande vilão

S0C4

O Darth Vader dos ABENDS.


O que significa?

Violação de armazenamento.


Tentou acessar

memória inválida.


Exemplo

CALL 'ROTINA'

USING WS-NOME

ROTINA

espera

LK-NOME


LK-ID


LK-DATA

Recebe apenas um.

Kaboom.


Como ocorre

CPU acessa

endereço inexistente.


Exemplo

00000000

ou

FFFFFFFF

Crash.


S0C7

Outro inimigo.


Exemplo

Campo contém

ABC

Programa espera

999

Código

ADD 1 TO WS-VALOR

ABEND.


S806

Muito comum.

Programa não encontrado.


Verificar

STEPLIB

JOBLIB

LNKLST

APF


U4038

Erro do LE.

Language Environment.


Normalmente

problemas de parâmetros.

Heap.

Stack.

Storage.


O CEEDUMP

Ferramenta dos Mestres.

Poucos usam.

Deveriam usar.

Muito.


Compilar

TEST

ou

LIST

Executar

gera

CEEDUMP


Possui

Stack

Registers

Storage

Offsets

Variáveis

Call Stack


Exemplo

MAIN


↓

VALIDA


↓

CPFCHK


↓

FORMATA


↓

ABEND

Melhor que adivinhar.


IPCS

Ferramenta lendária.

Poucos dominam.


Permite

abrir dump.

Examinar memória.

Ver registradores.

Offsets.

TCB.

PSW.


O segredo do Offset

Mensagem

IGZ0035S


OFFSET X'01A2'

LISTING

0001A2 MOVE WS-ID

Achou erro.


Capturando problemas

Técnica Bellacosa 1

Log antes.

DISPLAY 'ENTRADA'


DISPLAY WS-ID


DISPLAY WS-NOME

Técnica 2

Log depois.

DISPLAY 'RETORNO'

Técnica 3

Interface versionada

05 LK-VERSAO.


PIC X(02).

Técnica 4

Validar ponteiros

IF PTR = NULL

DISPLAY 'ERRO'

END-IF

Técnica 5

Checksum

Estruturas críticas.


Técnica 6

Tamanho esperado

IF LENGTH OF LK-AREA


NOT = 256

Descobrindo loops

CALL

A

B

C

A

B

C


CPU

100%


Usar

SMF

RMF

Strobe

APA


Detectando corrupção

Antes

MOVE WS-BLOCO TO WS-BKP

Depois

Comparar.

IF WS-BKP


NOT = WS-BLOCO

Monitorando produção

SMF 30

SMF 110

RMF


Dica Bellacosa

Nunca faça:

MOVE 16 TO RETURN-CODE
CONTINUE

E ignore.


Faça

IF RETURN-CODE > 0

DISPLAY MSG


PERFORM LOG


END-IF

Easter Egg Mainframe

Existe em praticamente todos os bancos:

Programa

GENCALL

ou

UTIL0001

Possui:

7000 linhas.

300 CALLs.

120 IFs.

47 GO TO.

3 autores.

Última alteração:

Documentação:

Nenhuma.


Produção:

Executa há vinte anos.


Ninguém mexe.


É conhecido como:

O Boss Final do Mainframe™


Checklist Jedi de Troubleshooting

✅ Verificar RETURN-CODE

✅ Conferir parâmetros

✅ Conferir ordem

✅ Conferir tamanho

✅ Conferir LISTING

✅ Conferir CEEDUMP

✅ Conferir Offset

✅ Conferir STEPLIB

✅ Conferir Binder

✅ Conferir RENT

✅ Conferir Work-Storage

✅ Conferir Local-Storage

✅ Conferir ponteiros

✅ Conferir versão da interface

✅ Conferir quantidade de cafés consumidos


A Filosofia Jedi do CALL – Parte 3

O Padawan iniciante acredita:

"O programa caiu."

O desenvolvedor intermediário pensa:

"Preciso achar a linha."

O Mestre Mainframe sabe:

O programa nunca cai sozinho.

Ele deixa pistas.

Offsets.

PSW.

CEEDUMP.

Registers.

SMF.

IPCS.

RETURN-CODE.

Storage.

Call Stack.

E o verdadeiro Jedi do z/OS aprende que depurar um problema em produção não é apenas corrigir um bug.

É fazer arqueologia digital em sistemas que processam bilhões de transações por dia, compreender contratos invisíveis entre programas escritos ao longo de décadas e transformar um assustador S0C4 das 3 da manhã em apenas mais uma história para contar tomando um café no Bellacosa Mainframe.


Na Parte 4, o Padawan enfrentará o conteúdo avançado: Reentrância, RENT/NORENT, Thread Safety, HEAP, STACK, CICS, LE, AMODE 31/64, otimização extrema de CALLs, microbenchmarks e os segredos utilizados pelos arquitetos de sistemas IBM Z para executar milhões de chamadas por segundo com segurança.


sábado, 24 de fevereiro de 2007

O que é COBOL Bug Trap e Captura de ABEND?

Bellacosa Mainframe o que é Bug Trap em Cobol


O que é COBOL Bug Trap e Captura de ABEND?

Em ambientes Mainframe, especialmente em aplicações críticas, um dos maiores desafios é descobrir rapidamente:

Por que o programa falhou?
Onde ocorreu o erro?
Qual variável causou o problema?

Para isso existem mecanismos conhecidos como:

Bug Trap

e

Captura de ABEND


O que é um ABEND?

ABEND significa:

Abnormal End

Ou seja:

Finalização Anormal

O programa termina devido a um erro.


Exemplos de ABENDs comuns

ABENDCausa
S0C7Erro de dados numéricos
S0C4Violação de memória
S806Programa não encontrado
SB37Falta de espaço
U4038Erro definido pela aplicação
ASRAExceção em CICS

Exemplo de S0C7

MOVE 'ABC' TO WS-VALOR-NUM
ADD 1 TO WS-VALOR-NUM

Resultado:

S0C7

O Problema

Sem diagnóstico adequado você recebe apenas:

JOB ABENDED

e precisa descobrir:

Qual campo?
Qual linha?
Qual programa?

O que é Bug Trap?

Bug Trap é uma técnica ou ferramenta que captura informações detalhadas antes do programa terminar.

Objetivo:

Transformar um ABEND misterioso
em um erro fácil de analisar

O que o Bug Trap captura?

  • Nome do programa

  • Data e hora

  • Parágrafo COBOL

  • Variáveis

  • SQLCODE

  • CICS EIBRESP

  • Chave VSAM

  • Dados recebidos

  • Stack de chamadas


Fluxo Simplificado

Erro
 ↓
Bug Trap
 ↓
Captura informações
 ↓
Gera relatório
 ↓
ABEND

Exemplo

Sem Bug Trap:

S0C7

Com Bug Trap:

PROGRAMA = FIN001

PARAGRAFO = CALCULA-JUROS

CAMPO = WS-SALDO

VALOR = ABCDEF

ABEND = S0C7

Captura de ABEND no COBOL

Uma prática comum é criar rotinas padronizadas.


Exemplo

IF SQLCODE NOT = 0

   PERFORM TRATA-ERRO

END-IF

Rotina de Tratamento

TRATA-ERRO.

DISPLAY 'ERRO SQL'

DISPLAY SQLCODE

MOVE 16 TO RETURN-CODE

STOP RUN.

Capturando FILE STATUS

Muito comum em arquivos.


READ ARQCLIENTE

IF WS-FS NOT = '00'

   DISPLAY 'ERRO LEITURA'

   DISPLAY WS-FS

END-IF

Captura de SQLCODE

Programas DB2.


EXEC SQL

   SELECT ...

END-EXEC

IF SQLCODE NOT = 0

   DISPLAY SQLCODE

END-IF

Captura de CICS

Programas online.


EXEC CICS

   READ FILE(...)

   RESP(WS-RESP)

END-EXEC

IF WS-RESP NOT = DFHRESP(NORMAL)

   DISPLAY WS-RESP

END-IF

Uso de Declaratives

COBOL possui tratamento nativo.


DECLARATIVES.

ARQ-ERROR SECTION.

USE AFTER STANDARD ERROR PROCEDURE
ON ARQCLIENTE.

DISPLAY 'ERRO ARQUIVO'.

END DECLARATIVES.

LE Condition Handler

No ambiente IBM Language Environment (LE).


Pode interceptar:

S0C7
S0C4
Overflow
Underflow

Ferramentas modernas utilizam LE para coletar:

  • Call Stack

  • Variáveis

  • Offset

  • PSW


Ferramentas Comerciais


IBM Fault Analyzer

Uma das mais utilizadas.

Captura automaticamente:

  • ABEND

  • Variáveis

  • Fonte COBOL

  • Call Stack


IBM Application Performance Analyzer

Auxilia análise de execução.


Abend-AID

Muito popular em bancos.

Produz relatórios detalhados.


Xpediter

Debug e análise de falhas.


Exemplo Fault Analyzer

Após um S0C7:

ABEND S0C7

PROGRAMA:
FIN001

PARAGRAFO:
CALCULA-PARCELA

CAMPO:
WS-VALOR

CONTEUDO:
ABC123

Exemplo Abend-AID

Mostra:

Linha COBOL

Variáveis

Offsets

Call Stack

Storage

Captura Manual (Estilo Bellacosa)

Uma prática comum é criar um copybook corporativo.


COPY LOGERRO.

Sempre que ocorrer erro:

PERFORM REGISTRA-ERRO

Grava:

Programa

Parágrafo

Usuário

Data

Hora

SQLCODE

File Status

Mensagem

Exemplo de Log

PROGRAMA=FIN001

PARAGRAFO=ATUALIZA-SALDO

SQLCODE=-911

USUARIO=BELLA01

DATA=20260801

HORA=14:35:21

Captura de Call Stack

Especialmente importante em:

CALL
CALL
CALL
CALL

Exemplo:

MAIN
 ↓
CALCULO
 ↓
JUROS
 ↓
VALIDA

Erro ocorreu em:

VALIDA

Captura de Dumps

Ferramentas analisam:

SYSUDUMP
SYSABEND
CEEDUMP

CEEDUMP

Muito usado com Language Environment.

Contém:

  • variáveis;

  • registradores;

  • call stack;

  • offsets.


Boas Práticas

✅ Sempre verificar FILE STATUS

✅ Sempre verificar SQLCODE

✅ Tratar RESP em CICS

✅ Gerar logs padronizados

✅ Produzir CEEDUMP

✅ Utilizar Fault Analyzer ou Abend-AID

✅ Registrar contexto do erro


Curiosidade

Em muitos bancos, mais de 90% dos incidentes COBOL são resolvidos sem abrir um dump completo porque as rotinas de Bug Trap já registram:

Programa
Parágrafo
Campo
Valor inválido
Usuário
Transação

permitindo localizar a causa raiz em poucos minutos.


Resumo Rápido

ConceitoFunção
ABENDFinalização anormal
S0C7Erro numérico
S0C4Violação memória
Bug TrapCaptura contexto do erro
CEEDUMPDump do LE
SYSUDUMPDump sistema
SQLCODEErro DB2
FILE STATUSErro arquivo
RESPErro CICS
Fault AnalyzerDiagnóstico IBM
Abend-AIDDiagnóstico avançado
XpediterDebug

Conclusão

Bug Trap é o conjunto de técnicas e ferramentas utilizadas para capturar informações detalhadas antes ou durante um ABEND. Em ambientes COBOL corporativos, ele é essencial para acelerar a análise de incidentes, identificar a causa raiz e reduzir drasticamente o tempo de diagnóstico de erros em aplicações Batch, CICS, IMS e DB2.