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

 

 

Bellacosa Mainframe apresenta Suporte a Produção

☕🔥 Suporte à Produção Mainframe — engenharia operacional em estado bruto

Se você já deu CANCEL com o coração na mão, já leu dump em hexadecimal, já decorou mensagem $HASP melhor que CPF, então este texto não é para iniciantes.
Aqui falamos de Produção de verdade. Sem romantização. Sem power-point bonito.

---

🧠 Suporte à Produção Mainframe ≠ Operação

É engenharia operacional sob carga real.

Produção não é:

• Rodar job

• Reiniciar STC

• Abrir chamado

Produção é:

• Análise de impacto

• Decisão em ambiente crítico

• Entendimento sistêmico do z/OS

• Correlação entre eventos aparentemente desconexos

Produção é onde o design encontra a realidade — e geralmente perde.

---

🕰️ Raiz Histórica (para quem veio do MVS, não do YouTube)

O Suporte à Produção nasce quando:

• O batch deixou de ser “linear”

• O online passou a ser 24x7

• O negócio começou a depender de janela de processamento

• O erro deixou de ser aceitável

A evolução foi clara:

• Operador de console →

• Analista de Produção →

• Especialista em estabilidade operacional

Hoje, Produção é a última linha de defesa entre o z/OS e o prejuízo financeiro.

---

🎯 Objetivo Real do Suporte à Produção (versão sem marketing)

• Garantir throughput, não apenas execução

• Controlar contenção, não apenas erro

• Preservar integridade transacional

• Manter SLA, RTO e RPO

• Atuar antes do incidente virar crise

☕ Veterano sabe:

Produção não corrige código — corrige efeito colateral.

---

🧩 Arquitetura de Conhecimento (o que separa júnior de veterano)

🖥️ z/OS — domínio do núcleo

• JES2/JES3, initiators, classes, priorities

• Spool contention

• ENQ/DEQ, RESERVE, latch

• WTOR, automation hooks

• Dumps SVC vs SYSMDUMP

🔥 Apimentado:
Quem não entende JES não entende produção.

---

🧠 CICS — transação é sagrada

• Task Control

• Storage violation

• Transaction isolation

• Deadlock silencioso

• Dumps DSNAP / CEEDUMP

☕ El Jefe truth:

CICS não cai — ele sangra em silêncio.

---

📬 MQ — quando o assíncrono vira gargalo

• Depth x High/Low Threshold

• Channels retrying

• Poison message

• Commit vs rollback

• Impacto no batch e no online

🔥 Easter egg:
Fila cheia é sintoma, não causa.

---

🔌 Integration Bus (Broker)

• Flow degradation

• Message backlog

• XML/JSON parsing cost

• CPU vs I/O trade-off

• Propagação de erro invisível

☕ Fofoquice técnica:
Quando o Broker falha, todo mundo aponta para o mainframe.

---

🧪 REXX — automação tática

• Monitoramento ativo

• Ações condicionais

• Coleta de evidência

• Resposta automática a eventos

• Integração com SDSF, consoles e logs

🔥 Produção sem REXX é operação cega.

---

🗄️ DB2 Utilities — o campo minado

• REORG mal planejado

• RUNSTATS atrasado

• Lock escalation

• Deadlock intermitente

• Log pressure

☕ Frase clássica:

“Não mexe agora… deixa rodar.”

---

🌐 WebSphere / Acesso Remoto

• JVM pressure

• Thread starvation

• Timeout mascarado

• Latência invisível

• Cascata de falhas

🔥 Curiosidade:
O Web cai rápido. O mainframe aguenta a culpa.

---

🔍 Funcionamento Real em Produção (sem filtro)

1. Sintoma aparece longe da causa

2. Métrica parece normal

3. SLA corre

4. Dump gerado

5. Análise cruzada (JES + CICS + DB2 + MQ)

6. Decisão com risco calculado

7. Execução mínima, impacto máximo

8. Ambiente estabiliza

9. Post-mortem técnico

10. Documentação (que ninguém lê… até precisar)

---

🧠 Mentalidade do Veterano

✔️ Não confia em “achismo”
✔️ Não executa comando sem rollback mental
✔️ Pensa em efeito dominó
✔️ Prefere degradar a parar
✔️ Sabe quando não agir

☕🔥 Regra de ouro:

Em Produção, o comando mais perigoso é o que “sempre funcionou”.

---

🥚 Easter Eggs de Produção

• Todo ambiente tem um job que “ninguém encosta”

• Sempre existe um dataset com DISP=SHR que não deveria

