Uma visão geral sobre o trabalhador de Mainframe

Equipe de desenvolvimento mainframe

Descubra a Stack MAINFRAME e veja o que necessita para ser um Desenvolvedor COBOL de Sucesso. Aprenda COBOL, há 65 anos revolucionando o mercado de informática.

Conheças algumas vantagens de desenvolver em COBOL Mainframe

Stack Mainframe

Descubra a Stack MAINFRAME Aprenda COBOL, há 65 anos revolucionando o mercado de informática.

Como Programar sem Violar a Fortaleza do z/OS ☕🔐

 

Bellacosa Mainframe comenta sobre os risco e perigos e elogia o guardião RACF

🔥 Manual de Segurança RACF para Desenvolvedores

Como Programar sem Violar a Fortaleza do z/OS ☕🔐

No Mainframe, segurança não é um módulo.
É uma camada estrutural invisível que permeia tudo.

E no coração dessa segurança está o RACF (Resource Access Control Facility).

Para o desenvolvedor, RACF pode parecer apenas “aquele erro de autorização”.
Na realidade, ele é o guardião de:

🏦 dados bancários
🪪 informações pessoais
📊 bases governamentais
🧾 registros legais
💰 trilhões em transações

Entender RACF não é opcional — é requisito profissional.

---

🧠 1) Você não “bypass” RACF — você trabalha com ele

Não existe atalho legítimo.

Se o acesso foi negado, é porque:

👉 Você não precisa dele
👉 Falta autorização formal
👉 O recurso é sensível
👉 Há segregação de funções

Profissionais maduros não pedem acesso amplo — pedem acesso correto.

---

🔒 2) Princípio do Menor Privilégio

Regra fundamental:

Tenha apenas o acesso necessário para sua função.

Isso reduz:

✔ Risco de erro humano
✔ Possibilidade de abuso
✔ Impacto de incidentes
✔ Superfície de ataque

Se você tem acesso demais, algo está errado.

---

📁 3) Dataset é recurso protegido

Cada dataset pode ter regras específicas.

Níveis comuns de acesso:

• READ — leitura

• UPDATE — alteração

• CONTROL — manipulação avançada

• ALTER — controle total

Nunca assuma que READ permite processamento completo.

---

🏦 4) Bibliotecas de produção são zonas críticas

Load libraries e datasets de produção são altamente protegidos.

Desenvolvedores normalmente:

❌ Não podem alterar diretamente
✔ Devem promover via processos formais
✔ Passam por change management
✔ São auditados

Isso garante integridade operacional.

---

🧾 5) Logs existem — e são analisados

Cada tentativa de acesso pode ser registrada.

Auditores conseguem ver:

📅 Quem acessou
🕒 Quando acessou
📦 Qual recurso
❌ Tentativas negadas
⚠ Padrões suspeitos

Transparência é total.

---

🧠 6) IDs pessoais são responsabilidade individual

Nunca compartilhe sua credencial.

Seu ID representa você legal e operacionalmente.

Tudo feito com ele é atribuído a você.

---

🛑 7) Hardcode de credenciais é proibido

Código não deve conter:

❌ Senhas
❌ IDs de usuário
❌ Tokens
❌ Dados sensíveis

Além de inseguro, viola normas de auditoria.

---

🔐 8) RACF também protege programas

Não apenas dados.

Pode controlar execução de:

• Programas autorizados

• Transações CICS

• Comandos do sistema

• Recursos UNIX

• Serviços especiais

Isso evita uso indevido de funções críticas.

---

🔁 9) Ambientes são segregados

Desenvolvimento, teste e produção possuem regras diferentes.

Mover código entre ambientes requer:

✔ Aprovação formal
✔ Procedimentos controlados
✔ Registro da mudança

Acesso direto à produção é raro e justificado.

---

📊 10) Segurança influencia o design do software

Aplicações devem considerar:

✔ Controle de acesso
✔ Proteção de dados sensíveis
✔ Logs apropriados
✔ Não exposição de informações confidenciais

