Bellacosa Mainframe apresenta caçando os vilões em zos performance tuning

🍔💾 Essential z/OS Performance Tuning Workshop achando os vilões

Versão técnica: RMF, SMF e a arte de não tunar errado

O Essential z/OS Performance Tuning Workshop separa, logo de cara, dois tipos de profissionais:

1. Quem acha que faz performance tuning

2. Quem sabe onde olhar primeiro

Essa versão é para o segundo grupo — ou para quem quer migrar do 1️⃣ para o 2️⃣ sem trauma.

---

🎯 Regra zero do workshop

Nunca comece pelo parâmetro. Comece pela observação.

Antes de qualquer ALTER, DEFINE ou SET:

• Qual workload?

• Qual período?

• O que mudou?

• Existe baseline?

Sem isso, tuning vira superstição técnica.

---

🧠 CPU: o falso vilão

Onde olhar no RMF

RMF CPU Activity Report (Postprocessor)

Campos clássicos:

• % Busy

• % LPAR Utilization

• % Logical Processor Dispatch

• % IFA / zIIP / zAAP (quando aplicável)

Interpretação que o workshop ensina

• CPU alta com response time estável → sistema saudável

• CPU média com response time degradando → gargalo fora da CPU

• CPU baixa + atraso → WLM ou I/O

📌 Easter egg técnico:
Se o LPAR Delay cresce, não é falta de tuning — é falta de peso ou política errada.

---

⚙️ WLM: tuning começa aqui, não no SYS1.PARMLIB

RMF Workload Activity Report

Campos críticos:

• Service Class Period

• Velocity

• Average Response Time

• Delay Reasons

Exemplo típico visto no workshop:

Service Class: ONLINE_HI
Velocity Goal: 50
Achieved Velocity: 12
Delay: I/O 65%, Enqueue 20%

👉 Conclusão correta:

• Não adianta subir prioridade

• Não adianta mexer em CPU

• O gargalo não é WLM, é dependência externa

💡 Lição central:

WLM não resolve gargalo físico. Ele apenas escolhe quem sofre primeiro.

---

📊 RMF Monitor III: o “agora dói aqui”

Uso correto (e erro comum)

Monitor III serve para:

• Incidente ativo

• Observação em tempo real

• Confirmação de suspeita

Não serve para:

• Análise histórica

• Decisão estrutural

• Justificativa pós-morte

Campos típicos:

• Address Space Delay

• Device Response Time

• Enqueue Waits

📌 Erro clássico:
Usar Monitor III como prova definitiva em reunião de causa raiz.

---

🗃️ SMF: onde a discussão acaba

SMF 30 – Address Space Accounting

Usado para responder:

• Quem consumiu CPU?

• Quanto?

• Em qual período?

Exemplo prático:

SMF30:
CPU Time: baixo
Elapsed Time: alto

👉 Indício claro:

• Espera externa

• I/O

• Lock

• Dependência de outro job

---

SMF 70 / 72 – CPU e WLM

SMF 72 é o coração do tuning orientado a SLA.

Campos essenciais:

• Service Class Performance Index

• Delay Breakdown

• Period Transitions

📌 Easter egg de workshop:
Performance Index < 1.0 não é vitória se o response time continua ruim.

---

SMF 74 – I/O e Storage

Onde muitos problemas se revelam.

Campos observados:

• Device Response Time

• Pending Time

• Channel Utilization

Exemplo clássico:

• CPU “sobrando”

• Response time alto

• 3390 com Pending elevado

👉 Solução raramente é tuning de parâmetro.
Normalmente é layout, cache, storage tier ou concorrência mal planejada.

---

⚠️ Casos clássicos discutidos no workshop

🔥 “O batch atrasou tudo”

RMF mostra:

• Batch em baixa prioridade

• Online atrasando

SMF revela:

• Batch segurando enqueue crítico

• Online esperando lock

👉 Ajuste correto:

• Revisar serialização

• Reavaliar janela batch

• Não subir prioridade às cegas

---

🔥 “Depois da mudança ficou lento”

Primeira pergunta ensinada no workshop:

Qual foi o último change?

Sem resposta clara:

• tuning suspenso

• investigação começa

📌 Lição dura:

Performance tuning não corrige change mal feito.
Ele só mascara — até piorar.

---

🚀 O que o workshop realmente forma

Não forma “tuner de parâmetro”.
Forma analista de comportamento do sistema.

Quem sai sabendo:

• Correlacionar RMF + SMF

