🔥💣 “O MAINFRAME NÃO FICOU CARO — VOCÊ É QUE DEIXOU O 4HRA VIRAR UM INCÊNDIO” ☕💾

 

Bellacosa Mainframe e o custo medio de uso do mainframe 4HRA

🔥💣 “O MAINFRAME NÃO FICOU CARO — VOCÊ É QUE DEIXOU O R4HA VIRAR UM INCÊNDIO” ☕💾

Rolling 4HRA no IBM Z: A Verdade Brutal que Todo Sysprog Junior Descobre Quando o CPU Começa a Derreter

Padawan…

Existe um momento sombrio na vida de todo SYSprog junior.

Um momento em que:

• o CPU começa a subir,

• o RMF vira filme de terror,

• o DBA começa a suar frio,

• o gerente pergunta sobre custos,

• e alguém pronuncia uma sigla maldita dentro da sala de guerra:

🚨 R4HA

Ou:

🔥 Rolling 4-Hour Average

Nesse instante…

Você deixa de ser apenas “o cara que olha JES2 e IPL”.

E começa a entender a realidade brutal do mundo IBM Z moderno:

O maior inimigo do mainframe não é a falta de potência.

É workload mal otimizado queimando MSU como se CPU fosse lenha.

---

☕ O GRANDE MITO: “MAINFRAME É CARO”

Padawan…

O IBM Z não ficou caro por acaso.

O problema é que muita empresa roda:

• SQL desastroso,

• batch sem controle,

• SORT monstruoso,

• loops infinitos,

• CICS mal desenhado,

• e workloads completamente desequilibrados.

Depois olha para a conta mensal e diz:

• “o mainframe custa caro”.

É como culpar a usina elétrica porque alguém deixou um forno industrial ligado dentro da garagem.

---

🔥 O QUE É O ROLLING 4HRA?

O Rolling 4HRA é:

• uma média móvel de consumo de CPU/MSU das últimas 4 horas.

Mas dizer só isso é simplificar demais.

Na prática ele é:

💀 O SENSOR FINANCEIRO DO DATACENTER

Porque ele mede:

• consumo sustentado,

• pressão operacional,

• tendência de carga,

• risco financeiro,

• e eficiência arquitetural do ambiente.

---

💾 O MAINFRAME NÃO TEM MEDO DE PICOS

Esse é o detalhe genial do modelo IBM Z.

O sistema foi construído para absorver:

• explosões de workload,

• fechamento bancário,

• Black Friday,

• processamento massivo,

• milhões de transações.

O problema nunca foi:

• o pico curto.

O problema é:

🔥 O INCÊNDIO CONTÍNUO

É aí que o R4HA entra.

---

☕ A FILOSOFIA POR TRÁS DO R4HA

Imagine um motor Ferrari.

Uma acelerada rápida:

• não destrói o motor.

Mas manter:

• giro máximo,

• temperatura extrema,

• pressão contínua,

• por horas…

Aí o sistema começa a sofrer.

O Rolling 4HRA existe justamente para medir:

• desgaste sustentado.

---

🚨 POR QUE A IBM USA ISSO?

Porque seria injusto cobrar:

• pelo pico de alguns minutos.

Então o ecossistema IBM criou:

• média móvel de 4 horas.

Isso suaviza:

• explosões temporárias,

• spikes pequenos,

• ruídos operacionais.

Mas também revela:

• workloads persistentemente ruins.

---

🔥 E É AQUI QUE O SYSprog PADAWAN ACORDA PARA A VIDA

Você percebe que:

• CPU não é apenas CPU.

Ela virou:

• dinheiro,

• licensing,

• SLA,

• capacidade,

• reputação operacional.

No IBM Z moderno:

💰 MSU = DINHEIRO

---

💣 QUANDO O DESASTRE COMEÇA

Tudo parece normal.

Até que alguém sobe:

• um SQL sem índice,

• um tablespace scan monstruoso,

• um batch paralelo sem controle,

• um SORT insano,

• um COBOL looping,

• um CICS runaway task.

Aí…

O CPU começa a subir.

Mas o verdadeiro terror ainda nem começou.

---

☕ O “EFEITO VENENO” DO R4HA

Esse conceito separa:

• o junior do veterano.

Porque mesmo depois de corrigir o problema:

