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

 

🔥 SEU PROGRAMA NÃO “ENXERGA” MEMÓRIA… ELE NEGOCIA COM O z/OS 😳 O guia proibido da Addressability que separa dev COBOL de engenheiro de sistema

 

Bellacosa Mainframe em uma viagem ao Addressability do z/os

🔥 SEU PROGRAMA NÃO “ENXERGA” MEMÓRIA… ELE NEGOCIA COM O z/OS 😳

O guia proibido da Addressability que separa dev COBOL de engenheiro de sistema

Você acha que seu COBOL acessa memória direto?

👉 Não acessa.

No mainframe, nada é direto.
Tudo passa por:

• tradução
• autorização
• tabelas
• registradores
• controle do sistema

Se você não entende isso…
👉 você nunca vai dominar dump, performance ou abend 💀

---

🧠 O QUE É ADDRESSABILITY (SEM ENROLAR)

Addressability é:

a capacidade de um programa acessar dados — onde quer que eles estejam

---

💡 Tradução Bellacosa

“Addressability é o GPS + chave + autorização da memória.”

---

⚙️ 1. DISPATCHING WORK — ONDE TUDO COMEÇA

Quando sua task roda:

• dispatcher escolhe
• CPU assume
• CR1 é carregado

👉 CR1 aponta para o address space ativo

---

🔥 Insight

CR1 define “qual mundo você está enxergando”

---

🌍 2. VIRTUAL STORAGE — O UNIVERSO NÃO É REAL

Cada usuário tem:

👉 seu próprio universo de memória

---

🔹 Características:

• até 16 exabytes 😳
• isolado
• protegido

---

💡 História

MVS = Multiple Virtual Storage

👉 desde os anos 70 já fazia isso

---

🧨 Easter Egg

Você acha que está acessando memória real…

👉 está acessando endereço virtual traduzido

---

🧩 3. ADDRESS SPACE — SUA “BOLHA”

Tudo roda dentro de:

👉 um address space

---

🔹 Tipos:

• Batch
• TSO
• Started Task

---

💡 Insight

cada programa vive isolado

---

🔗 4. CROSS MEMORY — QUEBRANDO A BOLHA

Mas… o sistema permite sair dela.

---

🔹 O que é?

Acessar outro address space

---

🔥 Exemplo real

COBOL → chama serviço → DB2 → retorna

👉 são address spaces diferentes

---

💡 Estados:

• Home → origem
• Primary → execução
• Secondary → dados

---

🧨 Curiosidade

Se são diferentes:

👉 você está em cross-memory mode

---

🚀 5. PROGRAM CALL (PC) — O TELEPORTE DO z/OS

🔹 O que faz?

• troca de address space
• mantém controle
• permite retorno

---

🔥 Fluxo real

User → LLA → VLF → módulo → volta

👉 tudo invisível

---

💡 Tradução

PC é um “portal controlado”

---

🧱 6. LINKAGE STACK — A MEMÓRIA DA EXECUÇÃO

Sempre que um programa chama outro:

👉 estado é salvo automaticamente

---

🔹 Salva:

• registradores
• PSW
• access registers

---

💡 Vantagens

• menos erro
• suporte a reentrância
• debug mais limpo

---

🧨 Curiosidade

Substitui os antigos save areas

---

⚙️ 7. ACCESS REGISTERS — O PODER ESCONDIDO

🔹 O que são?

• 16 registradores
• permitem acessar outros espaços

---

🔥 Funcionamento

AR → qual espaço
GR → qual dado

---

💡 Tradução Bellacosa

AR = endereço do universo
GR = endereço dentro do universo

---

🧠 8. ACCESS LIST / ALET / ALE — CONTROLE DE ACESSO

Nada é livre.

---

🔹 Processo:

1. obter S-token
2. ALESERV
3. criar ALE
4. gerar ALET
5. carregar AR

---

💡 Insight

acesso exige autorização formal

---

🧨 Curiosidade

Sem isso:

👉 proteção de memória bloqueia acesso

---

⚡ 9. ADDRESSABILITY MODES

🔹 AMODE

• 24-bit
• 31-bit
• 64-bit

---

🔹 RMODE

• onde o programa carrega

---

💡 História

Compatibilidade com décadas de software

---

🔄 10. PASSO A PASSO COMPLETO

Task é despachada
 ↓
CR1 define address space
 ↓
Programa executa
 ↓
Se precisar:
   → PC (outro space)
   → AR (outro data space)
 ↓
Linkage stack salva estado
 ↓
Retorno

---

💀 ONDE ISSO APARECE NA VIDA REAL?

🔥 Dump (IPCS)

Você vê:

• PSW
• registers
• ARs
• linkage stack

---

🔥 Abend clássico

👉 S0C4 = erro de addressability

---

🔥 Performance

• cross memory custa
• LPA melhora

---

🧨 CURIOSIDADES (NÍVEL JEDI)

🤯 1. Um programa pode acessar vários universos ao mesmo tempo

---

🔥 2. Memória é totalmente virtual

---

💀 3. Um erro de ponteiro quebra tudo (S0C4)

