Bellacosa Mainframe descreve as atividade de um operador mainframe em CICS

💥 Operador de CICS Não Aperta Botão: Ele Evita Caos em Milhões de Transações (E Quase Ninguém Percebe)

Se você acha que o operador de mainframe só “fica olhando tela verde”… cuidado.
No universo do CICS, ele é o guardião silencioso que impede filas travadas, regiões colapsando e clientes reclamando no app do banco.

Hoje vamos abrir essa caixa-preta no estilo Bellacosa Mainframe: direto, provocativo e com aquele tempero de quem já viu CICS pegando fogo às 3 da manhã. ☕

---

🧠 O Papel REAL do Operador de CICS

O operador não programa… mas mantém o sistema RESPIRANDO.

Ele atua em três frentes:

🔹 1. Monitoramento contínuo

• Região CICS ativa?
• Transações fluindo?
• CPU explodindo?
• Tasks presas?

🔹 2. Intervenção rápida

• Mata transação travada
• Habilita/desabilita recursos
• Responde incidentes antes do usuário perceber

🔹 3. Comunicação

• Aciona suporte (sysprog, dev, DBA)
• Documenta incidentes
• Traduz problema técnico em impacto real

👉 Em resumo:
O operador não resolve tudo — mas sabe exatamente quando algo está errado.

---

⚙️ Comandos CICS que TODO operador deve dominar

Dentro do CICS (via terminal ou console), esses são os clássicos:

🔥 CEMT — O CANIVETE SUÍÇO

O mais importante. Se o operador souber só um… que seja esse.

Exemplos:

CEMT I TASK

→ Lista tasks ativas

CEMT I TRANS

→ Mostra transações

CEMT SET TRANS(xxxx) DISABLED

→ Desabilita transação problemática

CEMT SET FILE(nome) CLOSED

→ Fecha arquivo (VSAM/DB2 ligado)

CEMT SET TASK(xxxx) PURGE

→ Mata task travada

💡 Dica Bellacosa:
Se você usou PURGE mais de 3x no dia… tem problema estrutural.

---

🔥 CEDA — Definições (nível mais avançado)

CEDA I TRANS(xxxx)

→ Ver definição da transação

👉 Operador usa menos, mas precisa reconhecer.

---

🔥 CECS / CECI — Testes

Mais usados por dev, mas operador esperto sabe identificar uso indevido.

---

🖥️ Onde o SDSF entra no jogo?

Aqui começa o poder real.

O SDSF é o radar do operador.

---

🔍 Telas que ele MAIS usa:

🔹 ST (Status)

• Ver address space do CICS
• CPU, memória, status

👉 Identificar se o CICS está:

• Loopando
• Travado
• Consumindo CPU absurda

---

🔹 DA (Display Active)

• Tasks no z/OS
• Ver impacto fora do CICS

---

🔹 LOG

• Mensagens do sistema

👉 Aqui mora o OURO.

Exemplo:

• AICA abends
• DFHxxxx mensagens
• Falhas de recurso

💡 Easter egg:
Se aparecer DFHAC2001 com frequência…
👉 Pode apostar: alguém esqueceu commit ou está em loop.

---

🔹 SP (Spool)

• Logs de jobs
• Dumps

---

🚨 Quando o CICS está “aberto” — o que se espera do operador?

CICS aberto = ambiente em produção, usuários ativos.

O operador precisa:

✅ 1. Garantir disponibilidade

• Região UP
• Transações habilitadas

✅ 2. Detectar anomalias

• Lentidão
• Travamentos
• Picos

✅ 3. Agir ANTES do caos

• Kill de tasks
• Disable de transação problemática

✅ 4. Seguir procedimento

• Nada de “inventar moda”
• Produção NÃO é laboratório

---

🧨 Situações clássicas (vida real)

💣 Caso 1 — Loop infinito

Sintoma:

• CPU 100%
• Usuários travados

Ação:

CEMT I TASK
CEMT SET TASK(xxxx) PURGE

---

💣 Caso 2 — Arquivo travado

Sintoma:

