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:

1. Às 10h15, usuários reclamam que o aplicativo móvel está lento.

2. O OMEGAMON revela pressão em CICS/Db2 e filas crescendo.

3. O APA mostra que uma rotina COBOL recém-alterada elevou fortemente o CPU por transação.

4. O DBA encontra um acesso Db2 menos eficiente.

5. O time corrige a lógica ou o índice.

6. A ferramenta de capacity analisa se o evento alterou R4HA, tendência e custo mensal.

7. 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ências

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

• IFASMFDP para 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.”