Buff e Debuff

 

☕ BUFF & DEBUFF

Quando a vida roda com ou sem prioridade

Tem termos que a gente aprende jogando videogame, assistindo anime… e quando percebe, está usando no trabalho, na vida e até no mainframe. Buff e Debuff são dois desses conceitos mágicos que escaparam do mundo dos RPGs e viraram filosofia prática do dia a dia.

---

🎮 Origem: dos dados de RPG ao pixel

Buff e debuff nascem lá atrás, no RPG de mesa (Dungeons & Dragons, anos 70).

• Buff: efeito positivo temporário (força +10, defesa +20, velocidade extra).

• Debuff: efeito negativo (veneno, lentidão, confusão, medo).

Quando os videogames chegaram, isso virou regra:

• Final Fantasy

• Dragon Quest

• Chrono Trigger

• MMORPGs como Ragnarok, WoW, Lineage

No Japão, o conceito foi absorvido com gosto — porque combina com estratégia, disciplina e preparação.

---

📺 Animes: o buff virou roteiro

Nos animes, buff e debuff deixaram de ser só mecânica e viraram narrativa.

Exemplos clássicos:

• Dragon Ball → Kaioken, Super Saiyajin (BUFF MONSTRUOSO).

• Naruto → modos Sennin, selos amaldiçoados (buff com debuff embutido).

• Bleach → Bankai (buff de alto risco).

• Isekai → status screen, skills passivas, debuffs malditos.

Easter egg clássico:
Todo buff poderoso cobra um preço.
Todo debuff forte ensina humildade.

---

🖥️ Tradução Bellacosa Mainframe

No meu mundo:

• Buff = prioridade alta no JES2

• Debuff = CPU contention às 10h da manhã

Exemplos práticos:

• Um sistema bem tunado → BUFF

• Um JCL mal escrito → DEBUFF

• Índice errado no DB2 → debuff permanente

• Cache quente, I/O afinado → buff passivo invisível

Na IA?

• Prompt bem feito → buff cognitivo

• Dados ruins → debuff silencioso

---

🧠 Impacto cultural

Buff/debuff moldaram como:

• pensamos estratégia,

• aceitamos limites,

• entendemos consequências.

No Japão, isso conversa com:

• ikigai (quando seus buffs fazem sentido),

• shikata ga nai (aceitar debuffs inevitáveis),

• kintsugi (transformar debuff em aprendizado).

---

🥚 Curiosidades & easter eggs

• Muitos jogos escondem buffs secretos por comportamento, não por item.

• Alguns debuffs só aparecem se o jogador for ganancioso.

• Em RPGs antigos, status “confusão” era mais perigoso que morte.

Na vida também.

---

🧓 Nostalgia

Quem viveu os anos 80 e 90 lembra:

• status em tela preta,

• números piscando,

• música 8-bit avisando perigo.

Hoje a gente chama isso de:

• burnout (debuff),

• férias (buff temporário),

• experiência acumulada (buff permanente).

---

☕ Comentário final do El Jefe

A vida é um RPG mal documentado.

Você não escolhe todos os debuffs,
mas escolhe como se prepara.

• Estudo é buff.

• Paciência é buff.

• Curiosidade é buff raro.

E reclamar demais…
bom, isso é debuff empilhável.

☕
No fim, seja no anime, no game, no mainframe ou na IA:

vence quem sabe gerenciar status.

 

Bellacosa Mainframe apresenta Suporte a Produção

☕🖥️ Suporte à Produção Mainframe — o coração que mantém o z/OS batendo 

Se desenvolvimento é o cérebro, Suporte à Produção Mainframe é o sistema nervoso central do ambiente z/OS. É quem sente a dor antes do usuário ligar, quem age antes do SLA estourar e quem garante que o batch das 23h termine antes do café esfriar ☕.

Vamos destrinchar esse tema com história, funcionamento, aplicações práticas, dicas de guerra, curiosidades, easter eggs e aquela fofoquice técnica que só mainframer raiz conhece.

