Bellacosa Mainframe e uma revisão do rexx

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🦖 MIKE COWLISHAW E O DINOSSAURO QUE APRENDEU A AUTOMATIZAR O MAINFRAME: REXX, A LINGUAGEM NASCIDA ÀS 3 DA MADRUGADA QUE CONQUISTOU O z/OS!

De uma ideia concebida em 1979 aos ambientes IBM Z de 2026: sob a ótica de Mike Cowlishaw, vamos descobrir como uma linguagem criada para simplificar a programação se transformou numa poderosa ferramenta de automação. Uma jornada por COBOL, JCL, TSO, ISPF, EXECIO, Data Stack, LINKMVS, SYSREXX, DevOps e os perigos silenciosos de um script que funciona perfeitamente — até chegar à produção.

Bellacosa Mainframe — Arqueologia da Computação, IBM Z, COBOL, REXX, Automação e os Mistérios da Tecnologia

🎬 Prólogo — 03h17: o homem que acordou com uma linguagem de programação na cabeça

Inglaterra, 20 de março de 1979.

Enquanto boa parte do mundo dormia, um engenheiro da IBM acordava com uma ideia que mudaria discretamente a história da programação.

Seu nome era Mike Cowlishaw.

Naquela época, os computadores pessoais ainda estavam conquistando espaço, os mainframes dominavam o processamento corporativo e escrever programas exigia familiaridade com linguagens, comandos e convenções nem sempre intuitivas.

Cowlishaw enxergava um problema que muitos especialistas pareciam aceitar como inevitável: por que as linguagens de programação precisavam impor tantas dificuldades aos seus usuários?

Por que transformar tarefas simples em exercícios de memorização de símbolos e regras?

Segundo o relato histórico preservado pela Rexx Language Association, naquele dia ele despertou por volta das três da madrugada com uma visão clara do que pretendia desenvolver. Ao final do dia, já havia compartilhado uma especificação inicial para receber comentários.

Era o nascimento do REXX.

Décadas depois, em novembro de 2026, imaginemos o mesmo Mike Cowlishaw entrando num moderno centro de processamento IBM Z.

Diante dele, monitores exibem jobs executando no JES2, aplicações COBOL processam informações bancárias, operadores investigam mensagens pelo SDSF e desenvolvedores utilizam ferramentas modernas de automação.

Em uma tela, aparece um programa:

/* REXX */
say 'Bom dia, Mainframe!'

Cowlishaw sorri.

A linguagem criada para tornar a programação mais acessível continua viva.

Mas ele encontra algo ainda mais interessante.

Aquele pequeno programa agora pode fazer parte de sistemas que consultam datasets, executam comandos, monitoram processos e integram aplicações escritas em diferentes linguagens.

O pequeno script cresceu.

E o dinossauro aprendeu a automatizar seu próprio castelo.

Esta cena é uma dramatização literária. A história do nascimento do REXX e os princípios de Cowlishaw são documentados; o encontro imaginário em 2026 não aconteceu.

🧠 Capítulo I — Quem é Mike Cowlishaw e por que devemos estudar sua filosofia?

Mike Cowlishaw é um cientista da computação britânico conhecido por seu trabalho no desenvolvimento do REXX e por contribuições posteriores ao processamento decimal em computadores.

No final dos anos 1970, ele trabalhava no laboratório da IBM em Hursley, na Inglaterra.

Sua preocupação não era simplesmente criar mais uma linguagem.

Ele buscava uma ferramenta que pudesse ser compreendida por profissionais de informática e também por usuários que não fossem programadores especializados.

O nome REXX representa REstructured eXtended eXecutor.

O projeto recebeu contribuições e comentários de usuários durante seu desenvolvimento. Essa característica é fundamental para compreender sua filosofia.

Em vez de criar uma linguagem pensando exclusivamente na facilidade de implementação do interpretador, Cowlishaw procurou observar as necessidades de quem realmente escreveria os programas.

Seu artigo The Design of the REXX Language, publicado no IBM Systems Journal em 1984, explica justamente essa preocupação com simplicidade, legibilidade e utilização prática.

O REXX foi apresentado publicamente em 1981, durante o SHARE 56, em Houston. Em 1983, passou a integrar oficialmente o ambiente VM/SP da IBM.

E aqui encontramos nossa primeira grande curiosidade.

🥚 Easter egg nº 1 — O REXX quase teve outro nome!

O projeto foi originalmente chamado REX, de Reformed EXecutor.

Segundo o histórico publicado pela IBM, o segundo X foi acrescentado para evitar problemas relacionados a marcas registradas.

Uma pequena alteração no nome ajudou a construir uma identidade que sobreviveria durante décadas.

