☕ EXECIO no REXX Mainframe O canivete suíço de I/O que todo mundo usa… e quase ninguém respeita

 

☕ EXECIO no REXX Mainframe

O canivete suíço de I/O que todo mundo usa… e quase ninguém respeita

“Quando o REXX toca no disco, o EXECIO está por trás.
E quando o disco fica lento, geralmente é culpa de quem não entendeu o EXECIO.”

---

🧠 Introdução – Onde o REXX encontra o mundo real

REXX é excelente para controle, decisão e orquestração.
Mas em algum momento ele precisa fazer o que todo batch faz desde 1964:

👉 Ler dados
👉 Escrever dados

É aí que entra o EXECIO.

Simples no nome.
Perigoso no impacto.

---

🕰️ Origem histórica – Por que o EXECIO nasceu?

Antes do EXECIO:

• REXX era fortemente interativo

• I/O era dependente de comandos externos

• Ler arquivos sequenciais era lento e improvisado

Com a popularização do REXX no TSO/E e no batch, a IBM precisava de:

• Um método padrão

• Um comando eficiente

• Compatível com DDNAME

• Funcional tanto em TSO quanto em batch

Assim nasceu o EXECIO, no final dos anos 80, como ponte direta entre:

REXX ⇄ QSAM ⇄ MVS

---

📜 O que é EXECIO?

EXECIO é o comando REXX responsável por:

• Ler registros de um DDNAME

• Escrever registros em um DDNAME

• Transferir dados entre datasets e variáveis REXX

Ele trabalha sempre com:

• DDNAME alocado

• Registros sequenciais

• Stem variables

---

🧪 Sintaxe essencial