Segurança não é “camada externa”.

---

🧯 11) Violação pode gerar consequências sérias

Dependendo do ambiente:

⚠ Investigação interna
⚠ Revogação de acessos
⚠ Medidas disciplinares
⚠ Implicações legais

Mainframe é ambiente regulado.

---

🧩 12) Peça ajuda ao time de segurança

Não tente “descobrir sozinho”.

Equipes RACF existem para:

✔ Conceder acessos corretos
✔ Explicar políticas
✔ Garantir conformidade
✔ Evitar incidentes

Colaboração é parte do processo.

---

🏛️ 13) Segurança é base da confiança no Mainframe

O motivo de bancos e governos confiarem no z/OS é simples:

🔒 Controle rigoroso
📜 Auditoria forte
🧱 Arquitetura segura
⏳ Estabilidade comprovada

Sem RACF (ou equivalente), esse nível de confiança não existiria.

---

☕ Filosofia Bellacosa Mainframe

Desenvolvedor maduro não luta contra a segurança.

Ele entende que:

“Se o sistema financeiro mundial confia nessa plataforma, a segurança precisa ser implacável.”

---

⭐ Conclusão

RACF não é obstáculo.
É proteção — inclusive para você.

Quando usado corretamente:

✔ Evita erros catastróficos
✔ Garante conformidade regulatória
✔ Protege dados sensíveis
✔ Sustenta operações críticas

“No Mainframe, segurança não é feature. É fundação.”

 

☕🔥 “O Dia em que o Mainframe Aprendeu Big Data — e o Mundo Percebeu que Sempre Foi Assim”

Apache Spark no z/OS: quando a inteligência vai até o cofre

Durante anos venderam a ideia de que Big Data nasceu fora do mainframe.

Hadoop. Cloud. Clusters baratos. Data Lakes infinitos.

Enquanto isso, silenciosamente, o IBM Z continuava processando:

• Transações globais

• Sistemas bancários

• Seguros

• Cartões

• Governos inteiros

Então veio um momento histórico:

E se o motor de analytics moderno rodasse dentro do mainframe?

Nascia o Spark no z/OS.

---

🧠 O que é o Apache Spark (de verdade)

Ele revolucionou o processamento distribuído porque:

• Trabalha em memória (in-memory computing)

• Executa pipelines complexos via DAG

• Suporta SQL, streaming e machine learning

• Escala horizontalmente

Hoje é um dos pilares da engenharia de dados moderna.

Mas sua verdadeira transformação começou quando encontrou o mainframe.

---

🏛 Quando Spark encontrou o z/OS

O z/OS é o sistema operacional que roda nos computadores mais resilientes já construídos.

No mundo real, os dados mais valiosos vivem aqui:

• Db2 for z/OS

• IMS

• CICS

• VSAM

• SMF

• Logstreams

Mover esses dados para fora sempre foi caro, lento e arriscado.

Spark no z/OS muda o paradigma:

Não leve o dado ao analytics.
Leve o analytics ao dado.

---

📅 História e Release

A plataforma IBM z/OS Platform for Apache Spark foi anunciada oficialmente em 2016.

Foi um movimento estratégico da IBM para:

• Modernizar analytics no mainframe

• Integrar IA ao core transacional

• Evitar exfiltração massiva de dados

• Preparar o Z para a era Data-Driven

Foi também um reconhecimento implícito:

O mainframe nunca deixou de ser o maior data platform do mundo.

---

⚙️ Como o Spark roda no z/OS

Spark executa no z/OS via:

• USS (Unix System Services)

• JVM (Java é obrigatório)

• Deployment Standalone

• Processos distribuídos entre LPARs (Sysplex)

Arquitetura típica:

Master daemon  → Cluster Manager
Slave daemon   → Worker Node
Executors      → Processamento paralelo
MDSS           → Ponte para dados MVS

O MDSS (Mainframe Data Service for Apache Spark) é a peça secreta.

