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)

Zone	Função
GLOBAL	índice e controle
TARGET	o que está rodando
DLIB	base 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.”

 

 

Bellacosa Mainframe comenta sobre cobol quebrando e a busca por culpados smp/e nos bastidores

🔥💀 “SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE MEXEU NOS BASTIDORES”

O guia que todo dev COBOL deveria ler antes de culpar o programa

---

Se você é dev COBOL, já viveu isso:

💣 “o programa rodava ontem… hoje ABENDOU… e ninguém mexeu em nada”

👉 Spoiler: alguém mexeu sim
👉 E provavelmente foi o SMP/E

---

🧠 A VERDADE QUE NINGUÉM TE CONTA

No mundo do mainframe, seu COBOL não vive sozinho.

Ele depende de:

• load modules
• bibliotecas
• runtime
• serviços do sistema

E tudo isso é controlado por um cara invisível:

💀 SMP/E — o gerente silencioso do ambiente

---

🕰️ UM POUCO DE HISTÓRIA (QUE EXPLICA TUDO)

Antes dos anos 80…

• sysprog fazia manutenção manual
• copiava módulos na mão
• sobrescrevia código sem controle

Resultado?

💣 ambiente inconsistente
💣 sistema instável
💣 caos

Então nasceu o SMP (depois SMP/E):

👉 pra trazer controle, rastreabilidade e sanidade

---

🔥 TRADUZINDO PRA VOCÊ, DEV COBOL

Pensa assim:

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

---

⚙️ O QUE O SMP/E FAZ (NA VIDA REAL)

• instala produtos (CICS, DB2, z/OS)
• aplica correções (PTFs)
• atualiza módulos que você usa
• controla versões do ambiente

💡 Ou seja:

🔥 ele pode mudar seu runtime sem você tocar no código

---

💀 O FLUXO QUE DECIDE SEU DESTINO

receive → apply → accept

🧩 RECEIVE

👉 baixa a mudança
👉 não altera nada ainda

---

💥 APPLY

👉 altera o ambiente
👉 muda módulos que seu programa usa

💀 é aqui que seu COBOL pode “mudar de comportamento”

---

🏁 ACCEPT

👉 oficializa a mudança
👉 vira baseline

---

⚠️ EASTER EGG (VIDA REAL)

💣 “ninguém mexeu no programa”
👉 mas alguém fez APPLY ontem à noite

---

🧱 TARGET vs DLIB (A CHAVE DO UNIVERSO)

👉 Isso aqui explica MUITA coisa:

Tipo	O que é
TARGET	o que roda
DLIB	base confiável

---

💡 Cenário clássico:

• APPLY alterou TARGET
• seu programa usa nova versão
• comportamento mudou

👉 você nem viu acontecer

---

♻️ RESTORE — O HERÓI ESQUECIDO

Quando dá ruim:

👉 SMP/E pode restaurar versão da DLIB

restore = desfazer desastre

💡 Sim… dá pra “voltar no tempo”

---

🧠 CSI — O CÉREBRO DO SISTEMA

SMP/E não trabalha no escuro.

Ele mantém um banco chamado:

🔥 CSI (Consolidated Software Inventory)

Ali ele sabe:

• o que está instalado
• versões
• dependências
• histórico

---

💀 Sem CSI consistente:

você não tem ambiente… tem uma bomba relógio

---

📦 SYSMOD — O PACOTE QUE MUDA TUDO

Tudo que entra no sistema vem assim:

👉 SYSMOD

Tipos:

• PTF → correção
• APAR → problema corrigido
• FUNCTION → nova funcionalidade
• USERMOD → customização

---

💡 Curiosidade:

USERMOD mal feito = pesadelo eterno 😄

---

🧠 MCS — A LINGUAGEM SECRETA

Dentro do SYSMOD existe:

++ alguma coisa

Isso são MCS (instructions)

Exemplo:

++VER
++MOD
++HOLD

---

💡 Tradução:

SMP/E não “decide”… ele executa ordens do SYSMOD

---

💣 DEPENDÊNCIAS (ONDE O BICHO PEGA)

Tipos:

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

---

