Bellacosa Mainframe em uma visão sobre o LOG do DB2

🔥☕ O SUBMUNDO DO Db2 z/OS — LOGS, RECOVERY E O QUE ACONTECE QUANDO O BANCO “MORRE” ☕🔥

Existe um momento na vida de todo programador COBOL/Db2 em que ele descobre uma verdade assustadora:

O Db2 nunca esquece nada.

Cada:

• INSERT,
• UPDATE,
• DELETE,
• COMMIT,
• ROLLBACK,
• ALTER,
• REORG,

deixa rastros.

E esses rastros vivem dentro de uma das estruturas mais importantes do ecossistema mainframe:

🔥 O LOG DO Db2.

Se você é programador COBOL pleno e acha que recovery é “coisa de DBA”, cuidado.

Porque no dia em que um:

-904
-911
-803
00C90084
RESOURCE UNAVAILABLE

explodir produção às 3h da manhã…

você vai descobrir que entender o log do Db2 muda completamente sua carreira.

---

☕ O QUE É O LOG DO Db2?

O log do Db2 é o “diário transacional” do banco.

Tudo que altera dados gera registros de log.

O Db2 escreve:

• before image,
• after image,
• controle transacional,
• checkpoints,
• unidades de recuperação.

Basicamente:

ALTERAÇÃO → LOG → DISCO

Antes mesmo da página ser gravada no tablespace.

---

🔥 ACTIVE LOGS vs ARCHIVE LOGS

Aqui começa uma das maiores confusões dos iniciantes.

🔹 Active Logs

São os logs online e ativos.

Ficam sendo usados continuamente.

Eles armazenam:

• alterações recentes,
• transações em andamento,
• recovery imediato.

São críticos.

Perder active log é pesadelo nível apocalipse.

---

🔹 Archive Logs

Quando active logs ficam cheios:

• Db2 descarrega,
• copia,
• arquiva.

Esses logs históricos viram:

ARCHIVE LOGS

Eles são usados para:

• PIT recovery,
• auditoria,
• rollback histórico,
• disaster recovery.

---

☕ COMO O Db2 ESCREVE NO LOG?

Muita gente acha que Db2 grava direto no disco.

Não.

Primeiro ele grava em:

🔥 LOG BUFFERS

na memória.

Depois:

• COMMIT,
• checkpoint,
• buffer cheio,
• sync I/O,

forçam gravação nos:

ACTIVE LOG DATASETS

---

🔥 WRITE AHEAD LOGGING (WAL)

Aqui está o segredo do recovery moderno.

O Db2 segue:

🔥 WAL — Write Ahead Logging

Regra:

“O log precisa ser gravado ANTES da página do banco.”

Isso garante:

• rollback,
• redo,
• recuperação consistente.

Sem isso:
💀 corrupção.

---

☕ O QUE ACONTECE NUM COMMIT?

Quando o programa COBOL faz:

EXEC SQL COMMIT END-EXEC

o Db2:

1. sincroniza logs,
2. confirma UOW,
3. libera locks,
4. torna alterações permanentes.

O COMMIT é basicamente:

🔥 “Agora isso virou verdade oficial.”

---

☕ E NUM ABEND?

Aqui entra o terror psicológico do DBA.

Se ocorre:

• S0C7,
• S878,
• timeout,
• deadlock,
• cancel,
• crash,
• queda de LPAR,

o Db2 usa os logs para:

🔥 ROLLBACK

Ele desfaz tudo desde o último COMMIT.

---

🔥 TIPOS DE ERRO MAIS COMUNS

---

⚠️ SQLCODE -911 / -913

Deadlock ou timeout

Dois programas querem recursos incompatíveis.

Exemplo clássico:

• batch segurando tabela,
• online tentando atualizar.

DBA/Sysprog:

• analisar locking,
• IFCID,
• traces,
• IRLM,
• timeout values.

Programador COBOL:

• reduzir tempo entre commits,
• melhorar SQL,
• evitar scan gigante.

---

⚠️ SQLCODE -904

Resource unavailable

Tablespace parado.
Utility rodando.
Objeto indisponível.

DBA:

• verificar STOP status,
• utilities,
• claim/drain,
• locks.

Sysprog:

• investigar subsystem,
• storage,
• I/O,
• coupling facility.

---

⚠️ SQLCODE -803

Duplicate key

Programador tentou inserir chave já existente.

Programador:

• validar lógica,
• tratar concorrência,
• revisar sequence/identity.

DBA:

• verificar índice,
• constraints,
• integridade.

---

⚠️ SQLCODE -805

Package não encontrado

