SMP/E for z/OS Workshop : ACCEPT Processing

 

Bellacosa Mainframe SMP/E accept processing

SMP/E for z/OS Workshop

ACCEPT Processing

O momento em que o código vira história oficial

Se o APPLY é onde o código começa a rodar,
o ACCEPT é onde ele ganha certidão de nascimento.

Depois do ACCEPT, não tem mais desculpa:

“isso aqui já faz parte do produto”

---

O papel real do ACCEPT no SMP/E

O ACCEPT command é responsável por:

• Instalar os elementos dos SYSMODs nas Distribution Libraries (DLIBs)

• Atualizar a Distribution Zone (DZONE)

• Definir o nível oficial e permanente do software

📌 Em termos simples:

Zona	Papel
Target	Código que roda
Distribution	Código que define o produto

👉 Nunca se executa código direto das DLIBs
(Se você já viu alguém tentar… você sabe o nível do problema 😬)

---

Target vs Distribution – a verdade nua e crua

🔹 Target Libraries

• Load modules executáveis

• Macros e source (para assembly)

• Ambiente vivo

• Pode mudar

🔹 Distribution Libraries

• Elementos “puros”

• Backup oficial

• Base para RESTORE

• Não deveriam mudar toda hora

💡 Easter egg #1

Quem aceita PTF direto em DLIB de produção sem clone
não gosta de dormir tranquilo.

---

ACCEPT é parecido com APPLY?

Sim. E isso é proposital.

A IBM fez o ACCEPT ser quase um APPLY com outro destino:

• Mesmos critérios de seleção

• Mesmas opções:

  • CHECK

  • BYPASS

  • REDO

  • COMPRESS

• Mesma lógica de dependência

• Mesma validação de HOLDDATA

A diferença é onde o SMP/E escreve.

---

Pré-requisitos para um ACCEPT saudável

Antes de aceitar qualquer coisa, o SMP/E verifica:

✅ SYSMOD foi aplicado?

Por padrão:

• SIM → pode aceitar

• NÃO → rejeitado

Se quiser aceitar sem aplicar (caso raro):

BYPASS(APPLYCHECK)

💡 Easter egg #2

BYPASS(APPLYCHECK) é como sudo root
só use se você realmente souber o que está fazendo.

---

✅ Não existem HOLDs pendentes?

O ACCEPT verifica no Global Zone:

• SYSTEM HOLD

• USER HOLD

• ERROR HOLD

Se existir HOLD:

• ACCEPT para

• Você resolve primeiro

---

Como os HOLDs são resolvidos no ACCEPT

🟡 SYSTEM / USER HOLD

• Execute a ação descrita no REASON

• Depois use:

BYPASS(HOLDSYSTEM)

🔴 ERROR HOLD

• Resolvido automaticamente

• Quando o APAR/PTF corretivo é instalado

• Ou um superseding PTF é aceito

📌 Boa prática:

Nunca aceitar PTF com ERROR HOLD ativo.

💡 Easter egg #3

Quem ignora ERROR HOLD
aprende RESTORE na prática.

---

Seleção de elementos no ACCEPT

(a parte que poucos entendem)

O ACCEPT não copia elemento “no grito”.
Ele garante que nenhum nível seja regredido.

Ele compara:

• FMID

• RMID

• UMID

• PRE / SUB no ++VER

Regras básicas:

• Elementos substitutos devem PRE ou SUB

• UPD (SRC, MAC, ZAP) devem respeitar UMID

• Se não respeitar:

  • ACCEPT pode até continuar

  • Mas emite warning

  • E você acabou de assumir o risco

💡 Easter egg #4

Warning ignorado hoje
vira incidente amanhã.

---

O que o ACCEPT faz de verdade (por dentro)

Quando tudo está validado, o SMP/E:

1️⃣ Busca os elementos em:

• SMPPTS

• SMPTLIBs

• LKLIB / TXLIB

2️⃣ Invoca utilitários:

• IEBCOPY

• IEBUPDTE

• LINKEDIT (quando aplicável)

3️⃣ Instala nas DLIBs corretas
(via DISTLIB=)

4️⃣ Atualiza a Distribution Zone:

• Cria entradas de SYSMOD

• Atualiza FMID / RMID

• Remove UMIDs antigos

• Registra ZAPs e UPDs

---

Limpeza pós-ACCEPT (o “lixo controlado”)

Por padrão, o ACCEPT:

• Remove SYSMOD entry do Global Zone

• Apaga MCS do SMPPTS

• Deleta SMPTLIBs associados

• Remove backups (SMPCDS)

Tudo isso acontece porque:

O SYSMOD agora virou baseline

⚠️ Se quiser manter tudo:

NOPURGE

💡 Easter egg #5

Quem usa NOPURGE sem motivo
costuma ficar sem espaço em disco.

---

Relatórios do ACCEPT

Depois do ACCEPT, sempre revise:

• Accept Summary Report

• Element Change Report

• Utility Output

• Deleted SYSMOD Report (quando aplicável)

📌 Se você não leu o report:

O ACCEPT não aconteceu de verdade.

---

ACCEPT em uma frase (Bellacosa style)

RECEIVE traz o pacote
APPLY faz o sistema rodar
ACCEPT transforma mudança em padrão
RESTORE ensina respeito

---

Checklist Bellacosa – ACCEPT seguro

✔ ACCEPT sempre em DLIB clone
✔ BACKUP antes de produção
✔ Nenhum HOLD pendente
✔ APPLY feito (ou BYPASS consciente)
✔ Relatórios lidos
✔ Espaço em disco conferido

---

Conclusão

O ACCEPT é o último passo da cadeia SMP/E.
Depois dele:

• O código vira referência

• O produto muda de nível

• O RESTORE passa a depender disso

Quem domina ACCEPT:

• Entende gestão de software

• Não só instalação

💡 Easter egg final

System programmer bom instala.
System programmer experiente aceita.
System programmer sábio sabe quando não aceitar.

 

 

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:

1. Verifica se o FMID pertence ao Target Zone

2. Valida PRE, REQ e IF-REQ

3. Verifica HOLDs (SYSTEM, ERROR, USER, FIXCAT)

4. Executa cross-zone IFREQ (XZIFREQ)

5. Determina ordem de processamento

Ordem padrão:

1. Functions

2. PTFs

3. APARs

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