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

Era	Limite
24-bit	16MB 😱
31-bit	2GB
👉 64-bit	16EB 🤯

---

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

 

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.