Clássico inferno de deploy.

DBA:

• verificar BIND,
• PLAN/PACKAGE,
• consistency token.

Sysprog:

• SDSNLOAD,
• STEPLIB,
• DBRM libraries.

Programador:

• garantir promote correto.

---

⚠️ 00C90084

Log full

Aqui o DBA começa a envelhecer rapidamente.

O active log lotou.

Possíveis causas:

• UOW gigante,
• commit inexistente,
• archive parado.

DBA:

• verificar ARCHIVE process,
• aumentar logs,
• cancelar job problemático.

Programador:

• COMMIT frequente,
• evitar transação monstruosa.

---

☕ COMO FUNCIONA O RECOVERY?

Aqui mora a mágica do Db2.

---

🔥 FORWARD RECOVERY

Db2:

1. restaura image copy,
2. reaplica logs.

Resultado:
✅ banco volta até ponto desejado.

---

🔥 BACKOUT / ROLLBACK

Db2 usa:

• before images,
• undo records.

E desfaz alterações.

---

🔥 RESTART RECOVERY

Após crash do subsystem:

Db2:

• lê logs,
• identifica UOW incompletas,
• faz undo/redo automático.

Muitas vezes o usuário nem percebe.

---

☕ O PAPEL DO DBA

O DBA é o “cirurgião do banco”.

Ele:

• monitora logs,
• executa RECOVER,
• controla utilities,
• administra image copies,
• resolve locking,
• acompanha catalog,
• analisa performance.

Ferramentas clássicas:

• DSN1LOGP,
• RECOVER,
• COPY,
• REORG,
• DISPLAY DATABASE,
• DISPLAY LOG.

---

☕ O PAPEL DO SYSPROG

O Sysprog atua na infraestrutura pesada.

Ele cuida:

• do subsystem Db2,
• IRLM,
• z/OS,
• JES,
• storage,
• coupling facility,
• datasets de log,
• BSDS,
• bootstrap datasets.

Se o DBA é cirurgião…
o Sysprog é engenheiro nuclear.

---

☕ O QUE O PROGRAMADOR COBOL PRECISA ENTENDER?

Muito mais do que imaginam.

Porque SQL ruim gera:

• lock,
• timeout,
• log storm,
• escalation,
• crash recovery lento.

---

🔥 Um bom programador Db2:

✅ faz commit racional
✅ evita cursor infinito
✅ reduz scans
✅ trata SQLCODE corretamente
✅ entende UOW
✅ sabe impacto do rollback
✅ evita transações gigantes

---

☕ O MAIOR ERRO DOS INICIANTES

Achar que:

COMMIT é só “salvar”.

Não.

COMMIT é:

• sincronização,
• liberação de lock,
• persistência,
• checkpoint lógico,
• controle de recovery.

É o coração do Db2 transacional.

---

🔥 CONCLUSÃO

O log do Db2 é praticamente:

🔥 a memória do banco.

Sem ele:

• não existe rollback,
• recovery,
• integridade,
• restart,
• consistência.

Quando você entende:

• active log,
• archive log,
• WAL,
• UOW,
• rollback,
• recovery,

você deixa de ser apenas “quem escreve SELECT”.

E começa a pensar como:

• DBA,
• sysprog,
• arquiteto transacional.

E no universo mainframe…

isso muda tudo. ☕🔥

⚡💣 LAB CICS — MEM CRÍTICO 🚨 “QUANDO A MEMÓRIA ACABA… O CICS PEDE SOCORRO” 🚨

 

Bellacosa Mainframe memoria critica no CICS

⚡💣 LAB CICS — MEM CRÍTICO

🚨 “QUANDO A MEMÓRIA ACABA… O CICS PEDE SOCORRO” 🚨

👉 Tema: SOS (Short on Storage) + degradação + decisão de failover

---

🎬 🎯 CENÁRIO

Você está operando uma região do
IBM CICS

🕐 14:32 — horário crítico
📍 Região: CICSPRD1
📍 Ambiente: Produção

---

💥 ALERTAS INICIAIS

• Tempo de resposta subindo
• Tasks WAITING
• CPU irregular
• Storage aumentando rápido

---

💣 LOGS (CSMT)

DFHSM0133 Short on storage condition detected
DFHSM0606 Storage violation detected

👉 Tradução Bellacosa:

“O CICS está ficando sem memória — e isso escala rápido.”

---

🧠🔥 FASE 1 — DIAGNÓSTICO INICIAL

🔎 Comando:

CEMT I SYS

🔥 Resultado típico:

• Storage > 90%
• Tasks acumulando
• Sistema degradando

