Bellacosa Mainframe apresenta um checklist para analisar a performance e tuning em Mainframe

💥 🧠 CHECKLIST PROFISSIONAL — SAMPLING PERFORMANCE TUNING

---

🎯 1. IDENTIFICAÇÃO DO PROBLEMA

Antes de sair rodando ferramenta:

✔ CPU alto?
✔ Elapsed alto?
✔ Batch lento?
✔ CICS lento?

---

💡 Pergunta chave

“É CPU ou WAIT?”

---

⚙️ 2. DEFINIÇÃO DO ALVO (TARGET)

Escolha corretamente:

• Job batch
• Região CICS
• Address space DB2

---

🔥 Regra de ouro

✔ Comece amplo (job)
✔ Refinar depois (step / programa)

---

🔬 3. DEFINIR O NÍVEL DE ANÁLISE

🔹 Macro (primeiro passo)

• Job inteiro

🔸 Micro (diagnóstico)

• Step específico
• Programa específico

---

💣 Erro comum

❌ Ir direto para detalhe sem contexto

---

⏱️ 4. CONFIGURAR DURAÇÃO

✔ 15–30 minutos padrão
✔ Batch curto → ajustar

---

💡 Regra

Duração suficiente para capturar comportamento real

---

🔢 5. CONFIGURAR SAMPLES

✔ 1000–1500 samples/min

---

📊 Referência

Samples/min	Qualidade
< 500	ruim
1000	bom
1500+	excelente

---

💣 Erro crítico

❌ Poucos samples → diagnóstico errado
❌ Muitos → overhead desnecessário

---

🔁 6. ATIVAR “MEASURE TO STEP END”

✔ Sempre que possível

---

💡 Use quando:

• Batch imprevisível
• Jobs longos
• Problema intermitente

---

🔗 7. ATIVAR COLETORES CORRETOS

✔ DB2 → se houver SQL
✔ CICS → se for transação
✔ IMS → se aplicável

---

💣 Regra

Ative só o necessário

---

⚠️ Erro comum

❌ Ativar tudo → overhead alto

---

🚀 8. EXECUTAR A SESSÃO

✔ Monitorar status
✔ Aguardar finalizar
✔ Verificar número de samples

---

💣 Nunca faça

❌ Analisar sessão ativa
❌ Analisar com poucos samples

---

📊 9. VALIDAR QUALIDADE DO RELATÓRIO

Antes de confiar:

✔ Samples suficientes?
✔ Margem de erro baixa (<5%)?
✔ Duração adequada?

---

💡 Se não:

👉 Refaça a coleta

---

🔍 10. ANÁLISE PRINCIPAL (CPU vs WAIT)

📊 Interpretação

Situação	Diagnóstico
CPU alto	problema de código
WAIT alto	problema externo

---

🔥 11. IDENTIFICAR HOTSPOTS

Procurar:

• Módulo
• Offset
• Função

---

💡 Pergunta chave

“Quem está consumindo CPU de verdade?”

---

🧱 12. CLASSIFICAR O PROBLEMA

🔥 CPU-bound

• Loop
• Cálculo
• Algoritmo

---

🐢 WAIT-bound

• VSAM I/O
• DB2
• ENQ / lock
• MQ

---

🔬 13. DRILL-DOWN (INVESTIGAÇÃO)

Se CPU:

👉 Ir para código (COBOL / PL/I)

Se WAIT:

👉 Ir para:

• DB2 → SQL
• VSAM → dataset
• Sistema → ENQ

---

🛠️ 14. AÇÃO DE TUNING

🔥 CPU

✔ Reduzir loops
✔ Evitar processamento redundante
✔ Melhorar algoritmos

---

🐢 I/O

✔ Melhorar acesso VSAM
✔ Ajustar buffers
✔ Indexar DB2

---

🔐 LOCK

✔ Reduzir contenção
✔ Ajustar commit

---

🔁 15. VALIDAR RESULTADO

👉 Rodar nova sessão

Comparar:

• CPU antes/depois
• Tempo antes/depois

---

💣 Regra

Sem validação = tuning incompleto

---

📈 16. DOCUMENTAR

✔ Problema
✔ Diagnóstico
✔ Solução
✔ Ganho

---

💡 Isso vira:

• Base de conhecimento
• Aceleração futura

---

🔥 CHECKLIST RÁPIDO (versão bolso)

1. CPU ou WAIT?
2. Definir target
3. Configurar samples (1000/min)
4. Ativar step end
5. Executar sessão
6. Validar samples
7. Analisar CPU vs WAIT
8. Encontrar hotspot
9. Corrigir
10. Validar resultado

---

💣 ERROS QUE MATAM PERFORMANCE (e sua carreira 😅)

❌ Analisar sem dados suficientes
❌ Culpar DB2 sem prova
❌ Ignorar WAIT
❌ Não validar margem de erro
❌ Ajustar “no chute”

---

🧠 FRASE FINAL (nível arquiteto)

“Performance não se melhora com opinião.
Se melhora com evidência.”

 

 

Bellacosa Mainframe apresenta ferramenta de analise performance em z/os

💥 VOCÊ NÃO TEM PROBLEMA DE CPU — VOCÊ TEM FALTA DE VISIBILIDADE