---

🕰️ Origem & História — de Operador de Sala ao Analista de Produção

Nos primórdios do mainframe:

• Existia a sala de máquinas

• Operadores ficavam de olho em luzes piscando, fitas rodando e impressoras cantando

• Um abend era quase um evento social 😅

Com a evolução:

• Chegaram MVS, JES2, SDSF, CICS online

• Depois z/OS, DB2, MQ, WebSphere, Integration Bus

• E o operador virou Analista de Suporte à Produção, com visão técnica, analítica e estratégica

👉 Hoje, Suporte à Produção não é “apagar incêndio”, é prevenção, análise e controle do ecossistema.

---

🎯 O que é Suporte à Produção Mainframe?

É a área responsável por:

• Acompanhar processamento batch e online

• Analisar incidentes, falhas e degradação

• Atuar em eventos críticos de produção

• Garantir disponibilidade, performance e integridade

• Usar ferramentas do z/OS para diagnóstico rápido e preciso

💡 Resumo Bellacosa:

Suporte à Produção é quem garante que o sistema funcione mesmo quando tudo conspira contra.

---

🎓 O que deve aprender para trabalhar em Suporte à Produção Mainframe

Esse programa de capacitação é praticamente um manual de sobrevivência do ambiente produtivo IBM Mainframe.

📚 Estrutura Geral

• Artigos

• Exercicios

• Videos

• Manuais IBM

👉 Ideal para quem quer pensar como Produção, não só executar comandos.

---

🧠 Objetivo Real (o que ninguém fala no folder)

Além do texto bonito, o curso prepara o aluno para:

• Tomar decisão sob pressão

• Escolher a melhor solução, não a mais óbvia

• Entender impacto sistêmico

• Dialogar com desenvolvimento, infraestrutura, segurança e negócio

💬 Frase clássica de produção:

“Pode até funcionar… mas em produção é outra história.”

---

👥 Público-Alvo (quem sobrevive bem nesse mundo)

• Profissionais de TI

• Operadores de Mainframe

• Analistas em transição para Produção

• Quem já cansou de ouvir:

  “Na homologação funcionou…”

📌 Pré-requisitos

• TSO/ISPF

• SDSF

• Noções de z/OS

• Inglês básico (sim, mensagem de erro não vem em português 😄)

---

🧩 Estrutura Curricular — o arsenal do Suporte à Produção

Vamos ao mapa das armas:

🖥️ z/OS

• JES2, spool, jobs, STCs

• WTOR, WTO, mensagens

• Performance, datasets, enqueues

• Easter egg: quem nunca decorou mensagem $HASP?

---

🧠 CICS

• Regiões online

• Transações travadas

• Dumps, abends, filas

• Curiosidade: CICS raramente “cai”… ele se defende

---

📬 MQ

• Filas cheias

• Mensagens presas

• Canais parados

• Dica de ouro: produção ama fila vazia e canal ativo

---

🔌 Integration Bus (Broker)

• Integração entre mundos

• Mensagens XML/JSON

• Transformações e rotas

• Fofoquice: quando quebra, ninguém sabe de quem é a culpa 😅

---

🧪 REXX

• Automação de tarefas

• Scripts de monitoramento

• Ações rápidas em incidentes

• Easter egg raiz: REXX salva madrugada!

---

🗄️ DB2 – Utilitários

• REORG, RUNSTATS, COPY

• Locks, deadlocks

• Espaço e performance

• Dica Bellacosa: DB2 lento quase sempre avisa antes

---

🌐 WebSphere / Servidores de Aplicação

• Acesso remoto

• Integração web

• Monitoramento de serviços

• Curiosidade: quando o web cai, o mainframe “leva a culpa”

---

🔍 Funcionamento na Prática — um dia típico de Produção

1. Batch inicia

2. Job abenda

3. SLA começa a gritar

4. SDSF aberto

5. Mensagem analisada

6. Dataset bloqueado

