🧾 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.

📌 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. 

 

Bellacosa Mainframe apresenta JCL Job Control Language

☕🔥 JCL & Produção Batch Mainframe — a engenharia silenciosa que move bilhões 

Se você já otimizou STEP para caber na janela, já analisou RC 0004 com cara de 0012, já salvou processamento crítico com um COND= bem colocado, então este texto não é introdutório.
É JCL raiz, técnico, com cheiro de CPD, café requentado e responsabilidade financeira.

---

🕰️ Origem & História — por que o JCL ainda governa o mundo

O JCL (Job Control Language) nasce junto com o conceito de processamento em lote nos grandes centros de dados, quando:

• Processar tudo “online” era inviável

• O custo de CPU precisava ser controlado

• O erro precisava ser detectável, tratável e auditável

Enquanto linguagens vêm e vão, o JCL ficou porque:

• É determinístico

• É declarativo

• É governável

• É auditável

☕ Verdade histórica:

Toda fintech moderna ainda depende de batch — só não admite.

---

🏦 Por que bancos, telecom e gigantes globais usam Mainframe

Empresas que processam milhões de transações críticas exigem:

• Alta disponibilidade (24x7)

• Integridade absoluta

• Escalabilidade previsível

• Segurança nativa

• Throughput sob pico

A Plataforma IBM Mainframe entrega:

• Sysplex

• Parallel Sysplex

• z/OS

• DB2, CICS, MQ

• RACF, SMF, RMF

🔥 El Jefe truth:

Cloud escala. Mainframe sustenta.

---

🧠 JCL não é script — é contrato operacional

JCL define:

• O que roda

• Quando roda

• Com quais recursos

• Com quais dados

• O que acontece se falhar

Ele não executa lógica de negócio.
Ele orquestra o sistema operacional.

📌 Exemplo clássico:

//STEP01 EXEC PGM=PROG01,COND=(4,LT)
//DD01  DD DSN=BASE.DADOS.ENTRADA,DISP=SHR

☕ Comentário ácido:

JCL errado não falha — impacta.

---

⚙️ Funcionamento do Processamento Batch

Fluxo real:

1. Job submetido

2. JES valida sintaxe

3. Initiator seleciona

4. Recursos alocados

5. Programas executam

6. RC avaliados

7. Próximo STEP decide

8. Output gerado

9. SLA confirmado ou perdido

🔥 Veterano sabe:

O problema raramente está no STEP que abendou.

---

🧩 Ecossistema Operacional — as ferramentas de poder

🧑‍💻 TSO — o shell do z/OS

• Execução direta

• Diagnóstico rápido

• REXX, CLIST, comandos

☕ Curiosidade:

Quem domina TSO resolve problema sem ticket.

---

🗂️ ISPF/PDF — produtividade industrial

• Editor poderoso

• Gestão de datasets

• Browse inteligente

• Macros

🔥 Easter egg:

PF7 e PF8 são memória muscular.

---

📊 SDSF — o raio-X da produção

• Jobs

• STCs

• Spool

• Syslog

• Comandos

📌 Uso clássico:

SDSF DA / ST / H

☕ Verdade dura:

SDSF é onde a verdade aparece.

---

🧪 JCL na prática — decisões de veterano

COND vs IF/THEN/ELSE

• COND = simples e perigoso

• IF/THEN = legível e controlável

🔥 Regra de produção:

COND errado roda STEP que não deveria.

---

Alocação de Recursos

• DISP

• SPACE

• UNIT

• VOL

☕ Fofoquice técnica:

DISP=SHR mal usado já derrubou banco.

---

Tratamento de Erros

• RC esperado ≠ sucesso

• RC aceitável ≠ erro

• Abend ≠ falha total

📌 Exemplo:

// IF (STEP01.RC <= 4) THEN

---

🛠️ Utilitários do Sistema — os bastidores

• IEBGENER

• IDCAMS

• SORT / ICETOOL

• IEBCOPY

• DFSORT

🔥 Veterano:

Quem domina utilitário domina batch.

---

🧠 Lógica Estruturada aplicada ao Batch

Mesmo sem “programar”:

• Sequência

• Decisão

• Repetição (simulada)

