Bellacosa Mainframe fala sobre segurança mainframe RACF TSS ACF2

🔥 Quem Realmente Manda no Seu z/OS? — RACF vs TSS vs ACF2, a Guerra Silenciosa que Decide Tudo

Se você trabalha com mainframe há tempo suficiente, já sabe:
o sistema pode ser o mais estável do mundo… mas quem decide o que acontece nele não é o z/OS — é o ESM.

E aí entra o trio que moldou décadas de segurança no mainframe:

• IBM RACF
• CA Top Secret (TSS)
• CA ACF2

Três filosofias. Três formas de pensar segurança.
E, mais importante: três maneiras completamente diferentes de cometer erros — ou evitá-los.

---

🧠 Capítulo 1 — Origem: Quando Segurança Virou Necessidade (não luxo)

Volta para os anos 70/80.

Mainframe já processava:

• bancos
• governo
• folha de pagamento
• defesa

E aí veio a pergunta que mudou tudo:

“Quem pode acessar o quê?”

A resposta não era trivial — porque o z/OS (na época MVS) não nasceu com segurança robusta nativa.

🔵 RACF (IBM)

Criado pela própria IBM:

• integração total com o sistema
• modelo corporativo
• foco em governança

👉 DNA:

segurança como parte da arquitetura

---

🟢 TSS (CA Top Secret)

Criado pela CA:

• foco em simplicidade
• modelo centrado no usuário

👉 DNA:

segurança como controle direto

---

🟣 ACF2

Também da CA:

• abordagem radicalmente diferente
• rule-based

👉 DNA:

segurança como linguagem

---

🧬 Capítulo 2 — O DNA de Cada Um

🔵 RACF — O Burocrata Organizado

RACF pensa assim:

Usuário → Grupo → Recurso → Permissão

Ele cria estrutura.

Exemplo real:

ADDUSER DEV01 DFLTGRP(DEV)
PERMIT PROD.APP.* CLASS(DATASET) ID(DEV01) ACCESS(READ)

👉 RACF gosta de:

• hierarquia
• governança
• previsibilidade

---

🟢 TSS — O Operador Pragmático

TSS elimina intermediários:

ACID → Permissões

Exemplo:

TSS PERMIT(DEV01) DATASET(PROD.APP.*) ACCESS(READ)

👉 TSS gosta de:

• simplicidade
• rapidez
• controle direto

---

🟣 ACF2 — O Hacker Formal

ACF2 inverte tudo:

Recurso → Regra → Usuário

Exemplo:

$KEY(PROD)
 UID(DEV01) ALLOW

👉 ACF2 gosta de:

• regras
• lógica
• flexibilidade extrema

---

⚔️ Capítulo 3 — A Diferença que Ninguém Te Conta

Aqui está o ponto que separa júnior de sênior:

Esses produtos não são equivalentes — eles são modelos mentais diferentes

---

🧠 RACF pensa em “organização”

Você define estrutura e depois controla acesso.

---

🧠 TSS pensa em “identidade”

Você dá poder direto ao usuário.

---

🧠 ACF2 pensa em “lógica”

Você escreve regras e deixa o sistema decidir.

---

🧨 Capítulo 4 — Onde os Projetos Quebram

Vamos direto ao campo de batalha.

🔥 Caso real 1 — Migração TSS → RACF

Problema:

• TSS:

  DIVISION / DEPARTMENT
  

• RACF:

  GROUP
  

👉 Não existe equivalência direta.

Resultado:

• perda de contexto
• decisões arquiteturais obrigatórias

---

🔥 Caso real 2 — ACF2 mal governado

ACF2 permite:

• regras complexas
• lógica condicional

👉 Sem controle vira:

“ninguém entende mais quem tem acesso a quê”

---

🔥 Caso real 3 — RACF mal configurado

Erro clássico:

UACC(READ)

👉 Tradução:

você abriu o dataset para meio mundo

---

🧠 Capítulo 5 — Como Eles Funcionam HOJE (2026)

