Translate

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

terça-feira, 28 de abril de 2026

💣🔥 LAB DFSMS COMPLETO — DO DATASET À POLÍTICA

 

Bellacosa Mainframe treinando em storage mainframe

💣🔥 LAB DFSMS COMPLETO — “DO DATASET À POLÍTICA”

🎯 OBJETIVO

Você vai:

  • Criar Data Class, Storage Class, Management Class
  • Definir ACS routines
  • Alocar dataset via JCL
  • Validar via ISPF/ISMF
  • Simular comportamento real

🧱 PARTE 1 — CRIAR DATA CLASS

No ISMF:

Option 3 → Data Class

📌 Definição:

Data Class Name  ===> LABDATA
Description ===> LAB FB 80

DSORG ===> PS
RECFM ===> FB
LRECL ===> 80
BLKSIZE ===> 800

Primary ===> 5 CYL
Secondary ===> 2 CYL

💣 Isso define o DNA do dataset


⚡ PARTE 2 — STORAGE CLASS

Option 4 → Storage Class
Name             ===> LABFAST
Description ===> HIGH PERF LAB
Performance ===> HIGH

💣 Aqui você está dizendo:
👉 “Esse dado precisa ser rápido”


🔁 PARTE 3 — MANAGEMENT CLASS

Option 5 → Management Class
Name             ===> LABMC
Description ===> LAB POLICY

Backup ===> DAILY
Expire ===> 030 DAYS

Migration:
ML1 ===> 02 DAYS
ML2 ===> 05 DAYS

💣 Aqui você controla:

  • Vida útil
  • Backup
  • Migração

🗂️ PARTE 4 — STORAGE GROUP

Option 6 → Storage Group
Name             ===> LABSG
Type ===> POOL

Volumes:
VOL001
VOL002

💣 Pool de discos → onde tudo vai parar fisicamente


🧠 PARTE 5 — ACS ROUTINE (CORAÇÃO)

Option 7 → ACS ROUTINES

📌 STORAGE CLASS ACS

IF &HLQ = 'LAB'
THEN SET &STORCLAS = 'LABFAST'
ELSE
SET &STORCLAS = 'STANDARD'

📌 MANAGEMENT CLASS ACS

IF &HLQ = 'LAB'
THEN SET &MGMTCLAS = 'LABMC'

📌 DATA CLASS ACS

IF &HLQ = 'LAB'
THEN SET &DATACLAS = 'LABDATA'

💣 Aqui acontece a mágica:

👉 Você não escolhe nada no JCL
👉 O sistema decide automaticamente


⚔️ PARTE 6 — JCL REAL

//LABJOB   JOB  (ACCT),'LAB DFSMS',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=LAB.TEST.FILE,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(5,2)),
// UNIT=SYSDA

💣 Note:

❌ Nenhuma class foi especificada
👉 ACS vai decidir tudo


🔍 PARTE 7 — VALIDAR NO ISPF

Use:

3.4 → Data Set List Utility

Verifique:

  • Data Class aplicada ✅
  • Storage Class correta ✅
  • Management Class ativa ✅

🔥 PARTE 8 — TESTE REAL

💥 Teste 1 — Mudar HLQ

DSN=TEST.FILE

👉 Resultado esperado:

  • Não pega LAB classes
  • Cai no default

💥 Teste 2 — Simular erro

Altere ACS:

SET &STORCLAS = 'INVALID'

👉 Resultado:

  • Falha de alocação 💣
  • Excelente para aprendizado

🚀 PARTE 9 — SIMULAÇÃO HSM (MENTAL)

Com o tempo:

Dia 0 → criado
Dia 2 → ML1
Dia 5 → ML2 (fita)
Dia 30 → deletado

💣 Isso é automático via Management Class


⚔️ PARTE 10 — CENÁRIO REAL

Banco cria dataset LAB.PAYROLL
→ ACS aplica FAST + BACKUP
→ Dados usados
→ Após dias → migra
→ Auditoria exige restore
→ HSM recupera

