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.

 

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.”

 

Solucionando ABENDS em COBOL

 

Bellacosa Mainframe solucionando abends em cobol

Bellacosa Mainframe e o caçador de abends

Não entre em Pânico.

Supere seus desafios. A solução de ABENDS em mainframe pode ser desafiadora, intrigante, caótica e gratificante ao mesmo tempo, tudo junto e bem misturado. Por isso mantenha uma atitude positiva e uma mentalidade construtiva e esteja pronto para enfrentar qualquer problema que surgir em seu caminho.

Seja paciente e persistente e não desista facilmente. Seja criativo e flexível e não dependa de uma solução ou método, às vezes receitas de bolo pioram o problema. Canalize a colaboração e a cooperação e tente não trabalhar isoladamente.

Ao solucionar problemas, documente e compartilhe o conhecimento com os colegas, lembre-se sempre da máxima do velho deitado, digo velho ditado: uma mão lava a outra e aproveite a jornada do mainframe, participe de um projeto que há 70 anos vem tirando noite de sonos de homens e mulheres nos mais diversos Centros de Processamento de Dados do Mundo.

No pior cenário consulte o manual da linguagem, instalação e procure o Mestre dos Magos, sempre haverá um, mais próximo do que imagine.

ABEND

Relembrando, ABEND é uma situação anômala onde um programa mainframe (COBOL, PLI, Natural, REXX, Easytreve etc) tem um término anormal. Ou seja, termina com erro. A origem da palavra ABEND, que no Brasil virou sinônimo de erro e, ao mesmo tempo, verbo, surgiu da junção de duas palavras inglesas: ABNORMAL (anormal) END.

Muito em uso nos CPDS, agora chega de delongas e vamos ao nosso pequeno help na solução de alguns abends comuns em COBOL Mainframe, que poderão ser visualizados no SDSF, através do SPOOL do JOB, que indicara qual o step do JCL, o programa envolvido e o código do ABEND.

S0C1

Quais são as possíveis causas dos ABEND: S0C1?

O S0C1 é um erro associado a ambiente de I/O, muito normalmente associado a arquivos QSAM/VSAM e suas declarações no programa e JCL, e em algumas raras situações a chamadas CALL em subprogramas. A solução é relativamente simples e a correção é rápida, basta identificar o statemant do erro e verificar o tipo de Bug, conforme tabela abaixo:

1. Nome DD ausente ou escrito incorretamente.

2. Ler/gravar em DataSet não aberto.

3. Leia a saída aberta do DataSet.

4. Gravar na entrada aberta do DataSet.

5. Subprograma chamado não encontrado

S0C4

Quais são as possíveis causas dos ABEND: S0C4?

O SOC4 é um erro associado ao ambiente de I/O, Arrays e Tabelas internas, uso de variáveis computacional. Abaixo temos algumas causas comuns, muitas vezes é necessário o uso de DISPLAY para encontrar o erro com mais segurança, alguns comandos COBOL possuem captura de erro, utilize-os para antecipar e prever anomalias.

1. Instrução Select ausente (durante a compilação), verificar as declarações no Environment Division / Data Division, pode estarem com erro de grafia nome, verifique também a clausula D DD no JCL.

2. Em um array ou Tabela interna o Subscrito/índice está  incorreto.

3. Variável computacional com valores incorretos, uma Exceção de proteção.

4. Falta de inicialização ou variável incorreta, ou seja, parâmetros ausentes na chamada CALL de subprograma.

5. Ler/gravar registros de dados em arquivo não aberto.

6. Gravar registros de dados de/para em arquivo não aberto.

S0C5

Quais são as possíveis causas dos ABEND: S0C5?

O SOC5 é um erro associado ao ambiente de I/O, Arrays e Tabelas internas. Abaixo temos algumas causas comuns, muitas vezes é necessário o uso de DISPLAY para encontrar o erro com mais segurança.

1. Subscrito/índice incorreto em Tabela interna ou Array,

2. Tentativa de Fechar um DataSet não aberto durante o processamento.

3. Problemas no PERFORM, saída conturbada ou erro de logica.

