Translate

Mostrar mensagens com a etiqueta exec. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta exec. Mostrar todas as mensagens

sábado, 1 de novembro de 2025

🚀☕ REXX: O “Python do Mainframe” QUE JÁ EXISTIA QUANDO A INTERNET AINDA ENGATINHAVA ☕🚀


Bellacosa Mainframe apresenta o REXX

🚀☕ REXX: O “Python do Mainframe” QUE JÁ EXISTIA QUANDO A INTERNET AINDA ENGATINHAVA ☕🚀

A linguagem lendária da IBM que transformou operadores em programadores e virou o canivete suíço do z/OS

“Enquanto muita gente hoje descobre automação com Python… o mainframe já fazia isso elegantemente com REXX há mais de 40 anos.” 😎


📜 O NASCIMENTO DE UMA LENDA

Final dos anos 70.

Mainframes dominavam o planeta corporativo:

  • bancos
  • governos
  • seguradoras
  • bolsas de valores
  • telecomunicações

Mas existia um problema gigantesco.

Programar era:

  • complexo
  • burocrático
  • lento
  • doloroso

COBOL era poderoso…
Assembler era monstruoso…
CLIST era limitado…

Foi então que surgiu:

⚡ REXX ⚡

Criado por Mike Cowlishaw nos laboratórios IBM Hursley, o REXX nasceu com uma missão quase revolucionária:

“Tornar a programação humana novamente.”

E conseguiu.


🤯 O QUE TORNAVA O REXX DIFERENTE?

Naquela época, linguagens queriam que:

  • humanos pensassem como máquinas.

O REXX fez o contrário:

  • fez a máquina entender humanos.

Resultado?

Uma linguagem:

  • limpa
  • natural
  • flexível
  • extremamente poderosa

😲 O REXX NÃO QUER SABER DE BUROCRACIA

Enquanto COBOL exigia:

01 WS-NOME      PIC X(20).
01 WS-IDADE PIC 9(03).
01 WS-SALARIO PIC 9(05)V99.

o REXX simplesmente dizia:

nome = "VAGNER"
idade = 40
salario = 99999

Pronto.
Acabou.
Sem WORKING-STORAGE.
Sem DATA DIVISION.
Sem sofrimento existencial. 😂


☕ O OPERADOR VIROU PROGRAMADOR

Aqui está uma das maiores revoluções silenciosas do mainframe.

Antes do REXX:

  • automação era território dos desenvolvedores hardcore.

Depois do REXX:

  • operadores
  • analistas
  • sysprogs
  • suporte
  • administradores

começaram a automatizar tudo.

O REXX democratizou o poder do z/OS.


🧠 O PARSE: A ARMA SECRETA DO REXX

O PARSE do REXX é quase magia negra corporativa.

Imagine receber uma linha:

USER01 PROD 1500

E transformar isso em variáveis automaticamente:

linha = "USER01 PROD 1500"

parse var linha usuario ambiente saldo

say usuario
say ambiente
say saldo

Saída:

USER01
PROD
1500

Sem SPLIT.
Sem REGEX.
Sem trauma psicológico.


🔥 REXX NO MUNDO REAL

O REXX virou a “cola universal” do z/OS.

Ele conversa com:

  • TSO
  • ISPF
  • SDSF
  • JES2
  • DB2
  • IMS
  • NetView
  • QMF

É praticamente o “multiverso da automação mainframe”.


💣 EXEMPLO REAL — GERANDO JCL AUTOMATICAMENTE

Imagine criar 100 steps manualmente…

Agora veja o REXX humilhando a tarefa:

do i = 1 to 100
say "//STEP"i "EXEC PGM=IEFBR14"
end

Boom. 💥

100 steps gerados em segundos.


😎 O REXX NÃO LIGA PARA INDENTAÇÃO

Python:

if x > 10:
print("OK")

Errou espaço?
💀 morreu.

REXX:

if x > 10 then
say "OK"

ou:

if x > 10 then
say "OK"

ou até:

IF X > 10 THEN SAY "OK"

O REXX olha pra isso e fala:

“Relaxa. Eu entendi.” 😎


