 |
| Bellacosa Mainframe apresenta SMP/E Apply Processing |
SMP/E for z/OS – Apply Processing
O momento em que o código vira sistema
Se o RECEIVE é quando o código chega na casa e o ACCEPT é quando ele vira herança oficial, o APPLY é o momento crítico: quando o código realmente entra em produção técnica, nos target libraries.
É aqui que o SMP/E deixa de ser teoria, CSI e HOLDDATA… e começa a mexer em load modules, macros, fontes, JARs, HFS e dados reais do sistema.
No estilo Bellacosa Mainframe: APPLY não é comando — é cirurgia.
O que o APPLY faz (sem romantizar)
O comando APPLY:
Instala elementos fornecidos por SYSMODs nas Target Libraries
Atualiza o Target Zone (TZONE) com o novo estado do sistema
Garante que nenhum serviço seja regredido
Controla dependências, pré-requisitos, co-requisitos e IF-REQs
Invoca utilitários reais do sistema (Binder, IEBCOPY, IEBUPDTE, BPXCOPY, etc.)
📌 Importante:
APPLY NUNCA deve ser feito diretamente em produção. Sempre em clone, test system, shadow libraries.
Target Libraries, Target Zone e Distribution Zone
Target Libraries: onde vivem os executáveis, macros, fontes e dados usados pelo sistema
Target Zone (TZONE): o mapa vivo do que está instalado e em qual nível
Distribution Libraries (DLIB): código base, mantido pelo ACCEPT
Distribution Zone (DZONE): mapa do código base
👉 APPLY mexe apenas em Target Libraries e TZONE.
SET BDY – dizendo ao SMP/E onde operar
Antes do APPLY:
SET BDY(TARGET1)
APPLY ...
Cada Target Zone mapeia um conjunto específico de bibliotecas.
💡 Estratégia clássica:
APPLY no sistema de teste
Validação
Promoção do clone para produção
Como o SMP/E escolhe os SYSMODs
A seleção é controlada pelos operandos do APPLY:
Seleção direta
SELECT
EXCLUDE
FORFMID
Por tipo
FUNCTION
PTF
APAR
USERMOD
Por origem
SOURCEID
EXSRCID
Se nenhum tipo for especificado:
👉 default = apenas PTFs
GROUP e GROUP EXTEND – o efeito dominó controlado
GROUP
Inclui automaticamente:
Pré-requisitos (PRE)
Co-requisitos (REQ)
IF-requisitos
Exemplo:
UL9 → requer UL7 e UL8
UL7 → requer UL5
UL8 → requer UL6
👉 APPLY com GROUP seleciona UL9, UL7, UL8, UL5 e UL6
GROUP EXTEND
Vai além:
Resolve HOLDs automaticamente
Procura SYSMODs que supersedem erros ou requisitos faltantes
Pesquisa no GZONE e PTS
⚠️ Pode ser restringido:
NOAPARS
NOUSERMODS
BYPASS – a alavanca perigosa
Quando uma condição geraria erro fatal, o BYPASS manda o SMP/E ignorar.
Exemplos:
BYPASS(ID)
BYPASS(HOLD)
BYPASS(XZIFREQ)
BYPASS(HOLDFIXCAT)
⚠️ Use com extremo cuidado
Todo desastre em SMP/E começa com alguém que confiou demais no BYPASS.
APPLY CHECK – a simulação obrigatória
APPLY CHECK ...
O CHECK:
Não atualiza bibliotecas
Não altera CSI
Simula seleção, dependências e validações
Detecta regressões
🚨 CHECK não valida espaço em disco
📌 Dica Bellacosa:
CHECK sempre com BYPASS(HOLDSYSTEM,HOLDID)
REDO – reaplicando serviço
Usado quando:
Biblioteca foi restaurada de backup antigo
Fix aplicado se perdeu
APPLY SELECT(AZ81463) REDO
👉 Reinstala mesmo que já conste como aplicado
Espaço em disco: RETRY e COMPRESS
COMPRESS
COMPACTA bibliotecas alvo
Pode ser:
Por DDNAME
ALL
RETRY
Default = YES
Reage a erros de espaço
Usa lista definida no GZONE (RETRYDDN)
⚠️ Pegadinha clássica:
CHECK + COMPRESS ALL não faz sentido
CHECK não atualiza nada → COMPRESS não ocorre.
Applicability Checks – o funil do SMP/E
Depois da seleção:
Verifica se o FMID pertence ao Target Zone
Valida PRE, REQ e IF-REQ
Verifica HOLDs (SYSTEM, ERROR, USER, FIXCAT)
Executa cross-zone IFREQ (XZIFREQ)
Determina ordem de processamento
Ordem padrão:
Functions
PTFs
APARs
USERMODs
DELETE em Functions – quando uma versão morre
Funções podem ter:
++VER DELETE
Efeito:
Remove elementos da função antiga
Remove entradas no TZONE
Remove serviços dependentes
👉 DELETE explícito e implícito
JCLIN – a alma estrutural do APPLY
JCLIN:
É processado durante o APPLY
Cria estrutura no TZONE
Define MOD, LMOD, SYSLIB, LKEDCNTL
📦 Resultado:
SMP/E sabe como montar o load module
CALLLIBS
Indica linkagens implícitas
Binder é chamado duas vezes
Usa SMPMTS para restore futuro
Element Selection – evitando regressão
Cada elemento é rastreado por:
FMID – quem introduziu
RMID – quem substituiu
UMID – quem atualizou
SMP/E usa:
++VER PRE
++VER SUP
Para garantir:
Nenhum APPLY reduz o nível atual do elemento
Instalação real dos elementos
Dependendo do tipo:
MOD → Binder (link-edit)
MAC / SRC → IEBCOPY / IEBUPDTE
JAR → COPY ou GIMDRS
DATA / HFS → COPY / BPXCOPY
GIMDTS / GIMDRS
Permitem empacotar elementos não FB80
Reconversão automática no APPLY
CSI Updates – o inventário consolidado
Após o APPLY:
Atualiza entradas de elementos no TZONE
Atualiza FMID, RMID, UMID
Cria SYSMOD entry no TZONE
Atualiza APPID no GZONE
📌 Regra de ouro:
Status de APPLY se verifica no TZONE, não no GZONE
Relatórios – o SMP/E contando vantagem
Principais relatórios:
SYSMOD Status Report
Element Summary Report
Causer SYSMOD Summary (Root Cause)
Regression Report
Unresolved HOLD Report
HOLDDATA Summary
DDs importantes:
SMPRPT
SMPHRPT (HOLDDATA separado)
FIXCAT no APPLY moderno
FIXCAT permite:
Expressar interesse por categorias
Bloquear APPLY se serviço crítico faltar
Automatizar PSP buckets
Exemplo estratégico:
FIXCAT(IBM.ProductInstall-RequiredService)
👉 Garante instalação de todo serviço recomendado
Conclusão Bellacosa
APPLY é onde o SMP/E deixa de ser administrativo e vira operacional.
Quem domina APPLY:
Não quebra produção
Não regride serviço
Não depende de sorte
No mainframe, conhecimento não é poder — é sobrevivência.
No próximo capítulo: ACCEPT – quando o código vira base do sistema.
Sem comentários:
Enviar um comentário