El Jefe Midnight Lunch

✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta racf. Mostrar todas as mensagens

sexta-feira, 12 de abril de 2024

Uma visão geral sobre o trabalhador de Mainframe

Equipe de desenvolvimento mainframe

Descubra a Stack MAINFRAME e veja o que necessita para ser um Desenvolvedor COBOL de Sucesso. Aprenda COBOL, há 65 anos revolucionando o mercado de informática.

quinta-feira, 11 de abril de 2024

Conheças algumas vantagens de desenvolver em COBOL Mainframe

Stack Mainframe

Descubra a Stack MAINFRAME Aprenda COBOL, há 65 anos revolucionando o mercado de informática.

domingo, 10 de março de 2013

Atraves do espelho: TSO / ISPF Login Process

Através do Espelho: TSO / ISPF Login Process

A porta, o cofre e a sala de controle do IBM z/OS

“Antes de rodar um JOB,
antes de editar um COBOL,
antes de caçar MIPS…
todo mainframeiro passa pelo mesmo ritual.”

O login TSO/ISPF não é apenas um passo técnico.
Ele é o controle de acesso ao coração financeiro do planeta.

Vamos destrinchar esse processo como ele realmente funciona, e por que ele existe desse jeito há décadas — e continua absolutamente atual em 2026.

🧠 Por que o login no mainframe é diferente?

Porque o mainframe não é um notebook pessoal.

Estamos falando de um ambiente:

Multiusuário
Multiempresa
Missão crítica
24x7x365
Onde um erro pode parar um país

Logo:

Nada começa sem identidade, autorização e controle.

👤 Passo 1 — User ID: quem é você no mundo z/OS

No IBM z/OS, ninguém é anônimo.

Cada usuário recebe um User ID, que é muito mais do que um “login”.

O User ID define:

👤 Quem você é
🛂 O que você pode ou não acessar
📁 Quais datasets são seus
🗂️ Quais JOBs você pode submeter
🛡️ Quais recursos do sistema você enxerga

Em linguagem Bellacosa:

O User ID é sua identidade civil no mainframe.

Sem ele:

Não existe sessão
Não existe ISPF
Não existe batch
Não existe nada

🔐 Passo 2 — Password: provando que você é você

O password valida sua identidade.

Mas aqui não estamos falando de senha fraca de rede social.

No mainframe, o password:

🔐 Protege bilhões em dados
🛡️ Trabalha junto com RACF (ou ACF2 / Top Secret)
📜 Atende políticas rígidas de segurança corporativa
🚨 Bloqueia tentativas indevidas automaticamente

Dica El Jefe:

Errou senha demais?
Bem-vindo ao bloqueio automático e à ligação para o suporte.

Segurança aqui não é opcional, é contrato social.

🧱 Entre o password e o ISPF existe o TSO

Após User ID + Password válidos, acontece algo fundamental:

👉 Uma sessão TSO é criada.

Isso significa:

O sistema aloca recursos
Controla prioridade
Define limites
Registra auditoria

Sem TSO:

Não existe interação com o z/OS.

TSO é o ambiente base, invisível para muitos, essencial para todos.

📋 Passo 3 — ISPF Panels: onde o trabalho começa

Só depois disso o usuário entra no ISPF.

ISPF não é login.
ISPF é produtividade.

Os painéis ISPF oferecem:

📋 Menus estruturados
🔢 Navegação clara
✍️ Editores robustos
⚙️ Gestão de datasets, JCL, programas

Em linguagem Bellacosa:

ISPF é a sala de controle.

É ali que:

O COBOL nasce
O JCL roda
O erro aparece
O padawan vira mainframeiro

🔁 O fluxo completo, sem romantização

O login real funciona assim:


User ID
   ↓
Password
   ↓
Sessão TSO criada
   ↓
Entrada no ISPF

Ou, resumindo:

Identidade → Autenticação → Sessão → Produtividade

🏗️ Analogia Bellacosa (clássica)

User ID → Quem você é
Password → Prova que é você
TSO → Portaria + controle de acesso
ISPF → Sala de operações

Sem portaria:

ninguém entra

Sem sala de operações:

ninguém trabalha

⚠️ Erros clássicos de padawan

❌ Achar que ISPF faz login
❌ Ignorar o papel do TSO
❌ Não entender RACF
❌ Tratar User ID como “só um login”

