☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

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

terça-feira, 30 de março de 2021

O Guia Definitivo para um Programador Padawan Entender o Que Realmente Acontece Quando um Programa "Morre" no IBM Z

 

Bellacosa Mainframe apresenta abends sem misterios

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios

O Guia Definitivo para um Programador Padawan Entender o Que Realmente Acontece Quando um Programa "Morre" no IBM Z

"O primeiro ABEND assusta. O centésimo ensina. O milésimo transforma um programador comum em alguém que consegue conversar com o sistema operacional."


Introdução

Existe um momento na vida de praticamente todo programador COBOL em que ele termina seu código, compila sem erros, executa o JOB e...

***** ABEND *****

Silêncio.

O coração acelera.

A primeira reação costuma ser:

"Meu programa está errado."

Na maioria das vezes, essa conclusão está incompleta.

No mundo Mainframe, um ABEND (Abnormal End) não significa apenas que o programa possui um erro. Ele significa que alguma parte do ecossistema que envolve aquela execução encontrou uma condição considerada fatal.

E esse ecossistema é enorme.

Um programa COBOL nunca trabalha sozinho.

Ele depende de:

  • JCL

  • JES2

  • z/OS

  • Catálogo

  • Arquivos

  • CICS

  • Db2

  • VSAM

  • SDSF

  • Memória

  • Storage

  • Segurança (RACF)

  • Compilador

  • Link-Edit

  • Bibliotecas (STEPLIB)

Quando qualquer uma dessas peças falha, o programa pode terminar com um ABEND.

Entender isso é a primeira evolução de um Programador Padawan.


Afinal, o que significa ABEND?

ABEND é abreviação de:

ABnormal END

Ou seja:

O sistema encerrou aquela execução porque ela não podia continuar de maneira segura.

É importante observar que:

Nem todo erro produz um ABEND.

Um programa pode terminar normalmente retornando RC=08.

Outro pode gerar apenas mensagens.

Já um ABEND significa:

"A execução foi interrompida imediatamente."


Quem executa um programa COBOL?

Muitos iniciantes imaginam algo assim:

COBOL
 ↓
Executa

Na realidade, acontece algo muito maior.

JCL

↓

JES2

↓

Initiator

↓

Load Module

↓

Language Environment

↓

Programa COBOL

↓

Arquivos

↓

Db2

↓

VSAM

↓

CICS

↓

z/OS

O programa é apenas um pequeno participante.


O papel do JCL

O JCL funciona como um plano de execução.

Ele informa:

  • qual programa executar;

  • quais arquivos abrir;

  • quais bibliotecas usar;

  • memória necessária;

  • parâmetros;

  • classes;

  • datasets temporários.

Se o COBOL é o cozinheiro...

O JCL é a receita inteira.


O papel do JES2

O JES2 (Job Entry Subsystem 2) é o grande organizador do processamento batch.

Ele:

  • recebe JOBs;

  • coloca na fila;

  • controla prioridades;

  • envia para execução;

  • coleta SYSOUT;

  • registra mensagens;

  • devolve resultados.

Pense no JES2 como um enorme aeroporto.

Os JOBs são aviões.

O JES2 decide:

  • quem decola;

  • quando decola;

  • em qual pista;

  • para onde vai.


O papel do SDSF

Depois da execução, normalmente usamos o SDSF.

Ele não executa nada.

Ele apenas permite observar.

No SDSF encontramos:

  • JESMSGLG

  • JESJCL

  • JESYSMSG

  • SYSOUT

  • RC

  • ABEND

É o equivalente ao painel de monitoramento.


Como um ABEND nasce?

Imagine:

JCL

↓

Programa COBOL

↓

OPEN INPUT CLIENTES

↓

Arquivo inexistente

↓

IEC141I

↓

S013

Ou então:

MOVE "ABC"
TO WS-NUMERO PIC 9(5)

↓

S0C7

Cada tipo de erro produz um código diferente.

Esse código é o ABEND.


