Bellacosa Mainframe apresenta caçando os vilões em zos performance tuning

🍔💾 Essential z/OS Performance Tuning Workshop achando os vilões

Versão técnica: RMF, SMF e a arte de não tunar errado

O Essential z/OS Performance Tuning Workshop separa, logo de cara, dois tipos de profissionais:

1. Quem acha que faz performance tuning

2. Quem sabe onde olhar primeiro

Essa versão é para o segundo grupo — ou para quem quer migrar do 1️⃣ para o 2️⃣ sem trauma.

---

🎯 Regra zero do workshop

Nunca comece pelo parâmetro. Comece pela observação.

Antes de qualquer ALTER, DEFINE ou SET:

• Qual workload?

• Qual período?

• O que mudou?

• Existe baseline?

Sem isso, tuning vira superstição técnica.

---

🧠 CPU: o falso vilão

Onde olhar no RMF

RMF CPU Activity Report (Postprocessor)

Campos clássicos:

• % Busy

• % LPAR Utilization

• % Logical Processor Dispatch

• % IFA / zIIP / zAAP (quando aplicável)

Interpretação que o workshop ensina

• CPU alta com response time estável → sistema saudável

• CPU média com response time degradando → gargalo fora da CPU

• CPU baixa + atraso → WLM ou I/O

📌 Easter egg técnico:
Se o LPAR Delay cresce, não é falta de tuning — é falta de peso ou política errada.

---

⚙️ WLM: tuning começa aqui, não no SYS1.PARMLIB

RMF Workload Activity Report

Campos críticos:

• Service Class Period

• Velocity

• Average Response Time

• Delay Reasons

Exemplo típico visto no workshop:

Service Class: ONLINE_HI
Velocity Goal: 50
Achieved Velocity: 12
Delay: I/O 65%, Enqueue 20%

👉 Conclusão correta:

• Não adianta subir prioridade

• Não adianta mexer em CPU

• O gargalo não é WLM, é dependência externa

💡 Lição central:

WLM não resolve gargalo físico. Ele apenas escolhe quem sofre primeiro.

---

📊 RMF Monitor III: o “agora dói aqui”

Uso correto (e erro comum)

Monitor III serve para:

• Incidente ativo

• Observação em tempo real

• Confirmação de suspeita

Não serve para:

• Análise histórica

• Decisão estrutural

• Justificativa pós-morte

Campos típicos:

• Address Space Delay

• Device Response Time

• Enqueue Waits

📌 Erro clássico:
Usar Monitor III como prova definitiva em reunião de causa raiz.

---

🗃️ SMF: onde a discussão acaba

SMF 30 – Address Space Accounting

Usado para responder:

• Quem consumiu CPU?

• Quanto?

• Em qual período?

Exemplo prático:

SMF30:
CPU Time: baixo
Elapsed Time: alto

👉 Indício claro:

• Espera externa

• I/O

• Lock

• Dependência de outro job

---

SMF 70 / 72 – CPU e WLM

SMF 72 é o coração do tuning orientado a SLA.

Campos essenciais:

• Service Class Performance Index

• Delay Breakdown

• Period Transitions

📌 Easter egg de workshop:
Performance Index < 1.0 não é vitória se o response time continua ruim.

---

SMF 74 – I/O e Storage

Onde muitos problemas se revelam.

Campos observados:

• Device Response Time

• Pending Time

• Channel Utilization

Exemplo clássico:

• CPU “sobrando”

• Response time alto

• 3390 com Pending elevado

👉 Solução raramente é tuning de parâmetro.
Normalmente é layout, cache, storage tier ou concorrência mal planejada.

---

⚠️ Casos clássicos discutidos no workshop

🔥 “O batch atrasou tudo”

RMF mostra:

• Batch em baixa prioridade

• Online atrasando

SMF revela:

• Batch segurando enqueue crítico

• Online esperando lock

👉 Ajuste correto:

• Revisar serialização

• Reavaliar janela batch

• Não subir prioridade às cegas

---

🔥 “Depois da mudança ficou lento”

Primeira pergunta ensinada no workshop:

Qual foi o último change?

Sem resposta clara:

• tuning suspenso

• investigação começa

📌 Lição dura:

Performance tuning não corrige change mal feito.
Ele só mascara — até piorar.

---

🚀 O que o workshop realmente forma

Não forma “tuner de parâmetro”.
Forma analista de comportamento do sistema.

Quem sai sabendo:

• Correlacionar RMF + SMF

• Defender decisão com dados

• Evitar tuning destrutivo

• Criar baseline útil

No CPD, isso vira reputação.

---

🧠 Frase final  

“RMF mostra o sintoma.
SMF mostra a causa.
WLM executa a decisão — certa ou errada.”