🧠 CHECKLIST FINAL

Se você fez tudo:

✅ Criou classes
✅ Programou ACS
✅ Rodou JCL
✅ Validou resultado
✅ Entendeu ciclo de vida


💣 FRASE FINAL (NÍVEL PRODUÇÃO)

“Se você controla o ACS…
você controla o destino de todos os dados do sistema.”



quarta-feira, 22 de abril de 2026

💣 SEU COBOL NÃO É LENTO — SEU STORAGE É QUE DECIDE O DESTINO DO JOB

 

Bellacosa Mainframe apresenta Storage para DEV Cobol

💣 SEU COBOL NÃO É LENTO — SEU STORAGE É QUE DECIDE O DESTINO DO JOB

Um papo direto com quem já escreveu milhões de linhas em COBOL…
mas talvez nunca tenha olhado o storage como o verdadeiro protagonista.


☕ Introdução — o erro que ninguém te contou

Você já viu isso:

  • Job que ontem rodava em 5 minutos… hoje leva 40
  • Batch que “do nada” começa a gargalar
  • VSAM “misteriosamente” lento
  • DB2 com I/O explodindo

E alguém diz:

“É o programa.”

Não.
Na maioria das vezes… é o storage.


🧠 CAPÍTULO 1 — Antes do disco… existia o tempo físico

🧾 Cartão perfurado: o primeiro “storage”

Antes de DASD, antes de tape…
o dado era literalmente um buraco no papel.

  • Cada linha COBOL → um cartão
  • Ordem física → lógica do programa
  • Caiu no chão? 💣 acabou o sistema

💡 Insight:

O primeiro “bug” da história era… baralho embaralhado.


🎞️ CAPÍTULO 2 — Tape: o começo do streaming

📼 Fita magnética — o avô do Big D

Tape trouxe algo revolucionário:

  • Processamento sequencial
  • Grandes volumes
  • Backup antes de existir “backup”

👉 E aqui nasce o conceito que você usa até hoje:

Batch

💡 Curiosidade:

  • Tape ODEIA parar
  • Se parar → “shoe-shining” (vai e volta igual fita cassete)

💿 CAPÍTULO 3 — Disco: quando o acesso ficou inteligente

🏢 DASD (Direct Access Storage Device)

Aqui muda o jogo:

  • Acesso direto (não sequencial)
  • Surge VSAM
  • Surge CICS
  • Surge DB2

👉 Você para de ler tudo… e passa a ler o que precisa

💡 Insight COBOL:

READ NEXT virou READ KEY


⚡ CAPÍTULO 4 — Flash: o fim da mecânica

🔥 SSD no mundo enterprise

Sem disco girando
Sem braço mecânico
Sem latência física relevante

👉 Resultado:

  • I/O quase instantâneo
  • Batch acelera absurdamente
  • DB2 muda comportamento

💡 Insight crítico:

Flash não melhora programa ruim…
ele expõe arquitetura ruim


🚀 CAPÍTULO 5 — NVMe: paralelismo bruto

Aqui não é mais “rápido”…
é outro modelo mental.

  • I/O paralelo massivo
  • Filas simultâneas
  • CPU quase não espera

👉 No mainframe:

O gargalo deixa de ser storage… e vira desenho da aplicação


🔌 CAPÍTULO 6 — O segredo que poucos entendem: I/O NÃO É CPU

🧠 Como o z/OS realmente funciona

No mundo distribuído:

  • CPU faz tudo

No mainframe:

  • CPU manda
  • Channel executa
  • Storage responde

👉 Resultado:

Seu COBOL NÃO faz I/O… ele pede I/O

💡 Easter egg:

  • EXCP → você acha que controla tudo
  • Mas quem manda mesmo é o Channel Subsystem

🧬 CAPÍTULO 7 — RAID: onde mora o risco invisível

Você nunca configurou RAID no COBOL…
mas ele define seu tempo de execução.

  • RAID 5 → barato, mais lento
  • RAID 10 → caro, extremamente rápido
  • RAID 6 → seguro, mais pesado