🔵 RACF hoje

• integrado ao z/OS
• forte com ferramentas como:
  • auditoria
  • compliance
• padrão de mercado

👉 Usado em:

• bancos
• governo
• grandes corporações

---

🟢 TSS hoje

• ainda muito presente
• especialmente em ambientes antigos

👉 Problema:

• escassez de profissionais
• pressão de custo

---

🟣 ACF2 hoje

• nicho forte
• ambientes altamente customizados

👉 Perfil:

• organizações com regras complexas

---

🧩 Capítulo 6 — Easter Eggs de Quem Já Viveu Isso

🥚 1. O mito do “ALL”

No TSS:

ACCESS(ALL)

👉 Pode significar mais do que você imagina…

---

🥚 2. O clássico “por que isso funcionava antes?”

Resposta:

porque estava no TSS… e ninguém sabia

---

🥚 3. O fantasma do dataset genérico

PROD.*

👉 Um único profile pode abrir acesso para centenas de datasets.

---

🥚 4. O usuário com SPECIAL no RACF

👉 Isso aqui é praticamente “root do mainframe”

---

🧠 Capítulo 7 — Comparação Brutal (sem filtro)

Critério	RACF	TSS	ACF2
Governança	Alta	Média	Alta
Simplicidade	Média	Alta	Baixa
Flexibilidade	Alta	Média	Extremamente alta
Risco operacional	Médio	Médio	Alto
Mercado atual	Dominante	Caindo	Nicho

---

💣 Capítulo 8 — A Verdade que Poucos Dizem

Não existe “melhor” absoluto.

Existe:

• o mais adequado ao seu ambiente
• o mais governável pela sua equipe
• o menos arriscado para auditoria

---

🧠 Insight de arquiteto

Se você precisa:

• padronização → RACF
• simplicidade → TSS
• controle extremo → ACF2

---

🔥 Conclusão — A Guerra Invisível

Enquanto todo mundo fala de:

• cloud
• APIs
• microservices

No mainframe, a pergunta continua sendo a mesma há 40 anos:

“Quem pode fazer o quê?”

E a resposta continua dependendo de um desses três.

---

☕ Frase final estilo Bellacosa

“Você pode modernizar o COBOL, migrar para APIs, colocar z/OS Connect…
mas se errar no RACF, TSS ou ACF2 — nada disso importa.”

 

 

🧙‍♂️ 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.

 

📦 O que é REXX Data Stack

📌 Conceito básico

O Data Stack é uma fila (stack/queue) de dados em memória, mantida pelo interpretador REXX, usada para:

Trocar dados entre comandos, programas e o próprio REXX, sem usar datasets.

Ele funciona como um buffer temporário de linhas.

---

🧠 Modelo mental simples

Imagine o Data Stack como:

• Uma caixa de mensagens

• Onde você empilha (PUSH) ou enfileira (QUEUE) dados

• E depois retira (PULL / PARSE PULL)

📌 Muito parecido com:

• STDIN / STDOUT

• Pipe de Unix

• Buffer de mensagens

---

🔁 LIFO vs FIFO

O Data Stack suporta dois comportamentos:

Comando	Comportamento
PUSH	LIFO (último a entrar, primeiro a sair)
QUEUE	FIFO (primeiro a entrar, primeiro a sair)

---

🔹 Comandos principais do Data Stack

1️⃣ PUSH – empilha no topo

PUSH 'LINHA1'
PUSH 'LINHA2'
PULL x
say x        /* LINHA2 */

---

2️⃣ QUEUE – coloca no fim da fila

QUEUE 'LINHA1'
QUEUE 'LINHA2'
PULL x
say x        /* LINHA1 */

---

3️⃣ PULL / PARSE PULL – retira da stack

PARSE PULL a b c

---

📌 Data Stack x Variáveis