Dica de veterano:

Quem entende login entende segurança.
Quem entende segurança nunca é pego de surpresa.

🥚 Easter-eggs do cotidiano z/OS

Todo mundo já ficou preso no painel de login
Todo mundo já teve User ID revogado
Todo mundo já decorou PF3 para sair
Todo mundo já respeitou o cadeado 🔐 no RACF

☕ Palavra final do El Jefe

No mainframe, nada começa sem controle.

O processo de login TSO/ISPF não é burocracia.
É engenharia de segurança em escala planetária.

Se TSO é o portão,
e ISPF é a sala de controle…

Então lembre-se:

Só entra quem pode.
Só trabalha quem entende.

segunda-feira, 2 de julho de 2012

🧠 “SMF como fonte de verdade para observabilidade corporativa”

Porque antes de existir observability platform, já existia evidência

☕ 01:38 — Quando o gráfico mente, mas o SMF não

Todo mainframer aprende cedo uma verdade incômoda:
logs contam histórias, métricas sugerem hipóteses, mas o SMF registra fatos.

Enquanto o mundo distribuído ainda debate o que é single source of truth,
o z/OS já resolveu isso há décadas — e deu o nome de System Management Facility.

🧬 Um pouco de história (quando observabilidade não tinha marketing)

O SMF nasceu para:

auditoria
cobrança
capacidade
performance
rastreabilidade

Não para “monitorar bonito”,
mas para provar o que aconteceu.

📌 Comentário Bellacosa:
SMF nunca foi sexy. Foi confiável. E isso envelhece melhor.

🔍 O que o SMF realmente é (traduzindo para cloudês)

No mundo moderno:

Logs
Metrics
Traces

No z/OS:

Tudo isso… em um formato só
Com timestamp confiável
Com contexto de sistema
Com impacto mensurável

🔥 Tradução direta:
SMF é observabilidade com evidência jurídica.

🧠 SMF como “fonte de verdade”

Por que o SMF é a source of truth?

✔️ É gerado pelo sistema operacional
✔️ Não depende da aplicação “colaborar”
✔️ Não perde evento por backpressure
✔️ Não é amostrado
✔️ Não é opinativo

😈 Easter egg:
Se o SMF não viu, provavelmente não aconteceu.

📊 Comparação honesta: SMF x Observabilidade moderna

Observabilidade moderna	SMF
Métricas amostradas	Dados completos
Traces instrumentados	Evidência sistêmica
Logs verbosos	Registros estruturados
Dashboards	Capacidade histórica
Alertas	Diagnóstico pós-morte

📌 Comentário ácido:
Dashboard serve para avisar.
SMF serve para explicar.

🧭 Passo a passo mental: usando SMF como observabilidade

1️⃣ Coleta contínua (SMF ativo é pré-requisito)
2️⃣ Classificação por tipo (CPU, I/O, CICS, DB2, MQ…)
3️⃣ Correlação temporal
4️⃣ Análise de impacto real
5️⃣ Conclusão baseada em dado, não sensação

🔥 Regra de ouro:
Sem correlação, métrica vira superstição.

🧩 SMF e aplicações distribuídas (onde os mundos se encontram)

Hoje, arquiteturas são:

híbridas
distribuídas
event-driven

O SMF entra como:

referência de carga real
baseline de comportamento
âncora de verdade

📌 Exemplo prático:
Quando a API “fica lenta”, o SMF diz:

se foi CPU
se foi I/O
se foi concorrência
ou se foi culpa de quem chamou demais

📚 Guia de estudo para o mainframer moderno

Conceitos essenciais

Observabilidade ≠ Monitoramento
Correlação ≠ Alerta
Evidência ≠ Opinião
Capacidade ≠ Pico momentâneo

Exercício recomendado

👉 Pegue um incidente passado
👉 Releia só o SMF
👉 Ignore dashboards
👉 Reescreva a RCA

O resultado costuma ser… desconfortável — e correto.

🎯 Aplicações reais no mundo corporativo

Auditoria e compliance
Capacity planning sério
SRE corporativo
Integração com AIOps
Base para observabilidade híbrida

🔥 Comentário Bellacosa:
Todo AIOps sério começa com dado confiável.
E dado confiável tem sobrenome: SMF.

