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 explica smp/e para padawans

🔥💀 DÚVIDAS FREQUENTES SOBRE SMP/E

“o que todo mundo já errou… mas não admite”

---

🧠 1. SMP/E é só para sysprog?

👉 Resposta curta: SIM (na prática)

👉 Resposta real:

• Dev COBOL não usa direto
• Mas é impactado o tempo todo

💡 Se você é dev e entende SMP/E:

você para de sofrer debug desnecessário

---

⚙️ 2. Qual a diferença entre RECEIVE, APPLY e ACCEPT?

👉 Clássico:

RECEIVE → carrega
APPLY   → instala (TARGET)
ACCEPT  → oficializa (DLIB)

💥 Dica:

APPLY muda o ambiente
ACCEPT muda o futuro

---

💀 3. Posso dar APPLY direto em produção?

👉 Pode…

👉 Mas também pode:

• quebrar sistema
• gerar incidente
• trabalhar de madrugada 😄

💡 Regra:

sempre APPLY CHECK + ambiente clone

---

🔁 4. O que faz o RESTORE?

👉 Volta para versão anterior usando DLIB

💡 Tradução:

botão “desfazer desastre”

---

🧩 5. O que é SYSMOD?

👉 Tudo que entra no SMP/E

Tipos:

• PTF → correção
• APAR → bug
• FUNCTION → produto
• USERMOD → custom

---

🧠 6. O que é CSI?

👉 Banco de dados do SMP/E

Guarda:

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

💀 Sem CSI:

você está cego

---

🧬 7. O que são FMID, RMID e UMID?

👉 Controle de versão real:

• FMID → origem
• RMID → última substituição
• UMID → updates

💡 SMP/E sabe mais do sistema do que você 😄

---

⚠️ 8. O que é HOLDDATA?

👉 Bloqueio de instalação

Tipos:

• ERROR
• SYSTEM
• USER

💥 Ignorar HOLD:

pedir problema

---

🔗 9. Por que o APPLY falha?

👉 90% dos casos:

• dependência (PRE/REQ)
• HOLDDATA
• zone errada
• FMID incorreto

---

🧠 10. O que é ++VER?

👉 A linha mais importante do SYSMOD

Define:

• onde instalar
• dependências
• compatibilidade

💡 Se der erro:

começa por aqui

---

🏗️ 11. O que é JCLIN?

👉 “manual de montagem” do load module

💡 Não executa… mas ensina o SMP/E

---

📦 12. Onde o SMP/E roda?

👉 Dentro do z/OS

Interfaces:

• ISPF (tela)
• JCL (produção)

❌ não é HMC

---

⚙️ 13. SMP/E automatiza manutenção?

👉 Sim (e deveria)

Com:

• REXX
• RECEIVE ORDER
• scripts

---

💣 14. Por que meu COBOL mudou comportamento?

👉 Possíveis causas:

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

💀 não foi seu código

---

🧠 15. Como evitar problemas com SMP/E?

👉 Checklist:

✔ APPLY CHECK
✔ validar dependências
✔ analisar HOLDDATA
✔ testar em clone
✔ só depois produção

---

🔥 BÔNUS — VERDADE FINAL

💀 “o erro raramente está no COBOL…
está no que mudou ao redor dele”

 

 

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

 

Bellacosa Mainframe apresenta SMP/E CSI

SMP/E Workshop – CSI (Consolidated Software Inventory) sem Medo

"Se o z/OS é uma cidade, o CSI é o cartório, o mapa urbano, o histórico de obras e o código de posturas… tudo junto."
Estilo Bellacosa Mainframe ☕🖥️

---

📌 O que é o CSI (Consolidated Software Inventory)?

O CSI é o coração do SMP/E. Sem ele, o SMP/E não sabe:

• onde instalar código

• qual versão está ativa

• quem substituiu quem

• o que pode ou não ser aplicado

👉 Nada de código executável vive no CSI.
O CSI é metadados, não binários.

Ele descreve como o sistema foi construído e qual o nível de serviço de cada elemento.

---

🧠 Por que o CSI é essencial?

Imagine um z/OS com:

• centenas de bibliotecas

• milhares de módulos

• décadas de PTFs, APARs e USERMODs

Sem um banco de controle confiável:

🚨 módulo no lugar errado = abend
🚨 load module mal linkado = IPL problem
🚨 manutenção fora de ordem = rollback impossível