---

❓ O que você faz?

A) Reinicia CICS
B) Ignora
C) Analisa storage
D) Derruba tudo

---

✅ RESPOSTA: C

👉 Reiniciar agora pode piorar
👉 Você precisa entender quem está consumindo storage

---

🔍 FASE 2 — INVESTIGAÇÃO DE STORAGE

🔎 Ver tasks:

CEMT I TASK

👉 Procure:

• Tasks longas
• Muitas instâncias
• Status WAITING

---

💡 Padrão clássico:

• Programa não liberando storage
• Loop com GETMAIN
• Leak de memória

---

📊 FASE 3 — IDENTIFICAR VILÃO

🔎 Filtro:

CEMT I TASK TRA(ORDR)

👉 Resultado:

• Muitas tasks
• Alto consumo
• Crescendo continuamente

---

❓ Diagnóstico provável:

A) CPU
B) Storage leak
C) Rede
D) MQ

---

✅ RESPOSTA: B

🔥 Você está vendo um memory leak em CICS

---

☠️💣 FASE 4 — CONTENÇÃO IMEDIATA

Agora vem decisão crítica.

🎯 Objetivo:

• parar consumo
• evitar colapso

---

💥 Ações:

1. Derrubar tasks críticas:

CEMT SET TASK(501) PURGE

Se necessário:

CEMT SET TASK(501) FORCEPURGE

---

2. Bloquear transação:

CEMT SET TRAN(ORDR) DISABLED

👉 Isso é essencial.

---

🧬 FASE 5 — SITUAÇÃO PIORA 😈

Mesmo após purge:

• Storage não libera totalmente
• Região continua degradando

👉 Isso acontece porque:

• Fragmentação
• Storage preso
• Controle interno comprometido

---

🚨 FASE 6 — DECISÃO CRÍTICA (NÍVEL SYSPROG)

❓ O que fazer agora?

A) Continuar purge
B) Reiniciar região
C) Acionar failover
D) Ignorar

---

✅ RESPOSTA IDEAL: C

👉 Você entra no modo resiliência

---

🌍⚡ FAILOVER COM GDPS

Utilizando:

IBM GDPS

---

💥 Ação:

• Transferir workload
• Ativar região standby
• Redirecionar usuários

---

🎯 Resultado esperado:

• Continuidade de serviço
• Zero downtime perceptível (ou mínimo)

---

🧯 FASE 7 — ESTABILIZAÇÃO

Após failover:

• Região secundária assume
• Sistema normaliza
• Usuários voltam

---

🔬 FASE 8 — ANÁLISE PROFUNDA

Agora você investiga a causa real.

🔎 Ferramentas:

• IBM IPCS
• IBM Fault Analyzer

---

💣 Descoberta:

• Programa COBOL com loop de GETMAIN
• Sem FREEMAIN
• Leak progressivo

---

🔧 FASE 9 — CORREÇÃO DEFINITIVA

📋 Ações:

• Corrigir código
• Garantir FREEMAIN
• Revisar uso de storage
• Testar em QA

---

🧠💡 LIÇÕES DE OURO

👉 SOS nunca é “só performance”
👉 É risco de colapso total

👉 Sempre:

• monitore storage
• detecte crescimento anormal
• tenha failover preparado

---

🧩😄 EASTER EGGS

• “SOS não avisa duas vezes”
• “Se chegou no SOS… alguém esqueceu FREEMAIN”
• “Memory leak em CICS é assassino silencioso”

---

🏁 SCORE FINAL

Critério	Resultado
Diagnóstico	🧠 Excelente
Tempo de reação	⚡ Crítico
Contenção	🎯 Precisa
Resiliência	🛡️ Nível enterprise

---

🎯💬 FECHAMENTO

Esse lab é o divisor de águas.

👉 Aqui você deixa de ser operador
👉 e vira engenheiro de sobrevivência do mainframe

 

Bellacosa Mainframe apresenta um Simulador CICS

🚨💥 SIMULADOR CICS — “GUERRA EM PRODUÇÃO” 💥🚨

🎮 Modo: Interativo | 🎯 Objetivo: Restaurar o serviço sem causar dano colateral

Você está no comando de uma região do IBM CICS em produção.

---

🎬 CENÁRIO INICIAL

🕐 10:02 — Pico de acesso
📍 Região: CICS01
📍 Aplicação crítica: pagamentos

💥 Sintomas:

• Tempo de resposta > 5s
• CPU subindo rápido
• Usuários travando
• Chamados explodindo 😄

---

🧠 FASE 1 — PRIMEIRA DECISÃO

