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.

https://www.linkedin.com/pulse/zos-n%C3%A3o-%C3%A9-cpu-o-poder-invis%C3%ADvel-que-realmente-move-e-quase-bellacosa 

 

As “zonas secretas” da memória do z/OS — Onde o sistema guarda suas ferramentas

 

Bellacosa Mainframe fala sobre The Line no Storage

☕ Um Café no Bellacosa Mainframe

As “zonas secretas” da memória do z/OS — Onde o sistema guarda suas ferramentas

Se a memória total é o cérebro…
e o paging é a respiração…

👉 Esses indicadores mostram as salas técnicas dentro do cérebro.

CSA      74%
ECSA     56%
ESQA     89%
BELOW 16M 94%

Para leigos, isso parece nome de agência governamental secreta 😄
Mas na verdade são áreas internas críticas da memória do sistema.

E sim — se uma delas enche demais, o sistema pode travar mesmo tendo RAM sobrando.

Vamos abrir essa “planta baixa” do mainframe ☕

---

TSO SDSF Simulator

🏢 Antes de tudo: memória do z/OS NÃO é um espaço único

Diferente de PCs comuns, o z/OS divide a memória em áreas especializadas.

Pense num hospital:

• Emergência

• Centro cirúrgico

• UTI

• Administração

• Farmácia

Cada uma tem função específica.

---

IBM Z Storage Full Virtual Memory Map

🧰 CSA — Common Service Area (74%)

👉 Área compartilhada entre várias tarefas do sistema

Aqui ficam coisas usadas por muitos programas ao mesmo tempo:

• Tabelas do sistema

• Estruturas de comunicação

• Controles de subsistemas

• Buffers comuns

💡 Analogia:

👉 É o “hall central” do prédio.

74% significa:

✔️ Ocupado, mas confortável
✔️ Sem risco imediato

---

🌐 ECSA — Extended Common Service Area (56%)

Mesma ideia da CSA… porém em memória mais alta.

Criada quando os sistemas começaram a crescer além dos limites antigos.

💬 História curiosa:

Nos primórdios, tudo precisava caber em poucos megabytes.
A IBM foi “estendendo” áreas sem quebrar compatibilidade.

Resultado: nomes com “Extended” por toda parte 😄

56% = tranquilo.

---

🧠 ESQA — Extended System Queue Area (89%)

Agora a coisa fica interessante.

👉 Área usada para estruturas internas do núcleo do sistema
👉 Controle de filas, recursos e sincronização

Pense como:

🧾 A central de logística do sistema

89% é alto — mas não necessariamente crítico.

💬 Sysprogs experientes monitoram ESQA com carinho.

Se encher totalmente:

⚠️ Pode impedir novas alocações
⚠️ Pode causar falhas estranhas
⚠️ Pode exigir IPL (reinicialização)

---

🕰️ BELOW 16M — 94% 😱

Aqui mora uma relíquia histórica importantíssima.

📜 O limite mágico dos 16 MB

Nos anos 80, sistemas operavam em endereçamento de 24 bits:

👉 Máximo de memória acessível = 16 MB

Mesmo hoje, algumas estruturas precisam ficar nessa região por compatibilidade.

💬 Sim — software de décadas atrás ainda roda.

---

💡 O que fica BELOW 16M?

• Componentes antigos do sistema

• Drivers específicos

• Partes de subsistemas

• Estruturas críticas que nunca foram migradas

---

⚠️ 94% é alto?

👉 Sim — é a área que mais preocupa operadores.

Porque:

❌ Não dá para expandir facilmente
❌ Não depende da RAM total instalada
❌ Pode causar problemas mesmo em máquinas gigantes

É como um elevador antigo num prédio moderno:
todo mundo ainda precisa dele.

---

🕵️ Fofoquice histórica deliciosa

Durante anos, uma das artes do sysprog era:

👉 “Liberar storage abaixo da linha”

Comandos obscuros, tuning, patches, ajustes…

Existem até histórias de sistemas parando porque um único componente consumiu alguns KB a mais nessa área.

Sim — kilobytes.

---

🧃 Explicação ultra simples

Se o IBM Z fosse um shopping:

• CSA → área comum do público

• ECSA → expansão do shopping

• ESQA → sala de controle operacional

• BELOW 16M → infraestrutura antiga do prédio

👉 Esta última está quase cheia.

---

🤫 Easter Egg Mainframe

Você pode ouvir veteranos dizendo:

“O problema não é falta de memória… é falta de memória NO LUGAR CERTO.”

Essa tela prova exatamente isso.

---

🏥 Diagnóstico geral

💚 CSA — OK
💚 ECSA — confortável
💛 ESQA — atenção leve
⚠️ BELOW 16M — área crítica monitorada

Nada necessariamente errado… mas digno de acompanhamento.

---

🚀 Por que isso é fascinante?

Porque mostra algo único do mundo mainframe:

👉 Compatibilidade absoluta com o passado
👉 Engenharia evolutiva em vez de destrutiva
👉 Sistemas escritos há 40 anos ainda funcionando

Enquanto PCs e smartphones vivem de “formata e reinstala”.

---

☕ Conclusão

Esta tela revela a anatomia interna da memória do z/OS.

Não é apenas “quanto temos” — é:

👉 Onde está sendo usado
👉 Quem está usando
👉 Quais áreas podem virar gargalo

E principalmente:

👉 Que mesmo supercomputadores corporativos têm seus pontos sensíveis.