💥 Se faltar dependência:

APPLY FAILED

👉 e o sysprog entra em guerra

---

🧬 TRACKING — O NÍVEL NINJA

SMP/E sabe exatamente o nível de cada módulo:

FMID = origem
RMID = última substituição
UMID = updates

---

💡 Isso permite:

• saber versão real
• evitar conflito
• diagnosticar erro

---

⚠️ EASTER EGG DE PRODUÇÃO

💣 “o bug apareceu do nada”

👉 não apareceu

👉 o RMID mudou 😄

---

🧠 VISÃO DE GUERRA (PRA DEV COBOL)

Se você entender SMP/E:

✅ você para de culpar o programa
✅ entende mudanças de ambiente
✅ conversa melhor com sysprog
✅ vira profissional diferenciado

---

🔥 UMA GRANDE VERDADE

💀 COBOL quebra raramente
💀 ambiente quebra frequentemente

---

🍛 A PENSAR NA HORA DO ALMOÇO

👉 Quantos erros você já debugou…

…que na verdade eram:

• mudança de load module
• alteração de runtime
• PTF aplicada

---

🧪 MÃO NA MASSA (MENTALIDADE)

Próxima vez que algo quebrar:

❌ não pergunte:

“quem mudou o programa?”

✅ pergunte:

“teve APPLY recente?”

---

🚀 FRASE FINAL (ESTILO BELLACOSA)

🔥 “Seu programa não mudou…
o mundo ao redor dele mudou.”

 

Bellacosa Mainframe em uma missao possivel troubleshooting smp/e

🔥💀 TROUBLESHOOTING SMP/E PARA PADAWAN

“Quando o APPLY falha… começa o seu treinamento”

---

🧠 REGRA Nº1 (GRAVA ISSO)

💣 SMP/E NÃO ERRA
💣 ELE TE AVISA — VOCÊ NÃO ENTENDEU A MENSAGEM

---

🔍 1. ONDE OLHAR PRIMEIRO?

Quando algo falhar:

👉 NÃO OLHE O JCL PRIMEIRO

Olhe:

• 📄 SMPLOG
• 📄 SMPOUT

💡 ali está a verdade

---

⚠️ 2. ERRO MAIS COMUM — DEPENDÊNCIA

💥 Sintoma:

GIM35901E APPLY PROCESSING FAILED

👉 Causa:

• faltou PRE
• faltou REQ

---

🔥 Como resolver:

👉 use:

APPLY CHECK

👉 ou:

LIST SYSMODS

💡 descubra o que está faltando

---

🧩 3. HOLD DATA (PEGADINHA CLÁSSICA)

💥 Sintoma:

SYSMOD HELD

👉 Tradução:

“não instala isso ainda, jovem padawan”

---

🔥 Solução:

• verificar HOLDDATA
• ou usar (com cuidado 😈):

BYPASS(HOLDERR,HOLDSYS)

💡 nunca faça isso sem saber o impacto

---

💀 4. ZONE ERRADA (ERRO DE INICIANTE)

💥 Sintoma:

• nada acontece
• ou erro estranho

👉 Causa:

SET BDY errado

---

🔥 Correto:

GLOBAL → RECEIVE
TARGET → APPLY
DLIB   → ACCEPT

---

🧨 5. CSI INCONSISTENTE

💥 Sintoma:

• erro sem sentido
• comportamento estranho

👉 Causa:

• CSI fora de sincronia

---

🔥 Solução:

• revisar zones
• rodar REPORT
• validar histórico

---

⚙️ 6. ELEMENTO NÃO ENCONTRADO

💥 Sintoma:

ELEMENT NOT FOUND

👉 Causa:

• FMID errado
• elemento não pertence àquela zone

---

🔥 Solução:

👉 verificar:

++VER FMID(...)

---

🔁 7. QUANDO TUDO DER ERRADO

👉 use o poder supremo:

RESTORE

💥 volta versão estável da DLIB

---

🧠 CHECKLIST DE SOBREVIVÊNCIA

Antes de APPLY:

✔ RECEIVE ok
✔ APPLY CHECK rodado
✔ dependências resolvidas
✔ HOLDDATA analisado
✔ zone correta

