Translate

Mostrar mensagens com a etiqueta seguranca mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta seguranca mainframe. Mostrar todas as mensagens

sexta-feira, 15 de maio de 2026

☕💣 15 COISAS SOBRE SMP/E QUE TODO SYSProg JUNIOR DESCOBRE TARDE DEMAIS ☕💣

 

Bellacosa Mainframe e uma lista com 15 curiosidades sobre o SMP/E

☕💣 15 COISAS SOBRE SMP/E QUE TODO SYSProg JUNIOR DESCOBRE TARDE DEMAIS ☕💣

O SMP/E parece “só um instalador”.

Até o dia em que ele destrói seu APPLY, trava uma maintenance window ou começa uma guerra silenciosa com o RACF às 3 da manhã.

Aí você percebe:

o SMP/E não é ferramenta.
É uma entidade cósmica do z/OS.

Então pega o café porque aqui vão algumas das curiosidades mais fascinantes — e assustadoras — do universo SMP/E.


☕ 1 — O SMP/E EXISTE DESDE A ERA DOS DINOSSAUROS CORPORATIVOS

Antes do SMP/E existia o:

SMP (System Modification Program)

O “E” de Extended veio depois.

E mesmo assim MUITA lógica histórica do MVS clássico ainda vive dentro dele.

Ou seja:

parte do SMP/E moderno carrega DNA dos anos 70.

☕ 2 — O CSI É BASICAMENTE O “BANCO DE DADOS DA VERDADE”

O CSI:

Consolidated Software Inventory

é o coração do SMP/E.

Ele sabe:

  • o que está instalado,

  • o que falta,

  • pré-requisitos,

  • dependências,

  • supersedes,

  • HOLDDATA.

Se o CSI corromper:

o desespero psicológico começa.

☕ 3 — APPLY NÃO INSTALA “ARQUIVOS”

Essa é uma das maiores surpresas para iniciantes.

O SMP/E NÃO funciona igual Windows Installer.

Ele trabalha com:

  • ELEMENTS,

  • MODs,

  • MACs,

  • SRCs,

  • RELFILEs,

  • SYSMODs.

Ou seja:

o SMP/E pensa em engenharia de software,
não em “copiar arquivo”.

☕ 4 — O RECEIVE ORDER FEZ O MAINFRAME ENTRAR NA INTERNET SEM FAZER BARULHO

Muita gente acha que cloud inventou automação.

Enquanto isso o z/OS já fazia:

  • download automático,

  • SSL/TLS,

  • autenticação por certificado,

  • automação de manutenção,

anos antes de muita startup existir.


☕ 5 — O SMP/E USA JAVA… E ISSO ASSUSTA VETERANOS

Nada é mais engraçado que ver um SYSProg raiz descobrir:

javahome=
classpath=

dentro de uma JCL SMP/E.

O sujeito cresceu no:

IEBGENER
IDCAMS
IEFBR14

e de repente precisa debugar TLS Java.


☕ 6 — O HOLDDATA É O “SISTEMA NERVOSO” DA MANUTENÇÃO

HOLDDATA não é “só um arquivo”.

Ele avisa:

  • PTF problemática,

  • conflito,

  • ação manual,

  • PE error,

  • bypass necessário.

Veteranos respeitam HOLDDATA como:

um oráculo antigo do datacenter.

☕ 7 — EXISTE GENTE QUE TEM MEDO DE CONTENT(ALL)

E com razão.

O primeiro:

RECEIVE ORDER CONTENT(ALL)

de um ambiente antigo pode baixar um apocalipse de manutenção acumulada.

Tem ambiente que parece:

um tsunami de PTFs vindo do passado.

☕ 8 — O SMP/E CONSEGUE SABER DEPENDÊNCIAS MELHOR QUE MUITO GERENTE

Ele entende:

  • pré-requisitos,

  • co-requisitos,

  • supersedes,

  • incompatibilidades.

