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

⚡ Parte 2 – Shotaro Ishinomori

 

⚡ Parte 2 – Shotaro Ishinomori

👺 O Visionário que Criou os Heróis da TV Japonesa

Discípulo de Tezuka, Ishinomori misturou ficção científica e ação em um estilo inconfundível.
Criador de Cyborg 009 e Kamen Rider, ele inspirou o gênero tokusatsu e até os Power Rangers!

🔹 Curiosidades:

• Autor com maior número de volumes publicados (mais de 770!)

• Criou histórias com forte crítica social

• Considerado o “pai dos heróis japoneses”

🚀 Sua visão moldou o Japão moderno — entre a máquina e a alma humana.

🦸‍♂️ Biografia

⚡ O Arquiteto dos Heróis Japoneses

Shotaro Ishinomori era um verdadeiro mainframe criativo, conectando fios de mitologia, tecnologia e drama humano como se fossem sub-rotinas de um sistema universal de heroísmo. Antes dele, o conceito de super-herói japonês era limitado; depois dele, era infraestrutura cultural.

Criador de clássicos como Cyborg 009, Kamen Rider e Super Sentai, Ishinomori programou o DNA do tokusatsu moderno. Seus personagens não eram apenas combatentes contra o mal — eram ícones de esperança, códigos morais rodando em alta performance, capazes de transmitir coragem, justiça e emoção em cada episódio e página.

⚙️ Inovação constante
Enquanto o Japão se reconstruía, ele reinventava gênero após gênero: misturava ficção científica, drama humano e ação em sequências que pareciam algoritmos perfeitos. Cada transformação, cada moto, cada traje colorido era uma sub-rotina de empatia, calibrada para impactar gerações de crianças e adultos.

📖 Legado eterno
Ishinomori não se limitou à página ou à tela. Ele definiu a linguagem dos heróis japoneses. O conceito de equipe, o herói solitário que se sacrifica, os monstros que refletem a sociedade — tudo isso se tornou padrão global, influenciando quadrinhos, cinema e cultura pop.

🛡️ O programador da esperança
Mesmo após sua partida em 1998, seus códigos continuam ativos: cada criança que assiste Kamen Rider, cada fã que acompanha Super Sentai ou lê Cyborg 009 está rodando o sistema Ishinomori, aprendendo coragem, amizade e justiça.

Alguns criam histórias. Ishinomori criou protocolos de heroísmo que nunca param de rodar.

#ShotaroIshinomori #KamenRider #Cyborg009 #MangáClássico

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

🗾 Série: Os Mestres do Mangá — Parte 1

 

🗾 Série: Os Mestres do Mangá — Parte 1

🎨 Osamu Tezuka – O Deus do Mangá

Se hoje o mundo ama animes e mangás, é graças a ele.
🧠 Médico de formação, artista por paixão — Osamu Tezuka criou o estilo moderno do mangá e revolucionou a narrativa visual japonesa.

✨ Obras inesquecíveis:

• Astro Boy 🤖

• Kimba, o Leão Branco 🦁

• A Princesa e o Cavaleiro 👑

• Black Jack ⚕️

📚 Curiosidades:

• Publicou mais de 700 mangás e produziu 500 animações

• Dormia pouquíssimo para desenhar

• Foi chamado de “Deus do Mangá” (Manga no Kami-sama)

• Inspirou Akira Toriyama, Miyazaki e toda uma geração

🗯️ “Quero mostrar a beleza da vida. Porque cada ser vivo tem valor.” — Tezuka

🌀 Sem ele, talvez o mangá moderno nem existisse.

🧬 Biografia

🌟 O Deus do Mangá e do Anime

Osamu Tezuka não apenas escreveu histórias — ele programou o núcleo do entretenimento japonês. Conhecido como o “Deus do Mangá”, Tezuka operava em modo full-stack criativo: desenhava, roteirizava, inovava técnicas e definia padrões que ainda hoje rodam no sistema cultural do Japão e do mundo.

💡 Inovador absoluto
Com obras como Astro Boy (Tetsuwan Atom), Kimba, o Leão Branco e Black Jack, Tezuka redefiniu narrativa visual. Introduziu quadros cinematográficos, pausas dramáticas, personagens expressivos e diálogos densos — um upgrade definitivo para o mangá tradicional. Cada obra era um subprocesso de ética, emoção e imaginação, pronto para rodar em qualquer geração.

🌌 Explorador de temas complexos
Tezuka não temia tocar em vida, morte, guerra, moralidade e tecnologia. Seus universos misturavam humanidade e ciência, esperança e tragédia. Astro Boy, com seu coração de metal, tornou-se símbolo do potencial e da fragilidade humana — a interface perfeita entre máquina e emoção.