A primeira lição de Cowlishaw é extraordinariamente atual:

Uma tecnologia não precisa ser difícil de compreender para ser poderosa.

E isso vale tanto para um estudante de COBOL em 2026 quanto para um programador que utilizava VM/CMS em 1983.

🖥️ Capítulo II — O castelo IBM Z: onde COBOL, JCL e REXX trabalham juntos

Imagine um enorme castelo tecnológico.

Dentro dele, milhares de programas COBOL processam pagamentos, atualizam saldos, consultam contratos, calculam juros e movimentam informações empresariais.

O COBOL representa os trabalhadores especializados, responsáveis pelas regras de negócio.

O JCL organiza o processamento batch, indicando programas, datasets, parâmetros e recursos necessários.

O JES2 recebe e gerencia os trabalhos submetidos.

O Db2 e o VSAM armazenam informações fundamentais.

O RACF controla identidades e permissões.

E o REXX?

O REXX atua como um assistente extremamente versátil.

Ele não precisa substituir os especialistas.

Sua função pode ser coordenar atividades, verificar condições, consultar resultados e eliminar procedimentos manuais repetitivos.

Considere uma operação noturna com cinco etapas:

Verificar se o dataset de entrada está disponível.
Validar os parâmetros do processamento.
Executar ou preparar as operações autorizadas.
Consultar resultados e códigos de retorno.
Registrar o estado final para análise operacional.

Um operador poderia realizar parte dessas atividades manualmente.

Mas, quando as mesmas verificações precisam acontecer diariamente, surge uma oportunidade de automação.

É aqui que REXX se destaca.

Na apresentação APPDEV2, encontramos uma frase que resume essa relação:

"REXX não substitui COBOL. Ele substitui o humano apertando tecla."

A frase é uma metáfora, mas transmite uma distinção importante.

COBOL continua sendo especialmente adequado para a implementação de regras empresariais. REXX oferece uma maneira prática de automatizar diversas operações ao redor dessas aplicações.

Um não precisa eliminar o outro.

Em muitos ambientes, os dois trabalham melhor juntos.

📜 Capítulo III — Aprendendo REXX: o primeiro programa de um futuro Mestre Jedi

Vamos começar do zero.

Quem conhece COBOL perceberá imediatamente uma diferença.

No COBOL, normalmente declaramos variáveis e estruturas em seções específicas. No REXX, podemos trabalhar com variáveis de forma muito mais direta.

Nosso primeiro programa será:

/* REXX */
say 'Bem-vindo ao Bellacosa Mainframe!'

A primeira linha é um comentário.

A instrução SAY exibe uma mensagem.

Pronto!

Agora vamos introduzir uma variável:

/* REXX */
nome = 'Mike Cowlishaw'
ano = 1979

say nome
say 'Ano de nascimento do REXX:' ano

Resultado esperado:

Mike Cowlishaw
Ano de nascimento do REXX: 1979

Observe que não precisamos definir antecipadamente um campo PIC X(30) ou PIC 9(4).

Entretanto, essa flexibilidade traz responsabilidades.

Em COBOL, a definição de dados ajuda a organizar as informações. No REXX, o programador precisa estabelecer regras claras para os valores que suas variáveis podem receber.

Nosso primeiro processamento repetitivo

/* REXX */
do i = 1 to 5
  say 'Executando rotina numero' i
end

Resultado:

Executando rotina numero 1
Executando rotina numero 2
Executando rotina numero 3
Executando rotina numero 4
Executando rotina numero 5

O DO executa o bloco repetidamente.

O END encerra o bloco.

Para um iniciante, essa estrutura é fácil de compreender.

Mas vamos avançar.

/* REXX */
parse arg cliente

if cliente = '' then do
  say 'ERRO: cliente nao informado'
  exit 8
end

say 'Processando cliente:' cliente
exit 0

O comando PARSE ARG permite receber argumentos.

O código de retorno 8 indica, por convenção definida nesse exemplo, que houve uma falha de validação.

O código zero indica conclusão normal.

Dica de produção: não utilize códigos de retorno apenas como números decorativos. Documente seu significado, pois eles poderão influenciar decisões em JCL e ferramentas de automação.

🧩 Capítulo IV — Compound Variables: os arrays que não são exatamente arrays

Aqui começa uma das partes mais interessantes do REXX.

Imagine que precisamos armazenar informações de três clientes.

Podemos escrever:

/* REXX */
cliente.1 = 'ANA'
cliente.2 = 'BRUNO'
cliente.3 = 'CARLA'
cliente.0 = 3

do i = 1 to cliente.0
  say cliente.i
