Bellacosa Mainframe e a lista de abends

☕🔥 Guia Completo — ABENDs Clássicos do IBM OS/VS e z/OS

Excelente observação!
No resumo anterior realmente ficaram faltando vários ABENDs importantes da lista original do artigo histórico do OS/VS. Agora segue a versão completa, revisada e expandida, incluindo TODOS os códigos mencionados no documento.

---

🔥 S013 — OPEN ERROR / DCB ERROR

Mensagem comum

IEC141I

O que significa

Falha ao abrir dataset.

Principais causas

• BLKSIZE incompatível

• RECFM incorreto

• LRECL errado

• Membro inexistente em PDS

Muito comum em

• SORT

• COBOL batch

• IDCAMS

---

🔥 S0C1 — OPERATION EXCEPTION

O que significa

Execução de instrução inválida.

Causas

• Overlay de memória

• Programa corrompido

• Executar área de dados como código

• Compilação/link incorreto

---

🔥 S0C4 — PROTECTION EXCEPTION

O clássico absoluto do z/OS

O que significa

Acesso inválido à memória.

Causas comuns

• Subscript fora do limite

• Ponteiro inválido

• Tabela ultrapassada

• LINKAGE SECTION incorreta

---

🔥 S0C5 — ADDRESSING EXCEPTION

O que significa

Tentativa de acessar endereço inexistente.

Muito comum em

• CALLs errados

• Parâmetros incompatíveis

• Ponteiros inválidos

---

🔥 S0C7 — DATA EXCEPTION

O ABEND mais famoso do COBOL

O que significa

Campo numérico contém valor inválido.

Exemplos clássicos

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

Principais causas

• Campo COMP-3 corrompido

• Dados não numéricos

• Index fora da tabela

• Working-storage sem inicialização

---

🔥 S106 — LINK/LOAD ERROR

O que significa

Falha durante LOAD ou LINK.

Causas

• Biblioteca incorreta

• Módulo inconsistente

• Problema de disco

---

🔥 S213 — DATASET NOT FOUND

Mensagem comum

IEC143I

O que significa

Dataset inexistente.

Causas

• DSNAME errado

• Dataset não catalogado

• VOL=SER incorreto

---

🔥 S222 — JOB CANCELADO

Mensagem comum

IEF301I

O que significa

Operador cancelou o job.

Normalmente ocorre por

• Loop infinito

• Job preso

• Alto consumo

---

🔥 S2F3 — SYSTEM FAILURE

O que significa

Falha do sistema operacional durante execução.

Causas

• Crash do sistema

• IPL

• Problema interno do z/OS

Procedimento

• Reexecutar o job

• Verificar logs do sistema

---

🔥 S322 — TIME EXCEEDED

O que significa

Job excedeu o tempo permitido.

Muito comum em

• Loops infinitos

• SQL sem índice

• SORT gigantes

Exemplo

TIME=1

---

🔥 S613 — TAPE I/O ERROR

Mensagem comum

IEC147I

O que significa

Erro de I/O em fita magnética.

Causas

• Fita mal posicionada

• Multi-volume incorreto

• Problema físico na fita

---

🔥 S722 — SYSOUT LIMIT EXCEEDED

O que significa

Quantidade de linhas impressas excedeu limite.

Muito comum em

• LOOP com DISPLAY

• Relatórios infinitos

• Dumps excessivos

---

🔥 S804 — INSUFFICIENT VIRTUAL STORAGE

O que significa

Falta de memória virtual.

Causas

• REGION pequena

• Programa gigante

• Uso excessivo de tabelas

Exemplo

REGION=512K

---

🔥 S806 — MODULE NOT FOUND

O loader não encontrou o módulo

Causas

• STEPLIB errada

• LOADLIB ausente

• Nome incorreto do programa

Mensagem clássica

CSV003I REQUESTED MODULE NOT FOUND

---

🔥 S80A — STORAGE SHORTAGE

O que significa

Complemento do S804.

Causa principal

Falta de memória virtual disponível.

---

🔥 S813 — TAPE LABEL ERROR

