 |
| 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:
A auditoria executa:
O RH imprime:
O marketing gera:
A segurança inicia:
Os DBAs:
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:
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:
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.
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:
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.