Aspecto	Variáveis	Data Stack
Estrutura	Escalar	Fila
Ordem	Fixa	FIFO / LIFO
Uso típico	Lógica	Comunicação
Persistência	Apenas no script	Pode cruzar comandos

---

🧩 Integração com comandos do sistema

Exemplo clássico – capturar saída de comando TSO

ADDRESS TSO "LISTDSI 'USER.TEST'"
PARSE PULL msg
say msg

📌 O comando escreve no Data Stack
📌 O REXX lê do Data Stack

---

🔄 Stacks múltiplas (avançado)

REXX permite criar pilhas separadas:

Comando	Função
NEWSTACK	Cria stack isolada
DELSTACK	Remove stack

Exemplo

NEWSTACK
QUEUE 'TEMP'
PULL x
say x
DELSTACK

💡 Essencial para:

• Macros ISPF

• SYSREXX

• Scripts grandes

---

🧠 Uso real no mainframe

✔ Capturar saída de:

• TSO

• ISPF

• SDSF

• OPERCMDS

✔ Passar dados entre:

• REXX ↔ COBOL

• REXX ↔ utilitários

✔ Evitar datasets temporários

---

⚠️ Erros clássicos (Easter Eggs 🥚)

❌ Esquecer de limpar stack
❌ Misturar PUSH e QUEUE sem critério
❌ Não usar NEWSTACK em macros
❌ Ler stack vazia (gera valores inesperados)

---

📋 Checklist rápido

• Sei se preciso FIFO ou LIFO?

• Stack está isolada (NEWSTACK)?

• Stack está limpa antes de sair?

• Uso PARSE PULL corretamente?

---

🧠 Frase final estilo Bellacosa Mainframe

Se você entende o Data Stack, você entende o REXX.
Ele é a ponte entre comandos, programas e o sistema.

 

 

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

1. Executar comando

2. Capturar mensagem

3. Interpretar resposta

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

🧠 Comparativo Mainframe REXX vs Shell Script vs Python

 

🧠 Comparativo Mainframe

REXX vs Shell Script vs Python

---

1️⃣ REXX (TSO/E – ISPF – Batch)

✅ Vantagens

✔ Nativo do mainframe (vem no z/OS)
✔ Integração direta com:

• TSO/E

• ISPF

• SDSF

• JES

• SYSREXX

• OPERCMDS / CONSOLE
  ✔ Chamada direta de programas COBOL/ASM (LINKPGM)
  ✔ Manipulação natural de datasets (PS, PDS, PDSE)
  ✔ Baixíssimo overhead
  ✔ Ideal para automação de produção

❌ Desvantagens

✖ Pouco conhecido fora do mundo mainframe
✖ Sintaxe estranha para quem vem de linguagens modernas
✖ Bibliotecas externas quase inexistentes
✖ Não é ideal para APIs REST modernas sem middleware

🎯 Quando usar

✔ Automação batch
✔ Operação e monitoração
✔ SYSREXX
✔ Orquestração COBOL / utilities
✔ Scripts críticos de produção

---

2️⃣ Shell Script (z/OS UNIX – OMVS)

✅ Vantagens

✔ Familiar para quem vem de Linux/Unix
✔ Bom para:

• FTP/SFTP

• Arquivos ASCII

• Integrações externas
  ✔ Excelente para pipelines simples
  ✔ Ótimo para chamadas de comandos USS

❌ Desvantagens

✖ Não é nativo do MVS
✖ Acesso ruim a:

• JES

• SDSF

• TSO

• RACF
  ✖ Manipulação de datasets MVS é limitada
  ✖ Debug difícil em produção
  ✖ Performance inferior para grandes volumes MVS

🎯 Quando usar

✔ Integração com mundo distribuído
✔ Transferência de arquivos
✔ Scripts híbridos mainframe ↔ Linux
✔ Orquestração simples em USS

---

3️⃣ Python (z/OS – USS / Open Source)

✅ Vantagens

✔ Linguagem moderna, popular
✔ Ecossistema enorme de bibliotecas
✔ Ideal para:

• APIs REST

• JSON / XML

• Analytics

• Automação DevOps
  ✔ Fácil integração com Git, CI/CD
  ✔ Curva de aprendizado curta

❌ Desvantagens

✖ Não é nativo MVS
✖ Precisa de:

• Ambiente USS

• Port de Python

• Gerenciamento de versões
  ✖ Performance inferior em I/O MVS pesado
  ✖ Acesso indireto a:

• JES

• SDSF

• RACF
  ✖ Overhead maior que REXX

🎯 Quando usar

✔ Modernização
✔ APIs e microserviços
✔ Integração cloud
✔ DevOps corporativo
✔ Análise de dados

---

4️⃣ Comparativo direto (tabela decisiva)

Critério	REXX	Shell	Python
Nativo z/OS	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐
Batch MVS	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐
JES / SDSF	⭐⭐⭐⭐⭐	⭐	⭐
Chamar COBOL	⭐⭐⭐⭐⭐	⭐	⭐⭐
APIs REST	⭐	⭐⭐	⭐⭐⭐⭐⭐
Performance	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐
DevOps	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Curva aprendizado	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

---

5️⃣ Regra de Ouro (mundo real)

❝ REXX governa o core do mainframe
❝ Shell conecta o mainframe ao Unix
❝ Python conecta o mainframe ao mundo moderno

💡 Arquitetura vencedora não escolhe um — combina os três.

---

6️⃣ Exemplo prático real

• REXX

  • Controla jobs batch

  • Chama COBOL

  • Lê JES / SDSF

• Shell

  • Move arquivos

  • Converte EBCDIC ↔ ASCII

• Python

  • Expõe API REST

  • Integra com GitHub / Jenkins

  • Analisa logs

---

7️⃣ Resumo executivo (para arquiteto)

Use se…	Ferramenta
Controle total do z/OS	REXX
Integração Unix	Shell
Cloud / APIs / DevOps	Python

---

🧩 Frase final estilo Bellacosa Mainframe

REXX é o cérebro do mainframe.
Shell é o braço que alcança o Unix.
Python é a ponte para o futuro.

 

✅ CHECKLISTS DE PRODUÇÃO – REXX MAINFRAME (z/OS)

---

1️⃣ Checklist Geral – Antes de colocar qualquer REXX em produção

☐ Objetivo do exec claramente definido
☐ Exec documentado no cabeçalho (nome, autor, data, função)
☐ Tratamento de erro implementado (SIGNAL ON ERROR, RC verificado)
☐ Uso de PROCEDURE para isolar variáveis
☐ Variáveis globais padronizadas (gVar, kConst)
☐ Nenhuma dependência “hardcoded” (HLQ, volumes, consoles)
☐ Exec testado com dados inválidos e cenários de erro
☐ Não deixa datasets alocados ao final
☐ Código revisado por outro analista (peer review)

---

2️⃣ Checklist – REXX Interpretado (TSO)

☐ Exec localizado em PDS autorizado (SYSEXEC ou SYSPROC)
☐ Não depende de perfil pessoal do usuário
☐ Usa ADDRESS TSO explicitamente quando necessário
☐ Usa EXIT RC adequado (0, 4, 8, 12…)
☐ Não usa TRACE ?R ou debug ativo em produção
☐ Não usa SAY excessivo (poluição de spool)
☐ EXECIO fecha corretamente arquivos (FINIS)
☐ Testado em sessão TSO limpa (sem allocations prévias)

---

3️⃣ Checklist – REXX Compilado (CEXEC / OBJECT)

☐ Código compilado com XREF para revisão
☐ Opções de compilação corretas:

• ☐ SLINE se usa TRACE ou SOURCELINE()

• ☐ ALT se precisa Alternate Library

• ☐ CONDENSE avaliado (trade-off load x execução)
  ☐ %COPYRIGHT incluído (requisito IBM / auditoria)
  ☐ Código não depende de comportamento interpretado
  ☐ Dataset CEXEC alocado corretamente no SYSEXEC
  ☐ Teste comparativo interpretado vs compilado validado
  ☐ Performance validada (CPU e tempo)

