🔐 Guia de Segurança – OPERCMDS em REXX Mainframe
OPERCMDS não é automação.
OPERCMDS é autoridade delegada de operador.
1️⃣ O que é OPERCMDS (sem romantizar)
OPERCMDS permite que um REXX envie comandos de operador MVS/JES como se estivesse no console do sistema.
Exemplos do que isso significa na prática:
-
Cancelar jobs
-
Parar subsistemas
-
Exibir status do sistema
-
Interferir diretamente na produção
📌 Conclusão:
Quem controla OPERCMDS, controla o sistema.
2️⃣ Princípio Zero: quando NÃO usar OPERCMDS
❌ Não use OPERCMDS se:
-
O comando pode ser feito via SDSF read-only
-
É apenas consulta de status
-
É um script de usuário final
-
Não existe logging/auditoria
👉 OPERCMDS só entra quando não há alternativa segura.
3️⃣ Pré-requisitos obrigatórios de segurança
Antes de QUALQUER ADDRESS OPERCMDS:
-
Autorização formal da área de segurança
-
Perfil RACF específico (não genérico)
-
Execução restrita (SYSREXX / batch controlado)
-
Script armazenado em library protegida
-
Alteração via change management
🧠 OPERCMDS sem RACF é uma bomba-relógio.
4️⃣ Classificação de comandos OPERCMDS
🟢 Classe 1 – Consulta (menor risco)
Exemplos:
-
D A -
D J,L -
D OMVS
Regras:
-
Preferir leitura
-
Log obrigatório
-
Nunca usar como gatilho de ação direta
🟡 Classe 2 – Controle (alto risco)
Exemplos:
-
CANCEL jobname -
P subsystem -
S subsystem
Regras:
-
Só em SYSREXX
-
Validação prévia obrigatória
-
RC + mensagem analisados
-
Execução única (sem loop)
🔴 Classe 3 – Impacto sistêmico (crítico)
Exemplos:
-
Z EOD -
VARY -
FORCE
📌 Regra absoluta:
REXX NÃO deve executar esses comandos automaticamente.
5️⃣ Checklist técnico antes do comando
Antes de executar OPERCMDS:
-
O comando foi validado?
-
Existe confirmação lógica (não humana)?
-
O ambiente é o correto (LPAR, sistema)?
-
O job alvo realmente existe?
-
O comando é idempotente?
-
Existe timeout / proteção contra loop?
6️⃣ Captura e validação de mensagens (obrigatório)
Nunca execute OPERCMDS “cego”.
Fluxo correto:
-
Executar comando
-
Capturar mensagem
-
Interpretar resposta
-
Só então decidir próxima ação
Ferramentas:
-
GETMSG -
CART -
Data Stack
📌 OPERCMDS sem GETMSG é irresponsável.
7️⃣ Tratamento de RC e mensagens
-
RC analisado imediatamente
-
Mensagem validada (texto, não só RC)
-
Erro gera abort controlado
-
Sucesso gera log explícito
-
Nenhum “continue anyway”
🥚 RC = 0 não significa sucesso operacional.
8️⃣ Logs e Auditoria (não negociável)
Todo OPERCMDS deve gerar:
-
Quem executou
-
Quando executou
-
Qual comando
-
Qual retorno
-
Qual decisão foi tomada
Regras:
-
Log em dataset protegido
-
SYSOUT identificado
-
Retenção definida
🧠 Sem log, não há defesa em auditoria.
9️⃣ Proteções obrigatórias no código
-
Nunca hardcode jobnames críticos
-
Nunca aceitar input direto do usuário
-
Nunca rodar em loop sem limite
-
Nunca executar em ambiente errado
-
Nunca assumir sucesso
📌 REXX é rápido — erros também.
🔟 OPERCMDS em Batch vs TSO
| Ambiente | Recomendação |
|---|---|
| TSO interativo | ❌ Evitar |
| ISPF | ⚠️ Só leitura |
| Batch controlado | ✅ Recomendado |
| SYSREXX | ✅ Ideal |
1️⃣1️⃣ Governança e Versionamento
-
Header com aviso de risco
-
Versão explícita
-
Responsável técnico
-
Revisão periódica
-
Aprovação da operação
1️⃣2️⃣ Frases que salvam produção
❝ OPERCMDS não falha — pessoas falham ❞
❝ Automação sem controle é incidente futuro ❞
❝ Se pode derrubar o sistema, precisa de checklist ❞
🧠 Conclusão – mentalidade correta
OPERCMDS não é para mostrar poder técnico.
É para reduzir risco operacional com disciplina.