end

O resultado será:

ANA
BRUNO
CARLA

Para quem conhece arrays, parece um vetor convencional.

Mas existe uma diferença conceitual.

Em REXX, cliente.1, cliente.2 e cliente.3 são variáveis compostas.

A parte anterior ao ponto é chamada stem. A parte posterior pode ser construída dinamicamente.

Isso permite criar estruturas flexíveis, inclusive utilizando chaves textuais.

/* REXX */
cidade.ITATIBA = 'SAO PAULO'
cidade.LISBOA = 'PORTUGAL'
cidade.YORK = 'INGLATERRA'

say cidade.YORK

Entretanto, o funcionamento das caudas das variáveis compostas depende das regras de avaliação do REXX, que devem ser compreendidas antes de utilizar essas estruturas em aplicações complexas.

O perigoso valor padrão

Observe:

/* REXX */
saldo. = 0
saldo.123 = 500

say saldo.123
say saldo.999

Resultado:

500
0

O valor de saldo.999 não significa que uma conta com esse identificador foi encontrada.

Ele aparece porque estabelecemos zero como valor padrão para o stem.

Agora imagine uma aplicação bancária.

Uma conta com saldo zero existe.

Uma conta inexistente não existe.

Um saldo ainda não consultado é desconhecido.

São três situações diferentes.

Se nosso programa tratar todas como equivalentes, teremos um problema de lógica empresarial.

🥚 Easter egg nº 2 — O fantasma mora na variável que você não inicializou

A apresentação APPDEV2 alerta para um problema clássico: variáveis compostas podem conservar informações de operações anteriores.

Imagine carregar uma lista com cem clientes e, depois, carregar outra com apenas dez.

Se não houver limpeza adequada, elementos da primeira operação poderão permanecer na estrutura.

Para evitar resultados residuais, podemos usar:

drop cliente.

Também devemos validar se determinada variável foi inicializada.

/* REXX */
drop saldo.
saldo.123 = 500

if symbol('SALDO.999') = 'VAR' then
  say 'Variavel definida'
else
  say 'Variavel nao definida'

SYMBOL() é útil, mas não substitui a validação empresarial da existência do registro.

Lição de Cowlishaw aplicada à produção: simplicidade sintática não elimina a necessidade de compreender profundamente o comportamento dos dados.

📚 Capítulo V — Data Stack: a pilha que pode salvar ou sabotar sua automação

Imagine uma pequena agência dos correios.

As mensagens chegam, são armazenadas e posteriormente retiradas para processamento.

Essa é uma analogia útil para entender a Data Stack do REXX.

Duas instruções merecem atenção:

QUEUE adiciona informações ao final da fila.

PUSH coloca informações no início.

Considere:

/* REXX */
queue 'CLIENTE A'
queue 'CLIENTE B'
push 'URGENTE'

parse pull mensagem1
parse pull mensagem2
parse pull mensagem3

say mensagem1
say mensagem2
say mensagem3

A saída será:

URGENTE
CLIENTE A
CLIENTE B

Aqui encontramos duas estruturas clássicas de computação.

FIFO — First In, First Out: o primeiro elemento inserido é o primeiro a sair.

LIFO — Last In, First Out: o último elemento inserido é o primeiro a sair.

A Data Stack permite organizar fluxos temporários de informações, mas ela não é equivalente a um stem.

A pilha pertence ao contexto de execução e pode ser compartilhada por diferentes operações.

Um stem, por outro lado, é uma estrutura de variáveis submetida às regras de escopo do programa.

O perigo da stack suja

Imagine um exec que coloca vinte mensagens na stack, mas consome apenas quinze.

Sob determinadas condições, as cinco mensagens restantes podem interferir em operações posteriores.

A apresentação APPDEV2 resume o risco:

"Stack é compartilhada. Stem é sua."

É uma boa regra didática, embora existam mecanismos de compartilhamento e exposição de variáveis que exigem atenção.

Como isolar uma pilha temporária?

/* REXX */
call newstack

queue 'TAREFA001'
queue 'TAREFA002'

do while queued() > 0
  parse pull tarefa
  say 'Executando:' tarefa
end

call delstack

NEWSTACK estabelece uma nova pilha.

DELSTACK elimina essa pilha e retorna ao contexto anterior.

Dica: em uma aplicação real, estruture também o tratamento de erros para assegurar que os recursos temporários sejam liberados mesmo diante de falhas.

💾 Capítulo VI — EXECIO: quando o REXX abre as portas dos datasets

Agora entramos no território clássico do mainframe.

O mundo IBM Z trabalha intensamente com datasets.

