✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta Service Class. Mostrar todas as mensagens

sábado, 28 de dezembro de 2024

Workload Manager (WLM) sem Mistérios

☕ 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:

até

Onde

é 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.

sexta-feira, 15 de maio de 2020

CICS Workload Management (WLM) — A Sociedade do Anel e o Guardião Invisível que Decide o Destino das Transações

Bellacosa Mainframe apresenta o cics workload management wlm

☕ Um Café no Bellacosa Mainframe

CICS Workload Management (WLM) — A Sociedade do Anel e o Guardião Invisível que Decide o Destino das Transações

"Um bom rei não governa apenas pela força. Ele sabe onde cada recurso deve ser empregado para que todo o reino prospere."

No universo de O Senhor dos Anéis, poucos personagens percebiam que a guerra contra Sauron não seria vencida apenas por espadas, magia ou coragem. O verdadeiro desafio era administrar recursos extremamente limitados.

Havia poucos exércitos.
Poucos cavalos.
Pouca comida.
Pouco tempo.

Cada decisão precisava colocar os recursos certos no lugar certo.

No mundo do IBM Mainframe, acontece exatamente a mesma coisa.

Milhares de programas executam simultaneamente.

Todos querem CPU.

Todos querem memória.

Todos querem acesso ao disco.

Todos querem prioridade.

Se cada aplicação decidisse sozinha quando executar, o resultado seria um verdadeiro caos, semelhante aos exércitos de Mordor atravessando os portões de Minas Tirith ao mesmo tempo.

É exatamente para impedir esse caos que existe um dos componentes mais inteligentes já criados pela IBM:

Workload Manager (WLM)

Talvez seja um dos softwares mais brilhantes do z/OS e, curiosamente, um dos menos conhecidos pelos programadores COBOL iniciantes.

Hoje faremos uma longa viagem pela Terra Média do Mainframe para entender por que o WLM é considerado o grande estrategista invisível do sistema operacional.

Pegue seu café.

A viagem começa agora.

Capítulo I — O Reino onde Todos Querem a Mesma CPU

Imagine um enorme banco brasileiro.

São exatamente 9 horas da manhã.

Milhões de clientes começam a acessar:

Internet Banking
Aplicativo Mobile
PIX
TED
Cartões
Caixa eletrônico
Agências
Open Finance
APIs
Débito automático

Ao mesmo tempo...

o departamento financeiro inicia:

fechamento contábil

A auditoria executa:

consultas gigantes

O RH imprime:

folhas de pagamento

O marketing gera:

relatórios

A segurança inicia:

varreduras

Os DBAs:

RUNSTATS
REORG
BACKUP

Enquanto isso...

milhares de programas COBOL continuam executando normalmente dentro do CICS.

Todos querem exatamente os mesmos recursos.

Como decidir quem recebe CPU primeiro?

A primeira ideia (que não funciona)

Seria muito simples dizer:

Quem chegou primeiro executa primeiro.

Parece justo.

Mas imagine o seguinte.

Um relatório interno começou um segundo antes de um cliente tentar sacar dinheiro.

O relatório consome CPU durante vários segundos.

O saque precisa esperar.

Resultado?

O cliente pensa que o caixa eletrônico travou.

Na prática, o problema nunca foi falta de CPU.

Foi falta de inteligência para decidir quem deveria utilizá-la primeiro.

Foi exatamente esse problema que deu origem ao WLM.

Capítulo II — O Conselho de Elrond

Na Sociedade do Anel, nenhuma decisão importante era tomada por apenas uma pessoa.

Existia um conselho.

No z/OS também existe um conselho.

Esse conselho chama-se:

Workload Manager.

Toda vez que milhares de tarefas competem pelos recursos do sistema, o WLM analisa a situação antes de distribuir o poder computacional disponível.

Ele não pergunta:

Quem pediu primeiro?

Ele pergunta:

Quem é mais importante para o negócio?

Essa pequena mudança de pensamento revolucionou completamente o gerenciamento de desempenho dos mainframes modernos.

O que realmente é o WLM?

Muitos iniciantes acreditam que o WLM distribui CPU.

Isso é apenas uma pequena parte.

Na realidade, o WLM administra praticamente toda a estratégia operacional do z/OS.

Ele acompanha continuamente:

utilização da CPU
memória
filas
tempo de resposta
tempo de espera
I/O
paging
dispatching
prioridades
utilização das regiões
cumprimento dos SLAs

