Bellacosa Mainframe e um laboratorio pratico IMS DB

☕💣🚨 LABORATÓRIO IMS PARA SYSPROGS E SYSADMINS

10 Incidentes Reais de Monitoramento e Troubleshooting no IMS Mainframe

Este laboratório foi projetado para colocar o aluno em situações próximas das encontradas em bancos, seguradoras e ambientes corporativos que utilizam IMS TM e IMS DB.

Objetivo:

• Desenvolver raciocínio de troubleshooting

• Interpretar sintomas

• Utilizar monitoramento

• Identificar causa raiz

• Aplicar correções

---

LAB 1 — Filas OTMA Crescendo Sem Parar

Cenário

Usuários reclamam que operações via aplicativo móvel estão lentas.

Monitoramento:

OMEGAMON IMS

OTMA Queue Depth

08:00 -> 100
08:05 -> 500
08:10 -> 1500
08:15 -> 3500

---

O que investigar

Verificar:

/DIS TMEMBER
/DIS TRAN

Analisar:

• IMS Connect

• OTMA

• MPPs disponíveis

---

Diagnóstico

As mensagens chegam.

Os programas não conseguem consumi-las.

---

Causa Raiz

Todas as MPPs estão ocupadas.

---

Solução

Aumentar MPPs:

/START REGION TYPE(MPP)

ou corrigir programa que está monopolizando processamento.

---

LAB 2 — IMS Connect Respondendo Lentamente

Cenário

Aplicativo mobile demora 15 segundos.

Terminal IMS continua rápido.

---

Monitoramento

PING OK

IMS TM OK

IMS Connect Response
15 segundos

---

Investigação

Verificar:

NETSTAT
AT-TLS
TCPIP

---

Diagnóstico

Handshake TLS excessivamente lento.

---

Causa

Certificado expirado gerando renegociações.

---

Solução

Atualizar certificados RACF.

Reiniciar componentes TLS.

---

LAB 3 — Região MPP Consumindo CPU Excessiva

Cenário

CPU dispara para 95%.

---

Monitoramento

RMF

IMSMPR01

CPU = 92%

---

Investigação

Verificar:

/DIS REGION

Analisar dumps.

---

Diagnóstico

Loop lógico no programa COBOL.

---

Causa

GN executado sem condição de parada.

---

Solução

Corrigir programa.

Recompilar.

Reimplantar.

---

LAB 4 — Banco IMS Não Abre

Cenário

Após IPL:

/START DB

Falha.

---

Mensagem

DATABASE NOT AVAILABLE

---

Investigação

Consultar:

DBRC
RECON

---

Diagnóstico

Image Copy inconsistente.

---

Causa

Backup interrompido.

---

Solução

Executar Recovery.

Gerar nova Image Copy.

---

LAB 5 — Shared Queue Congestionada

Cenário

IMSplex apresenta lentidão.

---

Monitoramento

CQS Queue Depth

Normal: 300

Atual: 25.000

---

Investigação

Verificar:

CQS
CF
Shared Queues

---

Diagnóstico

Estrutura da Coupling Facility saturada.

---

Solução

Expandir estrutura.

Redistribuir carga.

---

LAB 6 — Falha de Comunicação Mobile → IMS

Cenário

Aplicativo recebe:

HTTP 503

---

Investigação

Fluxo:

Mobile
 |
API
 |
z/OS Connect
 |
IMS Connect

---

Diagnóstico

IMS Connect indisponível.

---

Verificação

D A,L

---

Solução

Reiniciar:

S HWS

---

LAB 7 — Crescimento Anormal de Storage

Cenário

IMS termina com:

S878

---

Monitoramento

Region Storage

31-bit exhausted

---

Investigação

Analisar:

Buffers
Pools
Storage reports

---

Diagnóstico

Buffer pool configurado incorretamente.

---

Solução

Redimensionar buffers.

Migrar estruturas para 64 bits.

---

LAB 8 — Tempo de Resposta Intermitente

Cenário

Usuário reclama:

Às vezes rápido.
Às vezes lento.

---

Monitoramento

RMF

I/O Peaks

---

Investigação

Verificar:

• DASD

• Storage Controller

• Canal FICON

---

Diagnóstico

Contenção de I/O.

---

Solução

Redistribuir datasets.

Balancear volumes.