• Transações não respondem

Ação:

CEMT SET FILE(nome) CLOSED
CEMT SET FILE(nome) OPEN

---

💣 Caso 3 — Transação problemática

CEMT SET TRANS(xxxx) DISABLED

---

🕵️ Curiosidade raiz (história real de datacenter)

Um operador notou que o CICS estava “normal”…
Mas usuários reclamavam.

Ele fez algo simples:

CEMT I TASK

Percebeu centenas de tasks iguais.

👉 Era um bug em produção gerando loop silencioso.

Ele matou UMA task… e o problema sumiu.

💡 Moral:
Nem sempre o problema é barulhento.

---

🎯 Dicas nível Bellacosa (ouro puro)

🔥 Nunca saia dando PURGE sem entender
🔥 Sempre olhe o SDSF antes de agir
🔥 Aprenda a reconhecer padrões (isso separa operador de operador)
🔥 Documente TUDO
🔥 Conheça mensagens DFH (isso é superpoder)

---

🧩 Easter Egg técnico

Se você digitar:

CEMT I SYSTEM

Vai ver:

• Status geral
• Recursos
• Saúde do CICS

👉 Pouca gente usa… mas deveria.

---

🚀 Conclusão

O operador de CICS não é figurante.
Ele é o primeiro firewall humano entre o sistema e o caos.

Enquanto desenvolvedores escrevem código…
👉 Ele garante que o sistema NÃO PARE.

E quando tudo está funcionando perfeitamente…

👉 Foi porque ele fez o trabalho certo — e ninguém percebeu.

 

Bellacosa Mainframe explorando address spaces & tasks

☕ O Segredo Mais Importante do z/OS Que Quase Ninguém Explica: Address Spaces & Tasks (O “Multiverso” do Mainframe)

🧙‍♂️ Padawan, aproxime-se.
Se você entender profundamente Address Spaces e Tasks, você atravessa a porta de entrada do mundo Sysprog. Sem isso, z/OS parece magia. Com isso, vira engenharia.

Pegue seu café. Vamos abrir o capô do mainframe. ☕

---

🌌 Capítulo 1 — O z/OS Não Executa Programas. Executa Universos.

Em um PC comum você pensa:

“Vou rodar um programa.”

No z/OS, o raciocínio é outro:

⭐ “Vou criar um ambiente isolado onde programas poderão existir.”

Esse ambiente é o:

🏢 Address Space

Ele contém:

• Memória virtual privada
• Identidade de segurança
• Recursos
• Estruturas de controle
• Tasks (unidades de execução)
• Programas rodando

👉 Tudo roda dentro de um address space.

Exceto funções internas do kernel — e isso é assunto para um Jedi Master.

---

🔎 Como ver o “multiverso” ao vivo

Abra o SDSF:

SDSF → DA

Cada linha é um universo independente:

• MASTER
• JES2
• TCPIP
• IBMUSER
• CICS
• Jobs batch
• Processos UNIX

Um sistema real pode ter centenas.

🥚 Easter Egg #1:
O MASTER é sempre ASID 1.
Se ele cair… você tem problemas maiores do que um dump.

---

🔒 Capítulo 2 — O Isolamento Que Salvou o Mainframe

Cada address space tem memória privada.

Um programa em A NÃO pode acessar a memória de B.

Isso evita:

• Corrupção entre aplicações
• Vazamento de dados
• Quedas sistêmicas
• Caos total

🧠 Mas há um truque genial…

Cada espaço acha que possui toda a memória.

Sim. Toda.

---

🧭 Virtual Memory — A Ilusão Controlada

Dois programas podem usar o mesmo endereço:

x'2795'

E acessar memórias físicas diferentes.

Isso ocorre graças à:

⭐ DAT — Dynamic Address Translation

Virtual → Page Tables → Real Memory

👉 Daí o nome Address Space.

Cada universo tem seus próprios endereços.

---

🤝 Compartilhamento? Só com permissão

Quando necessário:

• Common Storage (CSA/ECSA)
• Cross-memory services
• Program Call
• Serviços autorizados