🎬 Pai do anime moderno
Além do papel, Tezuka revolucionou animação: produção em série, simplificação de movimentos e storytelling audiovisual. Criou pipelines criativos que permitiram o boom do anime, abrindo portas para tudo que veio depois — de Osamu Dezaki a Hayao Miyazaki.

🛡️ Legado eterno
Mais que mangaká, Tezuka foi sistema operacional da imaginação japonesa. Cada história sua continua rodando em nós, carregando mensagens de humanidade, ética e criatividade.

Alguns contam histórias. Tezuka compilou a alma do Japão em pixels e tinta.

#OsamuTezuka #Mangá #Anime #HistóriaDoMangá

 

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

✨🎨 OSAMU TEZUKA — O DEUS DO MANGÁ: O HOMEM QUE CRIOU UM MUNDO INTEIRO EM DESENHOS

Se hoje você ama animes e mangás, deve agradecer a um homem: Osamu Tezuka (1928–1989). Médico de formação, artista por vocação, e gênio por natureza, ele é o pilar fundamental da cultura otaku moderna. 🌸

---

👑 Quem foi Osamu Tezuka

Nascido em Osaka, Japão, Tezuka cresceu durante a Segunda Guerra Mundial e encontrou nos quadrinhos uma forma de escapar da realidade sombria. Influenciado pelos filmes da Disney e pela animação ocidental, ele criou um novo estilo narrativo, introduzindo expressões cinematográficas, enquadramentos dinâmicos e personagens com olhos grandes e emotivos — uma marca que se tornaria o padrão do anime moderno.

Apesar de ter se formado em medicina, Tezuka seguiu o chamado da arte. Seu lema era simples e poderoso:

“O que quero transmitir através dos meus mangás é a importância da vida.”

---

🖋️ Principais Obras

• 🧒 Astro Boy (Tetsuwan Atom, 1952)
  O primeiro herói robô com alma humana. Símbolo da era pós-guerra, Astro Boy mistura ética, tecnologia e emoção.
  → Curiosidade: foi o primeiro anime de sucesso mundial, abrindo as portas da animação japonesa.

• 👧 A Princesa e o Cavaleiro (Ribon no Kishi, 1953)
  Um dos primeiros mangás shoujo da história, com uma princesa que luta travestida de cavaleiro.
  → Um marco no empoderamento feminino dentro do mangá.

• 🐘 Kimba, o Leão Branco (Jungle Taitei, 1950)
  Conta a jornada de um leão que busca justiça e paz na selva.
  → Muita gente vê semelhanças com O Rei Leão da Disney — e a polêmica até hoje gera debates.

• ⛩️ Buda (Buddha, 1972–1983)
  Uma obra-prima filosófica e visual sobre a vida de Sidarta Gautama, o Buda histórico.
  → Mistura história, religião e humanidade em um épico espiritual.

• 💀 Black Jack (1973–1983)
  Um cirurgião genial que atua nas sombras, ajudando quem não tem voz.
  → Inspirado na própria formação médica de Tezuka — mistura drama, ética e dilemas morais.

---

🌍 A Revolução Tezuka

• Criou a estrutura moderna de mangá (quadros sequenciais, ritmo cinematográfico e storytelling profundo).

• Fundou o Tezuka Productions, estúdio que formou gerações de animadores.

• Foi o primeiro a adaptar mangá em série de TV, criando o formato de anime semanal.

• Publicou mais de 700 mangás e produziu mais de 500 animações durante sua vida.

---

💬 Curiosidades para Otakus

• Era chamado de “Manga no Kami-sama” — O Deus do Mangá.

• Dormia apenas algumas horas por dia, desenhando até o limite.

• Era obcecado por evolução, tanto biológica quanto artística.

• Inspirou mestres como Akira Toriyama (Dragon Ball), Hayao Miyazaki (Studio Ghibli) e Naoki Urasawa (Monster, Pluto).

• Seu trabalho "Pluto", reinterpretado por Urasawa, é uma homenagem direta a Astro Boy.

---

💫 Legado

Tezuka não apenas criou personagens — ele criou o conceito de narrativa emocional japonesa moderna.
Sem ele, talvez nunca existissem Naruto, One Piece ou Attack on Titan.
Seu traço simples escondia mensagens profundas sobre ética, amor, ciência e humanidade.

---

🧭 Frase que resume Tezuka

“O que quero retratar é a beleza da vida — porque cada ser vivo tem valor.”

---

💡 Para os otakus de hoje, conhecer Osamu Tezuka é mergulhar nas raízes daquilo que amamos: a emoção, a filosofia e a arte do mangá.
Ele não só desenhou histórias — ele desenhou o futuro.

 

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