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