Exemplo clássico:

CICS falando com DB2.

---

🧵 Capítulo 3 — Dentro do Universo: Tasks

Um address space sozinho não executa nada.

Quem executa são:

🧵 Tasks (TCBs ou SRBs)

⭐ Task = menor unidade despachável

O dispatcher agenda tasks nos CPUs.

---

⚡ Paralelismo real

Se houver 10 CPUs → até 10 tasks executando simultaneamente.

Mas…

🥚 Easter Egg #2:
A maioria das tasks está esperando algo — não executando.

Porque sistemas corporativos são I/O-bound.

---

⏳ Estados típicos

🟢 Running

No CPU agora

🟡 Ready

Quer CPU, mas aguarda

🔴 Waiting

Esperando evento:

• I/O
• Lock
• Resposta externa
• Timer
• Memória

---

📦 Uma task pode executar vários programas

Mas:

❗ Apenas um por vez

Exemplo COBOL clássico:

MAIN
  CALL VALIDATE
  CALL CALCULATE
  CALL UPDATE
  CALL PRINT
STOP RUN

Tudo na mesma task.

---

⚙️ Quer paralelismo? Crie novas tasks.

ATTACH → nova TCB

Exemplo batch paralelo:

Task A → Arquivo1
Task B → Arquivo2
Task C → Arquivo3

---

🐧 Padawans vindos do UNIX

Boa analogia:

z/OS	UNIX
Address Space	Process
Task (TCB)	Thread

E sim:

⭐ Cada thread USS é uma task.

---

👑 Capítulo 4 — A Task Raiz: RCT

Quando um address space nasce:

1. Cria-se a Region Control Task (RCT)
2. Outras tasks são iniciadas
3. Programas executam nelas

Hierarquia:

Address Space
   └── RCT
         ├── Task A
         └── Task B

🥚 Easter Egg #3:
Se a RCT terminar… o address space inteiro termina.

Sem órfãos. Sem bagunça.

---

⚡ Capítulo 5 — O Primo Ninja: SRB

Existem dois tipos de tasks:

🧵 TCB — normal

Aplicações, batch, TSO, etc.

⚡ SRB — especial

Serviços do sistema.

Diferenças fundamentais:

TCB	SRB
Pode esperar	Geralmente não
Longo prazo	Curto
Local	Pode ser cross-memory
Aplicações	Sistema

SRBs são criados via:

SCHEDULE

Não automaticamente.

---

🧠 Capítulo 6 — Memória Compartilhada entre Tasks

Dentro do mesmo address space:

👉 Tasks compartilham memória.

Isso permite cooperação rápida.

Mas também risco.

Programas autorizados podem proteger áreas — aplicações comuns raramente fazem isso.

---

🏛️ Capítulo 7 — Como Address Spaces Nascem

Criados quando surge um workload independente:

• IPL do sistema
• START de serviço
• Logon TSO
• Job batch selecionado pelo JES
• Processo UNIX iniciado

❌ NÃO quando:

• Um programa começa
• Um comando TSO é digitado
• Uma subrotina é chamada

🥚 Easter Egg #4:
Criar address space é caro. z/OS evita fazer isso sem necessidade.

---

🧾 Capítulo 8 — ASCB, ASID e Jobname

Cada address space é registrado por um:

⭐ ASCB — Address Space Control Block

Contém:

• ASID (ID interno)
• Jobname (nome visível)
• Ponteiros para TCBs
• Estado
• Dados de gerenciamento

Operador vê:

👉 JOBNAME

Sistema usa:

👉 ASID

---

👨‍💼 Capítulo 9 — Administração na Vida Real

Operadores controlam address spaces, não tasks.

Comandos típicos:

S TCPIP
P CICS
C JOB123
F JES2,QUIESCE

Tasks só entram em cena quando algo dá errado.

---

💥 Capítulo 10 — Por Que Isso Faz o Mainframe Ser o Mainframe

Essa arquitetura permite:

✔ Escalabilidade massiva
✔ Isolamento forte
✔ Alta disponibilidade
✔ Throughput absurdo
✔ Recuperação controlada
✔ Multi-tenant seguro

---

🏆 O Insight Jedi

🏢 Address Space = Ambiente

🧵 Task = Execução

💻 Program = Código executado

Ou, no idioma Bellacosa:

“O z/OS não roda programas.
Ele mantém universos onde programas vivem.”

---

☕ Missão do Padawan

Se você entendeu este artigo, já ultrapassou 80% dos iniciantes em mainframe.

O próximo passo é dominar:

• Dispatching e WLM
• Storage Manager
• JES internals
• Subsystems architecture
• Dump analysis

---

💬 Último conselho

🧙‍♂️ “Quem entende Address Spaces e Tasks não apenas usa o z/OS… começa a pensar como ele.”

 

 

Bellacosa Mainframe SysRexx o REXX como framework

🔥💣 SYSREXX: O “KUBERNETES INVISÍVEL” DO z/OS QUE JÁ EXISTIA ANTES DA NUVEM 💣🔥

Quando o REXX deixou de ser linguagem… e virou infraestrutura operacional do Mainframe ☕🚀

“Enquanto o mundo moderno descobria automação… o z/OS já executava automações sistêmicas em paralelo dentro do próprio núcleo operacional.”

Existe um momento na história do Mainframe em que o REXX sofre uma mutação absurda.

Ele deixa de ser:

• simples linguagem de scripts
• ferramenta TSO
• automação de rotina

…e se transforma em algo muito maior:

☕ Uma camada operacional inteligente do próprio z/OS.

Esse momento atende pelo nome de:

🔥 SYSREXX (System REXX)

E pouca gente percebe a profundidade arquitetural disso.

Porque o SYSREXX não é “apenas REXX fora do TSO”.

💣 O SYSREXX é praticamente:

• um runtime operacional
• um engine de automação
• um orquestrador interno
• um mini middleware sistêmico
• um framework de operações embutido no z/OS

Décadas antes:

• Kubernetes
• PowerShell
• DevOps
• ChatOps
• AIOps
• Infrastructure as Code

…o Mainframe já possuía:

automação operacional orientada a eventos usando REXX.

---

☕ O DIA EM QUE O REXX VIROU “PARTE DO SISTEMA”

Durante anos o REXX viveu:

• no TSO
• em CLISTs
• em automações ISPF
• em SDSF
• em jobs batch

Mas a IBM percebeu algo:

O mundo começava a exigir:

• integração web
• automação rápida
• observabilidade
• APIs operacionais
• gerenciamento simplificado

Então nasceu o SYSREXX.

A própria IBM define o objetivo assim:

“Required an infrastructure to support web based initiatives interacting with z/OS components.”

Traduzindo para Bellacosa Mainframe:

🔥 “Precisávamos transformar o z/OS em algo programável em tempo real.”

---

🚀 O SYSREXX É UM SUBSYSTEM DE VERDADE

Esse é o primeiro choque.

Muita gente imagina:

“Ah… deve ser só um EXEC diferente.”

Negativo.

O SYSREXX nasce como:

AXR

Uma Started Task real.

Ela:

• cria workers
• controla filas
• gerencia requests
• dispara ambientes TSO
• administra automações
• integra console e APIs

💣 Isso é arquitetura enterprise raiz.

---

☕ O QUE O SYSREXX FAZ?

Ele permite executar EXECs:

• fora do TSO
• fora do Batch
• via console
• via APIs
• via programas assembler
• via automação sistêmica

Ou seja:

🔥 O REXX vira uma API operacional do z/OS.

---

🧠 O DETALHE QUE QUASE NINGUÉM PERCEBE

O SYSREXX introduziu no Mainframe conceitos que hoje chamamos de:

• workers
• queues
• asynchronous execution
• runtime isolation
• service execution
• orchestration

Observe a arquitetura lógica IBM:

• Listener
• Queue Control
• Worker Tasks
• Async Processing
• Console Interface
• AXREXX API

💣 Isso parece arquitetura cloud moderna.