🖤 Epílogo — 03:27, incidente encerrado

Quando o ruído some,
quando o gráfico contradiz o discurso,
quando a RCA precisa sobreviver a auditoria…

é o SMF que fica.

El Jefe Midnight Lunch assina:
“Observabilidade é saber. SMF é provar.”

quarta-feira, 16 de fevereiro de 2011

🔥 Challenges of Running COBOL with Git – Uma Observação Prática (com cheiro de sala-cofre) 🔥

COBOL e os desafios do GITHUB e ECLIPSE

🔥 Challenges of Running COBOL with Git – Uma Observação Prática (com cheiro de sala-cofre) 🔥

Durante décadas, COBOL e z/OS viveram felizes no seu ecossistema fechado, previsível e extremamente confiável. ISPF, PDS/PDSE, JCL, compile noturno, café forte e aquele silêncio respeitoso do data center. Então alguém chegou dizendo:

“Agora tudo é Git. Branch, pull request, rebase e pipeline.”

🤔 Pause dramático de mainframer veterano.

Este artigo nasce de pesquisa, observação prática e muita conversa de corredor — aquele tipo de conhecimento que não aparece em Redbook, mas surge no café das 3h da manhã durante um IPL mal-humorado.

🧬 1. EBCDIC vs UTF-8 – A Guerra Invisível dos Bytes

Aqui começa o primeiro boss final.

Git assume UTF-8. COBOL em z/OS respira EBCDIC. Misture isso sem regras claras e você ganha:

Literais corrompidos
DISPLAY mostrando hieróglifos
Compilação falhando sem erro “óbvio”

💡 Dica Bellacosa:
Defina conversão explícita e obrigatória no pipeline. Nada de “ah, o plugin cuida disso”. Ele não cuida.

🥚 Easter egg:
Muitos bugs “fantasma” em COBOL moderno não são lógicos — são encoding bugs disfarçados.

📚 2. Copybooks – O Efeito Dominó Silencioso

COBOL sem copybook é como mainframe sem SMF: tecnicamente existe, mas ninguém confia.

O problema?
Git não entende dependência semântica.

Um copybook alterado
137 programas impactados
12 recompilados
125 esquecidos
Produção quebra… só amanhã

💡 Dica de guerra:
Pipeline dependency-aware é obrigatório. Ferramentas como DBB, scripts de impacto ou metadados não são luxo — são sobrevivência.

🗣 Fofoquinha real:
Já vi incidente crítico porque “era só um copybook de comentário”. Spoiler: não era.

📐 3. Diffs, Colunas e a Maldade do Espaço em Branco

Git ama linhas.
COBOL ama colunas.

Um espaço fora do lugar vira:

Diff gigante
Merge impossível
Revisão inútil

Comentários deslocados geram mais conflito que erro lógico.

💡 Dica Bellacosa raiz:

Padronize formatação
Use ferramentas de pretty-print COBOL
Trate espaço em branco como código, não estética

🥚 Easter egg clássico:
Um MOVE perfeito na lógica pode falhar só porque começou na coluna errada. Git não entende isso. O compilador sim — e ele não perdoa.

⚙️ 4. Build, Compile e o “CI/CD de Verdade”

Aqui mora a grande ilusão moderna:

“Ah, só dar git push que compila.”

Não, não compila.

COBOL exige:

Compile no z/OS
Link-edit
Bind DB2
Execução JCL
Controle de RC
Logs rastreáveis

Sem automação real, Git vira apenas um repositório bonito.

💡 Dica prática:
Se o commit não dispara compile, bind e validação automática, você não tem CI/CD — só tem GitHub caro.

🧠 5. Cultura, Pessoas e o Choque de Gerações

Aqui não é tecnologia — é gente.

Desenvolvedores COBOL dominam ISPF como ninguém
Git traz conceitos novos: rebase, squash, branch strategy
Sem cuidado, isso vira atrito desnecessário

💡 Dica de liderança técnica:
Não force Git “goela abaixo”. Traduza conceitos:

Branch ≈ versão lógica
Pull request ≈ revisão formal
Pipeline ≈ JCL automático

🗣 Comentário de bastidor:
Os melhores times são híbridos: mainframers aprendendo Git e devops aprendendo z/OS. Quem só ensina e não aprende falha.