• Defender decisão com dados

• Evitar tuning destrutivo

• Criar baseline útil

No CPD, isso vira reputação.

---

🧠 Frase final  

“RMF mostra o sintoma.
SMF mostra a causa.
WLM executa a decisão — certa ou errada.”

O Essential z/OS Performance Tuning Workshop não ensina atalhos.
Ensina responsabilidade técnica em ambiente onde erro custa caro.

 

🧾 JCL – Linha do Tempo Completa

Do cartão perfurado ao DevOps no z/OS

---

🧠 Antes do JCL (anos 1950 – início dos 60)

Contexto

• Programas rodavam em batch puro, controlados manualmente.

• Operadores plugavam cabos, montavam fitas, ajustavam switches.

• Cada sistema tinha seu próprio “jeito” de rodar jobs.

📌 Problema:
Não existia uma linguagem padrão para dizer o que rodar, quando e com quais recursos.

👉 Solução da IBM: criar uma linguagem declarativa para controlar o sistema.

---

🟦 1964 – NASCE O JCL (OS/360)

Sistema: OS/360
Hardware: IBM System/360
Evento histórico: um único SO para toda a linha de hardware.

O que surge

• JCL formalmente introduzido

• Conceitos fundamentais:

  • //JOB

  • //EXEC

  • //DD

• Sintaxe baseada em cartões perfurados

• Colunas fixas, 80 caracteres, tolerância zero a erro

📌 Impacto

• Pela primeira vez, o operador deixa de decidir tudo manualmente

• O job descreve:

  • programa

  • datasets

  • dispositivos

  • prioridade

🧨 Easter Egg histórico

Fred Brooks (IBM) disse que JCL foi uma das linguagens mais difíceis já criadas —
mas impossível de abandonar.

---

🟨 1966–1971 – JCL no DOS/360 e OS/360 amadurece

Sistemas: DOS/360, OS/360 MFT/MVT

Evolução

• Pequenas variações de JCL entre DOS e OS

• Mais parâmetros em DD

• Introdução de:

  • datasets temporários

  • concatenação

  • procedimentos simples

📌 Nota Bellacosa
Aqui nasce a primeira dor do mainframer:
👉 “Esse JCL roda no MVT mas não no DOS?”

---

🟧 1972–1974 – A Era do Virtual Storage (OS/VS → MVS)

Sistemas: OS/VS1, OS/VS2, depois MVS

O que muda no JCL

• Nada quebra (compatibilidade total)

• Mas o poder cresce:

  • mais steps

  • mais memória

  • mais jobs simultâneos

• Procedures catalogadas se tornam padrão

• JCL passa a ser infraestrutura crítica

📌 Marco invisível
O JCL deixa de ser “controle de job”
e vira linguagem de orquestração do datacenter.

---

🟥 Final dos anos 70 – JES2 / JES3

Subsistemas: JES2 e JES3

Evolução prática

• JCL começa a dialogar mais com o spool

• Controle refinado de:

  • SYSOUT

  • classes

  • prioridades

• Ambientes multi-LPAR começam a surgir

🧠 Filosofia
JCL continua simples…
mas o ambiente em volta vira um monstro.

---

🟪 Anos 80 – Estabilidade Absoluta

Sistemas: MVS/XA, MVS/ESA

O que muda

• Quase nada na sintaxe

• Muitos novos parâmetros

• JCL vira uma “linguagem fossilizada viva”

📌 Realidade
Um JCL de 1975 ainda roda.
Um COBOL também.
O estagiário não.

---

🟩 1995 – OS/390 (o JCL entra na era corporativa moderna)

Sistema: OS/390

Evolução

• Consolidação:

  • MVS

  • JES

  • DFSMS

• JCL passa a lidar fortemente com:

  • SMS

  • storage groups

  • políticas corporativas

📌 Mudança cultural
O JCL deixa de ser “do operador”
e vira ativo estratégico da empresa.

---

🟦 2000 – z/OS nasce (JCL entra no século XXI)

Sistema: z/OS 1.1

O que muda (sem quebrar nada)

• Integração com:

  • Unix System Services (USS)

  • arquivos POSIX

• JCL agora convive com:

  • shell scripts

  • Java

  • C/C++

• Melhor controle condicional

📌 Importante
Nenhum “JCL 2.0”
Nenhuma revolução sintática
👉 só evolução silenciosa.

---

🟨 2005–2015 – JCL + Automação

Novidades

• IF / THEN / ELSE / ENDIF no JCL