• o R4HA continua alto.

E o padawan pergunta:

“Mas já cancelamos o job… por que continua ruim?”

Porque o Rolling 4HRA:

• ainda está carregando o histórico do desastre.

---

🔥 O R4HA TEM MEMÓRIA

Ele funciona como:

• uma onda de calor.

Mesmo após apagar o incêndio:

• o ambiente continua quente.

Isso gera:

• impacto financeiro,

• impacto operacional,

• pressão no capacity planning.

---

💾 O ERRO CLÁSSICO DOS JUNIORS

Confundir:

• CPU instantânea
  com

• Rolling 4HRA.

São coisas completamente diferentes.

Você pode ter:

• CPU baixa AGORA,

• mas R4HA altíssimo.

Porque a média móvel ainda está contaminada pelas horas anteriores.

---

🚨 O QUE MAIS INCENDIA O R4HA?

🔥 DB2

Aqui mora um dos maiores vilões do datacenter.

Um único SQL ruim pode:

• destruir cache,

• explodir SORT,

• aumentar GETPAGE,

• saturar CPU,

• gerar scan absurdo.

E tudo isso:

• alimenta o R4HA.

---

🔥 CICS

Quando mal desenhado:

• vira um triturador de MSU.

Problemas clássicos:

• pseudo-conversational ruim,

• polling excessivo,

• loops de transação,

• runaway tasks,

• filas gigantes.

---

🔥 BATCH

O batch mal otimizado é um clássico.

Especialmente:

• DFSORT gigantesco,

• JOINKEYS abusivo,

• I/O thrashing,

• múltiplos jobs concorrentes.

O resultado:

💀 tempestade de CPU

---

☕ O WLM TENTA SALVAR O AMBIENTE

O WLM funciona como:

• o maestro do caos.

Ele tenta:

• priorizar workloads,

• proteger online,

• equilibrar recursos,

• manter SLA.

Mas quando:

• tudo começa a consumir demais…

Nem o WLM faz milagre.

---

🔥 SOFT CAPPING: A FACA DE DOIS GUMES

Então alguém diz:

“Vamos limitar MSU!”

Aí nasce o:

💣 Soft Capping

Objetivo:

• evitar explosão financeira.

Mas se configurado errado:

• batch atrasa,

• online degrada,

• filas explodem,

• SLA morre.

---

💾 O PARADOXO DO SYSprog

Se libera CPU:
💰 custo explode.

Se limita demais:
💀 produção explode.

Esse equilíbrio delicado é uma das artes mais difíceis do IBM Z.

---

🚨 O QUE O SYSprog EXPERIENCED APRENDE

Ele aprende que performance tuning não é:

• “deixar rápido”.

É:

🔥 impedir o datacenter de sangrar dinheiro

---

☕ O MAINFRAME MODERNO É UMA MÁQUINA DE EFICIÊNCIA

O IBM Z moderno:

• processa milhões de TPS,

• roda bancos inteiros,

• suporta cloud híbrida,

• executa IA,

• integra APIs,

• conversa com Kubernetes,

• roda Linux massivamente.

O hardware é absurdamente poderoso.

O problema normalmente está:

• no workload.

---

💣 O MAINFRAME NÃO ESTÁ LENTO

Na maioria dos casos:

• o ambiente está sendo sabotado por software ruim.

E o Rolling 4HRA:

• apenas revela isso de forma cruel.

---

🔥 O DIA EM QUE O PADAWAN EVOLUI

A evolução acontece quando ele entende:

tuning não é estética

Não é:

• “ganhar benchmark”.

É:

• sobrevivência financeira,

• estabilidade operacional,

• sustentabilidade do ambiente.

---

☕ RMF: O ORÁCULO DO IBM Z

O SYSprog veterano aprende a ler:

• RMF,

• SMF 70,

• SMF 72,

• OMEGAMON,

• MXG,

• IntelliMagic.

Porque nesses relatórios está:

• a verdade do ambiente.

O R4HA conta uma história.

E essa história normalmente aponta:

• quem está incendiando CPU.

---

🔥 O MAINFRAME CONTINUA SENDO O REI

E aqui está a ironia maravilhosa.

Mesmo sob caos:

• milhões de transações continuam funcionando,

• ATM continua online,