Ou seja:

o SMP/E sabe mais sobre o software do banco
do que metade da equipe.

☕ 9 — RACF E SMP/E TÊM UMA RELAÇÃO COMPLICADA

Quando SSL entra na história…

o SYSProg descobre:

  • keyring,

  • certificados,

  • trust chain,

  • RDATALIB,

  • DIGTCERT.

E aí nasce o clássico:

“isso é problema do RACF ou do SMP/E?”

Ninguém sabe.


☕ 10 — O SMP/E É MAIS PRÓXIMO DE UM GERENCIADOR DEVOPS DO QUE VOCÊ IMAGINA

Na prática ele já fazia:

  • versionamento,

  • rollback lógico,

  • controle de dependência,

  • inventory,

  • automação,

  • compliance.

Muito antes da palavra DevOps virar moda.


☕ 11 — APPLY CHECK SALVOU MAIS CARREIRAS QUE BACKUP

Veteranos SEMPRE fazem:

APPLY CHECK

Porque APPLY direto é:

esporte radical corporativo.

☕ 12 — O SMP/E NÃO “ESQUECE” FACILMENTE

O CSI guarda histórico detalhado.

Então quando alguém pergunta:

“quem aplicou isso?”

o SMP/E normalmente sabe.

É praticamente auditoria forense do z/OS.


☕ 13 — EXISTEM SYSProgs QUE AMAM MAIS O SMP/E QUE O ISPF

Parece exagero.

Até você perceber que:

um bom SYSProg mede estabilidade pela qualidade da maintenance strategy.

☕ 14 — O RECEIVE ORDER TRANSFORMOU O MAINFRAME EM UM CLIENTE CLOUD

Isso parece absurdo.

Mas o z/OS hoje:

  • autentica via TLS,

  • usa certificados digitais,

  • conversa com APIs,

  • baixa conteúdo remoto,

  • automatiza updates.

Ou seja:

o mainframe virou um cidadão da internet moderna.

☕ 15 — O SMP/E ENSINA UMA LIÇÃO BRUTAL SOBRE O z/OS

O iniciante acha que mainframe é:

“tela verde e COBOL”

O SMP/E mostra que o mundo real é:

  • engenharia de software,

  • segurança enterprise,

  • criptografia,

  • automação,

  • integração,

  • compliance,

  • arquitetura crítica.

E talvez seja por isso que o z/OS continua vivo.

Porque no final…

ninguém no planeta leva manutenção enterprise tão a sério quanto o mainframe.

quinta-feira, 14 de maio de 2026

☕🔐 SMP/E INTERNET SERVICE RETRIEVAL — O “WINDOWS UPDATE” DO MAINFRAME QUE TRANSFORMOU O SYSProg EM UM ENGENHEIRO DE SEGURANÇA ENTERPRISE ☕🔐

 

Bellacosa Mainframe e o SMP/E o poder da atualização do Sysprog

☕🔐 SMP/E INTERNET SERVICE RETRIEVAL — O “WINDOWS UPDATE” DO MAINFRAME QUE TRANSFORMOU O SYSProg EM UM ENGENHEIRO DE SEGURANÇA ENTERPRISE ☕🔐

Existe um momento na vida de todo profissional de mainframe em que ele percebe uma verdade brutal:

O z/OS deixou de ser “apenas um sistema operacional”.

Ele virou uma fortaleza criptográfica conectada à internet.

E poucos exemplos mostram isso tão bem quanto o SMP/E Internet Service Retrieval.

Lançado oficialmente nas gerações modernas do SMP/E do z/OS no início dos anos 2000 e amplamente consolidado durante a era z/OS 1.10/1.11 em diante, esse recurso mudou completamente a forma como o mainframe recebe manutenção.
E diferente de muitos recursos clássicos do universo IBM, ele nunca foi oficialmente retirado do mercado — pelo contrário: tornou-se praticamente obrigatório no ecossistema moderno de manutenção enterprise.


