Bellacosa Mainframe e o SMP/E o poder da atualização do Sysprog

☕🔐 SMP/E INTERNET SERVICE RETRIEVAL — O “WINDOWS UPDATE” DO MAINFRAME QUE TRANSFORMOU O SYSProg EM UM ENGENHEIRO DE SEGURANÇA ENTERPRISE ☕🔐

Existe um momento na vida de todo profissional de mainframe em que ele percebe uma verdade brutal:

O z/OS deixou de ser “apenas um sistema operacional”.

Ele virou uma fortaleza criptográfica conectada à internet.

E poucos exemplos mostram isso tão bem quanto o SMP/E Internet Service Retrieval.

Lançado oficialmente nas gerações modernas do SMP/E do z/OS no início dos anos 2000 e amplamente consolidado durante a era z/OS 1.10/1.11 em diante, esse recurso mudou completamente a forma como o mainframe recebe manutenção.
E diferente de muitos recursos clássicos do universo IBM, ele nunca foi oficialmente retirado do mercado — pelo contrário: tornou-se praticamente obrigatório no ecossistema moderno de manutenção enterprise.

---

☕ O DIA EM QUE O SMP/E PAROU DE SER “SÓ UM INSTALADOR”

Antigamente, baixar manutenção para mainframe parecia operação militar.

O SYSProg precisava:

• entrar no portal do fabricante,
• procurar PTF manualmente,
• baixar arquivos,
• transferir para o z/OS,
• organizar datasets,
• conferir HOLDDATA,
• aplicar RECEIVE/APPLY/CHECK.

Era praticamente um ritual xamânico corporativo.

Então surgiu o RECEIVE ORDER via internet.

E o jogo mudou.

Agora o próprio SMP/E:

consulta servidores,
autentica via SSL,
baixa manutenção,
valida certificados,
e entrega tudo pronto no z/OS.

O que antes parecia um processo artesanal virou quase um:

yum install do mundo mainframe.

---

☕ O SYSProg MODERNO VIROU UM “ENGENHEIRO DE PKI”

E aqui está a parte que muita gente fora do z/OS não entende.

Para configurar SMP/E Internet Service Retrieval, você NÃO aprende só SMP/E.

Você aprende:

• SSL/TLS,
• PKI,
• certificados X.509,
• RACF Digital Certificates,
• ACF2,
• Top Secret,
• Java no z/OS,
• USS,
• segurança enterprise,
• autenticação criptográfica.

Ou seja:

o SYSProg moderno virou meio administrador Linux,
meio especialista em segurança,
meio engenheiro de criptografia.

---

☕ O MAINFRAME AGORA FALA HTTPS COMO UM NAVEGADOR MODERNO

Esse é o detalhe mais fascinante.

O SMP/E literalmente age como um cliente HTTPS corporativo.

Ele conversa com:

Broadcom Order Server
Broadcom Download Server

usando:

• SSL,
• certificados digitais,
• trust chain,
• autenticação mútua.

Sim.

O z/OS está fazendo praticamente o mesmo tipo de handshake TLS que:

• Chrome,
• Firefox,
• Edge,
• APIs REST modernas.

Só que dentro do coração bancário do planeta.

---

☕ O “CHAVEIRO DIGITAL” DO MAINFRAME

A parte mais linda disso tudo é o conceito de KEYRING.

O nome parece inocente.

Mas o keyring é basicamente:

o cofre de identidade digital do z/OS.

Ali ficam:

• certificados pessoais,
• certificados trusted,
• chaves privadas,
• cadeias de confiança.

Sem keyring:

não existe SSL no mundo mainframe.

---

☕ RACF, ACF2 E TOP SECRET — A GUERRA DOS IMPÉRIOS

Uma das coisas mais clássicas do universo z/OS aparece aqui:

Cada ESM faz tudo de um jeito diferente.

O curso mostra comandos para:

• RACF,
• CA ACF2,
• CA Top Secret.

E isso revela uma verdade histórica maravilhosa:

no mainframe até os certificados têm guerra política.

