 |
| Bellacosa Mainframe apresenta storage no ZOS |
🧠 Padawan, aproxime-se do console… hoje o assunto é: Monitoramento de Disco no IBM Mainframe
(ou: como não deixar o DASD virar o Lado Sombrio da Força)
📜 Um pouco de história (porque no mainframe nada nasce ontem)
Antes de existir storage definido por software, cloud ou “é só aumentar o volume”, já existia DASD — Direct Access Storage Device.
Nos primórdios, isso significava discos gigantes, barulhentos, caríssimos e venerados 🛐.
👉 O mainframe sempre tratou disco como recurso nobre.
Nada de “joga log fora depois a gente vê”.
E aí entra o lendário…
 |
| IBM Mainframe unidade de disco |
💿 DASD – Direct Access Storage Device
No mundo z/OS, disco não é disco, é DASD.
E DASD tem personalidade, etiqueta e hierarquia.
Tipos clássicos
-
📀 3380 – Jurassic Park (ainda aparece em livro antigo)
-
💿 3390 – O padrão ouro (e nosso foco)
-
🧠 EAV / EAS – Extended Address Volumes (para os discos gigantes de hoje)
 |
| Unidade de disco 3390 antiga |
🧱 O mito do 3390
📦 O que é um 3390?
Um modelo lógico de disco, não importa se o storage físico é:
-
DS8K
-
Flash
-
NVMe disfarçado de DASD
👉 Para o z/OS, continua sendo um 3390, com:
-
📐 Trilhas
-
📊 Cylinders
-
🧮 Extents
Tamanhos clássicos
| Tipo | Cylinders |
|---|---|
| 3390-1 | 1.113 |
| 3390-3 | 3.339 |
| 3390-9 | 10.017 |
| 3390-27 | 32.760 |
| EAV | milhões 😈 |
🧠 Easter Egg:
Mesmo em storage 100% flash, o z/OS ainda “pensa” em trilhas.
Legacy não morre, evolui.
👀 Por que monitorar DASD, Padawan?
Porque disco cheio não avisa com carinho.
Ele derruba job, trava aplicação e chama gerente.
Riscos clássicos
-
🚨 Volume acima de 85%
-
🚨 Fragmentação absurda
-
🚨 Catálogo estourado
-
🚨 Extents demais por dataset
-
🚨 Sorts falhando sem espaço temporário
🛠️ Ferramentas nativas (sem gastar um centavo)
📟 SDSF
Seu sabre de luz inicial.
Comandos úteis:
ou
Você vê:
-
Volume
-
Device Type (3390)
-
Online/Offline
-
Uso geral
🧾 IDCAMS – O velho sábio
Ou para volumes:
📌 Mostra:
-
Quantos datasets
-
Extents
-
Fragmentação
-
Catálogo
🧠 Easter Egg:
LISTCAT mal interpretado já causou pânico desnecessário em muito CPD.
🧪 DFSMS – O cérebro invisível
Se você usa:
-
SMS
-
Storage Groups
-
Management Classes
Então o monitoramento precisa olhar:
-
Storage Group cheio
-
Pool desbalanceado
-
Volumes quentes vs frios
Comandos:
🧙♂️ Ferramentas corporativas (o lado premium da Força)
-
IBM Tivoli / OMEGAMON
-
BMC MainView
-
Broadcom SYSVIEW
Essas ferramentas:
-
Alertam antes do caos
-
Criam gráficos bonitos
-
Salvam operadores de madrugadas ruins ☕😵💫
📐 Métricas que todo Padawan deve decorar
🔢 Uso de volume
-
🟢 Até 70% → zen
-
🟡 70–85% → atenção
-
🔴 > 85% → reunião marcada
🧩 Fragmentação
-
Muitos extents = performance ruim
-
VSAM sofre mais que sequential
🧮 Extents
-
Dataset com 200+ extents é pedido de REORG
-
Antigamente: limite era dor e sofrimento
🧪 Exemplo real (história de guerra)
“O batch sempre rodou… até hoje.”
Motivo?
-
Volume temporário (SORTWK) com 92%
-
Job falha com:
Solução?
-
Monitoramento
-
Alocação dinâmica
-
Limpeza automática
📌 Moral: disco cheio não falha… ele se vinga.
🧠 Curiosidades & Fofoquices de CPD
-
🔍 Muitos ambientes ainda usam um único volume SYSRES
-
🧓 Dataset criado em 1998 ainda rodando em produção
-
😅 Volume “temporário” com dados críticos
-
📦 Flash moderno, mas pensado como 3390-3
🧭 Dicas Bellacosa Mainframe™️
✔️ Nunca confie em volume acima de 80%
✔️ Monitore tendência, não só foto do momento
✔️ Volume “barato” é o que causa outage caro
✔️ Documente storage group (ninguém faz, todo mundo sofre)
✔️ Ensine o Padawan antes que ele vire Operador às 3h da manhã
🧩 Encerrando…
Monitorar DASD no mainframe não é só técnica —
é filosofia, história viva e respeito à máquina.
💬 “No mainframe, disco não acaba… ele avisa.
O problema é quando ninguém está ouvindo.”
Sem comentários:
Enviar um comentário