Mensagem comum

IEC149I

O que significa

Nome do dataset na fita não bate com DD.

Causas

• LABEL incorreto

• DSNAME errado

• Volume errado

---

🔥 S913 — RACF SECURITY VIOLATION

Mensagem comum

IEC150I

O que significa

Acesso negado pelo RACF.

Muito comum em

• Produção

• Db2

• GDGs

• VSAM corporativo

---

🔥 SA13 — END OF TAPE / FILE NOT FOUND

Mensagem comum

IEC151I

O que significa

Arquivo não encontrado na fita.

Causas

• LABEL incorreto

• Número sequencial errado

• Volume incorreto

---

🔥 SB37 — OUT OF SPACE

Mensagem comum

IEC030I

O que significa

Dataset ficou sem espaço.

Causas

• Espaço secundário insuficiente

• Muitas extents

• Volume cheio

---

🔥 SD37 — NO SECONDARY SPACE

Mensagem comum

IEC031I

O que significa

Acabou espaço primário e não existe secondary allocation.

Exemplo clássico

SPACE=(CYL,(10,0))

---

🔥 SE37 — EXTENT LIMIT EXCEEDED

Mensagem comum

IEC032I

O que significa

Dataset atingiu limite máximo de extents.

Muito comum em

• PDS antigos

• SORT gigantes

• Arquivos temporários

---

☕🔥 Os ABENDs Mais Icônicos da História do Mainframe

ABEND	Significado
S0C7	Data Exception
S0C4	Protection Exception
S806	Module Not Found
S913	RACF Violation
SB37	Dataset sem espaço
S322	Timeout
S213	Dataset não encontrado

---

☕ Curiosidade Histórica

Nos tempos do:

• OS/360

• OS/VS1

• OS/VS2

• MVS/XA

os operadores praticamente decoravam os ABENDs “na raça”.

Muitos programadores COBOL antigos conseguiam identificar o erro apenas olhando:

IEF450I

ou:

IEC141I

sem precisar abrir dump.

Isso virou quase uma “linguagem secreta” do mundo mainframe.

🔥 VOCÊ USA z/OS TODO DIA… MAS NUNCA VIU ISSO AQUI! O “ESQUELETO INVISÍVEL” DO SYSTEM SERVICES QUE DECIDE SEU JOB VIVE OU MORRE 💀

 

Bellacosa Mainframe fala sobre z/OS system Service Structure

🔥 VOCÊ USA z/OS TODO DIA… MAS NUNCA VIU ISSO AQUI!
O “ESQUELETO INVISÍVEL” DO SYSTEM SERVICES QUE DECIDE SEU JOB VIVE OU MORRE 💀

---

Se você é dev COBOL raiz, daqueles que já tomou S0C7 no café da manhã e resolveu com dump na unha… segura essa:

👉 Existe uma camada no z/OS que você usa o tempo todo…
👉 Mas quase ninguém entende de verdade…
👉 E ela decide TUDO — do I/O ao ABEND.

Bem-vindo à z/OS System Services Structure.

---

🧠 O QUE É ESSA TAL DE STRUCTURE?

Pensa no z/OS como uma cidade:

• Você (COBOL) → é o cidadão
• JCL → é o pedido formal
• JES2 → é o correio
• E o System Services?
  👉 É a prefeitura, polícia, energia, trânsito e bombeiros… TUDO JUNTO.

É a estrutura que fornece serviços fundamentais como:

• Gerenciamento de tarefas (Task Management)
• Comunicação entre programas
• Gerenciamento de memória
• I/O (entrada/saída)
• Tratamento de erros (ABENDs 👀)

---

⚙️ A ESTRUTURA NA PRÁTICA (SEM MIMIMI)

Aqui entra o coração técnico que muita gente ignora:

🔹 Control Blocks (os “documentos secretos”)

• TCB (Task Control Block) → representa uma task
• ASCB (Address Space Control Block) → representa o espaço de endereçamento
• RB (Request Block) → encadeamento de chamadas