---

LAB 9 — Falha de Recovery

Cenário

Recovery falha.

---

Mensagem

LOG RECORD MISSING

---

Investigação

Analisar:

RECON
Archive Logs
DBRC

---

Diagnóstico

Log arquivado ausente.

---

Solução

Restaurar log perdido.

Reexecutar recovery.

---

LAB 10 — O Incidente das 2 da Manhã

Cenário

Todos os sintomas aparecem ao mesmo tempo.

Filas crescendo
CPU alta
Usuários reclamando
Mobile lento

---

Monitoramento

OMEGAMON
RMF
IMS
TCPIP

---

Investigação

Passo 1

CPU

Passo 2

Storage

Passo 3

IMS Connect

Passo 4

MPP

Passo 5

OTMA

---

Diagnóstico

Uma única MPP travada.

Todas as filas aguardando.

---

Solução

Cancelar região problemática.

/CANCEL REGION

Iniciar nova região.

/START REGION TYPE(MPP)

Filas normalizam.

Sistema volta ao normal.

---

Resultado Esperado do Laboratório

Ao concluir os 10 incidentes o aluno terá contato com:

✅ IMS TM

✅ IMS Connect

✅ OTMA

✅ MPP

✅ BMP

✅ Shared Queues

✅ CQS

✅ IMSplex

✅ DBRC

✅ Recovery

✅ Storage

✅ Performance

✅ OMEGAMON

✅ RMF

✅ RACF

✅ TCP/IP

E principalmente aprenderá a pensar como um Sysprog ou Sysadmin experiente:

"Não procurar apenas o erro, mas entender o fluxo completo da transação do usuário até o IMS Database."

☕💣🚀 Regra de ouro do laboratório: em ambientes IMS, o sintoma raramente está no mesmo lugar da causa raiz. O trabalho do Sysprog e do Sysadmin é seguir a trilha da transação até encontrar o verdadeiro culpado.

 

Bellacosa Mainframe e root cause analysis em Mainframe

---

☕🔥💣 “O SYSprog PADAWAN E A ARTE DA GUERRA CONTRA O CAOS” — ROOT CAUSE ANALYSIS NO MAINFRAME Z17, DEVOPS, CICS, JES2 E A CAÇADA À CAUSA RAIZ

Quando o operador para de apagar incêndios e começa a eliminar demônios do datacenter

Existe um momento na vida de todo Sysprog Padawan em que ele percebe uma verdade brutal do universo corporativo:

“Reiniciar o JOB não resolveu o problema…”

Apenas escondeu o cadáver.

E é exatamente nesse momento que nasce a verdadeira disciplina do guerreiro IBM Z:
a arte da Root Cause Analysis — ou simplesmente RCA.

No universo do mainframe moderno, onde bilhões de transações passam por CICS, DB2, MQ, IMS e JES2, problemas não aparecem do nada.

Todo ABEND possui uma origem.

Todo LOOP tem um motivo.

Todo dataset corrompido conta uma história.

E todo operador experiente sabe:

“O sintoma mente. A causa raiz não.”

Hoje vamos mergulhar profundamente no universo da RCA no estilo Bellacosa Mainframe, explorando:

• história,

• filosofia,

• métodos,

• guerra operacional,

• automação,

• observabilidade,

• DevOps,

• IA operacional,

• e sobrevivência psicológica em ambientes z/OS críticos.

Prepare o café.
Abra o SDSF.
E mantenha o dump por perto.

Porque o LOBO da causa raiz está observando.

---

☕ O QUE É ROOT CAUSE ANALYSIS?

Root Cause Analysis é a ciência de descobrir a verdadeira origem de um problema.

Não o sintoma.
Não o efeito.
Não o caos superficial.

Mas sim:
o gatilho original que iniciou a cascata da destruição.

Na definição da IBM:

“RCA é o processo de identificar a raiz de um problema para evitar sua recorrência.”

O detalhe importante aqui é:

EVITAR RECORRÊNCIA.

Porque qualquer novato consegue:

• cancelar TASK,

• reiniciar STC,

• reciclar CICS,

• dar IPL no desespero.

Mas poucos conseguem impedir o problema de voltar.

---

☕ A DIFERENÇA ENTRE OPERADOR E ENGENHEIRO

Operador reativo:

“Voltou a funcionar? Ótimo.”

Engenheiro RCA:

“Por que parou?”

Essa diferença separa:

• operadores comuns,

• Sysprogs lendários.

---

☕ A ORIGEM HISTÓRICA DA RCA

A RCA não nasceu na TI.

Ela surgiu em ambientes extremos.

Segunda Guerra Mundial

Engenheiros militares precisavam descobrir:

• por que aviões caíam,

• por que motores explodiam,

• por que radares falhavam.

Não havia espaço para tentativa e erro.

A falha matava pessoas.

A filosofia então evoluiu para:

• engenharia industrial,

• indústria nuclear,

• aviação,

• automóveis,

• telecom,

• e finalmente TI corporativa.

---

☕ TOYOTA E O MÉTODO DOS 5 WHYs

Nos anos 1950, Taiichi Ohno criou o famoso:

“5 Porquês”

A lógica era simples:

Continue perguntando “por quê?” até encontrar a verdade.

---

☕ EXEMPLO MAINFRAME REALÍSTICO

Problema:

JOB noturno ABEND S0C7.

---

Por quê?

Campo numérico inválido.

---

Por quê?

Arquivo veio com caracteres errados.

---

Por quê?

Conversão ASCII/EBCDIC falhou.

---

Por quê?

Novo middleware FTP alterou encoding.

---

Por quê?

Mudança entrou sem homologação.

---

CAUSA RAIZ:

Processo DevOps inadequado.

Perceba:
o COBOL não era o vilão.

O problema estava na governança.

---

☕ O MAIOR ERRO DOS PADAWANS

Todo Sysprog iniciante acredita em sintomas.

Mas sintomas enganam.

Exemplo clássico:

Sintoma:

CPU alta.

O Padawan pensa:

“Precisamos de mais processador.”

O mestre RCA responde:

“Não.
Precisamos descobrir QUEM está consumindo CPU.”

Pode ser:

• loop COBOL,

• SQL ruim,

• runaway task,

• lock contention,

• buffer inadequado,

• storage leak,

• automação defeituosa.

A CPU alta é apenas o grito do sistema.

---

☕ OS 3 TIPOS DE CAUSAS

A IBM divide RCA em três dimensões.

---

1. CAUSAS FÍSICAS

Hardware.
Infraestrutura.
Equipamentos.

Exemplos:

• DASD defeituoso

• canal FICON instável

• controladora falhando

• memória ECC corrompida

• falha elétrica

---

☕ EXEMPLO Z/OS

O JES2 começa a apresentar I/O ERROR.

Batch falha aleatoriamente.

Após investigação:

Causa raiz:

microfissura em controladora storage.

---

2. CAUSAS HUMANAS

O terror invisível do datacenter.

Exemplos:

• operador cancelando STC errada,

• PROC alterada incorretamente,

• DELETE DATASET acidental,

• parâmetro inválido,

• JCL truncado.

---

☕ O CLÁSSICO ERRO DO PADAWAN

//STEP01 EXEC PGM=IEFBR14
//DD1 DD DSN=PROD.CLIENTES,
// DISP=(OLD,DELETE,DELETE)

Parabéns.

Você acabou de invocar o demônio ancestral do DELETE em produção.

---

3. CAUSAS ORGANIZACIONAIS

As mais perigosas.

Porque sobrevivem por anos.

Exemplos:

• ausência de documentação,

• treinamento ruim,

• processo inexistente,

• automação incompleta,

• cultura tóxica,

• deploy sem governança.

---

☕ A VERDADE SOMBRIA

Grandes falhas raramente acontecem por um único motivo.

Elas acontecem porque:

múltiplas pequenas falhas se alinham.

Igual peças de dominó.

---

☕ O CICLO DA DESTRUIÇÃO OPERACIONAL

1. Pequena falha ignorada

2. Monitoramento ruim

3. Automação incompleta

4. Time cansado

5. Mudança mal testada

6. Alertas ignorados

7. Deploy na sexta-feira

8. Caos absoluto

---

☕ O PROCESSO COMPLETO DE RCA

Agora entramos na disciplina guerreira.

---

ETAPA 1 — IDENTIFICAR O PROBLEMA

Definição ruim:

“O sistema caiu.”

Definição profissional:

“O CICS PAY01 apresentou degradação progressiva após aumento de lock contention DB2 causado por crescimento anômalo de filas MQ.”

Agora sim existe material técnico.

---

☕ ETAPA 2 — MONTAR O TIME RCA

Você precisa reunir:

• operadores,

• Sysprogs,

• DBAs,

• DevOps,

• segurança,

• storage,

• redes,

• automação.

Porque falhas modernas são híbridas.

---

☕ ETAPA 3 — COLETA DE DADOS

Aqui começa a arqueologia digital.

Ferramentas clássicas:

• SDSF

• RMF

• SMF

• IPCS

• NetView

• OMEGAMON

• SYSLOG

• dumps

• traces

• logs MQ

• logs DB2

---

☕ O PODER DOS LOGS

Logs são fósseis digitais.

Eles contam a história da tragédia.

O problema é:

Padawans não leem logs.

Eles olham apenas:

• RC=12

• ABEND=S806

• IEC141I

E entram em pânico.

---

☕ ETAPA 4 — BRAINSTORM DAS CAUSAS

Aqui existe uma regra sagrada:

NÃO ASSUMA NADA.

O maior inimigo da RCA é:

“Já sei o que aconteceu.”

Porque normalmente você NÃO sabe.

---

☕ ETAPA 5 — DETERMINAR A CAUSA RAIZ

Agora elimina-se hipótese por hipótese.

Até restar:

• evidência,

• causalidade,

• sequência lógica.

---

☕ ETAPA 6 — IMPLEMENTAR A SOLUÇÃO

Agora nasce a verdadeira engenharia.

Não basta corrigir.

É preciso:

• automatizar,

• prevenir,

• monitorar,

• alertar,

• documentar.

---

☕ MÉTODOS RCA MAIS IMPORTANTES

---

☕ 5 WHYs

Simples.
Poderoso.
Mortal.

Excelente para:

• incidentes operacionais,

• falhas batch,

• troubleshooting rápido.

---

☕ FMEA

Failure Mode and Effects Analysis.

Muito usado em:

• bancos,

• aviação,

• missão crítica.

Objetivo:

Prever COMO o sistema pode falhar antes do desastre.

---

☕ ISHIKAWA (FISHBONE)

O famoso diagrama espinha de peixe.

Divide problemas em categorias:

• pessoas,

• máquinas,

• processos,

• ambiente,

• software,

• gestão.

Excelente para war rooms.

---

☕ PARETO

80% dos problemas vêm de 20% das causas.

Exemplo real:

• 70% dos ABENDs vêm de input inválido.

• 15% vêm de espaço.

• 10% vêm de lock.

• 5% diversos.

Ataque os 20%.
Ganhe estabilidade absurda.

---

☕ RCA EM DEVOPS

No DevOps moderno:

TODO INCIDENTE GERA POSTMORTEM.

Mas aqui existe uma mudança filosófica gigantesca.

---

☕ BLAMELESS POSTMORTEM

Google popularizou:

“Postmortem sem caça às bruxas.”

Objetivo:

Não destruir pessoas.
Mas aprender.

Porque sistemas falham.
Humanos erram.
Processos quebram.

A maturidade está em aprender rápido.

---

☕ RCA NO MAINFRAME MODERNO

O IBM Z atual é extremamente avançado.

Hoje temos:

• observabilidade,

• IA operacional,

• automação,

• analytics,

• machine learning.

Ferramentas modernas:

• IBM Instana

• OMEGAMON

• System Automation

• NetView

• z/OSMF

• SMF Analytics

---

☕ EXEMPLO REAL — O APOCALIPSE DO PIX

Imagine:

Sexta-feira.
18:05.
PIX nacional congestionado.

Sintomas:

• CICS lento

• MQ crescendo

• DB2 travando

• CPU disparando

Padawans entram em desespero.

---

☕ INVESTIGAÇÃO

A RCA descobre:

Deploy DevOps alterou frequência de COMMIT.

Resultado:

• lock contention,

• timeout,

• crescimento de filas,

• efeito cascata.

---

☕ CAUSA RAIZ

Mudança sem teste de carga.

---

☕ SOLUÇÃO

• rollback,

• observabilidade,

• testes automáticos,

• limites MQ,

• monitoramento preditivo.

Agora o sistema ficou MAIS FORTE que antes.