ABENDs do Sistema (Sxxxx)

Quando começam com:

S

Significa:

System Abend

O próprio z/OS detectou o problema.

Exemplos:

S0C4

S0C7

S013

SB37

ABENDs do Usuário (Uxxxx)

Quando aparecem:

U4038

U0999

Foram gerados pela aplicação.

Ou pelo Language Environment.


ABENDs do CICS

No CICS aparecem códigos de quatro letras:

ASRA

AICA

AEI9

São específicos do ambiente transacional.


Os ABENDs mais importantes


S0C1

Operation Exception

O processador tentou executar uma instrução inválida.

Pode ocorrer por:

  • módulo corrompido;

  • CALL incorreto;

  • programa não compilado corretamente;

  • desvio para área inválida.

É relativamente raro.


S0C4

Protection Exception

Provavelmente o ABEND mais famoso.

O programa tentou acessar memória proibida.

Exemplos:

  • ponteiro inválido;

  • tabela fora do OCCURS;

  • endereço inexistente;

  • parâmetro incorreto na LINKAGE.

Sempre que ouvir "Storage Violation", pense em S0C4.


S0C7

Data Exception

O favorito dos iniciantes.

O programa tentou fazer cálculo com dados inválidos.

Exemplo:

PIC 9(5)

conteúdo:

12A45

Ao executar:

ADD 1

Resultado:

S0C7

A maior causa costuma ser falta de validação de entrada.


S013

Erro de Dataset

Relaciona-se à abertura de arquivos.

Normalmente envolve:

  • DCB incompatível;

  • RECFM;

  • LRECL;

  • BLKSIZE;

  • modo de abertura incorreto;

  • DD errado.

É um ABEND de integração entre JCL e programa.


S222

O JOB foi cancelado manualmente.

Normalmente:

CANCEL JOB

Não significa erro da aplicação.


S322

Tempo de CPU excedido.

O programa entrou em loop.

Ou o TIME do JOB foi ultrapassado.

Sempre investigue:

PERFORM UNTIL

GO TO

READ

EOF

S806

Programa não encontrado.

As causas clássicas:

  • STEPLIB incorreta;

  • LOAD inexistente;

  • biblioteca errada;

  • módulo não linkeditado.

É um dos primeiros erros que um desenvolvedor encontra.


SB37

Sem espaço durante gravação.

O dataset atingiu seu limite.

Muito comum em SORTs.


SD37

Sem espaço por quantidade de extents.

Mesmo existindo espaço físico.

O dataset não consegue crescer.


SE37

Quantidade máxima de extensões atingida.

O administrador normalmente resolve ajustando a alocação.


B37

Erro semelhante aos anteriores.

Também relacionado à falta de espaço.

A diferença está na forma como o sistema detectou a limitação.

Na prática, todo Padawan deve associar:

B37

SB37

SD37

SE37

↓

Problemas de espaço em disco.

U4038

Muito comum em COBOL.

Normalmente produzido pelo Language Environment.

Pode esconder:

  • S0C7;

  • S0C4;

  • SQLCODE fatal;

  • erro interno.

Sempre consulte o CEEDUMP.

Nunca pare na primeira mensagem.


U0999

Erro definido pela própria aplicação.

É comum em grandes bancos.

Exemplo:

IF ERRO

DISPLAY "CLIENTE INVALIDO"

MOVE 999 TO RETURN-CODE

CALL ABEND

É um erro de negócio.


ASRA (CICS)

Equivalente ao S0C4 ou S0C7 dentro do CICS.

Na maioria das vezes há um ABEND de sistema escondido atrás dele.

É necessário verificar o dump do CICS.


AEI9

Tentativa de acessar recurso inexistente.

Pode envolver:

  • programa;

  • mapa BMS;

  • fila;

  • recurso não instalado.


AKCS

Erro relacionado ao ambiente CICS ou à configuração de recursos e segurança. Costuma indicar inconsistências operacionais que exigem análise das mensagens associadas e da definição do recurso.


