☕💥 Seu DB2 não é lento… você que não está ouvindo ele: Um guia de Database Management para COBOListas raiz (com história, bastidores e prática real)

 

Bellacosa Mainframe fala sobre db2 database management

☕💥 Seu DB2 não é lento… você que não está ouvindo ele

Um guia de Database Management para COBOListas raiz (com história, bastidores e prática real)

---

🧠 Introdução — o erro clássico do dev COBOL experiente

Se você já escreveu toneladas de código em COBOL, rodou JCL de olhos fechados e fez commit no IBM Db2 como quem toma café…

👉 deixa eu te provocar:

Você domina DB2… ou só usa ele?

Porque existe uma diferença brutal entre:

• quem usa SELECT
• e quem entende o comportamento do banco em produção

Esse artigo é pra te levar do segundo nível ao terceiro 😈

---

🏛️ Origem — quando o banco virou protagonista

Antes do relacional:

• dados eram hierárquicos (tipo IBM IMS)
• dependência total da aplicação

Então veio Edgar F. Codd (1970) com o modelo relacional.

👉 Resultado:

• nasce SQL
• nasce o DB2
• nasce o conceito de independência de dados

💡 Easter egg histórico:

DB2 foi um dos primeiros DBMS comerciais a implementar o modelo relacional de forma prática em larga escala.

---

🧩 O que é Database Management (na prática real)

Você já viu no módulo:

Criar banco é fácil.
Manter banco é o jogo.

---

🔥 O DBA mindset que você precisa absorver

Criar → Carregar → Monitorar → Proteger → Otimizar → Evoluir

---

🏗️ PARTE 1 — CRIAÇÃO (onde tudo começa… ou dá errado)

🧠 Modelagem (não pule isso)

🔹 Conceitual

• negócio (cliente, pedido)

🔹 Lógico

• tabelas e relacionamentos

🔹 Físico

• DB2 real (tablespace, index, etc)

💡 Insight:

COBOL sem modelagem vira gambiarra persistente

---

💻 Exemplo (estilo produção)

CREATE TABLE CLIENTES (
  ID INTEGER NOT NULL,
  NOME VARCHAR(100) NOT NULL,
  SALDO DECIMAL(10,2),
  PRIMARY KEY (ID)
);

👉 Aqui você definiu:

• estrutura
• tipo
• integridade

---

⚙️ PARTE 2 — FIELD ATTRIBUTES (onde mora o perigo silencioso)

💥 Escolhas erradas que você já viu:

• PIC X(100) pra tudo 😬
• DECIMAL mal definido
• campos NULL sem controle

---

💡 Regra de ouro

Tipo correto = performance + qualidade + economia

---

🧠 Exemplo clássico

❌ errado:

SALDO VARCHAR(50)

✅ correto:

SALDO DECIMAL(10,2)

---

💾 PARTE 3 — BACKUP (ou como sobreviver)

💡 Verdade dura:

Backup não testado = backup inexistente

---

🔧 No mundo real

• full backup
• incremental
• logs

👉 DB2 usa logs pra recovery fino

---

💥 Cenário real:

00:00 backup
10:32 falha

👉 Recovery:

• restore backup
• aplicar logs até 10:31

---

🧾 PARTE 4 — LOGGING (a caixa preta do sistema)

Logs registram:

• INSERT
• UPDATE
• DELETE
• erros

💡 Easter egg:

Sem log, DB2 vira só um arquivo caro

---

⚡ PARTE 5 — PERFORMANCE (onde o bicho pega)

🔍 O erro clássico do COBOLista

SELECT * FROM CLIENTES;

👉 sem índice
👉 sem filtro
👉 sem plano

---

💥 Ferramenta essencial

EXPLAIN PLAN FOR ...

👉 mostra:

• table scan
• index usage
• custo

---

🧠 Insight de produção

Query lenta não é azar
👉 é falta de análise

---

🛠️ PARTE 6 — PROBLEM DETERMINATION

🧨 Situações reais

• deadlock
• tabela bloqueada
• job travado
• programa COBOL falhando

---

🔍 Ferramentas