• Mais lógica declarativa

• Menos dependência de retorno via utilitários externos

📌 JCL começa a pensar
Não é programação…
mas já decide caminhos.

---

🟧 2016–2020 – JCL encontra o DevOps

Mudanças indiretas

• JCL versionado em Git

• Edição em VS Code (Z Open Editor)

• Integração com pipelines

• JCL analisado, validado, automatizado

🧠 Paradoxo
A linguagem mais antiga do datacenter
vira parte do pipeline moderno.

---

🟥 2020–2025 – JCL nos z/OS atuais (2.5, 3.x)

Situação atual

• JCL continua:

  • estável

  • retrocompatível

  • crítico

• Novos parâmetros continuam surgindo

• Integração com:

  • Zowe

  • APIs

  • observabilidade

  • automação corporativa

📌 Verdade absoluta
Se o JCL parar,
o banco para.
O país sente.

---

🧭 Linha do tempo resumida

Ano	Sistema	Estado do JCL
1964	OS/360	JCL nasce
1974	MVS	JCL escala
1980s	MVS/XA/ESA	JCL estabiliza
1995	OS/390	JCL corporativo
2000	z/OS	JCL moderno
2010s	z/OS	JCL condicional
2020s	z/OS 3.x	JCL + DevOps

---

☕ Comentário final (Bellacosa Mode ON)

JCL não evoluiu para agradar desenvolvedores.
Evoluiu para não quebrar o mundo.

Enquanto linguagens vêm e vão,
o JCL permanece,
silencioso, feio, poderoso
e absolutamente indispensável.

 

REXX – Introducing My New Friend

(ou: como eu parei de torcer o nariz e ganhei um aliado no z/OS e z/VM)

“Às vezes o melhor software não é o mais caro, nem o mais novo. É o que já está aí, esperando você parar de ignorar.”

Navegar pelas complexidades do z/OS e do z/VM exige um arsenal respeitável de ferramentas. JCL, COBOL, assembler, CLIST, utilitários do sistema, produtos terceiros… tudo isso faz parte do dia a dia.
Mas em muitos momentos, o tool ideal simplesmente não existe, é caro demais, ou não justifica um processo de aquisição que passa por 37 comitês, 12 reuniões e 2 meses de espera.

Foi exatamente aí que, meio a contragosto, eu resolvi sair da zona de conforto e mergulhar em uma linguagem que sempre esteve ali, silenciosa, quase invisível: REXX.

Confesso: no começo houve resistência.
“Mais uma linguagem?”
“Isso não é coisa de CLIST melhorado?”
“Será que vale o tempo?”

Spoiler: vale. E muito.
Hoje, o REXX não é só uma linguagem — é meu novo amigo no mainframe.

---

📜 1. Um breve passeio pela história das linguagens

Antes de falar de REXX, precisamos contextualizar.

Da força bruta à legibilidade

• Anos 40/50: código de máquina e Assembly — poder absoluto, legibilidade zero.

• Anos 60: COBOL, FORTRAN — produtividade e portabilidade começam a surgir.

• Anos 70: linguagens estruturadas, foco em legibilidade e manutenção.

• Anos 80: linguagens de script e automação ganham espaço.

É nesse cenário que, em 1979, na IBM, surge o REXX (Restructured Extended Executor), criado por Mike Cowlishaw.

👉 O objetivo era claro:

Criar uma linguagem simples, legível, poderosa e tolerante a erros humanos.

Nada de pontuação excessiva, nada de sintaxe críptica.
REXX foi pensado para gente, não só para compiladores.

📌 Easter egg histórico:
Mike Cowlishaw também é o criador da notação decimal usada em IEEE 754-2008. Ou seja, o homem sabia exatamente o que estava fazendo.

---

🧑‍💻 2. O papel real de sysprogs e devs no z/OS e z/VM

Quem vive mainframe sabe:
o trabalho não é só programar.

No mundo real, fazemos:

• Automação de tarefas repetitivas

• Análise de datasets e catálogos

• Interação com TSO/ISPF

• Chamada de comandos do sistema

• Tratamento de mensagens (WTO, WTOR, GETMSG)

• Integração entre ferramentas

• Prototipação rápida de soluções

• “Apagar incêndio” às 3h da manhã 🔥

E aqui vem a pergunta fatal:

Você vai fazer tudo isso em COBOL compilado?

REXX entra exatamente nesse espaço:

• Mais poderoso que CLIST

• Mais simples que COBOL