☕ O DIA EM QUE O SMP/E PAROU DE SER “SÓ UM INSTALADOR”

Antigamente, baixar manutenção para mainframe parecia operação militar.

O SYSProg precisava:

  • entrar no portal do fabricante,
  • procurar PTF manualmente,
  • baixar arquivos,
  • transferir para o z/OS,
  • organizar datasets,
  • conferir HOLDDATA,
  • aplicar RECEIVE/APPLY/CHECK.

Era praticamente um ritual xamânico corporativo.

Então surgiu o RECEIVE ORDER via internet.

E o jogo mudou.

Agora o próprio SMP/E:

consulta servidores,
autentica via SSL,
baixa manutenção,
valida certificados,
e entrega tudo pronto no z/OS.

O que antes parecia um processo artesanal virou quase um:

yum install do mundo mainframe.

☕ O SYSProg MODERNO VIROU UM “ENGENHEIRO DE PKI”

E aqui está a parte que muita gente fora do z/OS não entende.

Para configurar SMP/E Internet Service Retrieval, você NÃO aprende só SMP/E.

Você aprende:

  • SSL/TLS,
  • PKI,
  • certificados X.509,
  • RACF Digital Certificates,
  • ACF2,
  • Top Secret,
  • Java no z/OS,
  • USS,
  • segurança enterprise,
  • autenticação criptográfica.

Ou seja:

o SYSProg moderno virou meio administrador Linux,
meio especialista em segurança,
meio engenheiro de criptografia.

☕ O MAINFRAME AGORA FALA HTTPS COMO UM NAVEGADOR MODERNO

Esse é o detalhe mais fascinante.

O SMP/E literalmente age como um cliente HTTPS corporativo.

Ele conversa com:

Broadcom Order Server
Broadcom Download Server

usando:

  • SSL,
  • certificados digitais,
  • trust chain,
  • autenticação mútua.

Sim.

O z/OS está fazendo praticamente o mesmo tipo de handshake TLS que:

  • Chrome,
  • Firefox,
  • Edge,
  • APIs REST modernas.

Só que dentro do coração bancário do planeta.


☕ O “CHAVEIRO DIGITAL” DO MAINFRAME

A parte mais linda disso tudo é o conceito de KEYRING.

O nome parece inocente.

Mas o keyring é basicamente:

o cofre de identidade digital do z/OS.

Ali ficam:

  • certificados pessoais,
  • certificados trusted,
  • chaves privadas,
  • cadeias de confiança.

Sem keyring:

não existe SSL no mundo mainframe.

☕ RACF, ACF2 E TOP SECRET — A GUERRA DOS IMPÉRIOS

Uma das coisas mais clássicas do universo z/OS aparece aqui:

Cada ESM faz tudo de um jeito diferente.

O curso mostra comandos para:

  • RACF,
  • CA ACF2,
  • CA Top Secret.

E isso revela uma verdade histórica maravilhosa:

no mainframe até os certificados têm guerra política.

O RACF virou o padrão dominante.

Mas ACF2 e Top Secret ainda vivem fortíssimos em bancos, seguradoras e governos.

E cada ambiente tem sua própria “religião operacional”.


☕ O ERRO QUE TODO SYSProg COMETE PELO MENOS UMA VEZ

O material mostra algo que parece pequeno:

RECFM=VB
LRECL=84
ASCII

Mas aqui mora o terror psicológico do SMP/E moderno.

Porque basta transferir um certificado errado…

e o inferno começa.

Você ganha:

SSL handshake failure
GSK_ERROR_BAD_CERT
certificate validation error

E aí começa o clássico ritual do SYSProg:

  • olhar JESMSGLG,
  • abrir IPCS,
  • conferir encoding,
  • verificar RACDCERT,
  • revisar keyring,
  • discutir com segurança,
  • culpar firewall,
  • descobrir depois que o FTP foi BINÁRIO.

