 |
| Bellacosa Mainframe apresenta smp/e sysmod packaging |
SMP/E na prática – SYSMOD Packaging sem medo
🧠 Introdução – SMP/E não é bicho‑papão
Quem trabalha com z/OS cedo ou tarde se depara com ele: SMP/E. Para alguns, um monstro antigo. Para outros, um mal necessário. A verdade é simples:
SMP/E é só método, disciplina e leitura correta das MCS.
Neste post vamos direto ao ponto: SYSMOD Packaging, ou seja, como os produtos, correções e USERMODs são empacotados, entregues e entendidos pelo SMP/E.
Sem marketing. Sem misticismo. Só mainframe raiz.
📦 O que é um SYSMOD de verdade?
Todo SYSMOD é composto por duas partes inseparáveis:
Conteúdo
módulos
macros
source
dados
HFS / JAR
MCS – Modification Control Statements
instruções que dizem ao SMP/E como, onde e quando instalar
👉 Durante o RECEIVE, o SMP/E lê primeiro as MCS, cria as MCS entries e armazena tudo no SMPPTS.
Se as MCS estiverem erradas… não há santo que salve o APPLY.
🧾 Regras de ouro das MCS (decore isso)
Todas começam com
++Colunas 1–2 obrigatórias
Terminam com ponto final (.)
Continuação de linha só se não houver ponto antes da coluna 73
Colunas 73–80 são ignoradas
📌 Erro clássico: esquecer o ponto final. Resultado? SMP/E surtando.
🪪 HEADER – identidade do SYSMOD
Toda SYSMOD começa com:
++HEADER
É aqui que o SMP/E descobre:
o tipo do SYSMOD
o SYSMOD‑ID
Tipos clássicos
FUNCTION – produto base
PTF – correção testada
APAR – correção de problema
USERMOD – correção local
Sem HEADER correto, não existe SYSMOD.
🧬 FMID – quem é o dono do código
O FMID (Function Modification ID):
tem 7 caracteres
identifica qual função é dona do elemento
aparece normalmente no
++VER
📌 Em FUNCTION SYSMOD, o FMID é o próprio SYSMOD‑ID.
Erro comum em prova e produção: FMID errado = APPLY recusado.
🔗 ++VER – o cérebro do SMP/E
O ++VER é obrigatório e define:
releases suportados
pré‑requisitos
co‑requisitos
supersedes
Principais operandos:
SREL – release do sistema
FMID – função dona
PRE – pré‑requisito
REQ – co‑requisito
SUP – supersede
👉 Sem ++VER, o SMP/E não confia em você.
🚦 ++HOLD – bloqueios controlados
Existem três HOLDs clássicos:
ERROR – correção com problema
SYSTEM – ação manual necessária
USER – regra local
O HOLD pode vir:
dentro do SYSMOD
ou separado em HOLDDATA
📌 HOLD não é erro. HOLD é controle.
🏗️ ++JCLIN – a planta da casa
O ++JCLIN descreve:
como o load module deve ser montado
quais objetos entram
qual link‑edit será usado
⚠️ JCLIN não executa JCL.
Ele apenas documenta a estrutura, permitindo RESTORE e rebuild corretos.
Sem JCLIN, o SMP/E fica cego.
🧩 MCS de elementos – o que realmente instala
Alguns exemplos:
++MOD– módulo++SRC– source++MAC– macro++DATA– dados++HFS– arquivo Unix++JAR– JAR inteiro++JARUPD– update parcial++ZAP– patch binário
📌 ZAP e UPD alteram partes. DATA e HFS sempre substituem tudo.
☕ JAR no SMP/E (onde muita gente erra)
++JAR→ substituição total++JARUPD→ update parcial
O SMP/E usa comandos do JDK para manipular o conteúdo.
Sim, Java também é mainframe.
📦 Técnicas de empacotamento SYSMOD
1️⃣ Relative File (tape)
clássico IBM
MCS em um arquivo
elementos em arquivos seguintes
usa
RELFILE
Muito comum em FUNCTION SYSMOD.
2️⃣ Inline
MCS e conteúdo juntos
registros fixos de 80 bytes
simples e direto
⚠️ Dados variáveis exigem GIMDTS.
3️⃣ Indirect Library
MCS no SMPPTS
conteúdo fora (PDS indicado no APPLY)
comum em USERMOD
Flexível e perigoso se mal documentado.
4️⃣ GIMZIP Archive (Shopz / Internet)
entrega moderna
tudo compactado
inclui MCS, conteúdo e HOLDDATA
Base do RECEIVE FROMNETWORK.
❌ Pegadinhas clássicas (anota aí)
++MOD não é o último MCS
Inline com RELFILE
FMID inexistente
SREL inválido
falta de ponto final
👉 Todas já derrubaram produção algum dia.
🧠 Conclusão – SMP/E é método
RECEIVE entende
APPLY constrói
ACCEPT congela
Quando você entende SYSMOD Packaging, o SMP/E deixa de ser mistério e vira aliado.
Mainframe não é velho.
Velho é não saber o que está rodando.
💾 Até o próximo post. Porque mainframe bom é mainframe bem documentado.
