Bellacosa Mainframe apresenta o Db2 Commands

🔥☕ DB2 COMMANDS NO IBM Z — A “SALA DE CONTROLE” DO MAINFRAME QUE QUASE NINGUÉM DOMINA 💾🚨

Existe uma enorme diferença entre:

• usar DB2,
  e

• controlar o DB2.

A maioria dos profissionais conhece:

• SQL,

• SELECT,

• tabelas,

• índices,

• packages.

Mas poucos realmente entendem o universo dos:

🔥 DB2 COMMANDS

E é exatamente aí que mora o verdadeiro poder operacional do IBM Z.

Porque quando:

• o online trava,

• o batch explode,

• o CPU dispara,

• o lock congela produção,

• o DDF enlouquece,

• o bufferpool satura,

não é o SQL que salva o ambiente.

É o operador que conhece:

-DISPLAY
-START
-STOP
-RECOVER
-MODIFY
-TRACE

E consegue enxergar o subsystem “por dentro”.

---

💾 O QUE SÃO DB2 COMMANDS?

Os DB2 Commands são comandos operacionais do Db2 for z/OS usados para:

• monitoramento,

• administração,

• recovery,

• troubleshooting,

• tuning,

• automação,

• controle do subsystem.

Eles podem ser executados:

• no SDSF,

• DB2I,

• console z/OS,

• batch,

• CICS,

• IMS,

• TSO,

• programas autorizados.

---

🔥 A GRANDE VERDADE

O DB2 no Mainframe não é apenas:

SELECT * FROM CLIENTES

Ele é:

• locking engine,

• recovery engine,

• log manager,

• memory manager,

• distributed server,

• transaction coordinator,

• storage subsystem.

E os comandos são o “painel de engenharia” desse motor gigantesco.

---

🚨 O COMANDO MAIS IMPORTANTE: DISPLAY

Quase tudo começa com:

-DISPLAY

ou forma curta:

-DIS

Esse comando possui dezenas de variações.

Cada uma revela uma parte diferente da “anatomia” do DB2.

---

🔥 DISPLAY THREAD — O ECG DO DB2

Comando

-DIS THREAD(*)

---

💾 O QUE ELE MOSTRA?

Threads ativas:

• CICS,

• batch,

• DDF,

• TSO,

• IMS,

• utilities.

---

🧠 O QUE É UMA THREAD?

É uma unidade ativa de execução DB2.

Pense como:

“uma conversa acontecendo agora com o banco”.

---

🚨 O QUE O DBA ANALISA?

WAIT

Pode indicar:

• lock,

• I/O lento,

• deadlock.

---

CPU ALTÍSSIMA

Uma única thread pode:

• consumir MSU,

• destruir zIIP,

• travar subsystem.

---

THREADS ZUMBI

Conexões:

• abertas,

• sem commit,

• esquecidas pela aplicação.

---

💥 CENÁRIO REAL

Aplicação Java:

• abre milhares de conexões DDF,

• não fecha corretamente.

Resultado:

-DIS THREAD(*)

mostra:

• avalanche de threads,

• consumo absurdo,

• risco subsystem.

---

🔥 DISPLAY DATABASE — A RADIOGRAFIA DO STORAGE LÓGICO

Comando

-DIS DB(*)

ou:

-DIS DATABASE(DBPROD)

---

💾 O QUE ELE ENTREGA?

Mostra:

• tablespaces,

• status,

• pendências,

• utilities,

• recovery,

• states críticos.

---

🚨 ESTADOS MAIS IMPORTANTES

Estado	Significado
RW	Read/Write
STOP	Parado
RO	Read Only
UT	Utility rodando
COPY	Backup pendente
CHKP	Check pending
RECP	Recovery pending

---

💣 RECP — O PESADELO

Recovery Pending significa:

o objeto não pode ser usado.

Pode ocorrer após:

• LOAD falho,

• recover incompleto,

• corrupção.

---

🔥 DISPLAY BUFFERPOOL — O RAIO-X DA MEMÓRIA

Comando

-DIS BPOOL(*)

---

💾 O QUE É BUFFERPOOL?