• Mais integrado que scripts externos

---

🔌 3. Integrando REXX ao seu workflow atual

REXX não substitui COBOL, PL/I ou Assembler.
Ele complementa.

Onde o REXX brilha:

• Dentro do TSO

• Em ISPF

• Em batch

• No z/VM (CMS, CP, EXECs)

• Chamando utilitários do sistema

• Orquestrando JCL

• Automatizando ambientes

📌 Easter egg prático:
Você pode chamar IDCAMS, IEFBR14, SDSF, comandos MVS e até programas COBOL diretamente do REXX.

REXX é o cola tudo do mainframe.

---

🧠 4. Fundamentos e base teórica do REXX

Filosofia da linguagem

• Tudo é string

• Tipagem dinâmica

• Sintaxe limpa

• Código próximo do inglês

• Pouca pontuação

• Muito foco em legibilidade

Exemplo simples:

say 'Hello, mainframe world!'

Sem ponto e vírgula.
Sem BEGIN/END obrigatórios.
Sem drama.

Estrutura básica

• Instruções lineares

• Controle por IF, DO, SELECT

• Funções internas riquíssimas

• Integração nativa com o ambiente

Variáveis

nome = 'Bellacosa'
say 'Bem-vindo,' nome

📌 Curiosidade:
Variáveis não inicializadas não quebram o programa.
Elas simplesmente retornam o próprio nome.
Isso é genial para debug… e perigoso se você não souber 😄

---

🧩 5. Pré-requisitos para aprender REXX

A boa notícia: poucos.

Idealmente você já conhece:

• Conceitos básicos de mainframe

• TSO/ISPF

• JCL (ao menos leitura)

• Dataset, PDS, PS, membros

• Comandos básicos do sistema

Se você sabe navegar no ISPF, já está 50% pronto.

---

🛠️ 6. REXX na prática – exemplos do mundo real

Exemplo 1 – Listar datasets

address tso "listcat level('USER01')"

Exemplo 2 – Automatizar ISPF

address ispexec "control errors return"
address ispexec "display panel(MYPANEL)"

Exemplo 3 – Batch REXX

//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSEXEC  DD DISP=SHR,DSN=USER.REXX.LIB
//SYSTSIN  DD *
  %MEUREXX
