Translate

Mostrar mensagens com a etiqueta ptf. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta ptf. Mostrar todas as mensagens

sexta-feira, 15 de maio de 2026

☕💣 15 COISAS SOBRE SMP/E QUE TODO SYSProg JUNIOR DESCOBRE TARDE DEMAIS ☕💣

 

Bellacosa Mainframe e uma lista com 15 curiosidades sobre o SMP/E

☕💣 15 COISAS SOBRE SMP/E QUE TODO SYSProg JUNIOR DESCOBRE TARDE DEMAIS ☕💣

O SMP/E parece “só um instalador”.

Até o dia em que ele destrói seu APPLY, trava uma maintenance window ou começa uma guerra silenciosa com o RACF às 3 da manhã.

Aí você percebe:

o SMP/E não é ferramenta.
É uma entidade cósmica do z/OS.

Então pega o café porque aqui vão algumas das curiosidades mais fascinantes — e assustadoras — do universo SMP/E.


☕ 1 — O SMP/E EXISTE DESDE A ERA DOS DINOSSAUROS CORPORATIVOS

Antes do SMP/E existia o:

SMP (System Modification Program)

O “E” de Extended veio depois.

E mesmo assim MUITA lógica histórica do MVS clássico ainda vive dentro dele.

Ou seja:

parte do SMP/E moderno carrega DNA dos anos 70.

☕ 2 — O CSI É BASICAMENTE O “BANCO DE DADOS DA VERDADE”

O CSI:

Consolidated Software Inventory

é o coração do SMP/E.

Ele sabe:

  • o que está instalado,

  • o que falta,

  • pré-requisitos,

  • dependências,

  • supersedes,

  • HOLDDATA.

Se o CSI corromper:

o desespero psicológico começa.

☕ 3 — APPLY NÃO INSTALA “ARQUIVOS”

Essa é uma das maiores surpresas para iniciantes.

O SMP/E NÃO funciona igual Windows Installer.

Ele trabalha com:

  • ELEMENTS,

  • MODs,

  • MACs,

  • SRCs,

  • RELFILEs,

  • SYSMODs.

Ou seja:

o SMP/E pensa em engenharia de software,
não em “copiar arquivo”.

☕ 4 — O RECEIVE ORDER FEZ O MAINFRAME ENTRAR NA INTERNET SEM FAZER BARULHO

Muita gente acha que cloud inventou automação.

Enquanto isso o z/OS já fazia:

  • download automático,

  • SSL/TLS,

  • autenticação por certificado,

  • automação de manutenção,

anos antes de muita startup existir.


☕ 5 — O SMP/E USA JAVA… E ISSO ASSUSTA VETERANOS

Nada é mais engraçado que ver um SYSProg raiz descobrir:

javahome=
classpath=

dentro de uma JCL SMP/E.

O sujeito cresceu no:

IEBGENER
IDCAMS
IEFBR14

e de repente precisa debugar TLS Java.


☕ 6 — O HOLDDATA É O “SISTEMA NERVOSO” DA MANUTENÇÃO

HOLDDATA não é “só um arquivo”.

Ele avisa:

  • PTF problemática,

  • conflito,

  • ação manual,

  • PE error,

  • bypass necessário.

Veteranos respeitam HOLDDATA como:

um oráculo antigo do datacenter.

☕ 7 — EXISTE GENTE QUE TEM MEDO DE CONTENT(ALL)

E com razão.

O primeiro:

RECEIVE ORDER CONTENT(ALL)

de um ambiente antigo pode baixar um apocalipse de manutenção acumulada.

Tem ambiente que parece:

um tsunami de PTFs vindo do passado.

☕ 8 — O SMP/E CONSEGUE SABER DEPENDÊNCIAS MELHOR QUE MUITO GERENTE

Ele entende:

  • pré-requisitos,

  • co-requisitos,

  • supersedes,

  • incompatibilidades.

Ou seja:

o SMP/E sabe mais sobre o software do banco
do que metade da equipe.

☕ 9 — RACF E SMP/E TÊM UMA RELAÇÃO COMPLICADA

Quando SSL entra na história…

o SYSProg descobre:

  • keyring,

  • certificados,

  • trust chain,

  • RDATALIB,

  • DIGTCERT.

E aí nasce o clássico:

“isso é problema do RACF ou do SMP/E?”

Ninguém sabe.


☕ 10 — O SMP/E É MAIS PRÓXIMO DE UM GERENCIADOR DEVOPS DO QUE VOCÊ IMAGINA