Só que no z/OS.

---

🔥 TSO=NO — O MODO “TURBO”

Aqui mora uma engenharia genial.

O modo:

TSO=NO

executa EXECs:

• em ambiente compartilhado
• alta velocidade
• baixo overhead
• até 64 workers paralelos

Resultado:

performance absurda.

---

☕ O PREÇO DA VELOCIDADE

Mas existe um detalhe importante.

A IBM alerta:

“Recommend no Data Set Allocation here.”

Porque:

• o ambiente é compartilhado
• workers são reutilizados
• problemas podem contaminar outros EXECs

🔥 Isso é extremamente importante.

---

🚨 O “VAZAMENTO FANTASMA”

Imagine um EXEC mal escrito:

/* REXX */

"ALLOC FI(TEST) DA('SYS1.PARMLIB') SHR"
EXIT

Sem FREE.

O dataset:

• continua alocado
• influencia EXECs futuros
• causa bugs aleatórios

💣 Bem-vindo ao terror operacional invisível do SYSREXX.

---

🚀 TSO=YES — O MODO “ISOLADO”

Aqui o EXEC ganha:

• Address Space própria
• ambiente TSO dinâmico
• acesso a datasets
• comandos POSIX
• SYSCALL
• maior segurança

Mas…

☕ não é um TSO “completo”.

E aqui muitos profissionais caem.

---

🔥 A ARMADILHA DO TSO DINÂMICO

O SYSREXX usa:

IKJTSOEV

para criar:

Dynamic TSO Environment

Mas o TMP tradicional NÃO existe completamente.

Resultado:

• alguns comandos falham
• alguns control blocks inexistem
• alguns LOADs explodem

E então aparece o famoso:

ABEND306

💣 O Mainframe lembrando:

“Você entrou numa área avançada.”

---

☕ AXRCMD — O SUPERPODER ABSURDO

Aqui o SYSREXX vira praticamente um operador automatizado.

Exemplo:

/* REXX */

Rc = AXRCMD("D IPLINFO",OUT.,5)

DO I = 1 TO OUT.0
   SAY OUT.I
END

🔥 O EXEC:

• envia comando MVS
• captura resposta
• processa output
• toma decisões

Isso muda completamente o jogo.

---

🚀 O MAINFRAME COMEÇA A “SE OBSERVAR”

Com AXRCMD você pode:

• monitorar jobs
• verificar DASD
• analisar JES2
• inspecionar XCF
• observar STORAGE
• controlar devices
• automatizar recovery

Tudo em REXX.

---

☕ EXEMPLO “OPS AI RAIZ”

Imagine isso:

/* REXX */

Signal On Failure

Rc = AXRCMD("D A,L",OUT.,5)

If Rc <> 0 Then Do
   Call AXRWTO "ERRO NO DISPLAY"
   Exit 8
End

Do I = 1 To OUT.0

   If Pos("CICS",OUT.I) > 0 Then Do

      If Pos("NOT ACTIVE",OUT.I) > 0 Then Do

         Call AXRWTO "CICS FORA DO AR"

         Rc2 = AXRCMD("S CICSPROD",MSG.,10)

         Call AXRWTO "RESTART AUTOMATICO EXECUTADO"

      End
   End
End

Exit 0

Failure:
Call AXRWTO "ABEND NO MONITOR"
Exit 16

💣 Isso é praticamente:

• observabilidade
• detecção automática
• autorecovery
• AIOps

Só usando SYSREXX.

---

🔥 AXRMLWTO — O “PAINEL OPERACIONAL”

Essa função é maravilhosa.

Ela permite gerar:

• WTOs multiline
• outputs organizados
• blocos formatados
• relatórios operacionais

Exemplo:

Connect='IPLCHK'

Call AXRMLWTO '=== STATUS IPL ===','Connect','L'

Do I = 1 To OUT.0
   Call AXRMLWTO OUT.I,'Connect','D'
End

Call AXRMLWTO '=== FIM ===','Connect','DE'

O console vira praticamente:

uma dashboard textual enterprise.

