Bellacosa Mainframe com uma overview do Dataset VSAM no z/os

🔥 VSAM NÃO MORREU — ELE SÓ ESTÁ RODANDO EM PRODUÇÃO HÁ 40 ANOS SEM ABEND

🧠 O Segredo Mais Subestimado do z/OS (e por que você ainda depende dele)

Se você é desenvolvedor COBOL raiz, daqueles que já viram JCL com mais linhas que romance russo, então sabe: VSAM não é só storage… é infraestrutura crítica disfarçada de dataset.

Enquanto o mundo fala de NoSQL, Data Lakes e Kubernetes, lá no coração do IBM z/OS, o VSAM continua firme, resiliente… e silenciosamente essencial.

---

🧬 Origem: quando performance era questão de sobrevivência

O VSAM nasceu nos anos 60 com o OS/VS, evoluindo até o que conhecemos hoje no z/OS. Ele foi criado para resolver limitações dos métodos antigos (ISAM principalmente), trazendo:

• Acesso indexado eficiente
• Gerenciamento automático de espaço
• Alta performance com grandes volumes

👉 Em outras palavras: VSAM foi o “Db2” antes do Db2 existir.

---

🚀 Versão atual relevante

Hoje, estamos na linha do:

👉 z/OS 3.x (como 3.1, 3.2, etc.)

E isso significa:

✔ VSAM atualizado automaticamente
✔ Melhorias de performance
✔ Integração com DFSMS
✔ Suporte a grandes volumes (EAV / Extended Addressability)

---

⚙️ O que evoluiu no VSAM ao longo do tempo

Mesmo sem “versão própria”, ele evoluiu MUITO:

🔹 Extended Addressability (EA)

• Saiu do limite de GB → foi para TB

🔹 RLS (Record Level Sharing)

• Concorrência real (quase “transacional”)

🔹 DFSMS

• Gerenciamento automático (ACS routines)

🔹 Buffering avançado

• Performance tuning muito mais fino

---

🧱 Onde o VSAM vive hoje

VSAM não é só “arquivo COBOL”:

👉 Ele é base de coisas grandes, como:

• IBM Db2 for z/OS (usa LDS por baixo)
• Catálogo do sistema
• Sistemas críticos bancários

💥 Ou seja:
Mesmo que você “não use VSAM”… você usa.

---

⚠️ Erro comum de iniciante (e até de sênior distraído)

Perguntar:

“Qual versão do VSAM estamos usando?”

👉 A pergunta correta é:

“Qual versão do z/OS estamos rodando?”

---

🗂️ Tipos de Arquivos VSAM (o coração da arquitetura)

🔑 KSDS — Key Sequenced Data Set (o rei do pedaço)

• Acesso por chave (PRIMARY KEY raiz do COBOL)
• Possui INDEX + DATA
• Suporta acesso sequencial e direto

💬 Comentário Bellacosa:
Se VSAM fosse banco de dados, o KSDS seria o OLTP raiz.

---

📦 ESDS — Entry Sequenced Data Set

• Registros gravados em ordem de entrada
• Sem chave
• Acesso via RBA (Relative Byte Address)

💬 Uso clássico: logs, trilhas de auditoria, arquivos append-only

---

🔢 RRDS — Relative Record Data Set

• Acesso via número relativo (RRN)
• Pode ter slots vazios
• Pode ser FIXED ou VARIABLE

💬 Parece simples… até você esquecer que tem slot vazio e dar READ errado 😅

---

🧱 LDS — Linear Data Set

• Sem estrutura lógica de registros
• Usado por sistemas como IBM Db2 for z/OS
• Base para tablespaces

💬 Aqui o VSAM vira “infra invisível”

---

⚙️ IDCAMS — O canivete suíço do VSAM

Se você nunca digitou isso, você não viveu:

//STEP01 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
  DEFINE CLUSTER(NAME(MEU.KSDS)
    INDEXED
    KEYS(10 0)
    RECORDSIZE(80 80)
    CYLINDERS(5 2))
/*

📌 Com o IDCAMS você:

• DEFINE / DELETE / ALTER
• REPRO (ETL raiz do mainframe)
• LISTCAT (o “SELECT * FROM VSAM”)

💬 Curiosidade:
O REPRO já fazia “data migration” décadas antes do termo existir.

---

🧠 Curiosidades que só quem viveu sabe

• VSAM usa Control Interval (CI) e Control Area (CA) — tuning fino de performance
• Split de CI/CA pode causar degradação se mal dimensionado
• Buffer tuning pode mudar completamente o desempenho
• SHAREOPTIONS define concorrência (e dor de cabeça 😄)

---

📊 VSAM vs SQL (Db2): o choque de paradigmas

VSAM	Db2
Navegacional	Declarativo
Ultra rápido	Flexível
Sem overhead	Com engine
Controle manual	Automação

👉 Hoje, o IBM Db2 for z/OS usa VSAM (LDS) por baixo.

💥 Plot twist: Você acha que saiu do VSAM… mas nunca saiu.

---

🧮 Limitações e características técnicas

• Máx. tamanho: até dezenas de TB (dependendo do tipo e configuração)
• Máx. keys:
  • 1 chave primária
  • múltiplos AIX (Alternate Indexes)
• Máx. tamanho de registro: ~32KB
• CI tamanho: 512 bytes até 32KB
• CA: múltiplos de CI

📌 Limitação real não é técnica — é governança e design

---

🧷 Pontos Fortes

✅ Performance absurda (baixo overhead)
✅ Estabilidade lendária
✅ Controle fino
✅ Ideal para batch massivo

---

⚠️ Pontos Fracos

❌ Complexidade operacional
❌ Curva de aprendizado alta
❌ Sem SQL nativo
❌ Manutenção manual (splits, tuning)

---

🧪 Exemplo COBOL clássico (KSDS)

READ MEU-KSDS
  KEY IS WS-CHAVE
  INVALID KEY
     DISPLAY 'NAO ENCONTRADO'
END-READ.

💬 Simples. Direto. Sem ORM. Sem mágica.

---

🚀 Versões atuais e evolução

VSAM continua sendo parte essencial do IBM z/OS (versões atuais como 3.x).

E evoluiu com:

• RLS (Record Level Sharing)
• DFSMS integração
• Melhorias de cache e buffering

---

📦 📊 Tamanho máximo de um VSAM (na prática e na teoria)

No IBM z/OS, o tamanho de um dataset VSAM não é um único número fixo — ele depende de:

• Tipo do VSAM (KSDS, ESDS, RRDS, LDS)

• Tamanho do CI (Control Interval)

• Quantidade de CA (Control Areas)

• Limitações do volume (DASD)

• SMS / DFSMS

---

🧠 💥 Resposta direta (o número que você quer)

👉 Um VSAM pode chegar a dezenas de TERABYTES

📌 Valores típicos modernos:

• Até ~128 TB por dataset (em ambientes modernos com Extended Addressability)
• Limitado principalmente pelo volume e configuração SMS

---

⚙️ 🔍 O que define esse limite?

1. 📦 Extended Addressability (EA)

Sem isso, você está preso ao passado.

• VSAM clássico: ~4 GB limite antigo
• VSAM com EA: escala para terabytes

💬 Se não tem EA habilitado → você está vivendo em 1985

---

2. 🧱 Control Areas (CA) e Control Intervals (CI)

• CI: até 32 KB
• CA: conjunto de CIs
• Total = CI × quantidade de CAs

👉 O VSAM cresce horizontalmente via CAs

---

3. 💽 Limite físico do DASD

Mesmo que o VSAM suporte muito:

• Seu volume pode limitar (3390, EAV, etc.)
• Multi-volume entra em jogo

---

🗂️ 📊 Por tipo de VSAM

Tipo	Tamanho Máximo
KSDS	Até dezenas de TB
ESDS	Similar ao KSDS
RRDS	Limitado por slots
LDS	Pode chegar a tamanhos enormes (base do Db2)

💬 LDS é o campeão pesado, porque é usado por IBM Db2 for z/OS

---

⚠️ 🚨 Limitações reais (as que doem em produção)

Não é o “máximo teórico” que quebra você… é isso aqui:

• CI mal dimensionado → splits constantes
• CA splits → degradação absurda
• AIX mal planejado → performance despenca
• Buffer tuning errado → gargalo invisível

💥 Ou seja:
👉 Você raramente quebra por tamanho — quebra por design

---

🧪 💡 Resumo estilo Bellacosa

👉 Teoricamente:
VSAM é gigante (TBs)

👉 Na prática:
Seu VSAM vai até onde seu projeto aguenta

---

☕ 🔥 Provocação final

Você está preocupado com o tamanho máximo…

…mas já olhou quantos CA splits seu KSDS teve hoje? 😏

---

🔑 Quantos AIX (Alternate Indexes) um KSDS pode ter?

IBM z/OS

💥 Resposta direta:

Até 255 Alternate Indexes (AIX)

---

🧠 Mas calma… isso é o limite TEÓRICO

Na prática, você raramente — quase nunca — chega perto disso.

---

⚙️ Como isso funciona por baixo dos panos

Cada AIX é:

• Um VSAM KSDS separado
• Com seu próprio INDEX + DATA
• Ligado ao cluster base via PATH

👉 Ou seja:

Você não tem “um arquivo com vários índices”

Você tem vários datasets VSAM interligados

---

🧱 Estrutura lógica

BASE CLUSTER (KSDS)
   ↓
   ├── AIX 1
   ├── AIX 2
   ├── AIX 3
   └── ...

Cada AIX:

• Pode ter chave diferente
• Pode permitir duplicidade (ou não)
• Pode ter upgrade automático (ou não)

---

⚠️ 🚨 Limitações reais (as que ferram em produção)

Aqui está o que ninguém te conta:

1. 🔥 Overhead de UPDATE

Cada WRITE/REWRITE no KSDS:

👉 Atualiza TODOS os AIX associados

💥 Resultado:

• I/O explode
• CPU sobe
• Batch começa a sofrer

---

2. 🧨 Risco de inconsistência

Se você não usar:

• UPGRADE
• PATH corretamente definido

👉 Pode ficar com AIX desatualizado

---

3. 🐌 Performance degradada

Quanto mais AIX:

• Mais lookup indireto
• Mais leitura de INDEX
• Mais complexidade

---

4. 💽 Espaço em disco

Cada AIX = outro VSAM

👉 10 AIX ≠ leve

👉 50 AIX = você criou um “pseudo-DB maluco”

---

📊 Regra de ouro (mundo real)

Quantidade de AIX	Situação
1–3	👍 Saudável
4–10	⚠️ Cuidado
10+	🚨 Arquitetura suspeita
50+	💀 Você perdeu o controle
255	☠️ Experimento acadêmico

---

🧪 Exemplo IDCAMS (AIX)

DEFINE ALTERNATEINDEX(NAME(MEU.AIX1)
  RELATE(MEU.KSDS)
  KEYS(5 0)
  RECORDSIZE(80 80)
  UPGRADE)

E o PATH:

DEFINE PATH(NAME(MEU.PATH1)
  PATHENTRY(MEU.AIX1))

---

💡 Insight estilo Bellacosa

👉 VSAM permite até 255 AIX…

Mas isso NÃO significa que você deve usar.

💥 Se você precisa de muitos índices:

👉 talvez o problema não seja VSAM… é modelagem

---

☕ Provocação 

Se o seu KSDS tem muitos AIX…

Você está usando VSAM…

ou tentando recriar o IBM Db2 for z/OS na unha? 😏

-----------------------------------------------------------------------------------

💡 Reflexão final (estilo Bellacosa Mainframe)

Enquanto muita gente corre atrás da “nova tecnologia revolucionária”…

👉 O VSAM está lá:

• Processando milhões de transações
• Sem downtime
• Sem hype
• Sem marketing

💥 VSAM não é legado. Ele é o alicerce.

---

☕ Provocação final

Você realmente entende VSAM…
ou só sabe fazer READ NEXT sem dar ABEND?

 

Bellacosa Mainframe ensina como encontrar um abend em menos de 60 segundos

🔥 O método de 60 segundos para descobrir por que um Job ABENDOU (sem abrir nenhum dataset)

No dia a dia de produção em IBM z/OS, quando um job ABEND acontece, muitos profissionais iniciantes começam abrindo datasets, dumps ou navegando em dezenas de telas.

Operadores experientes fazem diferente.

Eles usam um método rápido baseado no SDSF que normalmente revela a causa do problema em menos de 60 segundos — muitas vezes sem abrir nenhum dataset.

Este é um dos truques clássicos que circulam em grandes ambientes de produção.

☕ Bem-vindo a mais um Um Café no Bellacosa Mainframe.

---

🧠 A lógica por trás do método

Quando um job falha, o sistema sempre deixa rastros em três lugares principais:

1️⃣ Status do job
2️⃣ Mensagens do JES
3️⃣ Mensagens do sistema (SYSLOG)

O segredo é seguir a ordem correta.

---

⚡ Passo 1 — Abrir o SDSF e localizar o Job

Entre no SDSF:

SDSF

Depois vá ao painel de status:

ST

Agora filtre rapidamente:

PREFIX JOBNAME

Exemplo:

PREFIX PAYROLL*

Isso reduz a lista para apenas os jobs relevantes.

---

🔍 Passo 2 — Identificar rapidamente o ABEND

Na coluna RC / CC / ABEND você verá algo como:

ABEND=S0C7
ABEND=S322
ABEND=SB37

Cada código já indica uma pista importante.

Exemplos clássicos:

ABEND	Significado
S0C7	erro de dados numéricos
S0C4	violação de memória
S322	timeout (tempo excedido)
SB37	falta de espaço em dataset

Mas ainda não sabemos onde aconteceu.

---

📜 Passo 3 — Usar o “?” do SDSF (o atalho mais poderoso)

Digite ? ao lado do job.

Isso abre imediatamente o Job Output:

• JESMSGLG

• JESJCL

• JESYSMSG

Sem abrir nenhum dataset manualmente.

---

🎯 Passo 4 — Ir direto ao JESYSMSG

O arquivo JESYSMSG quase sempre contém a causa.

Procure por linhas como:

IEF450I JOBNAME ABENDED S0C7

ou

IEC030I B37-04

ou

CSV031I LIBRARY NOT FOUND

Em muitos casos a causa já aparece claramente aqui.

---

🔎 Passo 5 — Confirmar no SYSLOG

Agora abra o log do sistema:

LOG

e procure pelo JobID:

FIND JOB12345

Isso mostra mensagens do sistema relacionadas ao job.

Exemplos:

IEC141I DATA SET NOT FOUND

ou

IEF861I STEP TERMINATED DUE TO ERROR

---

⚡ Resultado: diagnóstico em menos de 60 segundos

Seguindo apenas estes passos:

SDSF
ST
PREFIX jobname
?
JESYSMSG
LOG
FIND jobid

Normalmente você já descobre:

✔ o step que falhou
✔ o tipo de erro
✔ a mensagem exata do sistema

Sem abrir nenhum dataset manualmente.

---

🧠 Exemplo real de diagnóstico

Imagine um job que termina assim:

ABEND=SB37

Seguindo o método:

No JESYSMSG aparece:

IEC030I B37-04 ON SYSDA

Diagnóstico imediato:

👉 Dataset ficou sem espaço.

Nenhuma investigação adicional necessária.

---

💡 A regra de ouro dos operadores experientes

Nos grandes datacenters existe uma regra não escrita:

“Se você abriu dataset antes de olhar o JESYSMSG, começou a investigação do jeito errado.”

80% dos problemas podem ser identificados apenas com SDSF.

---

☕ Conclusão

O segredo não está em ferramentas complexas.

Está em saber onde olhar primeiro.

Dominar o SDSF significa:

• investigar incidentes mais rápido

• reduzir tempo de troubleshooting

• ganhar confiança em ambientes de produção

E isso separa operadores iniciantes de profissionais experientes no mundo mainframe.

https://www.linkedin.com/pulse/o-m%C3%A9todo-de-60-segundos-para-descobrir-por-que-um-job-bellacosa-jxhkf

 

Bellacosa Mainframe falando sobre VSAM e seu motor otimizado para DATASETS

🔥 VSAM NÃO É ARQUIVO… É UM MOTOR OCULTO DO MAINFRAME — E VOCÊ AINDA ESTÁ USANDO COMO TXT?

Se você ainda trata VSAM como “um arquivo bonitinho com chave”, sinto te dizer: você está dirigindo uma Ferrari em primeira marcha.

Hoje, no melhor estilo Bellacosa Mainframe, vamos dissecar o conteúdo do artigo clássico do Macardeal — e ir MUITO além: origem, bastidores, armadilhas, dicas de guerra e até uns easter eggs que só quem já tomou ABEND às 3 da manhã conhece.

---

🧠 O QUE É VSAM (SEM ENROLAR)

VSAM (Virtual Storage Access Method) é um método de acesso a dados em disco (DASD) usado no mundo IBM mainframe — com estrutura orientada a registros e acesso direto ou sequencial

👉 Tradução Bellacosa:
VSAM não é arquivo. É um sistema de gerenciamento de dados low-level que antecede o banco.

O artigo original já aponta isso corretamente:

• acesso direto em disco
• leitura sequencial ou randômica
• controle via COBOL (READ, WRITE, START…)

Mas aqui vai o pulo do gato:

💡 VSAM é o “filesystem inteligente” que deu origem ao comportamento de bancos como DB2 e IMS.

---

🏛️ ORIGEM — O NASCIMENTO DO MONSTRO

VSAM nasceu nos anos 70 com o surgimento do MVS (Multiple Virtual Storage)

Ele veio para substituir dinossauros como:

• ISAM (lento, rígido)
• BDAM (baixo nível demais)

👉 Problema da época:
Os sistemas começaram a usar memória virtual… e os métodos antigos não acompanharam.

👉 Solução da IBM:
Criar algo:

• mais performático
• independente de hardware
• com indexação eficiente

Resultado: VSAM = a base de tudo que veio depois

---

⚙️ COMO ELE FUNCIONA (A PARTE QUE SEPARA OS JUNIORS DOS SENIORS)

Aqui mora a mágica…

VSAM organiza dados em:

• CI (Control Interval) → bloco de leitura/escrita
• CA (Control Area) → conjunto de CIs
• Cluster → Data + Index

👉 E o KSDS usa uma estrutura tipo B+ Tree

💥 Tradução Bellacosa:

VSAM já fazia indexação eficiente enquanto muito banco relacional ainda engatinhava.

---

📂 TIPOS DE VSAM (E QUANDO USAR)

Tipo	Quando usar	Mentalidade
KSDS	chave + acesso rápido	“quase um banco”
ESDS	append-only	log de eventos
RRDS	posição fixa	array persistente
LDS	sem estrutura	backend de DB

💡 Easter egg técnico:
👉 DB2 usa VSAM por baixo
👉 IMS também

Sim… você estava mexendo com VSAM sem saber.

---

🧪 COMANDOS COBOL (BASEADO NO ARTIGO)

O artigo traz o básico — e está correto:

• OPEN → abre dataset
• READ → leitura (direta ou NEXT)
• START → posicionamento lógico
• WRITE → grava
• REWRITE → update
• DELETE → remove

E o mais importante:

💣 FILE STATUS É SUA VIDA

Exemplo clássico citado:

• 00 → sucesso
• 10 → EOF
• 22 → duplicate key
• 23 → não encontrado

👉 Bellacosa insight:

Ignorar FILE STATUS é pedir pra tomar um ABEND fantasma.

---

🧰 IDCAMS — O “DDL DO VSAM”

O artigo mostra um DEFINE CLUSTER clássico — e isso é ouro.

👉 IDCAMS é:

• CREATE TABLE do VSAM
• DROP TABLE (DELETE CLUSTER)
• REBUILD INDEX (BLDINDEX)

💡 Dica avançada:

• FREESPACE evita split excessivo
• CISZ impacta performance
• RECORDSIZE mal definido = gargalo silencioso

---

⚠️ LIMITES (QUE NINGUÉM TE CONTA)

Vamos falar verdades:

🚫 VSAM NÃO TEM:

• JOIN
• SQL
• integridade relacional
• rollback nativo (sem CICS/RLS)

⚠️ PROBLEMAS CLÁSSICOS:

• CI/CA split → degrada performance
• espaço mal dimensionado
• locking complicado
• tuning altamente manual

💥 Tradução:

VSAM é poderoso… mas não é amigável.

---

🧠 DICAS DE GUERRA (EXPERIÊNCIA REAL)

✔ Sempre valide FILE STATUS
✔ Nunca ignore FREESPACE
✔ Planeje crescimento (CA split mata performance)
✔ Use Alternate Index com cuidado
✔ Batch → NSR | Online → LSR

👉 E a mais importante:

💣 VSAM não perdoa design ruim

---

🧨 CURIOSIDADES & EASTER EGGS

🔥 VSAM foi projetado antes de “NoSQL” existir
👉 Mas já era um NoSQL raiz

🔥 KSDS = B+ Tree
👉 mesmo conceito usado hoje em bancos modernos

🔥 Dataset catalog do MVS é VSAM
👉 o sistema roda sobre ele mesmo

🔥 LDS → base para DB2 tablespaces

👉 Conclusão:

VSAM não morreu… ele virou a fundação invisível.

---

🎯 CONCLUSÃO (ESTILO SOCO NA MESA)

Se você usa VSAM como “arquivo COBOL com chave”…

👉 você está subutilizando uma das tecnologias mais poderosas do mainframe.

VSAM é:

• storage engine
• indexador
• base de bancos
• e ainda roda bilhões de transações por dia

💣 VSAM não é legado.
Legado é a forma como você usa ele.

☕ EXECIO no REXX Mainframe O canivete suíço de I/O que todo mundo usa… e quase ninguém respeita

 

☕ EXECIO no REXX Mainframe

O canivete suíço de I/O que todo mundo usa… e quase ninguém respeita

“Quando o REXX toca no disco, o EXECIO está por trás.
E quando o disco fica lento, geralmente é culpa de quem não entendeu o EXECIO.”

---

🧠 Introdução – Onde o REXX encontra o mundo real

REXX é excelente para controle, decisão e orquestração.
Mas em algum momento ele precisa fazer o que todo batch faz desde 1964:

👉 Ler dados
👉 Escrever dados

É aí que entra o EXECIO.

Simples no nome.
Perigoso no impacto.

---

🕰️ Origem histórica – Por que o EXECIO nasceu?

Antes do EXECIO:

• REXX era fortemente interativo

• I/O era dependente de comandos externos

• Ler arquivos sequenciais era lento e improvisado

Com a popularização do REXX no TSO/E e no batch, a IBM precisava de:

• Um método padrão

• Um comando eficiente

• Compatível com DDNAME

• Funcional tanto em TSO quanto em batch

Assim nasceu o EXECIO, no final dos anos 80, como ponte direta entre:

REXX ⇄ QSAM ⇄ MVS

---

📜 O que é EXECIO?

EXECIO é o comando REXX responsável por:

• Ler registros de um DDNAME

• Escrever registros em um DDNAME

• Transferir dados entre datasets e variáveis REXX

Ele trabalha sempre com:

• DDNAME alocado

• Registros sequenciais

• Stem variables

---

🧪 Sintaxe essencial

EXECIO <quantidade> DISKR <ddname> (STEM var.
EXECIO <quantidade> DISKW <ddname> (STEM var.

Exemplo básico:

EXECIO * DISKR SYSIN (STEM linhas.

Aqui:

• * = todas as linhas

• DISKR = leitura

• SYSIN = DDNAME

• linhas. = onde os dados vão morar

---

🧩 Curiosidades que pouca gente comenta

🧩 1. EXECIO não entende “arquivo”

Ele entende DDNAME.

Se o DDNAME não existe:

• RC pode ser enganoso

• O erro aparece em mensagem

• GETMSG vira obrigatório

---

🧩 2. EXECIO * carrega tudo na memória

EXECIO * DISKR BIGFILE (STEM big.

Se o arquivo tem:

• 10 mil linhas → ok

• 1 milhão → boa sorte

EXECIO * é confortável… até não ser.

---

🧩 3. A variável .0 manda mais que você

Após leitura:

say linhas.0

Ela contém quantos registros foram lidos.

Ignorar .0 é convite a loop errado.

---

🥚 Easter Eggs técnicos

🥚 1. Leitura parcial estratégica

EXECIO 1 DISKR INDD (STEM linha.

Ótimo para:

• Ler cabeçalhos

• Identificar layout

• Decidir processamento sem ler tudo

---

🥚 2. EXECIO + Data Stack

É possível combinar:

• EXECIO

• PUSH / QUEUE

• PARSE PULL

Criando pipelines “à moda antiga”.

---

🥚 3. EXECIO em SYSREXX

No batch, EXECIO:

• Roda sem terminal

• Depende totalmente do JCL

• É mais rápido

• É mais perigoso

---

🧠 Exemplo prático – Batch inteligente

EXECIO * DISKR INPUT (STEM in.
DO i = 1 TO in.0
  IF POS('ERRO', in.i) > 0 THEN DO
     SAY 'Erro detectado na linha' i
     EXIT 8
  END
END
EXECIO in.0 DISKW OUTPUT (STEM in.

Esse REXX:

• Lê

• Analisa

• Decide

• Escreve

Tudo antes do COBOL rodar.

---

⚠️ Riscos reais do EXECIO

• Arquivo grande → consumo de memória

• DISKW sem controle → overwrite silencioso

• DISKR sem validação → loop infinito

• Falta de fechamento → dados inconsistentes

Boa prática Jedi

EXECIO 0 DISKW OUTDD

Força flush e fechamento correto.

---

🛡️ EXECIO e segurança

EXECIO respeita:

• RACF

• Permissões de dataset

• Contexto do job

Mas:

REXX que escreve dados é tão poderoso quanto um utility IBM.

Controle de acesso é obrigatório.

---

☕ Comentário Bellacosa Mainframe

O EXECIO é o momento em que:

• O REXX deixa de ser “script”

• E passa a mexer em dados corporativos

Quem trata EXECIO como “detalhe”:

• Cria batch frágil

• Gera incidentes silenciosos

• Descobre o erro em produção

EXECIO não é comando.
É compromisso com o dado.

---

🧠 Frase final para colar no monitor

Se o REXX leu, ele é responsável.
Se escreveu, ele é culpado até prova em contrário.