🔐 6. Segurança – RACF não é GitHub (e nunca será)

Git trabalha com:

Usuário
Token
Repo

Mainframe trabalha com:

Identidade
Perfil
Dataset
Auditoria pesada

Alinhar RACF/ACF2/TSS com Git não é trivial, principalmente em ambientes regulados.

💡 Dica Bellacosa:
Auditoria e rastreabilidade devem nascer no pipeline, não serem “adaptadas depois”.

🥚 Easter egg corporativo:
Compliance sempre descobre o problema depois que o sistema já está em produção.

🧠 Pensamento Final – Git Funciona com COBOL?

Sim.
Mas não por mágica.

Git funciona com COBOL quando existe:

Disciplina
Ferramentas corretas
Pipeline consciente
Respeito à cultura mainframe

Sem isso, você só moderniza o problema — não a solução.

🔥 Provocação final do El Jefe:
Quantos ambientes “modernizados” hoje só trocaram o PDS por Git, mas mantiveram os mesmos riscos de 1989?

quarta-feira, 3 de novembro de 2010

☕🔥 REXX Hardcore no z/OS — automação, controle e poder operacional

Bellacosa Mainframe apresenta o REXX

☕🔥 REXX Hardcore no z/OS — automação, controle e poder operacional

Se você já salvou produção com um exec improvisado, já rasgou SDSF via ADDRESS, ou já ouviu

“isso dá pra automatizar em REXX, né?”
então puxa a cadeira.
Aqui é REXX técnico, sem verniz didático e com cheiro de madrugada.

🕰️ Histórico & Origem — por que o REXX virou arma de produção

O REXX (Restructured Extended Executor) nasce na IBM nos anos 80 com uma missão clara:

Substituir JCL “verboso”
Padronizar scripts
Criar uma linguagem legível, extensível e integrada ao sistema

Ele não foi feito para ser “bonito”.
Foi feito para controlar ambiente.

☕ Verdade histórica:

REXX não é linguagem de apoio — é linguagem de governo operacional.

🧠 Conceito de Ambiente de Processamento

REXX não executa no vácuo.
Ele sempre roda dentro de um ambiente:

TSO/E
Batch
SDSF
ISPF
CICS (indiretamente)
Programas externos

Cada ambiente define:

Comandos válidos
RC interpretado
Recursos disponíveis
Permissões RACF

🔥 Easter egg:
O mesmo EXEC pode funcionar em TSO e falhar em Batch sem mudar uma linha.

🧩 Fundamentos da Linguagem — simples na superfície, profunda no núcleo

Sintaxe & Elementos

Tipagem dinâmica
Strings como cidadão de primeira classe
Sem declaração obrigatória
Case-insensitive (armadilha clássica)

📌 Exemplo:


parse upper arg parm1 parm2
if parm1 = '' then exit 8

☕ Comentário ácido:
REXX perdoa erro demais — e isso cobra seu preço em produção.

🏗️ Estrutura de um Programa REXX

Todo EXEC sério tem:

Identificação
Validação de ambiente
Tratamento de RC
Controle de erro
Cleanup

📌 Exemplo base:


/* REXX */
signal on error
signal on failure
signal on syntax

address tso
"ALLOC FI(IN) DA('DATASET') SHR"
...
exit 0

🔥 Veterano sabe:
EXEC sem SIGNAL ON é convite ao caos.

🧮 Estrutura de Dados — tabelas na memória

REXX não tem array clássico.
Tem stem variables.


tab.1 = 'A'
tab.2 = 'B'
tab.0 = 2

☕ Curiosidade:
Stem mal controlado vira memory leak conceitual.

📂 Acesso a Arquivos & Geração de Relatórios

ALLOC / FREE
EXECIO DISKR / DISKW
Geração de relatórios spoolados
Integração com SORT

📌 Exemplo:


"EXECIO * DISKR IN (STEM L.)"
do i=1 to L.0
  say L.i
end

🔥 Easter egg:
EXECIO ignora erro… até você checar o RC.

🔃 Classificação & Manipulação de Dados

SORT via IDCAMS
SORT via ICETOOL
Manipulação em memória (lento)
Pipeline híbrido REXX + SORT

☕ Regra de produção:

Se precisa ordenar muito, não é REXX — é SORT.

