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, 27 de outubro de 2025

💣🔥 LABORATÓRIO PRÁTICO — “DO DATASET À FITA (Storage Mainframe)

 

Bellacosa Mainframe Laboratorio pratico Storage Mainframe

💣🔥 LABORATÓRIO PRÁTICO — “DO DATASET À FITA”

DFSMS + DFSMShsm + DFSMSrmm para SysProg Junior & Aspirante a Storage ☕💾

🎯 Objetivo do LAB:

Você vai aprender na prática:

✅ Como o z/OS decide onde um dataset será armazenado
✅ Como políticas DFSMS funcionam
✅ Como ACS automatiza storage
✅ Como HSM migra dados
✅ Como RMM controla retenção e fitas

💣 Tudo isso pensando como um Storage Admin real.


🧠 CENÁRIO DO LAB

Você trabalha em um banco fictício:

BANCO Z17

Seu desafio:

👉 Criar uma política automática para datasets financeiros.

Regras:

  • Dados financeiros precisam ser rápidos

  • Backup diário

  • Migração automática após 2 dias

  • Retenção de 30 dias

  • Controle de fita para auditoria


⚔️ ETAPA 1 — CRIAR DATA CLASS

🎯 Objetivo

Definir a estrutura do dataset.


🖥️ ISMF

Option 3 → Data Class

📌 Criar:

Data Class Name ===> FINDATA

Description     ===> FINANCIAL FB 80

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

Primary Qty     ===> 10 CYL
Secondary Qty   ===> 5 CYL

✅ SOLUÇÃO

💡 O dataset agora possui:

  • Formato fixo

  • Estrutura padrão bancária

  • Crescimento controlado


⚡ ETAPA 2 — CRIAR STORAGE CLASS

🎯 Objetivo

Garantir alta performance.


🖥️ ISMF

Option 4 → Storage Class

📌 Criar:

Storage Class ===> FASTFIN

Performance   ===> HIGH
Description   ===> SSD STORAGE

✅ SOLUÇÃO

💡 O dataset agora será direcionado para storage de alta performance.


🔁 ETAPA 3 — MANAGEMENT CLASS

🎯 Objetivo

Automatizar ciclo de vida.


🖥️ ISMF

Option 5 → Management Class

📌 Criar:

Management Class ===> FINMGT

Backup           ===> DAILY

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

Expiration       ===> 030 DAYS

✅ SOLUÇÃO

💡 Agora o dataset:

  • Recebe backup

  • Migra automaticamente

  • Expira sozinho


🗂️ ETAPA 4 — STORAGE GROUP

🎯 Objetivo

Definir pool físico.


🖥️ ISMF

Option 6 → Storage Group

📌 Criar:

Storage Group ===> FINSG

Volumes:
VOL001
VOL002
VOL003

✅ SOLUÇÃO

💡 Os datasets poderão ser distribuídos automaticamente entre volumes.


🧠 ETAPA 5 — ACS ROUTINE

🎯 Objetivo

Automatizar decisões.


🖥️ ISMF

Option 7 → ACS Routines

📌 STORAGE CLASS ACS

IF &HLQ = 'FINANCE'
 THEN SET &STORCLAS = 'FASTFIN'

📌 MANAGEMENT CLASS ACS

IF &HLQ = 'FINANCE'
 THEN SET &MGMTCLAS = 'FINMGT'

📌 DATA CLASS ACS

IF &HLQ = 'FINANCE'
 THEN SET &DATACLAS = 'FINDATA'

✅ SOLUÇÃO

💣 Agora o sistema decide tudo sozinho.

Você não precisa informar classes no JCL.


⚔️ ETAPA 6 — EXECUTAR JCL

🎯 Objetivo

Criar dataset usando automação.


📌 JCL

//FINJOB  JOB (ACCT),'FINANCE',CLASS=A,MSGCLASS=X
//STEP1   EXEC PGM=IEFBR14
//DD1     DD  DSN=FINANCE.CLIENTES.DADOS,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(10,5)),
//            UNIT=SYSDA

✅ SOLUÇÃO

💡 Resultado esperado:

O z/OS aplicará automaticamente:

  • FINDATA

  • FASTFIN

  • FINMGT


🔍 ETAPA 7 — VALIDAR

🖥️ ISPF 3.4

FINANCE.CLIENTES.DADOS

📌 Verificar:

✅ Data Class
✅ Storage Class
✅ Management Class


💣 ETAPA 8 — SIMULAÇÃO DE ERRO

🎯 Objetivo

Aprender troubleshooting.


📌 Alterar ACS:

SET &STORCLAS = 'INVALID'

❌ Resultado esperado

Falha na alocação.


✅ LIÇÃO

💣 Uma linha errada no ACS pode afetar o ambiente inteiro.


🔄 ETAPA 9 — ENTENDENDO HSM

🎯 Fluxo automático

Dia 0 → Disco rápido
Dia 2 → ML1
Dia 5 → ML2 (fita)
Dia 30 → DELETE

✅ LIÇÃO

👉 O dataset “viaja” automaticamente conforme envelhece.


📼 ETAPA 10 — RMM & COMPLIANCE

🎯 Objetivo

Entender retenção.


📌 Cenário

Backup bancário precisa ficar 7 anos.

✅ SOLUÇÃO

RMM garante:

  • Rastreamento

  • Inventário

  • Auditoria

  • Vault


⚔️ DESAFIO FINAL

💥 Desafio para o aluno

Crie nova política para:

HLQ = TESTE

Regras:

  • Storage STANDARD

  • Sem backup

  • Expiração 5 dias


✅ RESPOSTA ESPERADA

O aluno deverá:

  • Criar novas classes

  • Alterar ACS

  • Validar comportamento



🧠 O QUE VOCÊ APRENDEU

✅ DFSMS Constructs
✅ ACS Routines
✅ Automação de storage
✅ Ciclo de vida HSM
✅ Conceitos RMM
✅ Troubleshooting básico


💣 FRASE FINAL ESTILO BELLACOSA

“No z/OS, datasets não envelhecem por acaso…
eles seguem políticas que alguém escreveu.”

 

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.