👴 O SYSOP VETERANO E O REXX

Todo ambiente z/OS tem aquele sysprog lendário que:

  • sabe JES2 de cabeça
  • conversa com dumps
  • domou CICS em produção
  • tem um PDS de REXX desde 1994

E normalmente existe um dataset misterioso chamado:

SYS1.REXX.CNTL

que ninguém ousa apagar. 😂

Porque:

  • metade da automação crítica mora lá.

🧪 EXEMPLO — CONSULTANDO DATASETS

say "Digite o dataset"

pull dsn

"LISTDS '"dsn"'"

say "Consulta finalizada"

Simples.
Humano.
Objetivo.


🚀 O REXX ERA “SCRIPTING MODERNO” ANTES DO SCRIPTING MODERNO

Muita coisa atribuída hoje ao Python já existia no REXX:

  • interpretado
  • shell scripting
  • tipagem dinâmica
  • automação
  • REPL interativo
  • parsing poderoso

O REXX estava décadas à frente.


👀 EASTER EGG MAINFRAME #1

Veteranos sabem…

Existe uma entidade ancestral chamada:

IRXJCL

Quando alguém descobre isso pela primeira vez:

  • automaticamente ganha +10 em automação. 😆

🔥 EXEMPLO — REXX EXECUTANDO COMANDOS TSO

address tso

"ALLOC FI(TESTE) DA('USER.TEST') SHR"

say "Dataset alocado!"

Aqui o REXX vira praticamente:

  • operador
  • console
  • automação
  • shell scripting

tudo ao mesmo tempo.


🤯 O REXX CONSEGUE “CONVERSAR” COM O SISTEMA

E isso muda tudo.

Você pode:

  • emitir comandos
  • ler retorno
  • analisar mensagens
  • tomar decisões
  • automatizar operações

Exemplo:

address tso "LISTCAT ENT(USER.TEST)"

if rc = 0 then
say "Dataset existe"
else
say "Dataset não encontrado"

REXX + RC = automação operacional absurda.


👀 EASTER EGG MAINFRAME #2

Se um REXX começa com:

/* REXX */

veteranos imediatamente sentem cheiro de:

  • ISPF macro
  • automação antiga
  • script crítico
  • possível perigo operacional 😂

☠️ O BUG MAIS CLÁSSICO DO REXX

Como variáveis não precisam ser declaradas…

isso aqui:

total = 100
totla = total + 1

cria:

  • TOTAL
  • TOTLA

automaticamente.

E o programador passa:

  • 4 horas
  • 3 cafés
  • 2 crises existenciais

tentando descobrir o erro.


🛡️ O ANTÍDOTO SAGRADO

Veteranos usam:

signal on novalue

Isso faz o REXX reclamar de variáveis inexistentes.

Quase um:

“modo anti-digitador cansado”.


💾 O REXX VIROU A ALMA DO ISPF

Muita gente não percebe…

Mas inúmeras ferramentas ISPF:

  • painéis
  • macros
  • diálogos
  • automações

dependem fortemente de REXX.

Sem REXX:

  • muita produtividade do z/OS evaporaria.

🎮 EASTER EGG MAINFRAME #3

Existe um momento mágico na vida do mainframeiro…

Quando ele cria seu primeiro:

ISREDIT MACRO

E percebe que pode controlar o editor inteiro.

Nesse instante:

  • o usuário evolui para forma final. 😂

🚨 O REXX NO MUNDO CORPORATIVO

Grandes bancos usam REXX para:

  • automação batch
  • validação operacional
  • geração de JCL
  • monitoramento
  • administração TSO
  • integração de ferramentas

E muitos ambientes ainda possuem:

  • milhares de execs ativos.

🧠 O VERDADEIRO SEGREDO DO REXX

Não é apenas a sintaxe.

É a produtividade.

Você escreve pouco…
e resolve MUITO.


⚡ MINI LAB — REXX “HELLO MAINFRAME”

/* HELLO */

say "=== BELLACOSA MAINFRAME ==="
say "Digite seu nome:"

pull nome

say "Bem-vindo ao universo REXX," nome