O RACF virou o padrão dominante.

Mas ACF2 e Top Secret ainda vivem fortíssimos em bancos, seguradoras e governos.

E cada ambiente tem sua própria “religião operacional”.

---

☕ O ERRO QUE TODO SYSProg COMETE PELO MENOS UMA VEZ

O material mostra algo que parece pequeno:

RECFM=VB
LRECL=84
ASCII

Mas aqui mora o terror psicológico do SMP/E moderno.

Porque basta transferir um certificado errado…

e o inferno começa.

Você ganha:

SSL handshake failure
GSK_ERROR_BAD_CERT
certificate validation error

E aí começa o clássico ritual do SYSProg:

• olhar JESMSGLG,
• abrir IPCS,
• conferir encoding,
• verificar RACDCERT,
• revisar keyring,
• discutir com segurança,
• culpar firewall,
• descobrir depois que o FTP foi BINÁRIO.

---

☕ O DETALHE MAIS ASSUSTADOR: JAVA

Sim.

JAVA.

O SMP/E moderno depende de Java para HTTPS.

Isso quebra completamente a cabeça do velho operador de MVS raiz.

Porque o sujeito que cresceu no:

IEBGENER
IDCAMS
IEHLIST

agora precisa entender:

classpath
javahome
TLS stack
USS

É a colisão definitiva:

mainframe clássico VS infraestrutura moderna.

---

☕ CONTENT(ALL) — O BOTÃO DO APOCALIPSE

Existe uma parte especialmente perigosa no RECEIVE ORDER:

CONTENT(ALL)

Na teoria:

“baixe tudo que está faltando”

Na prática:

“prepare espaço em disco porque o tsunami de PTFs vem aí”

O primeiro RECEIVE ORDER CONTENT(ALL) de um ambiente antigo pode parecer:

um dump nuclear de manutenção acumulada.

---

☕ O MAINFRAME ENTROU NA ERA DA AUTOMAÇÃO

O mais fascinante é perceber o impacto histórico disso.

Durante décadas, manutenção de mainframe foi algo extremamente manual.

Hoje:

• jobs podem ser agendados,
• downloads automatizados,
• HOLDDATA atualizada sozinha,
• recomendações críticas baixadas automaticamente.

Ou seja:

o z/OS entrou oficialmente na era DevOps…
do jeito mainframe.

---

☕ O SYSProg MODERNO NÃO É MAIS “OPERADOR”

Esse talvez seja o maior ensinamento de todo esse tema.

Quem acha que mainframe é:

“tela preta e COBOL”

não sobrevive 10 minutos configurando SMP/E Internet Service Retrieval.

Porque aqui o profissional precisa dominar:

• segurança,
• rede,
• certificados,
• autorização,
• Java,
• USS,
• automação,
• SMP/E,
• RACF,
• troubleshooting SSL.

Isso não é mais “operar sistema”.

Isso é:

engenharia pesada de infraestrutura enterprise.

---

☕ LANÇAMENTO E STATUS HISTÓRICO

Item	Informação
Tecnologia	SMP/E Internet Service Retrieval
Fabricante	IBM + Broadcom ecosystem
Consolidação comercial	Anos 2000
Popularização massiva	Era z/OS 1.10+
Função	Download automatizado de manutenção
Situação atual	Ainda ativa e amplamente utilizada
Data de retirada                                                                                     Nunca oficialmente retirada ☕ CONCLUSÃO O SMP/E Internet Service Retrieval é uma das provas mais impressionantes de como o mainframe evoluiu silenciosamente. Enquanto muita gente imagina o z/OS como um fóssil corporativo… o sistema já estava fazendo: TLS enterprise, autenticação criptográfica, automação de manutenção, integração internet/mainframe, quando muito “sistema moderno” ainda engatinhava. E talvez essa seja a maior ironia da computação corporativa: o computador mais antigo do datacenter acabou se tornando o mais sofisticado.

 

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:

1. Conteúdo

   • módulos

   • macros

   • source

   • dados

   • HFS / JAR

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

