SMP/E – Tracking Element Levels

 

Bellacosa Mainframe apresenta SMP/E Tracking Element Levels

SMP/E for z/OS Workshop – Tracking Element Levels

FMID, RMID e UMID sem mistério – no melhor estilo Bellacosa Mainframe

---

🎯 Por que o SMP/E controla níveis de elementos?

No mundo z/OS, nada é instalado “por cima e pronto”. Cada módulo, macro ou arquivo precisa ter rastro, histórico e responsável.

É exatamente isso que o SMP/E faz ao controlar o nível de serviço dos elementos nos ambientes:

• Target Libraries (TZONE) – o que está em execução

• Distribution Libraries (DZONE) – o que é a referência oficial

E o controle acontece por meio de três identificadores clássicos:

FMID – RMID – UMID

Se você domina esses três, domina auditoria, RESTORE, APPLY e ACCEPT.

---

🧠 A base de tudo: SYSMOD-ID

Todos os identificadores usados pelo SMP/E são extraídos do:

++HEADER

Eles são conhecidos genericamente como SYSMOD-ID, mas cada um tem um papel específico quando associado a um elemento.

---

🧩 O cenário do workshop (exemplo realista)

Vamos acompanhar a vida real de um elemento chamado MOD1.

📦 Function SYSMOD: HGF1200

• Introduz três elementos: MOD1, MOD2, MOD3

• Esses elementos formam o load module LMOD1

📌 Funções normalmente:

• não usam JCLIN inline

• usam relative file, que é um unload de um PDS com JCLIN

---

🏗️ APPLY da função – nascimento do elemento

Quando a função HGF1200 é aplicada:

• MOD1 passa a existir na Target Library

• SMP/E grava no TZONE:

Identificador	Valor
FMID	HGF1200
RMID	HGF1200
UMID	—

📌 Interpretação Bellacosa

MOD1 está no nível funcional.

A função HGF1200 é a dona do código.

Quando FMID = RMID, estamos falando de base code.

---

📦 ACCEPT da função – espelho na DLIB

Ao executar ACCEPT:

• MOD1 é copiado para a Distribution Library

• Os mesmos valores são registrados no DZONE

📌 O DZONE sempre representa:

“Como o produto deveria estar”

---

🩹 PTF UY00020 – primeira substituição

O PTF UY00020:

• contém um replacement de MOD1

• precisa identificar o dono funcional do elemento:

++VER FMID(HGF1200)

Como é o primeiro serviço sobre a base, não precisa de PRE.

🧾 Após APPLY do PTF UY00020 (TZONE)

Identificador	Valor
FMID	HGF1200
RMID	UY00020
UMID	—

📌 Regra de ouro:

Um elemento tem apenas um RMID.

---

🩹 PTF UY00040 – nova substituição

Agora entra o UY00040:

• substitui MOD1 novamente

• declara o UY00020 como pré-requisito

• identifica o dono funcional: HGF1200

Após APPLY:

Identificador	Valor
FMID	HGF1200
RMID	UY00040
UMID	—

📌 MOD1 agora está em um nível superior de serviço.

---

🐞 APAR AY91862 – update, não replacement

O APAR normalmente:

• não substitui o elemento inteiro

• faz um update para corrigir erro

O packager deve informar:

• FMID – quem é o dono

• PRE – qual SYSMOD está sendo atualizado

Após APPLY:

Identificador	Valor
FMID	HGF1200
RMID	UY00040
UMID	AY91862

📌 Conceito-chave

UMID representa quem atualizou o elemento.

---

🧩 USERMOD ME00012 – customização local

Agora entra o famoso USERMOD:

• altera MOD1 localmente

• precisa identificar:

  • FMID (HGF1200)

  • RMID (UY00040)

  • todos os UMIDs existentes

Após APPLY:

Identificador	Valor
FMID	HGF1200
RMID	UY00040
UMID	AY91862, ME00012

📌 Elemento pode ter vários UMIDs, mas apenas um RMID.

---

🔍 O que o SMP/E realmente está rastreando?

Para cada elemento, o SMP/E sabe responder:

• Quem introduziu? → FMID

• Quem substituiu por último? → RMID

• Quem atualizou? → UMID(s)

Isso vale tanto para:

• TZONE (APPLY)

• DZONE (ACCEPT)

---

🛡️ Visão de auditoria (dica de ouro)

Se você vê:

• USERMOD em produção

• sem ACCEPT

• com múltiplos UMIDs

👉 alerta de risco operacional

O SMP/E está dizendo a verdade. Basta saber ler.

---

🧠 Conclusão Bellacosa Mainframe

FMID diz quem manda
RMID diz quem substituiu
UMID diz quem mexeu

SMP/E não perde nada.
Quem se perde é quem não entende o CSI.

No próximo passo, o caminho natural é:

➡️ Consolidated Software Inventory

Porque rastrear é bom.
Consolidar é profissional.

---

💾 Mainframe bom é mainframe auditável.