Esse é o verdadeiro objetivo da RCA.

---

☕ A ERA DA IA OPERACIONAL

Hoje AIOps tenta prever:

• anomalias,

• falhas,

• gargalos,

• tendências,

• causas prováveis.

O futuro do Sysprog não é apenas reagir.

Será:

prever o desastre antes dele nascer.

---

☕ O VERDADEIRO NÍVEL MESTRE

O Sysprog lendário não luta contra incêndios.

Ele elimina as condições que permitem incêndios.

---

☕ LIÇÕES FINAIS PARA O SYSprog PADAWAN

Nunca confie no primeiro sintoma.

Nunca assuma a primeira hipótese.

Nunca ignore pequenos alertas.

Nunca faça deploy sexta-feira.

Nunca delete dataset sem olhar duas vezes.

Nunca subestime logs.

Nunca trate apenas o efeito.

---

☕ CONCLUSÃO

Root Cause Analysis não é apenas metodologia.

É mentalidade.

É disciplina.

É engenharia real.

No mundo IBM Z moderno, onde bilhões dependem da estabilidade do sistema, RCA separa:

• operadores comuns,

• arquitetos da confiabilidade.

Quando você aprende RCA:

você deixa de ser alguém que “reinicia sistemas”.

E se torna alguém que entende o funcionamento profundo do caos.

E no momento em que você compreende o caos…

você começa a dominar o datacenter.

☕🔥💣

Bellacosa Mainframe apresenta um checklist de RCA para sysprog junior

☕🔥💣 CHECKLIST DEFINITIVO DE RCA PARA O SYSprog PADAWAN

Como Evoluir de Apagador de Incêndios para Caçador de Causas Raiz

A maioria dos Sysprogs juniores aprende primeiro a resolver incidentes.

Poucos aprendem a impedir que eles aconteçam novamente.

O objetivo deste checklist é desenvolver a mentalidade de investigação que transforma um operador técnico em um verdadeiro engenheiro de confiabilidade.

---

🔍 NÍVEL 1 — FUNDAMENTOS DO INVESTIGADOR

Conhecer a arquitetura do ambiente

☐ Entender o fluxo completo da aplicação

☐ Conhecer as LPARs existentes

☐ Entender Sysplex

☐ Conhecer JES2/JES3

☐ Entender CICS

☐ Entender DB2

☐ Entender MQ

☐ Conhecer Storage Management

☐ Entender WLM

☐ Conhecer SDSF profundamente

Objetivo

Parar de enxergar componentes isolados e começar a enxergar o ecossistema.

---

📋 NÍVEL 2 — COLETA DE EVIDÊNCIAS

Antes de agir:

☐ Registrar horário exato do incidente

☐ Identificar quem reportou

☐ Verificar impacto

☐ Capturar mensagens de erro

☐ Salvar logs

☐ Salvar SYSLOG

☐ Salvar JESMSGLG

☐ Salvar JESJCL

☐ Salvar JESYSMSG

☐ Registrar alterações recentes

☐ Verificar deploys recentes

Regra de ouro

Nunca altere o ambiente antes de coletar evidências.

---

🔥 NÍVEL 3 — ANÁLISE JES2

☐ Verificar initiators

☐ Verificar classes

☐ Verificar backlog

☐ Verificar spool

☐ Verificar HOLDs

☐ Verificar jobs looping

☐ Verificar jobs aguardando recursos

☐ Verificar ENQ contention

☐ Verificar mensagens $HASP

Pergunta obrigatória

O problema começou no JES2 ou chegou até ele?

---

💾 NÍVEL 4 — STORAGE E MEMÓRIA

☐ Verificar CSA

☐ Verificar ECSA

☐ Verificar SQA

☐ Verificar ESQA

☐ Verificar Private Area

☐ Procurar storage leaks

☐ Analisar crescimento anormal

☐ Verificar mensagens IEA e IEF

☐ Consultar RMF

Atenção

Muitos "problemas de sistema" são apenas vazamentos de memória.

---

⚡ NÍVEL 5 — PERFORMANCE

☐ Verificar CPU

☐ Verificar I/O

☐ Verificar Paging

☐ Verificar DASD

☐ Verificar Coupling Facility

☐ Verificar WLM

☐ Verificar gargalos

☐ Comparar com baseline

☐ Analisar tendências