SMP/E for z/OS Workshop – O que é e para que serve?

 

Bellacosa Mainframe apresenta o update no mainframe através do SMP/E

SMP/E for z/OS Workshop – O que é e para que serve

1. O que é SMP/E?

SMP/E significa System Modification Program/Extended.

• É a ferramenta oficial da IBM para gerenciar correções, atualizações e modificações de software no IBM z/OS Mainframe.

• Ele controla:

  • SYSMODs (System Modifications): PTFs, APARs, USERMODs

  • Aplicação e teste de patches sem quebrar o sistema

  • Gerenciamento de versões e dependências

Resumo rápido: SMP/E é o controle de versão, patch e deployment para sistemas z/OS.

Sem SMP/E, atualizar o Mainframe era um pesadelo: você aplicava patch e… torcia para nada quebrar.

---

2. História e evolução

• Criado nos anos 1980, quando o z/OS ainda era chamado MVS/XA.

• Antes do SMP/E: sysprogs e operadores aplicavam correções manualmente, resultando em ABENDs e erros misteriosos.

• SMP/E introduziu:

  • Controle de dependências entre SYSMODs

  • Capacidade de desfazer patches problemáticos (RESTORE)

  • Auditoria e rastreabilidade de modificações

Fofoquice histórica:

• Nos primeiros dias, existia uma “tradição não oficial” de aplicar patches só às sextas-feiras, depois do expediente… mas ninguém documentava os passos. Isso virou lenda: “o patch de sexta-feira que ninguém lembra”. 😅

---

3. Casos de uso

• Aplicar um PTF (Program Temporary Fix) sem derrubar aplicações críticas.

• Testar correções em uma test library antes de ir para produção.

• Restaurar versões anteriores se uma atualização causar problemas.

• Gerenciar múltiplos ambientes: DEV, TEST, PROD, cada um com seu DLIB e SYSMODs.

Exemplo real de uso:

1. RECEIVE: trazer o PTF do IBM Service Repository
2. APPLY: aplicar o PTF na target library de teste
3. ACCEPT: promover a correção para produção
4. RESTORE: desfazer se algo der errado

---

4. Estrutura de SMP/E

• DLIB (Distribution Library): onde ficam os SYSMODs recebidos

• HOLD Library: para SYSMODs que precisam de aprovação ou teste

• Target Library: onde o software efetivamente roda

Pensando como Bellacosa: a DLIB é o “armário secreto do sysprog”, HOLD é o “cofre do teste”, e a Target Library é “o palco principal do Mainframe”.

---

5. Easter-eggs e curiosidades

• Alguns sysprogs antigos batizavam suas bibliotecas de SMP/E com nomes secretos, tipo “JEDI-DLIB”, “R2-D2-HOLD”.

• Existe uma piada clássica no z/OS: “Se SMP/E aceitar, você está salvo; se não, bem-vindo ao ABEND-land”.

• Comandos clássicos: RECEIVE, APPLY, ACCEPT, RESTORE → formam a linha da vida do SYSMOD.

---

6. Resumo Bellacosa

• O que: Gerenciador de patches e correções para z/OS

• Para que serve: Aplicar, testar, aceitar e restaurar modificações de software

• Onde atua: DLIB, HOLD, Target Library

• História: Criado nos anos 80 para controlar modificações de forma segura

• Dicas fofoqueiras: Sexta-feira era o dia favorito para patches misteriosos

• Easter-eggs: Bibliotecas secretas com nomes nerds, piadas internas de sysprog

 

Bellacosa Mainframe apresenta um review smp/e 

🧠 SMP/E for z/OS – Uma Revisão

Revisão definitiva (com cheiro de fita, CSI alinhado e café frio ☕)

Se você acha que SMP/E é complicado, relaxa: ele só é honesto.
Honesto no sentido de que reflete exatamente a complexidade do z/OS — sem abstrações mágicas, sem “next, next, finish”.

SMP/E não é só uma ferramenta.
É memória histórica, controle cirúrgico e disciplina operacional.