• PIX continua passando,

• cartão continua autorizando,

• folha continua fechando.

Enquanto isso…

• o IBM Z aguenta pancada absurda silenciosamente.

---

💾 A GRANDE VERDADE

O problema nunca foi:

• a potência do mainframe.

O problema é:

• arquitetura ruim,

• SQL ruim,

• falta de governança,

• tuning inexistente,

• e desconhecimento sobre workload management.

---

☕ LIÇÃO FINAL DO PADAWAN IBM Z

Quando você olha um Rolling 4HRA:

• você não está vendo apenas CPU.

Você está vendo:

• comportamento do ambiente,

• disciplina operacional,

• maturidade técnica,

• eficiência arquitetural,

• e o custo real das decisões ruins.

---

🔥 FRASE FINAL ESTILO BELLACOSA MAINFRAME

“O IBM Z não cobra caro por existir.
Ele apenas expõe, em MSU e R4HA, todas as decisões ruins que alguém colocou em produção.” ☕💾🔥

---

🔥 Rollinf 4HRA

 O Rolling 4HRA (Rolling 4-Hour Average) é a média móvel de consumo de capacidade do mainframe IBM Z durante as últimas quatro horas. Ele mede o uso sustentado de CPU e MSU, sendo utilizado pelo WLM, RMF e modelos de licenciamento IBM para calcular custos e avaliar performance do ambiente. Diferente do uso instantâneo de CPU, o 4HRA continua elevado mesmo após um pico terminar, refletindo impactos anteriores no workload. Por isso, SQL ruim, batch pesado e loops podem aumentar custos significativamente.

 

 

Bellacosa Mainframe numa visao dos sql joins em db2

☕🔥 SQL JOINs NO DB2 MAINFRAME — A ARTE PERIGOSA DE UNIR TABELAS SEM DERRUBAR A PRODUÇÃO

Existe um momento em que todo desenvolvedor SQL descobre uma verdade assustadora:

👉 Consultar uma tabela é fácil.

🔥 Difícil é unir múltiplas tabelas em ambiente corporativo REAL sem destruir performance.

E no IBM Mainframe DB2 isso ganha outra dimensão.

Porque JOIN no z/OS não é apenas sintaxe.

É:

• engenharia de acesso

• matemática de performance

• estratégia de índices

• controle de I/O

• sobrevivência operacional

---

☕ O QUE MUITA GENTE NÃO ENTENDE SOBRE JOIN

Nos cursos básicos aparece algo assim:

SELECT *
FROM A
INNER JOIN B
ON A.ID = B.ID

Parece simples.

Mas no DB2 Mainframe essa query pode gerar:

🔥 milhões de GETPAGE
🔥 SORTs monstruosos
🔥 CPU elevada
🔥 lock contention
🔥 access path desastroso

---

☕ NO MAINFRAME, JOIN É CIRURGIA

Porque estamos falando de tabelas com:

• bilhões de registros

• múltiplos índices

• concorrência extrema

• milhares de usuários simultâneos

---

☕🔥 INNER JOIN — O “CASAMENTO OBRIGATÓRIO” DO DB2

O INNER JOIN retorna apenas registros que existem nos dois lados.

---

☕ Exemplo clássico

Tabela EMPLOYEE

E001  AKHIL
E002  NIKITA
E003  NIL

Tabela JOIN_DATE

E002  2016-04-18
E003  2016-04-19

---

☕ Query

SELECT
   E.EMP_ID,
   E.FIRST_NAME,
   J.JOINING_DATE
FROM EMPLOYEE E
INNER JOIN JOIN_DATE J
ON E.EMP_ID = J.EMP_ID

---

☕ Resultado

Somente:

E002
E003

Porque apenas esses possuem correspondência.

---

☕ Bellacosa Mainframe Analysis™

INNER JOIN é como:

INTERSEÇÃO DE DATASETS CORPORATIVOS

Só sobrevive quem existe nos dois lados.

---

☕🔥 O ACCESS PATH É O VERDADEIRO REI

O iniciante olha a query.

O DBA Mainframe olha:

🔥 o plano de execução.

---

☕ O DB2 precisa decidir:

• qual tabela acessar primeiro

• qual índice usar

• qual JOIN METHOD aplicar

• se haverá SORT

• se haverá PREFETCH