☕ O DETALHE MAIS ASSUSTADOR: JAVA

Sim.

JAVA.

O SMP/E moderno depende de Java para HTTPS.

Isso quebra completamente a cabeça do velho operador de MVS raiz.

Porque o sujeito que cresceu no:

IEBGENER
IDCAMS
IEHLIST

agora precisa entender:

classpath
javahome
TLS stack
USS

É a colisão definitiva:

mainframe clássico VS infraestrutura moderna.

☕ CONTENT(ALL) — O BOTÃO DO APOCALIPSE

Existe uma parte especialmente perigosa no RECEIVE ORDER:

CONTENT(ALL)

Na teoria:

“baixe tudo que está faltando”

Na prática:

“prepare espaço em disco porque o tsunami de PTFs vem aí”

O primeiro RECEIVE ORDER CONTENT(ALL) de um ambiente antigo pode parecer:

um dump nuclear de manutenção acumulada.

☕ O MAINFRAME ENTROU NA ERA DA AUTOMAÇÃO

O mais fascinante é perceber o impacto histórico disso.

Durante décadas, manutenção de mainframe foi algo extremamente manual.

Hoje:

  • jobs podem ser agendados,
  • downloads automatizados,
  • HOLDDATA atualizada sozinha,
  • recomendações críticas baixadas automaticamente.

Ou seja:

o z/OS entrou oficialmente na era DevOps…
do jeito mainframe.

☕ O SYSProg MODERNO NÃO É MAIS “OPERADOR”

Esse talvez seja o maior ensinamento de todo esse tema.

Quem acha que mainframe é:

“tela preta e COBOL”

não sobrevive 10 minutos configurando SMP/E Internet Service Retrieval.

Porque aqui o profissional precisa dominar:

  • segurança,
  • rede,
  • certificados,
  • autorização,
  • Java,
  • USS,
  • automação,
  • SMP/E,
  • RACF,
  • troubleshooting SSL.

Isso não é mais “operar sistema”.

Isso é:

engenharia pesada de infraestrutura enterprise.

☕ LANÇAMENTO E STATUS HISTÓRICO

ItemInformação
TecnologiaSMP/E Internet Service Retrieval
FabricanteIBM + Broadcom ecosystem
Consolidação comercialAnos 2000
Popularização massivaEra z/OS 1.10+
FunçãoDownload automatizado de manutenção
Situação atualAinda ativa e amplamente utilizada
                            

Data de retirada                                                                                    Nunca oficialmente retirada

☕ CONCLUSÃO

O SMP/E Internet Service Retrieval é uma das provas mais impressionantes de como o mainframe evoluiu silenciosamente.

Enquanto muita gente imagina o z/OS como um fóssil corporativo…

o sistema já estava fazendo:

  • TLS enterprise,
  • autenticação criptográfica,
  • automação de manutenção,
  • integração internet/mainframe,

quando muito “sistema moderno” ainda engatinhava.

E talvez essa seja a maior ironia da computação corporativa:

o computador mais antigo do datacenter
acabou se tornando
o mais sofisticado.

sábado, 29 de março de 2014

☕🔥 ABEND S913 — O “MURO DE SEGURANÇA” DO z/OS

 

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:

  • ACF2

  • Top Secret


☕ 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:

  • ICH408I

  • IEC150I

  • IEFxxxx


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


quinta-feira, 25 de julho de 2013

☕🖥️ “O HOMEM QUE SEGURA O CAOS DIGITAL DO PLANETA” — POR QUE O SYSADMIN DE IBM Z NÃO É OPERADOR… É O ÚLTIMO GUARDIÃO DA CIVILIZAÇÃO CORPORATIVA 🌎⚡

 

Bellacosa Mainframe e o SysAdmin do Mainframe Z/OS