💣 Verdade dura:

RAID errado = gargalo invisível


🧠 CAPÍTULO 8 — SMS: o cérebro invisível

Aqui está o ponto mais ignorado por dev:

SMS decide onde seu dado vai viver

  • Storage Class → performance
  • Management Class → lifecycle
  • Data Class → formato

👉 Você escreve:

OPEN INPUT ARQUIVO

👉 Mas quem decide:

  • Disco?
  • Flash?
  • Tape?

💡 Insight:

Você não controla o storage…
você negocia com ele


📦 CAPÍTULO 9 — Tape moderno: o sobrevivente

Tape não morreu.

Ele virou:

  • Backup
  • Archive
  • Compliance
  • Air gap (anti-ransomware)

💡 Insight:

Quando tudo falha…
é o tape que salva


🤖 CAPÍTULO 10 — Cartridge + robô = escala

  • Cartucho = mídia
  • Drive = leitura
  • Robô = automação

👉 Você pede dataset
👉 Um robô físico movimenta o dado

Sim… existe um braço robótico trabalhando pro seu JCL


🧊 CAPÍTULO 11 — Air Gap: o último nível

  • Offline
  • Fora da rede
  • Intocável

👉 Nem hacker… nem erro humano alcança


💣 CAPÍTULO FINAL — A verdade que muda tudo

Você achava que:

“Programa define performance”

Mas na prática:

  • Storage define latência
  • RAID define risco
  • SMS define localização
  • Tape define sobrevivência

☕ Bellacosa-style conclusão

“COBOL executa regra de negócio…
mas é o storage que decide se ela chega a tempo.”

 

💣 LAB MASTER 🔥 Storage Não Armazena — Ele Decide o Destino do Dado

 

Bellacosa Mainframe Treine Storage Mainframe

💣 LAB MASTER

🔥 Storage Não Armazena — Ele Decide o Destino do Dado


🎯 Objetivo do LAB

Ao final você será capaz de:

  • Entender como o SMS decide storage
  • Criar datasets com e sem striping
  • Simular impacto de RAID (conceitual)
  • Trabalhar com DASD vs Tape
  • Ver migração automática (HSM ML1/ML2)
  • Executar backup e restore
  • Entender o papel do air gap

🏗️ Cenário

Você é responsável por:

  • Um ambiente com:
    • DASD (disco)
    • Flash (simulado via classe)
    • Tape (ML2)
  • Workloads:
    • Batch pesado
    • Dados críticos
    • Arquivos de archive

🧪 LAB 1 — Alocação sem SMS (controle manual)

🎯 Objetivo

Sentir o “mundo antigo”

//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USER.TEST.MANUAL,
// DISP=(NEW,CATLG),
// UNIT=3390,
// SPACE=(CYL,(10,5))

🧠 O que observar:

  • Você escolhe tudo manualmente
  • Sem inteligência

🧪 LAB 2 — Alocação com SMS

🎯 Objetivo

Ver o SMS em ação

//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USER.TEST.SMS,
// DISP=(NEW,CATLG),
// DATACLAS=STANDARD,
// STORCLAS=FAST,
// MGMTCLAS=BACKUP

🧠 O que observar:

  • Nenhum volume definido
  • SMS decide tudo

🧪 LAB 3 — Striping (performance)

🎯 Objetivo

Simular I/O paralelo

👉 Criar Data Class com:

  • Stripe Count = 4
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USER.TEST.STRIP,
// DISP=(NEW,CATLG),
// DATACLAS=STRIPE4

🧠 Observe:

  • Dataset distribuído
  • Performance maior

🧪 LAB 4 — RAID (conceitual via comportamento)

🎯 Objetivo

Entender impacto sem ver RAID direto

Teste:

  • Dataset pequeno vs grande
  • Com e sem striping

👉 Analise:

  • Tempo de execução
  • I/O count

💡 Insight:

RAID está por baixo — você vê o efeito, não a configuração


🧪 LAB 5 — Tape (gravação)