Enquanto tudo isso acontece...

ele recalcula prioridades diversas vezes por segundo.

É quase como um grande computador de xadrez jogando milhares de partidas simultaneamente.

Capítulo III — Gandalf nunca envia todos para a mesma batalha

Imagine Gandalf recebendo notícias da guerra.

Ele possui apenas:

100 cavaleiros

Mas existem cinco batalhas acontecendo ao mesmo tempo.

Como distribuir?

Ele poderia dizer:

"Cada batalha recebe vinte soldados."

Parece justo.

Mas seria uma decisão terrível.

Se Minas Tirith cair...

não importa que outra batalha tenha vencido.

O reino acabou.

Então Gandalf faz algo diferente.

Ele identifica qual batalha é crítica.

Depois envia a maior parte dos recursos para ela.

É exatamente isso que o WLM faz.

O conceito mais importante: prioridades de negócio

Esse talvez seja o maior choque para quem vem de outras plataformas.

No Windows ou Linux normalmente pensamos:

"Este processo possui prioridade alta."

No z/OS não.

O pensamento é completamente diferente.

O WLM pensa assim:

"Qual atividade gera mais valor para o negócio neste momento?"

Essa diferença muda tudo.

O fluxo completo do WLM

Podemos representar seu funcionamento da seguinte maneira:

Cliente

↓

Transação CICS

↓

Região CICS

↓

z/OS

↓

Workload Manager

↓

CPU

Memória

Disco

I/O

↓

Tempo de Resposta

Observe que o WLM não executa a aplicação.

Quem executa continua sendo:

CICS
Batch
Db2
IMS

O WLM apenas administra os recursos.

É como um maestro.

Ele nunca toca violino.

Mas sem ele a orquestra vira barulho.

Capítulo IV — As Classes da Sociedade

Uma das partes mais importantes do WLM chama-se:

Service Class

Imagine a Sociedade do Anel.

Cada membro possui uma função.

Frodo

Missão crítica.

Sam

Suporte essencial.

Aragorn

Alta prioridade.

Legolas

Ataque rápido.

Gimli

Combate pesado.

Merry e Pippin

Importantes, mas podem esperar alguns segundos em determinadas situações.

No WLM acontece exatamente isso.

Cada tipo de trabalho pertence a uma classe.

Exemplo:

PIX

Meta

200 ms

Importance 1

Saque ATM

Meta

300 ms

Importance 1

Consulta de saldo

Meta

800 ms

Importance 2

Extrato

Meta

2 segundos

Importance 3

Relatórios internos

Meta

30 segundos

Importance 5

Perceba uma curiosidade.

O WLM não pergunta:

"Quem possui prioridade máxima?"

Ele pergunta:

"Quem precisa cumprir determinada meta?"

Essa filosofia recebe o nome de:

Goal-Oriented Management

Curiosidade Bellacosa

O WLM foi um dos primeiros grandes exemplos de computação orientada a objetivos (goal-oriented computing), décadas antes de termos AIOps e sistemas inteligentes modernos.

Em vez de obedecer regras fixas, ele procura continuamente cumprir metas de negócio. É uma ideia que hoje aparece em plataformas de nuvem, orquestradores de containers e sistemas autônomos, mas que já fazia parte do z/OS há muitos anos.

Capítulo V — O Palantír do z/OS

Como o WLM sabe que alguém está sofrendo?

Ele observa tudo.

Literalmente tudo.

Entre centenas de indicadores, ele monitora:

utilização da CPU
filas
espera por I/O
uso da memória
paging
tempo médio
throughput
response time
velocity
dispatch delay
enfileiramentos

É como se o WLM tivesse um Palantír observando continuamente todo o reino.

Enquanto ninguém percebe...

ele está recalculando prioridades.

Importance

Além da meta existe outro conceito extremamente importante.

Importance.

Ela representa o peso daquele serviço.

Imagine duas aplicações.

As duas estão atrasadas.

As duas precisam de CPU.

Quem recebe primeiro?

Aquela cuja Importance é maior.

Normalmente encontramos níveis como:

Importance 1

Missão crítica.

Importance 2

Muito importante.

Importance 3

Importante.

Importance 4

Baixa prioridade.

Importance 5

Background.

O banco durante uma Black Friday

Vamos imaginar um cenário real.

CPU:

99%.

Milhões de acessos.

Ao mesmo tempo chegam:

PIX
consultas
investimentos
relatórios
backups
batch
monitoramento

