| Bellacosa Mainframe apresenta SMP/E CSI |
SMP/E Workshop – CSI (Consolidated Software Inventory) sem Medo
"Se o z/OS é uma cidade, o CSI é o cartório, o mapa urbano, o histórico de obras e o código de posturas… tudo junto."
Estilo Bellacosa Mainframe ☕🖥️
📌 O que é o CSI (Consolidated Software Inventory)?
O CSI é o coração do SMP/E. Sem ele, o SMP/E não sabe:
onde instalar código
qual versão está ativa
quem substituiu quem
o que pode ou não ser aplicado
👉 Nada de código executável vive no CSI.
O CSI é metadados, não binários.
Ele descreve como o sistema foi construído e qual o nível de serviço de cada elemento.
🧠 Por que o CSI é essencial?
Imagine um z/OS com:
centenas de bibliotecas
milhares de módulos
décadas de PTFs, APARs e USERMODs
Sem um banco de controle confiável:
🚨 módulo no lugar errado = abend
🚨 load module mal linkado = IPL problem
🚨 manutenção fora de ordem = rollback impossível
👉 O CSI garante ordem no caos.
🧩 Estrutura do CSI – Zonas
O CSI é dividido em zonas, cada uma com uma função clara:
🌍 Global Zone
Índice mestre do SMP/E
Controla o que foi recebido
Aponta para todas as outras zonas
Funções-chave:
lista de FMIDs
controle de opções
vínculo entre Target ↔ Distribution
📌 O nome sempre é GLOBAL (não negocia!)
🎯 Target Zone (TZONE)
Descreve:
bibliotecas executáveis
módulos em uso
status de APPLY
Aqui o SMP/E sabe:
o que está rodando no sistema
nível de serviço ativo
📦 Distribution Zone (DZONE)
Descreve:
bibliotecas de distribuição (DLIB)
código mestre
status de ACCEPT
É a fonte da verdade para RESTORE.
🗂️ CSI como VSAM KSDS
Cada zona pode residir em:
um KSDS próprio (recomendado)
ou um único CSI compartilhado (não recomendado)
Boas práticas Bellacosa:
✔ Um KSDS por zona
✔ Zona no mesmo volume das bibliotecas
✔ LLQ sempre CSI
✔ HLQ em user catalog, não no master
🌱 Priming do CSI – GIMZPOOL
Antes de usar uma zona, ela precisa ser semeada:
Macro:
GIMZPOOLCopiado via
IDCAMS REPROFonte:
SYS1.MACLIB
Sem isso?
🚫 SMP/E nem conversa com a zona.
🧱 Entradas do CSI – a alma do inventário
O CSI é composto por entries, agrupadas em 4 categorias:
1️⃣ Control
Controlam como o SMP/E trabalha:
GLOBAL definition entry
OPTIONS
UTILITY
DDDEF
FMIDSET / ZONESET
👉 Criadas manualmente (UCLIN ou diálogos)
2️⃣ Status
Controlam estado dos SYSMODs:
SYSMOD entry
HOLDDATA
Criadas quando:
RECEIVE
APPLY
ACCEPT
3️⃣ Content
Descrevem o que existe nas bibliotecas:
MOD
MAC
SRC
DATA
HFS
JAR
Aqui vivem:
FMID
RMID
UMID
4️⃣ Structure
Descrevem como tudo se combina:
LMOD
ASSEM
DLIB
📌 LMOD só existe no Target Zone
🔎 FMID, RMID e UMID no CSI
Resumo raiz:
FMID → quem introduziu o elemento
RMID → quem substituiu por último
UMID → quem atualizou (pode ter vários)
📌 Regra de ouro:
1 FMID
1 RMID
N UMIDs
⚙️ DDDEF – o GPS do SMP/E
O SMP/E não depende de DD no JCL.
Ele usa DDDEF entries para:
alocação dinâmica
apontar datasets
evitar ambiguidades entre ambientes
🔥 Dica Bellacosa:
Nome do DDDEF = LLQ do dataset
🛠️ Gerenciamento de Zonas
Os famosos Zone Management Commands:
ZONEEXPORT/ZONEIMPORTZONERENAMEZONEDELETEZONECOPYZONEMERGEGZONEMERGEZONEEDITUNLOADUPGRADE
⚠️ Aviso sincero:
Alguns desses comandos não perdoam erro humano.
Use com:
backup
café
e juízo
📦 UCLIN – poder absoluto (e perigoso)
O UCLIN permite:
ADD
REP
DEL
Em quase qualquer entry do CSI.
📛 Comparação honesta:
UCLIN é o SUPERZAP do SMP/E.
Use só quando souber exatamente o que está fazendo.
🧠 Conclusão Bellacosa
O CSI não é só um inventário:
é auditoria
é rastreabilidade
é rollback
é governança
Quem domina o CSI:
✔ domina o SMP/E
✔ dorme tranquilo após APPLY
✔ não teme auditoria
📘 Próximo capítulo: Zone Management Commands na prática
📦 Casos reais, armadilhas e quando NÃO usar ZONEMERGE
✍️ Bellacosa Mainframe – porque z/OS não se administra no improviso.
Sem comentários:
Enviar um comentário