🧙‍♂️ REXX em Modo Jedi Avançado

Quando o script deixa de ser código e vira governo do sistema

“Todo mundo escreve REXX.
Poucos entendem o que realmente estão controlando.”

☕ Introdução – REXX não é uma linguagem, é uma posição de poder

No mundo distribuído, scripts automatizam tarefas.
No mainframe, REXX governa fluxos.

REXX não nasceu para competir com COBOL, PL/I ou Python.
Ele nasceu para orquestrar, colar, conectar e, quando mal usado, derrubar produção em silêncio.

Entrar no modo Jedi do REXX significa entender que:

Você não escreve REXX para resolver problemas.
Você escreve REXX para controlar o sistema que resolve problemas.

🧠 Capítulo 1 – ADDRESS: o sabre de luz do REXX

Se você só usa ADDRESS TSO, você ainda é um Padawan.

O verdadeiro poder começa quando você entende que ADDRESS é um roteador de autoridade:

ADDRESS TSO → usuário
ADDRESS ISPEXEC → interface
ADDRESS SDSF → JES
ADDRESS CONSOLE → operador
ADDRESS OPERCMDS → sistema
ADDRESS LINK / LINKMVS / LINKPGM → MVS puro

🧩 Insight Jedi

ADDRESS define quem executa.
REXX apenas decide quando.

No modo Jedi, o REXX não executa — ele coordena entidades que têm poder real.

📦 Capítulo 2 – Data Stack: o lado invisível da Força

Todo REXX poderoso depende do Data Stack.
Quem não domina a stack, não domina REXX.

O Data Stack é:

STDIN/STDOUT do mainframe
Pipe de comunicação invisível
Fonte de 80% dos bugs silenciosos

Jedi sabe:

Quando usar PUSH (LIFO)
Quando usar QUEUE (FIFO)
Quando isolar com NEWSTACK
Quando limpar antes de sair

Stack suja = decisão errada baseada em lixo.

🛡️ Capítulo 3 – SYSREXX: quando o script vira operador invisível

SYSREXX não é um nome bonito.
É uma categoria mental.

SYSREXX é:

REXX que roda sem você
REXX que toma decisões
REXX que opera produção

Ele normalmente envolve:

Batch
SDSF
GETMSG
CART
OPERCMDS
CONSOLE

Verdade desconfortável

SYSREXX mal governado é mais perigoso que operador humano.

Operador erra uma vez.
SYSREXX erra toda vez, automaticamente.

🔐 Capítulo 4 – OPERCMDS: o Dark Side do REXX

OPERCMDS é o ponto onde engenharia vira ética.

Quem usa OPERCMDS sem checklist:

Não está automatizando
Está delegando autoridade sem supervisão

Regras Jedi absolutas

OPERCMDS sem log é proibido
OPERCMDS sem GETMSG é irresponsável
OPERCMDS em loop é incidente garantido
OPERCMDS sem RACF é suicídio institucional

Não é sobre conseguir executar o comando.
É sobre merecer executar o comando.

🔗 Capítulo 5 – LINK / LINKMVS / LINKPGM: REXX como maestro

Aqui o REXX para de ser script e vira maestro de orquestra.

COBOL executa regra
ASM executa velocidade
Utilities executam trabalho pesado
REXX coordena tudo

No modo Jedi:

REXX não faz I/O pesado
REXX não replica lógica de negócio
REXX chama quem sabe fazer melhor

REXX não substitui COBOL.
REXX governa COBOL.

🧪 Capítulo 6 – Checklists: a diferença entre mestre e herói morto

Padawans confiam no código.
Jedis confiam em processo.

Checklist não é burocracia.
Checklist é memória externa para evitar arrogância técnica.

Checklist Jedi inclui:

Segurança RACF
Data Stack limpa
RC validado
Mensagem interpretada
Log auditável
Rollback possível

REXX sem checklist é talento desperdiçado.

⚖️ Capítulo 7 – REXX vs Shell vs Python: maturidade arquitetural

O Jedi não briga por linguagem.

Ele sabe que:

REXX governa o core
Shell conecta ao Unix
Python conecta ao futuro

A arquitetura madura combina, não substitui.

Trocar REXX por Python no core do z/OS não é modernização.
É amnésia técnica.

🧠 Capítulo 8 – A mentalidade Jedi REXX

Um Jedi REXX:

Pensa em risco antes de pensar em sintaxe
Prefere previsibilidade a elegância
Documenta o óbvio
Desconfia de RC=0
Nunca confia em automação sem auditoria

Frase final (para colar na parede do data center):

REXX não é uma linguagem de programação.
É uma linguagem de responsabilidade.

☕ Epílogo – Um Café no Bellacosa Mainframe

O REXX Jedi não aparece no LinkedIn dizendo que “automatizou tudo”.
Ele aparece quando nada quebrou.

E no mainframe, isso é o maior elogio possível.

🔐 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

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.

El Jefe Midnight Lunch

segunda-feira, 22 de dezembro de 2025