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