👉 O CSI garante ordem no caos.

---

🧩 Estrutura do CSI – Zonas

O CSI é dividido em zonas, cada uma com uma função clara:

🌍 Global Zone

• Índice mestre do SMP/E

• Controla o que foi recebido

• Aponta para todas as outras zonas

Funções-chave:

• lista de FMIDs

• controle de opções

• vínculo entre Target ↔ Distribution

📌 O nome sempre é GLOBAL (não negocia!)

---

🎯 Target Zone (TZONE)

Descreve:

• bibliotecas executáveis

• módulos em uso

• status de APPLY

Aqui o SMP/E sabe:

• o que está rodando no sistema

• nível de serviço ativo

---

📦 Distribution Zone (DZONE)

Descreve:

• bibliotecas de distribuição (DLIB)

• código mestre

• status de ACCEPT

É a fonte da verdade para RESTORE.

---

🗂️ CSI como VSAM KSDS

Cada zona pode residir em:

• um KSDS próprio (recomendado)

• ou um único CSI compartilhado (não recomendado)

Boas práticas Bellacosa:

✔ Um KSDS por zona
✔ Zona no mesmo volume das bibliotecas
✔ LLQ sempre CSI
✔ HLQ em user catalog, não no master

---

🌱 Priming do CSI – GIMZPOOL

Antes de usar uma zona, ela precisa ser semeada:

• Macro: GIMZPOOL

• Copiado via IDCAMS REPRO

• Fonte: SYS1.MACLIB

Sem isso?

🚫 SMP/E nem conversa com a zona.

---

🧱 Entradas do CSI – a alma do inventário

O CSI é composto por entries, agrupadas em 4 categorias:

1️⃣ Control

Controlam como o SMP/E trabalha:

• GLOBAL definition entry

• OPTIONS

• UTILITY

• DDDEF

• FMIDSET / ZONESET

👉 Criadas manualmente (UCLIN ou diálogos)

---

2️⃣ Status

Controlam estado dos SYSMODs:

• SYSMOD entry

• HOLDDATA

Criadas quando:

• RECEIVE

• APPLY

• ACCEPT

---

3️⃣ Content

Descrevem o que existe nas bibliotecas:

• MOD

• MAC

• SRC

• DATA

• HFS

• JAR

Aqui vivem:

• FMID

• RMID

• UMID

---

4️⃣ Structure

Descrevem como tudo se combina:

• LMOD

• ASSEM

• DLIB

📌 LMOD só existe no Target Zone

---

🔎 FMID, RMID e UMID no CSI

Resumo raiz:

• FMID → quem introduziu o elemento

• RMID → quem substituiu por último

• UMID → quem atualizou (pode ter vários)

📌 Regra de ouro:

• 1 FMID

• 1 RMID

• N UMIDs

---

⚙️ DDDEF – o GPS do SMP/E

O SMP/E não depende de DD no JCL.

Ele usa DDDEF entries para:

• alocação dinâmica

• apontar datasets

• evitar ambiguidades entre ambientes

🔥 Dica Bellacosa:

Nome do DDDEF = LLQ do dataset

---

🛠️ Gerenciamento de Zonas

Os famosos Zone Management Commands:

• ZONEEXPORT / ZONEIMPORT

• ZONERENAME

• ZONEDELETE

• ZONECOPY

• ZONEMERGE

• GZONEMERGE

• ZONEEDIT

• UNLOAD

• UPGRADE

⚠️ Aviso sincero:

Alguns desses comandos não perdoam erro humano.

Use com:

• backup

• café

• e juízo

---

📦 UCLIN – poder absoluto (e perigoso)

O UCLIN permite:

• ADD

• REP

• DEL

Em quase qualquer entry do CSI.

📛 Comparação honesta:

UCLIN é o SUPERZAP do SMP/E.

Use só quando souber exatamente o que está fazendo.

---

🧠 Conclusão Bellacosa

O CSI não é só um inventário:

• é auditoria

• é rastreabilidade

• é rollback

• é governança

Quem domina o CSI:

✔ domina o SMP/E
✔ dorme tranquilo após APPLY
✔ não teme auditoria

---

📘 Próximo capítulo: Zone Management Commands na prática
📦 Casos reais, armadilhas e quando NÃO usar ZONEMERGE

---

✍️ Bellacosa Mainframe – porque z/OS não se administra no improviso.