/*

📌 Easter egg avançado:
REXX pode ler e escrever datasets linha a linha com EXECIO.
Sim, você pode fazer mini-SORTs sem DFSORT.

---

🤯 7. Curiosidades que poucos contam

• REXX existe fora do mainframe (OS/2, Windows, Linux)

• É base de automação em vários produtos IBM

• Muitos produtos “enterprise” usam REXX internamente

• CLIST perdeu espaço por causa do REXX

• É uma das linguagens mais subestimadas do ecossistema IBM Z

---

☕ Conclusão – Por que REXX virou meu novo amigo

REXX não é moda.
REXX não é hype.
REXX é eficiência silenciosa.

Ele resolve problemas reais:

• rápido

• integrado

• sem burocracia

• sem custo extra

• com curva de aprendizado amigável

Se você trabalha com z/OS ou z/VM e ainda ignora o REXX, deixo o conselho de veterano:

Não subestime uma linguagem que a IBM colocou no coração do sistema.

Porque às vezes, o melhor amigo já estava no mainframe…
você só nunca tinha puxado assunto 😉

 

Bellacosa Mainframe apresenta Suporte a Produção

☕🔥 Suporte à Produção Mainframe — engenharia operacional em estado bruto

Se você já deu CANCEL com o coração na mão, já leu dump em hexadecimal, já decorou mensagem $HASP melhor que CPF, então este texto não é para iniciantes.
Aqui falamos de Produção de verdade. Sem romantização. Sem power-point bonito.

---

🧠 Suporte à Produção Mainframe ≠ Operação

É engenharia operacional sob carga real.

Produção não é:

• Rodar job

• Reiniciar STC

• Abrir chamado

Produção é:

• Análise de impacto

• Decisão em ambiente crítico

• Entendimento sistêmico do z/OS

• Correlação entre eventos aparentemente desconexos

Produção é onde o design encontra a realidade — e geralmente perde.

---

🕰️ Raiz Histórica (para quem veio do MVS, não do YouTube)

O Suporte à Produção nasce quando:

• O batch deixou de ser “linear”

• O online passou a ser 24x7

• O negócio começou a depender de janela de processamento

• O erro deixou de ser aceitável

A evolução foi clara:

• Operador de console →

• Analista de Produção →

• Especialista em estabilidade operacional

Hoje, Produção é a última linha de defesa entre o z/OS e o prejuízo financeiro.

---

🎯 Objetivo Real do Suporte à Produção (versão sem marketing)

• Garantir throughput, não apenas execução

• Controlar contenção, não apenas erro

• Preservar integridade transacional

• Manter SLA, RTO e RPO

• Atuar antes do incidente virar crise

☕ Veterano sabe:

Produção não corrige código — corrige efeito colateral.

---

🧩 Arquitetura de Conhecimento (o que separa júnior de veterano)

🖥️ z/OS — domínio do núcleo

• JES2/JES3, initiators, classes, priorities

• Spool contention

• ENQ/DEQ, RESERVE, latch

• WTOR, automation hooks

• Dumps SVC vs SYSMDUMP

🔥 Apimentado:
Quem não entende JES não entende produção.

---

🧠 CICS — transação é sagrada

• Task Control

• Storage violation

• Transaction isolation

• Deadlock silencioso

• Dumps DSNAP / CEEDUMP

☕ El Jefe truth:

CICS não cai — ele sangra em silêncio.

---

📬 MQ — quando o assíncrono vira gargalo

• Depth x High/Low Threshold

• Channels retrying

• Poison message

• Commit vs rollback

• Impacto no batch e no online

🔥 Easter egg:
Fila cheia é sintoma, não causa.

---

🔌 Integration Bus (Broker)

• Flow degradation

• Message backlog

• XML/JSON parsing cost

• CPU vs I/O trade-off

• Propagação de erro invisível

☕ Fofoquice técnica:
Quando o Broker falha, todo mundo aponta para o mainframe.

---

🧪 REXX — automação tática

• Monitoramento ativo

• Ações condicionais

• Coleta de evidência

• Resposta automática a eventos

• Integração com SDSF, consoles e logs

🔥 Produção sem REXX é operação cega.

---

🗄️ DB2 Utilities — o campo minado

• REORG mal planejado

• RUNSTATS atrasado

• Lock escalation

• Deadlock intermitente

• Log pressure

☕ Frase clássica:

“Não mexe agora… deixa rodar.”

---

🌐 WebSphere / Acesso Remoto

• JVM pressure

• Thread starvation

• Timeout mascarado

• Latência invisível

• Cascata de falhas

🔥 Curiosidade:
O Web cai rápido. O mainframe aguenta a culpa.

---

🔍 Funcionamento Real em Produção (sem filtro)

1. Sintoma aparece longe da causa

2. Métrica parece normal

3. SLA corre

4. Dump gerado

5. Análise cruzada (JES + CICS + DB2 + MQ)

6. Decisão com risco calculado

7. Execução mínima, impacto máximo

8. Ambiente estabiliza

9. Post-mortem técnico

10. Documentação (que ninguém lê… até precisar)

---

🧠 Mentalidade do Veterano

✔️ Não confia em “achismo”
✔️ Não executa comando sem rollback mental
✔️ Pensa em efeito dominó
✔️ Prefere degradar a parar
✔️ Sabe quando não agir

☕🔥 Regra de ouro:

Em Produção, o comando mais perigoso é o que “sempre funcionou”.

---

🥚 Easter Eggs de Produção

• Todo ambiente tem um job que “ninguém encosta”

• Sempre existe um dataset com DISP=SHR que não deveria

• Todo incidente grave começa com:

  “Isso nunca aconteceu antes…”

• O melhor analista é o que não aparece no incidente report

---

🧨 Conclusão — El Jefe Midnight Lunch Manifesto

Suporte à Produção Mainframe é:

• Arquitetura viva

• Engenharia sob estresse

• Decisão sem margem de erro

• Responsabilidade sem aplauso

Não é glamour.
Não é palco.
É confiança operacional.

☕🔥 Se você já sobreviveu a uma madrugada de produção,
você sabe:

Produção não ensina — ela seleciona.

 

📌 O que é JCL (visão geral)

 

.

---

📌 O que é JCL (visão geral)

• JCL — Job 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íodo	Plataforma/Release	Principais mudanças no JCL
~1964–67	OS/360 / DOS/360	Introdução da JCL, JOB/EXEC/DD básicos, batch streams. Grokipedia
Anos 1970	MVS (OS/VS2 → MVS)	Virtual storage, procedures catalogadas, expansão de parâmetros. Wikipedia
1995	OS/390	Consolidaçã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.