APCT

Programa não encontrado no CICS.

Equivale ao S806 do ambiente batch.

Verifique:

  • PPT;

  • DFHRPL;

  • módulo.


AICA

Loop infinito.

O CICS cancelou a transação.

É o equivalente do:

S322

Só que dentro do CICS.


ATNI

A transação solicitada não está instalada ou habilitada.

Verifique:

  • PCT;

  • nome da transação;

  • instalação dos recursos.


AEYD

Problemas relacionados ao acesso ou ao estado de recursos do CICS (como filas, arquivos ou outros objetos), normalmente indicando que o recurso esperado não está disponível ou não pode ser utilizado da forma solicitada. A mensagem detalhada do CICS complementa o diagnóstico.


Como investigar um ABEND?

Uma sequência bastante utilizada por profissionais experientes é:

1
Qual é o ABEND?

↓

2
É System?
É User?
É CICS?

↓

3
Verificar JESYSMSG

↓

4
Verificar JESMSGLG

↓

5
Verificar SYSOUT

↓

6
Existe CEEDUMP?

↓

7
Existe SYSMDUMP?

↓

8
Analisar última instrução executada

↓

9
Conferir JCL

↓

10
Reproduzir o problema

Essa disciplina evita "corrigir" o sintoma sem encontrar a causa.


Dicas de ouro para um Padawan

  • Leia a primeira mensagem de erro, não apenas a última. Muitas vezes ela explica a causa antes do ABEND.

  • Aprenda a navegar no SDSF. JESMSGLG, JESYSMSG e SYSOUT contam a história da execução.

  • Conheça os utilitários do compilador e do Language Environment. CEEDUMP, SYSMDUMP e IPCS são aliados valiosos.

  • Não altere código antes de entender o erro. Corrigir por tentativa e erro pode esconder problemas mais sérios.

  • Entenda o contexto. Um S806 aponta para bibliotecas; um S013 para JCL e datasets; um S0C7 para dados; um S0C4 para memória. O código do ABEND já indica a direção da investigação.

  • Mantenha um caderno de ABENDs. Profissionais experientes criam seu próprio catálogo de erros e soluções ao longo da carreira.


Curiosidades

  • Muitos bancos possuem verdadeiras "enciclopédias" internas de ABENDs, acumuladas ao longo de décadas.

  • Alguns ABENDs praticamente desapareceram com compiladores modernos, enquanto outros continuam comuns porque dependem de erros de lógica ou configuração.

  • Um mesmo problema de negócio pode gerar ABENDs diferentes dependendo se a execução ocorre em batch, CICS ou sob o Language Environment.

  • Desenvolvedores experientes frequentemente identificam a causa provável apenas ao ouvir um código como S0C7 ou S806, antes mesmo de abrir o dump.


Conclusão

O maior erro de um iniciante é imaginar que um ABEND representa apenas um defeito no programa COBOL.

Na realidade, um ABEND é uma mensagem do ecossistema IBM Z. Ele informa que alguma camada — aplicação, JCL, compilador, Language Environment, CICS, JES2, arquivos, armazenamento ou o próprio z/OS — encontrou uma condição que impediu a continuidade segura da execução.

Aprender a interpretar esses códigos é um divisor de águas. O programador deixa de ser apenas alguém que escreve COBOL e passa a compreender como o sistema operacional, o ambiente batch e o ambiente transacional trabalham em conjunto.

Como todo Padawan descobre cedo ou tarde: escrever o programa é apenas parte do trabalho. O verdadeiro domínio começa quando se entende por que ele executa, por que falha e como o IBM Z revela exatamente onde procurar a causa.


sexta-feira, 26 de julho de 2013

☕🔥 ABEND S013 — O “GUARDIÃO DOS DATASETS” NO z/OS

 

Bellacosa Mainframe abend s013

☕🔥 ABEND S013 — O “GUARDIÃO DOS DATASETS” NO z/OS