EXECIO <quantidade> DISKR <ddname> (STEM var.
EXECIO <quantidade> DISKW <ddname> (STEM var.

Exemplo básico:

EXECIO * DISKR SYSIN (STEM linhas.

Aqui:

• * = todas as linhas

• DISKR = leitura

• SYSIN = DDNAME

• linhas. = onde os dados vão morar

---

🧩 Curiosidades que pouca gente comenta

🧩 1. EXECIO não entende “arquivo”

Ele entende DDNAME.

Se o DDNAME não existe:

• RC pode ser enganoso

• O erro aparece em mensagem

• GETMSG vira obrigatório

---

🧩 2. EXECIO * carrega tudo na memória

EXECIO * DISKR BIGFILE (STEM big.

Se o arquivo tem:

• 10 mil linhas → ok

• 1 milhão → boa sorte

EXECIO * é confortável… até não ser.

---

🧩 3. A variável .0 manda mais que você

Após leitura:

say linhas.0

Ela contém quantos registros foram lidos.

Ignorar .0 é convite a loop errado.

---

🥚 Easter Eggs técnicos

🥚 1. Leitura parcial estratégica

EXECIO 1 DISKR INDD (STEM linha.

Ótimo para:

• Ler cabeçalhos

• Identificar layout

• Decidir processamento sem ler tudo

---

🥚 2. EXECIO + Data Stack

É possível combinar:

• EXECIO

• PUSH / QUEUE

• PARSE PULL

Criando pipelines “à moda antiga”.

---

🥚 3. EXECIO em SYSREXX

No batch, EXECIO:

• Roda sem terminal

• Depende totalmente do JCL

• É mais rápido

• É mais perigoso

---

🧠 Exemplo prático – Batch inteligente

EXECIO * DISKR INPUT (STEM in.
DO i = 1 TO in.0
  IF POS('ERRO', in.i) > 0 THEN DO
     SAY 'Erro detectado na linha' i
     EXIT 8
  END
END
EXECIO in.0 DISKW OUTPUT (STEM in.

Esse REXX:

• Lê

• Analisa

• Decide

• Escreve

Tudo antes do COBOL rodar.

---

⚠️ Riscos reais do EXECIO

• Arquivo grande → consumo de memória

• DISKW sem controle → overwrite silencioso

• DISKR sem validação → loop infinito

• Falta de fechamento → dados inconsistentes

Boa prática Jedi

EXECIO 0 DISKW OUTDD

Força flush e fechamento correto.

---

🛡️ EXECIO e segurança

EXECIO respeita:

• RACF

• Permissões de dataset

• Contexto do job

Mas:

REXX que escreve dados é tão poderoso quanto um utility IBM.

Controle de acesso é obrigatório.

---

☕ Comentário Bellacosa Mainframe

O EXECIO é o momento em que:

• O REXX deixa de ser “script”

• E passa a mexer em dados corporativos

Quem trata EXECIO como “detalhe”:

• Cria batch frágil

• Gera incidentes silenciosos

• Descobre o erro em produção

EXECIO não é comando.
É compromisso com o dado.

---

🧠 Frase final para colar no monitor

Se o REXX leu, ele é responsável.
Se escreveu, ele é culpado até prova em contrário.

 

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

Era	Papel do JCL
OS/360	Controle batch
MVS	Automação
OS/390	Base corporativa
z/OS V1.x	Orquestração
z/OS V2.x	Mundo híbrido
z/OS 3.1	Core digital
z/OS 3.2	Alicerce 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.

 

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

Era	Papel do JCL
OS/360	Controle batch
MVS	Automação
OS/390	Base corporativa
z/OS V1.x	Orquestração total
z/OS V2.x	Mundo híbrido
z/OS 3.1	Fundaçã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.

 

Bellacosa Mainframe apresenta JCL V2R4 Job Control Language

🔥 JCL no z/OS V2R4 — o clássico absoluto em plena era do híbrido e do automático

---

📅 Datas importantes

• Release (GA): setembro de 2019

• Final de suporte IBM: 30 de setembro de 2024

O z/OS V2R4 não trouxe um “novo JCL”.
Ele consolidou o JCL como a linguagem mais estável do data center híbrido moderno.

---

🧬 Contexto histórico

Quando o z/OS V2R4 chegou, o jogo já estava claro:

• Cloud híbrida não era mais tendência — era realidade

• APIs já chamavam batch

• DevOps já convivia com JES

• Linux on Z crescia sem pedir desculpa

E no meio disso tudo…

👉 o JCL seguia intacto, confiável, previsível.

Bellacosa resumiria assim:

“Todo mundo muda a fachada. O JCL segura a fundação.”

---

Job Control Language JCL V2R4

✨ O que há de novo no JCL do V2R4 (sem mudar a linguagem)

A IBM foi inteligente: não mexeu no que não precisa ser mexido.

🆕 1. JCL totalmente integrado à automação moderna

No V2R4, o normal passou a ser:

• JCL disparado por:

  • APIs REST

  • schedulers inteligentes

  • eventos externos

• JCL funcionando como backend confiável do mundo digital

👉 O job batch deixou de ser “coisa da madrugada”.

---

🆕 2. JES2 ainda mais estável e previsível

• Melhor gerenciamento de spool

• Ambientes com milhares de jobs simultâneos

• Restart e recovery mais confiáveis

Menos “rezar pro job terminar”
Mais “sabemos exatamente o que vai acontecer”.

---

🆕 3. DFSMS maduro para volumes gigantes

• Convivência natural com:

  • EAV

  • datasets enormes

  • políticas automáticas

• Menos tuning manual de SPACE e UNIT

O JCL ficou mais simples, porque o sistema ficou mais inteligente.

---

🔧 Melhorias sentidas no dia a dia do mainframer

✔ Batch previsível em ambientes híbridos
✔ Menos ajustes manuais
✔ Mais padronização de jobs
✔ JCL tratado como ativo corporativo

Nada mudou na sintaxe.
Tudo mudou na confiança operacional.

---

🥚 Easter Eggs (para quem viveu o V2R4)

• 🥚 Jobs escritos no MVS rodando felizes no V2R4

• 🥚 IEFBR14 ainda presente em ambientes “cloud first” 😅

• 🥚 Comentários no JCL mais antigos que ferramentas DevOps

• 🥚 O erro nº 1 continuava sendo:

  • DISP errado

  • dataset em uso

  • RC ignorado

---

💡 Dicas Bellacosa para JCL no z/OS V2R4

🔹 Pense no JCL como infraestrutura crítica, não script
🔹 Documente o porquê do job
🔹 Use:

• IF / THEN / ELSE

• RC bem tratados

• nomes de passos claros

🔹 Lembre-se:

Esse job pode rodar quando você não estiver mais na empresa.

---

📈 Evolução do JCL até o V2R4

Era	Papel do JCL
OS/360	Controle de jobs
MVS	Automação batch
OS/390	Base corporativa
z/OS V1.x	Orquestração total
z/OS V2R2/V2R3	Mundo híbrido
z/OS V2R4	Maturidade absoluta

👉 No V2R4, o JCL já não precisa provar nada.

---

📜 Exemplo de JCL “cara de V2R4”

//BELLV24  JOB (ACCT),'JCL z/OS V2R4',
//             CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//*  JOB ORQUESTRADO POR SCHEDULER / API
//*
//STEP01   EXEC PGM=MYBATCH
//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.ARQ.TEMP
  SET MAXCC = 0
/*
//ENDIF

💬 Comentário Bellacosa:

“Não importa quem disparou esse job —
operador, scheduler ou API.
O JCL entrega do mesmo jeito.”

---

🧠 Comentário final

O JCL no z/OS V2R4 é o ponto onde tudo fica claro:

• Ele não é antigo

• Ele não é obsoleto

• Ele não é moda

Ele é confiável.

Enquanto o mundo corre atrás de estabilidade,
o JCL já está lá há décadas —
garantindo que o digital funcione quando ninguém está olhando.

🔥 JCL não é legado morto.
É legado que sustenta o presente.

 

Bellacosa Mainframe apresenta JCL Job Control Language V2R3

🔥 JCL no z/OS V2R3 — o veterano que aprendeu a viver no mundo híbrido

 

---

📅 Datas importantes

• Release (GA): setembro de 2018

• Final de suporte IBM: 30 de setembro de 2023

O z/OS V2R3 não tentou “modernizar” o JCL na marra. Ele fez algo melhor:
colocou o JCL no centro do mainframe conectado ao mundo cloud, API e DevOps.

---

🧬 Contexto histórico

Quando o z/OS V2R3 chegou, o cenário era curioso:

• Mainframe totalmente vivo

• Linux on Z crescendo

• APIs expostas para o mundo

• DevOps já batendo na porta do data center

• Cloud híbrida deixando de ser discurso

E no meio disso tudo…
👉 o JCL continuava sendo o maestro silencioso do batch corporativo.

Bellacosa diria:

“Enquanto o pessoal discute pipeline em YAML, o JCL fecha a contabilidade do dia.”

---

JCL Job Control Language V2R3

✨ O que há de novo no JCL (indiretamente) no V2R3

O JCL não muda a sintaxe, mas o contexto muda bastante.

🆕 1. JCL como backend de automação moderna

No V2R3, é comum ver:

• Jobs disparados por:

  • REST APIs

  • ferramentas DevOps

  • schedulers inteligentes

• JCL sendo tratado como contrato operacional estável

👉 O JCL vira “infraestrutura como código”… antes disso virar moda.

---

🆕 2. Melhor convivência com z/OS Connect e middleware

• Batch acionado por eventos externos

• Processos online + batch integrados

• JCL executando tarefas críticas iniciadas fora do mainframe

O batch deixou de ser “janela noturna isolada”.

---

🆕 3. JES2 e DFSMS ainda mais maduros

• Spool mais estável

• Melhor gerenciamento de grandes volumes de dados

• Menos tuning manual

• Mais previsibilidade operacional

---

🔧 Melhorias percebidas no dia a dia

✔ Jobs mais previsíveis em ambientes enormes
✔ Menos dependência de “magia do operador”
✔ Mais uso de IF/THEN/ELSE em vez de COND
✔ JCL tratado como ativo estratégico

Nada de comando novo — só robustez acumulada.

---

🥚 Easter Eggs (para quem viveu o V2R3)

• 🥚 Jobs escritos no OS/390 rodando felizes no V2R3

• 🥚 IEFBR14 ainda sendo usado em ambientes “cloud native” 😅

• 🥚 Comentários no JCL mais antigos que muitos analistas

• 🥚 O erro campeão seguia sendo:

  • dataset em uso

  • DISP mal pensado

  • SPACE subestimado

---

💡 Dicas Bellacosa para JCL no z/OS V2R3

🔹 Escreva JCL pensando em longevidade

Esse job vai sobreviver a você.

🔹 Prefira:

• IF / THEN / ELSE / ENDIF

• RC bem tratado

• mensagens claras no SYSOUT

🔹 Documente o porquê, não só o como

🔹 Leia JESMSGLG como se fosse log de produção crítica — porque é.

---

📈 Evolução do JCL até o V2R3

Fase	Papel do JCL
OS/360	Controle de jobs
MVS	Automação batch
OS/390	Espinha dorsal corporativa
z/OS V1.x	Orquestrador do data center
z/OS V2R3	Fundação do mundo híbrido

👉 No V2R3, o JCL deixa claro:
não é legacy — é legado confiável.

---

📜 Exemplo de JCL “cara de V2R3”

//BELLV23  JOB (ACCT),'JCL z/OS V2R3',
//             CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//*
//STEP01   EXEC PGM=MYBATCH
//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.ARQ.TEMP
  SET MAXCC = 0
/*
//ENDIF

💬 Comentário Bellacosa:

“Esse JCL pode ser disparado por um operador, um scheduler
ou uma API REST. Ele não se importa. Ele entrega.”

---

🧠 Comentário final

O JCL no z/OS V2R3 representa a maturidade absoluta:

• Sem hype

• Sem ruptura

• Sem necessidade de provar nada

Enquanto tecnologias modernas tentam alcançar estabilidade,
o JCL já está lá há décadas.

🔥 JCL não concorre com o futuro.
Ele garante que o futuro funcione.

 

Bellacosa Mainframe apresenta JCL V2R2 Job Control Language

🔥 JCL no z/OS V2R2 — o velho maestro regendo um data center moderno

---

📅 Datas importantes

• Release (GA): abril de 2017

• Final de suporte IBM: 30 de setembro de 2022

O z/OS V2R2 não reinventou o JCL — ele provou que o JCL ainda era essencial num mundo de APIs, containers e DevOps.

---

🧬 Contexto histórico

Quando o z/OS V2R2 chegou, o discurso no mercado era outro:
cloud, microservices, pipelines, YAML, JSON…

E lá estava o JCL, firme, rodando:

• bancos centrais

• bolsas de valores

• seguradoras

• governos

👉 O V2R2 marca a fase em que o mainframe deixa de pedir desculpa por existir e passa a dizer:

“Sim, sou legacy… e é por isso que você confia em mim.”

---

Job Control Language JCL V2R2

✨ O que há de novo (indiretamente) para o JCL no V2R2

O JCL em si muda pouco, mas o ambiente muda muito.

🆕 1. JCL convivendo com DevOps

• Jobs disparados por:

  • Jenkins

  • schedulers modernos

  • pipelines CI/CD

• JCL vira backend confiável de processos “modernos”

🆕 2. Melhor integração com DFSMS e storage moderno

• Melhor uso de:

  • Extended Address Volumes (EAV)

  • volumes grandes

  • políticas SMS mais refinadas

🆕 3. JES2 mais robusto

• Melhor gerenciamento de spool

• Melhor restart e recovery

• Mais previsibilidade em ambientes com milhares de jobs concorrentes

---

🔧 Melhorias práticas percebidas pelo mainframer

✔ Batch mais estável em ambientes gigantes
✔ Menos tuning “artesanal” de SPACE e UNIT
✔ Melhor convivência com workloads online e distribuídos
✔ JCL mais usado como contrato operacional, não só script

Nada de revolução sintática — o ganho foi maturidade operacional.

---

🥚 Easter Eggs (só pra quem viveu)

• 🥚 Jobs escritos nos anos 90 continuavam rodando sem alteração

• 🥚 Muitos ambientes V2R2 tinham JCL com comentários mais velhos que o operador 😅

• 🥚 IEFBR14 seguia firme, mesmo com ferramentas modernas fazendo a mesma coisa

• 🥚 O erro mais comum continuava sendo… DISP errado

---

💡 Dicas Bellacosa para quem trabalha com JCL no V2R2

🔹 Use IF / THEN / ELSE / ENDIF — pare de abusar do COND
🔹 Escreva comentários como se o job fosse durar 20 anos (porque vai)
🔹 Pense no JCL como:

infraestrutura como código… só que confiável

🔹 Não subestime:

• retorno de código (RC)

• análise de JESMSGLG

• mensagens do system log

---

📈 Evolução do JCL até o V2R2

Era	Papel do JCL
OS/360	Controle de jobs batch
MVS / OS/390	Automação corporativa
z/OS V1.x	Orquestrador do data center
z/OS V2R2	Fundamento confiável do mundo híbrido

👉 O JCL não compete com novas tecnologias — ele as sustenta.

---

📜 Exemplo de JCL no estilo “V2R2 consciente”

//BELLV22  JOB (ACCT),'JCL V2R2',
//             CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//*
//STEP01   EXEC PGM=MYPROG
//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.ARQ.OLD
  SET MAXCC = 0
/*
//ENDIF

💬 Comentário Bellacosa:

“Esse job pode rodar hoje, amanhã ou daqui a 15 anos.
O mainframe muda — o JCL continua.”

---

🧠 Comentário final

O JCL no z/OS V2R2 representa o auge da maturidade:

• Sem hype

• Sem marketing exagerado

• Sem ruptura

Apenas confiança operacional.

Enquanto o mundo discute a próxima moda, o JCL segue ali, discreto, garantindo que:

• o salário caia na conta

• o banco abra às 10h

• o avião decole

🔥 JCL não é velho.
Velho é sistema que você não confia.

 

Bellacosa Mainframe apresenta JCL V2R1 Job Control Language

🔥 JCL no z/OS V2R1 — o veterano entra oficialmente na era moderna

---

📅 Datas importantes

• Release (GA): julho de 2015

• Final de suporte IBM: 30 de setembro de 2020

O z/OS V2R1 é o divisor de águas:
o mainframe entra de vez na era do híbrido,
e o JCL passa a conviver oficialmente com APIs, Linux, Java e DevOps — sem mudar uma vírgula.

---

🧬 Contexto histórico

Até o z/OS V1.x, o discurso era “modernização controlada”.
No V2R1, a IBM muda o tom:

• z/Architecture madura

• Cloud híbrida começando a ganhar corpo

• Linux on Z crescendo

• Middleware (CICS, MQ, DB2) totalmente integrado

• Batch deixa de ser “janela noturna”

E no centro de tudo isso…

👉 o JCL segue sendo o contrato supremo de execução.

Bellacosa resumiria assim:

“O mundo ficou moderno.
O JCL já era.”

---

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

Aqui está a elegância do V2R1:

❌ Nenhuma ruptura
✅ Consolidação total

🆕 1. JCL como pilar do batch moderno

No V2R1:

• Batch passa a rodar 24x7

• Jobs são acionados por:

  • schedulers corporativos

  • aplicações distribuídas

  • eventos externos

👉 O JCL deixa de ser “script” e vira infraestrutura operacional.

---

🆕 2. IF / THEN / ELSE vira padrão (não mais exceção)

• Menos abuso de COND

• Mais clareza no fluxo

• Menos erro humano

O JCL começa a parecer… código bem escrito.

---

🆕 3. JES2 e DFSMS mais previsíveis

• Spool mais estável

• Melhor gerenciamento de workloads

• Storage cada vez mais orientado a políticas

O resultado?
👉 menos tuning artesanal, mais previsibilidade.

---

🔧 Melhorias percebidas no dia a dia

✔ Batch rodando fora da madrugada
✔ Jobs mais legíveis
✔ Menos “JCL mágico” herdado
✔ Mais padronização
✔ RC tratado com mais seriedade

Nada mudou na linguagem.
Tudo mudou no modo de uso.

---

🥚 Easter Eggs (para mainframer raiz)

• 🥚 JCL escrito no OS/390 rodando feliz no V2R1

• 🥚 IEFBR14 continuava sendo usado sem culpa

• 🥚 Comentários no JCL mais antigos que o próprio z/OS 😅

• 🥚 O erro clássico seguia firme:

  • RC ignorado

  • DISP mal planejado

  • dataset em uso

👉 Compatibilidade é uma faca de dois gumes.

---

💡 Dicas Bellacosa para JCL no z/OS V2R1

🔹 Comece a pensar JCL como código corporativo
🔹 Padronize nomes de jobs e passos
🔹 Use IF / THEN / ELSE sempre que possível
🔹 Documente decisões históricas no JCL
🔹 Leia JESMSGLG com atenção religiosa

Esse job não é seu.
Você só é o guardião da vez.

---

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

Era	Papel do JCL
OS/360	Controle batch
MVS	Automação
OS/390	Base corporativa
z/OS V1.x	Orquestração
z/OS V2R1	Entrada oficial no mundo híbrido

👉 No V2R1, o JCL cruza a fronteira do “legacy” e entra no moderno sem pedir permissão.

---

📜 Exemplo de JCL “cara de V2R1”

//BELLV21  JOB (ACCT),'JCL z/OS V2R1',
//             CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//*
//* JOB PENSADO PARA BATCH 24x7
//*
//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.TEMP
  SET MAXCC = 0
/*
//ENDIF

💬 Comentário Bellacosa:

“Esse JCL pode rodar de dia, de noite ou por evento.
Ele não pergunta. Ele executa.”

---

🧠 Comentário final

O JCL no z/OS V2R1 representa o momento em que o mainframe diz ao mercado:

🔥 “Não vou mudar minha base para parecer moderno.
Vou integrar o moderno à minha base.”

E o JCL, silencioso como sempre, aceita a missão.

JCL não é linguagem do passado.
JCL é compromisso com o resultado.