Para um iniciante em COBOL, acessar um arquivo frequentemente significa aprender SELECT, FD, OPEN, READ, WRITE e CLOSE.

O REXX possui uma alternativa poderosa no ambiente TSO/E: EXECIO.

Esse comando permite operações de leitura e escrita de registros em datasets compatíveis.

Passo 1 — Preparar o arquivo

Imagine um dataset sequencial denominado:

APPDEV2.DADOS.CLIENTES

Com os seguintes registros:

00001;ANA;1000
00002;BRUNO;2500
00003;CARLA;750

Passo 2 — Alocar o dataset

No ambiente TSO/E, podemos usar:

address tso

"ALLOC FI(ENTRADA) DA('APPDEV2.DADOS.CLIENTES') SHR"

ALLOC associa um dataset a um nome lógico, neste caso ENTRADA.

Passo 3 — Ler os registros

drop rec.

"EXECIO * DISKR ENTRADA (STEM rec. FINIS"
leituraRC = rc

DISKR realiza leitura.

STEM rec. armazena os registros em variáveis compostas.

FINIS encerra a utilização do arquivo nessa operação.

RC informa o resultado do comando.

Quando a leitura é concluída normalmente, rec.0 contém a quantidade de registros carregados.

Passo 4 — Percorrer os dados

do i = 1 to rec.0
  parse var rec.i codigo ';' nome ';' saldo
  say codigo nome saldo
end

O comando PARSE VAR permite separar os campos utilizando o ponto e vírgula como delimitador.

Passo 5 — Liberar o dataset

"FREE FI(ENTRADA)"

Naturalmente, precisamos verificar o código de retorno da alocação antes de executar a leitura e também validar o resultado da operação.

O que significa FINIS?

Uma dúvida frequente é imaginar que basta terminar a execução do programa para que o dataset tenha sido corretamente tratado.

A documentação IBM explica que alguns recursos podem ser liberados automaticamente ao final de determinados ambientes de execução.

Entretanto, recomenda explicitamente fechar os datasets quando não forem mais necessários.

Essa é uma excelente prática de programação defensiva.

🥚 Easter egg nº 3 — O número de registros não controla automaticamente o DISKW *

Ao escrever registros com EXECIO, podemos usar uma quantidade explícita:

"EXECIO" rec.0 "DISKW SAIDA (STEM rec. FINIS"

Ou o asterisco:

"EXECIO * DISKW SAIDA (STEM rec. FINIS"

Mas existe um detalhe: na escrita a partir de um stem, o asterisco não significa simplesmente utilizar o valor de rec.0.

O processamento pode continuar até encontrar uma variável não inicializada ou um registro nulo, conforme as regras documentadas.

Por isso, quando conhecemos a quantidade exata de registros, frequentemente é mais seguro indicá-la explicitamente.

Outra limitação importante: não devemos presumir que EXECIO oferece acesso direto a todas as organizações de datasets.

Para VSAM, especialmente arquivos indexados, devem ser consideradas interfaces apropriadas.

🚂 Capítulo VII — IKJEFT01 contra IRXJCL: dois caminhos para executar REXX em batch

Uma rotina que funciona perfeitamente no terminal pode falhar quando executada em batch.

Por quê?

Porque o ambiente importa.

A apresentação APPDEV2 destaca duas alternativas de execução.

IKJEFT01 executa comandos TSO/E em background.

IRXJCL permite executar REXX em um ambiente que não oferece automaticamente os mesmos serviços de uma sessão TSO/E.

Essa diferença afeta os comandos disponíveis e as dependências do programa.

Exemplo de JCL com IKJEFT01

//REXXJOB  JOB (ACCT),'REXX TESTE',
//             CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=IKJEFT01,DYNAMNBR=30
//SYSEXEC  DD DSN=APPDEV2.REXX.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
  %TESTE