Sem ele, Spark só vê dados “tipo Linux”.
Com ele, enxerga o coração do z/OS.

---

🔐 A arma secreta: processar dados sem movê-los

Em ambientes distribuídos tradicionais:

1. Extrai dados do mainframe

2. Copia para Data Lake

3. Processa

4. Reimporta resultados

Cada passo aumenta:

• Latência

• Custos

• Risco de vazamento

• Complexidade operacional

Com Spark no z/OS:

O processamento acontece no mesmo ambiente seguro.

RACF, criptografia e auditoria continuam protegendo tudo.

---

🧩 O papel do MDSS

O Mainframe Data Service for Apache Spark permite acessar dados clássicos como:

• VSAM

• Sequential datasets

• IMS

• SMF

• Logstream

Ele roda como started task, controlado por ISPF ou Data Service Studio.

Sem ele, Spark não entende formatos MVS.

Com ele, Spark enxerga décadas de história corporativa.

---

🚀 Funcionalidades herdadas do Spark padrão

z/OS Spark mantém praticamente todas as capacidades modernas:

✔ Spark SQL
✔ Machine Learning (MLlib)
✔ Graph processing (GraphX)
✔ Streaming
✔ Integração JDBC
✔ APIs REST
✔ Execução distribuída

A principal exceção histórica:

👉 Não suporta desenvolvimento em R.

---

🤝 Integração com programas tradicionais

Uma das features mais impressionantes:

Spark pode conversar com aplicações escritas em:

• COBOL

• PL/I

• Assembler

• Natural

Inclusive acessar dados e programas via CICS.

Isso cria um cenário único:

Machine Learning moderno dialogando com sistemas escritos há 40 anos — em produção global.

---

🧠 Curiosidades que pouca gente conta

🟡 O mainframe sempre foi Big Data

Antes de “Big Data” existir como buzzword, o Z já processava volumes gigantes.

🟡 zIIP pode reduzir custo do analytics

Workloads Java e analytics podem ser offloadados.

🟡 Parallel Sysplex = cluster de verdade

Sem SPOF, com disponibilidade absurda.

🟡 Segurança nativa imbatível

Copiar dados para fora frequentemente reduz segurança.

---

🥚 Easter Eggs arquiteturais

👉 Spark foi criado para clusters baratos distribuídos
👉 O IBM Z é o oposto: um supercomputador vertical

Quando os dois se encontram, surge algo raro:

Escala horizontal + potência vertical

É como colocar um motor de foguete num trem blindado.

---

🧠 Casos reais de uso

• Fraud detection em tempo real

• Análise de comportamento transacional

• Capacity planning via SMF

• Detecção de anomalias operacionais

• Analytics regulatório

• Scoring de crédito instantâneo

---

☕ Comentário Bellacosa

Durante anos disseram:

“Para inovar, saia do mainframe.”

Hoje a mensagem é outra:

“Se você quer inovar sem quebrar o core do negócio, traga a inovação para o mainframe.”

Spark no z/OS não é nostalgia.

É pragmatismo.

---

🎯 Conclusão

Apache Spark no z/OS representa algo maior do que tecnologia.

Representa uma mudança de mentalidade:

✔ O mainframe não é legado — é fundação
✔ Big Data não substitui o Z — complementa
✔ Segurança e analytics podem coexistir
✔ O futuro não é cloud ou mainframe — é híbrido

---

☕ Frase final de boteco mainframe

O mundo tentou levar os dados para a nuvem.

O IBM Z respondeu:

“Tragam a nuvem até mim.”

Atraves do espelho: TSO / ISPF Login Process

 

Através do Espelho: TSO / ISPF Login Process

A porta, o cofre e a sala de controle do IBM z/OS

“Antes de rodar um JOB,
antes de editar um COBOL,
antes de caçar MIPS…
todo mainframeiro passa pelo mesmo ritual.”

O login TSO/ISPF não é apenas um passo técnico.
Ele é o controle de acesso ao coração financeiro do planeta.

