Bellacosa Mainframe apresenta um checklist para analisar a performance e tuning em Mainframe

💥 🧠 CHECKLIST PROFISSIONAL — SAMPLING PERFORMANCE TUNING

---

🎯 1. IDENTIFICAÇÃO DO PROBLEMA

Antes de sair rodando ferramenta:

✔ CPU alto?
✔ Elapsed alto?
✔ Batch lento?
✔ CICS lento?

---

💡 Pergunta chave

“É CPU ou WAIT?”

---

⚙️ 2. DEFINIÇÃO DO ALVO (TARGET)

Escolha corretamente:

• Job batch
• Região CICS
• Address space DB2

---

🔥 Regra de ouro

✔ Comece amplo (job)
✔ Refinar depois (step / programa)

---

🔬 3. DEFINIR O NÍVEL DE ANÁLISE

🔹 Macro (primeiro passo)

• Job inteiro

🔸 Micro (diagnóstico)

• Step específico
• Programa específico

---

💣 Erro comum

❌ Ir direto para detalhe sem contexto

---

⏱️ 4. CONFIGURAR DURAÇÃO

✔ 15–30 minutos padrão
✔ Batch curto → ajustar

---

💡 Regra

Duração suficiente para capturar comportamento real

---

🔢 5. CONFIGURAR SAMPLES

✔ 1000–1500 samples/min

---

📊 Referência

Samples/min	Qualidade
< 500	ruim
1000	bom
1500+	excelente

---

💣 Erro crítico

❌ Poucos samples → diagnóstico errado
❌ Muitos → overhead desnecessário

---

🔁 6. ATIVAR “MEASURE TO STEP END”

✔ Sempre que possível

---

💡 Use quando:

• Batch imprevisível
• Jobs longos
• Problema intermitente

---

🔗 7. ATIVAR COLETORES CORRETOS

✔ DB2 → se houver SQL
✔ CICS → se for transação
✔ IMS → se aplicável

---

💣 Regra

Ative só o necessário

---

⚠️ Erro comum

❌ Ativar tudo → overhead alto

---

🚀 8. EXECUTAR A SESSÃO

✔ Monitorar status
✔ Aguardar finalizar
✔ Verificar número de samples

---

💣 Nunca faça

❌ Analisar sessão ativa
❌ Analisar com poucos samples

---

📊 9. VALIDAR QUALIDADE DO RELATÓRIO

Antes de confiar:

✔ Samples suficientes?
✔ Margem de erro baixa (<5%)?
✔ Duração adequada?

---

💡 Se não:

👉 Refaça a coleta

---

🔍 10. ANÁLISE PRINCIPAL (CPU vs WAIT)

📊 Interpretação

Situação	Diagnóstico
CPU alto	problema de código
WAIT alto	problema externo

---

🔥 11. IDENTIFICAR HOTSPOTS

Procurar:

• Módulo
• Offset
• Função

---

💡 Pergunta chave

“Quem está consumindo CPU de verdade?”

---

🧱 12. CLASSIFICAR O PROBLEMA

🔥 CPU-bound

• Loop
• Cálculo
• Algoritmo

---

🐢 WAIT-bound

• VSAM I/O
• DB2
• ENQ / lock
• MQ

---

🔬 13. DRILL-DOWN (INVESTIGAÇÃO)

Se CPU:

👉 Ir para código (COBOL / PL/I)

Se WAIT:

👉 Ir para:

• DB2 → SQL
• VSAM → dataset
• Sistema → ENQ

---

🛠️ 14. AÇÃO DE TUNING

🔥 CPU

✔ Reduzir loops
✔ Evitar processamento redundante
✔ Melhorar algoritmos

---

🐢 I/O

✔ Melhorar acesso VSAM
✔ Ajustar buffers
✔ Indexar DB2

---

🔐 LOCK

✔ Reduzir contenção
✔ Ajustar commit

---

🔁 15. VALIDAR RESULTADO

👉 Rodar nova sessão

Comparar:

• CPU antes/depois
• Tempo antes/depois

---

💣 Regra

Sem validação = tuning incompleto

---

📈 16. DOCUMENTAR

✔ Problema
✔ Diagnóstico
✔ Solução
✔ Ganho

---