/*

O job executa o membro TESTE localizado na biblioteca informada em SYSEXEC.

Os parâmetros do JOB e os nomes de datasets precisam ser adaptados ao ambiente de cada organização.

E por que não utilizar sempre IRXJCL?

Porque a escolha depende das necessidades do programa.

Um exec que utiliza comandos TSO/E pode exigir um ambiente diferente de outro que executa apenas lógica REXX e serviços disponíveis em MVS.

Não existe um mecanismo universalmente superior.

Existe o mecanismo adequado à aplicação.

O inimigo invisível: PULL em batch

Veja este código:

say 'Digite o numero do cliente:'
pull cliente

Em um terminal interativo, alguém pode fornecer a informação.

Em batch, porém, a origem dos dados depende da stack e do fluxo de entrada disponibilizado.

O resultado pode ser completamente diferente daquilo que o programador imaginou.

É preferível receber informações explicitamente:

parse arg cliente

if cliente = '' then do
  say 'ERRO: parametro ausente'
  exit 8
end

A automação precisa saber exatamente o que fazer sem depender de uma pessoa diante da tela.

🔗 Capítulo VIII — LINK, LINKMVS e LINKPGM: quando REXX conversa com COBOL

Aqui encontramos uma das partes mais sofisticadas do material.

Imagine que uma empresa possua um programa COBOL escrito em 1995.

Esse programa calcula uma regra financeira utilizada há décadas.

Você precisa automatizar sua utilização, mas não deseja reescrever a lógica.

Seria possível chamar diretamente esse programa a partir de REXX?

Dependendo da interface, sim.

O z/OS oferece ambientes como LINK, LINKMVS e LINKPGM.

Entretanto, eles não representam simplesmente três nomes diferentes para a mesma funcionalidade.

A principal dificuldade está na convenção de passagem de parâmetros.

Alguns módulos esperam receber uma cadeia de caracteres.

Outros esperam uma lista de endereços.

Existem ainda diferenças relacionadas aos comprimentos dos parâmetros e à possibilidade de modificar informações fornecidas pelo chamador.

Um exemplo conceitual de integração:

/* REXX */
cliente = '00000123'

address linkpgm 'CONSULTA cliente'

say 'Retorno:' rc

Nesse exemplo, CONSULTA seria um módulo hipotético preparado para receber parâmetros pela interface correspondente.

Não basta possuir um programa COBOL compilado para garantir que qualquer uma dessas chamadas funcione.

É preciso verificar sua convenção de entrada, o layout de parâmetros, as exigências de runtime e as características do módulo.

Uma recomendação para iniciantes

Antes de integrar um programa COBOL a REXX:

Identifique o módulo que será chamado.
Consulte sua documentação de interface.
Verifique os parâmetros esperados.
Confirme a compatibilidade com o ambiente de chamada.
Teste entradas válidas e inválidas.
Examine os códigos de retorno.
Documente o comportamento em caso de falha.

Esse processo é menos espetacular do que simplesmente escrever um comando LINK.

Mas é justamente ele que permite construir integrações confiáveis.

⚙️ Capítulo IX — REXX compilado: colocar um motor maior não conserta um carro quebrado

Uma dúvida inevitável surge quando os programas começam a crescer.

Se REXX é interpretado, por que não compilar tudo?

A IBM oferece tecnologia para compilar programas REXX.

A compilação pode melhorar o desempenho em determinadas circunstâncias, principalmente reduzindo parte do trabalho necessário para interpretar expressões e instruções.

Mas ela não transforma automaticamente um programa ruim em um programa eficiente.

Imagine um exec que demora cem segundos.

Durante vinte segundos, ele executa lógica REXX.

Nos oitenta segundos restantes, aguarda operações de entrada e saída.

Se a compilação reduzir o tempo da lógica pela metade, o processamento passará de cem para noventa segundos.

A redução total será de apenas dez por cento.

Nada desprezível.

Mas muito diferente da expectativa de executar tudo duas vezes mais rapidamente.

Por isso, antes de compilar, precisamos medir.

A curiosidade das opções SLINE, ALT, CONDENSE e XREF

A apresentação menciona essas opções em sua seção de REXX compilado.

É importante compreender que, no contexto do IBM Compiler for REXX, elas dizem respeito à compilação, representação e informações associadas ao programa.

Não devem ser confundidas com comandos genéricos de processamento de arquivos.

O significado de cada opção precisa ser consultado na documentação da versão do compilador utilizada.

Essa distinção é valiosa porque evita ensinar uma nomenclatura equivocada ao iniciante.

Regra de ouro: primeiro melhore o algoritmo, depois investigue as possibilidades de compilação.

🚨 Capítulo X — ADDRESS CONSOLE: o momento em que o script encontra a operação do z/OS

Até agora, nosso REXX leu variáveis, percorreu estruturas e acessou datasets.

Mas o z/OS possui outro universo.

O universo dos comandos operacionais.

É nele que encontramos mensagens de sistema, informações de recursos, respostas de subsistemas e procedimentos executados por operadores.

Determinados ambientes REXX permitem interagir com comandos de console, desde que as autorizações e as condições técnicas sejam atendidas.

Isso abre possibilidades para ferramentas de monitoramento.

Imagine um exec que verifica se um recurso operacional está respondendo normalmente.

Ele emite uma consulta autorizada, aguarda a resposta, interpreta o resultado e registra a situação.

Mas surge um problema.

E se vários comandos estiverem sendo executados simultaneamente?