Objetivo

Entender se a degradação é sintoma ou causa.

---

🖥️ NÍVEL 6 — RCA EM CICS

☐ Verificar transações lentas

☐ Verificar tasks pendentes

☐ Verificar Short On Storage

☐ Verificar TD Queues

☐ Verificar TS Queues

☐ Verificar DB2 Attach

☐ Verificar MQ Attach

☐ Verificar abends

☐ Verificar dumps

☐ Analisar traces

Nunca conclua

"CICS está lento"

sem descobrir:

"POR QUE está lento?"

---

🗄️ NÍVEL 7 — RCA EM DB2

☐ Verificar deadlocks

☐ Verificar lock escalation

☐ Verificar SQLCODEs

☐ Verificar buffer pools

☐ Verificar índices

☐ Procurar full table scan

☐ Verificar RUNSTATS

☐ Verificar REORG pendente

☐ Verificar crescimento de tabelas

Regra

Muitos problemas de CICS são, na verdade, problemas de DB2.

---

📬 NÍVEL 8 — RCA EM MQ

☐ Verificar Queue Depth

☐ Verificar canais

☐ Verificar backlog

☐ Verificar consumidores

☐ Verificar produtores

☐ Verificar DLQ

☐ Verificar mensagens presas

☐ Verificar timeouts

Lembre-se

Fila cheia normalmente é consequência.

Raramente é a causa raiz.

---

📊 NÍVEL 9 — OBSERVABILIDADE

☐ Utilizar OMEGAMON

☐ Utilizar RMF

☐ Utilizar SMF

☐ Utilizar NetView

☐ Utilizar Sysview

☐ Criar dashboards

☐ Definir baseline

☐ Identificar anomalias

☐ Correlacionar eventos

Meta

Parar de reagir.

Começar a prever.

---

🔎 NÍVEL 10 — TÉCNICAS DE INVESTIGAÇÃO

Five Whys

☐ Aplicar os 5 Porquês

---

Timeline Analysis

☐ Construir linha do tempo

---

Event Correlation

☐ Correlacionar eventos

---

Impact Analysis

☐ Medir impacto real

---

Trend Analysis

☐ Procurar recorrência

---

🤖 NÍVEL 11 — AUTOMAÇÃO E PREVENÇÃO

☐ Automatizar alertas

☐ Automatizar coleta de evidências

☐ Automatizar correções simples

☐ Criar scripts REXX

☐ Criar procedimentos de recuperação

☐ Integrar com SA z/OS

☐ Integrar com NetView

☐ Criar runbooks

Objetivo

Não resolver mais rápido.

Resolver menos vezes.

---

📚 NÍVEL 12 — CONHECIMENTO HISTÓRICO

☐ Manter base de incidentes

☐ Documentar RCA

☐ Criar Wiki interna

☐ Registrar lições aprendidas

☐ Catalogar soluções

☐ Criar biblioteca de dumps

☐ Registrar padrões recorrentes

Ouro do Sysprog

Experiência documentada vale mais que memória.

---

🧠 NÍVEL 13 — MENTALIDADE DE MESTRE

Antes de qualquer ação pergunte:

☐ O que aconteceu?

☐ Quando aconteceu?

☐ Quem foi impactado?

☐ O que mudou?

☐ Isso já aconteceu antes?

☐ O que os logs mostram?

☐ O que os dados mostram?

☐ Estou tratando sintoma ou causa?

☐ Como impedir recorrência?

☐ O que aprendi hoje?

---

🏆 CHECKLIST FINAL DO SYSprog MESTRE

Quando um incidente ocorrer:

❌ Não reinicie imediatamente

❌ Não assuma conclusões

❌ Não culpe usuários

❌ Não culpe desenvolvedores

❌ Não culpe infraestrutura

✅ Colete evidências

✅ Analise dados

✅ Correlacione eventos

✅ Pergunte "por quê?"

✅ Encontre a causa raiz

✅ Elimine a recorrência

✅ Documente a descoberta

✅ Compartilhe conhecimento

---

☕ Regra Suprema do Bellacosa Mainframe

"O Padawan reinicia o CICS.

O Sysprog investiga o dump.

O Mestre encontra a causa raiz.

O Arquiteto faz o problema desaparecer para sempre." 🚀💣🔥

 

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