say "Hoje você desbloqueou"
say "o canivete suíço do z/OS 😎"

exit 0

☕ CONCLUSÃO

O REXX não é apenas:

  • uma linguagem antiga.

Ele é:

  • um pedaço vivo da história da computação corporativa.

Uma linguagem:

  • elegante
  • poderosa
  • extremamente humana

que continua relevante porque resolve problemas reais.

Enquanto muita tecnologia moderna nasce e desaparece…

o REXX continua firme no coração do mainframe.

Porque no fim das contas:

produtividade nunca sai de moda. 😎☕


segunda-feira, 30 de setembro de 2024

🔥 JCL no z/OS 3.2 — o silêncio que sustenta tudo

 

Bellacosa Maiframe apresenta JCL V3.2 Job Control Language

🔥 JCL no z/OS 3.2 — o silêncio que sustenta tudo



📅 Datas importantes

  • Release (GA): setembro de 2024

  • Final de suporte IBM (EoS): 30 de setembro de 2029 (ciclo padrão de suporte)

O z/OS 3.2 não veio para “mudar o jogo”.
Ele veio para confirmar quem sempre mandou no jogo.


🧬 Contexto histórico

O z/OS 3.2 nasce num mundo onde:

  • Cloud híbrida já é chão de fábrica

  • Observabilidade virou obrigação

  • Segurança é contínua

  • Automação é regra

  • APIs e eventos disparam tudo

E mesmo assim…

👉 o JCL continua sendo o último elo confiável entre intenção e execução.

Bellacosa resumiria assim:

“O mundo ficou barulhento.
O JCL continua em silêncio… funcionando.”


JCL V3.2 Job Control Language

✨ O que há de novo no JCL no z/OS 3.2

A resposta curta (e honesta):

❌ Nada mudou na linguagem
✅ Tudo mudou no peso estratégico do JCL

🆕 1. JCL como fundação do core digital

No z/OS 3.2:

  • O batch é oficialmente serviço corporativo

  • JCL é disparado por:

    • APIs

    • eventos

    • pipelines

    • schedulers cognitivos

  • O JCL vira o contrato final de execução

👉 Se passou pelo JCL, aconteceu de verdade.


🆕 2. JES2 no ponto máximo de previsibilidade

  • Escala massiva de jobs concorrentes

  • Spool estável como rocha

  • Restart e recovery totalmente previsíveis

  • Integração total com automação e monitoramento

O operador agora governa fluxo,
não apaga incêndio.


🆕 3. DFSMS completamente orientado a políticas

  • Storage cada vez mais autônomo

  • Menos parâmetros manuais

  • Menos erro humano

  • Mais inteligência sistêmica

O resultado?
👉 JCL mais limpo, mais legível e mais durável.


🔧 Melhorias percebidas no dia a dia

✔ Batch 24x7 sem drama
✔ Menos “gambiarras históricas”
✔ Mais padronização
✔ JCL tratado como código crítico
✔ Auditoria e rastreabilidade nativas

Nada mudou no //STEP EXEC.
Tudo mudou na responsabilidade do job.


🥚 Easter Eggs (para mainframer raiz)

  • 🥚 JCL escrito no OS/360 ainda roda no z/OS 3.2

  • 🥚 IEFBR14 segue vivo e respeitado

  • 🥚 Comentários em JCL mais antigos que DevOps 😅

  • 🥚 O erro mais comum continua sendo:

    • RC ignorado

    • DISP mal planejado

    • dataset em uso em produção

👉 Tecnologia evolui. Erro humano é backward compatible.


💡 Dicas Bellacosa para JCL no z/OS 3.2

🔹 Trate JCL como ativo estratégico corporativo
🔹 Pense no job como serviço crítico, não script
🔹 Versione JCL como código
🔹 Padronize nomes, comentários e RC
🔹 Documente decisões, não só comandos

🔹 Sempre use:

  • IF / THEN / ELSE

  • RC explícito

  • SYSOUT claro

  • comentários pensando em décadas

Esse JCL vai rodar quando você não estiver mais aqui.


📈 Evolução do JCL até o z/OS 3.2