Como identificar a resposta correspondente a cada solicitação?

Uma das ferramentas envolvidas nessa situação é o CART — Command and Response Token.

O token ajuda a correlacionar comandos e mensagens de resposta.

Funções como GETMSG podem ser utilizadas para recuperação das mensagens em contextos apropriados.

É uma ideia semelhante à utilização de identificadores de correlação em sistemas distribuídos modernos.

🥚 Easter egg nº 4 — O console também precisa de identificadores

Muita gente associa identificadores de correlação exclusivamente a microsserviços, APIs e computação em nuvem.

Entretanto, a necessidade de associar solicitações às suas respostas também aparece na operação tradicional de mainframes.

A tecnologia muda.

O problema fundamental permanece.

E essa é uma das razões pelas quais estudar IBM Z ajuda a compreender arquiteturas modernas.

🛡️ Capítulo XI — SYSREXX: o poder exige responsabilidade

Chegamos ao nível mais avançado de nossa jornada.

System REXX permite executar programas em ambientes específicos do z/OS, fora do modelo tradicional de uma sessão interativa TSO/E.

Entre suas possibilidades estão a emissão de comandos de sistema e a recuperação de informações para processamento automatizado.

A IBM documenta dois ambientes importantes:

TSO=YES

TSO=NO

A distinção afeta os serviços disponíveis, a integração com TSO/E e as características de execução.

No ambiente System REXX encontramos funções como:

AXRCMD: utilizada para trabalhar com comandos de sistema e respectivas respostas.

AXRWTO: permite emitir mensagens por meio dos serviços correspondentes.

AXRWAIT: oferece mecanismos de espera controlada.

Essas ferramentas permitem construir assistentes operacionais, diagnósticos e rotinas de apoio ao operador.

Mas surge uma pergunta essencial.

Se um exec possui capacidade de interagir com funções sensíveis do sistema, quem controla o que ele pode fazer?

A resposta envolve segurança, autorizações, bibliotecas confiáveis e governança.

O RACF e os demais mecanismos de controle do z/OS desempenham papéis fundamentais.

Não basta que um programa execute corretamente.

Ele precisa executar somente aquilo que está autorizado a fazer.

Uma automação com privilégios excessivos pode se transformar em um risco operacional significativo.

O princípio do menor privilégio

Imagine um programa cuja única função seja consultar determinado recurso.

Ele não deveria receber permissões amplas para alterar configurações críticas, encerrar subsistemas ou modificar informações desnecessárias à consulta.

A simplicidade desejada por Cowlishaw precisa caminhar ao lado da responsabilidade exigida pela operação moderna.

Facilitar a programação não significa facilitar operações perigosas.

🧪 Capítulo XII — Mão na massa: nosso primeiro monitor de indicadores em REXX

Vamos reunir alguns conhecimentos em um projeto prático.

Nosso objetivo será criar um programa simples que leia informações de um dataset e identifique valores superiores a um limite estabelecido.

Imagine o arquivo:

APPDEV2.DADOS.HEALTH

Conteúdo:

CPU;65
MEMORIA;72
FILAS;91
IO;40

Esses valores são indicadores didáticos, não medições reais do sistema.

Passo 1 — Definir o limite

limite = 85

Passo 2 — Ler os registros

/* REXX */
address tso
drop dados.

"ALLOC FI(HCIN) DA('APPDEV2.DADOS.HEALTH') SHR"
if rc <> 0 then exit 12

"EXECIO * DISKR HCIN (STEM dados. FINIS"
leituraRC = rc

"FREE FI(HCIN)"

if leituraRC <> 0 then exit 12

Passo 3 — Verificar cada indicador

alertas = 0

do i = 1 to dados.0
  parse var dados.i indicador ';' valor

  if \datatype(valor,'W') then do
    say 'ERRO: valor invalido'
    exit 12
  end

  if valor < 0 | valor > 100 then do
    say 'ERRO: fora da escala'
    exit 12
  end

  if valor > limite then do
    say 'ALERTA:' indicador valor
    alertas = alertas + 1
  end
  else
    say 'OK:' indicador valor
end

if alertas > 0 then exit 4
exit 0

Passo 4 — Interpretar o resultado

Para os dados apresentados, esperamos:

OK: CPU 65
OK: MEMORIA 72
ALERTA: FILAS 91
OK: IO 40

O retorno será 4, indicando que pelo menos um indicador ultrapassou o limite.

Observe o que acabamos de construir.

Nosso programa possui:

Leitura de dataset.
Variáveis compostas.
Laço de repetição.
Validação de dados.
Lógica condicional.
Código de retorno.
Identificação de anomalias.