• Modularização por STEP

☕ Comentário ácido:

JCL ruim é código espaguete sem goto.

---

🧨 Atividades Operacionais & de Análise

Produção batch exige:

• Leitura de mensagens

• Análise de dumps

• Correlação entre jobs

• Impacto em cadeia

• Comunicação com negócio

🔥 Verdade cruel:

Produção não tem replay.

---

🥚 Easter Eggs & Curiosidades do Batch

• Todo ambiente tem um job “imortal”

• Sempre existe um dataset “temporário” de 10 anos

• O maior medo é:

  “Rodou fora da janela…”

• RC 0000 nem sempre é vitória

---

☕🔥 Conclusão — Manifesto El Jefe Batch

JCL não é:

• Legado morto

• Linguagem simples

• Detalhe operacional

JCL é:

• Coluna vertebral do processamento corporativo

• Contrato de execução

• Instrumento de controle de risco

☕🔥 Quem domina JCL,
não escreve jobs —
governa o processamento de dados.

Se quiser, posso:

• Criar labs de produção real

• Montar checklist de análise de jobs

• Criar guia JCL para veteranos

• Produzir versão acadêmica ou institucional

• Montar trilha Batch + JCL + SDSF + RACF

É só chamar.

 

Bellacosa Mainframe o que é PROC em Job JCL

O que é PROC no JCL?

Quando começamos a trabalhar com JCL em ambientes corporativos, rapidamente encontramos algo muito importante:

PROC

Ela é uma das estruturas mais usadas em produção no z/OS.

Praticamente todo ambiente mainframe grande utiliza:

• PROCs;

• bibliotecas PROC;

• variáveis simbólicas;

• JCL reutilizável.

---

O que significa PROC?

PROC significa:

Procedure

Em português:

procedimento reutilizável.

---

Definição simples

Uma PROC é:

um JCL reutilizável.

Ela permite:

• evitar repetição;

• padronizar execução;

• facilitar manutenção;

• reutilizar STEPs.

---

Analogia simples

Imagine uma receita pronta.

Em vez de escrever toda a receita novamente:

• você reutiliza o modelo;

• apenas troca alguns ingredientes.

PROC funciona exatamente assim.

---

Problema que PROC resolve

Imagine uma empresa com:

• 500 JOBs;

• todos executando SORT;

• DB2;

• backup;

• mesmas etapas.

Sem PROC:

• muito JCL duplicado;

• manutenção difícil;

• alto risco operacional.

---

Então surgiu a PROC

Ela permite:

centralizar lógica JCL.

---

Exemplo sem PROC

//STEP1 EXEC PGM=SORT
//SORTIN DD ...
//SORTOUT DD ...
//SYSIN DD ...

Repetido centenas de vezes.

---

Exemplo com PROC

//STEP1 EXEC PROC=SORTPROC

Muito mais simples.

---

Onde a PROC fica?

Normalmente em:

bibliotecas PROC.

Exemplo:

SYS1.PROCLIB

ou:

USUARIO.PROCLIB

---

Como o sistema encontra PROC?

Usando:

JCLLIB

ou bibliotecas configuradas no JES2.

---

Estrutura básica de PROC

---

Exemplo simples

//MINHAPRC PROC
//STEP1   EXEC PGM=IEFBR14
//PEND

---

Entendendo

---

PROC

Início da procedure.

---

PEND

Fim da procedure.

---

Como usar PROC?

No JOB:

//STEP1 EXEC PROC=MINHAPRC

---

Fluxo simples

JOB
 ↓
EXEC PROC
 ↓
JES2 expande PROC
 ↓
EXECUÇÃO

---

O que significa “expandir PROC”?

O JES2 substitui:

EXEC PROC

pelo conteúdo real da PROC.

---

O usuário vê isso?

Sim.

No spool:

JESJCL

mostra o JCL expandido.

---

O que são variáveis simbólicas?

Um dos recursos mais importantes das PROCs.

Também chamadas:

symbolic parameters.

---

Elas funcionam como variáveis

Permitem alterar:

• datasets;

• programas;

• parâmetros;

• classes;

• SYSOUT.

Sem alterar a PROC original.

---

Exemplo simples