---

☕ O SYSREXX É O “POWERSHELL DO MAINFRAME”

Mas com diferenças importantes:

• mais integrado
• mais seguro
• mais próximo do kernel
• mais operacional
• absurdamente eficiente

---

🔥 O EASTER EGG MAIS INSANO

Pouca gente percebe…

Mas o SYSREXX já fazia:

ChatOps operacional

Muito antes do Slack existir.

Observe:

@1STATUS
@1CICSCHK
@1JES2INFO
@1DASDMON

💣 Isso é praticamente:

• slash commands
• bots operacionais
• automação conversacional

No console do z/OS.

Décadas atrás.

---

☕ O MAINFRAME JÁ FAZIA “SERVERLESS”

Pense nisso.

Você:

• dispara EXEC
• runtime nasce
• executa lógica
• devolve resultado
• encerra worker

🔥 Isso lembra o quê?

Lambda.
Functions.
Serverless.

Só que:

no Mainframe.

---

🚀 O SYSREXX COMO “DEVOPS INVISÍVEL”

Hoje falam:

• DevOps
• GitOps
• AIOps
• Platform Engineering

Mas o z/OS já possuía:

• automação sistêmica
• workers paralelos
• filas
• eventos
• execução assíncrona
• automação declarativa

O SYSREXX era isso.

---

☕ O DETALHE MAIS BONITO DO SYSREXX

A IBM poderia ter criado:

• linguagem nova
• engine nova
• framework novo

Mas ela escolheu:

REXX.

Porque:

• simples
• legível
• humana
• rápida
• poderosa

---

🔥 CONCLUSÃO

O SYSREXX é uma das tecnologias mais subestimadas do z/OS.

Ele transformou o REXX em:

• infraestrutura
• automação enterprise
• motor operacional
• plataforma sistêmica
• interface programável do Mainframe

E talvez o mais impressionante:

☕ O mundo moderno reinventou muitos conceitos que o Mainframe já dominava há décadas.

Enquanto muita gente ainda estava aprendendo a automatizar servidores distribuídos…

🔥 o z/OS já executava automações inteligentes dentro do próprio coração do sistema operacional. 🔥

 

Bellacosa Mainframe apresenta Executing Host Commands em REXX

☕🚀 REXX: O “CANIVETE SUÍÇO” DO z/OS — Quando um Script Começa a Conversar com TODO o Mainframe 🚀☕

“O verdadeiro poder do REXX não está na sintaxe.
Está na capacidade de conversar com absolutamente tudo.”
— Estilo Bellacosa Mainframe

---

🧠 O Dia em Que Você Descobre Que o REXX NÃO É Só “Scripting”

Todo mundo começa igual.

O programador iniciante aprende:

SAY 'HELLO WORLD'

Depois:

DO I = 1 TO 10
   SAY I
END

Aí pensa:

“Ok… é uma linguagem simples.”

Mas então chega o momento da revelação.

O momento em que você escreve:

ADDRESS SDSF

…e percebe que aquele “scriptzinho inocente” acabou de ganhar acesso ao coração operacional do z/OS.

Nesse instante você entende:

😳 O REXX NÃO RODA NO MAINFRAME.

😳 O REXX CONVERSA COM O MAINFRAME.

E isso muda tudo.

---

🏛️ O Conceito Que Faz o REXX Virar Um Monstro de Automação

A IBM criou algo brilhante:

Host Command Environment

Traduzindo para Bellacosaês:

“Pra qual universo você quer mandar comandos agora?”

O REXX não executa tudo sozinho.

Ele atua como um maestro.

Cada ambiente executa um tipo de magia.

Host commands

Ambiente	Superpoder
TSO	comandos operacionais
ISPEXEC	controlar ISPF
ISREDIT	criar macros editoriais
SDSF	dominar spool/jobs
CONSOLE	virar operador MVS
DSNREXX	conversar com DB2
SYSCALL	controlar UNIX
SOCKET	falar TCP/IP

---

☕ ADDRESS — A Palavra Mais Poderosa do REXX