---

☕ E aqui nasce a magia (ou o desastre)

---

☕🔥 NESTED LOOP JOIN — O “LOOP DENTRO DE LOOP”

Estratégia clássica.

---

☕ Como funciona?

PARA CADA LINHA DA TABELA A
   PROCURE NA TABELA B

---

☕ Excelente para:

✅ pequenos volumes
✅ índices eficientes
✅ buscas seletivas

---

☕ Horrível para:

🔥 tabelas gigantes sem índice.

---

☕ Exemplo mental

É como procurar:

um CPF específico no arquivo do banco.

---

☕🔥 MERGE SCAN JOIN — O MESTRE DOS GRANDES VOLUMES

Agora entramos no território corporativo pesado.

---

☕ Funciona melhor quando:

• dados estão ordenados

• índices ajudam

• clustering está correto

---

☕ O DB2 faz:

TABELA A → ordenada
TABELA B → ordenada

E “caminha” simultaneamente pelas duas.

---

☕ Isso reduz brutalmente:

• I/O

• CPU

• leitura aleatória

---

☕ DBA Mainframe AMA Merge Scan.

---

☕🔥 HYBRID JOIN — O “FRANKENSTEIN” DO OTIMIZADOR

O DB2 mistura estratégias dependendo do cenário.

---

☕ Porque no z/OS:

🔥 performance é dinâmica.

---

☕ O que muda?

• cardinalidade

• RUNSTATS

• distribuição

• volume

• filtro

• índice

---

☕ Mesma query.

☕ Performance completamente diferente.

---

☕🔥 LEFT JOIN — O “TRAGA TUDO DA ESQUERDA”

Agora chegamos numa armadilha clássica.

---

☕ Query

SELECT
   E.NAME,
   J.JOIN_DATE
FROM EMPLOYEE E
LEFT JOIN JOIN_DATE J
ON E.ID = J.ID

---

☕ O que acontece?

Todos os registros da esquerda aparecem.

Mesmo sem correspondência.

---

☕ Resultado possível

AKHIL   NULL
NIKITA  2016

---

☕ Isso é MUITO usado em:

• auditoria

• relatórios

• detecção de ausência

• reconciliação financeira

---

☕🔥 NULL — O FANTASMA CORPORATIVO

Pouca coisa gera mais bugs que NULL.

---

☕ NULL não significa:

ZERO
VAZIO
ESPAÇO

---

☕ NULL significa:

🔥 “valor desconhecido”.

---

☕ E isso muda toda a lógica SQL.

---

☕ Exemplo perigoso

WHERE CAMPO = NULL

ERRADO.

---

☕ Correto:

WHERE CAMPO IS NULL

---

☕🔥 RIGHT JOIN — O “PRIMO ESQUECIDO”

Tecnicamente útil.

Praticamente raro.

---

☕ A maioria dos DBAs prefere:

LEFT JOIN

por legibilidade.

---

☕ Em grandes empresas padronização importa muito.

---

☕🔥 FULL OUTER JOIN — O “CAOS CONTROLADO”

Agora entramos numa operação pesada.

---

☕ FULL JOIN retorna:

✅ registros dos dois lados
✅ combinados ou não

---

☕ Isso é excelente para:

• reconciliação

• comparação

• migração

• auditoria

---

☕ Exemplo clássico bancário

SISTEMA A
vs
SISTEMA B

Detectar:

• faltantes

• inconsistências

• divergências

---

☕🔥 O VERDADEIRO PROBLEMA DOS JOINs

Não é a sintaxe.

É:

🔥 volume.

---

☕ Uma query inocente pode fazer:

JOIN 5 tabelas gigantes

E gerar:

• milhões de linhas intermediárias

• SORTs monstruosos

• WORKFILES enormes

---

☕ Resultado?

Batch explode.

---

☕🔥 WORKFILE — O “INFERNO INVISÍVEL”

Quando DB2 precisa ordenar ou materializar dados:

👉 usa WORKFILE DATABASE.

---

☕ JOIN ruim pode lotar WORKFILE rapidamente.

E aí começa o sofrimento:

• slowdown

• timeout

• degradação

• contenção

---

☕🔥 O SEGREDO DOS DBAs MAINFRAME

O DBA experiente NÃO começa pela query.