É um pequeno laboratório, mas contém os fundamentos de uma automação real.

Naturalmente, antes de utilizar essa ideia em produção, precisaríamos acrescentar tratamento completo de falhas, validação do formato dos registros, definição de limites por indicador, registros de auditoria e testes com entradas problemáticas.

Uma evolução interessante

Imagine substituir o dataset simulado por informações coletadas através de serviços autorizados do ambiente.

Poderíamos construir um monitor que identificasse condições operacionais e produzisse alertas.

A próxima etapa seria encaminhar os resultados para uma ferramenta de observabilidade.

E, posteriormente, integrar os registros a sistemas analíticos.

A partir daí, nossa automação começaria a participar de um ecossistema de operação inteligente.

🤖 Capítulo XIII — REXX, DevOps e inteligência artificial: a surpreendente modernidade de uma linguagem de 1979

É curioso imaginar que uma linguagem concebida antes da popularização dos computadores pessoais possa continuar relevante num mundo dominado por APIs, Git, automação e inteligência artificial.

Mas a explicação está na natureza do problema que REXX resolve.

Empresas continuam precisando coordenar processos.

Continuam precisando validar entradas.

Continuam precisando interpretar resultados.

Continuam precisando automatizar operações.

A inteligência artificial pode ajudar a explicar código, gerar testes, documentar rotinas e identificar padrões suspeitos.

Mas o modelo de IA não substitui automaticamente a necessidade de interfaces corretas, permissões apropriadas e validação empresarial.

Imagine um assistente inteligente encarregado de analisar uma rotina REXX.

Ele pode sugerir melhorias, identificar um RC ignorado ou observar que determinado dataset não foi corretamente fechado.

Entretanto, antes de aceitar qualquer modificação, será necessário confirmar que a alteração preserva o comportamento esperado.

Essa é uma das razões pelas quais conhecer profundamente REXX, COBOL e JCL continua importante.

A inteligência artificial pode acelerar o trabalho.

Mas a compreensão técnica permite verificar se o trabalho foi realizado corretamente.

Uma arquitetura possível

Um fluxo moderno pode utilizar:

Git para versionamento.

Uma pipeline CI/CD para testes e validações.

Zowe para integração com serviços do IBM Z.

JCL para processamentos batch.

COBOL para regras empresariais.

REXX para operações especializadas de automação.

RACF para controles de autorização.

E ferramentas de observabilidade para acompanhamento dos resultados.

Cada componente possui uma responsabilidade.

O segredo está na integração disciplinada.

🦖 Capítulo XIV — Dez erros que transformam um script REXX num pesadelo de produção

Depois de explorar os fundamentos, precisamos discutir as armadilhas.

1. Ignorar o RC. Um comando pode falhar sem que o restante do programa seja interrompido automaticamente.

2. Não inicializar estruturas. Variáveis residuais podem produzir resultados inesperados.

3. Confundir stem com array convencional. As regras de variáveis compostas precisam ser compreendidas.

4. Deixar a Data Stack contaminada. Informações pendentes podem interferir em operações posteriores.

5. Esquecer o FINIS. Recursos de I/O precisam ser gerenciados corretamente.

6. Presumir que EXECIO funciona com qualquer dataset. A organização e a interface de acesso importam.

7. Utilizar entrada interativa sem planejamento em batch. A ausência de um terminal altera as condições de execução.

8. Escolher LINK, LINKMVS ou LINKPGM sem compreender os parâmetros. A incompatibilidade de interfaces pode provocar falhas graves.

9. Compilar um programa sem medir seu desempenho. O ganho pode ser pequeno ou irrelevante para o problema real.

10. Automatizar comandos privilegiados sem controles adequados. Quanto maior a autoridade de um programa, maior a responsabilidade sobre sua segurança.

O que todos esses problemas possuem em comum?

Eles revelam a diferença entre conhecer a sintaxe de uma linguagem e compreender o ambiente em que ela funciona.

🏆 Capítulo XV — A trilha do Mestre Jedi do REXX

Se eu estivesse organizando uma formação de REXX para um iniciante em COBOL, dividiria o aprendizado em cinco estágios.

Primeiro estágio — Padawan da linguagem

Aprender SAY, PARSE, IF, DO, SELECT, PROCEDURE, funções e variáveis compostas.

O objetivo é escrever pequenos programas que possam ser compreendidos, testados e modificados.

Segundo estágio — Guardião dos datasets

Aprender EXECIO, Data Stack, tratamento de registros, validação de entradas e fechamento de recursos.

O objetivo é construir utilitários que trabalhem com dados sem comprometer sua integridade.

Terceiro estágio — Cavaleiro do batch