Sem WLM...

todos brigam igualmente.

Resultado:

lentidão geral
clientes irritados
SLA perdido
prejuízo

Com WLM...

o sistema toma decisões inteligentes.

PIX continua rápido.

Saques continuam rápidos.

Cartões continuam rápidos.

Relatórios esperam.

Backups aguardam.

O cliente sequer percebe que a CPU está completamente ocupada.

Essa é uma das maiores virtudes do WLM: ele não faz milagres, mas faz escolhas inteligentes.

Capítulo VI — O mapa da Terra Média do CICS

Um ambiente CICS corporativo dificilmente possui apenas uma região.

É comum encontrarmos arquiteturas como:

Usuários

↓

TOR

↓

AOR1

↓

AOR2

↓

AOR3

↓

FOR

↓

Db2

Cada região possui suas características.

Algumas executam aplicações.

Outras fazem comunicação.

Outras gerenciam arquivos.

O WLM auxilia a manter esse ambiente equilibrado, trabalhando em conjunto com recursos do CICS e do z/OS para que nenhuma região se torne um gargalo permanente.

CICSPlex SM não é WLM

Este é um erro clássico em entrevistas.

Muitos candidatos confundem os dois produtos.

Na prática:

CICSPlex SM

Gerencia o ambiente CICS.

regiões
roteamento
administração
monitoramento
gerenciamento operacional

WLM

Gerencia os recursos do z/OS.

CPU
prioridades
objetivos
service classes
dispatching

Eles trabalham juntos.

Jamais competem.

O papel do Sysprog

O programador COBOL normalmente não altera políticas de WLM.

Quem faz isso costuma ser o System Programmer (Sysprog) ou o especialista em desempenho.

Ele define:

Service Policies
Service Classes
Goals
Importance
Workloads
Activation Policies

Depois ativa a política.

A partir desse momento o próprio z/OS ajusta continuamente a distribuição de recursos.

O WLM não cria CPU

Existe uma frase muito conhecida entre especialistas em performance:

"Nenhum software produz processadores do nada."

Se o ambiente possui vinte CPUs físicas e a demanda exige quarenta, o WLM não fará mágica.

Ele fará algo muito mais útil.

Garantirá que as aplicações essenciais sobrevivam primeiro.

RMF — O Cronista de Gondor

Depois de definir políticas, surge a pergunta:

Funcionou?

Quem responde é o RMF (Resource Measurement Facility).

Ele registra indicadores como:

utilização da CPU
Response Time
Velocity
Goal Achievement
Delays
Waits

É o RMF que mostra se as metas estabelecidas pelo WLM estão realmente sendo alcançadas.

SMF — O Livro Vermelho do Reino

Enquanto o RMF mede o desempenho, o SMF (System Management Facility) registra a história do sistema.

Cada evento importante deixa rastros.

Esses registros são usados para:

Capacity Planning
Engenharia de Performance
Auditorias
Estudos de tendência
Ajustes de WLM
Investigação de incidentes
Cumprimento de SLAs

Por isso, profissionais de performance frequentemente analisam registros SMF antes de propor qualquer alteração nas políticas de WLM.

Passo a passo: como um especialista ajusta o WLM

Embora o processo varie entre empresas, um fluxo típico é:

Coletar dados com RMF e SMF para entender o comportamento real do ambiente.
Identificar gargalos, verificando quais Service Classes não estão atingindo seus objetivos.
Classificar os workloads de acordo com a importância para o negócio.
Definir ou revisar Goals e Importance, alinhando-os aos SLAs.
Criar ou atualizar a Service Policy utilizando os painéis ISPF ou ferramentas como o z/OSMF.
Ativar a política em um momento controlado.
Monitorar continuamente o impacto das mudanças.
Repetir o ciclo, pois o ambiente de produção evolui constantemente.

O WLM não é configurado uma única vez para sempre; ele acompanha a evolução do negócio.

Dicas para um Programador COBOL Padawan

Se você está começando no mundo do CICS, lembre-se destas lições:

Nem toda lentidão vem do seu programa. Às vezes o código está aguardando CPU, I/O ou recursos disputados.
Aprenda os conceitos de Service Class, Goal, Importance e Service Policy. Eles aparecem com frequência em entrevistas e em projetos corporativos.
Conheça o básico de RMF e SMF. Mesmo sem administrá-los, entender seus relatórios ajuda a conversar com equipes de infraestrutura.
Escreva programas eficientes. Um COBOL bem otimizado reduz consumo de CPU e facilita o trabalho do WLM.
Pense sempre no negócio. Uma transação crítica deve ser projetada para responder rapidamente, pois ela provavelmente estará associada às Service Classes mais importantes.