---

🧠 4. O sistema controla TUDO via tabelas

---

🎯 RESUMO FINAL

✔ Addressability = acesso controlado

✔ Address space = isolamento

✔ Cross memory = comunicação

✔ PC = chamada entre espaços

✔ AR = acesso avançado

✔ Linkage stack = estado

---

💥 FRASE FINAL

“No mainframe, memória não é um lugar… é um privilégio concedido pelo sistema.”

 

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z – O Despertar da Força dos Ponteiros - Parte I

 

Bellacosa Mainframe e os ponteiros de memoria no COBOL Parte I

COBOL Ponteiros de Memória: Os Cristais Kyber Escondidos do IBM Z

Parte 1 – O Despertar da Força dos Ponteiros

Quando o Padawan Descobre que um Endereço Pode Ser Mais Poderoso que os Dados

Por Bellacosa Mainframe

---

"O dado é importante. Mas conhecer onde ele vive na memória é conhecer a própria Força."

Mestre Sysprog Bellacosa

---

Introdução

Existe um momento na jornada de todo desenvolvedor COBOL em que ele acredita já ter visto praticamente tudo.

Aprendeu arquivos.

Aprendeu VSAM.

Aprendeu DB2.

Aprendeu CICS.

Aprendeu tabelas OCCURS.

Aprendeu REDEFINES.

Aprendeu recursão.

Aprendeu programas aninhados.

Aprendeu até THREADSAFE.

Então um dia aparece um código semelhante a este:

01 PTR-CLIENTE      USAGE POINTER.

SET PTR-CLIENTE TO ADDRESS OF WS-CLIENTE.

O jovem Padawan olha para aquilo e pergunta:

Mestre…

COBOL tem ponteiros?

O mestre sorri.

Toma um gole de café.

E responde:

Sim.

E são provavelmente uma das funcionalidades menos conhecidas, mais poderosas e potencialmente mais perigosas disponíveis no IBM Enterprise COBOL.

---

O grande mito

Existe um mito muito comum.

"COBOL não trabalha com endereços."

Errado.

COBOL trabalha.

Sempre trabalhou.

Só que de forma extremamente controlada.

Enquanto linguagens como C permitem brincar livremente com memória:

int *p;

COBOL diz:

Jovem Padawan...

Se você vai manipular memória...

Faça isso com respeito.

---

O que é um ponteiro?

Um ponteiro não é um dado.

Ele não contém um nome.

Ele não contém um CPF.

Ele não contém uma data.

Ele contém:

O endereço onde algo está.

Imagine.

Apartamento:

Rua Jedi 500

Apartamento 1001

O apartamento é o dado.

O endereço é o ponteiro.

---

Exemplo.

Cliente

Nome

Bellacosa

Está armazenado em:

7FFF012345678

O ponteiro guarda:

7FFF012345678

Nada mais.

---

Por que isso existe?

Porque às vezes queremos acessar memória dinamicamente.

Criar estruturas.

Buffers.

Caches.

Árvores.

Filas.

Listas.

Comunicar com C.

Trabalhar com APIs.

Manipular XML.

Shared Memory.

LE Runtime.

---

COBOL sempre teve ponteiros?

Não.

COBOL 60

Não.

COBOL 68

Não.

COBOL 74

Não.

---

A situação começou a mudar com:

COBOL 85

---

Mais tarde.

IBM Enterprise COBOL.

Introduziu:

USAGE POINTER

ADDRESS OF

BASED

ALLOCATE

FREE

---

Atualmente.

Enterprise COBOL

4

5

6

6.3

6.4

6.5

Suportam totalmente.

---

O que é USAGE POINTER?

É o tipo especial que armazena um endereço.

Exemplo.

01 WS-PTR.

   USAGE POINTER.

ou

01 WS-PTR POINTER.

---

Não faça:

PIC X(08)

Errado.

---

Não faça:

PIC 9(18)

Errado.

---

O compilador conhece o formato.

Você não precisa.

---

ADDRESS OF

Talvez seja a instrução mais importante.

Exemplo.

Temos.

01 WS-CLIENTE.

   05 WS-NOME PIC X(30).

---

Pegando endereço.

SET WS-PTR

TO ADDRESS OF WS-CLIENTE

Pronto.

Agora.

WS-PTR aponta.

Para WS-CLIENTE.

---

Visualmente

Antes.

WS-PTR


NULL

Depois.

WS-PTR


0000007FFF123450

---

Como funciona na memória

Imagine.

Working Storage

ENDEREÇO


1000


WS-NOME


Bellacosa



1030


WS-IDADE


52



1035


WS-PTR

---

Executamos.

SET PTR

TO ADDRESS OF WS-NOME

---

Resultado.

PTR


1000

---

O ponteiro virou.

Uma espécie de GPS.

---

O que é SET?

SET é o comando utilizado.

Para manipular ponteiros.

Exemplo.

SET PTR

TO ADDRESS OF WS-DADOS

---

Outro.

SET PTR TO NULL

---

Muito importante.

Sempre inicializar.

---

Boa prática.

SET PTR TO NULL