EraPapel do JCL
OS/360Controle batch
MVSAutomação
OS/390Base corporativa
z/OS V1.xOrquestração
z/OS V2.xMundo híbrido
z/OS 3.1Core digital
z/OS 3.2Alicerce definitivo

👉 No z/OS 3.2, o JCL não é discutido.
Ele é assumido.


📜 Exemplo de JCL “cara de z/OS 3.2”

//BELL32 JOB (ACCT),'JCL z/OS 3.2', // CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID //* //* JOB EXPOSTO COMO SERVIÇO CORPORATIVO //* DISPARADO POR API / EVENTO / PIPELINE //* //STEP01 EXEC PGM=COREPROC //STEPLIB DD DSN=BELLACOSA.LOADLIB,DISP=SHR //SYSOUT DD SYSOUT=* //* //IF (STEP01.RC = 0) THEN //STEP02 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE BELLACOSA.WORK.DATA SET MAXCC = 0 /* //ENDIF

💬 Comentário Bellacosa:

“Esse job não sabe quem o chamou.
E isso é exatamente o motivo pelo qual ele é confiável.”


🧠 Comentário final

O JCL no z/OS 3.2 é a confirmação definitiva de uma verdade antiga:

🔥 Confiabilidade não se reinventa.
Ela se preserva.

Enquanto novas plataformas prometem estabilidade,
o JCL segue entregando há mais de 60 anos.

JCL não é passado.
JCL é o chão onde o futuro pisa.

sábado, 30 de setembro de 2023

🔥 JCL no z/OS 3.1 — o clássico definitivo no mainframe pós-híbrido

 

Bellacosa Mainframe apresenta JCL V3.1 Job Control Language

🔥 JCL no z/OS 3.1 — o clássico definitivo no mainframe pós-híbrido

 


📅 Datas importantes

  • Release (GA): setembro de 2023

  • Final de suporte IBM (EoS): 30 de setembro de 2028

O z/OS 3.1 inaugura a era sem versão “R”.
Não é V2Rx. É z/OS 3.x.
E o JCL? Continua lá, firme, como sempre.


🧬 Contexto histórico

O z/OS 3.1 nasce num momento simbólico:

  • Mainframe totalmente integrado ao mundo digital

  • Cloud híbrida consolidada

  • APIs e eventos como padrão

  • Observabilidade, automação, segurança contínua

  • Batch tratado como serviço corporativo crítico

E no centro disso tudo…

👉 o JCL segue intocado, provando que boa arquitetura não precisa ser reescrita.

Bellacosa resumiria assim:

“Mudou o número da versão.
O JCL nem piscou.”


JCL V3.1 Job Control Language

✨ O que há de novo no JCL no z/OS 3.1

Aqui está a verdade nua e crua:

❌ Não existe “novo JCL”
✅ Existe um JCL mais estratégico do que nunca

🆕 1. JCL como API operacional invisível

No z/OS 3.1:

  • Jobs são acionados por:

    • APIs REST

    • eventos

    • pipelines CI/CD

    • schedulers corporativos

  • O JCL vira o contrato final entre:

    • mundo distribuído

    • core transacional

👉 O job é o endpoint que não falha.


🆕 2. JES2 no nível máximo de maturidade

  • Escala absurda de jobs simultâneos

  • Spool altamente estável

  • Restart e recovery previsíveis

  • Integração total com automação e observabilidade

O operador deixou de “apagar incêndio”.
Agora ele governa processos.


🆕 3. DFSMS totalmente orientado a políticas

  • Storage praticamente autônomo

  • Menos parâmetros manuais no JCL

  • Datasets gigantes tratados naturalmente

  • Menos erro humano, mais inteligência sistêmica

O JCL fica mais limpo porque o sistema ficou mais esperto.


🔧 Melhorias percebidas no dia a dia

✔ Batch tratado como serviço 24x7
✔ Menos JCL “cheio de gambiarra”
✔ Menos tuning artesanal
✔ Mais padronização
✔ JCL versionado, auditado e governado

Nada mudou na sintaxe.
Tudo mudou na importância estratégica.


