Bellacosa Mainframe CICS para Sysprogs

🚀💥 CICS: O “CONTROLADOR DE TRÁFEGO” DO MAINFRAME — ONDE TASKS NASCEM, EXECUTAM… E ÀS VEZES PRECISAM SER ELIMINADAS 💥🚀

Se você é SysProg raiz, sabe: o IBM CICS não é só um subsistema — é um organismo vivo.
Milhares de transações pulsando por segundo, usuários conectados, filas, locks, DB2, MQ… e no meio disso tudo: você, com a responsabilidade de manter tudo fluindo.

Aqui vai um guia no estilo “mão na massa + café forte” pra dominar o gerenciamento do CICS no dia a dia.

---

🧠🔥 VISÃO MENTAL DO CICS (ANTES DE OPERAR)

Pense no CICS como:

• Dispatcher → controla quem executa
• Tasks (TCA) → unidades de trabalho
• Terminal/User → origem da transação
• Programs → lógica (COBOL, PL/I…)
• Resources → VSAM, DB2, MQ

👉 Cada ENTER do usuário vira uma task
👉 Cada task consome CPU, storage e locks
👉 E sim… algumas tasks travam tudo 😄

---

🕵️‍♂️🔍 1. VENDO LOGS COMO UM DETETIVE

No CICS, erro nunca vem sozinho. Ele deixa rastro.

📌 Principais logs:

• CSMT → mensagens gerais
• CSM1 → log auxiliar
• Transient Data Queue (TDQ) → logs customizados
• SMF 110 → performance e auditoria

🔎 Exemplo clássico:

DFHAC2001 TRANSACTION ABCD ABENDED WITH CODE ASRA

👉 Tradução Bellacosa:

“Alguém fez besteira no programa — provavelmente S0C4 disfarçado” 😄

---

👤🆔 2. IDENTIFICANDO USER E TASK EM TEMPO REAL

Aqui começa o jogo de verdade.

📌 Transação chave:

CEMT I TASK

Isso mostra:

• Task Number
• Transaction ID
• UserID
• Status (RUNNING, WAITING…)
• CPU Time

🔥 Exemplo:

Tas(000123) Tra(ABCD) Use(USER01) Sta(RUN)

👉 Você já sabe:

• Quem → USER01
• O quê → ABCD
• Qual → Task 123

💡 Dica de ouro:

CEMT I TASK USE(USER01)

👉 Filtra direto no usuário (perfeito pra incidentes)

---

☠️💣 3. DERRUBANDO TASK (QUANDO O CAOS CHEGA)

Quando uma task trava:

• segura recurso
• explode CPU
• trava fila inteira

👉 Você entra com autoridade:

💥 Comando:

CEMT SET TASK(123) PURGE

⚠️ Versão nuclear:

CEMT SET TASK(123) FORCEPURGE

👉 Diferença:

• PURGE → educado
• FORCEPURGE → “sai ou eu te mato” 😄

💡 Cuidado:

• Pode deixar dados inconsistentes
• Use quando não há alternativa

---

📊⚡ 4. MONITORANDO PERFORMANCE E CONSUMO

Aqui mora o SysProg de elite.

📌 Transações importantes:

• CEMT I SYS → visão geral
• CEMT I TASK → consumo por task
• CEMT I TRAN → estatísticas de transação

🔎 Indicadores críticos:

• CPU time alto
• Tasks WAITING (lock?)
• Storage crescente
• Response time degradando

---

🧠 Dica avançada (nível hard):

Use SMF 110 + ferramentas como:

• IBM OMEGAMON
• IBM RMF

👉 Isso revela:

• Top consumidores
• Gargalos invisíveis
• Tendência de carga

---

🛠️📋 5. CHECKLIST DE SOBREVIVÊNCIA DO SYSPROG CICS

Quando der problema, siga isso:

✅ Passo a passo real:

1. Ver logs (CSMT)
2. Identificar erro (abend?)

3. Listar tasks

   CEMT I TASK
   

4. Filtrar usuário/transação
5. Ver consumo
6. Decidir ação
   • aguardar
   • PURGE
   • FORCEPURGE
7. Validar impacto
8. Registrar ocorrência

---