É o cache inteligente do DB2.

Armazena:

• páginas,

• índices,

• dados acessados recentemente.

---

🚨 O QUE O SYSPOG OBSERVA?

HIT RATIO

Baixo hit ratio:

• mais I/O,

• mais disco,

• mais CPU.

---

PGFIX(NO)

Pode gerar:

• paging,

• overhead CPU.

---

VPSIZE PEQUENO

Causa:

• sync I/O,

• gargalo físico.

---

💥 A VERDADE INCÔMODA

Muitos problemas “de SQL” são:

problemas de bufferpool.

---

🔥 DISPLAY DDF — O PULMÃO DISTRIBUÍDO

Comando

-DIS DDF

---

💾 O QUE É DDF?

Distributed Data Facility.

Responsável por:

• JDBC,

• APIs,

• microservices,

• Linux,

• cloud,

• aplicações externas.

---

🚨 O QUE PODE DAR ERRADO?

CONDBAT ESGOTADO

Muitas conexões simultâneas.

---

THREADS DISTRIBUÍDAS PRESAS

Pode indicar:

• problema TCP/IP,

• timeout,

• Java pool ruim.

---

DDF STOPPED

🔥 desastre moderno.

APIs param imediatamente.

---

🔥 DISPLAY LOCKS — O DETETIVE DO CRIME

Comando

-DIS LOCKS

---

💾 O QUE ELE REVELA?

• locks,

• waits,

• deadlocks,

• recursos presos.

---

💥 CENÁRIO CLÁSSICO

Batch:

UPDATE CLIENTES

sem commit adequado.

Resultado:

• CICS trava,

• PIX para,

• ATM congela.

DBA roda:

-DIS LOCKS

e encontra:

• o “assassino” da produção 😄

---

🔥 DISPLAY UTILITY — O CENTRO CIRÚRGICO

Comando

-DIS UTIL(*)

---

💾 UTILITIES IMPORTANTES

Utility	Função
REORG	Reorganização
COPY	Backup
LOAD	Carga
RUNSTATS	Estatísticas
RECOVER	Recovery

---

🚨 O QUE O DBA PROCURA?

Utility parada

Pode indicar:

• falta espaço,

• lock,

• erro I/O.

---

REORG ETERNA

Talvez:

• tablespace gigantesca,

• SORT insuficiente,

• disco saturado.

---

🔥 DISPLAY LOG — O DNA DO DB2

Comando

-DIS LOG

---

💾 O QUE ANALISAR?

• active logs,

• archive logs,

• checkpoints,

• offload,

• dual logging.

---

🚨 QUANDO O LOG SOFRE…

O subsystem inteiro sofre:

• commits lentos,

• rollback lento,

• recover piora,

• throughput cai.

---

💣 O LOG É O “SISTEMA NERVOSO” DO DB2

Sem log saudável:

não existe integridade transacional.

---

🔥 ADVISORY STATES — O DB2 TENTANDO TE AVISAR

Comando

-DIS DB(*) SPACENAM(*) ADVISORY

---

💾 O QUE É ADVISORY?

O DB2 dizendo:

“isso ainda funciona… mas vai piorar.”

---

🚨 AREO*

Advisory REORG Pending.

O DB2 recomenda:

REORG

---

🚨 ARBDP

Advisory Rebuild Pending.

Índice precisa rebuild.

---

💥 O QUE ACONTECE SE IGNORAR?

• access path degrada,

• CPU sobe,

• scans aumentam,

• overflow explode.

---

🔥 LPL — QUANDO O DB2 ENTRA EM MODO SOBREVIVÊNCIA

Comando

-DIS DB(DBPROD) SPACENAM(*) LPL

---

💾 LPL = LOGICAL PAGE LIST

Lista páginas:

• danificadas,

• inconsistentes,

• problemáticas.

---

🚨 COMO ISSO ACONTECE?

• falha I/O,

• corrupção,

• queda sistema,

• escrita interrompida.

---

💥 IMPACTO

• SQLCODE,

• abends,

• indisponibilidade,

• recover obrigatório.

---

🔥 START E STOP — O “PODER ABSOLUTO”