• logs
• return codes (SQLCODE 👀)
• traces

---

💡 Easter egg COBOL:

IF SQLCODE NOT = 0

👉 esse é o grito silencioso do DB2

---

🔁 PARTE 7 — REPLICATION (escala nível banco)

👉 cópia do banco:

• leitura distribuída
• alta disponibilidade

---

💡 Exemplo

• DB2 PROD → DB2 READ ONLY

---

🔄 PARTE 8 — ETL (o mundo além do transacional)

Fluxo:

• Extract → DB2
• Transform → regras
• Load → Data Warehouse

---

💡 Insight:

DB2 alimenta o negócio invisível

---

🗄️ PARTE 9 — ARCHIVING (o segredo da performance)

💥 Problema:

Tabela cresce sem controle

✅ Solução:

• arquivar dados antigos

---

💡 Exemplo:

• transações > 5 anos → archive

---

🧹 PARTE 10 — DATA QUALITY (o mais negligenciado)

💡 Pergunta brutal:

Você confia nos dados?

---

🔧 Técnicas:

• validação
• constraints
• scripts

---

💥 Exemplo

saldo negativo indevido
data inválida
cliente duplicado

---

📊 PARTE 11 — REPORTING (onde o dinheiro aparece)

👉 Dados → Informação → Decisão

---

🚀 RESUMO FINAL (nível senior)

DB2 não é banco…
é sistema crítico de negócio

---

☕ INSIGHT FINAL ESTILO BELLACOSA

Você pode escrever COBOL perfeito…
👉 mas se o DB2 estiver errado, tudo está errado 😈

---

🎯 FECHAMENTO

Se você chegou até aqui:

👉 você não é mais só dev COBOL
👉 você começou a pensar como DBA

 

Bellacosa Mainframe analisando o RTM

🔥 SEU PROGRAMA NÃO MORRE… ELE DEIXA PISTAS 💀

O guia proibido do RTM que revela como o z/OS investiga, sobrevive e aprende com cada falha

Você vê um ABEND e pensa:

👉 “deu erro…”

O z/OS pensa diferente:

💥 “vamos registrar, analisar, aprender e continuar rodando.”

Esse é o papel do Recovery Termination Manager (RTM) — o sistema que transforma falhas em evidência técnica.

Se você quer sair do nível “rodou ou não rodou” e entrar no nível engenharia de diagnóstico, esse é o mapa definitivo 👊🔥

---

🧠 1. A FILOSOFIA DO z/OS SOBRE ERROS

No mundo distribuído:

👉 erro = problema

No mainframe:

👉 erro = evento analisável

---

💡 Tradução Bellacosa

“falhar é permitido… repetir o erro não.”

---

⚙️ 2. RTM — O “INVESTIGADOR OFICIAL”

O RTM entra em ação quando:

• ocorre erro (ABEND)
• há falha de hardware
• há erro de sistema
• ou até quando tudo termina normalmente

---

🔥 Funções principais

• capturar erro
• chamar rotinas de recuperação
• gerar dumps
• registrar LOGREC
• limpar recursos

---

💡 Insight

RTM atua até quando o programa termina certo

---

🧩 3. RTM1 vs RTM2 — DOIS NÍVEIS DE SOBREVIVÊNCIA

🔹 RTM1 (System)

• protege o sistema
• chama FRR

---

🔹 RTM2 (Task)

• trata a task
• chama ESTAE

---

🔥 Fluxo real

Erro → RTM1 → RTM2 → Recovery → Dump → Cleanup

---

💡 Tradução

“primeiro o sistema sobrevive… depois a task”

---

🛡️ 4. ESTAE — A AUTODEFESA DO PROGRAMA

Programas podem registrar:

👉 rotinas de recuperação

---

🔥 Como funciona

• programa define ESTAE
• erro ocorre
• RTM chama essa rotina

---

💡 Tradução Bellacosa

“seu programa pode tentar se salvar antes do fim”

---

🧠 Exemplo real

COBOL acessa memória inválida
 ↓
ESTAE intercepta
 ↓
log + tratamento

---

💀 5. DUMPS — A CENA DO CRIME

