💣🔥 “10 MIL SEGUNDOS ROUBADOS POR DIA: O ASSASSINO SILENCIOSO DO SEU MAINFRAME” 🔥💣 Por que cada milissegundo no z/OS pode ser a diferença entre lucro e caos 🧠 Tradução + Expansão (na veia, sem anestesia) No mundo do processamento de transações em alto volume, “rápido o suficiente” é uma mentira confortável. Quando você roda milhões (ou bilhões) de transações por dia em um ambiente como z/OS, qualquer ineficiência — mesmo microscópica — vira um monstro financeiro. Não importa se você escreve em COBOL, PL/I ou Java. Se o seu código desperdiça tempo, o mainframe cobra — e cobra caro. 👉 Performance tuning não é “nice to have”. 👉 É sobrevivência corporativa. ⚙️ O Efeito Multiplicador (ou: como 10ms viram uma conta absurda) Vamos ao ponto crítico: Você otimiza um trecho e economiza 10 milissegundos. Agora multiplica isso: 1.000.000 execuções por dia Resultado: 👉 10.000 segundos economizados/dia (~2h46min de CPU) Agora entra o mundo real: Menos CPU → menos consumo de MSU Menos MSU → menor custo de licenciamento Menos contenção → mais throughput Mais throughput → mais negócio rodando 💣 Resumo estilo Bellacosa: “Você não economizou milissegundos… você salvou dinheiro REAL.” 🧨 Onde isso explode na prática 💥 Cenário clássico (batch assassino) Um JOB COBOL com loop: PERFORM VARYING WS-I FROM 1 BY 1 UNTIL WS-I > 1000000 EXEC SQL SELECT * INTO :HOST-VAR FROM CLIENTES WHERE ID = :WS-I END-EXEC END-PERFORM 💀 Problemas: SELECT * (crime hediondo) 1 milhão de chamadas SQL Possível table scan 🔧 Cirurgia de performance (passo a passo) 1️⃣ Reduzir dados (SQL cirúrgico) SELECT NOME, STATUS FROM CLIENTES WHERE ID = ? ✔ Menos I/O ✔ Menos CPU ✔ Menos transporte de dados 2️⃣ Garantir acesso via índice Use EXPLAIN no DB2: Evite: TABLE SCAN 😱 Busque: INDEX SEEK 😎 3️⃣ Trocar loop por processamento em bloco 💡 Em vez de 1 milhão de SELECTs: Use cursor Ou fetch em lote 4️⃣ Buffer Pool tuning (ouro puro) Se seu dado é acessado frequentemente: Ajuste buffer pools Evite I/O físico 💣 Easter Egg: Em muitos ambientes, só ajustar buffer pool já deu ganho de 30%+ sem mexer em uma linha de código. 🚀 Quick Wins que parecem pequenos… mas NÃO são 🧩 1. SQL eficiente Nunca use SELECT * Sempre valide acesso via índice Use EXPLAIN como religião ⚡ 2. Compiler moderno (COBOL v6+) Se você ainda usa compilador antigo: 💀 Você está ignorando otimizações do hardware moderno Ganhos comuns: Melhor uso de CPU Otimização automática de loops Instruções mais eficientes 💾 3. Movimento de dados (I/O mata performance) Regra de ouro: “Disco é lento. Memória é rei.” Faça: Cache inteligente Sort interno (quando adequado) Evite leituras repetidas 🧠 Curiosidade de guerra (história real de bastidor) Em um banco: Um único SELECT mal indexado Executado milhões de vezes/dia Resultado após correção: 👉 Redução de MSU suficiente para economizar dezenas de milhares por mês 💣 O código tinha 10 anos em produção 💣 Ninguém questionava 💣 Até alguém olhar com lupa 🔍 Análise profunda (nível arquiteto) Performance no mainframe não é só código. É um ecossistema: CPU (MIPS/MSU) I/O (disco vs memória) Locking (DB2) Concorrência (CICS) Batch window 👉 Uma otimização local pode gerar ganho global 👉 Ou causar efeito colateral (cuidado!) 🧨 Anti-patterns que destroem performance SELECT * Loop com SQL dentro Falta de índice Reprocessamento de dados Leitura repetida de VSAM/DB2 Uso de compilador legado 🏆 O verdadeiro “modernizar o mainframe” Não é só: API Cloud Microservices 💣 Isso é maquiagem se o core estiver ineficiente Modernizar de verdade é: ✔ Código otimizado ✔ Banco bem indexado ✔ CPU bem utilizada ✔ I/O sob controle 🔥 Conclusão (estilo Bellacosa raiz) “Mainframe não é lento. Código ruim é.” Um sistema bem ajustado não é só estável — 👉 Ele vira vantagem competitiva. 🛠️ Provocação final Qual foi aquele “fix ridiculamente simples” que você fez e: Derrubou consumo de CPU? Salvou batch window? Ou evitou um caos em produção? Se cavar… todo ambiente tem um “vilão escondido” esperando alguém enxergar. E quando você acha… 💣 o ganho vem em escala industrial.

 

Bellacosa Mainframe falando sobre performance e custo de processamento

💣🔥 10 MIL SEGUNDOS ROUBADOS POR DIA: O ASSASSINO SILENCIOSO DO SEU MAINFRAME 🔥💣

