sábado, 8 de janeiro de 2011

🔥 JCL no z/OS V1R1 — quando o “antigo” ganhou sobrenome moderno

Bellacosa Mainframe apresenta JCL Job Control Language

🔥 JCL no z/OS V1R1 — quando o “antigo” ganhou sobrenome moderno

📅 Datas importantes

Release (GA): outubro de 2000
Final de suporte (EoS/EoM): entre 2004 e 2005 (dependendo do nível de suporte IBM e migração para V1R2+)

O z/OS V1R1 marcou oficialmente a transição do OS/390 para z/OS, e o JCL veio junto — o mesmo DNA dos anos 60, agora rodando num sistema “novo em folha”.

🧬 Contexto histórico

Quando a IBM lançou o z/OS V1R1, o JCL já era um veterano respeitado. Ele não nasceu no z/OS — nasceu lá atrás, no OS/360 (1964) — mas sobreviveu a tudo: MVT, MVS, ESA, OS/390… e chegou ao z/OS sem pedir licença.

O que muda aqui não é a linguagem, mas o ambiente, o poder da máquina, a integração com UNIX System Services, TCP/IP nativo e workloads híbridos.

👉 Moral da história:

“Troca o sistema, troca o nome, troca o marketing… mas o JCL continua mandando no turno da noite.”

JCL V1R1

✨ O que há de “novo” no JCL do z/OS V1R1

Tecnicamente, o JCL é compatível para trás, mas o z/OS V1R1 trouxe melhorias indiretas importantes:

🆕 1. Integração total com o z/OS

JCL agora orquestra:
- Batch tradicional
- Utilitários do DFSMS
- Programas que acessam USS (OMVS)
- Processos ligados a TCP/IP e middleware

🆕 2. JES2/JES3 mais maduros

Melhor gerenciamento de:
- Spool
- Classes
- Prioridades
- Restart de jobs

🆕 3. DFSMS mais forte

JCL passa a explorar melhor:
- SMS-managed datasets
- Storage Groups
- Management Classes
- Data Classes

👉 O JCL continua simples, mas o ecossistema ao redor ficou muito mais poderoso.

🔧 Melhorias e mudanças percebidas no dia a dia

✔ Melhor estabilidade no processamento batch
✔ Melhor convivência entre online (CICS) e batch
✔ Menos “abend misterioso” por problemas de storage
✔ Maior previsibilidade de execução noturna

Nada de comandos novos mirabolantes — o ganho foi operacional.

🥚 Easter Eggs (para mainframer raiz)

🥚 JCL que funcionava no OS/390 funcionava igual no z/OS V1R1
Isso facilitou migrações gigantes sem reescrever milhares de jobs.
🥚 Muitos shops migraram para z/OS sem mudar uma linha de JCL
Só recompilaram programas e ajustaram SMS.
🥚 O //STEPLIB DD * continuava sendo usado… mesmo sendo má prática 😅

💡 Dicas Bellacosa para quem viveu (ou estuda) essa época

🔹 Aprenda JCL como linguagem de orquestração, não só como “script batch”
🔹 Entenda bem:

DISP
SPACE
UNIT
COND vs IF/THEN/ELSE
🔹 Leia syslog e JESMSGLG como quem lê log de produção moderna
🔹 Lembre-se:

JCL errado não falha — ele executa errado.

📈 Evolução a partir do V1R1

Depois do z/OS V1R1, o JCL seguiu firme:

V1R3+ → IF/THEN/ELSE mais usado
V1R6+ → Melhor integração com ferramentas modernas
V2.x → JCL convivendo com DevOps, schedulers e automação

Mas a base?
👉 Exatamente a mesma.

📜 Exemplo clássico de JCL (estilo raiz)

//BELLJOB  JOB (ACCT),'BELLACOSA',CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=IEFBR14
//OUTFILE  DD  DSN=BELLACOSA.TESTE.JCL,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(TRK,(1,1)),
//             UNIT=SYSDA

💬 Comentário Bellacosa:

“Se você entende esse JCL, você entende 70% do batch do mainframe.”

🧑‍🔧O que é DFSMS?

Na verdade, o DFSMS (Data Facility Storage Management Subsystem) não é apenas um utilitário único, mas sim uma suíte poderosa de componentes da IBM para o ambiente z/OS.

Em termos simples: ele é o "gerente de logística" do seu mainframe. Ele automatiza e centraliza a gestão de onde os dados são gravados, por quanto tempo ficam guardados e como são protegidos.

Os 4 Pilares do DFSMS

Para entender o DFSMS no dia a dia do JCL, é preciso conhecer seus principais componentes:

DFSMSdfp (Data Facility Product): O coração do sistema. Gerencia o acesso aos dados e a movimentação básica. É aqui que mora o famoso utilitário IDCAMS.
DFSMSdss (Data Sets Services): Focado em cópia, movimentação e backup de alta performance. O programa principal chamado via JCL é o ADRDSSU.
DFSMShsm (Hierarchical Storage Manager): Responsável por "limpar a casa". Ele migra dados pouco usados para mídias mais baratas (como fita ou discos lentos) e faz o backup automático.
DFSMSrmm (Removable Media Manager): Gerencia suas fitas (físicas ou virtuais), controlando quem pode usá-las e quando podem ser apagadas.

Como ele aparece no seu JCL?

No passado, você precisava dizer exatamente em qual disco (UNIT e VOL=SER) seu arquivo deveria morar. Com o DFSMS (especificamente o componente SMS), o sistema faz isso sozinho através de três parâmetros principais no comando DD:

DATACLAS (Data Class): Define os atributos físicos (organização, formato de registro, tamanho).
STORCLAS (Storage Class): Define o nível de serviço (em qual disco ele vai morar, se precisa ser um disco rápido ou SSD).
MGMTCLAS (Management Class): Define o "prazo de validade" (quando o HSM deve deletar ou migrar o arquivo para fita).

Exemplo de DD com SMS:

Snippet de código

//ARQUIVO  DD DSN=USER.TESTE.DADOS,
//            DISP=(NEW,CATLG,DELETE),
//            DATACLAS=DCPADRAO,
//            STORCLAS=SCFAST,
//            MGMTCLAS=MGT030D

🛠️ Principais Utilitários que você usará

Se você está procurando o "programa" para rodar, os mais comuns vinculados ao DFSMS são:

Utilitário	Para que serve?
IDCAMS	Criar, deletar, listar e gerenciar VSAM e catálogos.
ADRDSSU	Copiar volumes inteiros ou datasets específicos em alta velocidade.
IEBCOPY	(Gerenciado pelo DFP) para copiar e comprimir bibliotecas (PDS/PDSE).

🧠 Comentário final

O JCL no z/OS V1R1 prova uma verdade que todo mainframer aprende cedo:

Tecnologia boa não morre — ela evolui sem fazer barulho.

Enquanto linguagens vêm e vão, o JCL segue lá, silencioso, confiável, rodando milhões de jobs por noite…
…e garantindo que o mundo acorde com banco, energia, avião e folha de pagamento funcionando.

🔥 Longa vida ao JCL.

El Jefe Midnight Lunch

sábado, 8 de janeiro de 2011