Um dump é:

👉 uma foto completa do sistema no erro

---

🔥 Tipos

• SYSABEND → completo
• SYSMDUMP → técnico
• SYSUDUMP → básico
• SVC Dump → sistema
• Stand-alone → sistema morto

---

💡 Tradução

“dump é o momento congelado da falha”

---

🧠 Exemplo

S0C4
 ↓
dump gerado
 ↓
IPCS analisa

---

🧠 6. LOGREC — O HISTÓRICO DOS ERROS

LOGREC registra:

• falhas de hardware
• erros de software
• condições do sistema

---

💡 Insight

é o primeiro lugar que um sysprog olha

---

🔥 Tradução Bellacosa

“LOGREC = diário dos problemas”

---

📜 7. LOGS — A LINHA DO TEMPO

🔹 Principais:

• SYSLOG → sistema
• OPERLOG → sysplex
• JESMSGLG → job

---

💡 Uso

👉 entender o “antes” do erro

---

🎥 8. TRACES — O FILME COMPLETO

Enquanto dump = foto
👉 trace = vídeo

---

🔹 Tipos:

• System Trace
• GTF
• Component Trace

---

💡 Uso

👉 analisar fluxo ao longo do tempo

---

🧠 9. DAE — INTELIGÊNCIA DE DUMP

Evita:

👉 dumps repetidos

---

🔥 Usa:

• SYS1.DAE

---

💡 Tradução

“não repetir análise inútil”

---

🔎 10. IPCS — O CSI DO MAINFRAME

Ferramenta para:

• ler dumps
• interpretar dados
• analisar erro

---

💡 Tradução Bellacosa

“IPCS = laboratório forense”

---

🧨 11. SLIP TRAPS — PEGANDO ERRO NO FLAGRA

Você pode definir:

👉 “quando isso acontecer… capture tudo”

---

💡 Exemplo

Se S0C4 ocorrer → gerar dump completo

---

🔥 Tradução

“armadilha inteligente”

---

⚙️ 12. CLEANUP — O FINAL OBRIGATÓRIO

Após erro ou término:

• memória liberada
• datasets fechados
• locks removidos
• timers cancelados

---

💡 Tradução

“ninguém sai sem arrumar o ambiente”

---

🔄 13. PASSO A PASSO COMPLETO

Programa executa
 ↓
Erro ocorre
 ↓
RTM acionado
 ↓
ESTAE / FRR chamados
 ↓
Dump gerado
 ↓
LOGREC atualizado
 ↓
Recursos liberados
 ↓
Sistema continua

---

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. RTM roda até em término normal

---

🔥 2. Dump pode salvar dias de análise

---

💀 3. LOGREC é ignorado por iniciantes

---

🧠 4. SLIP é arma de elite

---

⚡ 5. z/OS foi feito para falhar… e continuar

---

🎯 RESUMO FINAL

✔ RTM controla término e erro

✔ RTM1 protege sistema

✔ RTM2 trata task

✔ ESTAE = recuperação

✔ Dumps = evidência

✔ LOGREC = histórico

✔ IPCS = análise

---

💥 FRASE FINAL

“No mainframe, o erro não encerra o sistema… ele inicia a investigação.”

 

 

☕💾🔥 CICS DATA SETS — O “SUBSOLO INVISÍVEL” QUE MANTÉM BANCOS VIVOS NO MAINFRAME IBM Z

O programador COBOL vê EXEC CICS.

O sysprog vê sobrevivência transacional.

Quando um programador iniciante começa no CICS, normalmente ele enxerga apenas:

EXEC CICS READ
EXEC CICS WRITE
EXEC CICS RETURN

Mas existe um universo gigantesco escondido por trás disso.

Um universo formado por:

• recovery,

• tracing,

• logging,

• observabilidade,

• filas,

• rollback,

• dumps,

• persistência operacional,

• orchestration.

E é exatamente isso que os datasets do CICS representam.

Neste artigo vamos mergulhar profundamente no “lado invisível” do CICS.

Porque:

entender datasets do CICS é começar a pensar como um verdadeiro sysprog.

---