Vamos destrinchar esse processo como ele realmente funciona, e por que ele existe desse jeito há décadas — e continua absolutamente atual em 2026.

---

🧠 Por que o login no mainframe é diferente?

Porque o mainframe não é um notebook pessoal.

Estamos falando de um ambiente:

• Multiusuário

• Multiempresa

• Missão crítica

• 24x7x365

• Onde um erro pode parar um país

Logo:

Nada começa sem identidade, autorização e controle.

---

👤 Passo 1 — User ID: quem é você no mundo z/OS

No IBM z/OS, ninguém é anônimo.

Cada usuário recebe um User ID, que é muito mais do que um “login”.

O User ID define:

👤 Quem você é
🛂 O que você pode ou não acessar
📁 Quais datasets são seus
🗂️ Quais JOBs você pode submeter
🛡️ Quais recursos do sistema você enxerga

Em linguagem Bellacosa:

O User ID é sua identidade civil no mainframe.

Sem ele:

• Não existe sessão

• Não existe ISPF

• Não existe batch

• Não existe nada

---

🔐 Passo 2 — Password: provando que você é você

O password valida sua identidade.

Mas aqui não estamos falando de senha fraca de rede social.

No mainframe, o password:

🔐 Protege bilhões em dados
🛡️ Trabalha junto com RACF (ou ACF2 / Top Secret)
📜 Atende políticas rígidas de segurança corporativa
🚨 Bloqueia tentativas indevidas automaticamente

Dica El Jefe:

Errou senha demais?
Bem-vindo ao bloqueio automático e à ligação para o suporte.

Segurança aqui não é opcional, é contrato social.

---

🧱 Entre o password e o ISPF existe o TSO

Após User ID + Password válidos, acontece algo fundamental:

👉 Uma sessão TSO é criada.

Isso significa:

• O sistema aloca recursos

• Controla prioridade

• Define limites

• Registra auditoria

Sem TSO:

Não existe interação com o z/OS.

TSO é o ambiente base, invisível para muitos, essencial para todos.

---

📋 Passo 3 — ISPF Panels: onde o trabalho começa

Só depois disso o usuário entra no ISPF.

ISPF não é login.
ISPF é produtividade.

Os painéis ISPF oferecem:

📋 Menus estruturados
🔢 Navegação clara
✍️ Editores robustos
⚙️ Gestão de datasets, JCL, programas

Em linguagem Bellacosa:

ISPF é a sala de controle.

É ali que:

• O COBOL nasce

• O JCL roda

• O erro aparece

• O padawan vira mainframeiro

---

🔁 O fluxo completo, sem romantização

O login real funciona assim:

User ID
   ↓
Password
   ↓
Sessão TSO criada
   ↓
Entrada no ISPF

Ou, resumindo:

Identidade → Autenticação → Sessão → Produtividade

---

🏗️ Analogia Bellacosa (clássica)

• User ID → Quem você é

• Password → Prova que é você

• TSO → Portaria + controle de acesso

• ISPF → Sala de operações

Sem portaria:

• ninguém entra

Sem sala de operações:

• ninguém trabalha

---

⚠️ Erros clássicos de padawan

❌ Achar que ISPF faz login
❌ Ignorar o papel do TSO
❌ Não entender RACF
❌ Tratar User ID como “só um login”

Dica de veterano:

Quem entende login entende segurança.
Quem entende segurança nunca é pego de surpresa.

---

🥚 Easter-eggs do cotidiano z/OS

• Todo mundo já ficou preso no painel de login

• Todo mundo já teve User ID revogado

• Todo mundo já decorou PF3 para sair

• Todo mundo já respeitou o cadeado 🔐 no RACF

---

☕ Palavra final do El Jefe

No mainframe, nada começa sem controle.

O processo de login TSO/ISPF não é burocracia.
É engenharia de segurança em escala planetária.

Se TSO é o portão,
e ISPF é a sala de controle…

Então lembre-se:

Só entra quem pode.
Só trabalha quem entende.

 