🧩💡 EASTER EGGS DE QUEM VIVE CICS

👉 😄 “Toda ASRA tem uma história triste por trás”
👉 😄 “Se precisa dar FORCEPURGE… alguém fez deploy na sexta”
👉 😄 “Task WAITING sem motivo = lock escondido no DB2”

---

🏛️📜 CURIOSIDADES QUE POUCA GENTE SABE

• O IBM CICS nasceu nos anos 60 (!!)
• Ainda hoje processa bilhões de transações/dia
• Grande parte dos caixas eletrônicos do mundo passam por ele
• Ele é um dos sistemas mais resilientes já criados

---

🎯💬 COMENTÁRIO FINAL (NA VEIA)

Gerenciar CICS não é rodar comando.

É:

• entender comportamento
• prever problema
• agir rápido
• e às vezes… tomar decisões duras

👉 Porque no fim do dia:

“CICS parado não é sistema fora — é empresa parada.”

 

 

Bellacosa Mainframe VSAM lento tuning IDCAMS e outros segredinhos

💣 VSAM LENTO? NÃO É O MAINFRAME — É O SEU TUNING! 🔥 Os Segredos de Performance que Ninguém Te Conta

🧠 1) Escolha o tipo correto de arquivo VSAM

📌 Tradução

O VSAM suporta quatro tipos principais de datasets:

• ESDS (Entry-Sequenced Data Set) → acesso sequencial
• KSDS (Key-Sequenced Data Set) → acesso por chave
• RRDS (Relative Record Data Set) → acesso direto por número relativo
• LDS (Linear Data Set) → armazenamento bruto (usado por DB2, etc.)

Cada tipo possui características diferentes e deve ser escolhido conforme o padrão de acesso aos dados.

---

💬 Comentário Bellacosa

Aqui está o primeiro erro clássico de projeto:

❌ “Vou usar KSDS pra tudo porque é mais completo”

👉 Resultado: I/O desnecessário, split, CI/CA fragmentation, e performance indo pro ralo.

---

🧪 Exemplo prático

✔ Caso ideal:

• Batch sequencial (ex: faturamento diário)
  → ESDS ganha disparado
• Sistema online CICS com lookup por chave
  → KSDS obrigatório
• Tabela indexada por posição fixa
  → RRDS simplifica tudo

---

🚀 Dica avançada (pouco falada)

Se seu acesso for altamente randômico:

👉 Combine:

• KSDS
• • SMB + ACCBIAS=DO (Direct Optimized)

Isso muda o jogo de performance.

---

🧠 2) Otimização de buffers

📌 Tradução

Buffers são áreas de memória usadas para armazenar dados temporariamente durante operações VSAM.

• Poucos buffers → excesso de I/O
• Muitos buffers → desperdício de CPU/memória

---

💬 Comentário Bellacosa

Aqui mora um dos maiores gargalos invisíveis:

VSAM não é lento…
VSAM mal bufferizado é lento.

---

🧪 Exemplo prático (JCL)

//DD1 DD DSN=SEU.VSAM.KSDS,
//     AMP=('BUFND=20','BUFNI=10')

• BUFND → buffers de dados
• BUFNI → buffers de índice

---

🧠 Regra de ouro

Tipo de acesso	Ajuste
Sequencial	BUFND alto
Randômico	BUFNI mais importante

---

🚀 Nível PRO (SMB tuning)

AMP=('ACCBIAS=DO','SMB')

• DO → acesso randômico otimizado
• SO → sequencial
• SW/DW → dinâmico

💣 Isso pode reduzir I/O drasticamente.

---

🧠 3) Minimizar tamanho de registro

📌 Tradução

O tamanho do registro influencia diretamente:

• Quantidade de blocos
• Uso de buffer
• Transferência de dados

---

💬 Comentário Bellacosa

Esse é clássico de legado:

“Ah, deixa esse campo aqui... vai que um dia usam”

👉 Resultado:

• Records inflados
• CI mal aproveitado
• Mais EXCP

---

🧪 Exemplo

❌ Ruim:

Cliente:
- Nome (100 bytes)
- Código (10)
- 20 campos não usados

✔ Melhor:

Cliente:
- Nome (40)
- Código (10)

---

🚀 Técnicas avançadas