🥚 Easter Eggs (para mainframer raiz)

  • 🥚 JCL escrito nos anos 70 ainda roda no z/OS 3.1

  • 🥚 IEFBR14 segue vivo (e seguirá)

  • 🥚 Comentários em JCL mais antigos que o termo “cloud” 😅

  • 🥚 O erro campeão continua sendo:

    • RC ignorado

    • DISP mal planejado

    • dataset em uso em produção

👉 Mudam as gerações. O erro humano permanece.


💡 Dicas Bellacosa para JCL no z/OS 3.1

🔹 Trate JCL como ativo estratégico
🔹 Pense no job como serviço corporativo
🔹 Versione JCL como código
🔹 Use padrões claros de nomenclatura
🔹 Documente o porquê, não só o como

🔹 Sempre:

  • IF / THEN / ELSE

  • RC explícito

  • SYSOUT claro

  • comentários pensando em 10+ anos

Esse JCL vai sobreviver a você.
Escreva com respeito.


📈 Evolução do JCL até o z/OS 3.1

EraPapel do JCL
OS/360Controle batch
MVSAutomação
OS/390Base corporativa
z/OS V1.xOrquestração total
z/OS V2.xMundo híbrido
z/OS 3.1Fundação do core digital

👉 No z/OS 3.1, o JCL deixa de ser “legacy” oficialmente.
Ele vira infraestrutura histórica viva.


📜 Exemplo de JCL “cara de z/OS 3.1”

//BELL31 JOB (ACCT),'JCL z/OS 3.1', // CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID //* //* JOB EXPOTO COMO SERVIÇO CORPORATIVO //* DISPARADO POR API, EVENTO OU SCHEDULER //* //STEP01 EXEC PGM=COREBATCH //STEPLIB DD DSN=BELLACOSA.LOADLIB,DISP=SHR //SYSOUT DD SYSOUT=* //* //IF (STEP01.RC = 0) THEN //STEP02 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE BELLACOSA.WORK.DATA SET MAXCC = 0 /* //ENDIF

💬 Comentário Bellacosa:

“Esse job pode ser chamado por um operador,
por um pipeline ou por uma API.
Ele não precisa saber. Ele só precisa entregar.”


🧠 Comentário final

O JCL no z/OS 3.1 é a prova definitiva de uma verdade que só mainframer entende:

🔥 Confiabilidade não se reescreve.
Ela se herda.

Enquanto o mundo corre atrás da próxima abstração,
o JCL continua garantindo que:

  • o banco feche

  • o governo processe

  • a indústria funcione

JCL não é passado.
JCL é a espinha dorsal silenciosa do presente e do futuro.

quinta-feira, 27 de fevereiro de 2020

📌 O que é JCL (visão geral)

 

.



📌 O que é JCL (visão geral)

  • JCLJob Control Language — é a linguagem de controle de jobs que instrui o sistema operacional IBM Mainframe sobre quais programas executar, com quais dados e recursos, em que sequência e como tratar saídas/erros. Wikipedia

  • Foi projetado para batch processing, declarando tudo explicitamente para evitar conflitos de recursos e permitir alocação antecipada de dispositivos/datasets. codedocs.org


🕰️ Linha do tempo da evolução do JCL

1) OS/360 – Introdução (1964–1966)

  • Data: meados da década de 1960 — cerca de 1964–1966. Grokipedia+1

  • Plataformas: OS/360 e DOS/360.

  • O que mudou:

    • JCL original lançada com o OS/360 (e paralelo no DOS/360) para controlar jobs batch nos recém-lançados System/360.

    • Sintaxe inicial baseada em cartões perfurados (JOB, EXEC, DD).

    • Estabelece a base do modelo que persiste até hoje.

  • Observação: essa é a primeira e principal “release” histórica — não existiam versões numeradas de JCL separadas do sistema operacional; era evoluído conforme OS/360 evoluía. Grokipedia

📌 Curiosidade: Fred Brooks — um dos líderes do projeto OS/360 — brincou que JCL foi “a pior linguagem já criada” devido à sua complexidade e rigidez, mas ela persistiu porque funcionava dentro das restrições daquele hardware/era. Wikipedia


