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

 

📌 O que é STACK em REXX?

Em REXX, STACK é uma pilha (fila LIFO/FIFO) de linhas de texto usada para:

• Passar dados entre programas

• Simular entrada padrão (PULL)

• Trocar informações com JCL, TSO e batch

• Comunicação entre execs

👉 Pense na STACK como um buffer de entrada/saída em memória.

---

1️⃣ STACK ≠ variável

A STACK:

• Não é uma variável

• Não precisa ser declarada

• É global ao exec

• Armazena linhas de texto

Ela é usada automaticamente por:

• PULL

• PARSE PULL

• Alguns comandos de host

---

2️⃣ Comandos principais da STACK

📤 PUSH

Coloca uma linha no topo da pilha (LIFO).

PUSH 'linha 1'
PUSH 'linha 2'

Ordem de saída:

linha 2
linha 1

---

📥 QUEUE

Coloca uma linha no final da fila (FIFO).

QUEUE 'linha 1'
QUEUE 'linha 2'

Ordem de saída:

linha 1
linha 2

---

📄 PULL

Lê a próxima linha da STACK.

PULL dado

Se a STACK estiver vazia:

• Em TSO → lê do terminal

• Em batch → lê de SYSTSIN

• Em SYSREXX → comportamento depende do ambiente

---

3️⃣ Diferença clara: PUSH x QUEUE

Comando	Tipo	Uso típico
PUSH	Pilha (LIFO)	Processamento reverso
QUEUE	Fila (FIFO)	Simular input sequencial
PULL	Leitura	Consome a STACK

---

4️⃣ Exemplo simples e didático

/* REXX */
QUEUE 'primeiro'
QUEUE 'segundo'
QUEUE 'terceiro'

PULL a
PULL b
PULL c

SAY a
SAY b
SAY c

Saída:

primeiro
segundo
terceiro

---

5️⃣ STACK em Batch (uso real)

Em batch, a STACK é fundamental.

Exemplo: simular entrada para um programa

QUEUE 'MATH1 10 20'
QUEUE 'exit'
ADDRESS TSO
CALL 'PROGCOB'

O COBOL lê como se fosse input real.

---

6️⃣ STACK + EXECIO (padrão profissional)

'EXECIO * DISKR INPUT (STEM in.'
DO i = 1 TO in.0
  QUEUE in.i
END

DO WHILE QUEUED() > 0
  PULL linha
  SAY linha
END

---

7️⃣ Função QUEUED()

Retorna quantas linhas existem na STACK.

IF QUEUED() = 0 THEN
  SAY 'Stack vazia'

💡 Boa prática: sempre testar antes de PULL.

---

8️⃣ STACK como comunicação entre execs

QUEUE 'valor1'
QUEUE 'valor2'
CALL OUTROEXEC

PULL resposta

O outro exec pode consumir e devolver dados pela STACK.

---

9️⃣ Erros comuns (produção)

❌ Usar PULL sem saber de onde vem a entrada
❌ Deixar lixo na STACK
❌ Misturar PUSH e QUEUE sem critério
❌ Assumir que STACK sempre tem dados

✔ Sempre limpar ou controlar a STACK

---

🔟 Regra de ouro

STACK em REXX é entrada padrão controlável.
Quem domina STACK domina automação batch.

---

🧠 Frase para memorizar

QUEUE escreve o roteiro,
PUSH muda a ordem,
PULL executa a cena.

 

 

☕ SLINE, ALT, CONDENSE e XREF no REXX Mainframe

As “condições invisíveis” que mandam no batch (e quase ninguém percebe)

“O batch não falhou.
Ele apenas executou exatamente o que você mandou…
inclusive o que você não sabia que estava mandando.”

---

🧠 Introdução – O batch não é só JCL

Quando falamos de batch no mainframe, a maioria pensa em:

• JCL

• Utilities

• RC

• Cond codes

Mas quem já viveu produção sabe:

O verdadeiro controle do batch moderno está nos REXX intermediários.

E dentro desses REXX, existem condições operacionais silenciosas que raramente são documentadas, mas mudam completamente o comportamento do processamento:

👉 SLINE
👉 ALT
👉 CONDENSE
👉 XREF

Elas não aparecem no JCL.
Não geram ABEND.
Mas definem o destino do processamento.

---

🕰️ Origem histórica – Por que isso existe?

Esses conceitos nasceram entre o final dos anos 80 e início dos 90, quando:

• REXX começou a ser usado como cola entre utilities

• ISPF virou padrão

• O batch passou a depender de pré-processamento inteligente

• O volume de dados cresceu, mas o tempo de janela diminuiu

O REXX deixou de ser “script do programador” e virou:

Camada de controle semântico do batch

SLINE, ALT, CONDENSE e XREF surgem como padrões operacionais, não como comandos formais únicos.

---

📜 SLINE – A linha como unidade de decisão

O que é SLINE?

SLINE representa o conceito de Single Logical Line.

No batch tradicional:

• Você lê registros

• Processa campos

• Escreve saída

No REXX:

• A linha inteira vira contexto

• A decisão acontece antes do parsing pesado

Onde aparece?

• Leitura de SYSIN

• Pré-processamento de arquivos texto

• Logs JES, SYSOUT, relatórios

Exemplo conceitual

do while lines(infile) > 0
  sline = linein(infile)
  if pos('ERROR', sline) > 0 then ...
end

🧩 Curiosidade

SLINE é o motivo pelo qual muitos REXX detectam erro antes do COBOL rodar.

SLINE é o “olhar rápido” do batch.

---

🔁 ALT – Alteração controlada de realidade

O que é ALT?

ALT representa a alteração do conteúdo original, normalmente:

• Substituição

• Normalização

• Correção emergencial

ALT não é “editar”.
ALT é corrigir o mundo antes que o batch veja.

Exemplo

sline = changestr(';;', ';', sline)

Onde ALT reina?

• Arquivos vindos de sistemas externos

• Migrações

• Contornos de erro sem recompilar COBOL

⚠️ Comentário Bellacosa

ALT é poderoso… e perigoso.
Se você altera dados sem log, você está reescrevendo a história.

---

🧹 CONDENSE – Limpar antes de decidir

O que é CONDENSE?

CONDENSE elimina:

• Espaços redundantes

• Caracteres inválidos

• Ambiguidade de parsing

É o equivalente batch do:

“Vamos arrumar a casa antes de discutir.”

Exemplo

sline = space(sline, 1)

Por que isso importa?

Porque 90% das falhas de batch REXX vêm de espaços invisíveis.

Easter Egg técnico 🥚

Muitos problemas “intermitentes” desaparecem apenas adicionando CONDENSE.

Não era bug.
Era whitespace.

---

🔗 XREF – A memória do batch

O que é XREF?

XREF (cross reference) não é um comando REXX padrão.
É um conceito de rastreabilidade:

• De onde veio o dado

• Para onde ele foi

• Quem foi afetado

No REXX batch, XREF geralmente aparece como:

• Tabelas stem

• Arquivos auxiliares

• Logs correlacionados

Exemplo conceitual

xref.userid = jobname
xref.record = sline

Por que isso existe?

Porque batch sem XREF:

• Não é auditável

• Não é explicável

• Não é confiável

XREF é o que transforma automação em processo corporativo.

---

🧪 Exemplo integrado – O batch invisível

do while lines(in) > 0
  sline = linein(in)

  sline = space(sline, 1)          /* CONDENSE */
  sline = changestr('|', ';', sline) /* ALT */

  if pos('INVALID', sline) > 0 then do
     xref.error = sline             /* XREF */
     iterate
  end

  call lineout out, sline
end

Esse REXX:

• Limpa

• Corrige

• Decide

• Documenta

Tudo antes do COBOL rodar.

---

🧠 O que isso significa no processo batch?

SLINE, ALT, CONDENSE e XREF são:

• Condições implícitas

• Regras não declaradas

• Decisões fora do JCL

Eles definem:

• Se o job falha ou passa

• Se o dado é confiável

• Se o erro é detectado cedo

• Se o incidente é explicável depois

---

⚠️ O risco oculto

“Não está no JCL, então ninguém revisa.”

Esse é o maior perigo.

REXX batch sem governança vira:

• Caixa-preta

• Dependência de pessoa

• Fonte de incidente crônico

---

☕ Comentário final – Um Café no Bellacosa Mainframe

No mainframe moderno:

O JCL agenda.
O COBOL processa.
Mas o REXX decide.

E quem domina SLINE, ALT, CONDENSE e XREF entende que o batch não quebra por acaso — ele quebra por decisões invisíveis.

Conhecer essas condições não te torna um programador melhor.
Te torna um guardião do processamento.