---

⚠️ EASTER EGG (REALIDADE)

💣 “funcionava ontem”

👉 ontem não tinha APPLY 😄

---

🧠 DICA DE OURO

Sempre pergunte:

teve mudança de smp/e?

antes de:

debugar cobol

---

🔥 FRASE FINAL

💀 “o erro não está no código…
está no nível do sistema”

 

Bellacosa Mainframe e o que é smp/e

O que é SMP/E?

Se existe uma ferramenta indispensável para manter um ambiente IBM Mainframe atualizado, essa ferramenta é o SMP/E.

Sempre que uma empresa instala:

• uma nova versão do z/OS;

• uma correção (PTF);

• um novo produto IBM;

• um patch de segurança;

• uma atualização do CICS, Db2 ou IMS;

existe uma grande chance de o SMP/E estar envolvido.

Sem ele, administrar milhares de módulos e bibliotecas seria praticamente impossível.

---

Definição simples

O SMP/E (System Modification Program/Extended) é o sistema oficial do z/OS responsável por instalar, atualizar, corrigir e manter softwares no IBM Mainframe.

Ele controla todo o ciclo de vida dos produtos instalados, garantindo que as atualizações sejam aplicadas corretamente e que o ambiente permaneça consistente.

Em outras palavras:

O SMP/E é o "gerenciador de instalação e atualização de software" do IBM Mainframe.

---

Uma analogia simples

Imagine uma oficina responsável pela manutenção de uma frota de aviões.

Cada aeronave possui:

• motores;

• sistemas elétricos;

• instrumentos;

• softwares.

Quando uma peça precisa ser substituída, não basta instalar qualquer componente.

É necessário verificar:

• compatibilidade;

• versão;

• histórico;

• documentação.

O SMP/E faz exatamente isso para os softwares do z/OS.

---

O que significa SMP/E?

SMP/E significa:

System Modification Program/Extended

Em português:

Programa Estendido de Modificação do Sistema.

Apesar do nome, sua função vai muito além de "modificar".

Ele controla praticamente toda a manutenção de softwares do ambiente z/OS.

---

Para que serve?

O SMP/E é utilizado para:

• instalar produtos IBM;

• aplicar PTFs;

• instalar APARs corrigidas;

• aplicar HOLDDATA;

• instalar novas versões;

• controlar dependências;

• manter histórico das instalações;

• remover atualizações quando necessário.

---

Por que o SMP/E é importante?

Imagine instalar uma atualização do Db2.

Essa atualização modifica:

• centenas de módulos;

• bibliotecas;

• macros;

• programas;

• documentação.

Fazer tudo manualmente seria extremamente arriscado.

O SMP/E automatiza esse processo.

---

Como funciona?

O fluxo básico é:

IBM

↓

Correção (PTF)

↓

Recebimento (RECEIVE)

↓

Análise (APPLY CHECK)

↓

Aplicação (APPLY)

↓

Aceitação (ACCEPT)

Cada etapa possui uma finalidade específica.

---

Principais componentes

SYSMOD

É o nome genérico dado às modificações controladas pelo SMP/E.

Uma SYSMOD pode ser:

• PTF;

• APAR;

• USERMOD;

• FUNCTION.

---

PTF

Program Temporary Fix.

É uma correção oficial liberada pela IBM.

Exemplo:

UI12345

---

APAR

Authorized Program Analysis Report.

Representa um problema identificado em um produto IBM.

Após sua correção normalmente surge uma PTF.

---

HOLDDATA

Contém informações importantes sobre atualizações.

Pode informar:

• dependências;

• pré-requisitos;

• cuidados especiais;

• necessidade de IPL.

---

USERMOD

Modificação criada pelo próprio cliente.

Muito utilizada para customizações.

---

FUNCTION

Representa uma nova funcionalidade ou instalação inicial de um produto.

---

O banco de dados do SMP/E

O SMP/E mantém informações em um conjunto de datasets chamado:

CSI

Consolidated Software Inventory

Ele registra:

• produtos instalados;

• versões;

• PTFs;