START DATABASE

-START DB(DBPROD)

Disponibiliza objeto.

---

STOP DATABASE

-STOP DB(DBPROD)

Indisponibiliza objeto.

---

🚨 USADO EM:

• maintenance,

• recovery,

• migração,

• REORG,

• troubleshooting.

---

💣 UM STOP ERRADO EM PRODUÇÃO…

…vira reunião de crise 😄

---

🔥 CANCEL THREAD — O BOTÃO VERMELHO

Comando

-CANCEL THREAD(token)

---

💾 PARA QUE SERVE?

Mata:

• thread travada,

• SQL infinito,

• aplicação congelada.

---

🚨 RISCO

Cancelar thread:

• pode gerar rollback gigante,

• lock storm,

• pressão de log.

---

🔥 TRACE — O MODO CSI DO DB2

Comando

-START TRACE

---

💾 O QUE É TRACE?

Captura:

• eventos internos,

• IFCIDs,

• waits,

• SQL,

• locking,

• performance.

---

🚨 PROBLEMA

Trace excessivo:

• consome CPU,

• gera overhead,

• pode piorar produção.

---

🔥 DSN — A PORTA DE ENTRADA DO DB2

Comando

DSN SYSTEM(DB9G)

---

💾 O QUE ELE FAZ?

Inicia sessão DB2 sob TSO.

---

🚨 SE DER ERRO

IKJ56500I COMMAND DSN NOT FOUND

normalmente:

• SDSNLOAD ausente,

• STEPLIB errada.

---

💾 SDSNLOAD — O “CORAÇÃO” DO DB2 BATCH

Contém:

• DSN,

• utilities,

• runtime,

• SPUFI,

• módulos DB2.

Sem SDSNLOAD:

não existe DB2 batch.

---

🔥 IKJEFT01 — O CANIVETE SUÍÇO

Programa clássico usado para:

• batch DB2,

• SPUFI,

• RUN,

• BIND,

• REBIND,

• comandos DISPLAY.

---

💥 EXEMPLO REAL

//STEP1 EXEC PGM=IKJEFT01
//STEPLIB DD DISP=SHR,DSN=DSN910.SDSNLOAD
//SYSTSIN DD *
 DSN SYSTEM(DB9G)
 -DIS THREAD(*)
 END
