 |
| Bellacosa Mainframe e o abend s913 |
☕🔥 ABEND S913 — O “MURO DE SEGURANÇA” DO z/OS
Quando o Mainframe Diz:
“VOCÊ NÃO TEM AUTORIZAÇÃO PARA FAZER ISSO.”
Se existe um ABEND que faz TODO Junior Padawan descobrir que:
segurança no mainframe é levada MUITO a sério…
é o lendário:
🚨 S913
E normalmente ele aparece assim:
IEF450I JOBNAME STEP01 - ABEND=S913
ou:
ICH408I USER NOT AUTHORIZED
ou ainda:
IEC150I 913-38
E então começa o pânico:
“Mas o dataset existe!”
“O JCL está certo!”
“Funcionava ontem!”
“O RACF me odeia?”
“O z/OS acabou de me expulsar do castelo?”
☕ Respira.
Porque o S913 é um dos ABENDs MAIS IMPORTANTES para entender:
RACF
segurança z/OS
autorização
datasets protegidos
acesso batch
permissões
auditoria corporativa
🔥 O QUE É O S913?
O S913 é um:
🚨 SECURITY / AUTHORIZATION FAILURE
Traduzindo:
O z/OS NEGOU ACESSO A UM RECURSO.
☕ A FILOSOFIA DO S913
No mundo mainframe:
NADA É ACESSADO SEM AUTORIZAÇÃO.
Nem:
dataset
transação
programa
loadlib
tape
recurso CICS
DB2
spool
🔥 O GRANDE SEGREDO
O S913 normalmente NÃO é erro de COBOL.
É:
erro de segurança.
☕ ANALOGIA BELLACOSA MAINFRAME
Imagine um cofre bancário.
Você possui:
✅ crachá
✅ login
✅ senha
Mas tenta entrar numa área:
❌ sem autorização.
O segurança aparece imediatamente.
Isso é o:
☠️ S913
🔥 O VERDADEIRO VILÃO
🚨 RACF
Ou equivalentes:
☕ O QUE É RACF?
Resource Access Control Facility
O guardião do z/OS.
Controla:
quem acessa
o quê
quando
como
com qual permissão
🔥 O MOMENTO EXATO DO S913
Fluxo:
Programa/JCL tenta acessar recurso
↓
SAF/RACF intercepta
↓
Valida permissão
↓
Acesso negado
↓
S913
☕ O CASO MAIS CLÁSSICO
DATASET SEM AUTORIZAÇÃO
🔥 EXEMPLO
//CLIENTE DD DSN=EMPRESA.FINANCEIRO.MASTER,
// DISP=SHR
Mas o usuário NÃO possui acesso.
Resultado:
💥 S913
☕ O MAINFRAME OLHA E DIZ
“VOCÊ NÃO TEM PERMISSÃO PARA VER ISSO.”
🔥 O IEC150I 913-38
Lenda clássica do z/OS.
☕ O QUE SIGNIFICA?
Frequentemente:
dataset authorization failure.
🔥 O ICH408I — A MENSAGEM SAGRADA
Essa é ouro puro.
Exemplo:
ICH408I USER(USER01) GROUP(GRP1)
NAME(USER TESTE)
EMPRESA.FINANCEIRO CL(DATASET)
INSUFFICIENT ACCESS AUTHORITY
Isso revela:
usuário
grupo
recurso
classe
nível negado
☕ O MAIOR ERRO DO PADAWAN
Ver:
S913
e recompilar COBOL.
Não.
O problema geralmente NÃO está no código.
🔥 O S913 E O DISP=OLD
Outro clássico.
☕ EXEMPLO
//ARQ DD DISP=OLD
Mas usuário só possui:
READ
Não possui:
UPDATE
Resultado:
☠️ S913
🔥 O S913 E O LOADLIB
Até executáveis possuem proteção.
☕ EXEMPLO
//STEPLIB DD DSN=EMPRESA.PROD.LOAD
Sem permissão de EXECUTE/READ:
💥 S913
🔥 O S913 E O CICS
No CICS isso aparece MUITO como:
NOTAUTH
AEY9
RACF violation
☕ O S913 E O DB2
Outro território sombrio.
Usuário tenta:
SELECT * FROM CLIENTES
Sem permissão.
DB2 chama RACF/segurança.
Resultado:
☠️ acesso negado.
🔥 O S913 E O JES2
Até o spool pode ser protegido.
Você tenta:
cancelar job
ver output
acessar SYSOUT
Sem autorização:
💥 S913
☕ O S913 E O FTP
Clássico enterprise.
Usuário tenta transferir:
dataset protegido
FTP recebe:
permission denied.
Origem real:
RACF.
🔥 COMO INVESTIGAR O S913 PASSO A PASSO
✅ PASSO 1 — PROCURE ICH408I
Essa mensagem é a Bíblia do S913.
✅ PASSO 2 — IDENTIFIQUE O RECURSO
Exemplo:
EMPRESA.ARQ.CLIENTE
✅ PASSO 3 — IDENTIFIQUE O TIPO DE ACESSO
Pergunte:
Tentou:
READ?
UPDATE?
ALTER?
EXECUTE?
✅ PASSO 4 — VERIFIQUE DISP
☕ DISP=SHR
Normalmente leitura.
☕ DISP=OLD
Controle exclusivo/update.
☕ DISP=MOD
Alteração.
🔥 PASSO 5 — FALE COM SEGURANÇA/RACF
Sim.
Mainframe é trabalho em equipe.
☕ O DUMP DO S913
Muitas vezes:
dump quase irrelevante.
Porque o erro é de autorização.
O ouro está nas mensagens:
🔥 O S913 E O “FUNCIONAVA ONTEM”
O clássico absoluto.
☕ O QUE ACONTECEU?
Talvez:
RACF mudou
grupo mudou
perfil mudou
dataset foi recatalogado
ACL alterada
migração ocorreu
🔥 O S913 FANTASMA
Outro terror real.
Job A cria dataset.
Job B tenta acessar.
Mas:
owner/permissão mudou.
Resultado:
💥 S913
☕ O S913 E O PROTECTED DATASETS
Datasets críticos costumam ser blindados:
folha salarial
financeiro
cartões
PIX
banking core
produção
O RACF leva isso MUITO a sério.
🔥 O S913 E O AUDITOR
Toda violação geralmente fica registrada.
Mainframe possui auditoria fortíssima.
☕ O S913 E O OPERADOR
Até operadores podem ter limites.
No z/OS:
privilégio é granular.
🔥 O S913 E O SURROGAT
Modo arquimago ativado.
Jobs submetidos em nome de outros usuários podem falhar por:
surrogate authorization.
☕ O S913 E O APF
Bibliotecas APF também possuem proteção pesada.
🔥 O SEGREDO DOS VETERANOS
Veteranos sempre perguntam:
“QUAL RECURSO FOI NEGADO?”
Porque o S913 é:
sintoma.
O alvo verdadeiro está na mensagem RACF.
☕ COMO EVITAR S913
✅ Validar permissões antes
✅ Revisar DISP
✅ Entender READ vs UPDATE
✅ Validar grupos RACF
✅ Revisar mudanças de segurança
✅ Evitar hardcode de datasets protegidos
✅ Trabalhar junto com equipe RACF
🔥 CURIOSIDADE HISTÓRICA
O S913 nasceu na era em que:
bancos começaram a depender totalmente do mainframe.
IBM percebeu cedo que segurança corporativa precisava ser:
rígida
auditável
centralizada
RACF virou um dos sistemas de segurança mais respeitados do mundo.
☕ EASTER EGG MAINFRAME
Veteranos brincam:
“S913 significa:
Você Tentou Entrar Onde Não Devia.”
🔥 O MAIOR ENSINAMENTO DO S913
Ele ensina algo profundo:
no z/OS, SEGURANÇA vem antes da conveniência.
Não importa:
se o programa funciona
se o JCL está perfeito
se o COBOL compilou
Sem autorização:
nada acontece.
☕ A VERDADE FINAL
O S0C7 pune dados inválidos.
O S0C4 pune memória inválida.
O S806 pune programas inexistentes.
O S878 pune fragmentação de storage.
Mas…
☕ O S913 É O MOMENTO EM QUE O z/OS OLHA PARA VOCÊ… E DECIDE QUE VOCÊ NÃO TEM PERMISSÃO PARA PASSAR PELO PORTÃO.