🎯 Objetivo

Gravar em fita

//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=USER.TEST.SMS,DISP=SHR
//SYSUT2 DD DSN=USER.TEST.TAPE,
// DISP=(NEW,CATLG),
// UNIT=TAPE,
// VOL=SER=TAPE01

🧠 Observe:

  • Acesso sequencial
  • Tempo maior


Bellacosa Mainframe apresenta leitor cartrige com braço robotico

🧪 LAB 6 — HSM (migração automática)

🎯 Objetivo

Ver dados indo para tape

Comando:

HSEND MIGRATE DATASET('USER.TEST.SMS')

🧠 Resultado:

  • ML1 → disco
  • ML2 → tape

Bellacosa Mainframe apresenta antigo leitor tape para mainframe mvs 

🧪 LAB 7 — Recall (volta do tape)

//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=USER.TEST.SMS,DISP=SHR

🧠 Observe:

  • Dataset volta do tape
  • Delay perceptível

🧪 LAB 8 — Backup

🎯 Objetivo

Criar cópia de segurança

//STEP1 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//DUMP DD DSN=USER.BACKUP.TAPE,
// UNIT=TAPE,
// DISP=(NEW,CATLG)
//SYSIN DD *
DUMP DATASET(USER.TEST.SMS) -
OUTDD(DUMP)
/*

🧪 LAB 9 — Simulação de desastre

🎯 Objetivo

Recuperação

//STEP1 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//DUMP DD DSN=USER.BACKUP.TAPE,DISP=SHR
//SYSIN DD *
RESTORE DATASET(USER.TEST.SMS) -
INDD(DUMP)
/*

🧪 LAB 10 — Air Gap (conceito aplicado)

🎯 Objetivo

Entender proteção real

👉 Cenário:

  • Dataset corrompido
  • Backup online comprometido

👉 Recuperação:

  • Apenas via tape

💡 Insight:

Aqui você entende por que tape ainda existe


🧠 Fechamento técnico

Você acabou de trabalhar com:

  • DASD (3390)
  • SMS (policy-driven storage)
  • Striping (performance)
  • RAID (efeito indireto)
  • Tape (sequencial)
  • HSM (automação)
  • Backup/Restore
  • Air Gap (segurança real)

☕ Bellacosa-style conclusão

“Você não manipulou disco…
você manipulou decisões sobre onde o dado vive, se move… e sobrevive.”

 

segunda-feira, 12 de janeiro de 2026

🧠 O que é HSM e DFSMShsm no IBM Mainframe z/OS

 

Bellacosa Mainframe apresenta o HSM e DFSMS

Um Café no Bellacosa Mainframe – HSM: o zelador invisível do z/OS


🧠 O que é HSM e DFSMShsm no IBM Mainframe z/OS

(ou: quem realmente manda nos seus discos enquanto você dorme)

Se você trabalha com IBM Mainframe z/OS e acha que HSM é só “backup automático”, sinto dizer:
👉 você está usando um Ferrari para ir à padaria.

Hoje vamos falar de HSM e do lendário DFSMShsm, no melhor estilo Bellacosa Mainframe: técnico, histórico, com fofoca, easter egg e aquela verdade que ninguém gosta de ouvir 😄


🧩 Conceito básico – o que é HSM?

HSM (Hierarchical Storage Management) é o conceito de gerenciamento hierárquico de armazenamento.

Em bom português mainframeiro:

“Colocar o dado certo, no lugar certo, pelo tempo certo, no custo certo.”

No z/OS, quem implementa isso é o DFSMShsm.


🏛️ O que é DFSMShsm?

DFSMShsm (Data Facility Storage Management Subsystem – Hierarchical Storage Manager) é um subsystem do DFSMS responsável por:

  • Backup

  • Migração

  • Recall

  • Expiração

  • Gerenciamento de fita

  • Liberação automática de espaço em disco

📌 Importante:
DFSMShsm não é um produto opcional “legalzinho” — ele é parte estrutural do z/OS moderno.


🕰️ Origem e história – HSM é mais velho que você imagina

  • Década de 1970: IBM já lidava com o problema de disco caro

  • Surgem os primeiros conceitos de hierarquia de storage

  • Anos 80: nasce o HSM para MVS

  • Anos 90: integração total com SMS

  • Hoje: HSM segue firme no z/OS, convivendo com cloud, VTL e LTO-10

🥚 Easter egg histórico:

O conceito de tiering moderno (hot, warm, cold data) nasceu no mainframe, não na nuvem.


🧠 Como o DFSMShsm funciona (visão prática)

Ele observa:

  • Uso do dataset

  • Política definida no SMS

  • Espaço disponível

  • Prioridade

E toma decisões sozinho.

Ele pode:

  • Migrar dataset para fita

  • Criar backups automáticos

  • Trazer dados de volta (recall)

  • Apagar dados vencidos

Sem pedir sua opinião.


📦 O que o HSM armazena?

🔹 Em disco (DASD)

  • Dados ativos

  • Dados recém-criados

🔹 Em fita

  • Dados migrados

  • Backups

  • Dados raramente acessados

  • Histórico e compliance

📌 Tudo catalogado, tudo controlado.


🧾 Tipos de operação do DFSMShsm

🔄 Migração

  • Move dados pouco usados para fita

  • Mantém um “stub” no catálogo

🔙 Recall

  • Usuário acessa dataset

  • HSM busca na fita automaticamente

💾 Backup

  • Incremental

  • Full

  • Versionado

🧹 Expiração

  • Remove dados vencidos

  • Libera espaço físico


🧪 Exemplo prático (mundo real)

📁 Dataset: FIN.RELATORIOS.2019

  • 180 dias sem uso

  • Management Class diz: migrar

  • HSM envia para fita

  • Dataset continua “existindo”

👨‍💻 Usuário acessa em 2026:

  • HSM faz recall

  • Usuário acha que “sempre esteve ali”

  • Operador sorri 😄


🧾 Exemplo de política SMS (simplificado)

Primary Days Non-Usage: 7 Secondary Days Non-Usage: 60 Expire After Days: 1825

☕ Tradução Bellacosa:

7 dias quente
60 dias morno
Depois disso… fita e paz eterna por 5 anos


🔧 Comandos essenciais do HSM

HSM LIST BACKUP HSM LIST MIGRATION HSM QUERY ACTIVE HSM RELEASE HSM RECOVER

🥚 Easter egg:
Se você nunca usou HSM QUERY, você confia demais 😄


🪜 Passo a passo – HSM funcionando na prática

1️⃣ Dataset é criado com SMS
2️⃣ Management Class define política
3️⃣ Usuário para de usar
4️⃣ HSM migra automaticamente
5️⃣ Backup é feito conforme agenda
6️⃣ Expiração limpa o que venceu

🎯 Tudo sem JCL manual, sem intervenção humana.


💪 Pontos fortes do DFSMShsm

✅ Automação extrema
✅ Economia de disco
✅ Integração total com z/OS
✅ Escalabilidade absurda
✅ Confiabilidade histórica
✅ Ideal para compliance e auditoria


⚠️ Pontos fracos (sim, eles existem)

❌ Curva de aprendizado
❌ Política mal feita vira desastre
❌ Recall em fita pode ser lento
❌ Dependência forte de SMS bem desenhado

☕ Verdade dura:

HSM ruim não é culpa do HSM — é culpa de quem configurou.


🧙 Curiosidades & Easter Eggs

🥚 O HSM já “salvou” mais empresa de crash de disco do que qualquer cloud
🥚 Muitas empresas usam HSM há 20 anos e nunca pararam para documentar
🥚 HSM é tão confiável que só é lembrado quando alguém desativa sem querer


🗣️ Comentário final Bellacosa Mainframe™

“DFSMShsm é como o síndico do prédio:
ninguém percebe, mas se ele falhar… o caos se instala.”

No IBM z/OS, HSM não é luxo, é sobrevivência operacional.


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.