🗂️ Acesso a Diretório de PDS

REXX + ISPF services:

LMDINIT
LMMLIST
LMCLOSE

📌 Exemplo:


address ispexec
"LMINIT DATAID(DID) DATASET('MY.PDS')"
"LMMLIST DATAID(DID) OPTION(LIST)"

🔥 Veterano:
ISPF services dão poder… e risco.

🧑‍💻 Interatividade com Usuário (TSO)

Pseudo-conversational
Command-level
SAY / PULL
Mensagens controladas

☕ Fofoquice:
Interface feia, mas resolve crise em minutos.

🧪 Modos de Execução REXX

🟢 REXX Linha de Comando (Online)

Interativo
Debug rápido
Dependente de perfil

🟡 REXX Batch Script (Interpretado)

Executa via IKJEFT01
Dependente de ambiente
Mais flexível

🔴 REXX Batch Compilado

Performance superior
RC previsível
Menos tolerante a erro
Exige processo de build

🔥 Script vs Compilado:

Interpretado é agilidade.
Compilado é confiabilidade.

🔐 REXX + RACF

REXX não ignora segurança:

Herda permissões do usuário
Pode consultar via RACROUTE (indireto)
Controla acesso via classes

☕ Verdade dura:
EXEC com SPECIAL é bomba com pavio curto.

🗄️ REXX + DB2

DSNREXX
SQL dinâmico
RC + SQLCODE + SQLSTATE
Automação de consultas e relatórios

📌 Exemplo:


ADDRESS DSNREXX
"EXECSQL SELECT COUNT(*) INTO :CNT FROM SYSIBM.SYSTABLES"

🔥 Easter egg:
SQLCODE ignorado vira incidente invisível.

🔀 ADDRESS — o coração da integração

ADDRESS muda o destino dos comandos:

TSO
ISPEXEC
SDSF
CONSOLE
DSNREXX

☕🔥 Regra sagrada:

Quem domina ADDRESS domina o sistema.

🔢 Return Code (RC) — o idioma da produção

RC ≠ erro sempre
RC precisa ser interpretado
Padronização é vital


if rc > 4 then exit rc

🔥 Veterano:
RC não tratado é mentira operacional.

📘 Programa do Curso — visão hardcore

Estrutura Geral / Labs

Ambiente restritivo
Casos reais
Incidentes simulados

Instruções REXX

IF, DO, SELECT
SIGNAL, EXIT
PARSE

Funções Internas / Sub-rotinas

Modularização
Reuso
Controle de escopo

Comandos REXX

SAY, PULL, TRACE
QUEUE / PULL
EXECIO

Funções TSO / CONSOLE

WTO
MODIFY
DUMP
SDSF

INTERPRET (🔥 perigoso)

Execução dinâmica
Flexibilidade extrema
Risco máximo

☕ Comentário ácido:

INTERPRET é poder absoluto — use sóbrio.

🥚 Easter Eggs & Fofoquices REXX

Todo ambiente tem um EXEC “salvador”
Sempre existe um REXX sem comentários rodando há anos
O melhor REXX é o que não precisa ser explicado
Debug começa com TRACE ?R

☕🔥 Conclusão — Manifesto El Jefe REXX

REXX não é:

Script simples
Linguagem de iniciante
Alternativa ao COBOL

REXX é:

Cola do z/OS
Automação estratégica
Ferramenta de sobrevivência em produção

☕🔥 Quem domina REXX,
não programa apenas —
orquestra o mainframe.

quinta-feira, 11 de fevereiro de 2010

