Bellacosa Mainframe Laboratorio SMP/E do caos a orquestração

🧪 LAB SMP/E — DO CAOS À ORQUESTRAÇÃO

🎯 Objetivo do Lab

Você vai executar:

1. 📦 RECEIVE / APPLY (com erro)
2. 📊 REPORT (diagnóstico)
3. 🔗 LINK MODULE (correção)
4. 🏗️ BUILDMCS (empacotamento)

👉 Resultado final:

Um ambiente corrigido, analisado e exportável

---

🧱 CENÁRIO DO LAB

👉 Situação:

• Produto instalado parcialmente
• Módulo faltando no LMOD
• PTF aplicada sem dependência

💥 Resultado:

Erro de execução + inconsistência SMP/E

---

🔥 PASSO 1 — RECEIVE (entrada da manutenção)

//RECEIVE JOB (ACCT),'SMP/E LAB',CLASS=A,MSGCLASS=X
//SMPCSI   DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPTS   DD DISP=SHR,DSN=SYS1.SMP.PTS
//SMPCNTL  DD *
  SET      BOUNDARY(GLOBAL).

  RECEIVE SYSMODS
          FROMDS('USER.PTF.INPUT')
          BYPASS(HOLDSYSTEM).
/*

---

💡 O que está acontecendo

• Carrega SYSMOD no SMPPTS
• Ignora HOLD SYSTEM (perigoso 👀)

---

⚠️ PASSO 2 — APPLY (com erro proposital)

//APPLY   JOB (ACCT),'SMP/E APPLY',CLASS=A,MSGCLASS=X
//SMPCSI  DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
  SET      BOUNDARY(TZONE1).

  APPLY    PTFS(UX12345)
           GROUPEXTEND
           BYPASS(HOLDCLASS).
/*

---

💥 Resultado esperado

Erro tipo:

GIM35901E - REQUIRED SYSMOD NOT FOUND

👉 Tradução:

Dependência faltando

---

🧠 PASSO 3 — REPORT (diagnóstico inteligente)

//REPORT  JOB (ACCT),'SMP/E REPORT',CLASS=A,MSGCLASS=X
//SMPCSI  DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPUNCH DD SYSOUT=*
//SMPCNTL DD *
  SET      BOUNDARY(TZONE1).

  REPORT   CROSSZONE.
  
  REPORT   ERRSYSMODS.

  REPORT   SYSMODS.
/*

---

🔍 O que você vai ver

• Dependências faltantes
• PTFs necessárias
• Conflitos

💡 E mais importante:
👉 SMPPUNCH com comandos prontos

---

🔗 PASSO 4 — LINK MODULE (cirurgia)

//LINKMOD JOB (ACCT),'SMP/E LINK',CLASS=A,MSGCLASS=X
//SMPCSI  DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
  SET      BOUNDARY(TZONE1).

  LINK     MODULE(CSAMPLE)
           FROMZONE(TZONE2).
/*

---

🧠 O que acontece

• Busca módulo em outra zona
• Rebuild do LMOD
• Cria TIEDTO

💡 Resultado:

Executável corrigido sem reinstalar tudo

---

🏗️ PASSO 5 — BUILDMCS (empacotar o ambiente)

//BUILDMCS JOB (ACCT),'SMP/E BUILD',CLASS=A,MSGCLASS=X
//SMPCSI   DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPUNCH DD SYSOUT=*
//SMPCNTL  DD *
  SET      BOUNDARY(TZONE1).

  BUILDMCS FORFMID(CICS123).
/*

---

📦 Resultado

No SMPPUNCH:

• ++FUNCTION
• ++MOD
• ++JCLIN

👉 Você criou um:

produto instalável do seu ambiente

---

🔁 PASSO 6 — APPLY CORRIGIDO

//APPLY2  JOB (ACCT),'SMP/E APPLY OK',CLASS=A,MSGCLASS=X
//SMPCSI  DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
  SET      BOUNDARY(TZONE1).

  APPLY    PTFS(UX12345)
           GROUPEXTEND
           CHECK.
/*

---

💡 Agora

• Sem erro
• Dependências resolvidas
• Ambiente consistente

---

🎯 LIÇÕES DO LAB (ESSENCIAL)

🧠 1. APPLY sem REPORT = risco

🧠 2. LINK MODULE = solução cirúrgica

🧠 3. BUILDMCS = portabilidade

🧠 4. REPORT = prevenção

---

💥 EASTER EGGS (NÍVEL BELLACOSA)

😈 Se você ignorar HOLDDATA
👉 vai quebrar produção

😈 Se usar LINK demais
👉 cria acoplamento invisível

😈 Se não usar BUILDMCS
👉 não consegue reconstruir ambiente

---

🚀 DESAFIO (NÍVEL HARDCORE)

Tente:

1. Rodar APPLY sem GROUPEXTEND
2. Ver erro
3. Resolver com REPORT + FIXCAT

---

🧠 FRASE FINAL DO LAB

“Quem roda SMP/E executa comando…
quem domina SMP/E controla o sistema.”

 

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

 

Bellacosa Mainframe analisando o smp/e for zos workshop

SMP/E for z/OS Workshop – RECEIVE e REJECT

Quando o SMP/E recebe, avalia… e decide se aceita ou devolve 📦⚖️

No mundo SMP/E, RECEIVE é a porta de entrada e REJECT é a porta de saída. Antes de qualquer APPLY ou ACCEPT, o SMP/E precisa estagiar, validar e registrar tudo que chega. É aqui que muita gente acha que RECEIVE é só “copiar fita”, mas na prática ele é um processo de seleção, validação e controle rigoroso.

Neste post, vamos destrinchar RECEIVE e REJECT, com visão de produção, exemplos reais e aquele toque Bellacosa Mainframe que separa quem decora de quem entende.

---

🧭 Onde RECEIVE e REJECT se encaixam no SMP/E

Os cinco comandos básicos do SMP/E:

1. RECEIVE – Estagia SYSMODs e HOLDDATA

2. APPLY – Instala nos target libraries

3. ACCEPT – Consolida nos distribution libraries

4. RESTORE – Volta DLIB → target

5. REJECT – Desfaz RECEIVE

👉 RECEIVE e REJECT atuam exclusivamente no Global Zone (GZONE).

---

📥 RECEIVE – muito além de copiar SYSMOD

O que o RECEIVE faz de verdade?

• Seleciona SYSMODs e HOLDDATA

• Valida aplicabilidade ao ambiente

• Estagia dados nos datasets SMP/E

• Atualiza o Global Zone

• Produz relatórios e logs

📌 Nada é instalado ainda. Apenas preparado.

---

📦 Entradas do RECEIVE

• SYSMODs (Function, PTF, APAR, USERMOD)

• HOLDDATA (++HOLD / ++RELEASE)

Fontes possíveis:

• 📼 Tape (CBPDO / ESO)

• 💾 DASD

• 🌐 Network (FTP / SMPNTS / Shopz)

---

⚙️ SET BDY(GLOBAL): regra número zero

Todo RECEIVE começa com:

SET BDY(GLOBAL)

Sem isso, o SMP/E nem conversa com você.

---

🎯 Seleção de SYSMODs – quem entra na fila?

A seleção é controlada por operandos do RECEIVE:

Exemplos comuns

• Sem operandos → tudo é candidato

• FMID / FMIDSET → restringe por função

• SELECT / EXCLUDE → filtra SYSMODs

• SOURCEID → agrupa SYSMODs

💡 Bellacosa Tip: SOURCEID é ouro para automação de APPLY/ACCEPT.

---

✅ Regras de aplicabilidade

Para um SYSMOD ser realmente recebido:

Function SYSMOD

• ++VER SREL deve existir no GZONE

PTF / APAR / USERMOD

• ++VER SREL e FMID devem existir no GZONE

🛑 Exceção: BYPASS(FMID) ignora o FMID check.

Outras regras:

• SYSMOD não pode já ter sido recebido

• HOLDDATA só processa se solicitado

---

🗂️ O que é estagiado pelo RECEIVE

SMPPTS

• Armazena MCS + textos de modificação

• Um membro por SYSMOD (nome = SYSMODID)

Global Zone

• Entrada de SYSMOD

• Entrada de HOLDDATA

• Atualização da lista de FMIDs

📌 Nenhum elemento é instalado ainda.

---

📁 RELFILE SYSMODs e SMPTLIB

Quando o SYSMOD vem em RELFILE:

• Cada RELFILE → um SMPTLIB

• RFDSNPFX define HLQ dos datasets

• TLIBs podem ser:

  • Pré-alocados

  • Dinamicamente alocados

💡 Dica Bellacosa: defina spill para SMPPTS e TLIBs, ou prepare-se para o caos.

---

🌐 RECEIVE via Network

FROMNETWORK

• Usa pacote GIMZIP

• Conecta via TCP/IP (FTP)

• Requer SERVER operand

FROMNTS

• Usa diretório SMPNTS

• Identificado por PKGID ou Order Entry

📦 Base da instalação moderna via Shopz.

---

🧾 Relatórios gerados pelo RECEIVE

• Receive Summary Report

• Exception SYSMOD Data Report (++HOLD / ++RELEASE)

• Dynamic Allocation Report

📌 Leitura obrigatória antes do APPLY.

---

🛑 HOLDDATA – quando o SMP/E levanta a mão

HOLDDATA sinaliza SYSMODs que:

• Exigem ação manual

• Dependem de outro fix

• Podem causar impacto operacional

Tipos de HOLD

• SYSTEM

• ERROR

• USER

• FIXCAT

🛑 SYSMOD com HOLD não aplica nem aceita.

---

🏷️ FIXCAT – inteligência aplicada

FIXCAT agrupa APARs por:

• Hardware

• Software

• Função

Durante RECEIVE:

• FIXCAT HOLDS criam SOURCEIDs automaticamente

• PTFs resolutores herdam o SOURCEID

Resultado:

APPLY SOURCEID(FIXCAT_xxx)

🎯 Simples, limpo e auditável.

---

📌 FIXCAT persistente (Options Entry)

• Lista salva no OPTIONS entry

• Usada por APPLY / ACCEPT / REPORT MISSINGFIX

• Configurada via:

  • UCLIN

  • Admin Dialog

  • Fix Category Explorer

💡 Bellacosa Truth: FIXCAT bem mantido evita outage silencioso.

---

🚪 REJECT – desfazendo o RECEIVE

REJECT reverte RECEIVE, não APPLY.

O que ele remove:

• SYSMOD entry no GZONE

• HOLDDATA entry

• MCS no SMPPTS

• SMPTLIBs associados

---

🎛️ Modos de REJECT

• MASS – tudo recebido e não instalado

• SELECT – SYSMOD específico

• PURGE – aceitos em uma DZONE

• NOTAPPLICABLE – não aplicáveis ao sistema

🔍 CHECK faz simulação (sempre use!).

---

🧠 Conclusão Bellacosa

RECEIVE é controle. APPLY é ação. ACCEPT é compromisso.

Quem domina RECEIVE:

• Evita lixo no SMPPTS

• Controla HOLDDATA

• Organiza SOURCEIDs

• Dorme melhor antes do APPLY

No próximo capítulo do workshop, entramos de vez no APPLY processing, onde o código finalmente toca o sistema.

🚀 Até lá, respeite o RECEIVE. Ele sabe mais do que parece.

 

Bellacosa Mainframe e o que é smp/e

O que é SMP/E?

Se existe uma ferramenta indispensável para manter um ambiente IBM Mainframe atualizado, essa ferramenta é o SMP/E.

Sempre que uma empresa instala:

• uma nova versão do z/OS;

• uma correção (PTF);

• um novo produto IBM;

• um patch de segurança;

• uma atualização do CICS, Db2 ou IMS;

existe uma grande chance de o SMP/E estar envolvido.

Sem ele, administrar milhares de módulos e bibliotecas seria praticamente impossível.

---

Definição simples

O SMP/E (System Modification Program/Extended) é o sistema oficial do z/OS responsável por instalar, atualizar, corrigir e manter softwares no IBM Mainframe.

Ele controla todo o ciclo de vida dos produtos instalados, garantindo que as atualizações sejam aplicadas corretamente e que o ambiente permaneça consistente.

Em outras palavras:

O SMP/E é o "gerenciador de instalação e atualização de software" do IBM Mainframe.

---

Uma analogia simples

Imagine uma oficina responsável pela manutenção de uma frota de aviões.

Cada aeronave possui:

• motores;

• sistemas elétricos;

• instrumentos;

• softwares.

Quando uma peça precisa ser substituída, não basta instalar qualquer componente.

É necessário verificar:

• compatibilidade;

• versão;

• histórico;

• documentação.

O SMP/E faz exatamente isso para os softwares do z/OS.

---

O que significa SMP/E?

SMP/E significa:

System Modification Program/Extended

Em português:

Programa Estendido de Modificação do Sistema.

Apesar do nome, sua função vai muito além de "modificar".

Ele controla praticamente toda a manutenção de softwares do ambiente z/OS.

---

Para que serve?

O SMP/E é utilizado para:

• instalar produtos IBM;

• aplicar PTFs;

• instalar APARs corrigidas;

• aplicar HOLDDATA;

• instalar novas versões;

• controlar dependências;

• manter histórico das instalações;

• remover atualizações quando necessário.

---

Por que o SMP/E é importante?

Imagine instalar uma atualização do Db2.

Essa atualização modifica:

• centenas de módulos;

• bibliotecas;

• macros;

• programas;

• documentação.

Fazer tudo manualmente seria extremamente arriscado.

O SMP/E automatiza esse processo.

---

Como funciona?

O fluxo básico é:

IBM

↓

Correção (PTF)

↓

Recebimento (RECEIVE)

↓

Análise (APPLY CHECK)

↓

Aplicação (APPLY)

↓

Aceitação (ACCEPT)

Cada etapa possui uma finalidade específica.

---

Principais componentes

SYSMOD

É o nome genérico dado às modificações controladas pelo SMP/E.

Uma SYSMOD pode ser:

• PTF;

• APAR;

• USERMOD;

• FUNCTION.

---

PTF

Program Temporary Fix.

É uma correção oficial liberada pela IBM.

Exemplo:

UI12345

---

APAR

Authorized Program Analysis Report.

Representa um problema identificado em um produto IBM.

Após sua correção normalmente surge uma PTF.

---

HOLDDATA

Contém informações importantes sobre atualizações.

Pode informar:

• dependências;

• pré-requisitos;

• cuidados especiais;

• necessidade de IPL.

---

USERMOD

Modificação criada pelo próprio cliente.

Muito utilizada para customizações.

---

FUNCTION

Representa uma nova funcionalidade ou instalação inicial de um produto.

---

O banco de dados do SMP/E

O SMP/E mantém informações em um conjunto de datasets chamado:

CSI

Consolidated Software Inventory

Ele registra:

• produtos instalados;

• versões;

• PTFs;

• APARs;

• dependências;

• histórico.

É o "cadastro" de todo o software do sistema.

---

As principais zonas do SMP/E

O ambiente é dividido em zonas.

Global Zone

Controla todo o ambiente SMP/E.

---

Target Zone

Representa os produtos que estão em uso.

É a biblioteca utilizada pelo sistema operacional.

---

Distribution Zone

Contém a cópia mestre dos produtos instalados.

Serve como referência para futuras manutenções.

---

O processo RECEIVE

O RECEIVE recebe as atualizações.

Exemplo:

IBM

↓

PTF

↓

RECEIVE

Nenhuma alteração ocorre no sistema ainda.

Apenas o recebimento.

---

APPLY CHECK

Antes da instalação real, executa-se:

APPLY CHECK

O SMP/E verifica:

• dependências;

• conflitos;

• pré-requisitos.

Nenhuma alteração é realizada.

É um "ensaio".

---

APPLY

Agora sim.

A atualização é instalada.

PTF

↓

APPLY

↓

Bibliotecas TARGET

---

ACCEPT

Após validar a atualização, executa-se:

ACCEPT

A alteração passa também para as bibliotecas DISTRIBUTION.

---

Fluxo completo

IBM

↓

RECEIVE

↓

APPLY CHECK

↓

APPLY

↓

Testes

↓

ACCEPT

Esse é o fluxo clássico do SMP/E.

---

Quem utiliza?

Principalmente:

• Sysprogs;

• Administradores z/OS;

• Especialistas SMP/E;

• Administradores CICS;

• Administradores Db2;

• Administradores IMS.

Programadores COBOL normalmente não utilizam o SMP/E diretamente.

---

Benefícios

Segurança

Instala apenas atualizações válidas.

---

Histórico completo

Tudo fica registrado.

---

Controle de dependências

Evita instalações incorretas.

---

Padronização

Todos os ambientes seguem o mesmo processo.

---

Recuperação

Facilita retornar a versões anteriores quando necessário.

---

Curiosidades incríveis

1. O SMP/E existe há décadas

Ele evoluiu junto com o z/OS e continua sendo a principal ferramenta de manutenção de software do IBM Mainframe.

---

2. Grandes ambientes possuem milhares de PTFs instaladas

O CSI controla todas elas automaticamente.

---

3. O APPLY CHECK evita muitos problemas

Ele identifica conflitos antes que qualquer alteração seja aplicada ao sistema.

---

4. Quase todos os produtos IBM para z/OS utilizam SMP/E

Entre eles:

• z/OS;

• CICS;

• Db2;

• IMS;

• MQ;

• RACF;

• TCP/IP;

• inúmeros outros produtos IBM e de terceiros compatíveis com o processo.

---

Erros comuns de iniciantes

"PTF é igual APAR"

Não.

A APAR descreve um problema.

A PTF é a correção distribuída para resolver esse problema.

---

"RECEIVE instala a atualização"

Não.

O RECEIVE apenas recebe a atualização.

A instalação ocorre durante o APPLY.

---

"Depois do APPLY posso apagar tudo"

Não.

O ACCEPT atualiza as bibliotecas de distribuição e consolida a manutenção.

Ele faz parte do processo recomendado.

---

Quando aprender SMP/E?

Depois de compreender:

• z/OS;

• datasets;

• JCL;

• Storage;

• bibliotecas do sistema.

Esse conhecimento é essencial para quem pretende atuar como Sysprog ou administrador de ambientes IBM Z.

---

Conclusão

O SMP/E é a ferramenta oficial do IBM Mainframe para instalação e manutenção de software no z/OS. Ele controla todo o ciclo de vida de atualizações, desde o recebimento de correções até sua aplicação e consolidação, garantindo segurança, rastreabilidade e consistência.

Ao automatizar o gerenciamento de PTFs, APARs, USERMODs e novas versões de produtos, o SMP/E tornou-se um dos pilares da administração do IBM Z. Compreender seu funcionamento é indispensável para qualquer profissional que deseje trabalhar com infraestrutura, administração de sistemas ou manutenção de ambientes mainframe.