☕ Um Café no Bellacosa Mainframe
Bellacosa Mainframe e o wlm workload manager
Workload Manager (WLM) sem Mistérios
Como o IBM Z Decide Quem Executa Primeiro — O Guia Definitivo do Programador COBOL Padawan Inspirado em Star Trek
"A necessidade de muitos supera a necessidade de poucos... ou de apenas um processo batch."
— Adaptado de Spock, Star Trek II
Introdução
Existe uma pergunta que todo programador COBOL faz mais cedo ou mais tarde.
"Por que meu programa demorou 2 minutos ontem e hoje levou 18 minutos, se eu não alterei uma linha sequer?"
A maioria imagina que seja:
o disco;
o Db2;
o CICS;
a rede;
o operador;
o compilador;
ou simplesmente "o mainframe está lento".
Na enorme maioria das vezes...
não é nada disso.
Existe um "cérebro invisível" tomando decisões milhares de vezes por segundo.
Ele observa:
CPU
Memória
I/O
Prioridades
Objetivos de negócio
Tempo de resposta
Importância das aplicações
E decide quem executa primeiro.
Esse cérebro chama-se WLM (Workload Manager).
Para um programador COBOL iniciante, entender o WLM muda completamente a forma de enxergar o IBM Z.
Hoje vamos descobrir por que.
Pegue seu café.
O Dr. Spock já está olhando desconfiado para uma fila de jobs no JES2.
Antes de tudo...
O que é um Workload?
A palavra Workload significa literalmente:
Carga de trabalho.
No IBM Z isso representa:
um programa COBOL
um CICS
uma transação IMS
um job batch
uma consulta Db2
uma API
um Java
um processo USS
Tudo isso compete pelos mesmos recursos.
Imagine um restaurante.
Entram ao mesmo tempo:
um cliente querendo um café
outro querendo um almoço
outro querendo um banquete
outro apenas pagar a conta
O restaurante precisa decidir:
Quem atender primeiro?
O IBM Z faz exatamente isso.
A origem do problema
Nos anos 60 e 70 era simples.
Existiam poucos jobs.
Poucos usuários.
Pouca memória.
Pouca CPU.
O sistema executava praticamente por ordem de chegada.
Funcionava.
Até deixar de funcionar.
Década de 80
As empresas cresceram.
Agora existiam:
folha de pagamento
cartões de crédito
reservas aéreas
bancos
bolsa de valores
Todos queriam CPU.
Ao mesmo tempo.
Imagine um banco.
08:00
Milhões de clientes entrando.
Ao mesmo tempo.
Quem recebe CPU?
A impressão do relatório?
Ou o PIX?
A resposta parece óbvia.
Mas alguém precisa decidir isso automaticamente.
Nasce o WLM
A IBM criou o Workload Manager.
A ideia era revolucionária.
Ao invés de dizer:
"Este job possui prioridade 7."
Passou-se a dizer:
"Quero que esta aplicação responda em menos de 0,5 segundo."
Perceba a diferença.
O administrador não fala mais COMO.
Ele fala O OBJETIVO.
Quem decide como alcançar esse objetivo é o WLM.
Isso foi um enorme avanço em relação aos antigos esquemas de prioridade fixa.
O Dr. Spock explica
Imagine a USS Enterprise.
Temos:
Motor Warp
Escudos
Sensores
Transporte
Holodeck
Refeitório
Todos querem energia.
Agora imagine:
Os Klingons atacam.
O computador pergunta:
"Capitão, onde envio energia?"
Spock responde imediatamente:
"Escudos primeiro."
Não porque gosta dos escudos.
Mas porque são mais importantes naquele momento.
O WLM faz exatamente isso.
Como o WLM enxerga o sistema?
Ele observa constantemente:
CPU
Memória
Disco
Canal
Rede
Db2
CICS
IMS
USS
Java
Batch
Tudo.
Em tempo real.
Centenas de vezes por segundo.
O conceito mais importante
Objetivos
O WLM trabalha baseado em objetivos.
Exemplo.
Aplicação bancária.
Objetivo:
95% das transações
devem responder
em até
0,3 segundo.
Outro sistema.
Relatórios batch.
Objetivo:
Finalizar antes das 06:00.
Outro.
Carga estatística.
Objetivo:
Executar apenas quando houver CPU livre.
Percebe?
Nem tudo possui a mesma importância.
Classes de Serviço
O WLM agrupa workloads em:
Service Classes
Exemplo.
Classe 1
PIX
Classe 2
ATM
Classe 3
Internet Banking
Classe 4
Relatórios
Classe 5
Testes
Cada uma possui metas diferentes.
Importance
Além da meta existe outro conceito.
Importance.
Vai de:
1
até
Onde
1
é a mais importante.
Imagine:
Pagamento instantâneo.
Importance 1.
Relatório mensal.
Importance 5.
Quem recebe CPU primeiro?
Obviamente.
Importance 1.
Velocity
Nem todo sistema mede tempo.
Alguns medem:
Velocity.
É quanto tempo uma aplicação consegue trabalhar sem ficar esperando recursos.
Quanto maior.
Melhor.
Response Time
Muito usado no:
CICS
IMS
APIs
Db2
Objetivo:
Responder rapidamente.
Execution Velocity
Mais comum em:
Batch
Long Running Jobs
Como o WLM decide?
Ele calcula algo chamado:
Performance Index
PI.
PI=1
Meta atingida.
PI menor que 1
Melhor que esperado.
PI maior que 1
Está atrasado.
Quanto maior o PI.
Mais recursos ele tende a receber.
O que acontece quando falta CPU?
Imagine.
100 programas.
Apenas 10 CPUs disponíveis.
Quem roda?
O WLM faz cálculos.
Avalia:
Objetivos
Importância
Fila
Tempo
Uso
Espera
E redistribui recursos.
Automaticamente.
O programador COBOL percebe isso?
Sim.
Muito.
Imagine este JCL.
//STEP01 EXEC PGM=FINANCE
Ontem.
3 minutos.
Hoje.
11 minutos.
O programa está igual.
O JCL está igual.
O Load Module está igual.
O Db2 está igual.
Mudou apenas:
O ambiente.
Mais workloads competindo.
O WLM redistribuiu CPU.
Um exemplo prático
Durante a madrugada.
Executam:
Backup
RUNSTATS
REORG
COPY
SORT
Folha
Faturamento
Fechamento financeiro
Seu programa COBOL entra.
O WLM percebe que existem workloads mais importantes.
Seu job espera.
Não porque esteja errado.
Mas porque alguém é mais prioritário.
Batch também usa WLM?
Sim.
Muita gente pensa que WLM serve apenas para CICS.
Erro clássico.
Batch também é controlado.
Inclusive:
JES2
Db2 Utilities
SORT
COBOL
PLI
Assembler
Todos.
O impacto no COBOL
Seu programa pode sofrer:
Menos CPU
Mais CPU
Mais espera
Mais concorrência
Mais I/O
Maior paralelismo
Tudo sem alterar uma linha.
O impacto no JCL
O JCL não conversa diretamente com o WLM.
Mas define:
Job Class
MSGCLASS
Initiator
Região
Scheduler
Todos esses elementos acabam influenciando como o workload será classificado.
Exemplo.
//JOB CLASS=A
Dependendo da instalação.
Classe A
Pode ser crítica.
Ou baixa prioridade.
Cada empresa configura diferente.
CICS
Quando um cliente faz:
EXEC CICS READ
O WLM acompanha.
Se a resposta está demorando.
Pode aumentar recursos para aquela região.
IMS
O mesmo ocorre.
Principalmente em transações OLTP.
Db2
Consultas críticas.
Podem ganhar mais CPU.
Consultas analíticas.
Podem esperar.
Sysplex
Agora imagine.
Quatro IBM Z.
Executando juntos.
Quem distribui a carga?
O WLM.
Ele conversa com:
Sysplex.
XCF.
LM.
PR/SM.
Hipersockets.
Tudo integrado.
Relação com o PR/SM
Outro detalhe interessante.
Existe um "WLM dentro do hardware."
Na verdade.
O WLM conversa com o PR/SM.
O hardware então redistribui capacidade entre LPARs.
É um verdadeiro diálogo entre software e firmware.
Um passo a passo mental para entender
Imagine:
Seu JCL entra no JES2.
↓
Aguarda Initiator.
↓
Começa a executar.
↓
O WLM identifica sua classe.
↓
Descobre seu objetivo.
↓
Mede seu desempenho.
↓
Calcula PI.
↓
Decide dar mais ou menos CPU.
↓
Continua monitorando.
↓
Repete tudo continuamente.
Dicas para o programador COBOL
Não culpe imediatamente o programa
Se ficou lento.
Veja:
Foi apenas hoje?
Só nesse horário?
Outros jobs também ficaram lentos?
Observe concorrência
Talvez o problema seja:
Backup
RUNSTATS
COPY
REORG
Compressão
Carga massiva
Consulte o operador
Pergunte:
"Houve alguma alteração de workload?"
Essa simples pergunta demonstra maturidade técnica.
Não aumente REGION sem motivo
Mais memória.
Nem sempre.
Mais desempenho.
SQL ruim continua ruim
O WLM não faz milagres.
Ele apenas distribui recursos.
CPU não resolve algoritmo ruim
Código:
PERFORM 10000000 TIMES
Continuará ruim.
Mesmo com prioridade máxima.
Problemas comuns
Job demora apenas em determinados horários
Normalmente.
Concorrência.
CICS lento somente às 10h
Pico de usuários.
Batch muito variável
Disputa por recursos.
PI elevado
Objetivos não sendo atendidos.
Espera de I/O
O gargalo não é CPU.
Como investigar?
Ferramentas comuns:
RMF
SMF
SDSF
IBM OMEGAMON
IBM Z Performance and Capacity Analytics
Resource Measurement Facility Reports
São elas que mostram onde o tempo realmente foi gasto.
Curiosidades
O WLM é considerado um dos maiores diferenciais do IBM Z.
Enquanto muitos sistemas operacionais ainda trabalham com prioridades relativamente estáticas, o z/OS ajusta dinamicamente a alocação de recursos para cumprir objetivos de negócio.
Em grandes bancos, seguradoras e companhias aéreas, essa inteligência permite que milhões de transações críticas coexistam com cargas batch sem intervenção manual constante.
Easter Eggs
Easter Egg 1
O WLM raramente recebe reconhecimento.
Quando tudo funciona, ninguém lembra dele.
Quando algo atrasa...
Todo mundo lembra.
É como Scotty na Enterprise: se o motor Warp está perfeito, ninguém comenta; basta um problema para todos chamarem o engenheiro.
Easter Egg 2
O WLM nunca "gosta" de um programa.
Ele apenas executa cálculos.
Isso combina perfeitamente com a filosofia vulcana de Spock:
"A lógica deve prevalecer sobre a emoção."
Easter Egg 3
Muitos programadores passam anos acreditando que aumentar a prioridade do job resolve qualquer lentidão.
Spock provavelmente responderia:
"Uma prioridade maior não cria mais CPU. Apenas muda quem espera."
Vantagens do WLM
Distribuição inteligente de CPU, memória e I/O.
Priorização por objetivos de negócio, não apenas por prioridade fixa.
Melhor aproveitamento do hardware IBM Z.
Redução da intervenção manual dos operadores.
Maior previsibilidade para aplicações críticas.
Integração com Parallel Sysplex e PR/SM.
Balanceamento dinâmico entre workloads.
Escalabilidade para milhares de workloads simultâneos.
Melhor experiência para usuários finais.
Uso eficiente de recursos mesmo em horários de pico.
Conclusão
Para o programador COBOL padawan, o WLM pode parecer invisível, mas ele influencia diretamente o comportamento de praticamente todo programa executado no z/OS. Um mesmo executável pode apresentar tempos completamente diferentes dependendo da carga do sistema, das metas definidas para sua classe de serviço e das prioridades de negócio vigentes naquele instante.
Compreender conceitos como workload, Service Class, Importance, Response Time, Velocity e Performance Index (PI) ajuda a separar problemas de infraestrutura de problemas de programação. Muitas vezes, o código COBOL está correto; o que mudou foi o ambiente ao seu redor.
Na visão do Dr. Spock, o WLM é o oficial de operações da Enterprise: ele não favorece aplicações por preferência, mas por lógica. Se uma transação financeira precisa responder em frações de segundo enquanto um relatório pode esperar alguns minutos, essa é exatamente a decisão que o WLM tomará, milhares de vezes por segundo, mantendo o IBM Z equilibrado, eficiente e alinhado aos objetivos do negócio.
No fim das contas, aprender WLM é deixar de enxergar apenas o programa COBOL e começar a compreender o ecossistema completo do mainframe. É perceber que um bom desenvolvedor não escreve apenas código eficiente; ele entende como esse código convive com milhares de outros programas, compartilhando recursos em um dos sistemas operacionais mais sofisticados já criados. Esse é um dos passos que transforma um padawan em um verdadeiro mestre do IBM Z.