• Todo incidente grave começa com:

  “Isso nunca aconteceu antes…”

• O melhor analista é o que não aparece no incidente report

---

🧨 Conclusão — El Jefe Midnight Lunch Manifesto

Suporte à Produção Mainframe é:

• Arquitetura viva

• Engenharia sob estresse

• Decisão sem margem de erro

• Responsabilidade sem aplauso

Não é glamour.
Não é palco.
É confiança operacional.

☕🔥 Se você já sobreviveu a uma madrugada de produção,
você sabe:

Produção não ensina — ela seleciona.

 

🧪 LAB CICS : 🧠 CICS — O que é (sem enrolação)

 

Bellacosa Mainframe em primeiros passos no mundo CICS Mainframe

🧠 CICS — O que é (sem enrolação)

O IBM CICS Transaction Server é o coração transacional do mainframe.

👉 Pense assim:

• Batch (JCL) = processamento em lote (fila, previsível)
• CICS = processamento online em tempo real

📌 Ele gerencia:

• Transações simultâneas (milhares!)
• Sessões de usuários (terminais, web, APIs)
• Integridade (commit/rollback)
• Integração com DB2, MQ, VSAM

💥 Tradução prática:

Se o usuário apertou ENTER e quer resposta na hora → tem CICS por trás.

---

🏗️ Arquitetura mental (modo operador)

Você não precisa decorar tudo — mas precisa entender o jogo:

🔹 Região CICS

• É como um “mini sistema operacional” dentro do z/OS
• Tem memória, tarefas e controle próprio

🔹 Transações

• Código de 4 letras (ex: CEMT, CECI)
• Entrada do usuário

🔹 Programas

• Normalmente em COBOL
• Executados sob controle do CICS

🔹 Recursos

• Arquivos (VSAM)
• Bancos (DB2)
• Filas (MQ)

---

🎮 Primeiros comandos (sobrevivência no CICS)

Esses aqui são o kit de sobrevivência do operador:

🔹 CEMT — o canivete suíço

CEMT I TASK
CEMT I TRANS
CEMT I FILE

👉 Serve para:

• Ver tarefas rodando
• Ver transações ativas
• Checar arquivos

---

🔹 CECI — laboratório interativo

CECI

👉 Executa comandos CICS manualmente
👉 Perfeito para testes sem programa

---

🔹 CESN / CESF — login/logout

CESN  (sign on)
CESF  (sign off)

---

🧪 LAB 1 — “Primeiro contato com a Força”

🎯 Objetivo: entender o que está rodando no CICS

Passo a passo:

1. Acesse o terminal (TSO ou emulador)
2. Entre no CICS
3. Digite:

CEMT I TASK

👉 Observe:

• TASK NUMBER
• STATUS
• CPU TIME

💡 Insight Bellacosa:

Cada linha ali é alguém usando o sistema agora — isso é produção viva!

---

🧪 LAB 2 — Investigando transações

CEMT I TRANS

👉 Veja:

• Transações habilitadas/desabilitadas
• Status (ENABLED / DISABLED)

🔥 Teste:

CEMT SET TRANS(xxxx) DISABLED

⚠️ Cuidado:

Você pode derrubar sistema se fizer isso em produção!

---

🧪 LAB 3 — Teste controlado com CECI

CECI

Execute:

EXEC CICS ASSIGN

👉 Veja:

• USERID
• TERMINAL
• TASK

💥 Isso é introspecção do ambiente

---

🧪 LAB 4 — Arquivos (VSAM na veia)

CEMT I FILE

👉 Veja:

• OPEN / CLOSED
• ENABLED / DISABLED

Teste (ambiente controlado!):

CEMT SET FILE(xxxx) CLOSED

---

🧭 Mentalidade de Produção (o diferencial)

Aqui está o pulo do gato 🧠

🔥 Você NÃO é desenvolvedor — você é guardião do runtime

Você precisa pensar em:

• Sistema está lento?
• Travou?
• Loop infinito?
• Recurso indisponível?

👉 Ferramentas-chave:

• CEMT
• CEDF (debug de transação)
• SMF / logs
• dumps (abend)

---

⚠️ Erros clássicos de iniciante

❌ Rodar comando sem saber impacto
❌ Derrubar FILE em produção
❌ Desabilitar TRANS crítica
❌ Ignorar mensagens do CICS

💥 Regra de ouro:

“Se você não sabe o efeito → NÃO execute”

---

🧠 Mapa mental resumido

• CICS = tempo real
• TRANS = entrada
• TASK = execução
• PROGRAM = lógica
• FILE/DB = dados