O Essential z/OS Performance Tuning Workshop não ensina atalhos.
Ensina responsabilidade técnica em ambiente onde erro custa caro.

🧪 Plano de Tuning Batch COBOL – IBM Mainframe

 

🧪 Plano de Tuning Batch

COBOL – IBM Mainframe

“Batch lento não é destino, é diagnóstico.”

---

🟥 FASE 0 — PRINCÍPIO SAGRADO

❌ Nunca tune sem medir
❌ Nunca mude tudo de uma vez
❌ Nunca confie só em elapsed time

---

🟦 FASE 1 — IDENTIFICAÇÃO DO PROBLEMA

🎯 Objetivo

Descobrir ONDE o batch gasta tempo:

• CPU?

• I/O?

• Espera?

• Lock?

• Storage?

📌 Ações

☑ Identificar JOB / STEP problemático
☑ Horário de execução
☑ Pico ou fora do pico

🔧 Ferramentas

• SMF 30 (Job)

• SMF 72 (CPU)

• OMEGAMON

• RMF

• SDSF (CPU TIME)

💬 Fofoquinha:

Batch “lento” às vezes só roda no horário errado.

---

🟨 FASE 2 — CPU vs ELAPSED (o divisor de águas)

Situação	Diagnóstico
CPU alto / Elapsed baixo	Código ruim
CPU baixo / Elapsed alto	I/O, lock, espera
Ambos altos	Tudo errado

☑ Compare:

• CPU TIME

• EXCP

• SRB vs TCB

---

🟩 FASE 3 — ANÁLISE DE CPU (quando a conta dói)

🧠 Verificar compilação COBOL

☑ Parâmetros:

OPTIMIZE(2)
TRUNC(BIN)
ARITH(EXTEND)
DATA(31)
RULES

☑ Evitar:

• NUMCHECK em produção sem necessidade

• SSRANGE

• INITCHECK

📉 Ganho típico: 5% a 30%

---

🟪 FASE 4 — CÓDIGO COBOL (o crime mais comum)

🔪 Pontos clássicos de CPU alta

☑ DISPLAY em loop
☑ MOVE repetido
☑ IF aninhado
☑ PERFORM THRU
☑ Conversão implícita de tipos

💡 Melhoria

• Código linear

• Parágrafos curtos

• Cálculo com COMP/COMP-5

🥚 Easter egg:

Um DISPLAY por registro já custou mais que licença de compilador.

---

🟧 FASE 5 — I/O (onde o tempo some)

📊 Analisar

• EXCP alto

• WAIT I/O

• VSAM CI/CA mal dimensionado

☑ Ajustes

• Buffers maiores

• Redução de leitura repetida

• SORT externo em vez de interno

📉 Ganho típico: 10% a 50% de elapsed

---

🟫 FASE 6 — SORT (o vilão invisível)

☑ Verificar:

• SORT interno vs DFSORT

• Quantidade de registros

• Campos de chave

💣 Erro comum:

SORT interno com milhões de registros sem tuning.

☑ Preferir:

EXEC PGM=SORT

---

🟥 FASE 7 — JCL (ninguém olha, mas paga)

☑ Revisar:

• REGION exagerado

• STEPLIB duplicado

• Programas obsoletos rodando

☑ Ajustar:

• DISP correto

• CONCATENATION mínima

• DD redundante removido

---

🟦 FASE 8 — PARALELISMO E JANELA

☑ Avaliar:

• Jobs sequenciais sem dependência

• Execução fora do pico

• Divisão por partição lógica

💬 Fofoquinha:

Batch mais rápido é o que não disputa CPU.

---

🟩 FASE 9 — zIIP / LE (dinheiro dormindo)

☑ Verificar:

• LE habilitado

• Versão do COBOL

• Ambiente preparado

📉 Offload possível:

• XML

• JSON

• Serviços

• Partes do LE

---

🟪 FASE 10 — MEDIR NOVAMENTE (o momento da verdade)

☑ Comparar:

• CPU antes/depois

• Elapsed antes/depois

• EXCP antes/depois

• SMF

☑ Documentar:

• Mudança aplicada

• Ganho real

• Risco

---

☠️ ERROS QUE ARRUÍNAM O TUNING

Erro	Consequência
Mudar tudo de uma vez	Incidente
Não medir SMF	Ilusão
Otimizar DEV só	Nenhum ganho real
Ignorar I/O	Elapsed explode
Culpar o mainframe	Vergonha técnica

---

🎓 RESUMO PADAWAN

✔ Batch lento tem causa
✔ CPU não mente
✔ Código importa
✔ I/O mata
✔ JCL conta
✔ zIIP salva

---

🧠 FRASE FINAL BELLACOSA™

“Tuning não é mágica.
É respeito à máquina.”