💡 Easter egg:
Se você já viu um dump com “TCB=…” e ignorou…
👉 você literalmente ignorou o “RG” da sua task.

---

🔹 Dispatcher (o maestro invisível)

• Decide qual task roda
• Gerencia prioridade
• Alterna contexto

💬 Comentário Bellacosa-style:

“Se seu programa está ‘lento’, talvez o problema não seja o COBOL…
é o dispatcher dizendo: calma campeão, tem fila 😎”

---

🔹 SVC (Supervisor Call)

• Porta de entrada para serviços do sistema
• Tudo passa por aqui

👉 Quando seu COBOL faz I/O, quem resolve não é ele…
é o z/OS via SVC.

💡 Curiosidade:
SVC é tipo syscall no Linux… só que com terno e gravata 👔

---

💥 ONDE ISSO TE PEGA (E VOCÊ NEM SABIA)

Se liga nesses cenários:

• ABEND estranho sem causa aparente
• Programa “travando” sem loop
• I/O lento do nada
• Problemas intermitentes

👉 90% das vezes… está ligado ao System Services, não ao seu código.

---

🧩 COMO TUDO SE CONECTA (VISÃO RAIZ)

Fluxo simplificado:

1. Seu COBOL executa
2. Precisa de recurso (I/O, memória, etc)
3. Chama um serviço via SVC
4. System Services aciona control blocks
5. Dispatcher decide quando executar
6. Resultado volta pra sua aplicação

👉 Se algo falhar nesse caminho…
💥 ABEND na sua cara

---

🧠 GUIA DE ESTUDO (MODO GUERREIRO MAINFRAME)

Se você quer sair do nível “codador” e virar engenheiro de verdade, estude isso:

📚 Ordem sugerida:

1. Address Spaces (ASID, ASCB)
2. TCB e SRB
3. Dispatcher e prioridades
4. SVCs mais comuns
5. Gerenciamento de memória (GETMAIN/FREEMAIN)
6. Dump reading (IPCS)

---

🧪 Dica prática (ouro puro 💰)

Pegue um dump real e procure:

• TCB atual
• PSW
• Última SVC chamada

👉 Isso é mais valioso que 10 cursos teóricos.

---

🕵️‍♂️ EASTER EGGS QUE POUCA GENTE SABE

💣 1. COBOL NÃO CONTROLA NADA
Quem controla é o z/OS. Seu programa só pede.

---

💣 2. ABEND NÃO É ERRO — É DECISÃO
O sistema decidiu parar você.
👉 E sempre tem motivo.

---

💣 3. TUDO É BLOCO ENCADEADO
z/OS é basicamente um grande “linked list corporativo” 😂

---

💣 4. PERFORMANCE NÃO É SÓ CÓDIGO
Pode ser prioridade de TCB, dispatching, ou contenção.

---

🚀 FRASE PRA LEVAR PRA VIDA (E PRO LINKEDIN 😎)

“Quem não entende System Services no z/OS…
não depura problema — só apaga incêndio.”

---

🔥 CONCLUSÃO (SEM ENROLAR)

Se você:

• Só olha código COBOL → você vê a superfície
• Entende System Services → você vê o sistema inteiro

👉 E é aqui que mora a diferença entre:

• Programador
  vs
• Especialista em Mainframe

 

Bellacosa Mainframe fala sobre dumps

🔥 SEU PROGRAMA ABENDOU… E AGORA?

O GUIA DEFINITIVO (E SEM MIMIMI) PARA DOMINAR DUMPS NO MAINFRAME 💥

Se você é dev COBOL e nunca ficou olhando um dump como se fosse hieróglifo egípcio… você ainda vai passar por isso 😄

Mas aqui vai a verdade estilo Bellacosa Mainframe:

👉 Dump não é problema… dump é RESPOSTA.
👉 Quem não sabe ler dump… fica refém de tentativa e erro.
👉 Quem domina dump… vira referência no time.

Bora transformar esse “bicho de 7 cabeças” em ferramenta de guerra ⚔️

---

💣 O QUE É UM DUMP (SEM ROMANCE)

Um dump é basicamente:

📌 Um snapshot da memória no momento do erro (ABEND)

Quando o programa explode (S0C7, S0C4, U4038…), o sistema salva:

• Conteúdo de registradores
• Memória ativa
• Área de variáveis
• Stack de execução
• PSW (Program Status Word)

👉 É literalmente o “estado da cena do crime”.

---

🧨 TIPOS DE DUMP (E POR QUE ISSO IMPORTA)

🔹 1. SYSUDUMP (o clássico raiz)

• Mais simples
• Legível
• Ideal para devs COBOL

👉 Se você está começando, é seu melhor amigo

---

🔹 2. SYSABEND (o detalhista hardcore)

• Muito mais verboso
• Inclui muito mais memória

👉 Útil… mas pode te afogar em informação

---

🔹 3. SYSMDUMP (nível CSI do mainframe)

• Dump completo de memória
• Usado para análise profunda / suporte IBM

👉 Aqui já é território de especialista ou suporte

---

📦 DDS DE DUMP (O QUE NÃO TE CONTAM DIREITO)

No JCL, o dump nasce aqui:

//SYSUDUMP DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//SYSMDUMP DD SYSOUT=*

💡 Dica Bellacosa:

• Nunca coloque os 3 juntos sem motivo
• Pode gerar dump gigante e travar spool

👉 Escolha com estratégia, não no desespero

---

🧠 COMO LER UM DUMP (O JEITO CERTO)

Aqui é onde separa dev comum de dev ninja 🥷

🔍 1. Comece pelo ABEND CODE

Exemplos clássicos:

• S0C7 → erro de dados (numérico inválido)
• S0C4 → violação de memória
• S0C1 → instrução inválida

👉 80% dos casos você resolve só entendendo isso

---

🧭 2. Vá direto no PSW

O PSW mostra:

• Endereço da instrução que falhou

👉 Esse endereço é o “X marca o tesouro” 🏴‍☠️

---

📍 3. Localize o OFFSET

Você vai ver algo assim:

OFFSET = 00001A2C

Agora:

👉 Procure no listing do compilador
👉 Encontre a linha correspondente

💡 Easter egg:
Se você compila com LIST, MAP, OFFSET… sua vida muda completamente

---

🧩 4. Analise os REGISTERS

Especial atenção para:

• R14 → retorno
• R15 → entrada
• R13 → área de trabalho

👉 Isso ajuda a entender o fluxo do programa

---

🔎 5. Veja o conteúdo das variáveis

No dump você verá HEX + EBCDIC:

F1F2F3F4 = 1234

👉 Aqui você encontra:

• Campo numérico com lixo
• Campo alfanumérico corrompido
• Dados desalinhados

---

⚡ EXEMPLO REAL (RAIZ)

Erro clássico:

MOVE WS-TEXTO TO WS-NUMERO

Se WS-TEXTO tiver:

'ABC'

💥 Resultado:

S0C7

👉 Dump vai mostrar valor inválido no campo numérico

---

🧠 COMO SER RÁPIDO (MODO ELITE)

🚀 Regra de ouro:

“Não leia dump inteiro. Faça ele te responder.”

Checklist prático:

1. ABEND code
2. PSW address
3. OFFSET
4. Linha no listing
5. Variável envolvida

👉 Pronto. Resolve 90% dos casos.

---

🧪 DICAS AVANÇADAS (OURO PURO)

💡 Compile assim sempre:

SSRANGE, LIST, MAP, OFFSET

• SSRANGE → pega erro de índice
• MAP → mostra variáveis
• OFFSET → conecta dump com código

---

💡 Use CEEDUMP (quando tiver LE)

Se seu ambiente usa Language Environment:

👉 você ganha dump mais amigável

---

💡 Procure por "LAST EXECUTED STATEMENT"

Alguns dumps mostram isso direto
👉 economiza MUITO tempo

---

💡 Cuidado com redefines

👉 80% dos dumps estranhos vêm daqui

---

🕵️ CURIOSIDADES (EASTER EGGS MAINFRAME)