Curiosidades

O WLM é considerado um dos pilares do conceito de autonomic computing da IBM, pois toma decisões de forma automática para cumprir metas de desempenho.
Muitas ideias usadas atualmente em plataformas de computação em nuvem, como priorização dinâmica de cargas e gerenciamento por objetivos, já estavam presentes no z/OS décadas antes.
Em ambientes financeiros, uma política de WLM bem ajustada pode representar milhões de reais economizados ao evitar a necessidade de ampliar capacidade apenas para absorver picos temporários.
O WLM não conhece o código COBOL; ele enxerga serviços, metas e comportamento do sistema. Isso reforça a importância de integrar desenvolvimento, operações e engenharia de performance.

Easter Egg Bellacosa Mainframe

Imagine que o Anel Único representa a CPU disponível.

Todos querem usá-lo.

Saruman deseja o Anel para dominar a Terra-média.

Sauron deseja o Anel para conquistar todos os povos.

Boromir acredita que poderia utilizá-lo para proteger Gondor.

Mas Gandalf compreende uma verdade fundamental:

O poder absoluto entregue à pessoa errada destrói todo o reino.

O WLM pensa exatamente assim.

Ele nunca entrega todos os recursos para quem simplesmente os solicita primeiro.

Ele entrega recursos para quem mantém o reino funcionando.

No Mainframe, o verdadeiro herói não é o programa que consome mais CPU.

É aquele que entrega valor ao negócio no momento certo, usando apenas os recursos necessários.

Assim como a Sociedade do Anel venceu porque cada integrante cumpriu sua missão, um ambiente CICS de alta disponibilidade permanece saudável porque CPU, memória e I/O são distribuídos com inteligência. O WLM é o guardião silencioso dessa ordem: raramente aparece nos holofotes, mas é um dos principais responsáveis por manter o "reino" do IBM Z funcionando de forma estável, eficiente e preparado para enfrentar até as cargas mais intensas.

quinta-feira, 22 de novembro de 2018

IBM Mainframe Discovery : Capítulo XI — O Almirante Invisível da Frota

Bellacosa Mainframe apresenta ibm mainframe parte xi

☕ Um Café no Bellacosa Mainframe

Capítulo XI — O Almirante Invisível da Frota

Workload Manager (WLM): A Inteligência que Decide Quem Salva a Galáxia Primeiro

OITAVA REGRA DAS GRANDES FROTAS

Se todas as naves tentarem usar o mesmo portal espacial ao mesmo tempo...

...nenhuma chegará ao destino.

Curiosamente, esse problema não existe apenas nas viagens interestelares.

Ele acontece todos os dias em:

bancos;
bolsas de valores;
companhias aéreas;
seguradoras;
hospitais;
governos;
empresas de telecomunicações.

Milhões de pessoas querem utilizar os mesmos recursos.

No mesmo instante.

Existe apenas uma pergunta.

Quem deve ser atendido primeiro?

Responder essa pergunta parece simples.

Até surgirem:

um PIX.

uma cirurgia.

uma compra de ações.

um caixa eletrônico.

uma consulta médica.

uma folha de pagamento.

Tudo exatamente no mesmo segundo.

Bem-vindo ao universo do Workload Manager.

Ou, simplesmente...

WLM.

A Nave Possui Recursos Limitados

Imagine uma gigantesca nave interestelar.

Ela possui:

motores;
energia;
combustível;
hangares;
radares;
processadores.

Mesmo a maior nave da galáxia possui limites.

Agora imagine que, exatamente às 9h da manhã, aconteçam simultaneamente:

uma invasão.

um incêndio.

um casamento.

uma entrega de suprimentos.

uma reunião diplomática.

uma pane elétrica.

Quem recebe prioridade?

Se ninguém decidir...

o caos decide.

O Grande Equívoco

Muitos acreditam que a CPU executa programas simplesmente na ordem em que chegam.

Isso seria como administrar um aeroporto dizendo:

"Quem correr mais embarca primeiro."

Não parece uma boa ideia.

No IBM Z isso nunca aconteceu.

Conheça o Grande Almirante

Imagine um oficial experiente observando centenas de painéis.

Ele acompanha:

uso de CPU.

memória.