Você precisa agir rápido.

❓ O que você faz primeiro?

A) Reinicia o CICS
B) Analisa logs e tasks
C) Derruba todas as tasks
D) Ignora (pode ser pico)

👉 Escolha mentalmente antes de continuar

---

✅ RESPOSTA CORRETA: B

👉 Reiniciar = impacto massivo
👉 Derrubar tudo = caos
👉 Ignorar = carreira curta 😄

---

🔍 FASE 2 — INVESTIGAÇÃO

Você executa:

CEMT I TASK

🔥 Resultado:

• 40 tasks da transação PAY1
• Todas RUNNING
• Mesmo USERID

---

❓ Próxima ação?

A) Esperar normalizar
B) Filtrar por transação
C) Derrubar aleatoriamente
D) Reiniciar região

👉 Escolha…

---

✅ RESPOSTA: B

CEMT I TASK TRA(PAY1)

👉 Agora você tem visibilidade total

---

📊 FASE 3 — DIAGNÓSTICO

Você analisa uma task:

CEMT I TASK TAS(401)

🔎 Observação:

• CPU TIME alto
• STATUS: RUNNING
• Sem I/O

👉 Isso indica:

❓

A) Espera de recurso
B) Loop CPU
C) Falha de rede
D) Storage baixo

---

✅ RESPOSTA: B (LOOP CPU)

🔥 Você achou o vilão.

---

☠️ FASE 4 — DECISÃO CRÍTICA

Agora vem a parte que separa operador de sysprog.

❓ O que fazer?

A) PURGE uma task
B) FORCEPURGE todas
C) Desabilitar transação
D) Nada

---

✅ RESPOSTA IDEAL: A + C

💥 Execução:

CEMT SET TASK(401) PURGE

Depois:

CEMT SET TRAN(PAY1) DISABLED

👉 Você:

• remove impacto imediato
• evita novas ocorrências

---

🧬 FASE 5 — INVESTIGAÇÃO PROFUNDA

Agora você precisa entender a causa.

💥 Gerar dump:

CEMT SET TRD(PAY1) DUMP

🔎 Análise com:

• IBM IPCS
• IBM Fault Analyzer

---

💣 Resultado:

• Loop em programa COBOL
• Falta de condição de saída

👉 Erro clássico de desenvolvimento 😄

---

🧯 FASE 6 — ESTABILIZAÇÃO

Você monitora:

CEMT I SYS

✅ Resultado:

• CPU normalizando
• Tasks reduzindo
• Usuários voltando

---

🔧 FASE 7 — PÓS-INCIDENTE

Agora entra maturidade real.

📋 Ações obrigatórias:

• Corrigir código
• Criar alerta de CPU
• Monitorar transação
• Revisar deploy

---

🏁 RESULTADO FINAL

🧾 SCORE

Critério	Resultado
Tempo de reação	⚡ Excelente
Impacto evitado	🛡️ Alto
Diagnóstico	🧠 Correto
Ação	🎯 Precisa

👉 🎉 Você salvou a produção.

---

🧩😄 VARIAÇÕES DO SIMULADOR (PRÓXIMO NÍVEL)

Se quiser evoluir o treinamento:

💣 Cenário 2

• Deadlock com DB2

💥 Cenário 3

• MQ travando fila

🔥 Cenário 4

• SOS (Short on Storage)

⚡ Cenário 5

• Região inteira degradando

---

🎯💬 FECHAMENTO

Esse tipo de simulador treina:

• raciocínio sob pressão
• tomada de decisão
• domínio real de CICS

👉 Porque no mundo real:

“Quem hesita… derruba produção.”

 

 

Bellacosa Mainframe desafio LAB C|ICS

🚨💥 LAB CICS: “A TASK QUE PAROU A EMPRESA” — DO CAOS À RECUPERAÇÃO 💥🚨

🎬 🎯 CENÁRIO

📍 Ambiente: Produção
📍 Região: CICS01
📍 Horário: 10:17 (pico)
📍 Sintoma:

• Usuários travados
• Tempo de resposta absurdo
• CPU subindo
• Reclamação geral 😄

👉 Clássico incidente crítico.

---

🧠🔥 FASE 1 — DETECÇÃO (O ALERTA)

🔎 Primeira ação: ver mensagens

CEMT I SYS

👉 Você percebe:

• Tasks acumulando
• Sistema lento

Agora vá direto ao log:

CEBR CSMT

💣 Você encontra:

DFHAC2001 TRANSACTION PAY1 ABENDED WITH CODE ASRA

👉 Tradução:

• Programa quebrando (provável S0C4)
• Pode estar em loop/restart

---

🕵️‍♂️ FASE 2 — IDENTIFICAR O PROBLEMA

🔍 Listar tasks:

CEMT I TASK

🔥 Saída suspeita:

Tas(000345) Tra(PAY1) Use(APPUSR) Sta(RUN)
Tas(000346) Tra(PAY1) Use(APPUSR) Sta(RUN)
Tas(000347) Tra(PAY1) Use(APPUSR) Sta(RUN)

👉 ALERTA:

• Mesma transação
• Mesmo user
• Muitas instâncias
• Todas rodando

💡 Possível cenário:

• Loop
• Deadlock
• Programa bugado

---

🎯 Filtro cirúrgico:

CEMT I TASK TRA(PAY1)

👉 Resultado:

• 30+ tasks abertas 😄

Agora ficou sério.

---

📊⚡ FASE 3 — ANÁLISE DE CONSUMO

🔎 Ver comportamento:

CEMT I TASK TAS(345)

👉 Observe:

• CPU TIME alto
• STATUS RUNNING contínuo
• Sem I/O

👉 Isso é clássico:

🔥 LOOP CPU (runaway task)

---

🧬 FASE 4 — INVESTIGAÇÃO PROFUNDA (DUMP)

Agora você quer prova técnica.

💥 Gerar dump:

CEMT SET TRD(PAY1) DUMP

ou automático via abend

---

🧠 Análise do dump:

Ferramentas:

• IBM IPCS
• IBM Fault Analyzer

🔎 Você encontra:

• Loop em programa COBOL
• Parágrafo sem EXIT 😄
• Variável nunca alterada

👉 Bingo.

---

☠️💣 FASE 5 — CONTENÇÃO (AÇÃO IMEDIATA)

Agora você precisa salvar o ambiente.

💥 Derrubar tasks:

CEMT SET TASK(345) PURGE

Se resistir:

CEMT SET TASK(345) FORCEPURGE

👉 Repita para as demais:

CEMT I TASK TRA(PAY1)

---

🚫 Bloquear entrada da transação:

CEMT SET TRAN(PAY1) DISABLED

👉 Isso evita novas execuções

---

🧯 FASE 6 — ESTABILIZAÇÃO

Agora observe:

CEMT I SYS

👉 Esperado:

• CPU normalizando
• Tasks reduzindo
• Sistema respondendo

💡 Se não normalizar:

• Ver DB2 locks
• Ver filas MQ
• Ver storage

---

🔧 FASE 7 — CORREÇÃO DEFINITIVA

Agora vem o pós-incidente.

📌 Ações:

• Corrigir programa COBOL
• Revisar lógica de loop
• Adicionar timeout/escape
• Validar com QA

---

🧠💡 FASE 8 — LIÇÕES DE OURO

👉 Sempre monitore:

• Transações com crescimento rápido
• CPU anormal
• Tasks duplicadas

👉 Crie alertas para:

• ASRA recorrente
• Volume de tasks
• Tempo de resposta

---

🧩😄 EASTER EGGS DO LAB

• “Toda FORCEPURGE tem história”
• “Loop em COBOL sempre aparece na sexta”
• “Se tem ASRA em massa… prepara café” ☕

---

🧪🎯 QUIZ — NÍVEL OPERADOR / SYSPROG

1️⃣ O que indica muitas tasks RUNNING com CPU alto?

A) I/O intenso
B) Loop CPU
C) Problema de rede
D) Storage baixo

👉 Resposta: B

---

2️⃣ Comando para ver tasks:

A) CEDF
B) CEMT I TASK
C) CICS LIST
D) DISPLAY TASK

👉 Resposta: B

---

3️⃣ Diferença entre PURGE e FORCEPURGE?

A) Nenhuma
B) FORCEPURGE força finalização imediata
C) PURGE é mais agressivo
D) PURGE mata região

👉 Resposta: B

---

4️⃣ O que é ASRA?

A) Timeout
B) Falha lógica COBOL
C) Erro de storage/execução
D) Deadlock

👉 Resposta: C

---

5️⃣ Melhor ação inicial?

A) Reiniciar CICS
B) Derrubar tudo
C) Analisar tasks e logs
D) Ignorar

👉 Resposta: C

---

🎯💬 FECHAMENTO ESTILO BELLOCAZZA

Ser SysProg de CICS não é saber comando.

É:

• ler comportamento
• antecipar desastre
• agir rápido
• e salvar produção sem pânico

👉 Porque no mundo real:

“Uma única task errada… pode derrubar milhares de usuários.”