Translate

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

sábado, 7 de março de 2026

🔥 O método de 60 segundos para descobrir por que um Job ABENDOU (sem abrir nenhum dataset)

 

Bellacosa Mainframe ensina como encontrar um abend em menos de 60 segundos

🔥 O método de 60 segundos para descobrir por que um Job ABENDOU (sem abrir nenhum dataset)

No dia a dia de produção em IBM z/OS, quando um job ABEND acontece, muitos profissionais iniciantes começam abrindo datasets, dumps ou navegando em dezenas de telas.

Operadores experientes fazem diferente.

Eles usam um método rápido baseado no SDSF que normalmente revela a causa do problema em menos de 60 segundos — muitas vezes sem abrir nenhum dataset.

Este é um dos truques clássicos que circulam em grandes ambientes de produção.

☕ Bem-vindo a mais um Um Café no Bellacosa Mainframe.


🧠 A lógica por trás do método

Quando um job falha, o sistema sempre deixa rastros em três lugares principais:

1️⃣ Status do job
2️⃣ Mensagens do JES
3️⃣ Mensagens do sistema (SYSLOG)

O segredo é seguir a ordem correta.


⚡ Passo 1 — Abrir o SDSF e localizar o Job

Entre no SDSF:

SDSF

Depois vá ao painel de status:

ST

Agora filtre rapidamente:

PREFIX JOBNAME

Exemplo:

PREFIX PAYROLL*

Isso reduz a lista para apenas os jobs relevantes.


🔍 Passo 2 — Identificar rapidamente o ABEND

Na coluna RC / CC / ABEND você verá algo como:

ABEND=S0C7
ABEND=S322
ABEND=SB37

Cada código já indica uma pista importante.

Exemplos clássicos:

ABENDSignificado
S0C7erro de dados numéricos
S0C4violação de memória
S322timeout (tempo excedido)
SB37falta de espaço em dataset

Mas ainda não sabemos onde aconteceu.


📜 Passo 3 — Usar o “?” do SDSF (o atalho mais poderoso)

Digite ? ao lado do job.

Isso abre imediatamente o Job Output:

  • JESMSGLG

  • JESJCL

  • JESYSMSG

Sem abrir nenhum dataset manualmente.


🎯 Passo 4 — Ir direto ao JESYSMSG

O arquivo JESYSMSG quase sempre contém a causa.

Procure por linhas como:

IEF450I JOBNAME ABENDED S0C7

ou

IEC030I B37-04

ou

CSV031I LIBRARY NOT FOUND

Em muitos casos a causa já aparece claramente aqui.


🔎 Passo 5 — Confirmar no SYSLOG

Agora abra o log do sistema:

LOG

e procure pelo JobID:

FIND JOB12345

Isso mostra mensagens do sistema relacionadas ao job.

Exemplos:

IEC141I DATA SET NOT FOUND

ou

IEF861I STEP TERMINATED DUE TO ERROR

⚡ Resultado: diagnóstico em menos de 60 segundos

Seguindo apenas estes passos:

SDSF
ST
PREFIX jobname
?
JESYSMSG
LOG
FIND jobid

Normalmente você já descobre:

✔ o step que falhou
✔ o tipo de erro
✔ a mensagem exata do sistema

Sem abrir nenhum dataset manualmente.


🧠 Exemplo real de diagnóstico

Imagine um job que termina assim:

ABEND=SB37

Seguindo o método:

No JESYSMSG aparece:

IEC030I B37-04 ON SYSDA

Diagnóstico imediato:

👉 Dataset ficou sem espaço.

Nenhuma investigação adicional necessária.


💡 A regra de ouro dos operadores experientes

Nos grandes datacenters existe uma regra não escrita:

“Se você abriu dataset antes de olhar o JESYSMSG, começou a investigação do jeito errado.”

80% dos problemas podem ser identificados apenas com SDSF.


☕ Conclusão

O segredo não está em ferramentas complexas.

Está em saber onde olhar primeiro.

Dominar o SDSF significa:

  • investigar incidentes mais rápido

  • reduzir tempo de troubleshooting

  • ganhar confiança em ambientes de produção

E isso separa operadores iniciantes de profissionais experientes no mundo mainframe.


https://www.linkedin.com/pulse/o-m%C3%A9todo-de-60-segundos-para-descobrir-por-que-um-job-bellacosa-jxhkf

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.


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988