 |
| Bellacosa Mainframe e o abend S213 |
☕🔥 ABEND S213 — O “GUARDIÃO DO DATASET” NO z/OS
Quando o Mainframe Diz: “VOCÊ NÃO TEM ACESSO A ISSO!”
Se você é um COBOL Junior Padawan entrando no universo z/OS… cedo ou tarde vai encontrar um dos ABENDs mais clássicos do mundo mainframe:
🚨 S213
E normalmente ele aparece assim:
IEC150I 913-38,IFG0194A,JOBNAME,STEP1,DDNAME,...
IEF450I JOBNAME STEP1 - ABEND=S213 U0000
Ou:
ABEND S213-04
ABEND S213-30
ABEND S213-38
E aí bate o desespero:
“MEU COBOL ESTÁ ERRADO?”
“O JCL ESTÁ QUEBRADO?”
“O DATASET SUMIU?”
“O JES2 ME ODEIA?”
Calma, Padawan. ☕
O S213 é um dos ABENDs MAIS DIDÁTICOS do z/OS.
🔥 O QUE É O ABEND S213?
O S213 é um:
🚨 SYSTEM ABEND
Gerado pelo próprio z/OS durante OPEN do dataset.
Traduzindo:
Seu programa, SORT, IDCAMS, COBOL ou utilitário tentou abrir um dataset…
E o sistema respondeu:
❌ “ACESSO NEGADO.”
🧠 O SIGNIFICADO REAL
O S213 normalmente envolve:
Falta de permissão RACF
Dataset protegido
Tentativa de acesso incompatível
Volume incorreto
DISPosition inadequado
Conflito de acesso
Dataset em uso exclusivo
Segurança SAF/RACF/A2/TopSecret
☕ A FILOSOFIA DO S213
O S213 NÃO significa necessariamente:
❌ “dataset não existe”
Ele significa:
“O SISTEMA IMPEDIU VOCÊ DE USAR O DATASET.”
Isso é MUITO importante.
🔥 O MOMENTO EXATO DO ABEND
Imagine:
COBOL -> OPEN INPUT CLIENTE
O COBOL chama:
OPEN
O OPEN chama:
OPEN/CLOSE/EOV
O z/OS consulta:
Catalog
VTOC
RACF
Volume
DISP
Integridade
Se algo falha:
💥 S213
🚨 OS SUBCÓDIGOS MAIS COMUNS
🔥 S213-04
Dataset não encontrado no volume especificado
Exemplo:
//ARQ DD DSN=EMPRESA.CLIENTES,
// VOL=SER=DISK01
Mas o dataset está em:
DISK02
Resultado:
S213-04
🔥 S213-30
Problema de integridade/acesso
Muito comum em:
Dataset em uso
DISP errado
Acesso incompatível
Exemplo clássico:
Dois jobs tentando:
DISP=OLD
ao mesmo tempo.
O sistema protege o dataset.
🔥 S213-38
🚨 O MAIS FAMOSO
FALTA DE AUTORIZAÇÃO (RACF)
O usuário NÃO possui permissão.
Esse é o “Access Denied” do mundo z/OS.
☕ EXEMPLO CLÁSSICO COBOL JUNIOR
Você recebe:
//CLIENTE DD DSN=PROD.CLIENTES.MESTRE,
// DISP=SHR
Seu COBOL:
OPEN INPUT CLIENTE
Resultado:
IEC150I 913-38
ABEND S213-38
O que aconteceu?
O RACF avaliou:
USER = DEVJR01
RESOURCE = PROD.CLIENTES.MESTRE
ACCESS = READ
E respondeu:
❌ ACCESS DENIED
🔥 COMO O RACF DECIDE ISSO?
O RACF consulta:
Perfil do dataset
Grupo do usuário
ACL
Permissões READ/UPDATE/CONTROL/ALTER
🧠 O QUE O JÚNIOR PRECISA APRENDER
Mainframe NÃO é PC.
No Windows:
abre arquivo
No z/OS:
posso abrir?
quem é você?
qual grupo?
qual nível?
dataset protegido?
outro job usando?
qual intenção?
O mainframe assume:
🔐 TUDO É CRÍTICO
Porque geralmente É.
🔥 COMO ANALISAR O S213 PASSO A PASSO
☕ PASSO 1 — IDENTIFIQUE O SUBCÓDIGO
Veja:
S213-38
ou:
IEC150I 913-38
O número após o hífen é o segredo.
☕ PASSO 2 — LOCALIZE O DDNAME
Exemplo:
IEC150I 913-38,IFG0194A,JOB1,STEP01,CLIENTE,...
DDNAME:
CLIENTE
Agora você sabe QUAL dataset causou o erro.
☕ PASSO 3 — VEJA O DSN NO JCL
Procure:
//CLIENTE DD DSN=...
☕ PASSO 4 — ANALISE O DISP
Exemplo problemático:
DISP=OLD
Talvez devesse ser:
DISP=SHR
☕ PASSO 5 — VERIFIQUE RACF
Pergunte:
Tenho READ?
Tenho UPDATE?
O dataset é PROD?
Está protegido?
☕ PASSO 6 — ANALISE O JESMSGLG
Ali está a VERDADE.
Muitos juniors olham apenas:
ABEND=S213
Mas o ouro está antes.
Mensagens:
IECxxx
ICH408I
IRRxxxx
contam a história completa.
🔥 O ICH408I — O “DEDO DURO” DO RACF
Quando existe falta de permissão:
ICH408I USER(USER01 ) GROUP(DEV )
NAME(VAGNER )
PROD.CLIENTES.MESTRE CL(DATASET )
INSUFFICIENT ACCESS AUTHORITY
ACCESS INTENT(READ )
ACCESS ALLOWED(NONE )
Aqui o RACF praticamente confessa tudo.
☕ COMO LER ISSO
ACCESS INTENT
O que você tentou fazer.
Exemplo:
READ
UPDATE
ACCESS ALLOWED
O que você realmente possui.
Exemplo:
NONE
READ
🔥 A PEGADINHA DO DISP=MOD
Junior clássico:
DISP=MOD
sem perceber.
O sistema entende:
“ELE QUER ESCREVER.”
Então READ não basta.
Agora precisa UPDATE.
Resultado:
S213-38
☕ O S213 E O OPEN DO COBOL
Outro detalhe importante:
O ABEND normalmente ocorre:
NO OPEN
Não no READ.
Porque o sistema valida o dataset ANTES.
Então:
DISPLAY 'ANTES OPEN'
OPEN INPUT CLIENTE
DISPLAY 'DEPOIS OPEN'
Você verá:
ANTES OPEN
E nunca verá:
DEPOIS OPEN
🔥 COMO ENTENDER O DUMP
O dump do S213 normalmente não exige análise profunda de storage como um S0C7.
O segredo está nas mensagens do sistema.
🧠 ONDE OLHAR
JESMSGLG
Mensagens do sistema.
SYSLOG
Pode conter RACF.
SDSF
ST
LOG
O
DA
IPCS (casos extremos)
Raramente necessário para S213 simples.
🔥 A ORIGEM HISTÓRICA
O “S” significa:
SYSTEM ABEND
O número 213 vem das antigas tabelas internas de erros do OS/360.
Estamos falando de uma herança dos anos:
🏛️ 1960
Sim…
Seu S213 possui DNA do OS/360.
☕ CURIOSIDADE HISTÓRICA
Nos anos 70/80:
Operadores aprendiam a reconhecer ABENDs “de ouvido”.
Quando aparecia:
213-38
já sabiam:
“RACF pegou alguém.”
🔥 EASTER EGG MAINFRAME
Muitos veteranos brincam:
“S213-38 é o firewall espiritual do z/OS.”
Porque ele aparece exatamente quando alguém tenta acessar algo proibido.
☕ DIFERENÇA ENTRE S213 E S806
Juniors confundem muito.
S213
Problema com DATASET.
S806
Programa não encontrado.
🔥 DIFERENÇA ENTRE S213 E FILE STATUS 35
FILE STATUS 35
Erro COBOL lógico.
Arquivo não encontrado.
S213
Erro SISTÊMICO do z/OS.
Muito mais baixo nível.
🧠 O QUE O PADAWAN PRECISA GUARDAR
S213 NÃO É “erro do COBOL”.
É:
🔐 z/OS protegendo integridade e segurança.
☕ CHECKLIST DE SOBREVIVÊNCIA
Quando aparecer:
S213-xx
Faça:
✅ Ver subcódigo
✅ Identificar DDNAME
✅ Conferir DSN
✅ Conferir DISP
✅ Procurar ICH408I
✅ Validar RACF
✅ Verificar volume
✅ Verificar dataset em uso
✅ Ler JESMSGLG inteiro
✅ Não entrar em pânico ☕
🔥 FRASE FINAL DO MUNDO MAINFRAME
O S0C7 humilha.
O S806 confunde.
Mas…
Sem comentários:
Enviar um comentário