Bellacosa Mainframe analise o triangulo da performance no Mainframe

💥 🧠 VISÃO GERAL — O TRIÂNGULO DA PERFORMANCE

👉 Em 90% dos problemas reais:

• COBOL → lógica
• VSAM → I/O
• DB2 → acesso a dados

---

🔥 1. TUNING COBOL — CPU (o assassino silencioso)

🎯 Problema típico

• CPU alto
• EXEC alto no sampling

---

🧨 Anti-patterns clássicos

❌ Loop ineficiente

PERFORM UNTIL WS-END = 'Y'
   READ FILE
END-PERFORM

---

❌ Reprocessamento desnecessário

• Mesmo cálculo várias vezes
• Falta de cache em memória

---

✅ Boas práticas

✔ Reduzir chamadas repetidas

IF WS-CALCULATED = 'N'
   PERFORM CALC
END-IF

---

✔ Usar tabelas em memória (lookup)

• Evita I/O repetido

---

✔ Minimizar chamadas externas

• DB2
• VSAM
• APIs

---

💣 Insight

COBOL lento raramente é COBOL…
geralmente é acesso a dados mal feito

---

🐢 2. TUNING VSAM — I/O (o vilão invisível)

🎯 Problema típico

• WAIT alto
• I/O dominante no sampling

---

🧨 Problemas clássicos

❌ Acesso aleatório excessivo

• KSDS sem chave eficiente

---

❌ CI/CA splits

• Dataset mal definido

---

❌ Buffer insuficiente

• Muitas operações físicas

---

✅ Boas práticas

✔ Aumentar buffers

• BUFNI / BUFND

---

✔ Acesso sequencial sempre que possível

• Evitar random

---

✔ Ajustar definição do dataset

• CI size
• CA size

---

✔ Usar READ NEXT quando possível

READ FILE NEXT RECORD

---

💥 Insight

VSAM mal configurado transforma CPU em WAIT

---

🗄️ 3. TUNING DB2 — O campeão de problemas

🎯 Problema típico

• WAIT alto
• CPU alto distribuído
• SQL dominante

---

🧨 Problemas clássicos

❌ Full table scan

• Falta de índice

---

❌ SQL executado milhares de vezes

PERFORM 10000 TIMES
   EXEC SQL SELECT ...
END-EXEC

---

❌ Falta de filtro adequado

• WHERE mal definido

---

✅ Boas práticas

✔ Criar índices corretos

• Baseado no WHERE

---

✔ Reduzir chamadas SQL

• Buscar em bloco
• Usar cursor

---

✔ Evitar SELECT dentro de loop

👉 mover lógica para fora

---

✔ Usar EXPLAIN

• Ver access path

---

💣 Insight

1 SQL ruim pode destruir toda a performance

---

🔗 4. INTEGRAÇÃO (onde mora o problema real)

💥 Cenário clássico

COBOL → chama DB2 → DB2 faz I/O → VSAM/disco

---

🧠 Diagnóstico via sampling

Sintoma	Causa
CPU alto	COBOL
WAIT alto	VSAM
CPU + WAIT	DB2

---

🔥 5. CASO REAL COMPLETO

🎯 Sintoma

• Job lento
• 2 horas de execução

---

📊 Sampling mostra

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

---

🧠 Diagnóstico

👉 Problema NÃO é COBOL
👉 É acesso a dados

---

🔧 Ações

• Criar índice DB2
• Reduzir chamadas SQL
• Ajustar VSAM

---

🚀 Resultado

• Tempo: 2h → 20min
  💥 ganho de 6x

---

⚡ 6. CHECKLIST RÁPIDO (produção)

1. CPU ou WAIT?
2. Identificar hotspot
3. COBOL → otimizar lógica
4. VSAM → otimizar I/O
5. DB2 → otimizar SQL
6. Validar com nova coleta

---

💣 ERROS QUE MAIS VEJO EM PRODUÇÃO

❌ Ajustar COBOL sem olhar DB2
❌ Culpar DB2 sem olhar VSAM
❌ Ignorar I/O
❌ Não usar sampling

---

🧠 MODELO MENTAL FINAL

COBOL = processamento
VSAM  = acesso físico
DB2   = acesso lógico

---