7. Lock liberado

8. Job restartado

9. Negócio segue

10. Usuário nem ficou sabendo 😎

👉 Isso é Suporte à Produção bem feito.

---

💡 Dicas de Ouro (nível Bellacosa Mainframe)

✔️ Aprenda a ler mensagens, não só copiar
✔️ Conheça o impacto do comando antes de executar
✔️ Documente tudo (memória falha às 3h da manhã)
✔️ Produção exige calma, método e sangue frio
✔️ O melhor incidente é o que não vira chamado

---

🥚 Easter Eggs & Curiosidades

• Todo ambiente tem um job “maldito”

• Sempre existe um STC que ninguém sabe para que serve

• Produção aprende mais em 1 incidente do que em 10 cursos

• O melhor elogio:

  “Nem percebemos que deu problema.”

---

☕ Conclusão Bellacosa Mainframe

O Suporte à Produção Mainframe não é apenas uma função — é uma mentalidade.

É entender:

• Tecnologia

• Processo

• Negócio

• Risco

• Responsabilidade

Quem passa por Produção:

• Vira profissional mais completo

• Aprende a pensar grande

• Ganha respeito técnico

📌 Em resumo:

Se o mainframe é o coração da empresa,
Suporte à Produção é quem garante que ele nunca pare de bater.

SMP/E for z/OS Workshop : BUILDMCS, LINK MODULE e LINK LMODS

 

Bellacosa Mainframe apresenta SMP/E buildmcs link lmods e module

SMP/E for z/OS Workshop

BUILDMCS, LINK MODULE e LINK LMODS

Quando o SMP/E deixa de ser manutenção e vira engenharia de produto

Até agora, no mundo SMP/E, falamos muito de rotina operacional:
RECEIVE, APPLY, ACCEPT, RESTORE.
O famoso arroz com feijão do dia a dia.

Mas existe um outro SMP/E.
Menos usado.
Mais poderoso.
Mais perigoso se mal compreendido.

Hoje entramos no território de product build, onde aparecem três comandos que não são para iniciantes:

• BUILDMCS

• LINK MODULE

• LINK LMODS

Aqui o SMP/E deixa de ser só manutenção e passa a ser engenharia reversa, migração e reconstrução de produtos.

---

SMP/E e a visão estrutural do z/OS

O SMP/E enxerga o z/OS como uma hierarquia:

• 🔹 Elementos simples (SRC, MAC, MOD, PARM)

• 🔹 Objetos intermediários (OBJ, módulos)

• 🔹 Estruturas complexas (LMODs)

• 🔹 Bibliotecas do sistema (target libraries)

Tanto o APPLY quanto os processos de geração de produto fazem a mesma coisa no fundo:

Pegam módulos, macros, source e dados
e combinam tudo para gerar load modules e bibliotecas executáveis

O segredo está em como o SMP/E entende essa estrutura:
👉 entries e subentries no CSI

---

Revisão rápida das principais subentries (a base de tudo)

🔹 DISTLIB=

Aponta para a distribution library
(cópia oficial, aceita, segura)

🔹 FMID=

Define o nível funcional

Quem é o dono original do elemento

🔹 RMID / UMID=

Definem o nível de serviço

Última substituição e atualizações

🔹 SYSLIB=

Usado por SRC, MAC, DATA, HFS
Define o DDNAME da target library

🔹 LMOD=

Usado em MODULE entries
Direciona o SMP/E para a estrutura do load module

Sem entender isso, BUILDMCS vira magia negra.

---

Distribution Zone: conteúdo sem estrutura

Um ponto crítico que muita gente erra:

Na DZONE não existe estrutura de LMOD

Na distribution zone:

• Existem MOD entries

• Não existem LMOD= subentries

• O foco é conteúdo, não link-edit

A estrutura só nasce no target, durante APPLY, GENERATE ou LINK.

---

BUILDMCS – o “clonar produto” do SMP/E

O que é o BUILDMCS?

