SMP/E – Tracking Element Levels

 

Bellacosa Mainframe apresenta SMP/E Tracking Element Levels

SMP/E for z/OS Workshop – Tracking Element Levels

FMID, RMID e UMID sem mistério – no melhor estilo Bellacosa Mainframe

---

🎯 Por que o SMP/E controla níveis de elementos?

No mundo z/OS, nada é instalado “por cima e pronto”. Cada módulo, macro ou arquivo precisa ter rastro, histórico e responsável.

É exatamente isso que o SMP/E faz ao controlar o nível de serviço dos elementos nos ambientes:

• Target Libraries (TZONE) – o que está em execução

• Distribution Libraries (DZONE) – o que é a referência oficial

E o controle acontece por meio de três identificadores clássicos:

FMID – RMID – UMID

Se você domina esses três, domina auditoria, RESTORE, APPLY e ACCEPT.

---

🧠 A base de tudo: SYSMOD-ID

Todos os identificadores usados pelo SMP/E são extraídos do:

++HEADER

Eles são conhecidos genericamente como SYSMOD-ID, mas cada um tem um papel específico quando associado a um elemento.

---

🧩 O cenário do workshop (exemplo realista)

Vamos acompanhar a vida real de um elemento chamado MOD1.

📦 Function SYSMOD: HGF1200

• Introduz três elementos: MOD1, MOD2, MOD3

• Esses elementos formam o load module LMOD1

📌 Funções normalmente:

• não usam JCLIN inline

• usam relative file, que é um unload de um PDS com JCLIN

---

🏗️ APPLY da função – nascimento do elemento

Quando a função HGF1200 é aplicada:

• MOD1 passa a existir na Target Library

• SMP/E grava no TZONE:

Identificador	Valor
FMID	HGF1200
RMID	HGF1200
UMID	—

📌 Interpretação Bellacosa

MOD1 está no nível funcional.

A função HGF1200 é a dona do código.

Quando FMID = RMID, estamos falando de base code.

---

📦 ACCEPT da função – espelho na DLIB

Ao executar ACCEPT:

• MOD1 é copiado para a Distribution Library

• Os mesmos valores são registrados no DZONE

📌 O DZONE sempre representa:

“Como o produto deveria estar”

---

🩹 PTF UY00020 – primeira substituição

O PTF UY00020:

• contém um replacement de MOD1

• precisa identificar o dono funcional do elemento:

++VER FMID(HGF1200)

Como é o primeiro serviço sobre a base, não precisa de PRE.

🧾 Após APPLY do PTF UY00020 (TZONE)

Identificador	Valor
FMID	HGF1200
RMID	UY00020
UMID	—

📌 Regra de ouro:

Um elemento tem apenas um RMID.

---

🩹 PTF UY00040 – nova substituição

Agora entra o UY00040:

• substitui MOD1 novamente

• declara o UY00020 como pré-requisito

• identifica o dono funcional: HGF1200

Após APPLY:

Identificador	Valor
FMID	HGF1200
RMID	UY00040
UMID	—

📌 MOD1 agora está em um nível superior de serviço.

---

🐞 APAR AY91862 – update, não replacement

O APAR normalmente:

• não substitui o elemento inteiro

• faz um update para corrigir erro

O packager deve informar:

• FMID – quem é o dono

• PRE – qual SYSMOD está sendo atualizado

Após APPLY:

Identificador	Valor
FMID	HGF1200
RMID	UY00040
UMID	AY91862

📌 Conceito-chave

UMID representa quem atualizou o elemento.

---

🧩 USERMOD ME00012 – customização local

Agora entra o famoso USERMOD:

• altera MOD1 localmente

• precisa identificar:

  • FMID (HGF1200)

  • RMID (UY00040)

  • todos os UMIDs existentes

Após APPLY:

Identificador	Valor
FMID	HGF1200
RMID	UY00040
UMID	AY91862, ME00012

📌 Elemento pode ter vários UMIDs, mas apenas um RMID.

---

🔍 O que o SMP/E realmente está rastreando?

Para cada elemento, o SMP/E sabe responder:

• Quem introduziu? → FMID

• Quem substituiu por último? → RMID

• Quem atualizou? → UMID(s)

Isso vale tanto para:

• TZONE (APPLY)

• DZONE (ACCEPT)

---

🛡️ Visão de auditoria (dica de ouro)