🧠 “SMF como fonte de verdade para observabilidade corporativa”

Porque antes de existir observability platform, já existia evidência

---

☕ 01:38 — Quando o gráfico mente, mas o SMF não

Todo mainframer aprende cedo uma verdade incômoda:
logs contam histórias, métricas sugerem hipóteses, mas o SMF registra fatos.

Enquanto o mundo distribuído ainda debate o que é single source of truth,
o z/OS já resolveu isso há décadas — e deu o nome de System Management Facility.

---

🧬 Um pouco de história (quando observabilidade não tinha marketing)

O SMF nasceu para:

• auditoria

• cobrança

• capacidade

• performance

• rastreabilidade

Não para “monitorar bonito”,
mas para provar o que aconteceu.

📌 Comentário Bellacosa:
SMF nunca foi sexy. Foi confiável. E isso envelhece melhor.

---

🔍 O que o SMF realmente é (traduzindo para cloudês)

No mundo moderno:

• Logs

• Metrics

• Traces

No z/OS:

• Tudo isso… em um formato só

• Com timestamp confiável

• Com contexto de sistema

• Com impacto mensurável

🔥 Tradução direta:
SMF é observabilidade com evidência jurídica.

---

🧠 SMF como “fonte de verdade”

Por que o SMF é a source of truth?

✔️ É gerado pelo sistema operacional
✔️ Não depende da aplicação “colaborar”
✔️ Não perde evento por backpressure
✔️ Não é amostrado
✔️ Não é opinativo

😈 Easter egg:
Se o SMF não viu, provavelmente não aconteceu.

---

📊 Comparação honesta: SMF x Observabilidade moderna

Observabilidade moderna	SMF
Métricas amostradas	Dados completos
Traces instrumentados	Evidência sistêmica
Logs verbosos	Registros estruturados
Dashboards	Capacidade histórica
Alertas	Diagnóstico pós-morte

📌 Comentário ácido:
Dashboard serve para avisar.
SMF serve para explicar.

---

🧭 Passo a passo mental: usando SMF como observabilidade

1️⃣ Coleta contínua (SMF ativo é pré-requisito)
2️⃣ Classificação por tipo (CPU, I/O, CICS, DB2, MQ…)
3️⃣ Correlação temporal
4️⃣ Análise de impacto real
5️⃣ Conclusão baseada em dado, não sensação

🔥 Regra de ouro:
Sem correlação, métrica vira superstição.

---

🧩 SMF e aplicações distribuídas (onde os mundos se encontram)

Hoje, arquiteturas são:

• híbridas

• distribuídas

• event-driven

O SMF entra como:

• referência de carga real

• baseline de comportamento

• âncora de verdade

📌 Exemplo prático:
Quando a API “fica lenta”, o SMF diz:

• se foi CPU

• se foi I/O

• se foi concorrência

• ou se foi culpa de quem chamou demais

---

📚 Guia de estudo para o mainframer moderno

Conceitos essenciais

• Observabilidade ≠ Monitoramento

• Correlação ≠ Alerta

• Evidência ≠ Opinião

• Capacidade ≠ Pico momentâneo

Exercício recomendado

👉 Pegue um incidente passado
👉 Releia só o SMF
👉 Ignore dashboards
👉 Reescreva a RCA

O resultado costuma ser… desconfortável — e correto.

---

🎯 Aplicações reais no mundo corporativo

• Auditoria e compliance

• Capacity planning sério

• SRE corporativo

• Integração com AIOps

• Base para observabilidade híbrida

🔥 Comentário Bellacosa:
Todo AIOps sério começa com dado confiável.
E dado confiável tem sobrenome: SMF.

---

🖤 Epílogo — 03:27, incidente encerrado

Quando o ruído some,
quando o gráfico contradiz o discurso,
quando a RCA precisa sobreviver a auditoria…

é o SMF que fica.

El Jefe Midnight Lunch assina:
“Observabilidade é saber. SMF é provar.”

 

 

