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.

 

Bellacosa Mainframe e o grande desafio de tunar um mainframe Zos com software legado

🍔💾 Essential z/OS Performance Tuning Workshop

Quando performance deixa de ser fé e vira engenharia

No mundo distribuído, performance costuma ser tratada como magia:
“sobe mais recurso”, “escala automático”, “reinicia o serviço”.

No mainframe, isso nunca existiu.

Aqui, performance sempre foi disciplina, observação e responsabilidade.
E é exatamente isso que o Essential z/OS Performance Tuning Workshop carrega no DNA.

Não é um curso para “deixar tudo rápido”.
É um treinamento para não fazer besteira em produção.

---

🧠 Um workshop que nasceu da dor (e do custo de CPU)

Quando o z/OS ainda se chamava MVS, cada ciclo de CPU custava dinheiro real.
Não existia elasticidade, nem desculpa técnica.

Se o sistema ficava lento, alguém tinha que explicar:

• por quê

• onde

• quem causou

• como evitar de novo

O Essential z/OS Performance Tuning Workshop surge dessa escola:
a escola em que medir vem antes de mexer, e mexer sem entender é pecado mortal.

---

🎯 O que o workshop realmente ensina (sem PowerPoint bonito)

👉 Performance não é velocidade

Performance é cumprir SLA de forma previsível.

O workshop deixa isso claro logo cedo:

• CPU a 90% não é problema, se o response time está estável

• Sistema “folgado” pode estar mal configurado

• Pico não é tendência

Aqui, aprende-se a ler o sistema como um organismo, não como um gráfico isolado.

---

⚙️ Os pilares do workshop (onde a verdade mora)

🧩 WLM – Workload Manager

O verdadeiro cérebro do z/OS.

No workshop, cai a ficha:

WLM não é tuning técnico. É política de negócio codificada.

• Service Class errada = prioridade errada

• Prioridade errada = usuário certo reclamando

• Ajuste sem alinhamento = guerra interna

📌 Easter egg clássico:
O WLM sempre faz exatamente o que você mandou.
O problema é quando você mandou errado.

---

📊 RMF – onde a mentira não sobrevive

RMF é tratado como deve ser:

• Monitor III → o agora

• Monitor II → o culpado

• Postprocessor → a história que não pode ser reescrita

O workshop ensina algo raro hoje em dia:

Contexto importa mais que screenshot.

Um gráfico sem horário, workload e mudança recente é só arte abstrata.

---

🗃️ SMF – a caixa-preta do sistema

Aqui o tuning vira investigação.

SMF:

• Não opina

• Não sugere

• Não perdoa

Quem aprende a ler SMF sai do workshop com um superpoder:
parar discussões baseadas em achismo.

---

⚠️ Desafios reais abordados (aqueles que ninguém gosta de admitir)

🔥 “Todo mundo é crítico”

Ambiente compartilhado, dezenas de sistemas, todos “prioridade máxima”.

O workshop ensina a separar:

• workload crítico

• workload importante

• workload barulhento

💡 Easter egg corporativo:
O sistema mais crítico quase nunca é o que mais grita.

---

🔥 Falta de baseline

Sem baseline:

• não existe “piorou”

• só existe “sensação”

Frase implícita do workshop:

Tuning sem baseline é tuning religioso.

---

🔥 A pressão do “só ajusta rapidinho”

Nada gera mais legado tóxico do que tuning feito:

• em incidente

• sem análise

• para agradar gestor

O workshop ensina algo valioso:

Saber dizer NÃO, com métrica na mão.

---

🚀 O que muda depois do workshop

Quem passa por esse treinamento:

• Para de tunar por instinto

• Começa a observar antes de agir

• Aprende a prever gargalos

• Ganha respeito em incidente sério

No mercado, isso tem um efeito curioso:

Profissional que entende performance em z/OS não fica sem emprego.
Fica sem tempo.

---

🕹️ Easter eggs nível CPD

• CPU alta pode ser sinal de sistema saudável

• O melhor tuning, às vezes, é não mexer

• Se o sistema só é lento em horário comercial, o problema raramente é técnico

• Performance tuning é 70% política e 30% tecnologia

---

🧠 Conclusão – a frase que devia estar na parede do CPD

“z/OS não é lento.
Lento é quem não entende o que está medindo.”

O Essential z/OS Performance Tuning Workshop não ensina truques.
Ensina responsabilidade técnica.