💡 Isso vira:

• Base de conhecimento
• Aceleração futura

---

🔥 CHECKLIST RÁPIDO (versão bolso)

1. CPU ou WAIT?
2. Definir target
3. Configurar samples (1000/min)
4. Ativar step end
5. Executar sessão
6. Validar samples
7. Analisar CPU vs WAIT
8. Encontrar hotspot
9. Corrigir
10. Validar resultado

---

💣 ERROS QUE MATAM PERFORMANCE (e sua carreira 😅)

❌ Analisar sem dados suficientes
❌ Culpar DB2 sem prova
❌ Ignorar WAIT
❌ Não validar margem de erro
❌ Ajustar “no chute”

---

🧠 FRASE FINAL (nível arquiteto)

“Performance não se melhora com opinião.
Se melhora com evidência.”

 

 

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

 

💣 DB2 Troubleshotting

Bellacosa Mainframe Db2 Troubleshotting

💣 DB2 Troubleshotting

💣 1. DEADLOCK — “o abraço da morte”

🧪 Cenário real

Transação A:

UPDATE CLIENTES SET NOME='ANA' WHERE ID=1;

Transação B:

UPDATE CLIENTES SET NOME='JOAO' WHERE ID=2;

👉 Depois:

• A tenta atualizar ID=2
• B tenta atualizar ID=1

💥 BOOM → deadlock

---

🧠 O que aconteceu?

Cada transação:

• segura um lock
• espera o lock da outra

👉 Db2 detecta e mata uma delas

---

💥 Sintoma clássico

SQLCODE = -911
REASON CODE = 00C90088

---

🔍 Diagnóstico

• IFCID 172 (trace)
• DISPLAY DATABASE LOCKS
• Monitoramento (OMEGAMON)

---

🛠️ Soluções

✔ Acessar tabelas sempre na mesma ordem
✔ Reduzir tempo de transação
✔ Usar COMMIT mais frequente
✔ Evitar “holding locks” por muito tempo

💡 Regra de ouro:

Ordem consistente = evita deadlock

---

⚠️ 2. LOCK ESCALATION — “quando o Db2 perde a paciência”

🧪 Cenário real

Você roda:

UPDATE CLIENTES SET STATUS='A';

👉 Sem WHERE 😬

---

🧠 O que acontece?

• Começa com row locks
• Muitos locks acumulam
• Db2 sobe para table lock

💥 Resultado:

Ninguém mais acessa a tabela

---

💥 Sintoma

• Lentidão geral
• Jobs travados
• Reclamação do usuário 😅

---

🔍 Diagnóstico

• IFCID 196
• Monitoramento de locks
• DSNZPARM (NUMLKTS / NUMLKUS)

---

🛠️ Soluções

✔ Sempre usar WHERE
✔ Commit em blocos (batch)
✔ Ajustar parâmetros de lock
✔ Usar LOCKSIZE adequado

💡 Bellacosa insight:

UPDATE sem WHERE é pedido formal de incidente 🚨

---

🚀 3. ACCESS PATH — “o plano invisível que decide tudo”

🧪 Cenário real

SELECT * FROM CLIENTES WHERE ID = 1;

👉 Parece simples… mas:

• Usa índice? ⚡
• Ou faz table scan? 🐢

---

🧠 O que é Access Path?

👉 Caminho que o otimizador escolhe para acessar os dados

---

🔍 Como ver?

EXPLAIN PLAN FOR
SELECT * FROM CLIENTES WHERE ID = 1;

👉 Consulta tabela PLAN_TABLE

---

💥 Possibilidades

Tipo	Impacto
Index scan	Rápido ⚡
Table scan	Lento 🐢
Nested loop	Bom
Sort	Custo extra

---

🛠️ Otimização

✔ Criar índice correto
✔ Atualizar RUNSTATS
✔ Evitar SELECT *
✔ Filtrar bem no WHERE

---

💡 Exemplo prático

❌ Ruim:

SELECT * FROM CLIENTES;

✅ Melhor:

SELECT NOME FROM CLIENTES WHERE ID = 1;

---

🧠 VISÃO DE PRODUÇÃO (OURO!)

🔥 Deadlock

👉 Problema de concorrência

---

🔥 Lock escalation