RACF: Mapeamento OPERCMD x SDSF (do Console à Tela Verde

Bellacosa Mainframe apresenta RACF

🔐 RACF NA VEIA

Mapeamento OPERCMD x SDSF (do Console à Tela Verde

“Quem manda no console manda no sysplex…
mas quem controla o RACF manda até no operador.” ☕🖥️

No mundo z/OS, existem dois universos de comando:

Console MVS real → controlado pela classe OPERCMDS
Interface SDSF → controlada por um conjunto de classes RACF

Muita gente confunde, mistura e sofre.
Vamos separar isso como JES2 separa spool 😈

🧱 1️⃣ OPERCMDS – O PODER DO CONSOLE MVS

🎯 O que controla?

A classe OPERCMDS controla quem pode emitir comandos MVS e subsistemas:

No console físico
Via TSO CONSOLE
Via REXX ADDRESS CONSOLE
Via automação (SA, NetView, OPS/MVS)

📌 Exemplos clássicos de comandos protegidos

Comando	Perfil OPERCMDS
`D A,L`	`MVS.DISPLAY.ACTIVE`
`D U,ALL`	`MVS.DISPLAY.UNITS`
`$DA` (JES2)	`JES2.DISPLAY.ACTIVE`
`$P JOB123`	`JES2.PURGE.JOB`
`VARY 1234,ONLINE`	`MVS.VARY.DEVICE.ONLINE`
`SET SMF=xx`	`MVS.SET.SMF`

📌 Regra de ouro:
👉 Se é comando MVS/JES, o RACF olha primeiro para OPERCMDS.

🧠 Exemplo RACF raiz


RDEFINE OPERCMDS MVS.DISPLAY.** UACC(NONE)
PERMIT MVS.DISPLAY.** CLASS(OPERCMDS) ID(OPERADOR) ACCESS(READ)
SETROPTS CLASSACT(OPERCMDS)
SETROPTS RACLIST(OPERCMDS) REFRESH

🖥️ 2️⃣ SDSF – O CONSOLE DE MENTIRINHA (MAS PERIGOSO)

“SDSF não é console…
mas faz estrago igual.” 😈

O SDSF é uma interface, e o RACF controla cada ação separadamente.

🧩 Classes RACF usadas pelo SDSF

Classe	Função
SDSF	Acesso geral ao SDSF
JESJOBS	Ações sobre jobs (cancel, purge, hold)
JES	Comandos JES
OPERCMDS	Se o SDSF emitir comando real
WRITER	Writers e saída
LOGSTRM	Logs do sistema
FACILITY	Funções especiais

📊 3️⃣ Tabela Mestre – OPERCMDS x SDSF

🧠 A tabela que salva operadores e professores

Ação no SDSF	Classe RACF	Perfil
Entrar no SDSF	SDSF	`SDSF`
Ver jobs (ST/DA)	JESJOBS	`JOB.*`
Cancelar job	JESJOBS	`JOB.CANCEL`
Purge job	JESJOBS	`JOB.PURGE`
Hold / Release	JESJOBS	`JOB.HOLD`
Ver SYSLOG	SDSF	`LOG`
Comando JES `$DA`	JES	`JES2.DISPLAY.ACTIVE`
Comando MVS `D A,L`	OPERCMDS	`MVS.DISPLAY.ACTIVE`
Alterar prioridade	JESJOBS	`JOB.MODIFY`

📌 Fofoquice real:
👉 Você pode ver tudo no SDSF e não conseguir executar nada, mesmo sendo “OPERADOR”.

⚔️ 4️⃣ Quando OPERCMDS e SDSF se cruzam

🎯 Exemplo clássico

Usuário no SDSF digita:


/D A,L

👉 O que acontece?

SDSF aceita o comando
RACF valida OPERCMDS
Se não tiver perfil → RC=8, NOT AUTHORIZED

📌 Moral:
SDSF não ignora OPERCMDS, ele chama o RACF como qualquer console.

🔐 5️⃣ Ambiente RACF Restritivo (vida real)

✔️ Boas práticas Bellacosa Approved™

❌ Nunca dar OPERCMDS MVS.** para usuário comum
✔️ Preferir:
- MVS.DISPLAY.*
- JES2.DISPLAY.*
✔️ Cancelamento via JESJOBS, não OPERCMDS
✔️ Usar ROLES no SDSF
✔️ Logar tudo (SMF 80, 83, 84)

🧪 6️⃣ Checklist rápido de segurança

✔ SDSF separado por perfil
✔ OPERCMDS mínimo necessário
✔ JESJOBS granular
✔ LOG e SYSLOG somente READ
✔ Nada de UACC(READ) em produção 😱
✔ SETROPTS AUDIT OPERCMDS ativo

☕ Frase final do Bellacosa Mainframe

“No mainframe, comando não é poder…
autorização é.”

sábado, 19 de dezembro de 2009

📋 Checklist Executável de Auditoria z/OS (SMP/E + RACF)

Bellacosa Mainframe e um Checklist de Auditoria Z/OS

Checklist executável criado com sucesso ✅

Ele já está pronto para:

🧪 execução técnica real (com comandos e evidências)
🛡️ auditoria interna e externa
📄 impressão / PDF
🎓 treinamento de sysprogs

Checklist Executável De Auditoria Z/os (smp/e + Racf)

segunda-feira, 2 de novembro de 2009

📘 Guia de Auditoria z/OS Completo

Bellacosa Mainframe apresenta Guia de Auditoria Z/OS

📘 Guia de Auditoria z/OS Completo

Do RACF ao SMP/E: como provar que seu mainframe é confiável

“Auditoria em z/OS não é caça ao erro.
É validação de maturidade operacional.”

🎯 Objetivo deste guia

Este guia serve para:

Preparar ambientes para auditoria
Responder auditores com evidência técnica
Evitar não conformidades
Padronizar governança em z/OS

👉 Não é teoria. É prática de campo.

🧠 Visão geral da auditoria em z/OS

Auditoria em z/OS gira em torno de 5 pilares:

1️⃣ Controle de acesso
2️⃣ Integridade do sistema
3️⃣ Gestão de mudanças
4️⃣ Rastreabilidade
5️⃣ Continuidade operacional

Cada pilar tem ferramentas nativas do mainframe.

🔐 Pilar 1 – Controle de Acesso (RACF / ACF2 / TSS)

O auditor verifica:

IDs privilegiados
Perfis genéricos
UACC
Logging
Segregação de funções

Evidências:

LISTUSER
RLIST
Relatórios SMF
Revisão periódica de acessos

📌 Privilégio excessivo reprova auditoria.

🛡️ Pilar 2 – Integridade do Sistema

Ferramentas-chave:

SMP/E
CSI
DLIB
TARGET libraries

O auditor quer saber:

Quem muda o sistema
Como muda
Se há controle

📌 Aqui o SMP/E reina absoluto.

🔁 Pilar 3 – Gestão de Mudanças

Avaliação típica:

Processo RECEIVE/APPLY/ACCEPT
APPLY CHECK obrigatório
Análise de ++HOLD e ++ERROR
USERMOD documentado

Evidências:

Outputs SMP/E
Change records
APARs e PTFs

🧩 Pilar 4 – Rastreabilidade e Evidência

O auditor exige:

Histórico preservado
Logs acessíveis
Responsáveis identificados

Ferramentas:

CSI
SMF
Logs RACF
Versionamento de JCL

📌 Sem evidência, não existe controle.

🔄 Pilar 5 – Continuidade e Recuperação

Avaliação:

Backup de CSI
Capacidade de RESTORE
Planos de contingência
Testes documentados

📌 Auditoria não aceita “nunca testamos”.

📦 Auditoria por componente (check rápido)

🔹 SMP/E

✔ Controle de acesso
✔ APPLY CHECK
✔ ACCEPT consciente
✔ USERMOD controlado

🔹 RACF

✔ UACC=NONE
✔ Logging ativo
✔ Revisão periódica

🔹 JES / System

✔ Parâmetros controlados
✔ Alterações documentadas

🔹 SMF

✔ Coleta ativa
✔ Retenção definida

🚨 Red flags clássicos em auditoria z/OS

❌ IDs genéricos
❌ ALTER irrestrito
❌ USERMOD esquecido
❌ PTFs de segurança atrasados
❌ Falta de documentação

👉 Tudo isso vira finding.

🧠 Caso real (estilo Bellacosa)

Auditor pergunta sobre um módulo alterado
Não há registro no SMP/E
Ninguém sabe quem fez

📌 Conclusão:

Ambiente sem governança.

🎓 Como se preparar para auditoria

Trate auditoria como rotina
Use SMP/E como aliado
Automatize evidências
Documente decisões
Revise acessos

💡 Dica Bellacosa:

“Auditoria bem-sucedida começa meses antes.”

🧠 Curiosidades Bellacosa

Auditor confia mais no CSI do que em planilha
Mainframe já nasce auditável
Falha é quase sempre humana, não técnica

🧾 Encerramento – Guia de Auditoria z/OS

z/OS não é inseguro.
Inseguro é rodar sem controle.

Quem domina:

RACF
SMP/E
Processos

👉 passa em qualquer auditoria.

📘💾🛡️🔥