E isso, em qualquer geração de tecnologia, continua raro.

Como “Compilar” seu Perfil no LinkedIn

 

analise critica do perfil linkedin com rabiscos e dumps

Como “Compilar” seu Perfil no LinkedIn — Bellacosa Mainframe Style

Se você já passou algum tempo perto de um mainframe, sabe que cada byte importa, que cada rotina deve ser eficiente, e que um job mal escrito pode travar todo o sistema. Pois bem: seu perfil no LinkedIn é o mainframe do seu eu profissional. Cada seção, cada palavra, cada link é como um registro COBOL — precisa ser correto, claro e impactante. Aqui vai um checklist inspirado no mundo Bellacosa:

1. Job Titles e Headlines: Evite “GIGO”

No mundo dos mainframes, GIGO (“Garbage In, Garbage Out”) é lei. O título do seu LinkedIn é a headline do seu job: seja específico, relevante e sem jargões confusos. Não basta “Analista de Sistemas” — diga “Analista de Sistemas | Especialista em Processamento de Dados Mainframe e Integração de Sistemas Legados”.

Vagner em home office com computadores e emulador 3270

2. Resumo: Seu JCL Pessoal

O resumo é como um Job Control Language (JCL): descreve quem você é, quais recursos utiliza e qual saída espera. Evite copiar padrões. Conte sua história, mostre resultados e adicione uma pitada de personalidade — sem travar o sistema com excesso de adjetivos inúteis.

3. Experiência Profissional: Rotinas Otimizadas

Cada experiência deve ser como uma sub-rotina COBOL bem escrita: clara, funcional e documentada. Use bullet points como comentários inteligentes, e destaque resultados mensuráveis. Nada de “responsável por sistemas” — mostre o que você compilou de fato.

4. Skills & Endorsements: Alocação de Recursos

Assim como mainframes alocam memória com cuidado, destaque habilidades que realmente importam. Tenha uma lista enxuta, relevante e priorizada. Evite inflar com skills genéricas — foco é performance.

5. Recomendações: Logs Positivos

Recomendações são como logs de auditoria bem registrados: mostram que o job rodou corretamente. Solicite de colegas, líderes ou parceiros de projeto. Quanto mais específicos os exemplos, mais confiável o output.

6. Networking: O Canal de Comunicação

No mundo mainframe, canais de comunicação entre sistemas são cruciais. No LinkedIn, conectar-se estrategicamente é igual: participe de grupos, comente postagens, compartilhe insights. Cada interação é uma mensagem PUT ou GET no buffer do seu networking.

7. Conteúdo e Publicações: Batch Jobs com Estilo

Postagens e artigos são batch jobs que rodam fora do horário pico, mas entregam grande valor. Compartilhe cases, aprendizados e tendências do setor. Assim, você demonstra expertise sem travar o feed do público.

---

💡 Dica Bellacosa Extra:
Seja como um mainframe antigo: sólido, confiável, indispensável — mas mostre que você sabe trabalhar com as tecnologias modernas. Um perfil otimizado é como um job que sempre retorna “CICS OK” no output: impecável, eficiente e reconhecido.

Meu Linkedin

#linkedin #perfil #seo #upgrade #visibilidade

Prompt para IA criar imagem critica do perfil 

"Critique a captura de tela do meu perfil do LinkedIn, sobreponha-o com rabiscos insanos, tinta vermelha, desenhos, observações e comentários em português."https://www.linkedin.com/in/vagnerbellacosa/

Boas Praticas em Performance e otimização uma primeira olhada

Salve jovem padawan, no artigo de hoje conversemos sobre um assunto pantanoso, que derruba 7 em 10 programadores, estou falando de performance e otimização de programas, infelizmente a pressa é inimiga da perfeição. Leia na Integra

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

 

 

🧾 COBOL 4.00 no IBM Mainframe

Guia para Iniciantes: Código Limpo, Seguro e Econômico

“COBOL 4 não perdoa código ruim.
Ele executa… e te cobra por isso.”

---

🕰️ Um Pouco de Contexto (Por que COBOL 4 importa)

O Enterprise COBOL 4.00 marcou uma virada de chave no mainframe:

• Introduziu um novo compilador

• Passou a gerar código mais próximo da arquitetura moderna

• Começou a penalizar código antigo e relaxado

👉 Muitos programas antigos funcionam, mas:

• Gastam mais CPU

• Usam mais memória

• Sofrem em batch pesado