Quando o Mainframe Diz:

“VOCÊ ESTÁ TENTANDO USAR O ARQUIVO DO JEITO ERRADO.”

Se existe um ABEND que faz o programador COBOL Junior questionar:

“O problema é no JCL?”
“No arquivo?”
“No DCB?”
“No RECFM?”
“No LRECL?”
“NO UNIVERSO?!”

…esse ABEND é o lendário:

🚨 S013

E normalmente ele aparece assim:

IEC141I 013-20

ou:

ABEND=S013

ou:

IEC141I 013-34

☕ Respira, Padawan.

Porque o S013 é um dos ABENDs MAIS IMPORTANTES para aprender:

dataset organization

DCB

RECFM

LRECL

BLKSIZE

OPEN/CLOSE/EOV

integridade física do arquivo


🔥 O QUE É O S013?

O S013 é um:

🚨 DCB / DATASET OPEN ERROR

Traduzindo:

O z/OS NÃO CONSEGUIU ABRIR O DATASET CORRETAMENTE.


☕ A FILOSOFIA DO S013

O dataset existe.

O JCL existe.

O programa existe.

Mas:

ALGUMA CARACTERÍSTICA DO ARQUIVO NÃO BATE.


🔥 O MAINFRAME É OBCECADO POR ESTRUTURA

No mundo distribuído:

abre arquivo

No z/OS:

qual RECFM?
qual LRECL?
qual BLKSIZE?
FB?
VB?
VBS?
U?
QSAM?
VSAM?

Porque:

arquivo no mainframe é estrutura física rigorosa.


☕ ANALOGIA BELLACOSA MAINFRAME

Imagine um trem tentando entrar num túnel.

Mas:

  • largura errada

  • altura errada

  • trilho incompatível

Resultado:

💥 S013


🔥 O MOMENTO EXATO DO S013

Fluxo:

COBOL OPEN
 ↓
OPEN/CLOSE/EOV
 ↓
Validação DCB
 ↓
Mismatch
 ↓
S013

☕ O QUE É DCB?

DATA CONTROL BLOCK

O DNA do dataset.

Define:

  • RECFM

  • LRECL

  • BLKSIZE

  • DSORG


🔥 O S013 MAIS FAMOSO

🚨 S013-20

O rei absoluto dos juniors.


☕ O QUE SIGNIFICA S013-20?

DCB incompatível

Geralmente:

  • RECFM errado

  • LRECL errado

  • programa espera algo diferente


🔥 EXEMPLO CLÁSSICO

Arquivo real:

RECFM=FB
LRECL=80

Mas COBOL define:

FD CLIENTE
   RECORD CONTAINS 120 CHARACTERS.

Resultado:

☠️ S013-20


☕ O MAINFRAME OLHA E DIZ

“O TAMANHO NÃO BATE.”


🔥 OUTRO CLÁSSICO

Arquivo:

VB

Programa espera:

FB

Resultado:

💥 S013


☕ FB vs VB — A GUERRA ETERNA


☕ FB

Fixed Block.

Todos registros possuem mesmo tamanho.


☕ VB

Variable Block.

Registros variáveis.

Possui RDW.


🔥 O RDW — O BYTE FANTASMA

VB possui:

Record Descriptor Word

4 bytes extras no início.

Junior esquece isso.

Resultado:

☠️ caos absoluto.


☕ O S013 E O COBOL

Outro clássico:

01 REGISTRO PIC X(100).

Mas dataset:

LRECL=80

Resultado:

💥 S013


🔥 O S013 E O SORT

SORT cria dataset:

VB

Programa batch espera:

FB

Explosão inevitável.


☕ O S013 E O DISP

Outro caso famoso.

//ARQ DD DISP=OLD

Mas dataset não permite acesso correto.

Ou:

  • está vazio

  • está corrompido

  • organização errada


🔥 O S013-14

Muito ligado a:

OPEN ERROR

Problemas físicos/lógicos na abertura.


🔥 O S013-18

