 |
| Bellacosa Mainframe comenta sobre a conferencia que apresentou o REXX ao mundo |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
REXX 1995: O dia em que a IBM quis conquistar o mundo — uma aventura mainframe sob a batuta de Spike Spiegel
Bellacosa Mainframe — Arqueologia da Computação, COBOL, REXX e os fantasmas do código legado
Por Vagner Bellacosa — Bellacosa Mainframe
“See you, Space Cowboy…” — Cowboy Bebop
1. Introdução — Uma nave chamada IBM e um caçador de recompensas chamado REXX
Imagine a cena.
Estamos em maio de 1995. A Internet começa a conquistar universidades, empresas e os primeiros aventureiros digitais. O Windows 95 ainda não chegou oficialmente ao mercado. O Linux é uma promessa jovem, o OS/2 tenta conquistar seu território e os mainframes IBM continuam processando uma quantidade gigantesca de informações empresariais.
Em algum ponto desse universo tecnológico, 130 especialistas se reúnem no Stanford Linear Accelerator Center, na Califórnia, para discutir o futuro de uma linguagem que nasceu discretamente nos corredores da IBM.
Seu nome: REXX.
Agora imagine Spike Spiegel, o despreocupado caçador de recompensas de Cowboy Bebop, entrando numa sala repleta de terminais, fitas magnéticas e programadores experientes.
De mãos nos bolsos, observa as telas, pergunta onde está o café e descobre que há uma recompensa muito mais interessante do que alguns milhares de woolongs.
A recompensa é compreender como uma linguagem criada em 1979 estava se preparando para conquistar o universo da computação.
A bordo desta Bebop imaginária, nossa tripulação será formada por COBOL, REXX, JCL, CICS, Db2 e alguns personagens históricos da IBM.
Spike assume a batuta narrativa. Mike Cowlishaw é o arquiteto da linguagem. Melinda Varian, de Princeton, é nossa correspondente especial no simpósio.
E o programador COBOL iniciante? Esse será o novo tripulante que aprenderá a navegar por sistemas com décadas de história.
O mais interessante é que o simpósio realmente aconteceu.
O Sexto Simpósio Internacional de REXX, realizado de 1 a 3 de maio de 1995, deixou um documento histórico extraordinário: o relatório de Melinda Varian, preservado pela REXX Language Association.
Nele encontramos anúncios controversos, discussões técnicas, ideias inovadoras, previsões ousadas e até comentários sobre decisões equivocadas de projeto.
Vamos embarcar nessa aventura.
2. Episódio 1 — A origem de REXX: uma ideia no meio da noite
Nossa viagem começa em março de 1979.
Mike Cowlishaw, engenheiro da IBM no laboratório de Hursley, na Inglaterra, desperta durante a noite pensando em uma nova linguagem de programação.
Sua preocupação não era simplesmente produzir mais uma ferramenta.
Ele queria desenvolver uma linguagem fácil de aprender, fácil de lembrar e suficientemente expressiva para resolver problemas reais.
Naquela época, usuários de VM/CMS trabalhavam com linguagens como EXEC e EXEC2.
Essas ferramentas eram úteis, mas podiam produzir programas difíceis de ler, especialmente pela quantidade de símbolos e convenções sintáticas.
Cowlishaw desejava algo diferente.
Uma linguagem em que o programador pudesse concentrar a atenção no problema, e não na pontuação.
Foi assim que nasceu o REXX, cujo nome se relaciona à expressão Restructured Extended Executor.
A primeira implementação foi distribuída pela rede interna VNET da IBM em 21 de maio de 1979.
Essa rede conectava profissionais distribuídos por diferentes instalações da empresa.
Cowlishaw enviava propostas, recebia comentários, corrigia comportamentos e desenvolvia novas funcionalidades.
A linguagem cresceu por meio da colaboração.
Curiosidade: uma espécie de desenvolvimento comunitário antes do GitHub
O processo descrito por Cowlishaw lembra bastante práticas modernas de engenharia de software.
Primeiro, ele documentava uma funcionalidade.
Depois, compartilhava a proposta com outros profissionais.
Em seguida, escrevia exemplos para verificar se a ideia realmente fazia sentido.
Somente então avançava na implementação.
Hoje chamaríamos parte desse processo de desenvolvimento orientado por especificações, testes e feedback.
Em 1979, tudo isso acontecia por uma rede corporativa.
Ao final do primeiro ano, Cowlishaw havia dedicado aproximadamente mil horas ao projeto, produzido dez mil linhas de Assembler e escrito cinco mil linhas de documentação.
Observe o detalhe: o interpretador era desenvolvido em Assembler, mas seu objetivo era oferecer ao usuário uma linguagem muito mais acessível.
É como construir uma nave espacial sofisticadíssima para que seu piloto precise lidar apenas com comandos compreensíveis.
Primeiro programa REXX
/* BELLACOSA - PRIMEIRO REXX */
say "Bem-vindo ao universo mainframe"
say "Ano historico: 1995"
say "Missao: aprender REXX"
exit 0A instrução SAY apresenta uma mensagem.
Os comentários ficam entre /* e */.
A instrução EXIT 0 encerra o programa indicando conclusão normal.
Simples, não?
Agora compare com um programa COBOL equivalente.
IDENTIFICATION DIVISION.
PROGRAM-ID. PRIMEIRO.
PROCEDURE DIVISION.
DISPLAY "Bem-vindo ao universo mainframe"
DISPLAY "Ano historico: 1995"
DISPLAY "Missao: aprender COBOL"
GOBACK.O exemplo COBOL utiliza formato fixo tradicional, com as instruções iniciando na área apropriada.
Ambos apresentam mensagens, mas suas estruturas são diferentes.
COBOL é especialmente adequado ao desenvolvimento de aplicações empresariais com regras de negócio e dados estruturados.
REXX é excelente para automação, interpretação de comandos e criação de utilitários.
Primeira lição da Bebop: não existe obrigação de escolher uma linguagem e abandonar todas as outras. O bom programador aprende a utilizar a ferramenta apropriada para cada missão.
3. Episódio 2 — A reunião secreta de 1995
Avancemos dezesseis anos.
Stanford Linear Accelerator Center, Califórnia.
Programadores, pesquisadores e especialistas se reúnem para o Sexto Simpósio Internacional de REXX.
Entre os participantes estão Mike Cowlishaw, Charles Daney, Ian Collier e Anders Christensen.
Cada um representa uma parte da evolução da linguagem.
O encontro tinha aproximadamente 130 participantes, o dobro do ano anterior.
Durante três dias, discutiram o REXX tradicional, sua evolução orientada a objetos, ferramentas de desenvolvimento, UNIX, Web, sistemas distribuídos, OS/2 e CICS.
Mas havia uma notícia que preocupava a comunidade.
A IBM havia anunciado a transferência do desenvolvimento de REXX de Endicott, nos Estados Unidos, para Böblingen, na Alemanha.
Segundo Melinda Varian, nenhum dos desenvolvedores existentes seria transferido junto com o projeto.
A autora demonstrou grande preocupação com essa decisão.
Ela estimou que a transferência poderia provocar um período de 18 a 24 meses de pouco avanço.
Essa estimativa era uma opinião registrada em 1995, não uma medição posterior do que efetivamente aconteceu.
O problema do conhecimento que desaparece
Imagine um sistema COBOL desenvolvido durante vinte anos.
Seu programador original conhece particularidades do código, regras de negócio, registros históricos e situações especiais que talvez nunca tenham sido documentadas.
Agora imagine que a equipe inteira seja substituída.
O código continua funcionando.
Os datasets continuam armazenados.
As transações CICS continuam sendo executadas.
Mas parte do conhecimento desaparece.
É exatamente essa a preocupação expressa por Varian.
Um dos maiores riscos de um sistema legado não é sua idade. É perder o conhecimento necessário para compreendê-lo e mantê-lo.
Essa lição permanece relevante para empresas que dependem de COBOL, PL/I, Assembler, REXX e JCL.
Dica Bellacosa Mainframe
Sempre que encontrar um programa antigo, investigue:
Quem desenvolveu o programa?
Qual problema empresarial ele resolve?
Quais arquivos e tabelas utiliza?
Quais outros programas dependem dele?
Como é executado?
Quais são seus códigos de retorno?
Existem procedimentos documentados para recuperação de erros?
Documentação é uma forma de preservar conhecimento.
E conhecimento preservado reduz o custo de manutenção.
4. Episódio 3 — A IBM queria levar REXX para Linux
Entre os anúncios apresentados no simpósio estava uma novidade surpreendente.
A IBM planejava disponibilizar Object REXX para diferentes plataformas.
O cronograma divulgado incluía:
| Plataforma | Previsão apresentada |
|---|---|
| Linux | Julho de 1995 |
| PowerPC | Setembro de 1995 |
| OS/2 | Outubro de 1995 |
| MVS | Dezembro de 1995 |
| AIX | Durante 1995 |
| Windows | Durante 1995 |
| VM | Março de 1996 |
Atenção: essas eram previsões divulgadas no evento, não comprovação de que todos os lançamentos ocorreram nas datas propostas.
O plano para Linux possuía uma característica especialmente interessante.
A IBM pretendia disponibilizar o código-fonte de sua implementação, permitindo que terceiros construíssem versões para outros sistemas UNIX e comercializassem suas soluções sem pagar royalties à empresa.
Não se tratava necessariamente de software livre nos moldes da GPL.
O anúncio estabelecia condições próprias.
Mesmo assim, para 1995, era uma decisão estratégica importante.
A IBM reconhecia que sua linguagem poderia ter um futuro além dos sistemas operacionais tradicionais da companhia.
Uma linguagem viajando entre planetas
Dentro da nossa analogia com Cowboy Bebop, cada sistema operacional representa um planeta.
VM/CMS é um dos mundos antigos.
MVS é uma enorme estação espacial corporativa.
OS/2 é uma colônia de computadores pessoais.
UNIX e Linux representam novos territórios.
REXX seria um viajante tentando circular entre todos eles.
Naturalmente, cada implementação possui particularidades.
Um script que executa comandos específicos de TSO não funcionará automaticamente em Linux.
A sintaxe básica pode ser semelhante, mas os comandos disponíveis dependem do ambiente.
Essa distinção é fundamental para iniciantes.
Portabilidade da linguagem não significa portabilidade automática de todos os programas.
Um script REXX que utiliza SAY, IF, DO e operações comuns sobre strings pode ser relativamente simples de adaptar.
Já um script que utiliza LISTDS, ALLOC, EXECIO ou serviços específicos de TSO/E exige um ambiente compatível ou alterações.
5. Episódio 4 — COBOL encontra REXX: duas linguagens, uma missão
Vamos imaginar uma empresa financeira.
Todos os dias, um programa COBOL processa movimentações e produz resultados.
O programa executa cálculos, valida registros e grava informações.
Mas alguém precisa preparar o ambiente, executar o processamento, conferir retornos e produzir relatórios.
É aqui que o REXX pode ajudar.
COBOL executa a regra de negócio.
JCL descreve e submete o trabalho em lote.
REXX pode automatizar tarefas operacionais e de desenvolvimento, inclusive a submissão de jobs e a análise de informações.
Vejamos um pequeno laboratório.
Laboratório 1 — Criando um programa COBOL para calcular saldos
Nosso programa inicial não acessará um banco de dados real nem movimentará dinheiro.
Ele trabalhará com valores fixos para facilitar a aprendizagem.
IDENTIFICATION DIVISION.
PROGRAM-ID. SALDOB01.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-SALDO-INICIAL PIC 9(7)V99 VALUE 1500.00.
01 WS-DEPOSITO PIC 9(7)V99 VALUE 250.00.
01 WS-SAQUE PIC 9(7)V99 VALUE 100.00.
01 WS-SALDO-FINAL PIC 9(7)V99 VALUE ZERO.
01 WS-SALDO-EDIT PIC Z(6)9.99.
PROCEDURE DIVISION.
COMPUTE WS-SALDO-FINAL =
WS-SALDO-INICIAL
+ WS-DEPOSITO
- WS-SAQUE
MOVE WS-SALDO-FINAL TO WS-SALDO-EDIT
DISPLAY "BELLACOSA MAINFRAME"
DISPLAY "SALDO FINAL: " WS-SALDO-EDIT
GOBACK.Esse exemplo usa formato fixo tradicional de COBOL, apropriado para ilustrar fontes clássicos.
Vamos entender os elementos.
WORKING-STORAGE SECTION contém variáveis usadas durante a execução.
PIC 9(7)V99 define um campo numérico com sete posições inteiras e duas decimais implícitas.
A letra V não ocupa espaço físico no campo.
COMPUTE executa o cálculo.
MOVE transfere o resultado para um campo editado.
DISPLAY apresenta informações na saída do programa.
GOBACK retorna o controle ao chamador ou ao ambiente de execução.
O saldo esperado é:
1500 + 250 − 100 = 1650.
O programa deverá apresentar o valor formatado como 1650.00, com os espaços iniciais previstos no campo editado.
O que acontece num sistema real?
Em uma aplicação empresarial, esses valores provavelmente seriam obtidos de arquivos sequenciais, VSAM, Db2 ou outra fonte.
Também seria necessário verificar saldos insuficientes, tipos de operação, consistência dos registros e possíveis falhas.
O programa acima demonstra apenas o cálculo.
A vantagem é que o iniciante consegue compreender sua estrutura antes de acrescentar complexidade.
6. Episódio 5 — JCL: o controlador de tráfego da Bebop
No ambiente z/OS, programas batch frequentemente são executados por meio de jobs descritos em JCL.
JCL significa Job Control Language.
Não é uma linguagem de programação de aplicação como COBOL.
Sua função é informar ao sistema quais programas executar, quais recursos utilizar e como tratar entradas e saídas.
Supondo que nosso programa COBOL já esteja compilado e linkeditado numa biblioteca de carga, poderíamos utilizar um job semelhante ao seguinte:
//BELLJOB JOB (ACCT),'BELLACOSA',
// CLASS=A,MSGCLASS=X,
// NOTIFY=&SYSUID
//*
//RUNCOB EXEC PGM=SALDOB01
//STEPLIB DD DSN=USER.COBOL.LOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//Os nomes de dataset e os parâmetros do JOB são ilustrativos e devem ser adaptados às regras da instalação.
A instrução JOB identifica o trabalho.
EXEC PGM=SALDOB01 solicita a execução do programa.
STEPLIB informa uma biblioteca de carga em que o sistema poderá localizar o módulo executável.
SYSOUT e SYSPRINT representam definições de saída frequentemente utilizadas em jobs.
O que acontece quando o job é submetido?
O JES recebe o trabalho, verifica suas condições de execução e o encaminha conforme a configuração do sistema.
O programa é carregado.
O cálculo é executado.
A saída pode ser examinada no spool, utilizando SDSF ou ferramentas equivalentes.
Passo a passo no ambiente TSO/ISPF
Passo 1: acesse o ambiente de desenvolvimento autorizado.
Passo 2: crie um membro de fonte COBOL em uma biblioteca apropriada.
Passo 3: digite o programa SALDOB01.
Passo 4: compile o programa utilizando o procedimento de compilação disponível na instalação.
Passo 5: verifique mensagens de erro, warnings e o código de retorno.
Passo 6: confirme que o módulo executável foi gravado na biblioteca de carga.
Passo 7: adapte o JCL de execução.
Passo 8: submeta o job.
Passo 9: examine o resultado no SDSF.
Passo 10: compare o saldo apresentado com o valor esperado.
Em muitos ambientes educacionais, existem procedimentos de compilação prontos. Utilize-os antes de tentar construir um JCL de compilação completo.
Dica de veterano
Um código de retorno zero geralmente representa conclusão normal, mas o significado depende da aplicação e de seus contratos de execução.
Não trate todos os retornos diferentes de zero como iguais.
Investigue também mensagens, condições de execução e eventuais abends.
Uma aplicação pode produzir resultado incorreto mesmo terminando com retorno zero.
7. Episódio 6 — REXX entra na sala de controle
Agora precisamos automatizar parte da missão.
Suponha que o programador execute frequentemente o mesmo job COBOL.
Em vez de navegar manualmente até o membro JCL e submetê-lo repetidamente, podemos criar um pequeno exec REXX.
No TSO/E, uma forma de submeter um membro JCL é utilizar o comando SUBMIT.
/* BELLJOB - ENVIO DE JOB COBOL */
say "BELLACOSA MAINFRAME"
say "Iniciando submissao do job..."
address tso
"SUBMIT 'USER.JCL(BELLJOB)'"
say "Retorno do comando SUBMIT:" rc
exit rcObserve os elementos.
ADDRESS TSO direciona os comandos ao ambiente TSO.
O comando SUBMIT envia o JCL ao JES.
A variável especial RC recebe o código de retorno do comando executado.
O programa apresenta esse valor e termina.
Importante: o retorno de SUBMIT não representa necessariamente o resultado final do processamento COBOL. Ele informa o retorno do comando de submissão.
O job pode ter sido aceito e ainda estar aguardando execução.
Para conhecer o resultado final, será necessário verificar o job no JES/SDSF ou usar uma interface apropriada de consulta.
Essa distinção evita um erro comum entre iniciantes.
Como executar o REXX
Em uma instalação TSO/E, você pode criar um membro chamado BELLJOB numa biblioteca REXX e executá-lo com uma instrução semelhante a:
EXEC 'USER.REXX(BELLJOB)' EXECA biblioteca precisa existir, e o usuário deve ter as permissões necessárias.
O nome USER é apenas ilustrativo.
Em ambientes reais, cada instalação define seus padrões de nomenclatura, segurança e autorização.
O que ganhamos?
Ganhamos repetibilidade.
Uma operação executada várias vezes pode ser encapsulada em um procedimento simples.
Mas não devemos exagerar.
O pequeno exec não substitui o monitoramento do JES, não resolve falhas de aplicações e não transforma automaticamente um programa COBOL em um serviço Web.
Ele automatiza uma tarefa específica.
E esse é justamente um dos segredos da produtividade: começar automatizando tarefas pequenas, repetitivas e bem compreendidas.
8. Episódio 7 — REXX dentro do CICS: uma revolução inesperada
Entre as apresentações mais interessantes do simpósio estava a de Bob Vogel, gerente de desenvolvimento da IBM.
Seu tema era REXX for CICS/ESA.
Para compreender a importância dessa apresentação, precisamos conhecer o CICS.
CICS significa Customer Information Control System.
Ele é um servidor de aplicações transacionais utilizado em ambientes empresariais.
Imagine milhares de usuários consultando saldos, registrando pedidos, atualizando contas ou realizando operações simultaneamente.
CICS ajuda a gerenciar a execução dessas transações, coordenando programas e recursos conforme a arquitetura da aplicação.
Historicamente, COBOL ocupa um lugar importante nesse ecossistema.
No simpósio de 1995, Bob Vogel apresentou uma implementação de REXX destinada ao CICS.
Ela utilizava como base o núcleo do interpretador TSO/E REXX.
A solução acrescentava recursos específicos para CICS, incluindo integração com Db2, editor de texto, shell interativo, facilidades de painéis e um sistema de arquivos baseado em VSAM.
A surpresa: produtividade de 10 a 20 vezes
Vogel relatou que sua equipe, composta principalmente de programadores COBOL/CICS, estimava ganhos de produtividade entre dez e vinte vezes em determinadas atividades realizadas com REXX.
Calma, jovem tripulante!
Isso não significa que um programa REXX execute vinte vezes mais rápido que um programa COBOL.
Também não demonstra que REXX seja universalmente superior ao COBOL.
A declaração se referia à produtividade percebida pelos desenvolvedores em seu contexto de trabalho.
São coisas completamente diferentes.
Uma ferramenta pode permitir construir um protótipo em poucas horas sem necessariamente oferecer o melhor desempenho para processar milhões de registros.
Quando utilizar cada tecnologia?
| Necessidade | Tecnologia frequentemente adequada |
|---|---|
| Regras empresariais complexas | COBOL |
| Aplicações transacionais | CICS com COBOL ou outras linguagens suportadas |
| Processamento batch | COBOL e JCL |
| Automação TSO/ISPF | REXX |
| Consultas e atualização de dados relacionais | SQL/Db2 |
| Organização da execução batch | JCL/JES |
| Investigação de jobs | SDSF e ferramentas associadas |
Essas tecnologias podem colaborar.
Não precisam disputar espaço como inimigas.
O sucesso de uma arquitetura depende da combinação correta de responsabilidades.
9. Episódio 8 — Object REXX: quando a linguagem ganhou novos poderes
Outra grande atração do simpósio foi o Object REXX.
Rick McGuire apresentou funcionalidades relacionadas à programação orientada a objetos.
Para um iniciante, orientação a objetos pode parecer um conceito complicado.
Mas sua ideia básica é relativamente simples.
Imagine que precisamos representar uma conta bancária.
Uma conta possui características:
Número.
Titular.
Saldo.
Situação.
E possui operações:
Consultar saldo.
Depositar.
Sacar.
Bloquear.
Em programação orientada a objetos, podemos organizar parte desses dados e comportamentos numa estrutura chamada classe.
Os objetos são instâncias dessa classe.
A proposta do Object REXX era acrescentar recursos desse modelo à linguagem tradicional.
Exemplo conceitual em Object REXX
/* Exemplo para Object REXX / ooRexx */
conta = .Conta~new
conta~depositar(250)
say "Saldo:" conta~saldo
::class Conta
::attribute saldo get
::method init
expose saldo
saldo = 1000
::method depositar
expose saldo
use arg valor
saldo = saldo + valorEsse exemplo ilustra uma implementação moderna compatível com os conceitos centrais de Object REXX. Não deve ser interpretado como uma reprodução literal de uma demonstração de 1995.
A classe Conta define um objeto.
O método init estabelece o saldo inicial.
O método depositar altera o saldo.
O símbolo ~ é utilizado para enviar mensagens aos objetos.
Mas COBOL também possui orientação a objetos?
Sim. Existem extensões e funcionalidades de COBOL orientado a objetos, dependendo do compilador e do ambiente.
Entretanto, é importante diferenciar o COBOL procedural tradicional das implementações com recursos orientados a objetos.
Grande parte dos sistemas empresariais COBOL utiliza estruturas procedurais, chamadas de programas, divisões, seções, parágrafos e módulos.
Para quem está começando, é mais importante dominar primeiro:
Estrutura de programa.
Tipos de dados.
Instruções condicionais.
Laços.
Processamento de arquivos.
Chamadas entre programas.
Tratamento de erros.
Depois disso, aprender novos paradigmas torna-se muito mais fácil.
10. Episódio 9 — REXX na Internet antes de muita gente conhecer a Web
Talvez a apresentação mais visionária do simpósio tenha sido a de Les Cottrell e Bebo White.
O assunto era a construção de scripts CGI para a World Wide Web utilizando REXX.
CGI significa Common Gateway Interface.
Era uma maneira de permitir que servidores Web executassem programas externos para produzir respostas dinâmicas.
Imagine que alguém acessa uma página de consulta.
O servidor recebe a solicitação.
Um programa processa informações.
O resultado é devolvido ao navegador.
Hoje esse modelo parece bastante familiar.
Mas em 1995 a Web ainda estava em sua infância.
Segundo o relatório, o SLAC havia instalado o primeiro servidor Web dos Estados Unidos em setembro de 1991.
Os apresentadores demonstraram principalmente soluções UNIX utilizando Uni-REXX, mas também discutiram ambientes VM.
Um exemplo didático de resposta HTTP
Um script CGI muito simples poderia produzir algo semelhante a:
/* Exemplo conceitual de CGI com REXX */
say "Content-Type: text/html"
say
say "<html>"
say "<body>"
say "<h1>Bellacosa Mainframe</h1>"
say "<p>REXX e a historia da Web</p>"
say "</body>"
say "</html>"Em um ambiente CGI devidamente configurado, a primeira linha define o tipo de conteúdo.
A linha vazia separa os cabeçalhos do corpo da resposta.
O restante forma uma pequena página HTML.
Naturalmente, um servidor real precisaria estar configurado para executar o interpretador e o programa com permissões apropriadas.
Esse exemplo tem finalidade histórica e educacional. Não é uma recomendação para publicar diretamente um CGI antigo na Internet atual.
O alerta de segurança de 1995
Os apresentadores também discutiram riscos de segurança.
Melinda Varian destacou o cuidado necessário com a instrução INTERPRET.
Em REXX, INTERPRET permite executar uma string como instruções da linguagem.
Imagine receber um texto de um usuário externo e executá-lo diretamente.
Se o conteúdo não for confiável, o resultado poderá ser extremamente perigoso.
A mesma categoria de problema aparece em outras linguagens quando desenvolvedores utilizam recursos equivalentes a eval com entradas não confiáveis.
Lição de segurança: nunca transforme dados fornecidos por usuários em comandos executáveis sem controles rigorosos.
Evitar a execução dinâmica de conteúdo externo costuma ser a abordagem mais segura.
Em sistemas empresariais, valide dados, restrinja permissões e utilize interfaces estruturadas.
Esse aviso já estava presente em 1995.
Os piratas digitais não nasceram ontem.
11. Episódio 10 — O grande segredo: REXX e a preservação dos sistemas legados
Uma das mensagens mais importantes do simpósio não estava relacionada a uma funcionalidade específica.
Era a preocupação com a continuidade tecnológica.
Melinda Varian registrou o receio de que a transferência da equipe de desenvolvimento provocasse perda de conhecimento.
Mike Cowlishaw explicou como a linguagem havia evoluído graças ao retorno de seus usuários.
Os participantes demonstraram interesse em manter a compatibilidade e ampliar a presença do REXX.
Tudo isso revela uma realidade que permanece fundamental nos ambientes mainframe.
Sistemas empresariais são construídos por pessoas.
Programas sobrevivem décadas porque equipes os mantêm, documentam, corrigem e adaptam.
Um sistema COBOL de 1985 pode continuar útil em 2026.
Mas sua manutenção dependerá de profissionais capazes de compreender tanto o código quanto as regras de negócio.
A idade do programa, isoladamente, não determina sua qualidade.
O que importa é sua confiabilidade, segurança, documentação, desempenho, suporte e capacidade de evolução.
Dica prática: seja um arqueólogo de código
Quando receber a missão de analisar um programa COBOL desconhecido, não comece alterando instruções.
Primeiro, investigue a estrutura.
Procure o PROGRAM-ID.
Identifique arquivos no FILE-CONTROL.
Examine os registros na FILE SECTION.
Observe variáveis na WORKING-STORAGE SECTION.
Localize o início do processamento na PROCEDURE DIVISION.
Procure instruções CALL, READ, WRITE, REWRITE, START e EXEC SQL.
Depois, construa um mapa das dependências.
Somente então prepare testes.
Se houver REXX associado ao processo, examine o que ele automatiza.
Se houver JCL, identifique o fluxo dos jobs.
Se houver CICS, investigue as transações, programas e recursos envolvidos.
Essa metodologia permite compreender o sistema antes de modificá-lo.
12. Episódio 11 — Um pequeno laboratório de automação
Vamos criar um segundo exemplo REXX.
Desta vez, nosso objetivo será validar dados numéricos antes de realizar um cálculo.
/* BELLVAL - VALIDACAO SIMPLES */
saldo = "1500.00"
deposito = "250.00"
saque = "100.00"
if \datatype(saldo, "N") |
\datatype(deposito, "N") |
\datatype(saque, "N") then do
say "ERRO: VALOR NAO NUMERICO"
exit 8
end
saldoFinal = saldo + deposito - saque
say "SALDO INICIAL:" saldo
say "DEPOSITO:" deposito
say "SAQUE:" saque
say "SALDO FINAL:" saldoFinal
exit 0A função DATATYPE verifica características de um valor.
Com o argumento "N", podemos testar se o conteúdo corresponde a uma representação numérica aceita pelo interpretador.
O operador \ representa negação lógica.
O operador | representa OU lógico.
A estrutura IF ... THEN DO ... END permite executar várias instruções quando uma condição é verdadeira.
Esse exemplo é apenas uma validação introdutória.
Para operações financeiras reais, também seria necessário verificar escala decimal, limites, valores negativos, regras monetárias e consistência empresarial.
Exercício para o leitor
Modifique o programa para que o saque seja maior do que o saldo disponível.
Depois acrescente uma condição impedindo que o saldo fique negativo.
Uma possível solução é:
if saque > saldo + deposito then do
say "ERRO: SALDO INSUFICIENTE"
exit 12
endRepare que agora estamos aproximando um script simples de uma regra de negócio.
É exatamente nesse ponto que o programador precisa pensar na responsabilidade de cada componente.
Uma validação feita em REXX não deve substituir os controles obrigatórios da aplicação COBOL que efetivamente processa a transação.
A segurança e a integridade devem ser garantidas no componente responsável pela operação.
13. Episódio 12 — Easter eggs e curiosidades do simpósio
Toda boa aventura possui seus segredos.
E o encontro de 1995 preservou alguns detalhes deliciosos para quem gosta da história da computação.
Easter egg 1 — A letra X de um milhão de dólares
Segundo Cowlishaw, a mudança do nome REX para REXX teria provocado custos internos estimados em aproximadamente um milhão de dólares.
O motivo envolvia atualizações de documentação e materiais já existentes.
Uma simples letra.
Um milhão de dólares.
É o tipo de história que demonstra como pequenas mudanças podem produzir enormes efeitos em ambientes corporativos.
Easter egg 2 — A mudança que quebrou milhões de programas
Cowlishaw também mencionou que a alteração de ARGS para ARG teria afetado aproximadamente 2,5 milhões de programas.
Essa quantidade era uma estimativa histórica apresentada pelo próprio criador da linguagem.
Para o programador COBOL iniciante, a lição é clara.
Alterar uma interface utilizada por outros sistemas pode produzir consequências muito maiores do que modificar uma variável local.
Compatibilidade é um patrimônio.
Easter egg 3 — O criador reconheceu os próprios erros
Cowlishaw comentou decisões que reconsideraria.
Entre elas estavam as comparações sensíveis a maiúsculas e minúsculas, o uso de DO em diferentes estruturas e a complexidade do mecanismo de parsing.
Essa atitude merece destaque.
Reconhecer limitações de projeto é uma qualidade importante de engenharia.
O fato de uma linguagem possuir milhões de usuários não significa que todas as escolhas originais tenham sido perfeitas.
Easter egg 4 — Perl virou motivo de brincadeira
Melinda Varian registrou uma piada em que Perl foi comparado ao REXX escrito apenas com caracteres especiais.
É uma brincadeira relacionada à conhecida densidade sintática de certas construções em Perl.
A curiosidade revela como as comunidades de programação já discutiam legibilidade, produtividade e estilos de linguagem.
Easter egg 5 — Os exemplos eram distribuídos em disquete
O simpósio começou com tutoriais apresentados por Chip Davis.
Os programas demonstrados foram disponibilizados no disquete do evento.
Hoje compartilhamos exemplos por repositórios digitais e plataformas de colaboração.
Naquela época, um pequeno disco magnético transportava parte do conhecimento técnico da conferência.
Easter egg 6 — Um problema real com ASCII, EBCDIC e PostScript
No final do relatório, Melinda Varian incluiu um exemplo de REXX e CMS Pipelines para processar um arquivo PostScript relacionado à proposta do padrão ANSI.
O arquivo apresentava diferenças nas terminações de linha e exigia conversões de caracteres.
A autora utilizou recursos de pipelines, conversão ASCII/EBCDIC e separação do documento em partes.
Esse trecho demonstra algo valioso: REXX também era uma ferramenta prática para resolver problemas de interoperabilidade entre sistemas.
Quem trabalha com mainframe conhece a importância de compreender codificações, formatos de registros e convenções de armazenamento.
Um arquivo aparentemente simples pode se tornar um quebra-cabeça quando atravessa plataformas.
14. Episódio 13 — O que o iniciante deve estudar depois dessa viagem?
A melhor maneira de aproveitar essa história é transformá-la em conhecimento prático.
Proponho uma trilha de estudos organizada em sete missões.
Missão 1 — COBOL básico. Aprenda a estrutura de um programa, campos PIC, instruções MOVE, DISPLAY, COMPUTE, IF, EVALUATE e PERFORM.
Missão 2 — JCL. Compreenda JOB, EXEC, DD, bibliotecas de carga, datasets, condições de execução e códigos de retorno.
Missão 3 — TSO/ISPF. Aprenda a navegar por bibliotecas, editar membros e localizar programas e jobs.
Missão 4 — REXX. Estude SAY, PARSE, IF, DO, DATATYPE, ADDRESS e o tratamento da variável RC.
Missão 5 — SDSF. Aprenda a consultar a execução de jobs, examinar saídas e interpretar mensagens.
Missão 6 — CICS e Db2. Conheça os fundamentos das aplicações transacionais e dos dados relacionais.
Missão 7 — Automação segura. Construa utilitários pequenos, documentados e testados para reduzir tarefas repetitivas.
O importante é não tentar aprender tudo simultaneamente.
Domine um fundamento.
Pratique.
Cometa erros em um ambiente autorizado de laboratório.
Leia as mensagens.
Corrija.
Depois avance.
Um programador não se torna experiente apenas assistindo a demonstrações.
Ele precisa executar, investigar e compreender.
15. Episódio 14 — O legado de 1995 em 2026
Trinta e um anos se passaram desde o simpósio.
O mercado de computação mudou profundamente.
A Internet se tornou infraestrutura essencial.
Linux passou a ocupar um lugar central em servidores e ambientes corporativos.
Serviços distribuídos, APIs, contêineres, computação em nuvem e inteligência artificial transformaram a maneira como construímos sistemas.
Mas COBOL continua presente em aplicações empresariais importantes.
REXX ainda é utilizado para automação em ambientes IBM Z.
JCL permanece essencial em muitos fluxos batch.
CICS e Db2 continuam associados a aplicações críticas.
Isso não significa que todos os planos apresentados em 1995 tenham se concretizado.
Alguns produtos evoluíram.
Outros perderam espaço.
Algumas arquiteturas foram substituídas por soluções diferentes.
O ponto importante é que a necessidade de integrar sistemas, preservar conhecimento e automatizar operações não desapareceu.
Ela apenas ganhou novas ferramentas.
Hoje podemos utilizar REXX para tarefas tradicionais, Python para automações externas, Zowe para interação com recursos z/OS, APIs para integração e ferramentas de DevOps para organizar entregas.
Cada tecnologia precisa ser avaliada conforme o ambiente, a segurança, o suporte e os objetivos do projeto.
A lição do simpósio é que modernização não começou com a computação em nuvem.
Ela já era uma preocupação concreta dos desenvolvedores de mainframe em 1995.
16. Episódio final — O último café da Bebop
Nossa nave retorna ao presente.
Spike Spiegel observa um antigo terminal.
Na tela, um programa COBOL apresenta seu resultado.
Ao lado, um pequeno exec REXX automatiza uma tarefa.
No spool do JES, um job termina normalmente.
Nada parece extraordinário.
Entretanto, cada componente carrega décadas de decisões arquiteturais, aprendizagem e engenharia.
O REXX nasceu da vontade de tornar a programação mais acessível.
O COBOL consolidou-se como instrumento fundamental para representar e executar regras empresariais.
O JCL organizou a execução de trabalhos.
O CICS ajudou a construir ambientes transacionais.
E os profissionais que desenvolveram essas tecnologias enfrentaram muitos dos mesmos problemas que encontramos hoje: produtividade, interoperabilidade, documentação, segurança e preservação do conhecimento.
O simpósio de 1995 nos ensina que o futuro raramente surge completamente separado do passado.
Muitas vezes ele nasce de uma melhoria aparentemente pequena, de uma necessidade operacional ou de uma ideia discutida entre programadores.
Como na jornada de Spike Spiegel, cada missão deixa alguma coisa para trás.
Algumas decisões não podem ser desfeitas.
Alguns erros continuam presentes.
Mas há sempre uma nova oportunidade para compreender melhor o sistema e construir uma solução mais elegante.
Para o novo programador COBOL, fica uma última recomendação.
Não trate o mainframe como uma caixa-preta.
Abra os manuais.
Leia os programas.
Experimente REXX.
Entenda JCL.
Investigue os jobs.
Aprenda com os profissionais que vieram antes.
E, quando encontrar um programa escrito há trinta ou quarenta anos, lembre-se de que alguém precisou imaginar, desenvolver, testar e colocar aquele código em produção.
Um sistema legado não é apenas um programa antigo. É uma história que continua sendo executada.
Até a próxima missão.
See you, Space Cowboy…
Referências históricas
Melinda Varian — REXX Symposium, May 1995. Relatório do Sexto Simpósio Internacional de REXX, publicado em 1995.
https://www.rexxla.org/events/1995/report.htmlProceedings of the 6th International REXX Symposium. SLAC-R-95-464, Stanford Linear Accelerator Center.
https://www.slac.stanford.edu/pubs/slacreports/reports21/slac-r-464.pdfMike Cowlishaw — REXX 1995: The Growth of a Language. Apresentação histórica sobre as origens e a evolução do REXX, incluída nos anais do simpósio.
REXX Language Association — Arquivo de apresentações históricas.
https://www.rexxla.org/events/presentation.rsp
Nota editorial: os personagens e as situações envolvendo Spike Spiegel e a nave Bebop constituem uma homenagem narrativa a Cowboy Bebop. Não representam acontecimentos reais do simpósio. Os programas didáticos foram elaborados para este artigo, e não extraídos literalmente das apresentações históricas. Os números de mercado, previsões de lançamento e estimativas de produtividade são apresentados no contexto em que foram relatados em 1995.
Bellacosa Mainframe
Preservando o passado, compreendendo o presente e programando o futuro.
See you, Mainframe Cowboy…