---

🧱 Estrutura Básica de um Programa COBOL (Visão Rápida)

IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

Para iniciantes:

• DATA DIVISION mal feita = desastre

• PROCEDURE DIVISION confusa = CPU jogada fora

---

⚠️ Grandes Perigos para Iniciantes no COBOL 4

☠️ 1. Código que “funciona” mas custa caro

Exemplo perigoso:

PERFORM UNTIL EOF
   READ ARQ
   MOVE CAMPO-A TO CAMPO-B
END-PERFORM

❌ MOVE desnecessário dentro do loop
❌ Loop sem controle de volume

✅ Melhor prática:

READ ARQ AT END
   SET EOF TO TRUE
END-READ

E só mover o que for necessário.

---

☠️ 2. PERFORM Excessivo (Modular demais mata CPU)

Iniciantes adoram:

PERFORM TRATA-REGISTRO

dentro de loop com milhões de registros.

⚠️ Cada PERFORM é custo.

✔️ Dica:

• Inline lógica crítica

• Use PERFORM para controle, não para micro-rotinas

---

☠️ 3. Variáveis mal definidas (memória desperdiçada)

Erro clássico:

01 WS-VALOR     PIC X(1000).

Quando só precisa de 10 bytes 😱

✔️ Regra de ouro:

• PIC do tamanho exato

• Evite campos genéricos “pra garantir”

📉 Menos memória = menos cache miss = menos CPU.

---

☠️ 4. Repetir cálculos desnecessários

Erro comum:

COMPUTE WS-TOTAL = WS-QTD * WS-VALOR

feito várias vezes no loop com os mesmos valores.

✔️ Dica:

• Calcule uma vez

• Armazene

• Reutilize

---

🧼 Como Escrever Código Mais Limpo no COBOL 4

✅ Use nomes claros

WS-VALOR-TOTAL
WS-FIM-ARQUIVO

❌ Evite:

WS-A
WS-X1

---

✅ Evite lógica escondida

Código perigoso:

IF A = B
   MOVE X TO Y
ELSE
   IF C = D
      MOVE Z TO Y
   END-IF
END-IF

✔️ Melhor:

• Clareza > esperteza

• COBOL foi feito para ser legível

---

🚀 Performance no COBOL 4: Dicas Práticas

⚙️ 1. Tire código de dentro de loops

Cada instrução dentro de loop custa N vezes.

---

⚙️ 2. Use corretamente os níveis da DATA DIVISION

• Campos agrupados bem definidos

• Evite REDEFINES desnecessário

REDEFINES mal usado = bugs silenciosos.

---

⚙️ 3. Cuidado com STRING e UNSTRING

Eles são poderosos… e caros.

✔️ Use apenas quando necessário
✔️ Evite em loops grandes

---

⚙️ 4. Arquivos: leia com cuidado

• READ sequencial é barato

• READ aleatório é caro

• Releitura custa CPU e I/O

---

🧠 Pontos de Atenção que Geram Bugs em Produção

Armadilha	Problema
Campo não inicializado	Resultado imprevisível
EOF mal tratado	Loop infinito
IF aninhado demais	Erro lógico
REDEFINES confuso	Dados corrompidos
Índices fora do limite	ABEND

---

🧙 Curiosidades & Easter Eggs COBOL 4

• COBOL 4 foi o primeiro passo real rumo ao COBOL 5

• Programas antigos compilam, mas podem custar o dobro de CPU

• O compilador já “entende” melhor a arquitetura do zSeries

---

🧭 Primeiros Passos Recomendados para Padawans

1. Aprenda estrutura limpa

2. Evite copiar código velho sem entender

3. Sempre pense:

   “Isso vai rodar quantas vezes?”

4. Meça CPU quando possível

5. Menos código = menos custo

---

🏁 Conclusão

COBOL 4.00 é:

• Estável

• Poderoso

• Implacável com código mal escrito

“No mainframe, não existe código inocente.
Só código caro ou econômico.”

 

📉 Como Caçar MIPS Desperdiçado IBM Mainframe COBOL

 

📉 Como Caçar MIPS Desperdiçado

IBM Mainframe COBOL – Manual do Caçador de Custos para Padawans

“MIPS não somem sozinhos.
Alguém os está queimando.”

---

🧠 Antes de Tudo: O que é MIPS (na vida real)

• MIPS = dinheiro

• Não é performance “bonita”

• É CPU faturada