Vamos revisar The Network do SMP/E for z/OS Workshop no melhor estilo Bellacosa Mainframe: com contexto, visão sistêmica e alguns easter eggs que só quem já brigou com um CSI entende 😉

---

🏛️ Antes do SMP/E: quando tudo era fita, suor e coragem

Nos anos 70, o mundo era simples — e perigoso.

• O sistema vinha em DLIB tapes

• O SYSGEN tinha Stage 1 e Stage 2

• O programador montava tudo na unha

• E manutenção?
  👉 Manual. Muito manual.

Resultado?

• Instabilidade

• Erros humanos

• Sistemas que “funcionavam… até não funcionarem”

💾 Easter egg #1:

Quem nunca teve medo de rodar um IEP_COPY no volume errado… não viveu essa época.

---

🧬 A chegada do SMP (e depois SMP/E)

Nos anos 80, a IBM fez algo revolucionário:
automatizou o que não podia mais depender da memória humana.

Nascia o SMP, que depois evoluiu para SMP/E (System Modification Program / Extended).

Agora o sistema tinha:

• Global Zone → cérebro

• Target Zone → sistema em execução

• Distribution Zone (DLIB) → fonte da verdade

Tudo documentado.
Tudo rastreável.
Tudo auditável.

---

🧠 O conceito-chave: CSI (Consolidated Software Inventory)

O CSI é o coração do SMP/E.

Ele responde perguntas críticas como:

• O que está instalado?

• Onde está?

• Como foi construído?

• Quem depende de quem?

Zonas:

• Global Zone
  Índice mestre + opções de controle

• Target Zone
  Reflete o que está rodando

• Distribution Zone
  Reflete o que foi entregue

📌 Regra de ouro:

SMP/E não adivinha. Ele só faz exatamente o que o CSI diz.

---

📦 Tudo em SMP/E é SYSMOD

Não existe exceção.
Se entrou no SMP/E, virou SYSMOD.

Tipos clássicos:

• FUNCTION → produto novo

• PTF → serviço preventivo

• APAR → correção corretiva

• USERMOD → customização local (o famoso “aqui a gente fez diferente”)

Todos eles têm:

• MCS (++ statements) → inteligência

• Modification Text → o código

💾 Easter egg #2:

Viu ++HOLD? Pare. Respire. Leia o PSP antes de qualquer APPLY.

---

🔁 O fluxo eterno do SMP/E

O ciclo que nunca muda:

1. RECEIVE

   • Entra no SMPPTS

   • Atualiza Global Zone

   • Nada muda no sistema ainda

2. APPLY

   • Atualiza Target Libraries

   • Sistema pode ser testado

   • Ainda reversível

3. RESTORE

   • Volta ao último nível aceito

   • Usa DLIB como fonte

   • Seu botão de “desfazer”

4. ACCEPT

   • Atualiza DLIB

   • Ponto sem volta

   • Agora é história oficial

💣 Easter egg #3:

ACCEPT em produção sem teste é um pedido formal de incidente grave.

---

🌐 The Network: quando o SMP/E ganhou internet

Chegamos ao ponto alto do módulo: entrega eletrônica.

Com Shopz / JustShopz, tudo mudou:

• Menos fita

• Mais automação

• Menos transporte físico

• Mais rastreabilidade

Opções modernas:

• ServerPac → replace completo

• CBPDO → produto ou serviço incremental

• Internet Delivery

  • RECEIVE FROMNETWORK

  • RECEIVE FROMNTS

  • RECEIVE ORDER

📦 Tudo chegando direto no HFS/zFS, validado por hash, protegido por certificado X.509.

🔐 Easter egg #4:

Se o RACDCERT não reconhece seu certificado, o SMP/E também não vai.

---

🧾 Shopz, pedidos e abas que importam

Depois de submeter o pedido:

• Ele aparece como Open

• Depois Submitted ou Order Center

• E você acompanha em:
  👉 In Progress

Quando muda para Download…
🎉 chegou a hora.

📬 E-mail da IBM
🔗 Link direto
⏳ 14 dias de validade

---