☕🖥️ “O HOMEM QUE SEGURA O CAOS DIGITAL DO PLANETA” — POR QUE O SYSADMIN DE IBM Z NÃO É OPERADOR… É O ÚLTIMO GUARDIÃO DA CIVILIZAÇÃO CORPORATIVA 🌎⚡

Existe um mito moderno dentro da TI corporativa:

Muita gente acredita que o mundo gira por causa da nuvem.

Errado.

O mundo gira porque existem profissionais invisíveis garantindo que os sistemas que movimentam bancos, bolsas, seguradoras, cartões, governos, aeroportos e telecomunicações simplesmente NÃO PAREM.

E no centro desse universo existe uma figura quase esquecida pela cultura pop da tecnologia:

O Sysadmin de Mainframe IBM Z.

Enquanto a internet idolatra DevOps de startup criando containers efêmeros que vivem minutos…

o Sysadmin de IBM Z administra ambientes que sustentam décadas de história operacional sem interrupção.

Não estamos falando de “subir servidor”.

Estamos falando de sustentar sistemas que carregam o DNA financeiro do planeta.


🏛️ O QUE REALMENTE É UM SYSADMIN EM IBM Z?

O Sysadmin de Mainframe é o profissional responsável por manter a infraestrutura lógica, operacional e sistêmica do ambiente z/OS funcionando com estabilidade, segurança, disponibilidade e performance extrema.

Ele é uma mistura de:

  • administrador de sistemas

  • engenheiro operacional

  • especialista em performance

  • analista de incidentes

  • arquiteto de automação

  • guardião de continuidade

  • investigador forense

  • estrategista de capacidade

  • psicólogo operacional corporativo

Na prática?

Ele garante que o caos nunca apareça para o usuário final.

Se o banco funciona…
Se o PIX passa…
Se o cartão autoriza…
Se a folha fecha…
Se a bolsa opera…
Se o avião decola…

existe uma chance gigantesca de um Sysadmin IBM Z estar mantendo tudo vivo nos bastidores.


⚙️ O UNIVERSO QUE ELE ADMINISTRA

Um Sysadmin de IBM Z normalmente trabalha com:

  • z/OS

  • JES2/JES3

  • TSO/ISPF

  • SDSF

  • RACF

  • USS (Unix System Services)

  • VTAM

  • TCP/IP

  • WLM

  • SMF/RMF

  • Sysplex

  • GDPS

  • DFSMS

  • HCD/HCM

  • IPL

  • PARMLIB

  • PROCLIB

  • Automation products

  • Storage management

  • Scheduler corporativo

  • Disaster Recovery

  • Monitoramento enterprise

  • Observabilidade

  • Performance tuning

E isso é só a superfície.

Porque o verdadeiro trabalho não é “conhecer comandos”.

É entender como todo o ecossistema corporativo respira junto.


☕ A ROTINA DIÁRIA DO SYSADMIN IBM Z

A rotina parece calma…

até você perceber que ele está observando milhares de eventos simultaneamente.

🌅 Início do dia

O dia normalmente começa analisando:

  • saúde do Sysplex

  • jobs falhados

  • consumo de CPU

  • paging

  • utilização de DASD

  • alertas de automação

  • mensagens críticas no console

  • saturação de initiators

  • filas JES2

  • espaço em spool

  • status de links

  • status de CICS/DB2/MQ

  • incidentes noturnos

  • backups

  • replicações

  • jobs batch críticos

O Sysadmin aprende algo importante muito cedo:

“O problema grave quase nunca começa grande.”

Ele começa pequeno.

Uma fila crescendo.
Um dataset enchendo.
Um job atrasando.
Um mount esquecendo.
Um buffer saturando.
Um lock estranho.
Uma mensagem ignorada.

E é exatamente aí que nasce o desastre corporativo.


🔍 O SYSADMIN COMO DETETIVE OPERACIONAL

Grande parte do trabalho é investigação.

O Sysadmin precisa interpretar sintomas.

Não basta saber que algo caiu.

