 |
| Bellacosa Mainframe e o IBM Capacity e suas diversas ferrmaentas |
☕ Um Café no Bellacosa Mainframe
☕ CSI: New York Entra no Data Center — O Caso do Pico de CPU que Não Estava na CPU
Ou: como um programador COBOL iniciante descobre que capacity no mainframe não é comprar processador, que SMF guarda impressões digitais, que OMEGAMON vê o crime acontecendo e que um REXX lendo logs pode virar tanto um laboratório forense quanto um belo desastre em produção
Imagine a abertura de CSI: New York: sirenes refletindo nos prédios de Manhattan, uma equipe isolando a cena do crime, Mac Taylor olhando para uma evidência minúscula e dizendo algo como: “Não procurem apenas o que aconteceu. Procurem o que deixou rastros.”
Agora troque Manhattan por uma sala com um IBM Z. Troque o cadáver por um fechamento mensal lento. Troque a mancha de sangue por um pico no R4HA. E coloque, no centro da cena, um programa COBOL que alguém jurou ser “só uma alteração simples”.
Bem-vindo ao estranho e caro universo de capacity management.
Para quem começa em COBOL, capacidade parece uma conversa distante, reservada ao povo que fala em MSU, LPAR, SCRT, capping, zIIP e fatura de software como quem comenta a previsão do tempo. Mas não é distante. Um PERFORM mal desenhado, um READ repetido, um SELECT Db2 sem índice, um sort desnecessário ou um batch agendado na hora errada podem se transformar em CPU, espera, atraso de SLA e dinheiro.
E, no mainframe, dinheiro costuma deixar rastro.
A cena do crime: o que é capacity, afinal?
Capacity é a capacidade de o ambiente entregar o serviço que o negócio espera, no momento em que ele precisa, sem desperdiçar recursos nem comprar potência como quem joga dinheiro pela janela.
Não é apenas “CPU disponível”.
Se uma LPAR fica em 95% de CPU por dez minutos de madrugada, mas nenhum batch perde janela e nenhum usuário sofre, talvez seja perfeitamente aceitável. Se ela fica em 55% de CPU às 10h30, mas o CICS demora, o Db2 acumula espera, os caixas travam e o aplicativo móvel dá timeout, há um problema sério — embora o gráfico de CPU média tente inocentar o ambiente.
Essa é a primeira lição do CSI Mainframe:
CPU alta não é automaticamente culpada. CPU baixa não é automaticamente inocente.
O capacity planner, o sysprog, o DBA, a operação e o desenvolvedor precisam olhar a história inteira:
O serviço foi entregue dentro do SLA?
Qual workload sofreu?
Houve espera por CPU, disco, memória, lock Db2, rede ou fila?
O WLM priorizou corretamente o que era importante?
O pico foi eventual, recorrente ou previsível?
Houve impacto no consumo de MSU e no custo de software?
É preciso ajustar código, SQL, WLM, agenda batch, hardware ou contrato?
Em outras palavras: capacity é performance, disponibilidade, previsão e custo sentados na mesma mesa — quase sempre discutindo quem derrubou a produção.
O cadáver chamado “média mensal de CPU”
Um erro clássico é alguém abrir um relatório e declarar:
“A CPU média do mês foi 43%. Não precisamos nos preocupar.”
Mac Taylor levantaria uma sobrancelha.
Média é uma estatística útil, mas também é ótima para esconder picos. Imagine que um restaurante receba quatro clientes por hora durante vinte e três horas e, à noite, receba duas mil pessoas de uma vez. A média diária pode dizer que o movimento foi tranquilo; a cozinha, porém, terá uma opinião bastante diferente.
No IBM Z, o problema costuma aparecer em intervalos críticos: fechamento contábil, pagamento de folha, processamento de PIX, abertura de mercado, campanha de varejo, virada de dia, cargas de integração ou aquela execução “temporária” que alguém deixou rodando desde 2019.
É por isso que capacity olha para séries históricas, picos por intervalo, comportamento por LPAR e principalmente para a relação entre recursos e serviço entregue.
Em ambientes com cobrança baseada em capacidade, surge um personagem digno de CSI: o R4HA, ou Rolling Four-Hour Average. De maneira simplificada, ele acompanha uma média móvel de quatro horas de uso de capacidade. Não é uma conta de padaria, nem deve ser interpretado sem considerar o contrato da empresa, mas ele explica por que um pico prolongado pode deixar uma marca financeira muito maior do que uma explosão curta de CPU.
A pergunta deixa de ser “a CPU ficou alta?” e passa a ser:
“Durante quanto tempo, em qual LPAR, com qual workload, por qual causa e a que custo?”
O laboratório: SMF, RMF e os rastros digitais
Em CSI, um fio de cabelo pode ligar suspeito, lugar e horário. No z/OS, os rastros aparecem principalmente em SMF e RMF.
O SMF — System Management Facilities — é o grande livro de ocorrências do z/OS. Ele registra eventos e medições de muitos componentes. Há registros ligados a jobs, segurança, CICS, Db2, uso de recursos e muito mais.
O RMF — Resource Measurement Facility — é a ferramenta de medição de recursos do z/OS. Ele observa CPU, memória, I/O, WLM e outros sinais vitais. Em vez de perguntar ao sistema “você está bem?”, RMF faz exames periódicos e devolve números.
Para o iniciante, pense assim:
| Elemento | Analogia CSI: NY | No z/OS |
|---|---|---|
| SMF | Livro de evidências | Registros de eventos e contabilidade |
| RMF | Monitor cardíaco e tomografia | Medição de recursos e performance |
| WLM | Central que decide prioridade | Define objetivos e prioridade dos workloads |
| SCRT | Perito financeiro | Gera dados associados à cobrança de software |
| SMF 30 | Ficha de atividade de job | Dados de execução e accounting de batch |
| SMF 70–79 | Sensores do prédio | Dados RMF de CPU, memória, I/O e afins |
| SMF 100/101/102 | Laudo do Db2 | Informações úteis de Db2 e accounting |
| SMF 110 | Relatório da cena CICS | Dados de transações e performance CICS |
| SMF 80 | Registro de acesso | Auditoria de segurança RACF |
Não é preciso decorar todos os tipos de SMF numa tarde. Mas é essencial compreender que eles não são “logs de texto” bonitinhos. Muitos registros são binários, possuem seções variáveis, versões e campos que evoluem com o produto. Abrir um SMF bruto e tentar interpretar tudo com um EXECIO de REXX, sem conhecer o layout, é como pegar uma amostra de DNA e analisá-la com uma régua escolar.
Pode funcionar para algo muito específico? Pode. É a primeira escolha para uma plataforma corporativa? Normalmente, não.
Os suspeitos do questionário: quem faz o quê?
A pesquisa mostrava nomes como zPCA, Zetaly, IntelliMagic, MICS, TMON, BMC AMI Capacity and Cost e solução caseira. Eles convivem no mesmo bairro, mas não exercem a mesma função.
IBM Z Performance and Capacity Analytics: o arquivo central do caso
O IBM Z Performance and Capacity Analytics, frequentemente chamado de ZPCA ou, informalmente, izPCA, trabalha com histórico, relatórios, tendências e planejamento. É uma ferramenta adequada para juntar dados, analisar uso passado, comparar previsão com realizado e discutir cenários futuros.
Ela responde perguntas como:
Nosso crescimento de transações pede mais capacidade no próximo ano?
Esta LPAR está crescendo de forma normal ou mudou depois de um release?
O que ocorre se movermos uma carga de trabalho?
Quais recursos estão chegando ao limite?
O que foi previsto no trimestre e o que realmente aconteceu?
É a sala onde se olha o filme inteiro, não apenas o frame da queda.
Sua vantagem é estar próxima do ecossistema IBM Z e trabalhar com disciplina de capacity. A desvantagem é exigir instalação, modelagem, coleta adequada e gente que saiba interpretar resultados. Ferramenta de capacity sem processo vira uma biblioteca cheia de relatórios que ninguém abre.
IntelliMagic Vision: a parede de telas, mas com cérebro
O IBM Z IntelliMagic Vision se destaca pela análise visual, tendências, dashboards e identificação de riscos. É útil quando o time precisa transformar uma montanha de dados em perguntas navegáveis.
Em vez de entregar ao analista iniciante 900 páginas de relatórios RMF e dizer “descubra por que o online ficou lento”, a solução ajuda a explorar:
onde ocorreu desvio do padrão;
qual LPAR mudou;
quando um recurso começou a degradar;
que subsistema acompanhou a alteração;
quais tendências indicam risco futuro.
Seu ponto forte é acelerar a investigação. Sua limitação é a mesma de toda ferramenta inteligente: ela mostra sinais e correlações; não substitui o raciocínio de quem conhece o negócio e a arquitetura.
Se o consumo cresce toda Black Friday, isso não é necessariamente anomalia. Se cresce em uma terça-feira comum após um novo SELECT, aí já há uma impressão digital interessante.
MICS: o arquivo histórico que conhece a cidade inteira
O MICS, tradicionalmente associado ao universo CA/Broadcom, é uma solução histórica e profunda para coleta, organização e análise de dados de performance e capacidade.
Ele tem a reputação do investigador veterano: talvez não chegue usando um painel moderno cheio de animações, mas conhece o histórico da cidade, os padrões de anos e a origem de quase todo relatório.
É forte em ambientes grandes, consolidação de informações, tendência, accounting e análises corporativas. Porém exige conhecimento. Não é uma ferramenta que se domina com dois cliques e entusiasmo de estagiário.
Uma empresa que mantém MICS bem administrado possui um patrimônio técnico. O desafio não é descartá-lo porque parece antigo; é garantir que seus dados possam ser entendidos, consultados e apresentados à nova geração.
TMON: o policial na rua
O TMON se aproxima mais do monitoramento operacional e da análise de performance no momento do evento. Ele ajuda a responder: “o que está acontecendo agora?”
Isso é valioso. Quando a produção reclama, não há tempo para esperar o planejamento trimestral. É preciso olhar transações, recursos, filas, uso de CPU, esperas e sintomas.
Mas monitoramento não é igual a planejamento de capacidade.
TMON pode ajudar a capturar o incidente e entender o comportamento imediato. Para planejar hardware, custo e crescimento para os próximos meses, você precisa armazenar, consolidar, comparar e prever — normalmente com uma camada adicional de dados e processo.
BMC AMI Capacity and Cost: quando o laudo encontra a fatura
A família BMC AMI Capacity Management trabalha com reporting, previsão, consumo e custo. Ela ganha força sobretudo em lojas que já usam BMC AMI Ops ou CMF, pois há integração entre a observação operacional e a análise de capacidade.
Ela é importante quando a conversa deixa de ser apenas técnica:
“Este pico foi necessário para o negócio ou foi desperdício de software mal desenhado?”
Essa pergunta é ouro. Às vezes o consumo é inevitável: crescimento real, novo produto, aquisição de outra empresa, volume maior de transações. Outras vezes, há desperdício: SQL regressivo, trabalho batch mal distribuído, falta de offload, código repetindo I/O, WLM mal configurado ou workload colocado na LPAR errada.
Atenção: cortar custo com capping agressivo pode parecer vitória até o primeiro SLA perdido. Economia técnica que derruba pagamento, folha ou atendimento não é otimização; é um ABEND financeiro.
Zetaly: o consultor que pergunta “quanto vai custar?”
A Zetaly tem uma abordagem bastante voltada à relação entre capacidade, previsão, cenário e FinOps de mainframe. É interessante quando a organização precisa simular crescimento, mudança de hardware, redistribuição de workloads ou orçamento de MLC.
Ela é útil para perguntas de diretoria:
Se crescer 20%, quanto isso exige de capacidade?
Se consolidarmos LPARs, qual efeito técnico e financeiro?
Se adquirirmos uma empresa, qual será o consumo?
Qual cenário atende SLA com menor custo?
Mas nenhuma simulação salva hipótese ruim. Se o Business Analyst sabe que haverá uma campanha capaz de dobrar o volume e o modelo recebe “crescimento de 5%”, o resultado pode sair impecável, cheio de gráficos, aprovado em reunião — e completamente errado.
OMEGAMON, APA e Xpediter: não são capacity planners, mas são ótimos peritos
Aqui mora uma distinção importante.
O IBM OMEGAMON é um monitor operacional e de performance. Ele observa o ambiente em tempo real ou quase real: z/OS, CICS, Db2, IMS, MQ, redes, storage e outros componentes, conforme os módulos licenciados.
Pergunta que ele ajuda a responder:
“O que está ruim agora, onde e com qual sintoma?”
O IBM Application Performance Analyzer (APA) investiga uma aplicação em profundidade. Ele pode ajudar a identificar onde um programa COBOL, PL/I, Java ou Assembler está consumindo tempo de CPU, realizando I/O, chamando rotinas repetidamente ou ficando em espera.
Pergunta típica:
“Qual trecho deste programa está queimando CPU?”
Já o Xpediter/Expeditor — hoje associado ao universo BMC, dependendo do produto e nomenclatura adotados pela empresa — é mais ligado a depuração e diagnóstico de programas, especialmente COBOL, CICS, Db2 e batch.
Pergunta típica:
“Por que este programa falhou, produziu dado errado ou se comportou de modo inesperado?”
Eles não substituem ZPCA, MICS, BMC AMI Capacity ou Zetaly. São complementares.
Veja um caso:
Às 10h15, usuários reclamam que o aplicativo móvel está lento.
O OMEGAMON revela pressão em CICS/Db2 e filas crescendo.
O APA mostra que uma rotina COBOL recém-alterada elevou fortemente o CPU por transação.
O DBA encontra um acesso Db2 menos eficiente.
O time corrige a lógica ou o índice.
A ferramenta de capacity analisa se o evento alterou R4HA, tendência e custo mensal.
A empresa evita comprar capacidade para compensar uma falha de aplicação.
OMEGAMON vê o carro batendo. APA abre o motor. Xpediter ajuda quando o carro explodiu. Capacity planning decide se a cidade precisa de uma avenida maior — ou se basta consertar o semáforo.
A solução caseira: REXX lendo SMF?
Sim. E ela pode ser muito boa — se for tratada como produto, não como gambiarra heroica.
Uma solução caseira típica poderia ser:
SMF / RMF / SCRT
↓
IFASMFDP seleciona registros
↓
JCL agenda extração e tratamento
↓
COBOL, SAS ou utilitário interpreta dados complexos
↓
REXX orquestra, valida e dispara relatórios
↓
Db2 guarda histórico
↓
Power BI, Excel, Grafana ou portal interno mostra tendênciasO REXX é excelente como maestro: recebe parâmetros, monta JCL, verifica retornos, chama utilitários, organiza datasets, valida datas, produz alertas e automatiza rotinas.
Mas REXX não precisa carregar sozinho o piano de cauda.
Ler SMF binário diretamente em REXX pode ser pesado, frágil e difícil de manter. Para grandes volumes, é comum usar:
IFASMFDPpara filtrar os registros necessários;RMF Postprocessor para gerar relatórios e extratos;
DFSORT/ICETOOL para seleção e transformação;
COBOL, PL/I ou Assembler para parsing estruturado;
SAS, se a empresa já tiver esse ecossistema;
Db2 para histórico, consultas e integração;
REXX para controlar o fluxo;
ferramentas modernas de visualização para a camada final.
O erro seria tentar construir, sozinho e escondido, um “MICS de garagem” sem documentação, sem controle de versão, sem validação e sem sucessor.
Uma solução caseira madura deve ter:
coleta automática;
documentação dos campos e cálculos;
retenção definida;
validação contra RMF, SCRT e eventos conhecidos;
segurança RACF para dados sensíveis;
controle de mudanças;
cálculo reproduzível;
pelo menos duas pessoas capazes de mantê-la;
comparação entre previsão e realizado.
Se apenas uma pessoa sabe ajustar a planilha ou o REXX, aquilo não é uma plataforma. É um single point of failure com café.
Passo a passo para começar sem cometer um S0C7 metodológico
Para um programador COBOL iniciante, o caminho não é tentar modelar toda a capacidade do banco no primeiro dia. Comece por uma investigação pequena e útil.
Passo 1: escolha uma pergunta concreta
Não comece com “vamos analisar todos os SMFs da empresa”.
Comece com:
Qual job batch mais consome CPU?
Qual é a janela de pico de uma LPAR?
O uso de zIIP está adequado?
Qual classe WLM perde objetivo?
O fechamento mensal mudou após uma alteração?
Qual programa COBOL aumentou o tempo de execução?
Pergunta ruim gera relatório grande. Pergunta boa gera decisão.
Passo 2: descubra os dados disponíveis
Converse com performance, sysprog, operação e DBA. Pergunte quais SMF/RMF existem, qual retenção há, se há SCRT, se existem relatórios RMF e quais ferramentas já estão instaladas.
Antes de criar mais um dashboard, descubra se alguém já resolveu 80% do problema em MICS, OMEGAMON, BMC, IntelliMagic ou ZPCA.
Passo 3: encontre um evento conhecido
Escolha uma data em que houve lentidão, atraso batch ou aumento de consumo. Eventos conhecidos são perfeitos para validar sua análise. Se o relatório disser que tudo estava ótimo quando a produção claramente estava sofrendo, o relatório está olhando para a métrica errada, intervalo errado ou fonte errada.
Passo 4: relacione recurso e serviço
Não basta dizer “CPU estava alta”. Procure relacionar:
CPU e response time;
zIIP e spillback;
I/O e tempo de job;
Db2 e transações CICS;
WLM e objetivos de serviço;
batch e janela de execução;
pico de uso e R4HA.
É nessa ligação que o analista deixa de ser leitor de gráfico e passa a ser investigador.
Passo 5: proponha uma ação verificável
Uma análise madura termina com ação e verificação:
ajustar SQL ou índice;
reduzir I/O repetitivo em COBOL;
alterar prioridade WLM;
mover ou escalonar batch;
revisar utilização de zIIP;
ajustar capacidade;
rever capping;
atualizar forecast.
Depois, meça novamente. Em CSI, teoria sem prova não fecha o caso. Em produção, mudança sem medição vira folclore.
Easter egg: o COBOL pode estar no laudo, não no banco dos réus
Há uma brincadeira injusta segundo a qual “COBOL consome muito”. COBOL não consome capacidade por existir; ele executa a lógica que alguém pediu.
Um programa COBOL pode ser extremamente eficiente e previsível. Outro pode fazer um READ em loop inadequado, repetir acesso Db2, classificar arquivos demais, chamar módulos desnecessariamente ou manter uma tabela em memória de modo desastroso.
O culpado não é a linguagem. É o desenho.
E isso vale para Java, Python, C#, SQL, scripts shell, qualquer coisa. Um programa ruim em linguagem moderna continua ruim; apenas apresenta o desperdício em JSON.
Conclusão: não compre CPU antes de ler a cena
Capacity management em IBM Z é a disciplina de observar recursos, entender workloads, cumprir SLA, prever crescimento e controlar custo. Ele precisa de ferramentas, mas sobretudo de método.
OMEGAMON ajuda a enxergar o incidente. APA ajuda a descobrir qual programa está gastando demais. Xpediter ajuda a depurar e entender falhas. SMF e RMF guardam os rastros. ZPCA, MICS, IntelliMagic, BMC AMI e Zetaly organizam partes diferentes da investigação e do planejamento. Uma solução caseira com REXX pode ser excelente, desde que seja automatizada, documentada, validada e sobrevivente à ausência do seu criador.
O programador COBOL que aprende essa visão deixa de enxergar seu PROGRAM-ID como uma ilha. Ele entende que cada READ, cada SQL, cada sort, cada chamada CICS e cada decisão de algoritmo entra em uma cadeia maior: serviço, consumo, custo e reputação da produção.
Mac Taylor talvez resumisse assim, diante de um gráfico de CPU aparentemente inocente:
“Não foi a máquina que ficou cara. Foi alguém que deixou um rastro — e o SMF estava olhando.”