👉 Problema de volume de locks

---

🔥 Access path

👉 Problema de performance

---

💣 CHECKLIST RÁPIDO (salva carreira)

Antes de subir para produção:

✔ Tem índice?
✔ Tem WHERE?
✔ Tem COMMIT?
✔ Rodou EXPLAIN?
✔ RUNSTATS atualizado?

---

😎 FRASES DE SENIOR (pra usar na daily)

• “Isso tá com cara de access path ruim”
• “Provavelmente lock escalation”
• “Vamos revisar o EXPLAIN antes de mexer”
• “Isso aí vai dar -911 em produção”

 

Um Café no Bellacosa Mainframe

2,167 subscribers

O que é Address Space?

Bellacosa Mainframe

4,424 followers

July 25, 2025

Salve jovem padawan, prosseguindo em nossa jornada de descobrimento e compartilhamento de conhecimento, hoje escreverei sobre um tema dificil, tentarei ser claro e ajudar com exemplos fáceis de entender.

Em minhas aulas percebo que os alunos ficam confusos por ser um tema muito abstrato, porém de máxima importância para um desenvolvedor Mainframe, a questão da memória, lembrando que um Z17 tem 16 exabytes de endereço de memória disponível.

Ao codificar, devemos dominar o espaço, ser econômicos em seu uso e dar o máximo de performance para um programa, por isso entender o conceito ajudará bastante.

✅ O que é Address Space?

Um Address Space é um ambiente isolado de execução fornecido pelo z/OS para que um job, um programa ou uma tarefa rode com sua própria memória e recursos protegidos. Pense nele como um "container" de memória virtual onde o seu programa COBOL roda. Esse cointainer será alocado no DATA DIVISION do Cobol e o programa ao ser enviado para o processamento na CPU, reservará esse espaço para usar durante todo o processo.

---

🧠 Por que isso é importante para COBOL?

Quando você submete um job COBOL batch, ou inicia um programa via CICS, o sistema cria um address space para:

• Carregar os programas COBOL compilados (load modules).
• Alocar memória para as variáveis.
• Abrir arquivos (datasets, VSAM, etc.).
• Comunicar com o CICS, DB2 ou IMS.
• Controlar segurança, permissões e acesso via RACF.
• Garantir que um job não interfira em outro (isolamento de execução).

Esse espaço estará isolado de outras aplicações e protegido contra interferências durante todo o processamento dos dados, porém devemos criá-lo com cuidado. Afinal muitas outras aplicações criarão os delas, esse espaço tende a ser continuo e para seu uso mais racional, o endereçamento renumera em tempo de execução para 1 até o ultimo byte reservado.

---

📌 Tipos de Address Space comuns no ambiente z/OS:

Tipo de EspaçoDescriçãoJob Address SpaceCriado quando um JCL é submetido. Executa seu programa COBOL.TSO Address SpaceQuando um usuário entra via TSO (ISPF), um espaço é criado.CICS RegionCICS cria um espaço para executar programas COBOL online.STC (Started Task)Tasks como SDSF, VTAM ou WebSphere são address spaces.

---

🛠️ Dica prática para COBOListas

Se você estiver enfrentando erros de memória, como abend S0C4, S0C1, S80A, saiba que o problema pode estar relacionado à forma como o seu programa está usando (ou ultrapassando) os limites do Address Space.

Sempre recomendo o uso dos Bug traps do COBOL, nunca deixe de validar returns codes, sql codes e validar os valores resultantes. Evitando abends descontralados em tempo de execução.

---

💡 Curiosidade Bellacosa Mainframe:

Cada address space tem sua própria área de memória protegida, mas todos compartilham o mesmo sistema de I/O, JES e catálogo. O z/OS garante que um job de um programador "distraído" não corrompa o ambiente do colega — um isolamento que já existia décadas antes dos containers Docker!

💡 Conclusão

Esse artigo teve como objetivo fornecer os primeiros passos para o futuro Mainframer, mas para obter maiores conhecimentos recomendo visitar o site da IBM , ler os manuais e participar da comunidade para evoluir sempre.

Espero ter ajudado e contem comigo para mais artigos, participe de nossa comunidade.

Ajude-nos a evoluir sempre.

Obrigado.