O BUILDMCS analisa um target zone ou distribution zone
e gera um SYSMOD funcional completo, contendo:

• ++FUNCTION

• ++MOD, ++MAC, ++SRC, ++PARM, ++HFS

• ++JCLIN completo

• FROMDS apontando para as DLIBs

📦 Resultado:

Um SYSMOD portátil, capaz de reinstalar um produto inteiro em outro ambiente SMP/E

---

Para que isso existe no mundo real?

Cenários clássicos:

• Migração de produto entre ambientes

• Criação de novo CSI

• Consolidação de sistemas

• Produto sem mais mídia oficial

• Ambientes isolados (sem internet, sem Shopz)

BUILDMCS cria uma imagem funcional completa do produto, incluindo:

• Função

• Serviço

• Usermods já aplicados

---

O que o BUILDMCS NÃO faz

🚫 Não altera o ambiente original
🚫 Não aplica nem aceita nada
🚫 Não “adivinha” dependências externas

Ele fotografa o estado atual do produto.

---

Como o BUILDMCS funciona por dentro

1️⃣ Analisa o zone (T ou D)
2️⃣ Reconstrói MCS a partir do CSI
3️⃣ Usa FROMDS para apontar para DLIBs
4️⃣ Gera SYSMOD superseding
5️⃣ Grava tudo no SMPPUNCH

Depois disso:

RECEIVE
APPLY
ACCEPT

em outro ambiente.

---

Relatórios gerados pelo BUILDMCS

BUILDMCS não é silencioso. Ele gera:

📄 Function Summary Report

• FMIDs processados

• SYSMODs substituídos

📄 Entry Summary Report

• Todos os elementos do FMID

• MODs, LMODs, DDDEFs

📄 Subentry Summary Report

• Detalhe fino de cada entry

Se você não leu esses relatórios, você não sabe o que copiou.

---

⚠️ Restrições do BUILDMCS (a parte que cai em produção)

BUILDMCS não é para todo produto.

Problemas aparecem quando existem:

❌ Load modules compartilhados

Um LMOD com módulos de mais de um produto

❌ Elementos comuns

Mesmo nome e tipo fornecido por produtos diferentes

❌ VERSION, ASSEM, PREFIX

Essas operações não são recriadas

❌ Informações ausentes no Target Zone

• LEPARM

• ALIAS

• DALIAS

Resultado?
👉 SYSMOD gerado incompleto ou incorreto

---

LINK MODULE – resolvendo dependência entre target zones

Agora imagine isso:

• Produto A em TZONE1

• Produto B em TZONE2

• Um LMOD precisa de módulos dos dois

Sem reinstalar nada.

👉 LINK MODULE resolve isso

---

O que o LINK MODULE faz?

• Reexecuta o link-edit

• Inclui módulos faltantes

• Atualiza ambos os target zones

• Cria relacionamento cruzado (TIEDTO)

Tudo isso sem APPLY, sem ACCEPT.

---

Como o SMP/E documenta isso?

Após o LINK MODULE:

• XZMODP no LMOD que foi relinkado

• XZLMODP nos módulos envolvidos

• TIEDTO nos dois target zones

Isso garante que o SMP/E:

• Saiba da dependência

• Avise (ou relinke automaticamente) no futuro

---

XZLINK – avisar ou agir?

No TIEDTO ZONE:

• XZLINK(DEFERRED)
  👉 Apenas avisa possível inconsistência

• XZLINK(AUTOMATIC)
  👉 SMP/E relinka automaticamente

Escolha errada aqui = surpresa em manutenção futura.

---

LINK LMODS – o REPORT CALLIBS que deu certo

O LINK LMODS substitui o antigo REPORT CALLIBS.

Ele:

• Identifica LMODs por nome ou CALLIBS

• Localiza todos os módulos

• Executa link-edit direto nas target libraries

• Tem CHECK mode

• Tenta recuperação automática (compress + retry)

É APPLY sem SYSMOD.

---