• Compressão de dados
• REDEFINES em COBOL
• Uso de campos variáveis (spanned records com cuidado)

---

💣 Trade-off real

Registro pequeno	Registro grande
+ menos I/O	+ menos splits
- desperdício de espaço	- mais dados por I/O

---

🧠 4) Ajuste da configuração de I/O

📌 Tradução

A configuração de I/O inclui:

• Tipo de device
• Velocidade
• Canais
• Pathing
• Alocação

Ferramentas recomendadas:

• SMF
• RMF

---

💬 Comentário Bellacosa

Aqui entramos no território dos sysprogs 🔥

Às vezes o problema NÃO é o VSAM
👉 é o storage, canal ou concorrência

---

🧪 Exemplo real

Problema:

• VSAM lento

Análise SMF:

• Alta contenção em volume

Solução:

• Redistribuir datasets
• Melhorar striping
• Ajustar cache

---

🚀 Dica ninja

• Use LSR (Local Shared Resources) em CICS
• Use RLS (Record Level Sharing) para concorrência

💣 Isso muda completamente o comportamento do VSAM online

---

🧠 5) Considerações extras (parte mais rica!)

💬 Expansão Bellacosa

Aqui entram os segredos que poucos documentam 👇

---

🔥 CI SIZE (Control Interval)

• Sequencial → CI maior (ex: 32K)
• Randômico → CI menor (ex: 4K ou 8K)

---

🔥 CA SIZE (Control Area)

• Afeta splits e performance
• CA maior → menos splits

---

🔥 FREESPACE

FREESPACE(20 10)

• 20% no CI
• 10% no CA

👉 Reduz splits (ESSENCIAL em KSDS)

---

🔥 Secondary Allocation

Evite muitos extents:

SPACE=(CYL,(100,50))

---

🔥 Split (o vilão silencioso)

Quando ocorre:

• CI Split
• CA Split

💣 Consequência:

• Mais I/O
• Fragmentação
• Queda brutal de performance

---

🧪 LAB PRÁTICO (nível Bellacosa 😎)

🎯 Objetivo:

Comparar performance com tuning vs sem tuning

---

Cenário 1 (ruim)

• KSDS
• CI pequeno
• Sem buffer tuning
• Sem FREESPACE

---

Cenário 2 (otimizado)

• KSDS
• CI adequado
• FREESPACE(20 10)
• SMB + ACCBIAS
• BUFND/BUFNI ajustado

---

🔍 Métrica:

• EXCP count
• Tempo de execução
• SMF 64/42

---

💥 Resultado esperado:

👉 Redução de I/O de 30% a 80% (sim, acontece!)

---

🏁 Conclusão estilo Bellacosa

VSAM não é velho…
VSAM é mal compreendido.

Quando bem tunado:

💣 Ele compete com banco moderno
💣 Ele escala
💣 Ele é absurdamente eficiente

 

Bellacosa Mainframe em um pequeno bate papo sobre segurança racf saf

🔥 SEU MAINFRAME ESTÁ SEGURO… OU SÓ PARECE?

A Verdade Crua da Segurança no z/OS (Do RACF ao Crypto Express)

---

☕ Introdução — Um Café com a Realidade

Se você acha que segurança no mainframe é “coisa do passado”, deixa eu te dar um choque de realidade:

O z/OS é um dos ambientes mais seguros do planeta — mas só quando bem configurado.

Porque na prática?

👉 O problema nunca foi a tecnologia
👉 O problema sempre foi quem configura

E é exatamente aqui que começa nossa jornada.

---

🕰️ Um pouco de história (e por que isso importa)

Nos anos 70, quando surgiram os primeiros sistemas corporativos massivos, a IBM percebeu algo:

“Se todo mundo acessa tudo… uma hora dá ruim.”

Nasce então o conceito de controle centralizado de acesso, que evolui para:

• RACF
• SAF
• E todo o ecossistema de segurança do z/OS

Enquanto o mundo distribuído ainda estava descobrindo autenticação…

👉 O mainframe já tinha segurança granular por recurso

---

🧠 O Coração da Segurança: SAF + RACF

Pensa nisso como um fluxo batch:

Usuário → SAF → RACF → decisão (ALLOW / DENY)