🧠 SMP/E moderno não é só manutenção

Hoje o SMP/E também:

• Ordena PTF automaticamente

• Agenda serviço

• Controla origem dos fixes (SourceID)

• Centraliza histórico

Tudo isso com:

• RECEIVE ORDER

• ORDER Management (Option 7)

• Java ou ICSF

• FTPS + Hash SHA-1

---

🧪 Planejamento: onde bons sysprogs se diferenciam

Antes de qualquer INSTALL:

• Clone do sistema

• Program Directory

• PSP Buckets

• Espaço em Target, DLIB e SMP/E datasets

• IVP depois

• Testes reais

• Migração controlada

🧠 Easter egg final:

O melhor sysprog não é o que instala rápido.
É o que dorme tranquilo depois do IPL.

---

🏁 Conclusão

SMP/E não é moda.
Não é hype.
Não é simples.

Ele é engenharia de software em estado puro, aplicada a um dos ambientes mais críticos do planeta.

E se você chegou até aqui entendendo tudo isso…
👉 Parabéns: você fala fluentemente Mainframe.

SMP/E for z/OS Workshop : LIST & REPORT Commands

 

Bellacosa Mainframe apresenta SMP/E List and Report Commands

SMP/E for z/OS Workshop

ACCEPT Processing – LIST & REPORT Commands

Quando olhar o CSI é tão importante quanto instalar o código

Instalar SYSMOD qualquer um instala.
Agora… saber exatamente o que está instalado, onde, por quê e com qual dependência
👉 isso separa operador de System Programmer.

É aqui que entram os comandos LIST e REPORT.

---

LIST Command

Abrindo o CSI como quem abre o capô do sistema

O comando LIST é o bisturi do SMP/E.
Ele não interpreta, não deduz, não opina.
Ele mostra os fatos gravados no CSI.

📌 O LIST pode extrair informações de:

• Global Zone

• Target Zone

• Distribution Zone

• SMPPTS

• SMPLOG

• SMPSCDS

💡 Easter egg #1

Se você confia mais na memória do que no LIST,
o CSI vai te humilhar em algum momento.

---

Boundary: o detalhe que separa sucesso de confusão

Antes de usar LIST, você define o boundary:

• Global Zone → acesso a SMPPTS

• Zona com DDDEF do SMPLOG

• Target Zone associada ao SMPSCDS

• Ou tudo de uma vez com:

ALLZONES

⚠️ ALLZONES lista tudo que existe, não tudo que você quer ver.

💡 Easter egg #2

ALLZONES às 3 da manhã
é como dar SELECT * em produção.

---

O que dá pra listar no Global Zone

Com LIST você pode ver:

• OPTIONS

• UTILITIES

• DDDEFs

• FMIDSETs

• ZONESETs

• SYSMOD entries

• MCS entries do SMPPTS

• HOLDDATA (++HOLD)

HOLDDATA com lupa

Você pode filtrar por:

• HOLDERROR

• HOLDSYSTEM

• HOLDUSER

E ainda combinar com SYSMOD específico.

📌 Se combinar filtros demais, o SMP/E só lista
entradas que satisfaçam todos.

---

Filtros avançados (onde mora o poder)

LIST aceita os mesmos refinamentos do APPLY/ACCEPT:

• SOURCEID

• EXSRCID

• FORFMID

• XZLMOD

• XZLMODP

• XREF

👉 Ideal para:

• Debug de dependência

• Auditoria

• Pós-migração

• Comparação entre ambientes

💡 Easter egg #3

SOURCEID bem usado
vale mais que planilha paralela.

---

LIST em Target e Distribution Zones

Além do básico, você pode listar:

• TARGETZONE definition

• DLIBZONE definition

• DDDEFs

• ELEMENT entries:

  • MOD

  • MAC

  • SRC

  • JAR

  • HFS

• LMOD entries

SYSMOD entries com status

Você pode filtrar por:

• ERROR

• SUP (superseded)

• NOSUP

• RESTORE

• NOAPPLY

• NOACCEPT

• BYPASS