Ele precisa descobrir:

  • por que caiu

  • onde começou

  • quem foi impactado

  • qual subsystem propagou o problema

  • se existe risco sistêmico

  • se o incidente pode voltar

Isso exige uma habilidade raríssima na TI moderna:

Correlação operacional.

O Sysadmin experiente enxerga padrões invisíveis.

Uma simples mensagem IEC pode indicar:

  • problema de storage

  • saturação de canal

  • erro humano

  • falha de automação

  • gargalo de batch

  • degradação de hardware

  • risco de outage

É quase medicina intensiva digital.


🧠 CONHECIMENTOS OBRIGATÓRIOS

⚡ z/OS Profundo

Não superficial.

Profundo.

O Sysadmin precisa entender:

  • address spaces

  • SRB

  • TCB

  • dispatching

  • memory management

  • cross-memory services

  • catalog

  • enqueue/dequeue

  • APF

  • authorized libraries

  • exits

  • IPL flow

  • subsystem interfaces

Porque sem isso ele não entende comportamento sistêmico.


🌐 TCP/IP E REDES

Mainframe moderno é totalmente conectado.

O Sysadmin trabalha diariamente com:

  • OSA

  • VIPA

  • Sysplex Distributor

  • FTP

  • TN3270

  • SFTP

  • AT-TLS

  • policy agents

  • firewall integration

  • certificados digitais

  • RACF digital certificates

Hoje o IBM Z é tão “network-centric” quanto qualquer ambiente Linux.


🔐 SEGURANÇA

O Sysadmin vive próximo da segurança.

Ele precisa entender:

  • RACF

  • permissões

  • dataset profiles

  • FACILITY class

  • SURROGAT

  • OPERCMDS

  • auditoria

  • compliance

  • LGPD

  • criptografia

  • MFA

  • certificados

Porque um erro pequeno pode abrir um rombo gigantesco.


📅 ROTINAS SEMANAIS

A semana do Sysadmin é recheada de manutenção preventiva.

📊 Capacity Planning

Analisar:

  • crescimento de datasets

  • tendência de CPU

  • consumo MSU

  • throughput

  • workload

  • crescimento batch

  • janelas operacionais

Mainframe não trabalha no improviso.

Tudo precisa ser previsível.


🛠️ Ajustes de Performance

O Sysadmin analisa:

  • WLM

  • RMF

  • SMF

  • contention

  • I/O bottlenecks

  • enqueue conflicts

  • dispatch delay

  • cache hit ratio

  • coupling facility behavior

Performance no IBM Z é ciência.

Pequenos ajustes podem economizar milhões.


🤖 Automação

Ambientes modernos usam:

  • System Automation

  • OPS/MVS

  • NetView

  • Control-M

  • OMEGAMON

  • Ansible

  • z/OSMF workflows

  • scripts REXX

  • observabilidade OpenTelemetry

O objetivo é simples:

Eliminar intervenção humana desnecessária.

Porque intervenção humana em produção é risco.


📆 ROTINAS MENSAIS

🔥 Disaster Recovery

O Sysadmin participa de:

  • testes de DR

  • switch de site

  • validação GDPS

  • recuperação de catálogo

  • simulação de desastre

  • restore massivo

  • recovery operacional

Aqui aparece a diferença brutal do mainframe:

O foco não é apenas “backup”.

É sobrevivência corporativa.


📈 Auditorias e Compliance

Ele participa de:

  • auditorias SOX

  • PCI-DSS

  • BACEN

  • LGPD

  • trilhas RACF

  • revisão de acessos

  • segregação de função

O Sysadmin de IBM Z frequentemente trabalha em ambientes mais regulados que muitos setores militares.


🧰 FERRAMENTAS MAIS IMPORTANTES

🖥️ SDSF

O coração operacional.

Ali vivem:

  • spool

  • console

  • jobs

  • logs

  • status operacional

Um Sysadmin experiente “lê” SDSF como piloto lê painel de avião.