A instrução:

ADDRESS

parece inocente.

Mas ela literalmente troca o “mundo” onde o REXX está falando.

---

🎯 Exemplo Simples

ADDRESS TSO
"LISTALC STATUS"

Aqui o REXX diz:

“TSO, execute isso pra mim.”

---

😎 O Grande Truque

Você pode mudar de ambiente a qualquer momento.

Tipo assim:

ADDRESS TSO
"ALLOC FI(INPUT) DA('CLIENTE.ARQ') SHR"

ADDRESS ISPEXEC
"DISPLAY PANEL(MENU001)"

ADDRESS SDSF
"ISFEXEC ST"

Percebe a insanidade disso?

😳 Um único programa:

• aloca dataset
• controla ISPF
• acessa SDSF
• automatiza operações

Tudo junto.

---

🔥 O Dia em Que o Programador Descobre o ISREDIT

Existe um momento na carreira do mainframeiro em que ele percebe:

O editor ISPF é programável.

A mente explode.

---

🧙 Macros ISPF: O “VIM MODE GOD” DO Mainframe

Exemplo:

/* REXX */
ADDRESS ISREDIT
"MACRO"

"CHANGE 'TESTE' 'PROD' ALL"

Você acabou de criar um comando novo dentro do editor ISPF.

Agora imagine:

• refatoração automática
• padronização COBOL
• alteração massiva JCL
• análise estática
• geração automática de código

Tudo feito em REXX.

Décadas antes de IDEs modernas.

---

🧨 Easter Egg Mainframe #1

Muita gente usa ISPF há 20 anos…

…sem perceber que o editor dele é basicamente um mini sistema operacional programável.

---

🚨 CONSOLE — O Modo “Deus do Sysprog”

Agora vem a parte perigosa.

ADDRESS CONSOLE
"D A,L"

Isso NÃO é brincadeira.

Você está emitindo comandos reais de operador MVS.

---

😅 Sim… Dá Medo.

Porque daqui a pouco você faz:

"F JES2,DEBUG"

ou pior:

"P TCPIP"

e o datacenter inteiro olha pra você.

---

🧨 Easter Egg Mainframe #2

Todo sysprog experiente conhece alguém que:

• derrubou subsystem
• pausou JES2
• congelou spool
• matou CICS

…“só testando um REXX rapidinho”.

---

🧠 SDSF + REXX = Automação Jedi

A maioria das pessoas usa SDSF manualmente.

O especialista usa:

rc=isfcalls('ON')

ADDRESS SDSF "ISFEXEC ST"

E então começa a automatizar o impossível.

---

🎯 Exemplo: Listar Jobs Ativos

rc=isfcalls('ON')

ADDRESS SDSF "ISFEXEC ST"

DO I = 1 TO JNAME.0
   SAY JNAME.I STATUS.I
END

rc=isfcalls('OFF')

---

😳 O Que Isso Significa?

Você pode criar:

• monitor batch
• restart automático
• watchdog operacional
• análise de spool
• alertas inteligentes
• observabilidade do z/OS

ANTES da palavra “observabilidade” virar moda.

---

☕ O Mainframe Já Fazia DevOps Antes do DevOps

Enquanto o mundo moderno:

• descobria scripts
• aprendia automação
• inventava pipelines

o z/OS já fazia isso com:

REXX + SDSF + JCL + ISPF

nos anos 80 e 90.

---

🗄️ DSNREXX — Quando o REXX Aprende SQL

A IBM foi além.

Ela pensou:

“E se o REXX falasse DB2 também?”

Nasceu o DSNREXX.

---

🎯 Exemplo Conceitual

ADDRESS DSNREXX

"EXECSQL
 SELECT NAME
 INTO :WS-NOME
 FROM CLIENTES
 WHERE ID = 100"

---

😳 Resultado?

O REXX virou:

• DBA assistant
• monitor DB2
• gerador relatório
• ferramenta troubleshooting

---

🧨 Easter Egg Mainframe #3

Muito DBA antigo automatizou ambientes inteiros sem escrever uma linha de COBOL.

