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 apresenta o software com poder de vida e morte no Mainframe SMP/E

🔥 SMP/E Não Instala Software — Ele Decide se o Seu Sistema Vive ou Morre

Se você é um dev COBOL sênior, deixa eu te provocar logo de cara:

Você confia no seu programa…
mas você confia no ambiente onde ele roda?

Porque no mundo do z/OS, não é o COBOL que quebra primeiro.

👉 É o ecossistema invisível que o SMP/E controla.

---

☕ A História que Ninguém Te Conta

Antes do SMP/E, instalar software no mainframe era quase artesanal:

• Fita magnética 📼
• JCL manual
• Catálogo na mão
• E muita… muita reza

Quando a IBM criou o SMP/E, a ideia não era só instalar software.

Era algo muito maior:

Criar um sistema de governança de software

---

🧠 O Que é SMP/E (de verdade)

Esquece a definição de manual.

👉 SMP/E é:

• Inventário vivo do sistema
• Motor de instalação
• Mecanismo de auditoria
• Sistema de dependência

💡 Tradução Bellacosa:

É o Git + Maven + Kubernetes do mainframe… só que criado décadas antes.

---

🧱 Como o Sistema é Construído (e você provavelmente nunca viu assim)

O SMP/E enxerga o mundo em camadas:

SOURCE → MACRO → MODULE → LOAD MODULE → LIBRARY

👉 E aí vem o pulo do gato:

• Seu programa COBOL → vira MODULE
• Vários MODULEs → viram LMOD
• LMOD → roda no sistema

💥 Se UMA peça estiver errada…

Seu programa perfeito vira erro em produção

---

🔥 APPLY — O Comando Mais Perigoso do Seu Ambiente

Todo mundo já rodou:

APPLY PTFS(...)

E pensou:

“RC=0… sucesso!”

😈 Aqui está o problema:

• Dependência pode estar faltando
• HOLD pode estar ignorado
• Outra zona pode quebrar

👉 E o erro?

Vai aparecer depois… no seu COBOL

---

🧠 Easter Egg (nível produção)

O APPLY não instala software…
ele muda o estado do sistema inteiro

---

🔍 LIST vs REPORT — O Momento em que você vira adulto no SMP/E

LIST

• Mostra dados
• Não pensa

👉 Tipo um dump bonito

---

REPORT

• Analisa
• Detecta problema
• Sugere ação

💡 Tradução:

LIST responde
REPORT decide

---

💥 Exemplo real

Você roda:

REPORT CROSSZONE

E descobre:

• Dependência faltando
• Outro produto impactado

👉 Antes do APPLY

💥 Resultado:

Você evitou um incidente

---

🔗 LINK MODULE — A Cirurgia que Salva Madrugada

Cenário clássico:

• Programa chama módulo
• Módulo não está no LMOD

💣 Resultado:

• Abend
• Erro estranho
• Chamado urgente

---

💡 Solução:

LINK MODULE(...)

👉 O SMP/E:

• Busca módulos em outra zona
• Reconstrói o executável

💥 Sem reinstalar nada

---

😈 Easter Egg

Isso resolve rápido…
mas cria dependência (TIEDTO)

👉 Você resolveu hoje… e criou um problema silencioso amanhã

---

🏗️ BUILDMCS — O Superpoder Escondido

Pouca gente usa. Pouca gente entende.

👉 Mas isso aqui é ouro:

BUILDMCS FORFMID(...)

---

O que ele faz?

• Pega um ambiente instalado
• Gera um SYSMOD completo
• Permite reinstalar tudo

---

💡 Analogia moderna

BUILDMCS é o “docker commit” do mainframe

---

📖 Caso real

• Sistema com USERMOD crítico
• Sem documentação
• Sem backup lógico

👉 Solução?

BUILDMCS

💥 Ambiente salvo

---

⚠️ O Lado Sombrio

Se você tiver:

• Shared LMOD
• Elementos comuns

👉 BUILDMCS pode gerar inconsistência

---

🌐 SMP/E Moderno — Ele Já Virou DevOps

Hoje você não precisa mais:

• Fita
• PSP manual
• Caçar PTF

---

🚀 RECEIVE ORDER

RECEIVE ORDER

👉 SMP/E:

• Pede manutenção
• Baixa
• Organiza

---

🧠 FIXCAT

O SMP/E escolhe o que você precisa instalar

---

🔄 Pipeline moderno

ORDER → RECEIVE → APPLY → ACCEPT

💡 Isso é CI/CD… no mainframe

---

🔥 Exemplo Real (nível enterprise)

Upgrade de ambiente:

1. RECEIVE HOLDDATA
2. REPORT MISSINGFIX
3. APPLY FIXCAT
4. VALIDAR

👉 Sem PSP manual
👉 Sem chute

---

😈 Easter Egg final

Quem ainda usa fita…
está em 1998

---

🧠 O Que Isso Muda para um Dev COBOL

Você deixa de ser:

❌ “quem escreve programa”

E vira:

✅ quem entende o ambiente
✅ quem evita erro antes de acontecer
✅ quem conversa com sysprog de igual para igual

---

💥 Passo a Passo Mental (guarda isso)

Antes de qualquer APPLY:

1. 🔍 REPORT
2. 📊 Analisar dependência
3. ⚙️ APPLY CHECK
4. 🚀 APPLY real
5. 📦 ACCEPT

---

🚀 Frase Final (nível Bellacosa)

“Seu COBOL pode estar perfeito…
mas quem decide se ele roda é o SMP/E.”

 

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.