---

🚀 Próximos passos (nível Jedi)

Se quiser evoluir, recomendo:

1. Criar sua primeira transação COBOL
2. Aprender EXEC CICS READ/WRITE
3. Entender COMMIT/ROLLBACK
4. Trabalhar com TSQ/TDQ
5. Explorar integração com APIs (CICS Web Services)

O IBM CICS Transaction Server é o coração transacional do mainframe.

👉 Pense assim:

• Batch (JCL) = processamento em lote (fila, previsível)
• CICS = processamento online em tempo real

📌 Ele gerencia:

• Transações simultâneas (milhares!)
• Sessões de usuários (terminais, web, APIs)
• Integridade (commit/rollback)
• Integração com DB2, MQ, VSAM

💥 Tradução prática:

Se o usuário apertou ENTER e quer resposta na hora → tem CICS por trás.

---

🏗️ Arquitetura mental (modo operador)

Você não precisa decorar tudo — mas precisa entender o jogo:

🔹 Região CICS

• É como um “mini sistema operacional” dentro do z/OS
• Tem memória, tarefas e controle próprio

🔹 Transações

• Código de 4 letras (ex: CEMT, CECI)
• Entrada do usuário

🔹 Programas

• Normalmente em COBOL
• Executados sob controle do CICS

🔹 Recursos

• Arquivos (VSAM)
• Bancos (DB2)
• Filas (MQ)

---

🎮 Primeiros comandos (sobrevivência no CICS)

Esses aqui são o kit de sobrevivência do operador:

🔹 CEMT — o canivete suíço

CEMT I TASK
CEMT I TRANS
CEMT I FILE

👉 Serve para:

• Ver tarefas rodando
• Ver transações ativas
• Checar arquivos

---

🔹 CECI — laboratório interativo

CECI

👉 Executa comandos CICS manualmente
👉 Perfeito para testes sem programa

---

🔹 CESN / CESF — login/logout

CESN  (sign on)
CESF  (sign off)

---

🧪 LAB 1 — “Primeiro contato com a Força”

🎯 Objetivo: entender o que está rodando no CICS

Passo a passo:

1. Acesse o terminal (TSO ou emulador)
2. Entre no CICS
3. Digite:

CEMT I TASK

👉 Observe:

• TASK NUMBER
• STATUS
• CPU TIME

💡 Insight Bellacosa:

Cada linha ali é alguém usando o sistema agora — isso é produção viva!

---

🧪 LAB 2 — Investigando transações

CEMT I TRANS

👉 Veja:

• Transações habilitadas/desabilitadas
• Status (ENABLED / DISABLED)

🔥 Teste:

CEMT SET TRANS(xxxx) DISABLED

⚠️ Cuidado:

Você pode derrubar sistema se fizer isso em produção!

---

🧪 LAB 3 — Teste controlado com CECI

CECI

Execute:

EXEC CICS ASSIGN

👉 Veja:

• USERID
• TERMINAL
• TASK

💥 Isso é introspecção do ambiente

---

🧪 LAB 4 — Arquivos (VSAM na veia)

CEMT I FILE

👉 Veja:

• OPEN / CLOSED
• ENABLED / DISABLED

Teste (ambiente controlado!):

CEMT SET FILE(xxxx) CLOSED

---

🧭 Mentalidade de Produção (o diferencial)

Aqui está o pulo do gato 🧠

🔥 Você NÃO é desenvolvedor — você é guardião do runtime

Você precisa pensar em:

• Sistema está lento?
• Travou?
• Loop infinito?
• Recurso indisponível?

👉 Ferramentas-chave:

• CEMT
• CEDF (debug de transação)
• SMF / logs
• dumps (abend)

---

⚠️ Erros clássicos de iniciante

❌ Rodar comando sem saber impacto
❌ Derrubar FILE em produção
❌ Desabilitar TRANS crítica
❌ Ignorar mensagens do CICS

💥 Regra de ouro:

“Se você não sabe o efeito → NÃO execute”

---

🧠 Mapa mental resumido

• CICS = tempo real
• TRANS = entrada
• TASK = execução
• PROGRAM = lógica
• FILE/DB = dados

---

🚀 Próximos passos (nível Jedi)

Se quiser evoluir, recomendo:

1. Criar sua primeira transação COBOL
2. Aprender EXEC CICS READ/WRITE
3. Entender COMMIT/ROLLBACK
4. Trabalhar com TSQ/TDQ
5. Explorar integração com APIs (CICS Web Services)
6.