• O termo “dump” vem literalmente de “despejar memória”
• Dumps existem desde os anos 60 (sim, mais velhos que muita linguagem moderna)
• Em ambientes críticos, dumps são analisados automaticamente por ferramentas de IA (sim, já estamos aí 🤯)

---

💬 COMENTÁRIO ESTILO BELLA

Se você ainda resolve erro com:

👉 DISPLAY pra todo lado
👉 Teste na tentativa
👉 “Ah, deve ser isso aqui…”

Você está perdendo tempo de vida.

---

🏁 CONCLUSÃO

Dump não é inimigo.

👉 Dump é o debugger raiz do mainframe.
👉 Dump é a verdade nua e crua.
👉 Dump é onde o COBOL fala com você.

E quando você aprende a ouvir…

💥 Você para de apagar incêndio e começa a dominar o ambiente.

 

Bellacosa Mainframe explica rtm o grande guarda-costas.

🔥 COBOL NÃO QUEBROU… FOI O RTM QUE DECIDIU O DESTINO

Se você trabalha com COBOL há anos, já viu isso acontecer:

💥 S0C7
💥 S0C4
💥 S878
…e aquele silêncio constrangedor no batch.

E aí vem a pergunta clássica:

👉 “O que aconteceu?”

Errado.

A pergunta certa é:

🧠 “O que o z/OS fez quando isso aconteceu?”

Porque no exato momento do ABEND…
quem assume o controle não é o seu programa.

É o RTM — Recovery Termination Manager.

---

🧠 O RTM: o juiz invisível do seu programa

O RTM é um componente do z/OS que entra em ação sempre que algo relevante acontece:

• ✔️ Erro
• ✔️ Falha
• ✔️ Terminação normal (sim!)

👉 Ele é responsável por:

• Capturar o erro
• Tentar recuperar
• Decidir o destino
• Registrar tudo

💡 Tradução Bellacosa:

🔥 “O RTM é quem decide se seu programa vive… ou vira dump.”

---

🚨 Quando o ABEND acontece (o bastidor real)

Você vê:

S0C7 – erro de dados

O RTM vê:

• Tipo de exceção
• Estado da CPU (PSW)
• Registradores
• Control blocks
• Contexto da task

👉 E imediatamente inicia o fluxo:

Erro → RTM → Recovery → Decisão → Dump → Investigação

💡 Isso acontece em milissegundos.

---

⚙️ Os serviços do RTM (o que ele realmente faz)

1️⃣ Captura do erro (o “detetive”)

O RTM intercepta:

• Program checks (S0C4, S0C7…)
• I/O errors
• Machine checks
• Falhas de memória

👉 Ele coleta o estado completo do sistema.

💡 Easter egg:

O SDWA é criado aqui — é literalmente o “snapshot do crime”.

---

2️⃣ Tentativa de recuperação (o “paramédico”)

Aqui entram os famosos:

• ESTAE → nível da aplicação
• FRR → nível do sistema

👉 O RTM pergunta:

“Alguém consegue salvar isso?”

💡 Curiosidade:

• Muitos sistemas robustos usam ESTAE para evitar queda total
• COBOL “puro” raramente usa diretamente… mas se beneficia disso sem saber

---

3️⃣ Decisão (o “juiz”)

Depois da tentativa:

• Continua execução?
• Finaliza a task?
• Derruba o address space?

👉 Essa decisão é crítica.

💡 Insight:

Nem todo erro vira ABEND visível — alguns são absorvidos

---

4️⃣ Geração de evidência (o “perito”)

O RTM gera:

• SYSUDUMP / SYSABEND / SYSMDUMP
• SVC dump
• LOGREC

👉 Isso vira seu material de análise.

💡 Frase forte:

Sem dump, você está cego.

---

🧹 RTM também limpa a bagunça (e isso é pouco falado)

Agora vem o que pouca gente sabe:

🔥 O RTM também atua quando TUDO DÁ CERTO

Quando seu job termina normalmente:

• Fecha datasets
• Libera memória
• Cancela timers
• Remove enqueues
• Limpa control blocks