Aprender JCL, IKJEFT01, IRXJCL, parâmetros, DDs, RC e análise de resultados no SDSF.

O objetivo é executar programas de maneira reproduzível, sem dependência de interação humana.

Quarto estágio — Especialista em integração

Estudar LINK, LINKMVS, LINKPGM, interfaces COBOL, módulos carregáveis e convenções de parâmetros.

O objetivo é conectar componentes sem precisar reescrever sistemas que já executam regras empresariais confiáveis.

Quinto estágio — Mestre Jedi da produção

Estudar System REXX, console, autorizações, logs, auditoria, recuperação, controle de mudanças e automação operacional.

O objetivo é compreender não apenas como executar uma operação, mas também seus riscos e consequências.

Essa progressão acompanha a filosofia central da apresentação APPDEV2: sair do pequeno script e avançar, com responsabilidade, para a automação do z/OS.

🔍 Capítulo XVI — O que Mike Cowlishaw nos ensinaria sobre programação em 2026?

Não podemos atribuir a Cowlishaw opiniões que ele não expressou sobre todos os desafios atuais.

Mas podemos refletir sobre os princípios documentados de sua linguagem.

REXX foi desenvolvido com atenção especial à experiência dos usuários.

Sua sintaxe procurava ser legível e coerente.

A linguagem deveria ajudar a resolver problemas reais, em vez de transformar cada atividade numa batalha contra a notação.

Esses princípios continuam extraordinariamente relevantes.

Em 2026, um iniciante pode pedir a uma inteligência artificial que escreva cinquenta linhas de REXX.

Mas isso não garante que ele compreenda o programa.

A IA pode gerar código que parece correto, mas utiliza um serviço indisponível no ambiente de execução.

Pode interpretar incorretamente um código de retorno.

Pode produzir uma chamada incompatível com a interface de um módulo COBOL.

Pode esquecer de liberar recursos.

Por isso, existe uma diferença fundamental entre gerar código e compreender sistemas.

O futuro não pertence apenas a quem consegue produzir programas mais rapidamente. Pertence também a quem consegue demonstrar que esses programas funcionam corretamente, com segurança e dentro das regras do negócio.

Essa reflexão está perfeitamente alinhada à filosofia de uma linguagem que nasceu procurando facilitar a compreensão humana.

🎬 Epílogo — 03h17: o criador do REXX encontrou o futuro dentro de um mainframe

Voltemos ao nosso centro de processamento imaginário.

São 03h17.

Um job termina com RC zero.

Uma rotina verifica a existência de um dataset.

Outra analisa registros de controle.

Um monitor identifica uma condição incomum e registra um alerta.

Uma aplicação COBOL continua executando suas regras empresariais.

E um pequeno programa REXX reúne informações que antes exigiam diversas operações manuais.

Mike Cowlishaw observa a cena.

A linguagem que nasceu de uma ideia simples agora participa de uma infraestrutura tecnológica que movimenta instituições financeiras, empresas e serviços essenciais.

Mas talvez o aspecto mais interessante não seja sua longevidade.

É o fato de que sua filosofia original continua fazendo sentido.

Uma linguagem pode ser acessível sem ser limitada.

Pode ser simples sem ser superficial.

Pode ter décadas de existência e continuar resolvendo problemas modernos.

Em um mundo fascinado pelas novidades, o REXX lembra que inovação nem sempre significa abandonar o passado.

Às vezes, significa descobrir novas possibilidades numa ferramenta que já estava diante de nossos olhos.

E quando o último monitor apaga sua mensagem de processamento, uma frase permanece na tela:

"O verdadeiro Mestre Jedi do Mainframe não é aquele que conhece todos os comandos. É aquele que entende as consequências de cada comando que executa."

O pequeno dinossauro sorri.

O REXX continua vivo.

E sua próxima aventura acaba de começar.

📚 Referências e material de aprofundamento

Mike F. Cowlishaw — The Design of the REXX Language, IBM Systems Journal, 1984.
IBM — z/OS TSO/E REXX User's Guide.
IBM — z/OS TSO/E REXX Reference.
IBM — System REXX e documentação de serviços de console.
IBM — Compiler for REXX on IBM Z.
Rexx Language Association — História da linguagem REXX.
APPDEV2 — REXX Mainframe: Do Script ao Motor de Automação z/OS, novembro de 2026.
Bellacosa Mainframe — Artigos sobre REXX.
GitHub — REXX MiniCurso: scripts e exercícios práticos.

Bellacosa Mainframe — Porque compreender o passado da computação é uma das melhores maneiras de construir seu futuro.

Translate

quarta-feira, 11 de novembro de 2026