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