Na prática ele já fazia:

  • versionamento,

  • rollback lógico,

  • controle de dependência,

  • inventory,

  • automação,

  • compliance.

Muito antes da palavra DevOps virar moda.


☕ 11 — APPLY CHECK SALVOU MAIS CARREIRAS QUE BACKUP

Veteranos SEMPRE fazem:

APPLY CHECK

Porque APPLY direto é:

esporte radical corporativo.

☕ 12 — O SMP/E NÃO “ESQUECE” FACILMENTE

O CSI guarda histórico detalhado.

Então quando alguém pergunta:

“quem aplicou isso?”

o SMP/E normalmente sabe.

É praticamente auditoria forense do z/OS.


☕ 13 — EXISTEM SYSProgs QUE AMAM MAIS O SMP/E QUE O ISPF

Parece exagero.

Até você perceber que:

um bom SYSProg mede estabilidade pela qualidade da maintenance strategy.

☕ 14 — O RECEIVE ORDER TRANSFORMOU O MAINFRAME EM UM CLIENTE CLOUD

Isso parece absurdo.

Mas o z/OS hoje:

  • autentica via TLS,

  • usa certificados digitais,

  • conversa com APIs,

  • baixa conteúdo remoto,

  • automatiza updates.

Ou seja:

o mainframe virou um cidadão da internet moderna.

☕ 15 — O SMP/E ENSINA UMA LIÇÃO BRUTAL SOBRE O z/OS

O iniciante acha que mainframe é:

“tela verde e COBOL”

O SMP/E mostra que o mundo real é:

  • engenharia de software,

  • segurança enterprise,

  • criptografia,

  • automação,

  • integração,

  • compliance,

  • arquitetura crítica.

E talvez seja por isso que o z/OS continua vivo.

Porque no final…

ninguém no planeta leva manutenção enterprise tão a sério quanto o mainframe.

quinta-feira, 14 de maio de 2026

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

 

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

ItemInformação
TecnologiaSMP/E Internet Service Retrieval
FabricanteIBM + Broadcom ecosystem
Consolidação comercialAnos 2000
Popularização massivaEra z/OS 1.10+
FunçãoDownload automatizado de manutenção
Situação atualAinda 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.

terça-feira, 14 de abril de 2026

🧠 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 

terça-feira, 7 de abril de 2026

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

 

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

EtapaStatus
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.”


segunda-feira, 6 de abril de 2026

💀🔥 SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE REESCREVEU O MUNDO AO REDOR

 

Bellacosa Mainframe falando sobre SMP/E 

💀🔥 “SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE REESCREVEU O MUNDO AO REDOR”

O guia que todo dev sênior precisa ler antes de culpar o programa


Você já viveu isso:

💣 “rodava ontem… hoje ABENDOU… ninguém mexeu no código”

👉 Então deixa eu te contar a verdade que poucos falam no mainframe:

💀 o código raramente muda… o ambiente muda o tempo todo

E quem controla isso?

🔥 SMP/E — System Modification Program / Extended


🕰️ UM POUCO DE HISTÓRIA (POR QUE ISSO EXISTE)

Antes do SMP/E:

  • sysprog copiava módulo na mão
  • sobrescrevia biblioteca sem controle
  • não existia rastreabilidade

Resultado?

💣 ambiente inconsistente
💣 bugs “fantasmas”
💣 caos operacional

O SMP nasceu pra resolver isso… e evoluiu para o SMP/E:

👉 controle
👉 consistência
👉 governança


🧠 SMP/E NA PRÁTICA (SEM ROMANTIZAR)

Pensa assim:

seu programa = ponta do iceberg
smp/e = quem controla o oceano inteiro

Ele decide:

  • qual versão roda
  • quais dependências são válidas
  • o que entra no sistema
  • o que quebra silenciosamente

🔠 ACRÔNIMOS (TRADUÇÃO DE VERDADE)

🔥 SMP/E

👉 System Modification Program / Extended
👉 gerenciador de instalação e manutenção


📦 SYSMOD

👉 pacote de mudança

Tipos:

  • FUNCTION → instala produto
  • PTF → correção oficial
  • APAR → problema reportado
  • USERMOD → customização local

💣 Easter egg:

USERMOD mal feito vira dívida técnica eterna


🧬 CSI

👉 Consolidated Software Inventory

👉 banco VSAM onde tudo é registrado:

  • versões
  • dependências
  • histórico