4. Tentativa de acesso à área de E/S (FD) antes do comando READ.

SOC7

Quais são as possíveis causas dos ABEND: S0C7?

Este abend pode ser ocasionado por variáveis numéricas, problemas de cálculos e confusão entre formatos alfanuméricos, alfabéticos e numéricos. Lembrando que toda variável de trabalho deve ser inicializada para evitar surpresas no decorrer do processamento, em algumas situações o mal uso do Índice na Tabela/Array resultará num S0C7

1. Operação numérica em dados não numéricos.

2. Variáveis não inicializadas ou com valores nulos.

3. Estouro de índice no uso de Tabela / Array.

SOCB

Quais são as possíveis causas dos ABEND: S0CB?

O abend S0CB normalmente esta associado com divisão, tanto no DIVIDY como no COMPUTE e informa que o divisor está com o valor zerado ou nulo.

1. Divisão por zero.

DICAS & SOLUÇÕES

Como solucionar um Abend SOC1 ?

Um Abend S0C1 ocorrerá se a CPU tentar executar um código binário que não seja uma instrução de máquina válida, por exemplo. Se você tentar executar dados.

Como solucionar um Abend SOC4 ?

Um S0C4 é uma violação de proteção de memória. Isso ocorre se um programa tentar acessar o armazenamento além das áreas atribuídas a ele. A famosa invasão de área, verifique suas tabelas e array, muitas vezes o culpado esta bem visível.

Como solucionar um Abend SOC7 ?

Em linhas bem gerais, não me xingue, basicamente necessitas corrigir os dados incorretos.

Muitas vezes o motivo do SOC7 é um item numérico não inicializado, lembre-se de usar o VALUE na declaração da variável, ou INITIALIZE no decorrer da execução. Examine essa possibilidade primeiro.

Muitas instalações fornecem um dump para ABENDs em tempo de execução (ele também pode ser gerado chamando algumas sub-rotinas ou serviços do sistema operacional através da linguagem assembly). Esses dumps fornecem o deslocamento da última instrução em que ocorreu o ABEND. Examine a compilação e produza a listagem XREF para obter o comando e o número da linha do código-fonte (Statement) neste deslocamento.

Então poderás olhar o código-fonte para caçar o bug, debugar para os íntimos. Lembrando que para capturar os dumps de tempo de execução, terás que definir alguns conjuntos de dados (SYSABOUT etc) no JCL.

Se nada disso for útil, use julgamento e DISPLAY para localizar a origem do erro, melhor solução sempre, porém lotaras o SPOOL e o analista de produção não gostará muito.

Algumas instalações podem ter ferramentas de depuração de programas em lote. Use-as se possível recomendo: o OMEGAMON e o APA.

DISPLAY

Utilize o comando DISPLAY para realizar uma trilha de DEBUG, assim pode seguir passo-a-passo por onde o ponteiro da execução passou, saberá até o momento anterior ao ABEND.

Utilize para ver o valor do antes e depois da variável após um cálculo, uma chamada CALL e etc.

Handling erros - Tratamento de erros

Deixe o COBOL trabalhar para ti, existem algumas soluções BUG TRAP, use código em seus programas que antecipe possíveis problemas de sistema ou de tempo de execução. Se você não incluir esse código, os dados ou arquivos de saída poderão ser corrompidos e o usuário poderá nem perceber que há um problema.

O código de tratamento de erros pode realizar ações como lidar com a situação, emitir uma mensagem ou interromper o programa. Você pode, por exemplo, criar rotinas de detecção de erros para erros de entrada de dados ou para erros conforme sua instalação os define.

Lembre-se sempre de prevenir, pensar, preparar-se e codificar uma mensagem de aviso é uma boa ideia, os famosos warnings de execução.

1.       ON OVERFLOW em STRING e UNSTRING operações.

2.       ON SIZE ERROR em operações aritméticas.

3.       No tratamento de arquivos de Input e Output.

4.       ON EXCEPTION ou ON OVERFLOW em chamadas CALL.

5.       Criar rotinas para validar e tratar possíveis exceções.