No início.

---

Primeiro exemplo completo

Passo 1

Criar estrutura

WORKING-STORAGE SECTION.


01 WS-CLIENTE.

   05 WS-NOME.

      PIC X(30).



01 WS-PTR

USAGE POINTER.

---

Passo 2

Preencher

MOVE 'BELLACOSA'

TO WS-NOME

---

Passo 3

Capturar endereço

SET WS-PTR

TO ADDRESS OF WS-CLIENTE

---

Passo 4

Display

DISPLAY 'PONTEIRO OK'

Fim.

---

O que o compilador faz?

Compilador cria.

Variável especial.

Compatível com arquitetura.

31 bits.

64 bits.

---

Padawan pergunta.

Mestre...

Então é um hexadecimal?

Resposta.

Sim.

Normalmente.

---

Exemplo.

0000000012345678

---

IBM Z e endereçamento

Aqui começa a magia.

IBM Z possui longa história.

---

AMODE 24

Década 70.

Memória.

16 MB.

---

AMODE 31

1983

2 GB

---

AMODE 64

zSeries

Exabytes teóricos.

---

COBOL acompanha.

---

Working Storage

Ponteiros podem apontar para:

Working Storage

---

Local Storage

---

Heap

---

Dynamically allocated

---

LE Areas

---

Buffers

---

Stack

Existe outra área.

Stack.

Exemplo.

Função chamada.

STACK



Frame A


Frame B


Frame C

---

Cada frame.

Possui.

Variáveis.

Retorno.

Contexto.

---

Ponteiros podem apontar.

Para stack.

Sim.

---

Mas aqui mora perigo.

---

O lado sombrio

Imagine.

Procedimento.

Termina.

Stack destruída.

---

Ponteiro ainda existe.

---

Aponta.

Para memória inválida.

---

Chamamos isso.

Dangling Pointer.

---

Exemplo.

PTR


12345

---

Memória já morreu.

---

Resultado.

SOC4.

---

Heap

Heap é diferente.

Sobrevive.

Mais tempo.

---

Usado em.

ALLOCATE.

CEEGTST.

GETMAIN.

---

Mais seguro.

---

Curiosidade

Muitos programas COBOL bancários.

Nunca usam ponteiros.

---

Por quê?

Não precisam.

---

COBOL nasceu.

Para registros.

Arquivos.

Campos fixos.

---

Ponteiros vieram.

Muito depois.

---

Vantagens

Extremamente rápidas.

Não copia dados.

---

Exemplo.

Mover.

1 MB.

Custa.

CPU.

---

Mover ponteiro.

8 bytes.

Instantâneo.

---

Onde usar?

Excelente para.

XML

JSON

Árvores

Cache

Filas

MQ

Buffers

APIs

Sockets

C

Metal C

---

Onde NÃO usar?

Cadastro clientes.

Folha pagamento.

Relatórios.

VSAM simples.

Batch convencional.

---

Performance

Muito boa.

Quase zero overhead.

---

Mas.

Erro custa caro.

---

Um MOVE errado.

Perde registro.

---

Ponteiro errado.

Pode derrubar programa.

---

SOC4.

---

Segurança

Ponteiros são ferramenta poderosa.

Mas perigosos.

---

Podem causar.

Corrupção memória.

Exposição dados.

Abends.

Memory leaks.

---

Padawan deve lembrar.

Ponteiro não sabe.

Se memória ainda existe.

Ele apenas acredita.

---

Curiosidades Bellacosa

Pouquíssimos desenvolvedores COBOL escrevem código com ponteiros diariamente.

Mas os profissionais que trabalham com:

• Language Environment

• XML parsers

• CEEGTST

• Metal C

• DB2 internals

• Middleware

• MQ exits

• CICS User Exits

• z/OS Connect

• Parsers de alta performance

frequentemente encontram USAGE POINTER, ADDRESS OF, BASED e estruturas dinâmicas escondidas em programas aparentemente inocentes.

---

O Conselho do Mestre Bellacosa

Imagine que os dados COBOL são sabres de luz.

Você pode segurá-los diretamente.

Pode copiá-los.

Pode movê-los.

Pode validá-los.

Mas um ponteiro é diferente.

Um ponteiro é um mapa para encontrar o sabre.

Ele não contém energia.

Ele não contém plasma.

Ele apenas diz:

"Vá até aquele lugar da memória e você encontrará aquilo que procura."

E essa é justamente a beleza e o perigo dos ponteiros em COBOL.

Eles permitem que o Padawan transcenda a programação tradicional baseada em registros fixos e passe a manipular a própria estrutura da memória do IBM Z.

Mas também ensinam uma das maiores lições do universo mainframe:

O dado pode estar protegido por RACF.

O dataset pode estar catalogado.

O programa pode ser RENT e THREADSAFE.

Mas um ponteiro errado continua tendo o poder de levar até mesmo um Mestre Sysprog ao temido S0C4.

Continua na Parte 2 – BASED, ALLOCATE, CEEGTST e Estruturas Dinâmicas: Construindo Listas Encadeadas no IBM Z.

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.