👉 Isso é feito de forma extremamente eficiente.

💡 Comentário Bellacosa:

“Se o RTM não limpasse… o z/OS virava um lixão em minutos”

---

🧩 RTM1 vs RTM2 (nível raiz)

🔹 RTM1 (System Level)

• Falhas do sistema
• Interface com FRR

🔹 RTM2 (Task Level)

• Programas (COBOL aqui 👈)
• Interface com ESTAE

👉 Fluxo clássico:

Erro
 ↓
RTM1
 ↓
FRR
 ↓
RTM2
 ↓
ESTAE
 ↓
Decisão

💡 Isso é arquitetura de verdade.

---

📦 Dumps: o presente que ninguém quer… mas precisa

Tipos que você já viu:

• SYSUDUMP → básico
• SYSABEND → completo
• SYSMDUMP → raiz (hex)

👉 E os de sistema:

• SVC Dump
• Standalone Dump

💡 Dica prática:

🔥 “Se o problema é estranho… peça SYSMDUMP”

---

🗂️ LOGREC: o histórico que salva sua vida

LOGREC guarda:

• Erros de hardware
• Eventos do sistema
• Condições críticas

💡 Dica de ouro:

👉 Sempre comece por LOGREC antes do dump

---

🧠 SLIP e DAE (nível ninja)

🔹 SLIP

• Armadilha de erro
• Dispara dump sob condição

🔹 DAE

• Evita dumps duplicados

💡 Produção sem isso:

caos + storage cheio

---

💥 Aplicação prática (COBOL raiz)

S0C7 — o clássico

👉 Normalmente:

• Dado inválido em campo numérico

Mas o RTM te dá:

• Instrução que falhou
• Endereço
• Conteúdo do campo

💡 Dica prática:

1. Veja PSW
2. Ache a instrução
3. Verifique o dado
4. Volte no código

---

🧠 Insight final (o que separa níveis)

❌ Júnior: “Deu S0C7”
❌ Pleno: “Campo inválido”
✅ Sênior: “Eu sei exatamente onde e por quê”

---

🏁 Conclusão (sem mimimi)

O RTM é:

• 🔥 O guardião da estabilidade
• 🔍 O perito do erro
• ⚖️ O juiz da execução
• 🧹 O faxineiro do sistema

---

💬 Frase pra levar pra vida

“COBOL não quebra…
o RTM só revela o que já estava errado.”

 

 

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:

ABEND	Significado
S0C7	erro de dados numéricos
S0C4	violação de memória
S322	timeout (tempo excedido)
SB37	falta 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

 

Bellacosa Mainframe analisando o RTM

🔥 SEU PROGRAMA NÃO MORRE… ELE DEIXA PISTAS 💀

O guia proibido do RTM que revela como o z/OS investiga, sobrevive e aprende com cada falha

Você vê um ABEND e pensa:

👉 “deu erro…”

O z/OS pensa diferente:

💥 “vamos registrar, analisar, aprender e continuar rodando.”

Esse é o papel do Recovery Termination Manager (RTM) — o sistema que transforma falhas em evidência técnica.

Se você quer sair do nível “rodou ou não rodou” e entrar no nível engenharia de diagnóstico, esse é o mapa definitivo 👊🔥

---

🧠 1. A FILOSOFIA DO z/OS SOBRE ERROS

No mundo distribuído:

👉 erro = problema

No mainframe:

👉 erro = evento analisável

---

💡 Tradução Bellacosa

“falhar é permitido… repetir o erro não.”

---

⚙️ 2. RTM — O “INVESTIGADOR OFICIAL”

O RTM entra em ação quando:

• ocorre erro (ABEND)
• há falha de hardware
• há erro de sistema
• ou até quando tudo termina normalmente

---

🔥 Funções principais

• capturar erro
• chamar rotinas de recuperação
• gerar dumps
• registrar LOGREC
• limpar recursos

---

💡 Insight

RTM atua até quando o programa termina certo

---

🧩 3. RTM1 vs RTM2 — DOIS NÍVEIS DE SOBREVIVÊNCIA