Só REXX + DSNREXX.

---

🌐 SOCKETS — O Momento Cyberpunk do z/OS

Agora segura essa.

O REXX consegue abrir socket TCP/IP.

Sim.

Socket.

TCP/IP real.

---

🎯 Exemplo

CALL SOCKET 'Initialize'

parse value SOCKET('Socket') with rc sock .

CALL SOCKET 'Connect',sock,'AF_INET 80','192.168.0.1'

---

😳 Você Entendeu o Que Isso Significa?

O mesmo REXX que:

• mexe em spool
• controla JCL
• automatiza ISPF

também consegue:

• falar rede
• integrar sistemas
• abrir conexão TCP

---

🧠 O z/OS Sempre Foi Mais Moderno do Que Diziam

Essa é a verdade que ninguém conta.

Muita tecnologia “moderna” já existia no mainframe:

• automação
• scripting
• integração
• APIs
• virtualização
• segurança centralizada
• observabilidade
• alta disponibilidade

Décadas antes do hype.

---

🐧 UNIX Dentro do Mainframe? Sim.

Com:

CALL SYSCALLS 'ON'

o REXX ganha acesso ao z/OS UNIX.

---

🎯 Exemplo

CALL SYSCALLS 'ON'

ADDRESS SYSCALL
"readdir / tmp."

DO I = 1 TO TMP.0
   SAY TMP.I
END

---

😎 Resultado?

Agora o mesmo REXX:

• acessa datasets
• conversa com JES
• executa SQL

também navega no filesystem UNIX.

---

🧨 Easter Egg Mainframe #4

Muitos ambientes bancários modernos:

• APIs
• microserviços
• integrações REST
• automações batch

têm algum REXX escondido funcionando nos bastidores.

Às vezes há 25 anos sem cair.

---

⚔️ LINK e ATTACH — Chamando Programas Como um Ninja

O REXX também consegue executar load modules diretamente.

---

🎯 Exemplo

ADDRESS LINKMVS "SORT parm"

---

😳 Isso é Profundo.

Porque o REXX deixa de ser:

• linguagem de script

e vira:

• controlador de execução MVS.

---

☕ O Verdadeiro Segredo do Mainframe

O segredo nunca foi o COBOL.

Nem o JCL.

Nem o CICS.

O segredo sempre foi:

Integração.

E o REXX virou a “cola universal” do ecossistema z/OS.

---

🧠 O REXX Como Sistema Nervoso do Mainframe

Observe esse fluxo:

REXX
 ↓
SDSF consulta JOB
 ↓
captura spool
 ↓
analisa ABEND
 ↓
consulta DB2
 ↓
abre ticket
 ↓
reinicia JOB
 ↓
notifica operador

Tudo em um único exec.

---

🚀 Comparação Moderna

Hoje	Mainframe já fazia
Python automation	REXX
DevOps scripting	SDSF REXX
VSCode macros	ISREDIT
Cloud orchestration	JES automation
REST integration	SOCKET/SYSCALL
Database scripting	DSNREXX

---

🧨 Easter Egg Final

Muitos dos ambientes mais críticos do planeta:

• bancos
• seguradoras
• bolsas
• governos

ainda sobrevivem graças a pequenos REXX feitos por algum mago do mainframe em 1998…

…que ninguém tem coragem de apagar.

Ambientes suportados

---

☕ Conclusão Bellacosa Mainframe

O REXX parece simples porque foi criado para humanos.

Mas por trás da simplicidade existe algo colossal:

Ele é a interface universal do z/OS.

Quando você domina:

• ADDRESS
• ISPEXEC
• ISREDIT
• SDSF
• CONSOLE
• DSNREXX
• SYSCALL

você para de “usar” o mainframe…

REXX e suas bibliotecas

…e começa a ORQUESTRAR o mainframe.

---

🚀 Frase Final

“O COBOL processa negócios.
O JCL organiza execução.
O CICS controla transações.

Mas o REXX…

o REXX conversa com o universo inteiro do z/OS.” ☕