Bellacosa Mainframe Laboratorio SMP/E do caos a orquestração

🧪 LAB SMP/E — DO CAOS À ORQUESTRAÇÃO

🎯 Objetivo do Lab

Você vai executar:

1. 📦 RECEIVE / APPLY (com erro)
2. 📊 REPORT (diagnóstico)
3. 🔗 LINK MODULE (correção)
4. 🏗️ BUILDMCS (empacotamento)

👉 Resultado final:

Um ambiente corrigido, analisado e exportável

---

🧱 CENÁRIO DO LAB

👉 Situação:

• Produto instalado parcialmente
• Módulo faltando no LMOD
• PTF aplicada sem dependência

💥 Resultado:

Erro de execução + inconsistência SMP/E

---

🔥 PASSO 1 — RECEIVE (entrada da manutenção)

//RECEIVE JOB (ACCT),'SMP/E LAB',CLASS=A,MSGCLASS=X
//SMPCSI   DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPTS   DD DISP=SHR,DSN=SYS1.SMP.PTS
//SMPCNTL  DD *
  SET      BOUNDARY(GLOBAL).

  RECEIVE SYSMODS
          FROMDS('USER.PTF.INPUT')
          BYPASS(HOLDSYSTEM).
/*

---

💡 O que está acontecendo

• Carrega SYSMOD no SMPPTS
• Ignora HOLD SYSTEM (perigoso 👀)

---

⚠️ PASSO 2 — APPLY (com erro proposital)

//APPLY   JOB (ACCT),'SMP/E APPLY',CLASS=A,MSGCLASS=X
//SMPCSI  DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
  SET      BOUNDARY(TZONE1).

  APPLY    PTFS(UX12345)
           GROUPEXTEND
           BYPASS(HOLDCLASS).
/*

---

💥 Resultado esperado

Erro tipo:

GIM35901E - REQUIRED SYSMOD NOT FOUND

👉 Tradução:

Dependência faltando

---

🧠 PASSO 3 — REPORT (diagnóstico inteligente)

//REPORT  JOB (ACCT),'SMP/E REPORT',CLASS=A,MSGCLASS=X
//SMPCSI  DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPUNCH DD SYSOUT=*
//SMPCNTL DD *
  SET      BOUNDARY(TZONE1).

  REPORT   CROSSZONE.
  
  REPORT   ERRSYSMODS.

  REPORT   SYSMODS.
/*

---

🔍 O que você vai ver

• Dependências faltantes
• PTFs necessárias
• Conflitos

💡 E mais importante:
👉 SMPPUNCH com comandos prontos

---

🔗 PASSO 4 — LINK MODULE (cirurgia)

//LINKMOD JOB (ACCT),'SMP/E LINK',CLASS=A,MSGCLASS=X
//SMPCSI  DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
  SET      BOUNDARY(TZONE1).

  LINK     MODULE(CSAMPLE)
           FROMZONE(TZONE2).
/*

---

🧠 O que acontece

• Busca módulo em outra zona
• Rebuild do LMOD
• Cria TIEDTO

💡 Resultado:

Executável corrigido sem reinstalar tudo

---

🏗️ PASSO 5 — BUILDMCS (empacotar o ambiente)

//BUILDMCS JOB (ACCT),'SMP/E BUILD',CLASS=A,MSGCLASS=X
//SMPCSI   DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPUNCH DD SYSOUT=*
//SMPCNTL  DD *
  SET      BOUNDARY(TZONE1).

  BUILDMCS FORFMID(CICS123).
/*

---

📦 Resultado

No SMPPUNCH:

• ++FUNCTION
• ++MOD
• ++JCLIN

👉 Você criou um:

produto instalável do seu ambiente

---

🔁 PASSO 6 — APPLY CORRIGIDO

//APPLY2  JOB (ACCT),'SMP/E APPLY OK',CLASS=A,MSGCLASS=X
//SMPCSI  DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
  SET      BOUNDARY(TZONE1).

  APPLY    PTFS(UX12345)
           GROUPEXTEND
           CHECK.
/*

---

💡 Agora

• Sem erro
• Dependências resolvidas
• Ambiente consistente

---

🎯 LIÇÕES DO LAB (ESSENCIAL)

🧠 1. APPLY sem REPORT = risco

🧠 2. LINK MODULE = solução cirúrgica

🧠 3. BUILDMCS = portabilidade

🧠 4. REPORT = prevenção

---

💥 EASTER EGGS (NÍVEL BELLACOSA)

😈 Se você ignorar HOLDDATA
👉 vai quebrar produção

😈 Se usar LINK demais
👉 cria acoplamento invisível

😈 Se não usar BUILDMCS
👉 não consegue reconstruir ambiente

---

🚀 DESAFIO (NÍVEL HARDCORE)

Tente:

1. Rodar APPLY sem GROUPEXTEND
2. Ver erro
3. Resolver com REPORT + FIXCAT

---

🧠 FRASE FINAL DO LAB

“Quem roda SMP/E executa comando…
quem domina SMP/E controla o sistema.”

🧠 SMP/E na Prática: O que são MCS — Modification Control Statements?

Bellacosa Mainframe apresenta SMP/E na pratica o fluxo de um MCS

🧠 SMP/E na Prática : O que são MCS — Modification Control Statements?

Os MCS (Modification Control Statements) são instruções de controle usadas pelo SMP/E para descrever o que um pacote de manutenção contém e como ele deve ser instalado.

👉 Pense no MCS como a “receita” que diz ao SMP/E:

• quais módulos vão ser substituídos,
• quais macros entram ou saem,
• dependências necessárias,
• pré-requisitos,
• co-requisitos,
• SYSMODs substituídos,
• módulos afetados,
• e onde tudo deve ser aplicado.

Essas instruções aparecem normalmente dentro de:

• PTFs (Program Temporary Fixes)
• APARs
• USERMODs
• FMIDs (instalação de produtos)

---

🧾 Como os MCS são emitidos?

Você não digita MCS manualmente durante a aplicação normal. Eles vêm dentro dos pacotes de manutenção, distribuídos pelo fornecedor (ex.: IBM).

O fluxo típico é:

1. Você recebe um PTF/APAR.
2. Dentro dele existem blocos MCS, como:
   • ++VER
   • ++MOD
   • ++MAC
   • ++JCLIN
   • ++HOLD
   • ++IF / ++REQ / ++PRE
3. Esses blocos descrevem ao SMP/E:
   • quais módulos substituir
   • como montar link-edit
   • dependências
   • regras de instalação

---

⚙️ Onde o APPLY entra nessa história?

O comando APPLY do SMP/E processa as instruções MCS e efetivamente instala as mudanças no ambiente target.

Fluxo simplificado:

1. RECEIVE
   • lê os MCS e registra no banco SMP/E.
2. APPLY
   • valida dependências declaradas nos MCS.
   • verifica PRE/REQ/IF.
   • monta JCL se houver ++JCLIN.
   • atualiza módulos, macros, etc.
3. ACCEPT
   • confirma no DLIB (distribution library).

---

🔄 Relação direta entre MCS e APPLY

✔ Os MCS dizem o que fazer.
✔ O APPLY executa o que foi declarado.

Exemplo conceitual:

++VER
++MOD(MYMOD) DISTLIB(AOSL)
++MAC(MYMAC)
++JCLIN

O APPLY vai:

• validar PREs e REQs,
• aplicar módulos,
• montar e executar o JCLIN,
• atualizar o ambiente.

---

🧩 O APPLY “lê” os MCS?

Exatamente. O SMP/E usa os MCS como instruções de engenharia. O APPLY:

• lê os blocos ++VER / ++MOD / ++MAC / ++JCLIN
• monta a sequência correta
• valida integridade
• garante consistência entre FMIDs, SYSMODs e bibliotecas

Sem MCS, o APPLY não saberia o que fazer.

---

🧪 Exemplo didático

Imagine um PTF que corrige um módulo COBOL:

O MCS pode declarar:

++VER(Z038) FMID(HBB7780).
++MOD(IGYCRCTL) DISTLIB(SIGYLOAD).

O APPLY irá:

• verificar FMID HBB7780
• garantir dependências
• substituir o módulo IGYCRCTL na loadlib correta

---

🧠 Resumo prático

• MCS = linguagem que descreve a manutenção.
• SMP/E = interpretador/engine.
• APPLY = ação que materializa as mudanças.

---

Um exemplo de MCS realista para um PTF que altera componentes do IBM Enterprise COBOL for z/OS e depende do runtime do IBM Language Environment (LE).

⚠️ Este é um exemplo didático (estrutura fiel, mas nomes ilustrativos).

---

📦 Exemplo — MCS de um PTF de COBOL/LE

Imagine um PTF que:

• Atualiza o módulo IGZCCTL (runtime LE para COBOL)
• Atualiza o compilador IGYCRCTL
• Exige um pré-requisito
• Inclui JCLIN para link-edit

Exemplo MCS

++PTF(UX12345) REWORK(20260413).
++VER(Z038)
     FMID(HIGY170)
     PRE(UJ99999)
     REQ(LE37000).

++HOLD(UX12345)
     SYSTEM
     REASON(ACTION)
     DATE(260413)
     COMMENT(
       'Este PTF atualiza módulos do compilador COBOL e
        componentes de runtime LE. Requer rebind após APPLY.'
     ).

++MOD(IGYCRCTL) DISTLIB(SIGYCOMP) SYSLIB(SIGYCOMP).
++MOD(IGZCCTL)  DISTLIB(SCEERUN)  SYSLIB(SCEERUN).

++MAC(IGZMAC01) DISTLIB(SCEEMAC).

++JCLIN.
 //LKED EXEC PGM=IEWL,PARM='LIST,XREF,LET'
 //SYSLMOD DD DSN=CEE.SCEERUN,DISP=SHR
 //SYSLIN  DD *
   INCLUDE SYSLIB(IGZCCTL)
   ENTRY IGZCCTL
   NAME IGZCCTL(R)
 /*
++END

---

🧠 O que cada bloco faz?

✔️ ++PTF

Define o SYSMOD e metadados.

✔️ ++VER

Define o FMID alvo (feature a ser mantida) e dependências:

• PRE → pré-requisitos
• REQ → requisitos obrigatórios

✔️ ++HOLD

Impede instalação automática e obriga ação manual (por exemplo, rebind).

✔️ ++MOD

Declara módulos a substituir e onde instalá-los.

✔️ ++MAC

Declara macros a atualizar.

✔️ ++JCLIN

Fornece instruções de link-edit que o SMP/E executará no APPLY.

---

⚙️ Como isso interage com APPLY?

Quando você executa:

SET BDY(TGT1).
APPLY PTFS(UX12345).

O SMP/E irá:

1. Verificar FMID e PRE/REQ
2. Validar HOLDS
3. Copiar módulos declarados em ++MOD
4. Rodar o JCLIN para link-edit
5. Registrar o resultado no CSI

---

🧩 Resumo rápido

• MCS = contrato do PTF
• APPLY = motor que executa esse contrato
• O ++JCLIN evita você montar manualmente link-edits 

 

Bellacosa Mainframe indica um lab para troubleshooting no Z/os SMP/E

🧪 LAB SMP/E — “Do APPLY sem CHECK ao RESTORE salvador”

🎯 Objetivo

Você vai:

• Executar RECEIVE → APPLY → ACCEPT → RESTORE
• Simular um erro real
• Diagnosticar via relatórios
• Recuperar o sistema corretamente

👉 Traduzindo:

você vai errar com segurança para aprender de verdade

---

🧱 Cenário do LAB

🖥️ Ambiente

• z/OS (real ou Hercules TK5)
• SMP/E configurado
• CSI existente
• Zonas:
  • GLOBAL
  • TARGET
  • DLIB

---

📦 Dados do exercício

• FMID: HXYZ123
• PTFs:
  • UQ00001 (base)
  • UQ00002 (dependente)
  • UQ00003 (com problema 💀)

---

🔄 FASE 1 — RECEIVE

🎯 Objetivo

Carregar SYSMODs no SMP/E

---

🧾 JCL

//RECEIVE JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPPTFIN DD DISP=SHR,DSN=SEU.PTF.INPUT
//SMPCNTL  DD *
 SET BDY(GLOBAL).
 RECEIVE SYSMODS.
/*

---

✅ Esperado

• SYSMODs no SMPPTS
• GLOBAL ZONE atualizada

---

🔍 Validar

• SMPRPT
• LIST SYSMODS

---

💣 FASE 2 — ERRO PROPOSITAL (APPLY SEM CHECK)

🎯 Objetivo

Simular erro real de produção

---

🧾 JCL (errado propositalmente)

//APPLY JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(TARGET).
 APPLY SELECT(UQ00003).
/*

---

💥 Resultado esperado

• Aplicação incompleta OU
• Sistema inconsistente

---

🧠 O que você fez

💀 ignorou dependências + não usou CHECK

---

🔍 FASE 3 — DIAGNÓSTICO

🎯 Objetivo

Descobrir o problema

---

📄 Analisar:

• SMPOUT
• SMPRPT
• Causer Report

---

💡 Encontrar:

• Dependência faltando (UQ00002)
• Possível HOLD

---

🧠 Insight

SMP/E não falha — ele te avisa

---

🔁 FASE 4 — APPLY CORRETO

🎯 Objetivo

Corrigir com CHECK

---

🧾 JCL

//APPLY JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(TARGET).
 APPLY CHECK SELECT(UQ00003) GROUPEXTEND.
/*

---

✅ Resultado

• Lista completa de dependências
• Nenhuma alteração real

---

🔥 Agora aplicar certo:

 APPLY SELECT(UQ00003) GROUPEXTEND.

---

📦 FASE 5 — ACCEPT

🎯 Objetivo

Consolidar mudança

---

🧾 JCL

//ACCEPT JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(DLIB).
 ACCEPT CHECK.
/*

---

⚠️ Depois:

 ACCEPT.

---

💀 Agora você não volta fácil…

---

🚨 FASE 6 — INCIDENTE

🎯 Simular problema pós-APPLY

👉 Imagine:

• Programa começa a falhar
• Load module inconsistente

---

🔄 FASE 7 — RESTORE

🎯 Objetivo

Reverter mudança

---

🧾 JCL

//RESTORE JOB ...
//SMPE     EXEC PGM=GIMSMP
//SMPCSI   DD DISP=SHR,DSN=SEU.CSI
//SMPCNTL  DD *
 SET BDY(TARGET).
 RESTORE SELECT(UQ00003) GROUP CHECK.
/*

---

🔍 Ajustar dependências

Depois:

 RESTORE SELECT(UQ00003) GROUP.

---

✅ Resultado

• TARGET revertido
• Sistema estável

---

💣 VARIAÇÃO AVANÇADA (nível sênior)

😈 Faça isso:

1. APPLY
2. ACCEPT
3. Tente RESTORE

---

💥 Resultado:

RESTORE não resolve

---

🧠 Aprendizado:

ACCEPT muda o jogo completamente

---

📊 CHECKLIST DO LAB

Etapa	Status
RECEIVE executado	☐
APPLY sem CHECK (erro)	☐
Diagnóstico feito	☐
APPLY correto	☐
ACCEPT realizado	☐
RESTORE executado	☐

---

🧠 LIÇÕES DO LAB

🔥 1. RECEIVE define o futuro

🔥 2. APPLY muda o presente

🔥 3. ACCEPT congela o sistema

🔥 4. RESTORE depende do passado

---

☕ FRASE FINAL

💀 “O erro não está no SMP/E… está em quem pula etapas.”

 

Bellacosa Mainframe apresenta o software com poder de vida e morte no Mainframe SMP/E

🔥 SMP/E Não Instala Software — Ele Decide se o Seu Sistema Vive ou Morre

Se você é um dev COBOL sênior, deixa eu te provocar logo de cara:

Você confia no seu programa…
mas você confia no ambiente onde ele roda?

Porque no mundo do z/OS, não é o COBOL que quebra primeiro.

👉 É o ecossistema invisível que o SMP/E controla.

---

☕ A História que Ninguém Te Conta

Antes do SMP/E, instalar software no mainframe era quase artesanal:

• Fita magnética 📼
• JCL manual
• Catálogo na mão
• E muita… muita reza

Quando a IBM criou o SMP/E, a ideia não era só instalar software.

Era algo muito maior:

Criar um sistema de governança de software

---

🧠 O Que é SMP/E (de verdade)

Esquece a definição de manual.

👉 SMP/E é:

• Inventário vivo do sistema
• Motor de instalação
• Mecanismo de auditoria
• Sistema de dependência

💡 Tradução Bellacosa:

É o Git + Maven + Kubernetes do mainframe… só que criado décadas antes.

---

🧱 Como o Sistema é Construído (e você provavelmente nunca viu assim)

O SMP/E enxerga o mundo em camadas:

SOURCE → MACRO → MODULE → LOAD MODULE → LIBRARY

👉 E aí vem o pulo do gato:

• Seu programa COBOL → vira MODULE
• Vários MODULEs → viram LMOD
• LMOD → roda no sistema

💥 Se UMA peça estiver errada…

Seu programa perfeito vira erro em produção

---

🔥 APPLY — O Comando Mais Perigoso do Seu Ambiente

Todo mundo já rodou:

APPLY PTFS(...)

E pensou:

“RC=0… sucesso!”

😈 Aqui está o problema:

• Dependência pode estar faltando
• HOLD pode estar ignorado
• Outra zona pode quebrar

👉 E o erro?

Vai aparecer depois… no seu COBOL

---

🧠 Easter Egg (nível produção)

O APPLY não instala software…
ele muda o estado do sistema inteiro

---

🔍 LIST vs REPORT — O Momento em que você vira adulto no SMP/E

LIST

• Mostra dados
• Não pensa

👉 Tipo um dump bonito

---

REPORT

• Analisa
• Detecta problema
• Sugere ação

💡 Tradução:

LIST responde
REPORT decide

---

💥 Exemplo real

Você roda:

REPORT CROSSZONE

E descobre:

• Dependência faltando
• Outro produto impactado

👉 Antes do APPLY

💥 Resultado:

Você evitou um incidente

---

🔗 LINK MODULE — A Cirurgia que Salva Madrugada

Cenário clássico:

• Programa chama módulo
• Módulo não está no LMOD

💣 Resultado:

• Abend
• Erro estranho
• Chamado urgente

---

💡 Solução:

LINK MODULE(...)

👉 O SMP/E:

• Busca módulos em outra zona
• Reconstrói o executável

💥 Sem reinstalar nada

---

😈 Easter Egg

Isso resolve rápido…
mas cria dependência (TIEDTO)

👉 Você resolveu hoje… e criou um problema silencioso amanhã

---

🏗️ BUILDMCS — O Superpoder Escondido

Pouca gente usa. Pouca gente entende.

👉 Mas isso aqui é ouro:

BUILDMCS FORFMID(...)

---

O que ele faz?

• Pega um ambiente instalado
• Gera um SYSMOD completo
• Permite reinstalar tudo

---

💡 Analogia moderna

BUILDMCS é o “docker commit” do mainframe

---

📖 Caso real

• Sistema com USERMOD crítico
• Sem documentação
• Sem backup lógico

👉 Solução?

BUILDMCS

💥 Ambiente salvo

---

⚠️ O Lado Sombrio

Se você tiver:

• Shared LMOD
• Elementos comuns

👉 BUILDMCS pode gerar inconsistência

---

🌐 SMP/E Moderno — Ele Já Virou DevOps

Hoje você não precisa mais:

• Fita
• PSP manual
• Caçar PTF

---

🚀 RECEIVE ORDER

RECEIVE ORDER

👉 SMP/E:

• Pede manutenção
• Baixa
• Organiza

---

🧠 FIXCAT

O SMP/E escolhe o que você precisa instalar

---

🔄 Pipeline moderno

ORDER → RECEIVE → APPLY → ACCEPT

💡 Isso é CI/CD… no mainframe

---

🔥 Exemplo Real (nível enterprise)

Upgrade de ambiente:

1. RECEIVE HOLDDATA
2. REPORT MISSINGFIX
3. APPLY FIXCAT
4. VALIDAR

👉 Sem PSP manual
👉 Sem chute

---

😈 Easter Egg final

Quem ainda usa fita…
está em 1998

---

🧠 O Que Isso Muda para um Dev COBOL

Você deixa de ser:

❌ “quem escreve programa”

E vira:

✅ quem entende o ambiente
✅ quem evita erro antes de acontecer
✅ quem conversa com sysprog de igual para igual

---

💥 Passo a Passo Mental (guarda isso)

Antes de qualquer APPLY:

1. 🔍 REPORT
2. 📊 Analisar dependência
3. ⚙️ APPLY CHECK
4. 🚀 APPLY real
5. 📦 ACCEPT

---

🚀 Frase Final (nível Bellacosa)

“Seu COBOL pode estar perfeito…
mas quem decide se ele roda é o SMP/E.”

 

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.