• Batch ruim = fatura triste 😭

☑️ Um programa pode estar correto
☑️ E ser financeiramente criminoso

---

🐘 Onde os MIPS se Escondem (Mapa do Crime)

Área	Crime comum
COBOL	MOVE inútil, PERFORM em loop
SORT	Sort desnecessário
DB2	Fetch linha a linha
I/O	Leitura registro a registro
JCL	Classes erradas
Compilação	Parâmetro errado

---

🧪 1. O Maior Vilão: LOOP INÚTIL

🔥 Sintoma

• CPU alto

• Pouca E/S

• Tempo absurdo

💀 Crime clássico

PERFORM 1000000 TIMES
   MOVE WS-A TO WS-B
END-PERFORM

🛠️ Cura Bellacosa™

• Elimine MOVE redundante

• Tire código de dentro do loop

☑️ Código dentro de loop custa MIPS

---

🧪 2. MOVE em Cadeia (o Vampiro Silencioso)

🔥 Sintoma

• CPU sobe

• Programa “simples”

💀 Crime clássico

MOVE A TO B
MOVE B TO C
MOVE C TO D

🛠️ Cura Bellacosa™

MOVE A TO D

☑️ COBOL não cobra por linha… cobra por execução.

---

🧪 3. PERFORM CALLADO (Sem necessidade)

🔥 Sintoma

• Modularização “bonita”

• CPU feia

💀 Crime clássico

PERFORM CALCULA-VALOR

chamado milhões de vezes.

🛠️ Cura Bellacosa™

• Inline lógica crítica

• Evite PERFORM em massa

☑️ Modularidade demais custa caro.

---

🧪 4. SORT Burro (Quando não precisava)

🔥 Sintoma

• CPU alto

• Disco suando

💀 Crime clássico

• SORT de arquivo já ordenado

• SORT para eliminar duplicidade

🛠️ Cura Bellacosa™

• Valide se já vem ordenado

• Use controle lógico

☑️ SORT é um monstro de MIPS.

---

🧪 5. DB2: FETCH Um a Um (Pecado Mortal)

🔥 Sintoma

• CPU altíssimo

• SQL “simples”

💀 Crime clássico

FETCH CURSOR

milhões de vezes.

🛠️ Cura Bellacosa™

• Use FETCH BLOCK

• Aumente ARRAY FETCH

☑️ Banco pensa em bloco, não em linha.

---

🧪 6. COMMIT Mal Posicionado

🔥 Sintoma

• Lock

• Reprocesso

• CPU extra

💀 Crime clássico

• COMMIT a cada registro

• COMMIT gigante demais

🛠️ Cura Bellacosa™

• Commit por lote

• Ajustar checkpoint

---

🧪 7. I/O Excessivo (Leitura Burra)

🔥 Sintoma

• Muito tempo de execução

• Pouca CPU útil

💀 Crime clássico

• READ dentro de loop

• Releitura desnecessária

🛠️ Cura Bellacosa™

• Buffer

• Carregar em memória quando possível

☑️ I/O custa caro e demora.

---

🧪 8. Compilação Errada = MIPS Perdido

🔥 Crime silencioso

• Compilar COBOL 5 com PARMs antigos

🛠️ Cura Bellacosa™

OPTIMIZE
ARCH(13+)

☑️ Compilador moderno gera código melhor.

---

🧪 9. JCL Mal Enquadrado

🔥 Sintoma

• Job pequeno em classe errada

💀 Crime clássico

• Classe de alto consumo

• Prioridade indevida

🛠️ Cura Bellacosa™

• Classe certa

• WLM ajustado

---

🧪 10. Falta de Métrica = Cegueira

🔥 Erro fatal

• “Acho que melhorou”

🛠️ Ferramentas

• SMF

• RMF

• Accounting DB2

• EXPLAIN PLAN

☑️ Sem métrica, não há tuning.

---

🧠 Checklist Rápido do Caçador de MIPS

☑️ Tirou código de loop
☑️ Reduziu SORT
☑️ Ajustou FETCH
☑️ Ajustou COMMIT
☑️ Compilou certo
☑️ Mediu antes e depois

---

🧙 Easter Eggs Bellacosa™

• 1 MOVE em loop pode custar milhões por mês

• Batch “simples” costuma ser o mais caro

• Melhor otimização: não executar

---

🏁 Conclusão

“MIPS não se otimizam…
MIPS se caçam.”

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