☕ O CICS NÃO É Apenas Um Transaction Monitor

Essa é uma das maiores descobertas que um profissional faz quando amadurece no mundo mainframe.

O CICS:

• não é apenas EXEC CICS,

• não é apenas COBOL online,

• não é apenas tela verde.

Ele é:

• transaction manager,

• recovery engine,

• queue manager,

• observability platform,

• tracing framework,

• runtime orchestrator.

E os datasets são literalmente:

os órgãos internos dessa criatura.

---

🔥 DFHCSD — O DNA Operacional do CICS

O primeiro dataset que um sysprog precisa entender profundamente é:

DFHCSD

O famoso:

CICS System Definition File.

---

☕ O Que o CSD Realmente Faz?

Ele funciona como:

• catálogo mestre,

• banco de definições,

• repositório operacional.

Tudo o que o CICS precisa conhecer:

• PROGRAM,

• TRANSACTION,

• FILE,

• TERMINAL,

• TCPIPSERVICE,

• URIMAP,

• TDQUEUE,

• JVMSERVER,

• PIPELINE,

fica definido no CSD.

---

🔥 O CICS NÃO “DESCUBRE” Recursos Automaticamente

Esse é um ponto fundamental.

No mundo cloud moderno muita gente está acostumada com:

• service discovery,

• auto registration,

• dynamic orchestration.

Mas o CICS nasceu em um mundo onde:

previsibilidade e controle eram mais importantes do que automação descontrolada.

Tudo precisa ser explicitamente definido.

---

☕ O Grande Segredo Arquitetural

O runtime do CICS:

NÃO trabalha diretamente no CSD.

Durante startup ocorre:

DFHCSD
   ↓
INSTALL
   ↓
Control Blocks em memória
   ↓
Runtime CICS

Isso é extremamente sofisticado.

---

🔥 O Que São Control Blocks?

São estruturas internas contendo:

• atributos,

• endereços,

• localização dos programas,

• flags,

• status operacional.

Quando um programa executa:

EXEC CICS LINK PROGRAM('PGM001')

O CICS consulta:

control blocks em memória.

Não o CSD.

---

☕ Isso Explica a Velocidade do CICS

Tudo fica:

• pré-carregado,

• indexado,

• organizado,

• otimizado em memória.

Décadas antes do conceito moderno de:

• metadata caching,

• in-memory orchestration,

• runtime repositories.

---

🔥 O CSD Revolucionou o CICS

Antes dele existiam:

• PPT,

• PCT,

• FCT,

• TCT.

Control tables extremamente rígidas.

Alterações exigiam:

• assemble,

• link-edit,

• restart.

O CSD trouxe:

• definição dinâmica,

• administração online,

• menos downtime,

• maior agilidade.

---

☕ DFHLOG — O Coração da Integridade Transacional

Agora chegamos no componente mais crítico de todos:

o system log.

Sem ele:

• bancos quebrariam,

• saldos ficariam inconsistentes,

• transações seriam perdidas.

---

🔥 O Que o DFHLOG Faz?

Ele registra:

• before images,

• syncpoints,

• rollback records,

• updates,

• UOWs.

Tudo necessário para:

recovery transacional.

---

☕ Before Image — Conceito Fundamental

Antes de alterar um dado:

o CICS grava o estado anterior.

Exemplo:

Saldo = 1000
↓
Tentativa de update para 800

Antes disso:

o valor antigo é registrado no log.

---

🔥 Dynamic Transaction Backout (DTB)

Agora imagine:

Debita conta A
↓
ABEND
↓
Crash

O CICS:

• consulta o DFHLOG,

• identifica updates incompletos,

• executa rollback,

• restaura integridade.

Isso é:

DTB — Dynamic Transaction Backout.

---

☕ Warm Start e Emergency Restart

Quando o CICS reinicia:

ele escaneia o log inteiro.

Para descobrir:

• quais tasks estavam ativas,

• quais UOWs precisam rollback,

• quais recursos devem ser restaurados.

---

🔥 Primary e Secondary Streams

O system log lógico é composto por:

• Primary stream

• Secondary stream

Ambos são vistos como:

um único logical log stream.

Isso mostra uma arquitetura extremamente madura.

---

☕ DFHSHUNT — O Mundo das Shunted UOWs

Quando uma Unit of Work:

• não consegue completar recovery,

• possui recurso indisponível,

• encontra erro persistente,

ela pode ficar:

shunted.

O CICS NÃO perde a integridade.

Ele preserva a UOW para recuperação posterior.

Isso é engenharia mission-critical real.

---

🔥 Dumps — A Forense do CICS

O CICS possui dois níveis principais de dump.

---

☕ System Dump

Captura:

• região inteira,

• memória,

• address spaces,

• control blocks,

• storage global.

Vai normalmente para:

SYS1.DUMPnn

É usado em:

• falhas severas,

• storage corruption,

• kernel problems.

---

🔥 Transaction Dump

Mais focado.

Captura:

• task específica,

• COMMAREA,

• EIB,

• storage da transação.

Usa:

DFHDMPA
DFHDMPB

Muito usado em:

• ASRA,

• S0C7,

• AICA,

• debugging aplicativo.

---

☕ Trace — O Gravador de Voo do CICS

O tracing do CICS é uma obra-prima da engenharia enterprise.

---

🔥 CETR — O Painel de Controle do Trace

A transação:

CETR

permite:

• ativar trace,

• parar trace,

• selecionar domains,

• ajustar níveis,

• controlar GTF,

• configurar auxiliary trace.

---

☕ GTF — Generalized Trace Facility

O GTF integra:

• CICS,

• z/OS,

• VTAM,

• DB2,

• TCP/IP.

Permitindo tracing sistêmico.

Muito antes do conceito moderno de:

• distributed tracing,

• observability pipelines,

• telemetry frameworks.

---

🔥 Auxiliary Trace — Evitando o Wrapping

Trace em memória é circular.

Quando enche:

sobrescreve dados antigos.

Para evitar isso:

DFHAUXT
DFHBUXT

permitem:

• persistência,

• grandes volumes,

• rotação automática.

Isso é praticamente:

rolling logs décadas antes do Linux popularizar isso.

---

☕ SMF — O Big Data Operacional do Mainframe

O CICS também produz telemetria enterprise.

---

🔥 O Que o CICS Grava no SMF?

• CPU usage,

• elapsed time,

• transaction counts,

• waits,

• VSAM activity,

• DB2 usage,

• storage consumption.

Especialmente via:

SMF Type 110

---

☕ Muito Antes da “Observabilidade Moderna”

Enquanto muita gente fala hoje sobre:

• Prometheus,

• Grafana,

• OpenTelemetry,

• observability,

O z/OS já fazia isso:

há décadas.

---

🔥 TSQ — Temporary Storage Queue

O CICS frequentemente precisa guardar dados temporários.

Para isso existem:

TSQs.

---

☕ Características da TSQ

• criação dinâmica,

• leitura por item,

• releitura,

• update.

Exemplo:

EXEC CICS WRITEQ TS
     QUEUE('TEMP001')
END-EXEC

---

🔥 Main TS vs Auxiliary TS

Main TS

• memória,

• rápido,

• temporário.

Auxiliary TS

• VSAM,

• persistente,

• maior capacidade.

Muito usado via:

DFHTEMP

---

☕ TDQ — Transient Data Queue

Agora chegamos em um clássico absoluto do CICS.

---

🔥 TDQ vs TSQ

Essa diferença derruba muitos iniciantes.

---

☕ TSQ

Mais flexível.

---

🔥 TDQ

Mais orientada a fluxo:

• leitura sequencial,

• destrutiva,

• pré-definida.

Ideal para:

• impressão,

• integração batch,

• pipelines assíncronos.

---

☕ Intrapartition vs Extrapartition

Intrapartition

Usada:

dentro da região CICS.

Controlada pelo próprio CICS.

---

Extrapartition

Usada:

dentro e fora do CICS.

Muito comum em:

• integração batch,

• JES,

• exportação,

• geração de arquivos.

---

🔥 O CICS Já Fazia Mensageria Muito Antes do Kafka