COBOL e os desafios do GITHUB e ECLIPSE

🔥 Challenges of Running COBOL with Git – Uma Observação Prática (com cheiro de sala-cofre) 🔥

Durante décadas, COBOL e z/OS viveram felizes no seu ecossistema fechado, previsível e extremamente confiável. ISPF, PDS/PDSE, JCL, compile noturno, café forte e aquele silêncio respeitoso do data center. Então alguém chegou dizendo:

“Agora tudo é Git. Branch, pull request, rebase e pipeline.”

🤔 Pause dramático de mainframer veterano.

Este artigo nasce de pesquisa, observação prática e muita conversa de corredor — aquele tipo de conhecimento que não aparece em Redbook, mas surge no café das 3h da manhã durante um IPL mal-humorado.

---

🧬 1. EBCDIC vs UTF-8 – A Guerra Invisível dos Bytes

Aqui começa o primeiro boss final.

Git assume UTF-8. COBOL em z/OS respira EBCDIC. Misture isso sem regras claras e você ganha:

• Literais corrompidos

• DISPLAY mostrando hieróglifos

• Compilação falhando sem erro “óbvio”

💡 Dica Bellacosa:
Defina conversão explícita e obrigatória no pipeline. Nada de “ah, o plugin cuida disso”. Ele não cuida.

🥚 Easter egg:
Muitos bugs “fantasma” em COBOL moderno não são lógicos — são encoding bugs disfarçados.

---

📚 2. Copybooks – O Efeito Dominó Silencioso

COBOL sem copybook é como mainframe sem SMF: tecnicamente existe, mas ninguém confia.

O problema?
Git não entende dependência semântica.

• Um copybook alterado

• 137 programas impactados

• 12 recompilados

• 125 esquecidos

• Produção quebra… só amanhã

💡 Dica de guerra:
Pipeline dependency-aware é obrigatório. Ferramentas como DBB, scripts de impacto ou metadados não são luxo — são sobrevivência.

🗣 Fofoquinha real:
Já vi incidente crítico porque “era só um copybook de comentário”. Spoiler: não era.

---

📐 3. Diffs, Colunas e a Maldade do Espaço em Branco

Git ama linhas.
COBOL ama colunas.

Um espaço fora do lugar vira:

• Diff gigante

• Merge impossível

• Revisão inútil

Comentários deslocados geram mais conflito que erro lógico.

💡 Dica Bellacosa raiz:

• Padronize formatação

• Use ferramentas de pretty-print COBOL

• Trate espaço em branco como código, não estética

🥚 Easter egg clássico:
Um MOVE perfeito na lógica pode falhar só porque começou na coluna errada. Git não entende isso. O compilador sim — e ele não perdoa.

---

⚙️ 4. Build, Compile e o “CI/CD de Verdade”

Aqui mora a grande ilusão moderna:

“Ah, só dar git push que compila.”

Não, não compila.

COBOL exige:

• Compile no z/OS

• Link-edit

• Bind DB2

• Execução JCL

• Controle de RC

• Logs rastreáveis

Sem automação real, Git vira apenas um repositório bonito.

💡 Dica prática:
Se o commit não dispara compile, bind e validação automática, você não tem CI/CD — só tem GitHub caro.

---

🧠 5. Cultura, Pessoas e o Choque de Gerações

Aqui não é tecnologia — é gente.

• Desenvolvedores COBOL dominam ISPF como ninguém

• Git traz conceitos novos: rebase, squash, branch strategy

• Sem cuidado, isso vira atrito desnecessário

💡 Dica de liderança técnica:
Não force Git “goela abaixo”. Traduza conceitos:

• Branch ≈ versão lógica

• Pull request ≈ revisão formal

• Pipeline ≈ JCL automático

🗣 Comentário de bastidor:
Os melhores times são híbridos: mainframers aprendendo Git e devops aprendendo z/OS. Quem só ensina e não aprende falha.

---

🔐 6. Segurança – RACF não é GitHub (e nunca será)

