Bellacosa Mainframe indica um lab para troubleshooting no Z/os SMP/E

🧪 LAB SMP/E — “Do APPLY sem CHECK ao RESTORE salvador”

🎯 Objetivo

Você vai:

• Executar RECEIVE → APPLY → ACCEPT → RESTORE
• Simular um erro real
• Diagnosticar via relatórios
• Recuperar o sistema corretamente

👉 Traduzindo:

você vai errar com segurança para aprender de verdade

---

🧱 Cenário do LAB

🖥️ Ambiente

• z/OS (real ou Hercules TK5)
• SMP/E configurado
• CSI existente
• Zonas:
  • GLOBAL
  • TARGET
  • DLIB

---

📦 Dados do exercício

• FMID: HXYZ123
• PTFs:
  • UQ00001 (base)
  • UQ00002 (dependente)
  • UQ00003 (com problema 💀)

---

🔄 FASE 1 — RECEIVE

🎯 Objetivo

Carregar SYSMODs no SMP/E

---

🧾 JCL

//RECEIVE JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPPTFIN DD DISP=SHR,DSN=SEU.PTF.INPUT
//SMPCNTL  DD *
 SET BDY(GLOBAL).
 RECEIVE SYSMODS.
/*

---

✅ Esperado

• SYSMODs no SMPPTS
• GLOBAL ZONE atualizada

---

🔍 Validar

• SMPRPT
• LIST SYSMODS

---

💣 FASE 2 — ERRO PROPOSITAL (APPLY SEM CHECK)

🎯 Objetivo

Simular erro real de produção

---

🧾 JCL (errado propositalmente)

//APPLY JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(TARGET).
 APPLY SELECT(UQ00003).
/*

---

💥 Resultado esperado

• Aplicação incompleta OU
• Sistema inconsistente

---

🧠 O que você fez

💀 ignorou dependências + não usou CHECK

---

🔍 FASE 3 — DIAGNÓSTICO

🎯 Objetivo

Descobrir o problema

---

📄 Analisar:

• SMPOUT
• SMPRPT
• Causer Report

---

💡 Encontrar:

• Dependência faltando (UQ00002)
• Possível HOLD

---

🧠 Insight

SMP/E não falha — ele te avisa

---

🔁 FASE 4 — APPLY CORRETO

🎯 Objetivo

Corrigir com CHECK

---

🧾 JCL

//APPLY JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(TARGET).
 APPLY CHECK SELECT(UQ00003) GROUPEXTEND.
/*

---

✅ Resultado

• Lista completa de dependências
• Nenhuma alteração real

---

🔥 Agora aplicar certo:

 APPLY SELECT(UQ00003) GROUPEXTEND.

---

📦 FASE 5 — ACCEPT

🎯 Objetivo

Consolidar mudança

---

🧾 JCL

//ACCEPT JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(DLIB).
 ACCEPT CHECK.
/*

---

⚠️ Depois:

 ACCEPT.

---

💀 Agora você não volta fácil…

---

🚨 FASE 6 — INCIDENTE

🎯 Simular problema pós-APPLY

👉 Imagine:

• Programa começa a falhar
• Load module inconsistente

---

🔄 FASE 7 — RESTORE

🎯 Objetivo

Reverter mudança

---

🧾 JCL

//RESTORE JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(TARGET).
 RESTORE SELECT(UQ00003) GROUP CHECK.
/*

---

🔍 Ajustar dependências

Depois:

 RESTORE SELECT(UQ00003) GROUP.

---

✅ Resultado

• TARGET revertido
• Sistema estável

---

💣 VARIAÇÃO AVANÇADA (nível sênior)

😈 Faça isso:

1. APPLY
2. ACCEPT
3. Tente RESTORE

---

💥 Resultado:

RESTORE não resolve

---

🧠 Aprendizado:

ACCEPT muda o jogo completamente

---

📊 CHECKLIST DO LAB

Etapa	Status
RECEIVE executado	☐
APPLY sem CHECK (erro)	☐
Diagnóstico feito	☐
APPLY correto	☐
ACCEPT realizado	☐
RESTORE executado	☐

---

🧠 LIÇÕES DO LAB

🔥 1. RECEIVE define o futuro

🔥 2. APPLY muda o presente

🔥 3. ACCEPT congela o sistema

🔥 4. RESTORE depende do passado

---

☕ FRASE FINAL

💀 “O erro não está no SMP/E… está em quem pula etapas.”

SMP/E for z/OS Workshop: Restore

Bellacosa Mainframe apresenta SMP/E Restore

SMP/E for z/OS Workshop

RESTORE: quando o Apply deu ruim e você precisa voltar no tempo (sem desligar a produção)

Se APPLY é instalar e ACCEPT é oficializar, RESTORE é o botão de “desfaz” do SMP/E.
Mas não se engane: RESTORE não é CTRL+Z. Ele exige entendimento profundo de dependências, níveis de serviço e do que está no target versus no distribution.

Vamos destrinchar isso no melhor estilo Bellacosa Mainframe: sem romantismo, com realidade de produção.

---

O que é o comando RESTORE no SMP/E?

O RESTORE permite remover um ou mais SYSMODs aplicados no target, reinstalando o nível existente nos DLIBs (distribution libraries) de volta para as target libraries.

📌 Ponto-chave

RESTORE só funciona para SYSMODs que foram APPLIED e ainda NÃO ACCEPTED.

Na prática:

• Algo foi aplicado

• Quebrou, gerou erro, impacto funcional ou regressão

• Você precisa voltar o código para o último nível aceito

RESTORE entra em ação.

---

Onde o RESTORE atua?

RESTORE é sempre direcionado a um Target Zone:

SET BDY(TZONE)

Esse target zone:

• Identifica as target libraries

• Mapeia qual distribution zone (DZONE) contém o backup válido

• Será atualizado com os metadados corretos após o restore

📦 O SMP/E não inventa código
Ele reinstala exatamente o que está nos DLIBs.

---

O que o RESTORE realmente faz?

Durante o processamento, o SMP/E:

✔ Substitui os elementos do target pelos elementos do DLIB
✔ Reexecuta link-edit se necessário
✔ Copia FMID, RMID e UMID do DZONE para o TZONE
✔ Atualiza o CSI
✔ Remove registros do SYSMOD restaurado (dependendo das opções)

Ou seja:

O target volta a refletir o último nível oficialmente aceito.

---

RESTORE vs APPLY – parecem iguais, mas não são

APPLY	RESTORE
Usa SMPPTS	Usa DLIBs
Entrada: Global Zone + SMPPTS	Entrada: DZONE + DLIBs
Instala novo código	Reinstala código anterior
Avança nível	Retrocede nível

👉 Ambos atualizam Target Libraries e Target Zone, mas com propósitos opostos.

---

Inline JCLIN e SMPCDS: o detalhe que derruba gente experiente

Se o SYSMOD a ser restaurado possui inline JCLIN, o SMP/E precisa do SMPCDS.

Por quê?

Porque o SMPCDS contém:

• Backup da estrutura do TZONE

• Informações necessárias para restaurar corretamente macros, source e datasets

Sem isso, o RESTORE pode:

• Falhar

• Ou deixar o ambiente inconsistente

---

O comando RESTORE na prática

Exemplo básico:

RESTORE 
  SELECT(UP00003)

Operandos importantes

🔹 SELECT (obrigatório)

Define quais SYSMODs você quer remover.

---

🔹 GROUP (a parte traiçoeira)

No RESTORE, o GROUP funciona ao contrário do APPLY.

• APPLY: GROUP busca pré-requisitos ausentes

• RESTORE: GROUP busca SYSMODs que DEPENDEM do selecionado

👉 Se um SYSMOD depende do que você quer remover, ele também precisa ser restaurado.

---

🔹 CHECK (sempre use!)

RESTORE CHECK SELECT(UP00003)

CHECK:

• Não altera nada

• Analisa dependências

• Mostra mensagens do tipo GIM35922I

📌 Dica Bellacosa:

Raramente o primeiro RESTORE CHECK resolve tudo.
Rode, leia os relatórios, ajuste o SELECT, rode de novo.

---

Exemplo clássico de dependências (vida real)

Temos 7 PTFs aplicados:

UP00001
 └─ UP00002
     ├─ UP00003
     │   ├─ UP00005
     │   └─ UP00007
     └─ UP00004
         └─ UP00006

Somente UP00001 foi ACCEPTED.

🎯 Objetivo: restaurar UP00003

Pergunta clássica de prova e produção:

Posso restaurar só o UP00003?

❌ Não.

Você também precisa restaurar:

• UP00005

• UP00007

Porque dependem diretamente dele.

---

Onde descobrir isso sem chutar?

1️⃣ Mensagens SMP/E (ex: GIM35922I)
2️⃣ SYSMOD Status Report
3️⃣ CAUSER SYSMOD SUMMARY REPORT ← o mais importante

Esse relatório explica:

• Por que o RESTORE falhou

• Quais SYSMODs estão bloqueando

• O que falta no SELECT

---

O que o SMP/E remove após um RESTORE bem-sucedido?

Se NOREJECT = OFF:

• Remove entrada do SYSMOD no Global Zone

• Remove MCS do SMPPTS

• Remove SMPTLIBs (se existirem)

⚠️ HOLD DATA NÃO É REMOVIDA

Se NOREJECT = ON:

• Remove apenas APPID do Target Zone

---

RESTORE não é simples (e nunca foi)

RESTORE pode se tornar complexo quando:

• Muitos PTFs aplicados

• DLIB muito atrás do Target

• Cadeias longas de dependência

👉 É comum rodar:

RESTORE CHECK
RESTORE CHECK
RESTORE CHECK

Até fechar todo o quebra-cabeça.

---

Conclusão Bellacosa Mainframe

RESTORE é:

• Uma ferramenta poderosa

• Um salva-produção

• Um teste de maturidade do system programmer

Quem domina RESTORE:
✔ Entende dependências
✔ Entende níveis de serviço
✔ Não entra em pânico quando APPLY quebra

APPLY instala. ACCEPT oficializa. RESTORE ensina humildade.

No próximo módulo, o foco sai do SMP/E operacional e entra no product build — onde o código nasce antes de virar SYSMOD.