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

SMP/E for z/OS Workshop : BUILDMCS, LINK MODULE e LINK LMODS

 

Bellacosa Mainframe apresenta SMP/E buildmcs link lmods e module

SMP/E for z/OS Workshop

BUILDMCS, LINK MODULE e LINK LMODS

Quando o SMP/E deixa de ser manutenção e vira engenharia de produto

Até agora, no mundo SMP/E, falamos muito de rotina operacional:
RECEIVE, APPLY, ACCEPT, RESTORE.
O famoso arroz com feijão do dia a dia.

Mas existe um outro SMP/E.
Menos usado.
Mais poderoso.
Mais perigoso se mal compreendido.

Hoje entramos no território de product build, onde aparecem três comandos que não são para iniciantes:

• BUILDMCS

• LINK MODULE

• LINK LMODS

Aqui o SMP/E deixa de ser só manutenção e passa a ser engenharia reversa, migração e reconstrução de produtos.

---

SMP/E e a visão estrutural do z/OS

O SMP/E enxerga o z/OS como uma hierarquia:

• 🔹 Elementos simples (SRC, MAC, MOD, PARM)

• 🔹 Objetos intermediários (OBJ, módulos)

• 🔹 Estruturas complexas (LMODs)

• 🔹 Bibliotecas do sistema (target libraries)

Tanto o APPLY quanto os processos de geração de produto fazem a mesma coisa no fundo:

Pegam módulos, macros, source e dados
e combinam tudo para gerar load modules e bibliotecas executáveis

O segredo está em como o SMP/E entende essa estrutura:
👉 entries e subentries no CSI

---

Revisão rápida das principais subentries (a base de tudo)

🔹 DISTLIB=

Aponta para a distribution library
(cópia oficial, aceita, segura)

🔹 FMID=

Define o nível funcional

Quem é o dono original do elemento

🔹 RMID / UMID=

Definem o nível de serviço

Última substituição e atualizações

🔹 SYSLIB=

Usado por SRC, MAC, DATA, HFS
Define o DDNAME da target library

🔹 LMOD=

Usado em MODULE entries
Direciona o SMP/E para a estrutura do load module

Sem entender isso, BUILDMCS vira magia negra.

---

Distribution Zone: conteúdo sem estrutura

Um ponto crítico que muita gente erra:

Na DZONE não existe estrutura de LMOD

Na distribution zone:

• Existem MOD entries

• Não existem LMOD= subentries

• O foco é conteúdo, não link-edit

A estrutura só nasce no target, durante APPLY, GENERATE ou LINK.

---

BUILDMCS – o “clonar produto” do SMP/E

O que é o BUILDMCS?

O BUILDMCS analisa um target zone ou distribution zone
e gera um SYSMOD funcional completo, contendo:

• ++FUNCTION

• ++MOD, ++MAC, ++SRC, ++PARM, ++HFS

• ++JCLIN completo

• FROMDS apontando para as DLIBs

📦 Resultado:

Um SYSMOD portátil, capaz de reinstalar um produto inteiro em outro ambiente SMP/E

---

Para que isso existe no mundo real?

Cenários clássicos:

• Migração de produto entre ambientes

• Criação de novo CSI

• Consolidação de sistemas

• Produto sem mais mídia oficial

• Ambientes isolados (sem internet, sem Shopz)

BUILDMCS cria uma imagem funcional completa do produto, incluindo:

• Função

• Serviço

• Usermods já aplicados

---

O que o BUILDMCS NÃO faz

🚫 Não altera o ambiente original
🚫 Não aplica nem aceita nada
🚫 Não “adivinha” dependências externas

Ele fotografa o estado atual do produto.

---

Como o BUILDMCS funciona por dentro

1️⃣ Analisa o zone (T ou D)
2️⃣ Reconstrói MCS a partir do CSI
3️⃣ Usa FROMDS para apontar para DLIBs
4️⃣ Gera SYSMOD superseding
5️⃣ Grava tudo no SMPPUNCH

Depois disso:

RECEIVE
APPLY
ACCEPT

em outro ambiente.

---

Relatórios gerados pelo BUILDMCS

BUILDMCS não é silencioso. Ele gera:

📄 Function Summary Report

• FMIDs processados

• SYSMODs substituídos

📄 Entry Summary Report

• Todos os elementos do FMID

• MODs, LMODs, DDDEFs

📄 Subentry Summary Report

• Detalhe fino de cada entry

Se você não leu esses relatórios, você não sabe o que copiou.

---

⚠️ Restrições do BUILDMCS (a parte que cai em produção)

BUILDMCS não é para todo produto.

Problemas aparecem quando existem:

❌ Load modules compartilhados

Um LMOD com módulos de mais de um produto

❌ Elementos comuns

Mesmo nome e tipo fornecido por produtos diferentes

❌ VERSION, ASSEM, PREFIX

Essas operações não são recriadas

❌ Informações ausentes no Target Zone

• LEPARM

• ALIAS

• DALIAS

Resultado?
👉 SYSMOD gerado incompleto ou incorreto

---

LINK MODULE – resolvendo dependência entre target zones

Agora imagine isso:

• Produto A em TZONE1

• Produto B em TZONE2

• Um LMOD precisa de módulos dos dois

Sem reinstalar nada.

👉 LINK MODULE resolve isso

---

O que o LINK MODULE faz?

• Reexecuta o link-edit

• Inclui módulos faltantes

• Atualiza ambos os target zones

• Cria relacionamento cruzado (TIEDTO)

Tudo isso sem APPLY, sem ACCEPT.

---

Como o SMP/E documenta isso?

Após o LINK MODULE:

• XZMODP no LMOD que foi relinkado

• XZLMODP nos módulos envolvidos

• TIEDTO nos dois target zones

Isso garante que o SMP/E:

• Saiba da dependência

• Avise (ou relinke automaticamente) no futuro

---

XZLINK – avisar ou agir?

No TIEDTO ZONE:

• XZLINK(DEFERRED)
  👉 Apenas avisa possível inconsistência

• XZLINK(AUTOMATIC)
  👉 SMP/E relinka automaticamente

Escolha errada aqui = surpresa em manutenção futura.

---

LINK LMODS – o REPORT CALLIBS que deu certo

O LINK LMODS substitui o antigo REPORT CALLIBS.

Ele:

• Identifica LMODs por nome ou CALLIBS

• Localiza todos os módulos

• Executa link-edit direto nas target libraries

• Tem CHECK mode

• Tenta recuperação automática (compress + retry)

É APPLY sem SYSMOD.

---

Resumo Bellacosa Mainframe

Comando	Papel
BUILDMCS	Clona um produto
LINK MODULE	Resolve dependência entre zones
LINK LMODS	Relinka LMODs diretamente

---

Frase final (estilo Bellacosa)

RECEIVE instala mídia.
APPLY constrói código.
ACCEPT oficializa.
RESTORE ensina humildade.
BUILDMCS revela quem realmente entende SMP/E.

No próximo módulo, entramos em LIST e REPORT — onde o SMP/E finalmente começa a contar a verdade sobre o seu sistema.