Translate

Mostrar mensagens com a etiqueta hsm. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta hsm. 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

💣 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.”

 

terça-feira, 31 de março de 2026

🔥 SEUS DADOS NÃO MORAM NO DISCO… ELES VIAJAM PELO UNIVERSO DO z/OS 😳

 

Bellacosa Mainframe num mergulho no mundo storage do z/os

🔥 SEUS DADOS NÃO MORAM NO DISCO… ELES VIAJAM PELO UNIVERSO DO z/OS 😳

O guia proibido de Storage Management que revela como memória, disco e sysplex trabalham juntos (e quase ninguém entende)

Você acha que seu dataset “fica no disco”?

👉 Não fica.

No z/OS, dados:

  • sobem pra memória
  • descem pra disco
  • migram pra fita
  • aparecem em outro LPAR
  • e até existem fora do seu address space

💥 “No mainframe, dado não tem endereço fixo… tem estratégia.”

Se você quer sair do nível “usuário” e pensar como engenheiro de sistema, esse é o mapa completo 👊🔥


🧠 1. ADDRESS SPACE — O UNIVERSO DO PROGRAMA

Cada programa roda em um address space isolado.


🔥 O que isso significa?

  • memória protegida
  • ambiente independente
  • controle total do sistema

💡 Insight

cada address space é um “universo privado”


⚡ 2. 64-BIT ADDRESSING — MEMÓRIA INFINITA (QUASE)

Com 64 bits:

👉 até 16 EXABYTES


🔥 Evolução histórica

EraLimite
24-bit16MB 😱
31-bit2GB
👉 64-bit16EB 🤯

💡 Tradução Bellacosa

“acabou a desculpa de falta de memória”


🧠 Uso real

  • Java
  • Db2
  • middleware
  • grandes buffers

🧩 3. DAT — A MÁGICA DA TRADUÇÃO

DAT (Dynamic Address Translation):

👉 converte endereço virtual → real


🔥 Sem DAT:

  • programa quebraria
  • memória não funcionaria

💡 Tradução

“você nunca acessa memória real diretamente”


🧠 4. STORAGE REQUESTS — COMO A MEMÓRIA É PEDIDA

Programas pedem memória via:

  • GETMAIN
  • STORAGE OBTAIN

🔥 O sistema decide:

  • onde alocar
  • em qual subpool
  • com qual proteção

💡 Insight

memória é gerenciada, não livre


🧱 5. SUBPOOLS — ORGANIZAÇÃO INTERNA

Memória é dividida em:

👉 subpools


🔥 Exemplos:

  • SP0 → sistema
  • SP229 → usuário

💡 Tradução

“cada tipo de dado tem seu bairro”


🌍 6. DATA SPACES & HIPERSPACES — FORA DO ADDRESS SPACE

🔹 Data Spaces

  • dados fora do address space
  • acessados via AR

🔹 Hiperspaces

  • alta performance
  • acesso indireto

🔥 Tradução Bellacosa

“memória extra fora do seu universo”


🧠 Exemplo

Programa → usa Data Space → grande volume de dados

⚡ 7. PAGING — QUANDO A MEMÓRIA NÃO CABE

Se falta memória:

👉 dados vão para disco (paging)


🔥 Fluxo

Memória cheia

página vai para DASD

quando necessário → volta

💡 Problema

👉 excesso de paging = sistema lento 💀


💾 8. FLASH STORAGE — O TURBO MODERNO

Flash (SSD):

  • baixa latência
  • alta velocidade
  • ideal para OLTP

💡 Uso

  • Db2
  • logs
  • datasets críticos

🔗 9. PARALLEL SYSPLEX — MEMÓRIA COMPARTILHADA ENTRE SISTEMAS

Aqui fica poderoso 😄


🔥 O que é?

Vários z/OS trabalhando juntos:

👉 como um só sistema


💡 Elementos:

  • LPARs
  • Coupling Facility (CF)
  • links de comunicação

🧠 Exemplo

LPAR A → acessa dado
LPAR B → acessa o mesmo dado

💡 Tradução

“dados compartilhados em tempo real”


🧠 10. COUPLING FACILITY (CF) — O CÉREBRO COMPARTILHADO

🔹 Função:

  • lock management
  • cache
  • filas

🔥 Tipos:

  • Internal CF
  • External CF

💡 Tradução Bellacosa

“CF = memória compartilhada do sysplex”


⚡ 11. DUPLEXING — ZERO PERDA

🔥 O que faz?

  • duplica dados
  • garante disponibilidade

💡 Exemplo

CF primário → falha
CF secundário → assume

🧨 Curiosidade

Sistema continua rodando sem impacto 😳


🧠 12. CF OPERATIONS — O QUE ACONTECE POR TRÁS

CF gerencia:

  • locks
  • buffers
  • filas

💡 Uso real

  • Db2 data sharing
  • CICS
  • IMS

⚙️ 13. STORAGE + I/O + CPU — TUDO CONECTADO

Nada funciona isolado:

Memória → I/O → CPU → WLM → Storage

💡 Insight

performance é resultado do conjunto


🔄 14. PASSO A PASSO COMPLETO

Programa inicia

recebe address space

pede memória (GETMAIN)

DAT traduz endereço

usa data space se necessário

paging ocorre se faltar memória

dados vão para disco/flash

sysplex compartilha dados via CF

duplex garante disponibilidade

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. Você não controla diretamente onde o dado está


🔥 2. Dados podem estar fora do seu address space


💀 3. Paging excessivo mata performance


🧠 4. Sysplex permite vários sistemas compartilharem dados


⚡ 5. CF é o segredo da alta disponibilidade


🎯 RESUMO FINAL

✔ Address space = isolamento

✔ 64-bit = escala absurda

✔ DAT = tradução

✔ Subpools = organização

✔ Data space = expansão

✔ Paging = fallback

✔ Flash = velocidade

✔ Sysplex = escala

✔ CF = coordenação

✔ Duplexing = resiliência


💥 FRASE FINAL

“No z/OS, dados não ficam armazenados… eles são orquestrados entre memória, disco e múltiplos sistemas em tempo real.”

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.