Resumo Bellacosa Mainframe

Comando	Papel
BUILDMCS	Clona um produto
LINK MODULE	Resolve dependência entre zones
LINK LMODS	Relinka LMODs diretamente

---

Frase final (estilo Bellacosa)

RECEIVE instala mídia.
APPLY constrói código.
ACCEPT oficializa.
RESTORE ensina humildade.
BUILDMCS revela quem realmente entende SMP/E.

No próximo módulo, entramos em LIST e REPORT — onde o SMP/E finalmente começa a contar a verdade sobre o seu sistema.

 

Bellacosa Mainframe apresenta JCL Job Control Language

☕🔥 JCL & Produção Batch Mainframe — a engenharia silenciosa que move bilhões 

Se você já otimizou STEP para caber na janela, já analisou RC 0004 com cara de 0012, já salvou processamento crítico com um COND= bem colocado, então este texto não é introdutório.
É JCL raiz, técnico, com cheiro de CPD, café requentado e responsabilidade financeira.

---

🕰️ Origem & História — por que o JCL ainda governa o mundo

O JCL (Job Control Language) nasce junto com o conceito de processamento em lote nos grandes centros de dados, quando:

• Processar tudo “online” era inviável

• O custo de CPU precisava ser controlado

• O erro precisava ser detectável, tratável e auditável

Enquanto linguagens vêm e vão, o JCL ficou porque:

• É determinístico

• É declarativo

• É governável

• É auditável

☕ Verdade histórica:

Toda fintech moderna ainda depende de batch — só não admite.

---

🏦 Por que bancos, telecom e gigantes globais usam Mainframe

Empresas que processam milhões de transações críticas exigem:

• Alta disponibilidade (24x7)

• Integridade absoluta

• Escalabilidade previsível

• Segurança nativa

• Throughput sob pico

A Plataforma IBM Mainframe entrega:

• Sysplex

• Parallel Sysplex

• z/OS

• DB2, CICS, MQ

• RACF, SMF, RMF

🔥 El Jefe truth:

Cloud escala. Mainframe sustenta.

---

🧠 JCL não é script — é contrato operacional

JCL define:

• O que roda

• Quando roda

• Com quais recursos

• Com quais dados

• O que acontece se falhar

Ele não executa lógica de negócio.
Ele orquestra o sistema operacional.

📌 Exemplo clássico:

//STEP01 EXEC PGM=PROG01,COND=(4,LT)
//DD01  DD DSN=BASE.DADOS.ENTRADA,DISP=SHR

☕ Comentário ácido:

JCL errado não falha — impacta.

---

⚙️ Funcionamento do Processamento Batch

Fluxo real:

1. Job submetido

2. JES valida sintaxe

3. Initiator seleciona

4. Recursos alocados

5. Programas executam

6. RC avaliados

7. Próximo STEP decide

8. Output gerado

9. SLA confirmado ou perdido

🔥 Veterano sabe:

O problema raramente está no STEP que abendou.

---

🧩 Ecossistema Operacional — as ferramentas de poder

🧑‍💻 TSO — o shell do z/OS

• Execução direta

• Diagnóstico rápido

• REXX, CLIST, comandos

☕ Curiosidade:

Quem domina TSO resolve problema sem ticket.

---

🗂️ ISPF/PDF — produtividade industrial

• Editor poderoso

• Gestão de datasets

• Browse inteligente

• Macros

🔥 Easter egg:

PF7 e PF8 são memória muscular.

---

📊 SDSF — o raio-X da produção

• Jobs

• STCs

• Spool

• Syslog

• Comandos

📌 Uso clássico:

SDSF DA / ST / H

☕ Verdade dura:

SDSF é onde a verdade aparece.

---

🧪 JCL na prática — decisões de veterano

COND vs IF/THEN/ELSE

• COND = simples e perigoso

• IF/THEN = legível e controlável

🔥 Regra de produção:

COND errado roda STEP que não deveria.

---

Alocação de Recursos