discos.

rede.

tempo de resposta.

filas.

prioridades.

temperatura da batalha.

Ele não pilota nenhuma nave.

Mas decide quem recebe recursos.

Esse personagem chama-se:

Workload Manager.

Segundo Wilhelm G. Spruth, o WLM monitora continuamente o comportamento do sistema e ajusta automaticamente a distribuição de recursos para atender objetivos previamente definidos pela organização.

O Erro da Lista de Prioridades

Imagine uma lista.

Banco
RH
Marketing
Desenvolvimento

Parece suficiente.

Não é.

Porque prioridades mudam.

O banco pode ser prioridade máxima durante o expediente.

À meia-noite...

talvez o processamento Batch seja mais importante.

No domingo...

homologação.

Na segunda...

produção.

O WLM entende que o universo muda constantemente.

Objetivos, Não Ordens

Aqui encontramos uma das ideias mais elegantes do Mainframe.

Você não diz:

"Dê exatamente 37% da CPU para este sistema."

Você diz:

"Quero que esta aplicação responda em menos de um segundo."

O restante...

o WLM descobre sozinho.

Essa filosofia ficou conhecida como:

Goal-Oriented Computing.

Em vez de administrar recursos diretamente, o administrador define metas de negócio, e o sistema procura atingi-las da forma mais eficiente possível.

O Restaurante Galáctico

Imagine um restaurante.

Chegam ao mesmo tempo:

um astronauta.

um embaixador.

uma família.

um entregador.

uma equipe médica.

Todos têm fome.

Mas alguns possuem urgência maior.

O gerente reorganiza a fila.

Sem confusão.

Sem injustiça.

O WLM faz exatamente isso.

Service Classes — As Missões da Federação

Imagine que cada missão recebe uma classificação.

Classe Alfa.

Classe Beta.

Classe Gama.

Classe Ômega.

Cada uma possui expectativas diferentes.

No WLM isso recebe o nome de:

Service Class.

Ela representa o nível de serviço esperado para determinado conjunto de aplicações.

Importance — O Peso da Missão

Agora imagine duas emergências.

Uma delas pode esperar cinco minutos.

A outra não.

Como decidir?

O WLM utiliza um conceito chamado:

Importance.

Ele representa o impacto daquela carga de trabalho para o negócio.

Quanto maior sua importância...

maior a atenção recebida.

Velocity — O Ritmo da Cidade

Nem toda aplicação trabalha respondendo rapidamente.

Algumas permanecem esperando:

discos.

rede.

usuários.

Outras precisam executar continuamente.

Para esses casos existe outro conceito.

Velocity.

Ela mede quanto tempo uma carga realmente consegue trabalhar em relação ao tempo que permanece aguardando recursos.

Response Time — O Relógio do Passageiro

Imagine um cliente entrando num banco.

Ele olha para o relógio.

Quanto tempo demorará?

No CICS isso importa muito.

O WLM acompanha constantemente o tempo de resposta das aplicações online.

Caso perceba degradação...

começa a redistribuir recursos.

Antes que usuários reclamem.

O Médico da Frota

Imagine um médico observando milhares de pacientes.

Ele percebe discretamente:

"A pressão daquele piloto começou a subir."

Nada aconteceu.

Ainda.

Mas ele age preventivamente.

O WLM trabalha exatamente assim.

Ele observa tendências.

Não apenas problemas consumados.

O Universo Está Sempre Mudando

Às 10h:

CICS domina a CPU.

À meia-noite:

Batch domina.

Durante backups:

I/O cresce.

Durante fechamento bancário:

Db2 torna-se crítico.

O WLM adapta continuamente a distribuição dos recursos.

Sem necessidade de intervenção manual.

O Capitão Nem Percebe

Uma característica elegante do WLM é sua discrição.

Ele quase nunca aparece.

Usuários não enxergam:

Service Classes.

Velocity.

Importance.

Eles apenas percebem que:

o sistema continua rápido.

Esse é exatamente o objetivo.

A Conversa com o PR/SM

Lembra do capítulo anterior?

Conhecemos o:

PR/SM.

Agora imagine dois grandes comandantes conversando.

O WLM observa:

"Minha missão Alfa precisa de mais CPU."

O PR/SM responde:

"Posso emprestar dois processadores desta outra LPAR."

Essa cooperação permite redistribuição dinâmica de recursos entre partições.

Spruth destaca justamente essa integração entre WLM e PR/SM como uma das forças da arquitetura IBM Z.