Observe algo impressionante.

Décadas antes de:

• Kafka,

• RabbitMQ,

• Event Streaming,

• Message Brokers modernos,

O CICS já implementava:

• filas,

• desacoplamento,

• processamento assíncrono,

• integração enterprise.

---

☕ Global Catalog — A Memória Persistente do Runtime

O global catalog:

• salva recursos instalados,

• guarda localização do system log,

• ajuda no warm start,

• auxilia recovery.

---

🔥 Installed ≠ Defined

Esse conceito é importantíssimo.

Defined

Existe no CSD.

Installed

Está ativo no runtime.

---

☕ O CICS Separa Configuração de Runtime

Isso é extremamente moderno.

Mesmo conceito atual de:

• configuration repositories,

• runtime metadata,

• orchestration state.

---

🔥 O Que Um Sysprog Junior Deve Entender?

Se você está começando em sysprog CICS:

pare de enxergar apenas EXEC CICS.

Comece a enxergar:

• recovery,

• rollback,

• observabilidade,

• logs,

• tracing,

• queues,

• startup orchestration,

• runtime control blocks.

Porque:

é isso que mantém bancos funcionando sem parar.

---

☕ O Grande Insight Final

O mais impressionante do CICS é perceber que:

muito antes da computação distribuída moderna existir,

o mainframe já havia resolvido problemas extremamente complexos.

Como:

• observabilidade,

• tracing,

• rollback automático,

• crash recovery,

• filas assíncronas,

• persistência runtime,

• transaction management.

---

🔥 Pensamento Final ao Estilo Bellacosa Mainframe

O programador iniciante vê:

EXEC CICS READ

O sysprog experiente vê:

• DFHLOG,

• SMF,

• CETR,

• GTF,

• recovery manager,

• syncpoints,

• UOWs,

• auxiliary trace,

• control blocks,

• startup orchestration.

E entende que:

o CICS não é apenas um monitor transacional.

Ele é uma das arquiteturas mais sofisticadas já construídas na história da computação enterprise.

☕💾🔥

 

Bellacosa Mainframe coloca o aluno a prova num lab db2

☕💾 LAB 2 — DB2 Teoria & Prática para Sysprog Júnior 💾☕

🎯 Objetivo do Laboratório

Neste laboratório o aluno irá aprender na prática:

• Catálogo e Diretório DB2
• Recovery e LOG
• Bufferpool
• EDM Pool
• Processamento interno DB2
• Address Spaces
• Troubleshooting básico

---

📘 Parte 1 — Conhecendo o Catálogo DB2

O que é?

O catálogo DB2 contém:

• definições de tabelas,
• índices,
• packages,
• plans,
• objetos do ambiente.

---

Objetivo Prático

Consultar informações do catálogo.

---

SQL

SELECT NAME, CREATOR
FROM SYSIBM.SYSTABLES
FETCH FIRST 10 ROWS ONLY;

---

Resultado Esperado

NAME        CREATOR
----------- --------
SYSTABLES   SYSIBM
SYSCOLUMNS  SYSIBM
SYSINDEXES  SYSIBM

---

Exercício

Quem criou as tabelas acima?

✅ SYSIBM

---

Explicação

O schema SYSIBM contém objetos internos fundamentais do DB2.

---

📘 Parte 2 — Entendendo o Diretório DB2

Conceito

O Directory DB2 armazena:

• objetos internos,
• controle operacional,
• informações críticas do subsistema.

---

Pergunta

Qual database representa o Directory?

A) DSNDB06
B) DSNDB01
C) SYSUTIL
D) DSNCAT

✅ Resposta: B

---

Curiosidade ☕

Database	Função
DSNDB01	Directory
DSNDB06	Catalog

---

📘 Parte 3 — Recovery e LOG

Objetivo

Visualizar informações de LOG.

---

Comando

-DISPLAY LOG

---

Resultado Simulado

CURRENT ACTIVE LOG DATA SET
COPY1 ACTIVE
COPY2 ACTIVE

---

Exercício

Quantas cópias de log estão ativas?

✅ 2

---

Explicação

O DB2 usa redundância para:

• recovery,
• rollback,
• restart,
• auditoria.

---

📘 Parte 4 — Simulando Recovery

Cenário

Uma tabela foi apagada acidentalmente.

---

Pergunta

Qual utilitário pode recuperar o objeto?

A) REORG
B) RECOVER
C) RUNSTATS
D) LOAD

✅ Resposta: B

---

Exemplo de Utility

//STEP1 EXEC PGM=DSNUTILB
//SYSIN DD *
 RECOVER TABLESPACE DBTEST.TSCLI001
/*

---

📘 Parte 5 — Investigando Bufferpool

Objetivo

Consultar bufferpool.

---

Comando

-DISPLAY BUFFERPOOL(BP0)

---

Resultado Simulado

BUFFERPOOL NAME BP0
STATUS ACTIVE
VPSEQT 80

---

Exercício

O bufferpool está ativo?

✅ Sim

---

Pergunta

O bufferpool serve para:

A) Armazenar JCL
B) Cache de páginas DB2
C) Compilar COBOL
D) Gerar logs

✅ Resposta: B

---

📘 Parte 6 — EDM Pool

Conceito

EDM Pool armazena:

• packages,
• plans,
• estruturas SQL em memória.

---

Pergunta

Problemas no EDM Pool podem causar:

A) SQL lento
B) Falha JES2
C) IPL automático
D) VTAM DOWN

✅ Resposta: A

---

📘 Parte 7 — Processamento DB2

Fluxo Simplificado

Aplicação → SQL → DB2 → Bufferpool → Disco

---

Explicação

O DB2 tenta acessar primeiro:
✅ memória (bufferpool)

Depois:
✅ disco físico

---

Exercício

Qual acesso é mais rápido?

A) Disco
B) Bufferpool

✅ Resposta: B

---

📘 Parte 8 — Address Spaces DB2

Objetivo

Conhecer os principais Address Spaces.

---

Principais

Address Space	Função
MSTR	Controle principal
DBM1	Gerenciamento banco
IRLM	Locks
DIST	Conexões distribuídas

---

Pergunta

Qual Address Space controla locks?

A) DIST
B) DBM1
C) IRLM
D) MSTR

✅ Resposta: C

---

📘 Parte 9 — Troubleshooting Real

Cenário

Usuários reclamam de lentidão.

Você executa:

-DISPLAY THREAD(*)

---

Resultado

THREAD STATUS = ACTIVE
TIME = 99999
AUTHID = BATCH01

---

Exercício

O que pode estar acontecendo?

A) Batch longo/travado
B) JES2 parado
C) IPL pendente
D) VTAM indisponível

✅ Resposta: A

---

Próximo Passo

Investigar:

• SQL executado,
• locks,
• utilities,
• CPU,
• I/O.

---

📘 Parte 10 — Determination Problem

Cenário

Aplicação travou.

Você suspeita:

• deadlock,
• lock,
• utility,
• objeto parado.

---

Sequência de investigação

1) Verificar objeto

-DISPLAY DATABASE(DBTEST)

---

2) Verificar threads

-DISPLAY THREAD(*)

---

3) Verificar utility

-DISPLAY UTILITY(*)

---

4) Verificar logs

-DISPLAY LOG

---

☕💀 DESAFIO FINAL — O Caçador de Problemas 💀☕

Cenário

Objeto aparece:

STATUS = STOPPED

---

Pergunta

Qual pode ser a causa?

A) Utility ativa
B) Recovery pendente
C) Intervenção operacional
D) Todas as anteriores

✅ Resposta: D 😅

---

📊 Resumo Final

Tema	Conceito
Catalog	Metadados
Directory	Controle interno
LOG	Recovery
Bufferpool	Cache
EDM Pool	SQL em memória
Address Space	Estrutura DB2
DISPLAY	Diagnóstico

---

☕🔥 Dica Bellacosa Mainframe 🔥☕

Sysprog júnior que aprende:

• DISPLAY,
• recovery,
• bufferpool,
• catálogo,
• address spaces,

já começa a pensar como um verdadeiro especialista DB2 z/OS. ☕💾🔥