 |
| Bellacosa Mainframe apresenta o misterio do Storage Mainframe |
🔥 z/OS NÃO É CPU: O Poder Invisível Que Realmente Move o Mainframe (E Quase Ninguém Explica)
⚠️ Se você acha que mainframe é “uma CPU gigante processando COBOL”… prepare-se para um pequeno choque de realidade.
🧙♂️ Padawan, aproxime-se…
Todo iniciante em mainframe passa por um momento de revelação.
No começo, você pensa:
“Quanto mais CPU, mais rápido.”
Depois vem o primeiro relatório de performance…
E aparece um número misterioso:
IOSQ = 37 ms
Ou pior:
DEVICE BUSY
PEND TIME ALTO
E então alguém experiente murmura:
“Isso não é CPU… é I/O.”
Bem-vindo ao lado invisível da Força.
🏛️ A Grande Mentira do Mundo Distribuído
No universo x86, a narrativa dominante é:
Performance = CPU + RAM
IBM Z como funciona a Performance
No IBM Z, a equação real é:
Performance = Addressability + I/O Architecture + Workload Management
CPU muitas vezes é só o maestro.
Quem toca a sinfonia são:
-
IOS
-
Channel Subsystem
-
Storage
-
Dispatching
-
Memory Architecture
-
PAV / HyperPAV
-
WLM / IRD
🧬 O Segredo Nº1: O mainframe NÃO espera I/O
Em sistemas comuns:
 |
| Fluxo de uso de memoria no X86 |
Programa → lê disco → espera → continua
Fluxo de uso da memoria no Mainframe
No z/OS:
Programa → delega I/O → CPU faz outra coisa
Quem assume o trabalho pesado?
👉 SAP — System Assist Processor
👉 Channel Subsystem
👉 Control Units
👉 Storage microcode
A CPU volta só quando o dado está pronto.
Isso é computação de alta eficiência em escala industrial.
🚀 Dispatching: O Coração Pulsante
Durante o IPL e ao longo da execução, o sistema escolhe quem roda a cada instante.
Unidades de trabalho:
-
TCB — Task Control Block (tarefas “normais”)
-
SRB — Service Request Block (tarefas super rápidas do kernel)
O dispatcher faz algo extraordinário:
troca contexto
aloca CPU
preserva estado
mantém isolamento
Tudo em microssegundos.
Curiosidade histórica:
O z/OS herdou conceitos do MVS dos anos 70 — e ainda assim continua décadas à frente em escalabilidade.
🧠 Addressability: O Poder que Quase Ninguém Entende
Padawan, aqui está o verdadeiro tesouro.
Cada programa roda em um Address Space isolado.
Mas o sistema permite acessar outros espaços de forma controlada.
Isso é feito por:
-
Cross-memory services
-
Program Call (PC)
-
Access Registers
-
ALESERV
-
Linkage Stack
🌀 Program Call: Visitando Outro Universo
Um programa pode executar código em outro address space sem copiar dados.
É como:
“Ir à casa do vizinho, usar o videogame dele e voltar.”
Com segurança de nível militar.
🧩 Linkage Stack: O Guardião do Retorno
Toda chamada salva automaticamente:
-
PSW
-
Registradores
-
Estado de execução
Sem precisar de save areas manuais.
Simplesmente elegante.
🔐 Access Registers: Chaves Dimensionais
Permitem que um programa acesse múltiplos espaços simultaneamente.
Não é apenas virtual memory.
É multi-universo controlado por hardware.
📦 Data Spaces e Hiperspaces: Memória Além da Memória
Antes do addressing de 64 bits, engenheiros criaram:
-
Data Spaces — áreas enormes de dados
-
Hiperspaces — armazenamento ultrarrápido fora do espaço principal
Hoje ainda aparecem em código legado.
E funcionam absurdamente bem.
⚡ O Verdadeiro Monstro: O I/O Supervisor (IOS)
 |
| IBM Mainframe I/OS Supervisor |
O IOS é o general das operações de entrada/saída.
Fluxo típico:
Aplicação
↓
IOS
↓
ORB criado
↓
SSCH (Start Subchannel)
↓
Channel Subsystem
↓
Control Unit
↓
Device
🧱 ORB, CCW e SCHIB — A Trindade do I/O
ORB — Operation Request Block
Define o pedido de I/O.
CCW — Channel Command Word
Comandos que o dispositivo executará.
SCHIB — Subchannel Information Block
Informações de caminhos e status.
🛣️ Dynamic Path Selection: GPS do Storage
O sistema escolhe automaticamente o melhor caminho até o device.
Se um estiver congestionado:
usa outro
Sem intervenção humana.
🔥 PAV e HyperPAV: Quando um Disco Não Basta
Antigamente:
1 volume → 1 operação por vez
Hoje:
👉 PAV cria aliases para paralelismo
👉 HyperPAV usa pool dinâmico
👉 SuperPAV ultrapassa limites de control unit
Resultado:
múltiplos I/Os simultâneos
🐹 IOSQ Alto: O Hamster Está Cansado
IOSQ = tempo esperando na fila do dispositivo.
Se alto:
-
contenção de volume
-
falta de aliases
-
workload concentrado
-
gargalo de storage
É o equivalente mainframe de:
“CPU está idle, mas tudo continua lento.”
⚡ zHPF: Menos Conversa, Mais Trabalho
Arquitetura clássica:
vários CCWs
várias interações
zHPF:
Transport Mode
TCW único
menos overhead
Ideal para workloads com milhões de pequenos I/Os.
🌌 zHyperLink: Hiperespaço do Storage
Conexão direta ultrarrápida com DS8000.
Latência:
FICON → centenas de microssegundos
zHyperLink → dezenas
Projetado especialmente para DB2.
🧠 IRD: O Maestro Invisível
O Intelligent Resource Director move recursos entre LPARs automaticamente:
-
CPU weights
-
Channel paths
-
Prioridades
Tudo baseado nas metas do WLM.
Sem reboot. Sem intervenção.
🧪 Easter Egg para Padawans Observadores
Se você olhar um dump real de SOC4 e conseguir identificar:
-
registrador base incorreto
-
endereço inválido
-
PSW no momento da falha
Parabéns.
Você já começou a ver a Matrix do z/OS.
🏁 Moral da História
O IBM Z não é poderoso por causa da CPU.
Ele é poderoso porque:
👉 Nunca para
👉 Nunca desperdiça ciclos
👉 Paraleliza tudo
👉 Isola tudo
👉 Gerencia recursos como um organismo vivo
💬 Frase para guardar na memória
O mainframe não é um computador rápido — é um sistema que evita ser lento.
🔮 Próximo Nível
Quando você realmente entender:
-
Addressability
-
Cross-memory
-
IOS
-
Channel Subsystem
-
Storage architecture
Você perceberá algo assustador:
O z/OS não executa programas… ele orquestra universos isolados cooperando.