2) MVS (Multiple Virtual Storage) — Evolução do JCL (1974+)

  • Data: 1974 e anos subsequentes. Wikipedia

  • Plataformas: OS/VS2 avançou para MVS — a base para os sistemas 370 e além.

  • O que mudou:

    • Introdução de virtual storage, multiprogramação e melhores capacidades de gestão de jobs.

    • JCL foi mantido compatível com versões anteriores, mas ganhou novas opções para dataset allocation, múltiplos steps, procedures etc.

  • Notas:

    • Nas versões MVS, o JCL permaneceu essencialmente o mesmo por compatibilidade, mas parâmetros novos foram adicionados conforme o sistema operacional expandiu funções (virtual storage, JES etc.). mainframemaster.com


3) OS/390 – Consolidando MVS (1995)

  • Data: 1995. Wikipedia

  • Plataforma: OS/390 (a evolução do MVS com pacotes completos — DFSMShsm, JES2/JES3 etc.).

  • O que mudou:

    • JCL não teve uma revisão revolucionária aqui; mas foi formalizado junto ao pacote OS/390.

    • Houve refinamentos de parâmetros e melhor suporte de integração entre subsistemas (JES, utilities, catalogação).

  • Importante: ainda não havia “JCL 2.0/3.0” no sentido de uma linguagem separada — as mudanças são ligadas à evolução dos operating systems.


4) z/OS – Era moderna (2000 até agora)

  • Data: 2000 (lançamento inicial do z/OS) até as releases atuais como z/OS 3.1, 3.2… (2020s). Grokipedia

  • Plataforma: z/OS (principal OS de mainframe IBM) com JES2/JES3.

  • O que mudou no JCL:

    • Backward compatibility total com JCL legado (jobs escritos décadas atrás ainda rodam em z/OS). Wikipedia

    • Novos parâmetros e recursos, como:

      • Manipulação de datasets inline e melhores constructs (ex: IF/THEN/ELSE no próprio JCL). Reddit

      • Suporte para novos dispositivos e sistemas de arquivos (Unix System Services).

      • Suporte a SYSIN/SYSOUT mais flexível e melhor integração com subsistemas modernos.

    • Integração com ferramentas de desenvolvimento modernas (IDE, JCL linters, LSP, integração com Git via Zowe etc.). ibm.github.io


📋 Como contar “releases” do JCL?

Diferente de linguagens como C ou Java, JCL não tem uma lista de versões como “JCL 1.0, 2.0, 3.0” — sua evolução está intrinsecamente ligada às versões dos sistemas operacionais IBM para mainframes:

Ano / PeríodoPlataforma/ReleasePrincipais mudanças no JCL
~1964–67OS/360 / DOS/360Introdução da JCL, JOB/EXEC/DD básicos, batch streams. Grokipedia
Anos 1970MVS (OS/VS2 → MVS)Virtual storage, procedures catalogadas, expansão de parâmetros. Wikipedia
1995OS/390Consolidação do pacote, recuperação de recursos e JES. Wikipedia
2000+z/OS (3.x, 4.x…)Back-compatibility, novo hardware, sistemas de arquivos modernos, integração com DevOps. ibm.github.io

📌 O que geralmente muda em JCL

Em termos gerais, as mudanças no JCL tendem a ser:

Novos parâmetros de DD/EXEC/JOB conforme o OS adiciona recursos. mainframemaster.com
Suporte a novas estruturas de dados ou subsistemas (ex: Unix System Services, datasets VSAM). IBM
Aprimoramentos de controle condicional e procedimentos. Reddit
Integração com ferramentas modernas (editores, validação, IDE). ibm.github.io


📌 Resumo (Estilo “Bellacosa Mainframe”)

  1. 1964–1966 – OS/360 & DOS/360: JCL nasce e define modelo. Grokipedia

  2. 1974+ – MVS: JCL cresce com virtual storage e multiprogramação. Wikipedia

  3. 1995 – OS/390: Pacote consolidado, refinamentos. Wikipedia

  4. 2000+ – z/OS (3.x, 4.x…): Evolução contínua, backward compatibility e suporte a tecnologias modernas.