Git trabalha com:

• Usuário

• Token

• Repo

Mainframe trabalha com:

• Identidade

• Perfil

• Dataset

• Auditoria pesada

Alinhar RACF/ACF2/TSS com Git não é trivial, principalmente em ambientes regulados.

💡 Dica Bellacosa:
Auditoria e rastreabilidade devem nascer no pipeline, não serem “adaptadas depois”.

🥚 Easter egg corporativo:
Compliance sempre descobre o problema depois que o sistema já está em produção.

---

🧠 Pensamento Final – Git Funciona com COBOL?

Sim.
Mas não por mágica.

Git funciona com COBOL quando existe:

• Disciplina

• Ferramentas corretas

• Pipeline consciente

• Respeito à cultura mainframe

Sem isso, você só moderniza o problema — não a solução.

🔥 Provocação final do El Jefe:
Quantos ambientes “modernizados” hoje só trocaram o PDS por Git, mas mantiveram os mesmos riscos de 1989?

 

Bellacosa Mainframe apresenta o REXX

☕🔥 REXX Hardcore no z/OS — automação, controle e poder operacional  

Se você já salvou produção com um exec improvisado, já rasgou SDSF via ADDRESS, ou já ouviu

“isso dá pra automatizar em REXX, né?”
então puxa a cadeira.
Aqui é REXX técnico, sem verniz didático e com cheiro de madrugada.

---

🕰️ Histórico & Origem — por que o REXX virou arma de produção

O REXX (Restructured Extended Executor) nasce na IBM nos anos 80 com uma missão clara:

• Substituir JCL “verboso”

• Padronizar scripts

• Criar uma linguagem legível, extensível e integrada ao sistema

Ele não foi feito para ser “bonito”.
Foi feito para controlar ambiente.

☕ Verdade histórica:

REXX não é linguagem de apoio — é linguagem de governo operacional.

---

🧠 Conceito de Ambiente de Processamento

REXX não executa no vácuo.
Ele sempre roda dentro de um ambiente:

• TSO/E

• Batch

• SDSF

• ISPF

• CICS (indiretamente)

• Programas externos

Cada ambiente define:

• Comandos válidos

• RC interpretado

• Recursos disponíveis

• Permissões RACF

🔥 Easter egg:
O mesmo EXEC pode funcionar em TSO e falhar em Batch sem mudar uma linha.

---

🧩 Fundamentos da Linguagem — simples na superfície, profunda no núcleo

Sintaxe & Elementos

• Tipagem dinâmica

• Strings como cidadão de primeira classe

• Sem declaração obrigatória

• Case-insensitive (armadilha clássica)

📌 Exemplo:

parse upper arg parm1 parm2
if parm1 = '' then exit 8

☕ Comentário ácido:
REXX perdoa erro demais — e isso cobra seu preço em produção.

---

🏗️ Estrutura de um Programa REXX

Todo EXEC sério tem:

1. Identificação

2. Validação de ambiente

3. Tratamento de RC

4. Controle de erro

5. Cleanup

📌 Exemplo base:

/* REXX */
signal on error
signal on failure
signal on syntax

address tso
"ALLOC FI(IN) DA('DATASET') SHR"
...
exit 0

🔥 Veterano sabe:
EXEC sem SIGNAL ON é convite ao caos.

---

🧮 Estrutura de Dados — tabelas na memória

REXX não tem array clássico.
Tem stem variables.

tab.1 = 'A'
tab.2 = 'B'
tab.0 = 2

☕ Curiosidade:
Stem mal controlado vira memory leak conceitual.

---

📂 Acesso a Arquivos & Geração de Relatórios

• ALLOC / FREE

• EXECIO DISKR / DISKW

• Geração de relatórios spoolados

• Integração com SORT

📌 Exemplo:

"EXECIO * DISKR IN (STEM L.)"
do i=1 to L.0
  say L.i
end

🔥 Easter egg:
EXECIO ignora erro… até você checar o RC.