---

4️⃣ Checklist – Execução REXX em Batch (IKJEFT01)

☐ Programa correto (IKJEFT01, IKJEFT1A ou IKJEFT1B)
☐ SYSEXEC concatenado corretamente
☐ SYSTSIN definido corretamente
☐ SYSTSPRT definido para saída do REXX
☐ SYSPRINT definido para mensagens do sistema
☐ Não depende de interação (PULL sem input)
☐ RC do jobstep validado no JCL
☐ Exec não depende de terminal (ISPF, DISPLAY)

---

5️⃣ Checklist – REXX em Batch via IRXJCL

☐ Exec não usa comandos TSO (ALLOCATE, PROFILE, etc.)
☐ Todos os DDs necessários definidos no JCL
☐ Não usa SYSCALL / POSIX
☐ Uso de EXECIO validado com datasets físicos
☐ Testado isoladamente sem ambiente TSO
☐ RC tratado corretamente (IRXJCL retorna RC do exec)

---

6️⃣ Checklist – REXX com comandos MVS (CONSOLE)

☐ Usuário possui autoridade RACF:

• ☐ CLASS(CONSOLE)

• ☐ CLASS(OPERCMDS)
  ☐ CONSPROF configurado corretamente
  ☐ CONSOLE ACTIVATE e DEACTIVATE sempre pareados
  ☐ Uso de CART único por comando
  ☐ Uso de GETMSG() com timeout adequado
  ☐ Exec não bloqueia console (wait infinito)
  ☐ Exec retorna ao ADDRESS TSO ao final
  ☐ Tratamento de mensagens inesperadas implementado

---

7️⃣ Checklist – System REXX (SYSREXX)

🔹 Planejamento

☐ SYSREXX realmente necessário (não usar se TSO resolve)
☐ Exec não inicia com letras A–I
☐ Exec armazenado em REXXLIB (não alterar SYS1.SAXREXEC)
☐ Nome do exec documentado e único

---

🔹 Ambiente

☐ AXR subsystem ativo
☐ Parmlib AXR00 configurado
☐ CPF definido corretamente
☐ AXRUSER definido e validado
☐ Teste em ambiente não produtivo realizado

---

🔹 Execução

☐ Modo correto definido:

• ☐ TSO=NO (preferencial)

• ☐ TSO=YES (se precisa ALLOCATE)
  ☐ Exec não assume userid fixo
  ☐ Exec limpa recursos explicitamente
  ☐ Não depende de terminal ou ISPF
  ☐ Exec tolera execução concorrente

---

8️⃣ Checklist – Uso das Funções SYSREXX

AXRCMD

☐ Timeout definido
☐ Stem inicializado
☐ stem.0 validado
☐ Mensagens tratadas (não apenas exibidas)

AXRWTO / AXRMLWTO

☐ Uso consciente (não floodar console)
☐ ConnectId controlado
☐ LineType correto (L, D, DE)

AXRWAIT

☐ Tempo mínimo necessário
☐ Não usado como loop de espera infinita

---

9️⃣ Checklist – Segurança e Auditoria

☐ Exec documenta comandos críticos executados
☐ Nenhum comando destrutivo sem confirmação
☐ Exec compatível com RACF auditing
☐ Exec não eleva privilégio indevidamente
☐ Exec respeita ambiente SYSPLEX
☐ Logs rastreáveis (WTO, SYSLOG, dataset)

---

🔟 Checklist – Pós-produção

☐ Exec monitorado em produção
☐ CPU e tempo medidos
☐ Exec incluído em inventário técnico
☐ Plano de rollback definido
☐ Procedimento operacional documentado
☐ Responsável técnico identificado

---

📌 Comentário final (experiência de produção)

REXX em produção não falha por sintaxe — falha por falta de checklist.