💥 FRASE FINAL (nível arquiteto)

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

 

 

Bellacosa Mainframe apresenta um estudo de caso para performance em Mainframe

💥 🔬 PERFORMANCE RELATÓRIO — VISÃO GERAL

PROGRAM MEASURED   - PROG001
JOB NAME           - JOB001
STEP NAME          - P010.S010

---

🧠 O que isso já diz?

👉 Você está analisando:

• Programa: PROG001
• Job: JOB001
• Step específico

💡 Ótimo sinal → análise já está refinada (não é genérica)

---

⚙️ 🔍 BLOCO 1 — Measurement Parameters

ESTIMATED SESSION TIME  - 30 MIN
TARGET SAMPLE SIZE      - 30,000

---

🧠 Interpretação

👉 Configuração padrão profissional:

• 30 min
• 1000 samples/min

✔ Excelente equilíbrio entre precisão e overhead

---

💣 Insight

Se isso estivesse errado → TODO o relatório seria suspeito

---

📊 🔥 BLOCO 2 — Measurement Statistics

EXEC TIME PERCENT - 90.84
WAIT TIME PERCENT - 9.16

---

🧠 Diagnóstico IMEDIATO

👉 Sistema está:

• 90% executando (CPU)
• 9% esperando

---

💥 Conclusão direta

✔ CPU-bound
❌ NÃO é problema de I/O
❌ NÃO é lock
❌ NÃO é DB2 wait

---

🎯 Ação

👉 Investigar:

• Código COBOL
• Algoritmo
• Loop
• Cálculo repetitivo

---

⚖️ 🔬 BLOCO 3 — Margem de erro

RUN MARGIN OF ERROR  - 0.65
CPU MARGIN OF ERROR  - 0.68
WAIT MARGIN OF ERROR - 2.16

---

🧠 Interpretação

👉 Estatisticamente confiável

Valor	Qualidade
< 1%	excelente
< 5%	confiável

---

💣 Insight

Você pode confiar nesse diagnóstico sem medo

---

🔢 📈 BLOCO 4 — Samples

TOTAL SAMPLES TAKEN     - 37,549
TOTAL SAMPLES PROCESSED - 22,548

---

🧠 Interpretação

👉 Nem todos os samples foram úteis

Possíveis motivos:

• CPU idle
• Outro address space
• Thread não relevante

---

💡 Insight

Isso é NORMAL — e esperado

---

⏱️ 📉 BLOCO 5 — Sampling Rate

INITIAL SAMPLING RATE - 8.33/sec
FINAL SAMPLING RATE   - 4.17/sec

---

🧠 Interpretação

👉 Taxa caiu ao longo do tempo

Possíveis causas:

• Mudança de carga
• Menos CPU ativa
• Contenção

---

💥 Insight

Sampling não é constante — ele reflete o ambiente real

---

🧾 🔍 BLOCO 6 — Ambiente

ADDRESS SPACE ID - 0061
DATE/TIME        - execução real
CONDITION CODE   - C-0000

---

🧠 Interpretação

✔ Job terminou OK
✔ Sem abend
✔ Ambiente válido

---

🔥 🔬 DIAGNÓSTICO FINAL

📊 Resumo técnico

CPU → 90%
WAIT → 10%
Erro → baixo
Samples → suficientes

---

🎯 Conclusão

💥 O problema está NO CÓDIGO, não no ambiente

---

💣 Possíveis causas reais

👉 Aqui começa o trabalho do especialista:

🔥 1. Loop ineficiente

PERFORM UNTIL ...

---

🔥 2. Leitura repetitiva

• VSAM read desnecessário
• DB2 repetido

---

🔥 3. Cálculo pesado

• Reprocessamento
• Falta de cache

---

🔥 4. Algoritmo ruim

• Complexidade alta
• Ordenação ineficiente

---

🚀 Próximo passo (o que você faria em produção)

1. Abrir relatório detalhado (modules)
2. Identificar:
   • módulo
   • offset
3. Mapear para código COBOL
4. Ajustar lógica

---

🧠 Modelo mental definitivo

EXEC alto → código
WAIT alto → recurso externo

---

💥 Frase final (nível especialista)

“O relatório já te deu a resposta.
Agora é você que precisa ir até o código.”