Associado a:

DCB inconsistente


🔥 O S013-34

Muito famoso em:

RECFM incompatível


☕ COMO INVESTIGAR O S013 PASSO A PASSO


✅ PASSO 1 — IDENTIFIQUE O SUBCÓDIGO

Exemplo:

013-20

O número após hífen é crucial.


✅ PASSO 2 — IDENTIFIQUE O DDNAME

Mensagem:

IEC141I 013-20,JOB1,STEP01,CLIENTE

DDNAME:

CLIENTE

✅ PASSO 3 — VERIFIQUE O DATASET

Use:

3.4 ISPF

ou:

LISTDSI

Verifique:

  • RECFM

  • LRECL

  • BLKSIZE

  • DSORG


✅ PASSO 4 — VERIFIQUE O FD COBOL

Exemplo:

FD CLIENTE
01 REG-CLIENTE PIC X(120).

Compare com dataset REAL.


✅ PASSO 5 — VERIFIQUE O JCL

Talvez:

DCB=(RECFM=FB,LRECL=80)

mas programa espera:

120

🔥 O SEGREDO DOS DUMPS

S013 normalmente NÃO exige dump profundo estilo S0C4.

O ouro está nas:

mensagens IEC


☕ AS MENSAGENS IEC SÃO A BÍBLIA

Exemplo:

IEC141I
IEC143I
IEC130I

Elas contam:

  • dataset

  • problema

  • DCB

  • incompatibilidade


🔥 COMO O VETERANO PENSA

Veterano vê:

013-20

E imediatamente pergunta:

“FB ou VB?”


☕ O MAIOR ERRO DOS JUNIORS

Pensar:

“O problema está no COBOL.”

Frequentemente está em:

  • JCL

  • DCB

  • dataset

  • utilitário

  • SORT anterior


🔥 O S013 E O IDCAMS

Outro clássico.

DEFINE CLUSTER cria:

LRECL diferente

Programa usa layout antigo.

Resultado:

💥 S013


☕ O S013 E O GDG

Geração nova criada com DCB errado.

Toda cadeia explode depois.


🔥 O S013 FANTASMA

O mais traiçoeiro.

Problema nasceu:

ontem

Mas explode:

hoje

Porque dataset foi criado incorretamente antes.


☕ O S013 E O “RECFM U”

Modo arquimago ativado.

Datasets:

RECFM=U

são “Undefined”.

Muito usados em:

  • loadlibs

  • executáveis

  • dumps

Ler isso como FB?

☠️ desastre garantido.


🔥 COMO EVITAR S013


✅ Sempre validar RECFM


✅ Sempre validar LRECL


✅ Revisar DCB no JCL


✅ Padronizar copybooks


✅ Conferir SORTs


✅ Verificar geração GDG


✅ Nunca assumir FB/VB


☕ O SEGREDO DO IEBGENER

Ferramenta clássica para testar datasets.

Veteranos usam para:

  • validar DCB

  • testar leitura

  • confirmar estrutura


🔥 CURIOSIDADE HISTÓRICA

O S013 vem dos tempos do:

IBM OS/360

Década de:

🏛️ 1960

Naquela época:

  • fitas

  • discos

  • blocagem física

eram fundamentais.

O sistema precisava garantir:

integridade absoluta da mídia.


☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S013 é o dataset dizendo:

VOCÊ NÃO ME ENTENDE.”


🔥 O MAIOR APRENDIZADO

S013 ensina algo profundo:

NO MAINFRAME, ARQUIVO NÃO É “SÓ UM ARQUIVO”.

É:

  • geometria

  • física

  • organização

  • blocagem

  • arquitetura


☕ A VERDADE FINAL

O S0C7 pune números inválidos.
O S0C4 pune memória inválida.
Mas…

☕ O S013 PUNE QUEM NÃO RESPEITA A ESTRUTURA SAGRADA DOS DATASETS NO z/OS.

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
GitHub LinkedIn
Inicializando conteúdo...