---

🔃 Classificação & Manipulação de Dados

• SORT via IDCAMS

• SORT via ICETOOL

• Manipulação em memória (lento)

• Pipeline híbrido REXX + SORT

☕ Regra de produção:

Se precisa ordenar muito, não é REXX — é SORT.

---

🗂️ Acesso a Diretório de PDS

REXX + ISPF services:

• LMDINIT

• LMMLIST

• LMCLOSE

📌 Exemplo:

address ispexec
"LMINIT DATAID(DID) DATASET('MY.PDS')"
"LMMLIST DATAID(DID) OPTION(LIST)"

🔥 Veterano:
ISPF services dão poder… e risco.

---

🧑‍💻 Interatividade com Usuário (TSO)

• Pseudo-conversational

• Command-level

• SAY / PULL

• Mensagens controladas

☕ Fofoquice:
Interface feia, mas resolve crise em minutos.

---

🧪 Modos de Execução REXX

🟢 REXX Linha de Comando (Online)

• Interativo

• Debug rápido

• Dependente de perfil

🟡 REXX Batch Script (Interpretado)

• Executa via IKJEFT01

• Dependente de ambiente

• Mais flexível

🔴 REXX Batch Compilado

• Performance superior

• RC previsível

• Menos tolerante a erro

• Exige processo de build

🔥 Script vs Compilado:

Interpretado é agilidade.
Compilado é confiabilidade.

---

🔐 REXX + RACF

REXX não ignora segurança:

• Herda permissões do usuário

• Pode consultar via RACROUTE (indireto)

• Controla acesso via classes

☕ Verdade dura:
EXEC com SPECIAL é bomba com pavio curto.

---

🗄️ REXX + DB2

• DSNREXX

• SQL dinâmico

• RC + SQLCODE + SQLSTATE

• Automação de consultas e relatórios

📌 Exemplo:

ADDRESS DSNREXX
"EXECSQL SELECT COUNT(*) INTO :CNT FROM SYSIBM.SYSTABLES"

🔥 Easter egg:
SQLCODE ignorado vira incidente invisível.

---

🔀 ADDRESS — o coração da integração

ADDRESS muda o destino dos comandos:

• TSO

• ISPEXEC

• SDSF

• CONSOLE

• DSNREXX

☕🔥 Regra sagrada:

Quem domina ADDRESS domina o sistema.

---

🔢 Return Code (RC) — o idioma da produção

• RC ≠ erro sempre

• RC precisa ser interpretado

• Padronização é vital

if rc > 4 then exit rc

🔥 Veterano:
RC não tratado é mentira operacional.

---

📘 Programa do Curso — visão hardcore

Estrutura Geral / Labs

• Ambiente restritivo

• Casos reais

• Incidentes simulados

Instruções REXX

• IF, DO, SELECT

• SIGNAL, EXIT

• PARSE

Funções Internas / Sub-rotinas

• Modularização

• Reuso

• Controle de escopo

Comandos REXX

• SAY, PULL, TRACE

• QUEUE / PULL

• EXECIO

Funções TSO / CONSOLE

• WTO

• MODIFY

• DUMP

• SDSF

INTERPRET (🔥 perigoso)

• Execução dinâmica

• Flexibilidade extrema

• Risco máximo

☕ Comentário ácido:

INTERPRET é poder absoluto — use sóbrio.

---

🥚 Easter Eggs & Fofoquices REXX

• Todo ambiente tem um EXEC “salvador”

• Sempre existe um REXX sem comentários rodando há anos

• O melhor REXX é o que não precisa ser explicado

• Debug começa com TRACE ?R

---

☕🔥 Conclusão — Manifesto El Jefe REXX

REXX não é:

• Script simples

• Linguagem de iniciante

• Alternativa ao COBOL

REXX é:

• Cola do z/OS

• Automação estratégica

• Ferramenta de sobrevivência em produção

☕🔥 Quem domina REXX,
não programa apenas —
orquestra o mainframe.