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

 

📼 El Jefe Midnight Lunch — Release 1970: ABEND Susto RC=911 🔥💾

 

📼 El Jefe Midnight Lunch — Release 1970: ABEND Susto RC=911 🔥💾
Logs de um sobrevivente do botijão 13kg – Versão Bellacosa Mainframe

---

Ainda estamos nos anos 1970.
Uma década granulada, cor sépia Kodak, som de Chacrinha ecoando longe e cheiro de Kibon Chicabon derretendo no papel. Eu, pequeno Bellacosa, arquivo vivo em fita magnética, presente naquele sábado na casa de Douglas e sua esposa — amigos dos meus pais, gente boa, riso largo, casa cheia do tipo JES2 lotado em horário de pico.

Homens na mesa com cerveja gelada, mulheres no CICS da cozinha montando o jantar — transação constante, sem timeout.
E nós, as crianças, orbitando como tape drives inquietos, buscando petiscos, travessuras e qualquer oportunidade de rodar um job proibido.

Nada muito incomum.
Seria só mais um encontro normal, desses que o storage da memória arquiva e depois descarta por falta de espaço.

Mas aí aconteceu o evento PQP – Panic Queue Protocol.
E este sim ficou gravado com retenção permanente em HD emocional.

---

No auge do preparo da janta, o gás do botijão acabou.
Douglas — root user da residência — foi trocar o cilindro. Só que anos 1970 eram um sistema operacional sem patch de segurança, sem ITIL, sem NR nenhuma. Era plug and pray.

E no swap do botijão, a válvula de contenção falhou.

De repente:
gás pressurizado jorrando como um dump em tela verde.
Gritos. Correria. Jobs cancelados. Checkpoints ignorados.
O ambiente virou um SDSF com ABEND em massa.

Meu pai, por instinto, agarrou Vivi e correu para o quintal.
Minha mãe, movida pelo mesmo desespero mas outro raciocínio, me puxou e correu para dentro da casa. Sim, para dentro.

E aqui entra o detalhe arquitetônico brasileiro:
Casa brasileira é máquina de segurança física nível RACF ultra restritivo.
Grades, fechaduras, ferrolhos, trancas.
Tudo pensado para impedir entrada — e sem rollback para saída.

Minha mãe me levou, na melhor das intenções, para uma armadilha perfeita.
Se o gás acendesse… nós dois viraríamos job zombie, sem saída, presos atrás de barras de aço. Um "halt and catch fire" literal.

Mas como você percebe — console ainda online, sessão ativa — o pior não aconteceu.
O botijão era pequeno, 13kg, liberou o inferno por uns 10 minutos, talvez menos, talvez mais — criança conta tempo como CPU sem relógio.
Quando a pressão diminuiu e o risco passou, meu pai entrou, nos resgatou do quarto como herói com override de segurança.

E como era 1970 —
não teve psicólogo, não teve auditoria de segurança, não teve SMS de incidente crítico.

Pegaram outro botijão. Continuaram a cozinhar.
E no final, jantamos todos juntos, rindo, reconstruindo o dump daquele quase-desastre.
Uma história que quase se perdeu no spool da vida, se não fosse pelo evento P-Q-P estampado na memória ROM da infância.

E cá estou.
Bit sobrevivente, bloco íntegro, registro ativo.

Vivo para contar.
E jantar outra vez.

🔥🐇💾
Bellacosa — log registrado, commit efetuado, RC=0 (por milímetros).