• DISP

• SPACE

• UNIT

• VOL

☕ Fofoquice técnica:

DISP=SHR mal usado já derrubou banco.

---

Tratamento de Erros

• RC esperado ≠ sucesso

• RC aceitável ≠ erro

• Abend ≠ falha total

📌 Exemplo:

// IF (STEP01.RC <= 4) THEN

---

🛠️ Utilitários do Sistema — os bastidores

• IEBGENER

• IDCAMS

• SORT / ICETOOL

• IEBCOPY

• DFSORT

🔥 Veterano:

Quem domina utilitário domina batch.

---

🧠 Lógica Estruturada aplicada ao Batch

Mesmo sem “programar”:

• Sequência

• Decisão

• Repetição (simulada)

• Modularização por STEP

☕ Comentário ácido:

JCL ruim é código espaguete sem goto.

---

🧨 Atividades Operacionais & de Análise

Produção batch exige:

• Leitura de mensagens

• Análise de dumps

• Correlação entre jobs

• Impacto em cadeia

• Comunicação com negócio

🔥 Verdade cruel:

Produção não tem replay.

---

🥚 Easter Eggs & Curiosidades do Batch

• Todo ambiente tem um job “imortal”

• Sempre existe um dataset “temporário” de 10 anos

• O maior medo é:

  “Rodou fora da janela…”

• RC 0000 nem sempre é vitória

---

☕🔥 Conclusão — Manifesto El Jefe Batch

JCL não é:

• Legado morto

• Linguagem simples

• Detalhe operacional

JCL é:

• Coluna vertebral do processamento corporativo

• Contrato de execução

• Instrumento de controle de risco

☕🔥 Quem domina JCL,
não escreve jobs —
governa o processamento de dados.

Se quiser, posso:

• Criar labs de produção real

• Montar checklist de análise de jobs

• Criar guia JCL para veteranos

• Produzir versão acadêmica ou institucional

• Montar trilha Batch + JCL + SDSF + RACF

É só chamar.

 

Bellacosa Mainframe e a lei da responsabilidade

☕ Lei da Responsabilidade

ou: quem deu o SUBMIT é dono do JOB

Vou falar em primeira pessoa, porque essa lei eu não aprendi em livro — eu aprendi na marra, entre JCL mal formatado, JOB em ABEND e decisões da vida que também não tinham //SYSOUT=* pra revisar depois.

---

📜 Origem – de onde vem essa lei?

A Lei da Responsabilidade nasce da mesma matriz que:

• o estoicismo (assuma o que depende de você),

• a ética clássica,

• e o famoso “cada ação gera consequência”.

No Japão, ela conversa muito bem com conceitos como giri (dever moral), sekinin (責任 – responsabilidade) e até com o mottainai: não desperdiçar oportunidades nem ações.

No mainframe?
Ela está implícita desde o primeiro dia:

“Quem submeteu o JOB é responsável pelo resultado.”

Simples. Brutal. Justo.

---

🧠 O que essa lei significa?

Significa entender que:

• escolhas têm efeitos,

• omissões também são escolhas,

• e não existe rollback da vida.

Na TI e na vida:

• Se deu certo → mérito.

• Se deu errado → aprendizado (ou ABEND).

Culpar:

• o sistema,

• o colega,

• o tempo,

• o governo,

• Mercúrio retrógrado,

é só uma forma elegante de rodar em WAIT indefinido.

---

🖥️ Tradução Bellacosa Mainframe

• Você escreveu o JCL → você testa.

• Você abriu a regra no RACF → você responde.

• Você fez o DEPLOY sexta à noite → você não some.

Na vida:

• Escolheu o caminho → sustente.

• Falou → arque.

• Prometeu → cumpra.

Responsabilidade é ownership, não culpa.

---

🛠️ Como praticar no dia a dia

• Pare de terceirizar decisões.

• Pare de dizer “não tive escolha”.

• Tenha coragem de dizer: “fui eu”.

Dica prática:

Antes de qualquer decisão, pergunte:
“Eu topo lidar com a consequência disso?”

Se a resposta for não, não submeta o JOB.

---

🥚 Easter eggs & curiosidades

• Em japonês corporativo, assumir erro rápido aumenta confiança, não diminui.

• Em times maduros, quem assume falhas vira referência.

• No mainframe, os melhores profissionais são os que dizem:
  “deixa comigo” — e ficam até resolver.

---

☕ Fofoquices do El Jefe

Já vi muito “senior” desaparecer quando o batch estourou.
E já vi muito “junior” crescer porque ficou até o último IEC999I virar sucesso.

Responsabilidade constrói reputação silenciosamente.

---

🧭 Como entender de verdade

Não confunda responsabilidade com peso.
Ela é liberdade com consciência.

Quando você assume:

• ganha autonomia,

• ganha respeito,

• ganha paz.

---

🌏 Importância para a vida (e para o Japão)

No Japão, responsabilidade mantém:

• confiança social,

• eficiência coletiva,

• harmonia (wa).

Na vida:

• ela te tira do modo vítima,

• te coloca no modo autor da própria história.

---

🧠 Conclusão Bellacosa

A Lei da Responsabilidade é simples:

Você é o operador do seu próprio sistema.
Se der ABEND, analisa, corrige e segue.

Sem drama.
Sem desculpa.
Sem RESET.

☕
E agora me diga…
você anda assumindo seus JOBs ou só reclamando do spool?

Uma tarde passeando por Leiria

Estamos passeando por um parque delicioso, aproveitando as margens deste ribeirão cheio de patinhos, como bom maníaco por fotos. Nao podia deixar de capturar este pequeno momento.

Esta cidade tem muitos encantos a serem descobertos, possui um  castelo, uma antiga fabrica de papel (parece que foi a primeira de Portugal), um parque com aviao militar, roda d'agua e o patinhos. Muitos patinhos nadando tranquilamente pela ribeira.

SMP/E for z/OS Workshop: Restore

Bellacosa Mainframe apresenta SMP/E Restore

SMP/E for z/OS Workshop

RESTORE: quando o Apply deu ruim e você precisa voltar no tempo (sem desligar a produção)

Se APPLY é instalar e ACCEPT é oficializar, RESTORE é o botão de “desfaz” do SMP/E.
Mas não se engane: RESTORE não é CTRL+Z. Ele exige entendimento profundo de dependências, níveis de serviço e do que está no target versus no distribution.

Vamos destrinchar isso no melhor estilo Bellacosa Mainframe: sem romantismo, com realidade de produção.

---

O que é o comando RESTORE no SMP/E?

O RESTORE permite remover um ou mais SYSMODs aplicados no target, reinstalando o nível existente nos DLIBs (distribution libraries) de volta para as target libraries.

📌 Ponto-chave

RESTORE só funciona para SYSMODs que foram APPLIED e ainda NÃO ACCEPTED.

Na prática:

• Algo foi aplicado

• Quebrou, gerou erro, impacto funcional ou regressão

• Você precisa voltar o código para o último nível aceito

RESTORE entra em ação.

---

Onde o RESTORE atua?

RESTORE é sempre direcionado a um Target Zone:

SET BDY(TZONE)

Esse target zone:

• Identifica as target libraries

• Mapeia qual distribution zone (DZONE) contém o backup válido

• Será atualizado com os metadados corretos após o restore

📦 O SMP/E não inventa código
Ele reinstala exatamente o que está nos DLIBs.

---

O que o RESTORE realmente faz?

Durante o processamento, o SMP/E:

✔ Substitui os elementos do target pelos elementos do DLIB
✔ Reexecuta link-edit se necessário
✔ Copia FMID, RMID e UMID do DZONE para o TZONE
✔ Atualiza o CSI
✔ Remove registros do SYSMOD restaurado (dependendo das opções)

Ou seja:

O target volta a refletir o último nível oficialmente aceito.