Ele começa perguntando:

TEM ÍNDICE?
TEM RUNSTATS?
QUAL A CARDINALIDADE?
QUAL O CLUSTERING?

---

☕ Porque tuning de JOIN é ciência.

---

☕🔥 EXPLAIN — O “RAIO-X” DO DB2

Ferramenta absolutamente crítica.

---

☕ O EXPLAIN mostra:

• access path

• join order

• join method

• índice usado

• custo estimado

---

☕ Sem EXPLAIN…

🔥 você está voando cego no Mainframe.

---

☕🔥 JOIN + COBOL — O CASAMENTO CORPORATIVO

Grande parte do mundo financeiro funciona assim:

COBOL
 ↓
DB2 JOIN
 ↓
CICS / Batch
 ↓
Transação financeira

---

☕ O SQL faz o “trabalho pesado”.

O COBOL orquestra.

---

☕🔥 O QUE O MAINFRAME ENSINA SOBRE SQL

JOIN não é apenas:

ON A.ID = B.ID

JOIN é:

• arquitetura

• performance

• estatística

• engenharia operacional

---

☕ Porque em ambientes críticos:

🔥 uma query mal otimizada pode custar milhões.

---

☕🔥 CONCLUSÃO — SQL JOIN NO DB2 É UMA GUERRA SILENCIOSA

O mundo moderno acha que SQL é apenas linguagem.

O Mainframe sabe que SQL é:

infraestrutura crítica.

E talvez essa seja a maior diferença entre:

• aprender JOIN
  e

• sobreviver ao DB2 z/OS em produção.

Porque no fim…

🔥 unir tabelas é fácil.
Difícil é fazer isso sem derrubar o sistema bancário.

 

Bellacosa Mainframe e a introdução a performance no mainframe

Introdução aos Conceitos de Performance em Mainframe

Quando falamos em Performance em Mainframe, estamos falando da arte e da ciência de fazer com que aplicações, bancos de dados, transações online e processos batch executem com máxima eficiência, consumindo o mínimo possível de recursos computacionais.

No universo IBM Z, performance não significa apenas velocidade. Ela envolve:

✅ Tempo de resposta

✅ Consumo de CPU

✅ Uso de memória

✅ Acesso a disco

✅ Tráfego de rede

✅ Custos de licenciamento

✅ Capacidade futura do ambiente

---

O Que é Performance?

De forma simples:

Performance =
Quantidade de trabalho realizado
÷
Recursos consumidos

Um sistema é considerado eficiente quando consegue processar mais transações utilizando menos recursos.

---

Por Que Performance é Tão Importante?

Em ambientes Mainframe, pequenas melhorias podem representar economias enormes.

Exemplo:

1% de redução de CPU
↓
Menos consumo de MSU
↓
Redução de custos
↓
Economia anual significativa

Por isso, grandes bancos possuem equipes dedicadas exclusivamente à performance.

---

Os Quatro Pilares da Performance

CPU

É o cérebro do Mainframe.

Responsável por executar:

• COBOL

• PL/I

• Java

• CICS

• IMS

• DB2

Exemplo:

CPU = 90%

Pode indicar gargalo.

---

Memória

Armazena programas e dados em execução.

Analisa-se:

• Frames

• Real Storage

• Paging

• Cache

Problemas comuns:

Pouca memória
↓
Paging excessivo
↓
Lentidão

---

I/O (Entrada e Saída)

Envolve:

• Discos

• Storages

• FICON

• VSAM

• DB2

Muitas vezes o gargalo não está na CPU, mas no acesso aos dados.

---

Rede

Hoje os Mainframes estão conectados a:

• APIs

• Cloud

• Mobile

• Open Banking

Logo, performance também envolve:

TCP/IP
OSA
HiperSockets
TLS

---

Conceitos Fundamentais

Tempo de Resposta

Quanto tempo o usuário espera.

Exemplo:

Consulta Saldo
↓
0,3 segundos

Excelente.

---

Throughput

Quantidade de trabalho processado.

Exemplo:

50.000 transações/segundo

---

Latência

Tempo necessário para iniciar uma operação.

Exemplo:

Aplicação
↓
DB2
↓
Resposta

Quanto menor, melhor.

---

Utilização

Percentual de uso de um recurso.

Exemplo:

CPU = 40%

---

Capacidade

Quanto o ambiente suporta antes de saturar.

---

Performance em Batch

Muito importante em Mainframe.

Exemplo:

JOB NOTURNO

Início: 22:00
Fim:    04:00

Objetivo:

22:00
↓
01:30

Menor janela batch.

---

Performance em CICS

Em ambiente online analisa-se:

• Tempo de resposta

• Número de transações

• Esperas

• Locks

Fluxo:

Terminal
↓
CICS
↓
COBOL
↓
DB2

Cada etapa é medida.

---

Performance em DB2

Grande parte dos problemas de performance está no SQL.

Exemplo ruim:

SELECT *
FROM CLIENTES

---

Melhor:

SELECT NOME
FROM CLIENTES
WHERE CPF = ?

---

Aspectos analisados:

• Índices

• Buffer Pools

• Access Path

• Tablespaces

---

Performance em COBOL

Algumas boas práticas:

Evitar Leitura Desnecessária

Ruim:

READ ARQUIVO

milhões de vezes.

---

Carregar Tabelas em Memória

Melhor:

READ UMA VEZ
↓
WORKING-STORAGE

---

Utilizar SEARCH ALL

Mais eficiente que busca sequencial.

---

Reduzir Chamadas ao Banco

Menos SQL significa:

Menos I/O
↓
Mais Performance

---

Principais Gargalos

CPU

Uso excessivo

---

Disco

I/O elevado

---

SQL

Full Table Scan

---

Rede

Latência

---

Aplicação

Loops ineficientes

---

Ferramentas de Performance

RMF

Resource Measurement Facility

Ferramenta nativa do z/OS.

Monitora:

• CPU

• Memória

• I/O

• Rede

---

SMF

System Management Facility

Gera registros estatísticos.

Exemplo:

SMF Type 30
SMF Type 110
SMF Type 101

---

OMEGAMON

Monitoramento em tempo real.

Muito utilizado para:

• CICS

• DB2

• IMS

• z/OS

---

MainView

Solução Broadcom.

---

Capacity Planning

Não basta analisar o presente.

É necessário prever o futuro.

Perguntas comuns:

O ambiente suporta
o crescimento do próximo ano?

---

Avalia:

• CPU

• Memória

• Storage

• Rede

---

MIPS e MSU

MIPS

Million Instructions Per Second

Métrica histórica.

---

MSU

Million Service Units

Mais utilizada atualmente.

---

zIIP e Performance

Os processadores zIIP ajudam a reduzir carga dos CPs.

Executam:

• Java

• XML

• JSON

• DB2

• Analytics

---

Fluxo:

CP
↓
zIIP
↓
Menos CPU

---

Workload Manager (WLM)

Controla prioridades.

Exemplo:

PIX
↓
Alta Prioridade

Relatório
↓
Baixa Prioridade

---

Performance e Cloud

Hoje também envolve:

APIs
OpenShift
Containers
z/OS Connect
LinuxONE

---

O Papel do Analista de Performance

Ele atua como um "médico do Mainframe".

Analisa:

• Sintomas

• Gargalos

• Tendências

• Crescimento

E propõe otimizações.

---

Curiosidade

Muitas das técnicas modernas de observabilidade utilizadas em Cloud Computing possuem origem em conceitos que os profissionais de Mainframe já utilizavam desde as décadas de 1970 e 1980 através de ferramentas como RMF, SMF e monitores de desempenho.

---

Resumo Rápido

Conceito	Objetivo
CPU	Processamento
Memória	Armazenamento temporário
I/O	Acesso a dados
Rede	Comunicação
Throughput	Volume processado
Latência	Tempo de espera
RMF	Monitoramento
SMF	Estatísticas
OMEGAMON	Tempo real
WLM	Priorização
zIIP	Offload de processamento
Capacity Planning	Planejamento futuro

---

Conclusão

Performance em Mainframe é uma disciplina estratégica que busca maximizar a eficiência dos recursos do IBM Z. Ela envolve monitoramento, análise, tuning e planejamento de CPU, memória, I/O, rede, aplicações COBOL, CICS, IMS e DB2. Dominar esses conceitos é fundamental para garantir que ambientes críticos continuem processando milhões de transações com rapidez, estabilidade e o menor custo possível.