 |
| Bellacosa Mainframe apresenta o maestro invisivel do Mainframe: WLM |
🚀 O Maestro Invisível do Mainframe: Como o WLM Decide Quem Vive, Quem Espera e Quem Domina o IBM Z
“O z/OS não é apenas um sistema operacional. É um sistema de sobrevivência computacional — e o WLM é seu cérebro.”
Se você é um padawan do mainframe 🧙♂️, há um momento em que tudo muda.
Você deixa de ver jobs, CICS e DB2 como coisas isoladas… e passa a enxergar um ecossistema vivo, onde milhares de tarefas lutam pelos mesmos recursos.
Nesse universo, existe um árbitro supremo:
🧠 Workload Manager — WLM
Sem ele, um mainframe moderno seria apenas um supercomputador caro brigando consigo mesmo.
🏛️ Antes do WLM: o caos elegante dos anos 70 e 80
Nos primórdios do MVS, a prioridade era… manual.
Operadores e sysprogs definiam:
-
Prioridades fixas
-
Classes de execução estáticas
-
Ajustes “no feeling”
-
Reconfiguração constante
Problemas clássicos:
💥 Batch travando online
💥 CICS lento em horário de pico
💥 CPU livre e usuários reclamando
💥 Sistema imprevisível
O hardware evoluiu. O software também precisava evoluir.
⚙️ O nascimento do WLM — computação orientada ao negócio
O WLM moderno surgiu com o OS/390 nos anos 90.
A ideia foi revolucionária:
❌ Não gerenciar processos
✅ Gerenciar objetivos de negócio
Você não diz:
👉 “Este job tem prioridade 8”
Você diz:
👉 “Quero que 90% das transações respondam em até 1 segundo”
O sistema decide como chegar lá.
🎼 O WLM é um maestro, não um executor
Ele não executa código.
Ele coordena:
-
Dispatcher (CPU)
-
IOS (I/O)
-
Memory manager
-
PR/SM (hardware)
-
Subsystems (CICS, DB2, etc.)
Política → Prioridade → Recursos → Execução
🧩 Os elementos fundamentais do WLM
🏷️ Service Class — “Quem é você?”
Categoria de workload com tratamento específico.
Exemplos reais:
-
CICS_ONLINE
-
DB2_OLTP
-
BATCH_HIGH
-
TSO_USERS
-
DISCRETIONARY
Uma única classe pode representar centenas de workloads.
🎯 Goal — “O que esperamos de você?”
Tipos principais:
-
⏱️ Response Time — tempo de resposta
-
⚡ Velocity — progresso contínuo
-
💤 Discretionary — use as sobras
⭐ Importance — “Quão importante você é?”
Escala de 1 a 5:
1️⃣ Missão crítica
5️⃣ Pode esperar
Sob escassez, isso decide tudo.
⏱️ Performance Periods — prioridade dinâmica
Uma obra-prima do design do WLM.
Permite tratar o mesmo trabalho de forma diferente ao longo do tempo.
Exemplo típico:
Período 1 — Importance 1 — resposta rápida
Período 2 — Importance 3 — menos crítico
Período 3 — Discretionary — só sobras
👉 Protege o sistema contra trabalhos “runaway”.
🧭 Classification Rules — o roteador automático
Determinam qual workload entra em qual Service Class.
Critérios possíveis:
-
Job name
-
User ID
-
Address space name
-
Transaction name (CICS)
-
Atributos de enclave
-
Padrões (wildcards)
💎 Curiosidade: também podem marcar workloads como Storage Critical.
⚡ Dispatchable Units — quem realmente roda
O dispatcher não agenda jobs.
Ele agenda DUs:
-
🧾 TCB — tasks de aplicação
-
⚡ SRB — trabalho de sistema
Múltiplas DUs podem rodar simultaneamente no mesmo address space.
🧮 Dispatching Priority — o número mágico
Escala: 0–255 (geralmente >190)
👉 Maior valor ⇒ maior chance de CPU
Mostrado no SDSF (painel DA).
É recalculado constantemente pelo WLM.
📀 I/O Priority e Memory
O WLM também influencia:
📀 I/O
-
Prioridade de acesso a discos
-
Filas de dispositivos
-
Latência de storage
Sem grupos específicos:
👉 I/O priority = Dispatching priority
💾 Storage Critical
Protege workloads contra swap.
Não dá mais memória — evita que sejam expulsos da RAM.
Crucial para:
-
CICS
-
DB2
-
Middleware
-
Serviços online
🩸 Donor vs Receiver — economia de recursos
Sob escassez:
-
🏆 Receivers → precisam cumprir metas
-
🩸 Donors → cedem recursos
-
💤 Discretionary → só sobras
Regra importante:
👉 Só doa quem está usando.
🧠 Enclaves — workloads distribuídos
Representam trabalho que atravessa múltiplos address spaces.
Muito usados em:
-
DB2 DDF
-
APIs
-
Java servers
-
MQ
-
Middleware
Permitem controle ponta a ponta.
🧪 Curiosidades e Easter Eggs
💎 O WLM é considerado uma das maiores vantagens competitivas do mainframe.
💎 Muitos conceitos de QoS em cloud vieram daqui.
💎 Sistemas distribuídos ainda lutam para replicar essa sofisticação.
💎 O mainframe pode parecer “antigo”, mas seu scheduler é mais avançado que o de muitos sistemas modernos.
💥 Falhas mais comuns em produção
❌ Políticas mal projetadas
Sintomas:
-
CPU alta sem ganho real
-
Online lento
-
Batch dominando horários críticos
❌ Service Classes demais
Complexidade gera comportamento imprevisível.
❌ Classificação incorreta
Workloads críticos tratados como comuns.
❌ Ignorar Performance Periods
Trabalhos longos monopolizam recursos.
🛠️ Como controlar e acompanhar
Ferramentas principais:
🖥️ SDSF
-
DA — Address Spaces ativos
-
ENCLAVES — workloads distribuídos
-
ST — Jobs
📊 RMF
Análise profunda de performance.
⚙️ WLM ISPF / z/OSMF
Configuração de políticas.
📈 SMF records
Base para capacity planning e auditoria.
🧭 Como pensar como um especialista
Quando algo está lento, pergunte:
👉 Qual recurso está saturado?
👉 Quem está consumindo?
👉 Esse workload deveria ter essa prioridade?
👉 O WLM está cumprindo ou ignorando metas?
🏆 A verdade final
O poder do mainframe não está apenas no hardware.
Está na capacidade de usar recursos de forma:
✔️ previsível
✔️ controlada
✔️ orientada ao negócio
✔️ resiliente sob carga extrema
🧠 Frase para levar para a vida
WLM não decide quem roda primeiro.
Ele decide quais objetivos do negócio serão preservados quando os recursos acabarem.