📊 RMF E SMF

São a caixa-preta do sistema.

Tudo deixa rastros.

Com RMF/SMF o Sysadmin consegue:

  • reconstruir incidentes

  • analisar gargalos

  • prever crescimento

  • identificar degradações


🔍 OMEGAMON

Observabilidade enterprise real.

Permite visualizar:

  • CICS

  • DB2

  • MQ

  • JVM

  • storage

  • network

  • Sysplex

Hoje observabilidade em IBM Z é absurdamente sofisticada.


🧠 REXX

O canivete suíço operacional.

Sysadmin veterano automatiza tudo com REXX.

Porque repetir tarefa manual é desperdício de vida.


🚨 O MAIOR ERRO SOBRE SYSADMIN MAINFRAME

As pessoas imaginam que o trabalho é “legado”.

Mas a realidade é outra.

O Sysadmin IBM Z moderno trabalha com:

  • APIs

  • REST

  • automação

  • containers Linux on Z

  • observabilidade moderna

  • OpenTelemetry

  • DevOps

  • Git

  • pipelines

  • integração cloud

  • criptografia avançada

  • IA operacional

O IBM Z atual é uma fusão entre:

  • estabilidade histórica

  • engenharia crítica

  • computação moderna


🏦 POR QUE ESSE PROFISSIONAL É TÃO VALIOSO?

Porque poucos conseguem operar ambientes onde:

  • downtime custa milhões por minuto

  • falhas viram manchete nacional

  • disponibilidade precisa beirar perfeição

  • estabilidade é obrigação

  • segurança é absoluta

O Sysadmin IBM Z trabalha em ambientes onde erro operacional não significa “bug”.

Significa:

  • banco parado

  • aeroporto parado

  • pagamentos travados

  • bolsa indisponível

  • crise corporativa


☠️ O PESO PSICOLÓGICO DA FUNÇÃO

Quase ninguém fala disso.

Mas existe enorme pressão emocional.

O Sysadmin vive em estado constante de vigilância.

Ele sabe que:

  • qualquer mudança pode explodir horas depois

  • qualquer automação mal feita pode derrubar produção

  • qualquer parâmetro errado pode gerar efeito cascata

É um trabalho de responsabilidade silenciosa.

Sem glamour.

Sem palco.

Mas absurdamente estratégico.


🚀 O FUTURO DO SYSADMIN IBM Z

O futuro aponta para:

  • observabilidade baseada em IA

  • automação autônoma

  • self-healing systems

  • integração híbrida cloud/mainframe

  • DevSecOps enterprise

  • automação cognitiva

  • analytics operacional

  • detecção preditiva de falhas

Mas existe uma ironia fascinante:

Quanto mais automação surge…

mais valioso fica quem realmente entende o sistema por baixo.

Porque quando tudo falha…

a empresa procura exatamente aquele profissional capaz de entender o caos estrutural.

E normalmente esse profissional é o Sysadmin de IBM Z.


☕ CONCLUSÃO — O GUARDIÃO INVISÍVEL DO MUNDO DIGITAL

O Sysadmin de Mainframe não é apenas um administrador técnico.

Ele é:

  • operador de continuidade

  • engenheiro de estabilidade

  • guardião financeiro

  • estrategista operacional

  • arquiteto de sobrevivência corporativa

Ele trabalha em silêncio…

mas sustenta sistemas que literalmente mantêm economias inteiras funcionando.

Enquanto o mundo da TI corre atrás da próxima tendência…

o Sysadmin IBM Z continua fazendo algo muito mais difícil:

Garantir que o impossível nunca aconteça.


sábado, 19 de janeiro de 2013

☕🔥 ABEND S213 — O “GUARDIÃO DO DATASET” NO z/OS

 

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…

☕ O S213 JULGA SUA AUTORIZAÇÃO COMO UM GUARDIÃO ANTIGO DO z/OS.