• APARs;

• dependências;

• histórico.

É o "cadastro" de todo o software do sistema.

---

As principais zonas do SMP/E

O ambiente é dividido em zonas.

Global Zone

Controla todo o ambiente SMP/E.

---

Target Zone

Representa os produtos que estão em uso.

É a biblioteca utilizada pelo sistema operacional.

---

Distribution Zone

Contém a cópia mestre dos produtos instalados.

Serve como referência para futuras manutenções.

---

O processo RECEIVE

O RECEIVE recebe as atualizações.

Exemplo:

IBM

↓

PTF

↓

RECEIVE

Nenhuma alteração ocorre no sistema ainda.

Apenas o recebimento.

---

APPLY CHECK

Antes da instalação real, executa-se:

APPLY CHECK

O SMP/E verifica:

• dependências;

• conflitos;

• pré-requisitos.

Nenhuma alteração é realizada.

É um "ensaio".

---

APPLY

Agora sim.

A atualização é instalada.

PTF

↓

APPLY

↓

Bibliotecas TARGET

---

ACCEPT

Após validar a atualização, executa-se:

ACCEPT

A alteração passa também para as bibliotecas DISTRIBUTION.

---

Fluxo completo

IBM

↓

RECEIVE

↓

APPLY CHECK

↓

APPLY

↓

Testes

↓

ACCEPT

Esse é o fluxo clássico do SMP/E.

---

Quem utiliza?

Principalmente:

• Sysprogs;

• Administradores z/OS;

• Especialistas SMP/E;

• Administradores CICS;

• Administradores Db2;

• Administradores IMS.

Programadores COBOL normalmente não utilizam o SMP/E diretamente.

---

Benefícios

Segurança

Instala apenas atualizações válidas.

---

Histórico completo

Tudo fica registrado.

---

Controle de dependências

Evita instalações incorretas.

---

Padronização

Todos os ambientes seguem o mesmo processo.

---

Recuperação

Facilita retornar a versões anteriores quando necessário.

---

Curiosidades incríveis

1. O SMP/E existe há décadas

Ele evoluiu junto com o z/OS e continua sendo a principal ferramenta de manutenção de software do IBM Mainframe.

---

2. Grandes ambientes possuem milhares de PTFs instaladas

O CSI controla todas elas automaticamente.

---

3. O APPLY CHECK evita muitos problemas

Ele identifica conflitos antes que qualquer alteração seja aplicada ao sistema.

---

4. Quase todos os produtos IBM para z/OS utilizam SMP/E

Entre eles:

• z/OS;

• CICS;

• Db2;

• IMS;

• MQ;

• RACF;

• TCP/IP;

• inúmeros outros produtos IBM e de terceiros compatíveis com o processo.

---

Erros comuns de iniciantes

"PTF é igual APAR"

Não.

A APAR descreve um problema.

A PTF é a correção distribuída para resolver esse problema.

---

"RECEIVE instala a atualização"

Não.

O RECEIVE apenas recebe a atualização.

A instalação ocorre durante o APPLY.

---

"Depois do APPLY posso apagar tudo"

Não.

O ACCEPT atualiza as bibliotecas de distribuição e consolida a manutenção.

Ele faz parte do processo recomendado.

---

Quando aprender SMP/E?

Depois de compreender:

• z/OS;

• datasets;

• JCL;

• Storage;

• bibliotecas do sistema.

Esse conhecimento é essencial para quem pretende atuar como Sysprog ou administrador de ambientes IBM Z.

---

Conclusão

O SMP/E é a ferramenta oficial do IBM Mainframe para instalação e manutenção de software no z/OS. Ele controla todo o ciclo de vida de atualizações, desde o recebimento de correções até sua aplicação e consolidação, garantindo segurança, rastreabilidade e consistência.

Ao automatizar o gerenciamento de PTFs, APARs, USERMODs e novas versões de produtos, o SMP/E tornou-se um dos pilares da administração do IBM Z. Compreender seu funcionamento é indispensável para qualquer profissional que deseje trabalhar com infraestrutura, administração de sistemas ou manutenção de ambientes mainframe.