Se você vê:

• USERMOD em produção

• sem ACCEPT

• com múltiplos UMIDs

👉 alerta de risco operacional

O SMP/E está dizendo a verdade. Basta saber ler.

---

🧠 Conclusão Bellacosa Mainframe

FMID diz quem manda
RMID diz quem substituiu
UMID diz quem mexeu

SMP/E não perde nada.
Quem se perde é quem não entende o CSI.

No próximo passo, o caminho natural é:

➡️ Consolidated Software Inventory

Porque rastrear é bom.
Consolidar é profissional.

---

💾 Mainframe bom é mainframe auditável.

RACF: Mapeamento OPERCMD x SDSF (do Console à Tela Verde

 

Bellacosa Mainframe apresenta RACF 

🔐 RACF NA VEIA

Mapeamento OPERCMD x SDSF (do Console à Tela Verde

“Quem manda no console manda no sysplex…
mas quem controla o RACF manda até no operador.” ☕🖥️

No mundo z/OS, existem dois universos de comando:

1. Console MVS real → controlado pela classe OPERCMDS

2. Interface SDSF → controlada por um conjunto de classes RACF

Muita gente confunde, mistura e sofre.
Vamos separar isso como JES2 separa spool 😈

---

🧱 1️⃣ OPERCMDS – O PODER DO CONSOLE MVS

🎯 O que controla?

A classe OPERCMDS controla quem pode emitir comandos MVS e subsistemas:

• No console físico

• Via TSO CONSOLE

• Via REXX ADDRESS CONSOLE

• Via automação (SA, NetView, OPS/MVS)

---

📌 Exemplos clássicos de comandos protegidos

Comando	Perfil OPERCMDS
D A,L	MVS.DISPLAY.ACTIVE
D U,ALL	MVS.DISPLAY.UNITS
$DA (JES2)	JES2.DISPLAY.ACTIVE
$P JOB123	JES2.PURGE.JOB
VARY 1234,ONLINE	MVS.VARY.DEVICE.ONLINE
SET SMF=xx	MVS.SET.SMF

📌 Regra de ouro:
👉 Se é comando MVS/JES, o RACF olha primeiro para OPERCMDS.

---

🧠 Exemplo RACF raiz

RDEFINE OPERCMDS MVS.DISPLAY.** UACC(NONE)
PERMIT MVS.DISPLAY.** CLASS(OPERCMDS) ID(OPERADOR) ACCESS(READ)
SETROPTS CLASSACT(OPERCMDS)
SETROPTS RACLIST(OPERCMDS) REFRESH

---

🖥️ 2️⃣ SDSF – O CONSOLE DE MENTIRINHA (MAS PERIGOSO)

“SDSF não é console…
mas faz estrago igual.” 😈

O SDSF é uma interface, e o RACF controla cada ação separadamente.

---

🧩 Classes RACF usadas pelo SDSF

Classe	Função
SDSF	Acesso geral ao SDSF
JESJOBS	Ações sobre jobs (cancel, purge, hold)
JES	Comandos JES
OPERCMDS	Se o SDSF emitir comando real
WRITER	Writers e saída
LOGSTRM	Logs do sistema
FACILITY	Funções especiais

---

📊 3️⃣ Tabela Mestre – OPERCMDS x SDSF

🧠 A tabela que salva operadores e professores

Ação no SDSF	Classe RACF	Perfil
Entrar no SDSF	SDSF	SDSF
Ver jobs (ST/DA)	JESJOBS	JOB.*
Cancelar job	JESJOBS	JOB.CANCEL
Purge job	JESJOBS	JOB.PURGE
Hold / Release	JESJOBS	JOB.HOLD
Ver SYSLOG	SDSF	LOG
Comando JES $DA	JES	JES2.DISPLAY.ACTIVE
Comando MVS D A,L	OPERCMDS	MVS.DISPLAY.ACTIVE
Alterar prioridade	JESJOBS	JOB.MODIFY

📌 Fofoquice real:
👉 Você pode ver tudo no SDSF e não conseguir executar nada, mesmo sendo “OPERADOR”.

---

⚔️ 4️⃣ Quando OPERCMDS e SDSF se cruzam

🎯 Exemplo clássico

Usuário no SDSF digita:

/D A,L

👉 O que acontece?

1. SDSF aceita o comando

2. RACF valida OPERCMDS

3. Se não tiver perfil → RC=8, NOT AUTHORIZED

📌 Moral:
SDSF não ignora OPERCMDS, ele chama o RACF como qualquer console.

---

🔐 5️⃣ Ambiente RACF Restritivo (vida real)

✔️ Boas práticas Bellacosa Approved™

• ❌ Nunca dar OPERCMDS MVS.** para usuário comum

• ✔️ Preferir:

  • MVS.DISPLAY.*

  • JES2.DISPLAY.*

• ✔️ Cancelamento via JESJOBS, não OPERCMDS

• ✔️ Usar ROLES no SDSF

• ✔️ Logar tudo (SMF 80, 83, 84)

---

🧪 6️⃣ Checklist rápido de segurança

✔ SDSF separado por perfil
✔ OPERCMDS mínimo necessário
✔ JESJOBS granular
✔ LOG e SYSLOG somente READ
✔ Nada de UACC(READ) em produção 😱
✔ SETROPTS AUDIT OPERCMDS ativo

---

☕ Frase final do Bellacosa Mainframe

“No mainframe, comando não é poder…
autorização é.”

 

Bellacosa Mainframe e o efeito borboleta

---

🦋 Lei do Efeito Borboleta

Ou: como um IF mal fechado pode mudar a vida inteira

Eu sempre digo: a vida roda em batch.
Você agenda um JOB achando que é simples… e lá na frente, três execuções depois, dá um ABEND existencial.

A Lei do Efeito Borboleta parte exatamente desse princípio:
👉 pequenas causas podem gerar consequências gigantescas.

O nome vem da famosa frase:

“O bater de asas de uma borboleta no Brasil pode provocar um tornado no Texas.”

Exagero poético? Talvez.
Mas quem já trabalhou com sistema complexo sabe: não é força, é encadeamento.

---

🌪️ Origem do Conceito (o nascimento do caos)

O conceito surgiu nos anos 1960 com o meteorologista Edward Lorenz, estudando modelos climáticos.

📌 Ele percebeu que:

• alterar um número decimal quase invisível

• mudava completamente a previsão do tempo

Na prática:

0.506127 ≠ 0.506

Na vida:

• um “sim”

• um atraso

• uma conversa não tida

• uma decisão tomada no cansaço

E o sistema inteiro muda.

---

🖥️ O Efeito Borboleta no Mainframe (a vida como JCL)

Quem é mainframeiro entende na hora:

• Um SORT mal definido

• Um campo com sinal errado

• Um JOB fora de sequência

• Um dataset sobrescrito sem backup

No começo: nada acontece.
Depois: tudo acontece ao mesmo tempo.

🦋 Pequeno erro →
🔥 Grande incêndio operacional

---

🧠 Como entender o Efeito Borboleta na prática

✔️ Sistemas complexos não são lineares
✔️ Nem tudo cresce proporcionalmente
✔️ Algumas coisas só fazem sentido depois

A vida:

• não é CICS online

• é batch noturno com dependência cruzada

---

🎎 No Japão (e nos animes)

O Japão ama esse conceito, mesmo sem chamar pelo nome.

📺 Exemplos clássicos:

• Steins;Gate – mudar uma mensagem muda o mundo

• Erased – pequenos atos alteram destinos

• Your Name – encontros mínimos, impactos máximos

• Tokyo Revengers – tentar consertar cria novos problemas

Easter egg cultural:
👉 o respeito extremo às pequenas ações
Cumprimentar, chegar no horário, silêncio, cuidado com detalhes.

---

🧩 Dicas Bellacosa para a vida

🦋 Nunca subestime pequenos atos

• Uma palavra

• Um gesto

• Uma omissão

🦋 Cuide do input

• Dados ruins geram saídas ruins

• Pensamentos ruins viram hábitos

🦋 Nem todo efeito é imediato

• Alguns JOBs rodam só no futuro

---

🤫 Fofoquices filosóficas

• A maioria dos “acidentes” não são acidentes

• A maioria das “coincidências” são encadeamentos

• A maioria dos arrependimentos começa pequeno

E ninguém percebe…
até o tornado chegar.

---

🦋 Importância do Efeito Borboleta

Ele nos ensina:

• humildade

• responsabilidade

• atenção aos detalhes

Porque no fim das contas…

Você nunca sabe qual pequena decisão
vai mudar tudo.

E como bom mainframeiro, eu aprendi cedo:

📌 O sistema nunca erra.
Ele apenas executa o que foi configurado.

E a vida?
Também.

🦋

🦇 Movimento Dark 1980 & Gótico 1990 — A Estrada Noturna da Tribo Invisível

 

🦇 Movimento Dark 1980 & Gótico 1990 — A Estrada Noturna da Tribo Invisível
Um artigo ao estilo Bellacosa Mainframe para o blog El Jefe Midnight

---

c

🌑 Introdução — Quando a noite era uma linguagem secreta

Antes dos algoritmos, antes da avalanche de notificações, existia um Brasil onde ser diferente exigia coragem — e ousadia. Os anos 1980 e 1990 foram décadas em que as subculturas não vinham por streaming: elas eram contrabandeadas por fitas cassete mal gravadas, revistas importadas escondidas entre LPs usados e conversas sussurradas nos corredores escuros das escolas.

É aqui que nasce o movimento Dark dos anos 80 e evolui para o Gótico dos anos 90: uma estrada noturna percorrida por almas inquietas, artistas à margem, e adolescentes que descobriam que o preto não era só uma cor — era um manifesto.

---

🦇 1. Os Anos 1980 — O Brasil cinza e o surgimento do Dark

O país recém saía da ditadura, o rock nacional florescia e o underground respirava mal, mas respirava. A estética Dark entrou como um vírus elegante:

• Cabelo comprido, franjas caídas, roupas rasgadas, coturnos;

• Letras introspectivas, soturnas, existenciais;

• Música vinda principalmente da Europa:

  • Siouxsie and The Banshees,

  • The Cure,

  • Joy Division,

  • Bauhaus,

  • Sisters of Mercy.

Mas aqui o Dark ganhou sotaque BR:

• Ira! — “Mudança de Comportamento”

• Plebe Rude

• Legião Urbana — “Sereníssima”, “Tempo Perdido”

• Arte No Escuro

• Zero – “Quimeras”

Os jovens não tinham internet — tinham o fanzine: xerox mal cortado, letras tortas, cola quente e vontade. Distribuía-se na rua Augusta, na Galeria do Rock, nos roqueiros do Largo do Arouche.

---

🦇 2. Ritual de Iniciação — Como alguém virava Dark em 1986

1. Uma fita K7 gravada de uma fita gravada de outra fita gravada da Rádio 89.

2. Cabelos ao vento, franjas cobrindo o olho esquerdo.

3. Roupas pretas: se não tinha griffe, a mãe ou a avó costuravam — movimento maker antes do maker existir.

4. Pôsters de filmes: “O Corvo”, “The Hunger”, “Nosferatu”.

5. Caminhadas noturnas discutindo Nietzsche sem ter lido Nietzsche.

6. A tribo: se encontrava sem combinar; a cidade conspirava.

Era um movimento emocional, quase ritualístico.

---

🌒 3. Anos 1990 — A mutação para o Gótico

Quando chegam os 90, o Dark amadurece. Larga parte do punk, assume uma estética mais teatral e abraça o misticismo. O termo “gótico” se consolida.

Os pilares do gótico 90

• Maquiagem pesada.

• Ternos e sobretudos longos (aquele que sua mãe costurou!).

• Simbolismo: ankh, crucifixos, caveiras discretas.

• Anéis vampíricos

• A melancolia deixa de ser fraqueza: vira estilo de vida.

As bandas do altar gótico

• The Cure (rainha-mãe do movimento inteiro).

• Clan of Xymox.

• London After Midnight.

• The Mission.

• Type O Negative (para os iniciantes em trevas do metal).

Aqui no Brasil a cena se fortalece:

• Madame Satã (Bexiga) — templo máximo.

• Espaço Retrô, Santa Cecília — clássico.

• Fofinho Rock Club, Belém — garagem pura.

• Aeroanta, Dama Xoc, Carbono 14.

Se você passasse pela Augusta num domingo cedo, veria vampiros desorientados indo embora enquanto as senhoras iam para a missa na igreja da Consolação. Um ecossistema perfeito.

---

🌘 4. Tribos Urbanas — A necessidade humana de pertencer

O Dark/Gótico não era só música. Era pertencimento.

Para muitos jovens — vindos da periferia, de famílias partidas, de escolas opressoras, de bairros onde pagode e samba eram regra — o preto era uma forma de existir no mundo.

Os encontros eram míticos:

• Cemitérios (não para cultos, mas porque eram silenciosos e tinham clima).

• Becos da Paulista.

• Madrugadas eternas na Praça Roosevelt.

• Conversas sobre a vida, o universo e o nada, enquanto um hot-dog da Augusta segurava a ressaca emocional.

• Caminhadas sobre a madrugada nas assustadoras ruas do Centro Velho de São Paulo (Rua São Bento, Rua Direita, XV de Novembro e vale do Anhangabaú entre outras).

• Zanzar sob a luz da Lua em noites de inverno paulistana.

• Estações ferroviárias CBTU fechadas, aguardando a abertura e o primeiro trem.

Quem viveu sabe: era liberdade em sua forma mais artesanal.

---

🌑 5. A Estética Hacker — o paralelo com o Mainframe

Como Bellacosa Mainframe exige:

O movimento Dark/Gótico tem uma lógica parecida com o mundo mainframe:

• Poucos entendem.

• Muitos falam sem saber.

• Há uma estética própria, fechada, ritualística.

• Você precisa dos velhos mestres para ser iniciado.

• Existe documentação, mas ela é esparsa, oral, perdida em zines e memórias.

• Quem faz parte… reconhece o outro no escuro.

Dark/Gótico é, essencialmente, um RACF Group invisível: só entra quem conhece a senha emocional.

---

🌑 6. Curiosidades (Easter Eggs Noturnos)

• O perfume favorito dos góticos paulistanos 90 era o Kaiak preto ou o Malbec — mesmo sabendo que a aura deveria ser de mofo poético.

• A maioria dos góticos da época sabia dançar Wave com fluidez, mesmo nunca tendo tido aula.

• O termo “vampirear” significava andar sem destino pela madrugada.

• Boa parte da cena gótica paulista nasceu… nos corredores da Galeria do Rock.

• O movimento era pequeno, mas altamente ramificado: cyber-gótico, vampírico, etéreo, pós-punk, industrial.

---

🌑 7. Conclusão — Ser Dark/Gótico não era moda. Era autobiografia.

O movimento Dark dos 80 e o Gótico dos 90 foram, para milhares de jovens, a escola onde se aprende a ser sensível, inquieto e diferente num mundo que queria todo mundo igual.

Era música, era estética…
Mas era, acima de tudo, um lugar emocional.

E quem viveu sabe:
A noite não era cenário.
Era lar.

E mesmo que hoje sejamos adultos caretas, programadores COBOL com backlogs intermináveis, analistas de sistemas soterrados em JCL…
Dentro de muitos de nós ainda há aquele adolescente andando de preto, ouvindo The Cure num walkman velho, filosofando bobagens às 2 da manhã sob um poste queimado da Vila Alpina.

E isso, meu caro,
é o tipo de coisa que mesmo o tempo não apaga.
🖤🌙

BUGUEI o YOUTUBE: 2002 - 28º Aniversario do Vagner

 Festa em Itatiba, 28º aniversario, o sultão e a família na maior festança da Rua Jose Brunelli Filho... Obrigado meus amigos vocês foram demais, foi uma festa memorável.

🍺🧘 CERVEJAS JAPONESAS & FILOSOFIA ZEN

 

Bellacosa Mainframe aproveitando uma tarde num izakaya e bebendo sapporo

🍺🧘 CERVEJAS JAPONESAS & FILOSOFIA ZEN

Se no Ocidente a cerveja virou barulho, rótulo gritante e hype de fim de semana…
no Japão, cerveja é silêncio que refresca.

Hoje vamos falar de Zen, mas não aquele de camiseta.
O Zen do cotidiano, do gesto simples, do copo frio, da conversa curta.
E sim: cerveja japonesa entende Zen melhor do que muito guru.

---

☸️ O QUE É ZEN (SEM INCENSO, SEM VIAGEM)

Zen vem do Budismo Chan, importado da China e lapidado no Japão.

Tradução Bellacosa:

Zen é fazer o básico muito bem, sem frescura.

Nada de excesso.
Nada de enfeite inútil.
Nada de “olha como sou diferente”.

Se isso não lembra mainframe… você nunca viu um JCL limpo.

---

Cervejas japonesas sapporo, asahi, kirin, suntory

🍺 A CERVEJA JAPONESA É ZEN POR NATUREZA

As grandes cervejas japonesas (Sapporo, Asahi, Kirin, Suntory):

✔ não são doces
✔ não são exageradamente amargas
✔ não têm aromas espalhafatosos
✔ não tentam “te surpreender”

Elas apenas:

existem, cumprem seu papel e não atrapalham a refeição

Isso é Zen líquido.

---

🧠 PRINCÍPIOS ZEN APLICADOS À CERVEJA

🪨 1. Wabi-Sabi – Beleza na simplicidade

Wabi-Sabi valoriza o simples, o discreto, o imperfeito.

🍺 Uma Sapporo gelada não tenta ser memorável.
Ela tenta ser correta.

Assim como:

• um batch que roda todo dia

• um sistema que ninguém comenta porque nunca cai

---

🌊 2. Ma (間) – O espaço entre as coisas

No Zen, o vazio importa tanto quanto o cheio.

Na cerveja japonesa:

• sabor leve

• final limpo

• espaço para a comida

• espaço para a conversa

Não ocupa tudo.
Não grita no paladar.

🍺 É a cerveja que respeita o silêncio entre um gole e outro.

---

🔁 3. Repetição consciente

Zen é repetir até ficar simples.

Cervejas japonesas são feitas para:
✔ beber várias
✔ em vários dias
✔ em qualquer estação

Sem cansar.

Mainframe feelings:

“esse sistema tá aí há 20 anos e ninguém mexe”.

---

🍜 IZAKAYA = TEMPLO ZEN DISFARÇADO

A izakaya japonesa não é bar.
É um ritual social.

🍺 cerveja
🍢 petiscos
🗣️ conversa baixa
🧠 sem pressa

Ninguém vai para “encher a cara”.
Vai para descomprimir a mente.

Zen puro.

---

🎌 CERVEJAS & PERSONALIDADE ZEN

🍺 Sapporo
➡️ Zen do norte
➡️ fria, limpa, silenciosa

🍺 Asahi Super Dry
➡️ Zen urbano
➡️ seca, rápida, eficiente

🍺 Kirin Lager
➡️ Zen tradicional
➡️ maltada, clássica, conservadora

🍺 Suntory Premium Malts
➡️ Zen estético
➡️ mais aromática, mas controlada

Cada uma é um caminho (Do).

---

🧠 EASTER EGGS CULTURAIS

🍺 No Japão, beber em silêncio não é estranho
🍺 Espuma excessiva é vista como desleixo
🍺 O copo sempre importa
🍺 A cerveja acompanha, não lidera

👉 Diferente do Ocidente, onde a cerveja quer ser protagonista.

---

💬 COMENTÁRIO BELLACOSA

Cerveja japonesa me lembra mainframe porque:

• ninguém elogia quando funciona

• todo mundo reclama quando falta

• existe para sustentar o sistema, não para aparecer

Zen é isso:

fazer bem, sem aplauso

---

🏁 CONCLUSÃO – ZEN NÃO É MODA

Cerveja japonesa não quer likes.
Quer continuidade.

É a cerveja de quem:
✔ já correu muito
✔ já viu hype morrer
✔ prefere estabilidade a barulho

🍺🧘
Beber uma Sapporo é um koan líquido:

“Se a cerveja não chama atenção… ela cumpriu sua função?”

---

📦 SMP/E for z/OS – SYSMOD Packaging

Bellacosa Mainframe apresenta smp/e sysmod packaging

📦 SMP/E for z/OS – SYSMOD Packaging

Entendendo MCS e técnicas de empacotamento sem dor de cabeça

---

🧠 Ideia central (em uma frase)

SYSMOD = conteúdo + instruções (MCS)
O como, onde e quando instalar é decidido pelas MCS.

---

🧩 O que existe dentro de um SYSMOD?

Todo SYSMOD tem duas coisas:

1. Texto de modificação

   • módulos

   • macros

   • source

   • dados

   • HFS / JAR

2. MCS – Modification Control Statements

   • instruções para o SMP/E

   • dizem onde, quando e em que ordem instalar

📌 Durante o RECEIVE, o SMP/E:

• lê primeiro as MCS

• grava tudo no SMPPTS

• cada SYSMOD vira uma MCS entry

---

🧱 Tipos de elementos em DLIB / TLIB

Tipo	O que é
Module	Código compilado/ligado
Macro	Fonte reutilizável
Source	Código fonte
Data	CLIST, PARM, PROC etc
HFS	Arquivos Unix
JAR	Java Archive

---

🧾 Regras básicas das MCS (cai em prova)

• Todas começam com ++

• Colunas 1–2 → ++

• Terminam com ponto (.)

• Podem continuar linha se não houver ponto antes da coluna 73

• Colunas 73–80 são ignoradas

---

🪪 HEADER e identificação do SYSMOD

++HEADER

• identifica o tipo do SYSMOD

• define o SYSMOD-ID

Tipos de SYSMOD

Tipo	Para quê
FUNCTION	Introduz produto
PTF	Correção testada
APAR	Correção de problema
USERMOD	Correção local

---

🧬 FMID — quem “é dono” do código

• FMID = Function Modification ID

• 7 caracteres

• identifica a função dona do elemento

• em FUNCTION, o FMID é o próprio SYSMOD-ID

📌 Todo SYSMOD exceto base FUNCTION usa FMID no ++VER.

---

🔗 ++VER — relacionamento e dependências

O ++VER é o cérebro da compatibilidade

Regras:

• Obrigatório

• Deve vir logo após o HEADER

• Define:

  • release suportado (SREL)

  • dependências

  • pré-requisitos

  • co-requisitos

  • supersedes

Operandos importantes

Operando	Função
SREL	Release do sistema
FMID	Função dona
PRE	Pré-requisito
REQ	Co-requisito
SUP	Supersede

---

🚦 ++HOLD — bloqueios controlados

Existem 3 tipos:

Tipo	Quando usar
ERROR	PTF com erro
SYSTEM	Ação manual necessária
USER	Regra local

📌 HOLD impede APPLY/ACCEPT até ser resolvido
📌 Pode vir no SYSMOD ou em HOLDDATA separado

---

🏗️ MCS estruturais – como o sistema é montado

++JCLIN

• descreve como o load module é ligado

• não executa, apenas é analisado

• grava estrutura no TZONE

Sem JCLIN → SMP/E não sabe reconstruir load modules.

---

🧩 MCS de elemento (o que será instalado)

MCS	O que instala
++MOD	Módulo
++SRC	Source
++MAC	Macro
++DATA	Dados
++HFS	Arquivo Unix
++JAR	JAR inteiro
++ZAP	Patch binário
++SRCUPD	Update de source
++MACUPD	Update de macro
++JARUPD	Update parcial de JAR

📌 ZAP / UPD = alteração parcial
📌 DATA / HFS = sempre substituição total

---

☕ JAR no SMP/E (pegadinha comum)

• ++JAR → substitui o JAR inteiro

• ++JARUPD → atualiza arquivos internos

• SMP/E usa comandos do JDK (jar x / jar u)

---

📦 Técnicas de empacotamento SYSMOD

Como o conteúdo chega até o SMP/E

1️⃣ Relative File (tape)

📼 Clássico IBM

• MCS em um arquivo

• elementos em arquivos seguintes

• usa RELFILE

✔️ Muito usado em FUNCTION SYSMOD

---

2️⃣ Inline

📄 Tudo junto

• MCS + conteúdo no mesmo arquivo

• registros fixos de 80 bytes

• simples, direto

⚠️ Dados variáveis precisam de GIMDTS

---

3️⃣ Indirect Library

📚 USERMOD raiz

• MCS no SMPPTS

• conteúdo fica fora (PDS indicado no APPLY)

• usa TXLIB, LKLIB

✔️ Ideal para USERMOD

---

4️⃣ GIMZIP Archive

🌐 Moderno / rede

• arquivo compactado no HFS

• inclui:

  • MCS

  • elementos

  • HOLDDATA

• usa:

  • GIMZIP

  • GIMUNZIP

  • RECEIVE FROMNETWORK

✔️ Base do Shopz / Internet delivery

---

❌ “What’s wrong with this picture?” (clássico de prova)

Erros comuns:

1. ++MOD não é o último MCS

2. Inline com RELFILE

3. FMID ausente

4. Falta ponto final

5. SREL inválido (2038 ≠ Z038)

---

🧠 Resumo final (para memorizar)

🔑 RECEIVE lê MCS
🔑 APPLY instala no target
🔑 ACCEPT congela no DLIB
🔑 ++VER controla dependências
🔑 JCLIN explica como montar
🔑 Packaging define onde está o conteúdo