/*

---

🔥 O QUE SEPARA O OPERADOR COMUM DO VETERANO

O iniciante:

• olha dashboard.

O veterano:

• olha threads,

• logs,

• locks,

• utilities,

• bufferpools,

• advisory states,

• DDF,

• recovery.

Porque ele sabe:

o DB2 SEMPRE avisa antes do desastre.

---

☕ O VERDADEIRO PODER DO MAINFRAME

No mundo distribuído:

• reiniciam servidor.

No IBM Z:

• analisam causa raiz.

E os DB2 Commands continuam sendo:

• rápidos,

• leves,

• resilientes,

• precisos,

• praticamente eternos.

Décadas depois…
o terminal 3270 ainda continua revelando tudo para quem sabe ler os sinais do subsystem DB2 💾🔥

💣🔥 “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.

 

Bellacosa Mainframe mergulhas em comandos avançados do Db2

🔥☕ DB2 COMMANDS AVANÇADOS NO IBM Z — TRADUÇÃO, EXPLICAÇÃO E LABORATÓRIO PASSO A PASSO PARA SYSPOGS E DBAs 💾🚨

Os comandos DB2 são usados para controlar praticamente todo o ambiente operacional do Db2 for z/OS. Eles podem ser executados via:

• console z/OS,

• TSO,

• SDSF,

• DB2I,

• CICS,

• IMS,

• batch JCL,

• programas autorizados.

Mas a grande verdade é:

esses comandos são muito mais do que “comandos”.

Eles são:

• sensores,

• diagnósticos,

• controles cirúrgicos,

• mecanismos de sobrevivência do subsystem.

---

🔥 -DISPLAY THREAD

“Mostre quem está vivo dentro do DB2”

Tradução

Exibe informações sobre threads ativas do Db2.

---

💾 O QUE É UMA THREAD?

Thread é:

• uma conexão ativa,

• uma unidade de execução,

• uma conversa em andamento com o DB2.

Pode vir de:

• CICS,

• batch,

• DDF,

• Java,

• IMS,

• TSO.

---

🧪 PASSO A PASSO

Passo 1 — Entrar no painel DB2

Digite:

DSN SYSTEM(DB9G)

---

Passo 2 — Executar comando

-DIS THREAD(*)

---

Passo 3 — Analisar saída

Você verá:

• THREADID

• STATUS

• PLAN

• AUTHID

• CPU

• WAIT

---

🚨 O QUE OBSERVAR?

WAIT

Pode indicar:

• lock,

• I/O lento,

• deadlock.

---

CPU muito alta

Pode indicar:

• SQL ruim,

• scan massivo,

• aplicação travada.

---

💥 EXEMPLO REAL

Sistema PIX lento.

Você executa:

-DIS THREAD(*)

e encontra:

• thread Java com milhões de gets,

• CPU disparando,

• WAIT=LCK.

Resultado:

lock contention distribuído.

---

🔥 -DISPLAY DATABASE

“A radiografia do storage lógico”

Tradução

Exibe informações de status das databases Db2.

---

🧪 PASSO A PASSO

Passo 1

-DIS DB(DBPROD)

---

Passo 2 — Expandir spaces

-DIS DB(DBPROD) SPACENAM(*)

---

💾 O QUE APARECE?

• tablespaces,

• indexspaces,

• status,

• pendências,

• utilities,

• recovery states.

---

🚨 STATUS IMPORTANTES

Status	Significado
RW	Read Write
RO	Read Only
STOP	Parado
UT	Utility ativa
RECP	Recovery Pending
CHKP	Check Pending

---

💥 EXEMPLO REAL

Após LOAD falho:

STATUS=RECP

O objeto:

• não aceita acesso,

• exige recovery.

---

🔥 -DISPLAY BUFFERPOOL

“O raio-x da memória do DB2”

Tradução

Exibe o status atual dos buffer pools ativos ou inativos.

---

💾 O QUE É BUFFERPOOL?

Cache inteligente do DB2.

Armazena:

• páginas,

• índices,

• dados frequentemente acessados.

---

🧪 PASSO A PASSO

Mostrar todos

-DIS BPOOL(*)

---

Mostrar detalhe

-DIS BPOOL(BP0) DETAIL

---

🚨 O QUE ANALISAR?

HIT RATIO

Baixo:

• excesso de disco,

• I/O alto,

• CPU alta.

---

VPSIZE

Muito pequeno:

• gargalo memória.

---

PGFIX(NO)

Pode gerar:

• paging,

• overhead CPU.

---

💥 EXEMPLO REAL

Batch lento.

DBA executa:

-DIS BPOOL(*)

e descobre:

• hit ratio despencando,

• BP saturado.

---

🔥 -DISPLAY DDF

“O pulmão das conexões distribuídas”

Tradução

Exibe informações sobre o status e configuração do DDF.

---

💾 O QUE É DDF?

Distributed Data Facility.

Responsável pelas conexões:

• JDBC,

• APIs,

• Linux,

• cloud,

• microservices.

---

🧪 PASSO A PASSO

Passo 1

-DIS DDF

---

Passo 2 — Verificar

• STATUS

• CONDBAT

• threads distribuídas

• localização remota

---

🚨 ALERTAS

CONDBAT saturado

Excesso conexões.

---

DDF STOPPED

APIs param imediatamente.

---

💥 EXEMPLO REAL

Aplicação Java:

• abre milhares de conexões.

Resultado:

DDF THREAD LIMIT REACHED

---

🔥 -DISPLAY LOCKS

“O detetive do crime em produção”

Tradução

Exibe locks e claims mantidos por threads ativas.

---

🧪 PASSO A PASSO

Passo 1

-DIS LOCKS

---

Passo 2 — Procurar

• lock owner,

• waiting threads,

• lock type.

---

🚨 CENÁRIO CLÁSSICO

Batch:

UPDATE MASSIVO

sem commit.

Resultado:

• online trava,

• CICS para.

---

💥 O DBA ENCONTRA

WAIT=LCK

---

🔥 -DISPLAY LOG

“O DNA transacional do DB2”

Tradução

Exibe informações sobre active logs e checkpoints.

---

🧪 PASSO A PASSO

Passo 1

-DIS LOG

---

Passo 2 — Analisar

• active logs,

• archive logs,

• offload,

• checkpoints.

---

🚨 RISCOS

Log cheio

Pode:

• parar commits,

• travar subsystem,

• gerar degradação severa.

---

💥 EXEMPLO REAL

Sistema:

• commits lentos,

• rollback gigante.

DBA verifica:

-DIS LOG

e encontra:

• pressão de active logs.

---

🔥 -DISPLAY UTILITY

“O centro cirúrgico do DB2”

Tradução

Exibe status das utilities Db2.

---

🧪 PASSO A PASSO

Passo 1

-DIS UTIL(*)

---

Passo 2 — Procurar

• REORG,

• COPY,

• LOAD,

• RUNSTATS,

• RECOVER.

---

🚨 O QUE PODE DAR ERRADO?

REORG presa

Pode indicar:

• lock,

• I/O lento,

• SORT insuficiente.

---

🔥 -CANCEL THREAD

“O botão vermelho do DBA”

Tradução

Cancela processamento de threads locais ou distribuídas.

---

🧪 PASSO A PASSO

Passo 1 — Identificar thread

-DIS THREAD(*)

---

Passo 2 — Cancelar

-CANCEL THREAD(token)

---

🚨 CUIDADO

Cancelar thread:

• pode gerar rollback gigantesco,

• pressão de log,

• lock storm.

---

🔥 -START DATABASE

“Trazer o objeto de volta à vida”

Tradução

Torna a database disponível para uso.

---

🧪 PASSO A PASSO

Passo 1

-START DB(DBPROD)

---

Passo 2 — Confirmar

-DIS DB(DBPROD)

---

🔥 -STOP DATABASE

“Parar o coração do objeto”

Tradução

Torna objetos indisponíveis para aplicações.

---

🧪 PASSO A PASSO

Passo 1

-STOP DB(DBPROD)

---

Passo 2 — Validar

STATUS=STOP

---

🚨 IMPACTO REAL

Se parar database crítica:

• PIX para,

• ATM trava,

• APIs falham.

---

🔥 -ARCHIVE LOG

“Forçar rotação do log”

Tradução

Fecha active log atual e abre próximo disponível.

---

🧪 EXEMPLO

-ARCHIVE LOG

---

💾 USO REAL

Muito usado:

• antes backup,

• antes maintenance,

• troubleshooting log.

---

🔥 -START TRACE

“Modo CSI do DB2”

Tradução

Inicia traces Db2.

---

🧪 EXEMPLO

-START TRACE(PERFM)

---

🚨 RISCO

Trace excessivo:

• aumenta CPU,

• gera overhead.

---

🔥 -MODIFY DDF

“Alterar DDF online”

Tradução

Modifica status/configuração do DDF.

---

🧪 EXEMPLO

-MODIFY DDF PKGREL(COMMIT)

---

💾 USO

Ajuste:

• threads distribuídas,

• comportamento JDBC,

• tuning online.

---

🔥 O QUE UM SYSPOG VETERANO FAZ?

Sequência clássica:

-DIS THREAD(*)
-DIS DB(*)
-DIS LOCKS
-DIS BPOOL(*)
-DIS DDF
-DIS LOG
-DIS UTIL(*)

---

💣 O QUE ELE CONSEGUE VER?

• gargalos,

• locks,

• CPU,

• memória,

• recovery,

• corrupção,

• pressão DDF,

• degradação,

• risco subsystem.

---

☕ O GRANDE SEGREDO DO IBM Z

No Mainframe:

• tudo deixa rastros,

• tudo gera sinais,

• tudo pode ser analisado.

O verdadeiro especialista não é quem sabe apenas SQL.

É quem consegue olhar um:

-DISPLAY THREAD

e entender:

a saúde inteira do negócio em produção 💾🔥