💀 sem CSI consistente:

você não tem ambiente… tem sorte


🧠 FMID / RMID / UMID

  • FMID → origem (quem criou)
  • RMID → última substituição
  • UMID → updates incrementais

👉 isso é controle de versão REAL (muito antes do Git 😄)


🧱 COMO FUNCIONA O ARMAZENAMENTO

📦 O coração: CSI (VSAM)

👉 dataset VSAM KSDS

Contém:

  • ZONES
  • entradas de elementos
  • relações entre bibliotecas

🧩 ZONES (ARQUITETURA LÓGICA)

ZoneFunção
GLOBALíndice e controle
TARGETo que está rodando
DLIBbase confiável

💡 Insight de sênior:

🔥 TARGET mente
🔥 DLIB não mente


📁 TIPOS DE DATASETS DO SMP/E

🔹 SMPCSI

👉 o banco (VSAM)


🔹 SMPPTS

👉 staging dos SYSMODs (RECEIVE)


🔹 SMPLOG / SMPOUT

👉 logs e mensagens (onde está a verdade)


🔹 TARGET LIBRARIES

👉 executáveis (load modules)


🔹 DISTRIBUTION LIBRARIES (DLIB)

👉 base confiável (source, macros, objetos)


💣 Curiosidade:

DLIB geralmente NÃO é executável
e mesmo assim é mais importante que TARGET


⚙️ COMO O SMP/E FUNCIONA (O FLUXO QUE MANDA EM TUDO)

RECEIVE → APPLY → ACCEPT

🔹 RECEIVE

  • carrega SYSMOD
  • não altera sistema

🔹 APPLY

  • altera TARGET
  • muda runtime

💀 aqui nasce o problema


🔹 ACCEPT

  • atualiza DLIB
  • vira baseline

💣 Easter egg:

APPLY muda o presente
ACCEPT muda o futuro


🖥️ SMP/E NO ISPF (TELA VERDE RAIZ)

Acesso típico:

TSO SMPE

Menu clássico:

  • RECEIVE
  • APPLY
  • ACCEPT
  • RESTORE
  • LIST / REPORT

💡 Dica de sênior:

ISPF é interface…
mas quem manda é o JCL


⚙️ SMP/E VIA BATCH (MUNDO REAL)

Execução padrão:

//SMPE EXEC PGM=GIMSMP
//SMPCSI DD ...
//SYSIN DD *
SET BDY(TZONE).
APPLY CHECK.
/*

💣 Curiosidade:

todo clique no ISPF vira JCL por baixo


🧩 MCS — A LINGUAGEM DO SMP/E

Tudo começa com:

++PTF
++VER
++MOD

🔥 ++VER (O MAIS IMPORTANTE)

Define:

  • FMID
  • dependências
  • aplicabilidade

💀 erro aqui = APPLY FAIL


🔗 DEPENDÊNCIAS (ONDE O BICHO PEGA)

  • PRE → precisa antes
  • REQ → precisa junto
  • SUP → substitui

💣 80% dos erros de SMP/E:

👉 dependência não resolvida


🏗️ JCLIN — O SEGREDO QUE NINGUÉM TE CONTA

👉 não executa
👉 descreve o link-edit

💡 SMP/E aprende como montar o sistema


💀 erro clássico:

código certo… montagem errada


🧬 TRACKING (O NÍVEL QUE DIFERENCIA)

SMP/E sabe:

FMID → origem
RMID → substituição
UMID → updates

💡 Insight:

  • 1 RMID por elemento
  • vários UMIDs

👉 isso explica comportamento estranho


💣 CASO REAL (VOCÊ JÁ VIU ISSO)

👉 programa mudou comportamento

Causa:

  • novo PTF
  • RMID alterado
  • runtime atualizado

💀 não foi o código


⚠️ TROUBLESHOOTING RÁPIDO

Se der erro:

  1. leia SMPOUT
  2. verifique dependência
  3. cheque HOLDDATA
  4. valide zone
  5. rode APPLY CHECK

🍛 A PENSAR NA HORA DO ALMOÇO

👉 quantos bugs você debugou…

…que eram:

  • mudança de load module
  • alteração de ambiente
  • PTF aplicado

🚀 CONCLUSÃO (NÍVEL SÊNIOR)

💀 SMP/E não instala software
🔥 ele governa o estado do sistema


🔥 FRASE FINAL (ASSINATURA)

💣 “Seu código não mudou…
o mundo ao redor dele mudou — e você não viu.”