🔬 Sampling Tools no z/OS: O Raio-X que expõe o que seu COBOL está escondendo

Se você é dev COBOL sênior, já viveu isso:

“O batch está lento… deve ser DB2.”
“CPU alta… deve ser o código.”
“Está demorando… talvez seja I/O…”

💣 Spoiler: na maioria das vezes… está todo mundo errado.

E é aqui que entram os Sampling Performance Tools — as ferramentas que transformam achismo em evidência.

---

🧠 Origem — Por que sampling nasceu?

Nos primórdios do mainframe, performance era analisada com:

• Dumps
• Traces pesados
• Logs extensos

Problema?

❌ Alto overhead
❌ Impacto em produção
❌ Volume absurdo de dados

👉 A solução foi genial:

“E se observarmos o sistema em intervalos regulares… e usarmos estatística?”

Assim nasceram ferramentas como:

• Compuware Strobe
• IBM Application Performance Analyzer
• CA Mainframe Application Tuner
• Macro4 FreezeFrame

---

🔬 O conceito que muda tudo

📸 Sampling = tirar fotos da CPU

Imagine:

t1 → COBOL
t2 → DB2
t3 → VSAM
t4 → COBOL

Depois de milhares de amostras:

COBOL → 50%
DB2   → 30%
VSAM  → 20%

💥 Pronto. Você tem a verdade.

---

💣 O maior erro de todo dev COBOL

“Vou otimizar meu código…”

Sem saber:

• onde está o problema
• quanto ele pesa
• se ele é realmente o culpado

👉 Isso é tuning no escuro.

---

🧠 O que o sampling realmente revela

✔ Módulo que consome CPU
✔ Offset (sim, linha lógica!)
✔ WAIT vs EXEC
✔ I/O vs DB2 vs ENQ
✔ System services (SVC, segurança, console)

---

🔥 Easter Egg (que poucos sabem)

🔍 Offset é praticamente um “GPS do bug”

Exemplo:

PROG001 offset X'1A' → 65% CPU

👉 Isso te leva direto para o trecho do COBOL

---

⚙️ Como usar na prática (passo a passo profissional)

1️⃣ Defina o alvo

• Job batch
• Step específico (sempre que possível)

---

2️⃣ Configure corretamente

👉 Regra de ouro:

Samples → 1000 a 1500 por minuto
Duração → 15 a 30 minutos

---

3️⃣ Use “Measure to Step End”

Especialmente para batch:

Nunca confie na duração média

---

4️⃣ Ative apenas coletores necessários

• DB2 → se houver SQL
• CICS → se for online
• MQ → se houver mensagens

💣 Ativar tudo = overhead inútil

---

5️⃣ Execute e aguarde

Nunca analise:

❌ sessão ativa
❌ poucos samples

---

6️⃣ Leia o relatório como um especialista

📊 Caso 1

EXEC 90%
WAIT 10%

👉 Problema = CPU (código)

---

📊 Caso 2

EXEC 30%
WAIT 70%

👉 Problema = recurso externo (VSAM, DB2, lock)

---

🔥 Caso real (estilo produção)

Sintoma

Batch de 2 horas

---

Sampling mostra

DB2 → 60%
COBOL → 25%
VSAM → 15%

---

Diagnóstico

👉 NÃO é COBOL
👉 É SQL

---

Ação

• Criar índice
• Ajustar WHERE
• Reduzir chamadas

---

Resultado

💥 2h → 20 min

---

🐢 VSAM — o vilão silencioso

Sampling revela coisas como:

• CI/CA splits
• excesso de I/O
• buffer ruim

💣 VSAM mal definido destrói performance sem aviso

---

🧠 DB2 — o assassino elegante

Um único SQL pode consumir mais CPU que todo o COBOL

Sampling mostra:

• tempo por SQL
• frequência
• impacto total

---

⚠️ Limitações (que você PRECISA entender)

❌ Não é trace
❌ Não mostra sequência exata
❌ Não mede rede (TCP/IP)
❌ Pode ignorar zIIP (em alguns casos)

---

🔥 Curiosidade (nível insider)

Sampling normalmente foca em CPU “cobrada” (GP)

Se você usa muito:

• zIIP

👉 Pode estar vendo só parte da história

---

💣 Erros clássicos em produção

❌ 100 samples/min → inútil
❌ duração longa (6h) → desperdício
❌ não usar step end → perde o problema
❌ ativar todos coletores → overhead
❌ otimizar COBOL sem olhar DB2

---

🧠 Modelo mental definitivo

Sampling responde:
→ Onde está o problema?
→ Quem está causando?
→ Por quê?

Você resolve:
→ Como corrigir

---

🔥 Frases pra guardar

“Sem sampling, você tem opinião.
Com sampling, você tem evidência.”

---

“CPU alta não é problema.
CPU mal usada é.”

---

“O gargalo não está no código…
está na forma como ele acessa dados.”

---

🚀 Conclusão

Sampling Tools não são só ferramentas.

São:

🧠 Um modelo mental
🎯 Um método de diagnóstico
💥 Um divisor entre júnior e especialista

---

💣 A verdade final

“Você não melhora performance olhando código…
você melhora entendendo comportamento.”