🧩 Quem faz o quê?

• SAF → interface (o “porteiro”)
• RACF → decisão (o “juiz”)

💡 Easter egg Bellacosa:

SAF nunca decide nada… ele só “encaminha o problema” 😄

---

🔐 O Mandamento Supremo: Least Privilege

Se você tiver que lembrar de UMA coisa:

“Dê o mínimo necessário — nunca o máximo possível.”

Exemplo clássico:

• Admin RACF → gerencia segurança
• Storage admin → só mexe em dataset

👉 Separação + privilégio mínimo = sistema saudável

---

💣 O ERRO QUE MAIS DERRUBA AMBIENTE

❌ PROTECTALL desligado

Sem isso:

Dataset sem perfil → acesso liberado 😱

👉 Simples assim.
👉 Sem perfil = sem segurança

💡 Curiosidade:
Muitos incidentes em mainframe não são ataques…
São configuração mal feita.

---

🔥 Criptografia no z/OS: Outro nível

Enquanto muita gente ainda “liga TLS”, o z/OS já faz:

🔐 Pervasive Encryption

• Dados em disco
• Dados em trânsito
• Dados protegidos sem mudar aplicação

---

🧬 A Hierarquia das Chaves (isso cai MUITO!)

Master Key → protege → Operational Key → protege → Data

Tipos importantes:

• Master Keys → topo da cadeia
• Symmetric → performance
• Asymmetric → troca segura
• Operational → uso diário

💡 Easter egg:

Se perder a master key… acabou o jogo.

---

⚙️ ICSF — O Tradutor da Criptografia

Aplicação nunca fala direto com hardware.

Ela fala com:

👉 ICSF

Que fala com:

👉 CPACF / Crypto Express

---

🛡️ Níveis de proteção (isso é ouro de prova)

Nível	Segurança
Clear Key	😬
Protected Key	👍
Secure Key	🔥🔥🔥

👉 Secure Key = dentro do hardware (Crypto Express)

---

💻 APF — Quem pode ser “superpoderoso”

Nem todo programa pode rodar com privilégio.

👉 Só quem está no APF

Programa fora do APF → sem privilégio
Programa no APF → modo supervisor

💡 Isso evita:

• código malicioso
• erro catastrófico

---

🌐 Rede no z/OS — Não é só TCP/IP

z/OS Communications Server

• TCP/IP (moderno)
• SNA (legado que ainda vive 😄)

Segurança:

• TLS → camada transporte
• IPSec → VPN (nível rede)

---

📊 SMF — O “log que conta tudo”

Se algo aconteceu:

👉 O SMF sabe

Mas atenção:

Nada é logado automaticamente se você não configurar

---

🧪 Caso real (estilo Bellacosa)

Empresa com:

• RACF instalado
• Criptografia ativa
• Auditoria configurada

Mas…

❌ PROTECTALL desligado
❌ UACC READ em datasets críticos

Resultado?

👉 Vazamento interno
👉 Sem ataque externo

💡 Moral:

Segurança não é tecnologia — é configuração.

---

🧠 Mentalidade Mainframe

Enquanto no mundo distribuído se fala:

“vamos adicionar segurança”

No mainframe é:

“vamos NÃO remover a segurança”

---

🔥 Frases pra tatuar no cérebro

• “SAF conecta, RACF decide”
• “Sem PROTECTALL, está exposto”
• “Sem chave, não há segurança”
• “ALL = mostra tudo”
• “SPECIAL = poder total (cuidado!)”

---

🏁 Conclusão — A Verdade Final

O z/OS não é seguro por acaso.

Ele é seguro porque:

• Foi projetado assim
• Evoluiu assim
• Exige disciplina

Mas…

Um mainframe mal configurado é tão vulnerável quanto qualquer outro sistema.

---

☕ Fechamento estilo Bellacosa

Segurança no mainframe não é só técnica.

É filosofia.

É controle.

É respeito ao sistema.

E principalmente:

É saber que o perigo não está fora… está dentro da configuração.

 

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 estudo do caso CPU Explodindo

💥 DB2 - CENÁRIO: CPU EXPLODINDO EM PRODUÇÃO

🧪 Situação