Por que cada milissegundo no z/OS pode ser a diferença entre lucro e caos

---

🧠 Performance na veia, sem anestesia

No mundo do processamento de transações em alto volume, “rápido o suficiente” é uma mentira confortável.

Quando você roda milhões (ou bilhões) de transações por dia em um ambiente como z/OS, qualquer ineficiência — mesmo microscópica — vira um monstro financeiro.

Não importa se você escreve em COBOL, PL/I ou Java.
Se o seu código desperdiça tempo, o mainframe cobra — e cobra caro.

👉 Performance tuning não é “nice to have”.
👉 É sobrevivência corporativa.

---

⚙️ O Efeito Multiplicador (ou: como 10ms viram uma conta absurda)

Vamos ao ponto crítico:

Você otimiza um trecho e economiza 10 milissegundos.

Agora multiplica isso:

• 1.000.000 execuções por dia
• Resultado:
  👉 10.000 segundos economizados/dia (~2h46min de CPU)

Agora entra o mundo real:

• Menos CPU → menos consumo de MSU
• Menos MSU → menor custo de licenciamento
• Menos contenção → mais throughput
• Mais throughput → mais negócio rodando

💣 Resumo estilo Bellacosa:

“Você não economizou milissegundos… você salvou dinheiro REAL.”

---

🧨 Onde isso explode na prática

💥 Cenário clássico (batch assassino)

Um JOB COBOL com loop:

PERFORM VARYING WS-I FROM 1 BY 1 UNTIL WS-I > 1000000
   EXEC SQL
      SELECT * INTO :HOST-VAR
      FROM CLIENTES
      WHERE ID = :WS-I
   END-EXEC
END-PERFORM

💀 Problemas:

• SELECT * (crime hediondo)
• 1 milhão de chamadas SQL
• Possível table scan

---

🔧 Cirurgia de performance (passo a passo)

1️⃣ Reduzir dados (SQL cirúrgico)

SELECT NOME, STATUS
FROM CLIENTES
WHERE ID = ?

✔ Menos I/O
✔ Menos CPU
✔ Menos transporte de dados

---

2️⃣ Garantir acesso via índice

Use EXPLAIN no DB2:

• Evite:
  • TABLE SCAN 😱
• Busque:
  • INDEX SEEK 😎

---

3️⃣ Trocar loop por processamento em bloco

💡 Em vez de 1 milhão de SELECTs:

• Use cursor
• Ou fetch em lote

---

4️⃣ Buffer Pool tuning (ouro puro)

Se seu dado é acessado frequentemente:

• Ajuste buffer pools
• Evite I/O físico

💣 Easter Egg:

Em muitos ambientes, só ajustar buffer pool já deu ganho de 30%+ sem mexer em uma linha de código.

---

🚀 Quick Wins que parecem pequenos… mas NÃO são

🧩 1. SQL eficiente

• Nunca use SELECT *
• Sempre valide acesso via índice
• Use EXPLAIN como religião

---

⚡ 2. Compiler moderno (COBOL v6+)

Se você ainda usa compilador antigo:

💀 Você está ignorando otimizações do hardware moderno

Ganhos comuns:

• Melhor uso de CPU
• Otimização automática de loops
• Instruções mais eficientes

---

💾 3. Movimento de dados (I/O mata performance)

Regra de ouro:

“Disco é lento. Memória é rei.”

Faça:

• Cache inteligente
• Sort interno (quando adequado)
• Evite leituras repetidas

---

🧠 Curiosidade de guerra (história real de bastidor)

Em um banco:

• Um único SELECT mal indexado
• Executado milhões de vezes/dia

Resultado após correção:

👉 Redução de MSU suficiente para economizar dezenas de milhares por mês

💣 O código tinha 10 anos em produção
💣 Ninguém questionava
💣 Até alguém olhar com lupa

---

🔍 Análise profunda (nível arquiteto)

Performance no mainframe não é só código.

É um ecossistema:

• CPU (MIPS/MSU)
• I/O (disco vs memória)
• Locking (DB2)
• Concorrência (CICS)
• Batch window

👉 Uma otimização local pode gerar ganho global
👉 Ou causar efeito colateral (cuidado!)

---

🧨 Anti-patterns que destroem performance

• SELECT *
• Loop com SQL dentro
• Falta de índice
• Reprocessamento de dados
• Leitura repetida de VSAM/DB2
• Uso de compilador legado

---

🏆 O verdadeiro “modernizar o mainframe”

Não é só:

• API
• Cloud
• Microservices

💣 Isso é maquiagem se o core estiver ineficiente

Modernizar de verdade é:

✔ Código otimizado
✔ Banco bem indexado
✔ CPU bem utilizada
✔ I/O sob controle

---

🔥 Conclusão (estilo Bellacosa raiz)

“Mainframe não é lento.
Código ruim é.”

Um sistema bem ajustado não é só estável —
👉 Ele vira vantagem competitiva.

---

🛠️ Provocação final

Qual foi aquele “fix ridiculamente simples” que você fez e:

• Derrubou consumo de CPU?
• Salvou batch window?
• Ou evitou um caos em produção?

Se cavar… todo ambiente tem um “vilão escondido” esperando alguém enxergar.

E quando você acha…

💣 o ganho vem em escala industrial.

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