🔹 RTM1 (System)

• protege o sistema
• chama FRR

---

🔹 RTM2 (Task)

• trata a task
• chama ESTAE

---

🔥 Fluxo real

Erro → RTM1 → RTM2 → Recovery → Dump → Cleanup

---

💡 Tradução

“primeiro o sistema sobrevive… depois a task”

---

🛡️ 4. ESTAE — A AUTODEFESA DO PROGRAMA

Programas podem registrar:

👉 rotinas de recuperação

---

🔥 Como funciona

• programa define ESTAE
• erro ocorre
• RTM chama essa rotina

---

💡 Tradução Bellacosa

“seu programa pode tentar se salvar antes do fim”

---

🧠 Exemplo real

COBOL acessa memória inválida
 ↓
ESTAE intercepta
 ↓
log + tratamento

---

💀 5. DUMPS — A CENA DO CRIME

Um dump é:

👉 uma foto completa do sistema no erro

---

🔥 Tipos

• SYSABEND → completo
• SYSMDUMP → técnico
• SYSUDUMP → básico
• SVC Dump → sistema
• Stand-alone → sistema morto

---

💡 Tradução

“dump é o momento congelado da falha”

---

🧠 Exemplo

S0C4
 ↓
dump gerado
 ↓
IPCS analisa

---

🧠 6. LOGREC — O HISTÓRICO DOS ERROS

LOGREC registra:

• falhas de hardware
• erros de software
• condições do sistema

---

💡 Insight

é o primeiro lugar que um sysprog olha

---

🔥 Tradução Bellacosa

“LOGREC = diário dos problemas”

---

📜 7. LOGS — A LINHA DO TEMPO

🔹 Principais:

• SYSLOG → sistema
• OPERLOG → sysplex
• JESMSGLG → job

---

💡 Uso

👉 entender o “antes” do erro

---

🎥 8. TRACES — O FILME COMPLETO

Enquanto dump = foto
👉 trace = vídeo

---

🔹 Tipos:

• System Trace
• GTF
• Component Trace

---

💡 Uso

👉 analisar fluxo ao longo do tempo

---

🧠 9. DAE — INTELIGÊNCIA DE DUMP

Evita:

👉 dumps repetidos

---

🔥 Usa:

• SYS1.DAE

---

💡 Tradução

“não repetir análise inútil”

---

🔎 10. IPCS — O CSI DO MAINFRAME

Ferramenta para:

• ler dumps
• interpretar dados
• analisar erro

---

💡 Tradução Bellacosa

“IPCS = laboratório forense”

---

🧨 11. SLIP TRAPS — PEGANDO ERRO NO FLAGRA

Você pode definir:

👉 “quando isso acontecer… capture tudo”

---

💡 Exemplo

Se S0C4 ocorrer → gerar dump completo

---

🔥 Tradução

“armadilha inteligente”

---

⚙️ 12. CLEANUP — O FINAL OBRIGATÓRIO

Após erro ou término:

• memória liberada
• datasets fechados
• locks removidos
• timers cancelados

---

💡 Tradução

“ninguém sai sem arrumar o ambiente”

---

🔄 13. PASSO A PASSO COMPLETO

Programa executa
 ↓
Erro ocorre
 ↓
RTM acionado
 ↓
ESTAE / FRR chamados
 ↓
Dump gerado
 ↓
LOGREC atualizado
 ↓
Recursos liberados
 ↓
Sistema continua

---

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. RTM roda até em término normal

---

🔥 2. Dump pode salvar dias de análise

---

💀 3. LOGREC é ignorado por iniciantes

---

🧠 4. SLIP é arma de elite

---

⚡ 5. z/OS foi feito para falhar… e continuar

---

🎯 RESUMO FINAL

✔ RTM controla término e erro

✔ RTM1 protege sistema

✔ RTM2 trata task

✔ ESTAE = recuperação

✔ Dumps = evidência

✔ LOGREC = histórico

✔ IPCS = análise

---

💥 FRASE FINAL

“No mainframe, o erro não encerra o sistema… ele inicia a investigação.”