• Batch rodando há anos
• De repente: ⬆ CPU / ⬆ elapsed time
• Usuários reclamando
• SLA estourando

---

⚠️ QUERY PROBLEMÁTICA

SELECT *
FROM VAGNER.PEDIDOS P
JOIN VAGNER.CLIENTES C
  ON P.CLIENTE_ID = C.ID
WHERE C.CIDADE = 'SAO PAULO';

---

💣 SINTOMAS

• CPU alto 🔥
• Long elapsed time
• I/O elevado
• Threads presas

---

🔍 PASSO 1 — EXPLAIN (descobrindo o vilão)

👉 Você roda EXPLAIN e vê:

ACCESSTYPE = R (TABLE SCAN)
METHOD = 1 (Nested Loop)
MATCHCOLS = 0

---

🧠 DIAGNÓSTICO

💥 Problemas identificados:

1. Sem índice em C.CIDADE
2. Join usando nested loop pesado
3. Alto volume de leitura
4. SELECT * (puxa dados desnecessários)

---

🚨 CAUSA REAL DO CPU ALTO

👉 Db2 está:

• Varredura completa (scan)
• Fazendo join linha a linha
• Lendo MUITO mais dados que precisa

💡 Tradução:

Está trabalhando demais pra responder pouco

---

🚀 PASSO 2 — CORREÇÃO (TUNING REAL)

🔹 1. Criar índice estratégico

CREATE INDEX IDX_CLIENTES_CIDADE
ON VAGNER.CLIENTES (CIDADE);

---

🔹 2. Índice para JOIN

CREATE INDEX IDX_PEDIDOS_CLIENTE
ON VAGNER.PEDIDOS (CLIENTE_ID);

---

🔹 3. Evitar SELECT *

SELECT P.ID, C.NOME
FROM VAGNER.PEDIDOS P
JOIN VAGNER.CLIENTES C
  ON P.CLIENTE_ID = C.ID
WHERE C.CIDADE = 'SAO PAULO';

---

🔹 4. Atualizar estatísticas

RUNSTATS TABLESPACE VAGNER.TSCLIENTES;
RUNSTATS TABLESPACE VAGNER.TSPEDIDOS;

---

🔁 PASSO 3 — NOVO EXPLAIN

Agora você vê:

ACCESSTYPE = I
MATCHCOLS > 0
METHOD = melhor otimizado

---

📊 RESULTADO REAL

Métrica	Antes	Depois
CPU	🔥 Alto	⚡ Baixo
Tempo	🐢 Lento	🚀 Rápido
I/O	Alto	Reduzido

---

💣 OUTROS CENÁRIOS DE CPU ALTO (VIDA REAL)

⚠️ 1. Falta de filtro

SELECT * FROM PEDIDOS;

👉 Scan total = CPU alto

---

⚠️ 2. Função no WHERE

WHERE UPPER(NOME) = 'ANA'

👉 Índice ignorado 😬

---

⚠️ 3. OR mal usado

WHERE CIDADE = 'SP' OR CIDADE = 'RJ'

👉 Pode quebrar índice

---

⚠️ 4. RUNSTATS desatualizado

👉 Otimizador toma decisão ruim

---

⚠️ 5. Índice errado

👉 Existe… mas não ajuda

---

🧠 CHECKLIST DE INCIDENTE (use isso na guerra)

Quando CPU subir:

✔ Rodar EXPLAIN
✔ Ver ACCESSTYPE
✔ Checar índices
✔ Ver RUNSTATS
✔ Analisar SELECT *
✔ Avaliar volume de dados

---

🔥 FERRAMENTAS QUE AJUDAM

• EXPLAIN / PLAN_TABLE
• IFCID 316 (performance)
• Monitor tipo OMEGAMON
• Accounting traces

---

😎 FRASES DE QUEM RESOLVE INCIDENTE

• “Isso tá fazendo tablespace scan”
• “O access path mudou”
• “Faltou índice nesse predicado”
• “RUNSTATS tá velho”

---

💥 MENTALIDADE FINAL

👉 CPU alto no Db2 quase nunca é “o mainframe lento”

👉 Normalmente é:

✔ SQL ruim
✔ Índice errado
✔ Estatística desatualizada

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