• DELETE

📌 SUP e NOSUP são mutuamente exclusivos.

💡 Easter egg #4

SYSMOD em ERROR não é bug
é aviso ignorado.

---

LIST LOG e BACKUP

• LIST LOG → conteúdo do SMPLOG

  • Total ou por intervalo de data

• LIST BACKUP → conteúdo do SMPSCDS

  • Tudo ou por SYSMOD específico

👉 LIST é o comando ideal para auditoria forense do SMP/E.

---

LIST vs DIALOG QUERY

LIST = dados brutos
QUERY = visão amigável

Quando a coisa aperta…
LIST sempre vence.

---

REPORT Command

Quando você precisa que o SMP/E pense por você

Se o LIST mostra,
o REPORT analisa.

Ele cruza zonas, dependências, FMIDs, SOURCEIDs e HOLDs
e ainda gera comandos prontos.

📌 REPORT é o SMP/E dizendo:

“relaxa, eu faço a correlação.”

---

REPORT CROSSZONE

Dependência entre produtos e zonas

Usado para responder:

“Instalei isso aqui… quebrou quem?”

Requisitos:

• ZONESET obrigatório

• Pode limitar por:

  • FMID

  • ZONE

O relatório mostra:

• Dependências cruzadas

• SYSMODs faltantes

• Se já foram RECEIVED

• Quem causou a dependência

👉 E ainda gera comandos SMP/E no SMPPUNCH

NOPUNCH

se você não quiser os comandos.

💡 Easter egg #5

SMPPUNCH esquecido
vira APPLY acidental.

---

REPORT ERRSYSMODS

Quando o passado volta pra cobrar

Identifica SYSMODs que:

• Já foram instalados

• Mas agora estão em ERROR HOLD

Pode analisar:

• Global Zone

• Target Zone

• Distribution Zone

Filtros:

• Data inicial / final

• FMID

O relatório mostra:

• SYSMOD afetado

• Reason ID

• Quem resolve

• ++HOLD completo

💡 Easter egg #6

ERROR HOLD não some
só muda de lugar.

---

REPORT SOURCEID

Quem veio de onde?

Descobre:

• Quais SOURCEIDs existem

• Quais SYSMODs usam cada um

Com ou sem filtro por SYSMOD.

👉 Excelente para:

• FIXCAT

• Hardware novo

• Coexistência

• Migração de release

---

REPORT SYSMODS

Comparação entre zonas

Usado para:

• Validar ambientes

• Comparar releases

• Checar desvio de serviço

Parâmetros:

• INZONE

• COMPAREDTO

Resultado:

• O que existe em uma zona

• E não existe na outra

• Com comandos prontos para corrigir

💡 Easter egg #7

Ambiente “igual” sem REPORT
é fé, não evidência.

---

REPORT MISSINGFIX (FIXCAT)

Adeus PSP Bucket manual

Disponível a partir do SMP/E 3.6.

Identifica:

• APARs faltantes

• Por categoria FIXCAT

• Para hardware, software e coexistência

Mostra:

• FIXCAT

• APAR

• PTF corretivo

• Dependências

• Problemas de HOLD

📌 Dois blocos:
1️⃣ Missing fixes
2️⃣ Resolving SYSMODs em erro

💡 Easter egg #8

FIXCAT bem usado
economiza fim de semana inteiro.

---

Bellacosa Summary – em poucas linhas

LIST mostra o que existe
REPORT explica o impacto
SMPPUNCH sugere a correção
Você decide se confia

---

Checklist Bellacosa – LIST & REPORT

✔ LIST antes de APPLY
✔ REPORT antes de migrar
✔ FIXCAT sempre atualizado
✔ SOURCEID bem definido
✔ SMPPUNCH revisado
✔ LOG nunca ignorado

---

Conclusão

Quem domina LIST e REPORT:

• Não instala no escuro

• Não depende de planilha

• Não descobre erro em produção

• Não briga com auditor

💡 Easter egg final

O SMP/E sempre soube a verdade.
Você só precisava perguntar direito.