📉 Checklist de Redução de MIPS Pós-Migração COBOL 5.00 — IBM Mainframe

 

📉 Checklist de Redução de MIPS

Pós-Migração COBOL 5.00 — IBM Mainframe

“Migrar é sobreviver. Reduzir MIPS é reinar.”

---

🟥 FASE 1 — MEDIÇÃO (sem medição é fé)

☑ Antes de otimizar, medir

• ☐ SMF 30 / 72 / 110 coletados

• ☐ CPU por job / step

• ☐ Elapsed vs CPU

• ☐ Consumo em horário de pico

☑ Ferramentas

• RMF

• OMEGAMON

• MXG

• SAS

• SMF Dump Analyzer

💬 Fofoquinha:

Time que “acha” que reduziu MIPS geralmente aumentou.

---

🟧 FASE 2 — COMPILAÇÃO INTELIGENTE (ganho rápido)

⚙ Parâmetros que economizam CPU

OPTIMIZE(2)          ← obrigatório
TRUNC(BIN)
ARITH(EXTEND)
RULES
DATA(31)

🧠 Avaliar com cuidado

NUMCHECK(ZON,BIN)
SSRANGE
INITCHECK

📉 Estratégia:

• DEV/QA → ON

• PROD → OFF somente se validado

💣 Erro comum:

Desligar NUMCHECK “pra ganhar CPU” sem limpar código.

---

🟨 FASE 3 — LIMPEZA DE CÓDIGO (onde mora o ouro)

🧹 Remover desperdícios clássicos

☑ DISPLAY em loop
☑ MOVE redundante
☑ IF aninhado desnecessário
☑ PERFORM THRU
☑ WORKING-STORAGE gigante não usada

📉 Impacto:

• ↓ CPU

• ↓ Cache miss

• ↓ Path length

🥚 Easter-egg:

Um DISPLAY esquecido num batch grande já pagou um carro zero.

---

🟦 FASE 4 — ESTRUTURA DO PROGRAMA (pipeline feliz)

☑ Preferir:

• PERFORM único

• Parágrafos curtos

• Fluxo previsível

☑ Evitar:

• GO TO

• PERFORM cruzando seções

• Código “criativo”

🧠 COBOL 5 + z Architecture:

Código linear = melhor uso de pipeline e cache L1/L2

---

🟩 FASE 5 — DADOS E FORMATOS (CPU invisível)

💥 Erros caros

Erro	Custo
DISPLAY usado como cálculo	Alto
COMP mal definido	Médio
REDEFINES abusivo	Alto
Conversão implícita	Altíssimo

☑ Use:

• COMP / COMP-5 corretamente

• PIC consistente

• TRUNC(BIN)

---

🟪 FASE 6 — I/O: O ASSASSINO SILENCIOSO

☑ Minimizar:

• Leitura redundante

• WRITE desnecessário

• SORT interno mal usado

☑ Melhorar:

• Buffers maiores

• Uso correto de SORT externo

• VSAM tuning (CI/CA)

💬 Fofoquinha:

Muitas “otimizações de CPU” são na verdade I/O mal feito.

---

🟫 FASE 7 — JCL E EXECUÇÃO (ninguém olha, mas pesa)

☑ Revisar:

• REGION excessivo

• STEPLIB desnecessário

• Programas antigos ainda rodando

☑ Avaliar:

• Rodar batch pesado fora do pico

• Paralelismo controlado

• zIIP offload

📉 Ganho indireto:

CPU MSU fora do pico = custo menor

---

🟧 FASE 8 — zIIP / Offload (dinheiro esquecido)

☑ Verificar:

• LE habilitado

• Compilação compatível

• Ambiente preparado

📉 O que pode ir pra zIIP:

• XML

• JSON

• Serviços

• Web Services

• Partes do LE

💬 Fofoquinha:

Tem cliente pagando MIPS caro enquanto o zIIP dorme.

---

🟥 FASE 9 — REMOÇÃO DE CHECKS (só depois de adulto)

📌 Sequência correta:

1. NUMCHECK ON

2. Corrigir código

3. Medir estabilidade

4. NUMCHECK OFF

5. Medir MIPS

❌ Pular etapa = incidente garantido

---

☠️ ERROS QUE MATAM ECONOMIA

Erro	Resultado
Otimizar sem SMF	Ilusão
OPTIMIZE(3) sem teste	Bug
Desligar checks cedo	Abend
Ignorar I/O	CPU sobe
Medir só elapsed	Fatura explode

---

🎓 RESUMO PADAWAN

✔ COBOL 5 pode reduzir MIPS
✔ Código limpo = CPU baixa
✔ Compilação correta = ganho imediato
✔ Medição manda, opinião não
✔ zIIP é dinheiro esquecido

---

🧠 FRASE FINAL BELLACOSA™

“Mainframe não é caro.
Caro é código ruim rodando rápido.”

 

🧪 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.”