---

RESTORE vs APPLY – parecem iguais, mas não são

APPLY	RESTORE
Usa SMPPTS	Usa DLIBs
Entrada: Global Zone + SMPPTS	Entrada: DZONE + DLIBs
Instala novo código	Reinstala código anterior
Avança nível	Retrocede nível

👉 Ambos atualizam Target Libraries e Target Zone, mas com propósitos opostos.

---

Inline JCLIN e SMPCDS: o detalhe que derruba gente experiente

Se o SYSMOD a ser restaurado possui inline JCLIN, o SMP/E precisa do SMPCDS.

Por quê?

Porque o SMPCDS contém:

• Backup da estrutura do TZONE

• Informações necessárias para restaurar corretamente macros, source e datasets

Sem isso, o RESTORE pode:

• Falhar

• Ou deixar o ambiente inconsistente

---

O comando RESTORE na prática

Exemplo básico:

RESTORE 
  SELECT(UP00003)

Operandos importantes

🔹 SELECT (obrigatório)

Define quais SYSMODs você quer remover.

---

🔹 GROUP (a parte traiçoeira)

No RESTORE, o GROUP funciona ao contrário do APPLY.

• APPLY: GROUP busca pré-requisitos ausentes

• RESTORE: GROUP busca SYSMODs que DEPENDEM do selecionado

👉 Se um SYSMOD depende do que você quer remover, ele também precisa ser restaurado.

---

🔹 CHECK (sempre use!)

RESTORE CHECK SELECT(UP00003)

CHECK:

• Não altera nada

• Analisa dependências

• Mostra mensagens do tipo GIM35922I

📌 Dica Bellacosa:

Raramente o primeiro RESTORE CHECK resolve tudo.
Rode, leia os relatórios, ajuste o SELECT, rode de novo.

---

Exemplo clássico de dependências (vida real)

Temos 7 PTFs aplicados:

UP00001
 └─ UP00002
     ├─ UP00003
     │   ├─ UP00005
     │   └─ UP00007
     └─ UP00004
         └─ UP00006

Somente UP00001 foi ACCEPTED.

🎯 Objetivo: restaurar UP00003

Pergunta clássica de prova e produção:

Posso restaurar só o UP00003?

❌ Não.

Você também precisa restaurar:

• UP00005

• UP00007

Porque dependem diretamente dele.

---

Onde descobrir isso sem chutar?

1️⃣ Mensagens SMP/E (ex: GIM35922I)
2️⃣ SYSMOD Status Report
3️⃣ CAUSER SYSMOD SUMMARY REPORT ← o mais importante

Esse relatório explica:

• Por que o RESTORE falhou

• Quais SYSMODs estão bloqueando

• O que falta no SELECT

---

O que o SMP/E remove após um RESTORE bem-sucedido?

Se NOREJECT = OFF:

• Remove entrada do SYSMOD no Global Zone

• Remove MCS do SMPPTS

• Remove SMPTLIBs (se existirem)

⚠️ HOLD DATA NÃO É REMOVIDA

Se NOREJECT = ON:

• Remove apenas APPID do Target Zone

---

RESTORE não é simples (e nunca foi)

RESTORE pode se tornar complexo quando:

• Muitos PTFs aplicados

• DLIB muito atrás do Target

• Cadeias longas de dependência

👉 É comum rodar:

RESTORE CHECK
RESTORE CHECK
RESTORE CHECK

Até fechar todo o quebra-cabeça.

---

Conclusão Bellacosa Mainframe

RESTORE é:

• Uma ferramenta poderosa

• Um salva-produção

• Um teste de maturidade do system programmer

Quem domina RESTORE:
✔ Entende dependências
✔ Entende níveis de serviço
✔ Não entra em pânico quando APPLY quebra

APPLY instala. ACCEPT oficializa. RESTORE ensina humildade.

No próximo módulo, o foco sai do SMP/E operacional e entra no product build — onde o código nasce antes de virar SYSMOD.