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