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 Storage Management no IBM z/OS

---

🧱 IBM Mainframe Storage Management no z/OS

DFSMS, SMS x non-SMS, ISMF, ACS, DASD, TAPE, JCL, VSAM, PS e PO

O disco não é só espaço. É política, disciplina e sobrevivência.

---

☕ Introdução – Quando o disco manda mais que o código

Todo mainframe nasce vazio.
Nenhum COBOL roda, nenhum CICS responde, nenhum batch fecha balanço sem que alguém tenha decidido onde os dados vão morar.

E é aqui que muita gente erra:

“Ah, storage é só pedir espaço no JCL…”

❌ Errado.
No IBM Mainframe, storage é governança, automação, história, política corporativa e, muitas vezes, briga silenciosa entre times.

Este artigo é para você que:

• Já sofreu com SMS override

• Já ouviu “o ACS mandou”

• Já viu dataset ir parar num disco que você nem sabia que existia

• Ou ainda acha que VOL=SER ainda manda em tudo

Senta, pega o café, que a aula começa agora.

---

🏛️ Origem e História – Do ferro bruto ao cérebro automático

📼 Anos 60–70: tudo era manual

• Disco era caro

• Poucos volumes

• Programador escolhia tudo

• Erro humano era rotina

💣 Anos 80: o caos

• Explosão de dados

• Batch gigante

• Fragmentação absurda

• Discos cheios às 03:00 da manhã

🧠 Anos 90: nasce o DFSMS

A IBM percebeu:

“Não dá para deixar cada programador decidir disco.”

Surge o DFSMS (Data Facility Storage Management Subsystem).

Objetivo:

• Padronizar

• Automatizar

• Controlar

• Evitar desastre operacional

📌 DFSMS não é luxo. É resposta ao caos.

---

🧠 DFSMS – O cérebro do armazenamento no z/OS

DFSMS é:

• Parte nativa do z/OS

• Gerente de dados

• Juiz das decisões de disco

• Guarda-costas da infraestrutura

Ele cuida de:

• DASD

• TAPE

• Migração

• Backup

• Alocação

• Performance

• Disponibilidade

---

💽 DASD – O chão onde tudo pisa

DASD = Direct Access Storage Device

Tradução Bellacosa:

“É o HD do mainframe, só que sério.”

Tudo mora em DASD:

• z/OS

• SYS1

• Aplicações

• VSAM

• Logs

• Catálogos

📌 Volume = Disco = DASD

Exemplos reais:

PRD001
TSO123
CICS45

---

📼 TAPE – O ancião que ainda reina

Muita gente subestima, mas:

• Tape é barato

• Tape é denso

• Tape é confiável

• Tape é rei do backup

DFSMS controla:

• Migração HSM

• Recall automático

• Arquivamento

📌 Easter egg:
Muitos bancos ainda têm dados mais velhos que o programador, morando felizes em fita.

---

🧩 SMS x non-SMS – O conflito eterno

🔴 Non-SMS (old school)

Você manda:

• VOL=SER

• SPACE

• UNIT

Vantagem:

• Controle total

Desvantagem:

• Risco total

📌 Hoje: usado só em casos muito específicos.

---

🟢 SMS-Managed (mundo real)

O sistema manda.

Você pede:

• Nome do dataset

O SMS decide:

• Onde fica

• Quanto espaço

• Performance

• Migração

📌 Naming convention é lei.

---

🧬 ACS – O código que manda mais que o JCL

ACS Routine = cérebro do SMS

Ela decide:

• Data Class

• Storage Class

• Storage Group

Baseado em:

• Nome do dataset

• Usuário

• Programa

• Ambiente

Exemplo simplificado:

IF &DSN = 'PRD.*'
   SET &STORCLAS = 'HIGH'

💣 Easter egg cruel:

Você pode pedir CYL(1000).
O ACS pode te dar TRK(10).
E ainda sorrir.

---

🖥️ ISMF – Onde o poder mora

ISMF = Interactive Storage Management Facility

Ferramenta do:

• Storage admin

• Infra

• Arquitetura

Aqui você vê:

• Volumes

• Classes

• Storage Groups

• ACS

• Espaço real

📌 Programador geralmente não entra aqui.

---

🧱 Data Class – O DNA do dataset

Define:

• RECFM (FB, VB…)

• LRECL

• DSORG

Exemplo:

RECFM=FB
LRECL=80
DSORG=PS

📌 Template padrão corporativo.

---

🚀 Storage Class – Performance e SLA

Define:

• Prioridade

• Backup

• Migração

• Disponibilidade

📌 Onde o negócio fala mais alto que o código.

---

🗄️ Storage Group – O endereço físico

• Conjunto de volumes

• Abstração total

• Usuário não escolhe disco

📌 Você não precisa saber qual disco.
📌 O SMS sabe.

---

📂 Tipos de Data Set – PS, PO, VSAM

📄 PS (Sequential)

• Batch

• Relatórios

• Entrada/Saída simples

---

📚 PO / PDS / PDSE

• Código

• JCL

• Copybooks

📌 PDSE > PDS (sempre que possível).

---

🧬 VSAM

• KSDS

• ESDS

• RRDS

Alta performance, alta complexidade.

📌 VSAM mal dimensionado = pesadelo.

---

📜 JCL x DFSMS – Quem manda?

JCL pede.
DFSMS decide.

Exemplo clássico:

SPACE=(CYL,(100,50))

Resultado:

SPACE=(TRK,(10,5))

Mensagem:

“Some attributes were overridden by ACS routine.”

📌 Tradução:

“Você tentou. Eu mandei.”

---

🧪 Passo a passo prático (vida real)

1. Dataset criado

2. ACS roda

3. Classes atribuídas

4. Volume escolhido

5. Espaço ajustado

6. Catálogo atualizado

Tudo automático.

---

🧙‍♂️ Dicas Bellacosa Mainframe

✔ Naming convention é tudo
✔ Nunca confie só no JCL
✔ Leia o ACS antes de reclamar
✔ ISMF é seu melhor amigo
✔ Storage admin é aliado, não inimigo
✔ PDSE sempre que possível
✔ VSAM exige respeito

---

🥚 Easter Eggs & Curiosidades

🥚 Existem ACS routines com 20+ anos em produção
🥚 Já houve banco parado porque alguém mexeu no ACS sem change
🥚 Muitos datasets “fantasmas” existem só porque ninguém sabe quem usa
🥚 Tape ainda salva mais empresa que cloud hype

---

☕ Conclusão – A frase que resume tudo

“No mainframe, código faz o sistema funcionar.
Storage faz o negócio sobreviver.”

Se quiser, posso:

• 📚 Transformar isso em curso

• 🧪 Criar labs práticos

• 🎓 Adaptar para aula corporativa

• 🔐 Criar versão bancária real

• 📊 Montar mapa mental DFSMS

Só chamar.
O café está quente ☕🖥️