Um Aeroporto Inteligente

Imagine um aeroporto.

Uma pista congestionou.

Imediatamente outra é aberta.

Funcionários mudam de posição.

Portões são reorganizados.

Voos são redistribuídos.

Sem reuniões.

Sem telefonemas.

Sem planilhas.

Tudo automaticamente.

Esse é o espírito do WLM.

O Batch Também Importa

Muitos iniciantes pensam que o WLM trabalha apenas com aplicações online.

Não.

Ele também administra:

Jobs.

Started Tasks.

Serviços UNIX.

Db2.

Java.

WebSphere.

Linux on Z.

Tudo entra na mesma grande estratégia.

O Universo Não É Democrático

Esta talvez seja a lição mais difícil.

Nem todas as aplicações possuem a mesma importância.

Imagine uma companhia aérea.

Você prefere priorizar:

o sistema de reservas

o servidor de papéis de parede?

Parece óbvio.

O WLM transforma essa lógica empresarial em decisões técnicas.

Inteligência em Vez de Força

Existe uma filosofia fascinante escondida aqui.

Durante décadas, muitas empresas resolveram problemas comprando servidores maiores.

O IBM Z preferiu outra abordagem.

Primeiro:

organize.

Depois:

otimize.

Só então:

aumente recursos.

O WLM representa exatamente essa filosofia.

O Que Diz Spruth?

Wilhelm G. Spruth destaca que o Workload Manager foi um dos grandes diferenciais do ambiente z/OS porque deslocou a responsabilidade da administração de recursos para um sistema automatizado baseado em objetivos.

Em outras palavras...

o administrador deixa de controlar detalhes técnicos.

Passa a controlar resultados.

O Que Mudou Desde 2010?

Desde que o relatório foi publicado, o WLM tornou-se ainda mais sofisticado.

Hoje ele trabalha em conjunto com:

z/OS Container Extensions;
Linux on IBM Z;
OpenShift;
z/OSMF;
APIs REST;
IA para observabilidade;
automação baseada em políticas;
ambientes híbridos;
métricas em tempo real.

Mas sua filosofia permanece exatamente igual.

Administrar objetivos.

Não processadores.

Uma Lição Para a Vida

Existe um ensinamento escondido neste capítulo.

Imagine um comandante tentando resolver pessoalmente cada pequeno problema da nave.

Ele fracassaria.

Um bom líder estabelece objetivos.

Forma equipes.

Distribui responsabilidades.

Acompanha resultados.

Corrige desvios.

O WLM faz exatamente isso.

Talvez ele seja menos um software...

...e mais uma filosofia de administração.

Curiosidades do Diário de Bordo

🚀 O WLM foi um dos primeiros sistemas comerciais amplamente utilizados a implementar gerenciamento baseado em metas (goal-oriented management), em vez de simples alocação fixa de recursos.

🛰️ Ele consegue adaptar dinamicamente o uso de CPU e outros recursos conforme o comportamento observado das cargas de trabalho.

📊 Conceitos como Service Class, Importance e Velocity transformam necessidades de negócio em decisões automáticas de infraestrutura.

🌌 Muitas plataformas modernas de orquestração e computação em nuvem utilizam princípios semelhantes de políticas e objetivos, ainda que implementados de maneiras diferentes.

Diário de Bordo do Padawan COBOL

Antes de deixar o Centro de Comando Estratégico da Frota, registre estas coordenadas no seu Holocron Técnico:

✅ O Workload Manager não distribui recursos de forma aleatória; ele trabalha para cumprir objetivos definidos pelo negócio.

✅ O WLM observa continuamente o comportamento do sistema e ajusta prioridades sem necessidade de intervenção constante do operador.

✅ A integração entre WLM, PR/SM e LPARs permite que o IBM Z adapte sua capacidade em tempo real conforme a demanda.

✅ Grandes arquiteturas não dependem apenas de hardware poderoso. Elas dependem de inteligência para decidir, a cada microssegundo, qual missão deve ser cumprida primeiro.

Missão Seguinte

No próximo capítulo embarcaremos em uma gigantesca Biblioteca Galáctica de Dados: o Db2 for z/OS.

Descobriremos por que bilhões de registros podem ser consultados em milissegundos, como páginas, buffers, índices e logs trabalham em perfeita harmonia e por que o Db2 é muito mais do que um banco de dados — ele é o guardião da memória de toda uma civilização computacional.

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.