//MINHAPRC PROC ARQ=CLIENTES
//STEP1 EXEC PGM=MEUPGM
//INPUT DD DSN=&ARQ,
//      DISP=SHR
//PEND

---

O que significa "&ARQ"?

Variável simbólica.

---

Como usar?

//STEP1 EXEC PROC=MINHAPRC,
//       ARQ=PRODUCAO.CLIENTES

---

Resultado expandido

//INPUT DD DSN=PRODUCAO.CLIENTES

---

Isso é extremamente poderoso

Porque permite:

• reutilização;

• flexibilidade;

• padronização.

---

Variáveis mais comuns

---

Dataset

&DSN

---

Classe

&CLASS

---

Programa

&PGM

---

SYSOUT

&OUT

---

Exemplo profissional

//COBPROC PROC PGM=COBPGM,
//             IN=CLIENTE.ARQ,
//             OUT=RELAT.SAIDA
//STEP1 EXEC PGM=&PGM
//INPUT DD DSN=&IN,DISP=SHR
//OUTPUT DD DSN=&OUT,
// DISP=(NEW,CATLG,DELETE)
//PEND

---

Chamada

//STEP1 EXEC PROC=COBPROC,
// PGM=FINANCE,
// IN=FINAN.ENTRADA,
// OUT=FINAN.SAIDA

---

O que é PROC catalogada?

PROC armazenada em:

PROCLIB.

Mais comum em produção.

---

O que é PROC inline?

PROC escrita dentro do próprio JOB.

---

Exemplo inline

//MINHA PROC
//STEP1 EXEC PGM=IEFBR14
//PEND
//
//JOB1 EXEC MINHA

---

Vantagens da PROC

---

Reutilização

---

Padronização

---

Menos erros

---

Manutenção centralizada

---

Menos duplicação

---

Muito usada em produção

---

O que é override?

Alterar parâmetros da PROC no JOB.

---

Exemplo

PROC:

//STEP1 EXEC PGM=COBOL

JOB:

//STEP1.STEP1 EXEC PGM=TESTE

---

Isso substitui o EXEC original

---

O que é nested PROC?

PROC chamando outra PROC.

Muito usado em ambientes grandes.

---

O que é JCLLIB?

Define bibliotecas PROC.

---

Exemplo

//JCLLIB JCLLIB ORDER=USUARIO.PROCLIB

---

O que acontece se PROC não for encontrada?

Erro no JESJCL.

Exemplo:

PROC NOT FOUND

---

Curiosidades incríveis

1. Grandes bancos possuem milhares de PROCs

---

2. Muitas automações batch dependem delas

---

3. Algumas PROCs existem há décadas

---

4. PROCs ajudam muito em padronização operacional

---

Erros comuns de iniciantes

---

1. Esquecer PEND

Erro clássico.

---

2. Variável simbólica incorreta

Exemplo:

&ARQ

não definida.

---

3. PROC não encontrada

Problema de PROCLIB.

---

4. Override errado

Pode alterar execução sem perceber.

---

Dicas importantes

Sempre use nomes claros

---

Padronize variáveis

---

Leia JESJCL expandido

---

Use PROC para lógica repetitiva

---

Como PROC aparece no dia a dia?

Praticamente em tudo:

• COBOL;

• DB2;

• SORT;

• backups;

• produção batch;

• automação.

---

Por que aprender PROC?

Porque PROC é:

uma das estruturas mais importantes do JCL corporativo.

Quem domina PROC entende:

• automação batch;

• reutilização JCL;

• produção z/OS;

• arquitetura operacional.

---

Resumo rápido

Conceito	Significado
PROC	JCL reutilizável
PEND	Final da PROC
Symbolic Parameter	Variável JCL
PROCLIB	Biblioteca de PROC
Override	Substituição de parâmetro
Inline PROC	PROC dentro do JOB
Cataloged PROC	PROC em biblioteca

---

Conclusão

PROC é um dos recursos mais poderosos do JCL no ambiente z/OS.

Ela permite reutilizar etapas batch, padronizar processamento e criar JOBs flexíveis usando variáveis simbólicas, sendo fundamental para operações corporativas em mainframe IBM Z.