 |
| 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)
☕ Tradução Bellacosa:
7 dias quente
60 dias morno
Depois disso… fita e paz eterna por 5 anos
🔧 Comandos essenciais do HSM
🥚 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.
