Bellacosa Mainframe apresenta o primeiro controle de versão IEBUPDATE

---

🍔💾 Before Git Was Cool

O primeiro controle de versão no mainframe (e por que você já usou sem saber)

Midnight Lunch Edition – para ler entre um batch e outro

Hoje todo mundo fala de Git como se controle de versão tivesse surgido junto com startup, hoodie e café cold brew.
Mas quem viveu (ou herdou) ambiente mainframe sabe: o problema é antigo — e a solução também.

Antes de existir “version control”, já existia controle de mudanças.
E spoiler: o mainframe resolveu isso décadas antes do Git.

---

🏛️ Quando “controle de versão” ainda não tinha nome

Nos anos 60, a pergunta já era a mesma que ecoa hoje nos times DevOps:

• Quem mexeu nesse source?

• Qual versão está em produção?

• Por que ontem funcionava e hoje abenda?

A diferença é que:

• Não existia terminal bonito

• Não existia branch

• Não existia merge

• Existia batch, cartão perfurado e PDS

---

🥇 O verdadeiro pioneiro: IEBUPDTE

📅 Ano de lançamento: 1964
🏭 Fabricante: IBM
🖥️ Ambiente: OS/360

O IEBUPDTE não era vendido como “controle de versão”, mas na prática ele fazia exatamente isso:

👉 Controle estruturado de alterações em código-fonte

---

🧠 O que o IEBUPDTE fazia (na raça)

• Aplicava deltas (ADD / DEL / CHANGE)

• Atualizava membros em PDS

• Permitida reconstrução de versões

• Mantinha histórico dentro do próprio source

• Funcionava 100% batch-first

Exemplo clássico:

./ ADD NAME=PROG1
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. PROG1.
./ ENDUP

Ou removendo código:

./ DEL 000300-000500

📌 Diff e patch antes do diff existir.

---

✅ O que ele fazia bem

✔️ Controle linha a linha
✔️ Reprodutibilidade
✔️ Integração total com o SO
✔️ Auditoria via JCL
✔️ Simplicidade brutal

❌ O que ele não fazia

✖️ Branch
✖️ Merge
✖️ Concorrência elegante
✖️ UX amigável
✖️ Marketing 😅

---

🟠 O primeiro “controle de versão moderno”: SCCS

📅 1972
🏭 Bell Labs (AT&T)

O SCCS (Source Code Control System) não nasceu no mainframe, mas trouxe os conceitos que moldaram tudo depois:

• Check-in / check-out

• Histórico separado do código

• Identificação automática de versão

• Deltas reversíveis

@(#)program.c 1.3

Se você usa Git hoje, agradeça silenciosamente ao SCCS.

---

⚔️ Outros nomes da época (não proprietários)

🟤 CMS UPDATE (VM/CMS)

Um IEBUPDTE interativo.
Simples, direto e extremamente eficiente em ambientes VM.

🟣 RCS (1982)

Evolução do SCCS, mais simples, mais elegante — ainda sem branches decentes.

---

🚫 E os famosos “controladores de biblioteca”

(menção honrosa, sem aprofundar)

• PANVALET

• LIBRARIAN

Eles dominaram o mercado, mas não inventaram o conceito.
Só empacotaram, venderam e deram manual grosso.

---

🥚 Easter Eggs de CPD

🥚 Easter Egg #1
IEBUPDTE é mais parecido com git apply do que com git commit.

🥚 Easter Egg #2
Comentário no COBOL tipo:

* ALTERADO POR CARLOS EM 12/08/1989

➡️ Isso é controle de versão manual.
Herança direta da era pré-ferramenta.

🥚 Easter Egg #3
Controle de versão nasceu batch-first.
CI/CD moderno só está reaprendendo isso.

🥚 Easter Egg #4
Se o histórico está no source, é porque um dia não existia repositório.

---

🧓 Filosofia Bellacosa Mainframe

“O Git não inventou controle de versão.
Ele só colocou uma interface moderna numa ideia que o mainframe já resolvia quando computador ocupava uma sala inteira.”

---

📌 Resumo para guardar no bolso

Ferramenta	Ano	Tipo	Origem
IEBUPDTE	1964	Controle de mudanças	IBM
CMS UPDATE	~1969	Controle de mudanças	IBM
SCCS	1972	Version control formal	Bell Labs
RCS	1982	Version control	Unix

---

🍔 Midnight Lunch Final Thought

Enquanto o mundo discute GitOps, trunk-based e feature flags, o mainframe segue ali, quieto, lembrando:

“Nada disso é novo. Só mudou o hype.”

---

 

Bellacosa Mainframe apresenta Murasaki Shikibu a primeira romancista da historia

📜 Murasaki Shikibu – a mulher que escreveu o primeiro “sistema operacional” da literatura

Antes de existir romance, antes de existir “novel”, antes de existir protagonista com crise existencial…
existiu Murasaki Shikibu.

E não, ela não escreveu qualquer coisa.
Ela escreveu Genji Monogatari (源氏物語) — O Conto de Genji — considerado por muitos historiadores o primeiro romance psicológico da história da humanidade.

Sim.
Enquanto a Europa ainda estava preocupada em não pegar peste, o Japão já estava rodando literatura nível enterprise.

---

Murasaki Shikibu

👘 Quem foi Murasaki Shikibu?

Murasaki Shikibu viveu por volta do ano 978 até cerca de 1014, durante o Período Heian, uma era marcada por refinamento estético, intrigas de corte e poesia como moeda social.

Ela era:

• Dama da corte imperial

• Intelectual autodidata

• Leitora de clássicos chineses (algo raríssimo para mulheres da época)

• Observadora silenciosa da elite japonesa

Curiosidade importante:
“Murasaki Shikibu” não é o nome real dela.

👉 “Murasaki” vem de uma personagem do próprio Genji
👉 “Shikibu” refere-se ao cargo do pai no Ministério dos Ritos

Ou seja:

Ela virou user ID histórico baseado na própria obra.

---

📚 O trabalho: Genji Monogatari

O Conto de Genji não é um livro curto.
São 54 capítulos, centenas de personagens, décadas de eventos e uma profundidade emocional absurda.

O protagonista:

• Hikaru Genji, o “Príncipe Brilhante”

• Belo, educado, poderoso… e profundamente humano

O diferencial?

• Não é uma história de herói

• É uma história de emoções, arrependimentos, impermanência

Nada de final feliz padrão.
Aqui tem debug emocional.

---

🧠 Por que isso foi revolucionário?

Antes de Murasaki:

• Histórias épicas

• Mitológicas

• Religiosas

Depois de Murasaki:

• Pessoas complexas

• Amor não correspondido

• Ciúmes

• Solidão

• Passagem do tempo

Ela escreveu sobre:

• Mulheres esquecidas

• Amores silenciosos

• Relações que não escalam

• A dor de envelhecer

É quase um log de produção da alma humana.

---

🏯 Contexto histórico: a corte Heian

A corte japonesa era:

• Extremamente hierárquica

• Obcecada por aparência

• Governada por etiqueta, poesia e fofoca

Sim, fofoca.

Cartas eram escritas em forma de poema.
Uma escolha errada de palavra podia:

• arruinar reputações

• encerrar relacionamentos

• causar exílio social

Murasaki observava tudo isso em silêncio, como um sysprog cultural, registrando comportamentos.

---

👀 Fofocas & bastidores

📌 Dizem que Murasaki era:

• Reservada

• Crítica

• Pouco impressionada com a corte

Ela escreveu em seu diário críticas diretas a colegas, chamando algumas de:

“superficiais e barulhentas”

Sim, ela era low profile, mas afiada.

📌 Há indícios de que:

• Parte do Genji seja autobiográfica

• Alguns personagens sejam sátiras disfarçadas da corte

Shadow IT literário.

---

🥚 Easter eggs culturais

• O Genji Monogatari influenciou:

  • Mangás

  • Animes

  • Dramas históricos (taiga dramas)

  • Estética do shōjo moderno

• O conceito japonês de mono no aware (a beleza da impermanência)
  👉 foi cristalizado ali

• Muitos clichês de anime:

  • Amores silenciosos

  • Personagens melancólicos

  • Relações que não se resolvem
    têm DNA Genji

---

🧬 Legado

Murasaki Shikibu deixou:

• O primeiro romance psicológico

• Uma nova forma de narrar o humano

• A base emocional da literatura japonesa

Ela provou que:

Observar é tão poderoso quanto agir.

E que:

Histórias mudam o mundo sem fazer barulho.

---

⚙️ Tradução para o mundo mainframe

Murasaki Shikibu era:

• Uma analista funcional da alma

• Uma arquiteta de sistemas emocionais

• Uma escritora que entendia estado, contexto e transição

Seu texto:

• Não força eventos

• Não acelera resoluções

• Respeita o tempo

Como um sistema legado bem projetado, que envelhece com dignidade.

---

☕ Comentário final estilo El Jefe Midnight Lunch

Num mundo que grita, Murasaki escreveu em sussurros.
Num ambiente competitivo, ela observou.
Num sistema rígido, ela criou algo eterno.

Mais de mil anos depois, ainda estamos lendo, adaptando e sentindo.

Isso não é moda.
Isso é arquitetura cultural.

 

Bellacosa Mainframe apresenta IBM SMP/E

🧩 SMP/E + RACF na prática

Onde manutenção encontra segurança (e o auditor sorri)

“Não adianta proteger usuário se qualquer um pode mudar o sistema.”

---

🧠 Por que SMP/E precisa de RACF?

SMP/E controla o código do z/OS.
RACF controla quem pode tocar nesse código.

👉 Separados, são fortes.
👉 Juntos, são governança.

---

🔐 O que exatamente deve ser protegido?

🎯 Alvos críticos

• CSI (Consolidated Software Inventory)

• SMP/E libraries

• Datasets TARGET e DLIB

• JCL de manutenção

• Procedimentos de APPLY/ACCEPT

📌 Quem altera isso altera o sistema inteiro.

---

🧩 Princípio da menor permissão

Não existe:

“Acesso total para facilitar.”

Existe:

• Acesso mínimo

• Temporário

• Auditável

---

🧾 Protegendo o CSI

Recomendação clássica

• DATASET profile no RACF

• UACC=NONE

• ALTER só para sysprog autorizado

• READ para auditoria

📌 CSI é prova histórica.

---

🛡️ Protegendo bibliotecas SMP/E

• SMPTLIB

• SMPMTS

• SMPPTS

• SMPSCDS

👉 Controle separado de produção e teste.

💡 Dica Bellacosa:

“Quem pode escrever no SMPMTS pode quebrar o sistema.”

---

👥 Segregação de funções (SOX friendly)

Função	Permissão
Sysprog	APPLY
Change Mgmt	Aprovar
Auditor	READ
Operação	Executar JCL controlado

📌 Uma pessoa não deve fazer tudo.

---

🔎 Auditoria e rastreabilidade

Auditor pergunta:

• Quem aplicou?

• Quando?

• O quê?

• Por quê?

👉 SMP/E responde
👉 RACF confirma

---

🧪 APPLY CHECK como controle

• APPLY CHECK obrigatório

• Output guardado

• Assinatura de mudança

💡 Dica Bellacosa:

“APPLY CHECK é evidência de controle.”

---

🚨 Cenário de risco real

Sysprog com ALTER irrestrito
USERMOD sem controle
ACCEPT em produção
Auditor encontra

📌 Resultado:

• Não conformidade

• Risco operacional

• Stress garantido

---

🛠️ Boas práticas recomendadas

✔ Perfis RACF específicos
✔ Logging ativo
✔ Revisão periódica
✔ Separação TEST/PROD
✔ Documentação SMP/E

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• RACF mal configurado invalida SMP/E

• Segurança começa no dataset

---

🧾 Comentário final – SMP/E + RACF

RACF protege acesso.
SMP/E protege integridade.
Juntos, protegem o negócio.

🧩🛡️💾🔥

📜 Pedro Malazarte – o “batch job” mais malandro do folclore brasileiro

Bellacosa Mainframe encontra Pedro Malazarte

📜 Pedro Malazarte – o “batch job” mais malandro do folclore brasileiro

Se o folclore brasileiro fosse um data center, Pedro Malazarte seria aquele programa antigo, mal documentado, mas que sempre roda certo — mesmo enganando o operador no meio do processo.

Ele não é forte.
Não é rico.
Não é nobre.

Mas é esperto, irônico e mestre em dar bypass em regra mal escrita.

---

🧭 Origem: de onde saiu esse “job”?

Pedro Malazarte (ou Pedro Malasartes, dependendo da versão) não nasceu exatamente no Brasil.

👉 Sua raiz vem da Europa, principalmente:

• Portugal

• Espanha

• Itália

Ele descende do arquétipo do trickster europeu, como:

• Till Eulenspiegel (Alemanha)

• Bertoldo (Itália)

• Juan Bobo (Espanha)

Quando chega ao Brasil, é recompilado:

• Vira sertanejo

• Vira caipira

• Vira pobre

• Vira sobrevivente

Código importado, customizado para ambiente tropical.

---

📚 História e personalidade

Pedro Malazarte é:

• Um homem simples

• Sem posses

• Sempre à margem do sistema

Mas com uma habilidade rara:

Explorar falhas humanas como se fossem brechas de segurança.

Ele engana:

• Patrões gananciosos

• Fazendeiros exploradores

• Padres hipócritas

• Autoridades arrogantes

Não com força, mas com:

• Ambiguidade

• Ironia

• Leitura literal das ordens

📌 Exemplo clássico:

“Faça exatamente o que eu mandei.”

Pedro faz.
E o sistema quebra.

---

⚙️ Pedro Malazarte no modelo mainframe

Se fosse um sistema, Pedro seria:

• Um programa em COBOL antigo

• Sem IF elegante

• Mas com lógica impecável

Ele usa:

• INPUT mal definido

• REGRA ambígua

• EXPECTATIVA humana falha

Resultado?

• ABEND moral no opressor

• RC=0 para o pobre

---

🥚 Easter eggs do folclore

🥚 Em várias histórias:

• Pedro finge ser burro → engenharia social

• Ele ganha sempre no final → justiça poética

• O poder nunca aprende → loop infinito

🥚 Em algumas versões:

• Ele morre pobre

• Mas deixa todos ricos de lição

🥚 Muitos contos terminam com:

“E Pedro seguiu seu caminho…”

Ou seja:

• O job nunca termina

• Ele apenas muda de ambiente

---

🧠 Curiosidades pouco comentadas

• Monteiro Lobato ajudou a popularizar Malazarte no Brasil

• Ele aparece em:

  • Literatura oral

  • Teatro popular

  • Cordel

  • Cinema nacional

• Mário de Andrade via Malazarte como:

  “O símbolo da inteligência popular brasileira”

• Ele é primo conceitual de:

  • Macunaíma

  • João Grilo (Auto da Compadecida)

  • O malandro carioca

---

🍽️ O que Malazarte “come”?

Não é sobre comida literal.

Ele se alimenta de:

• Desigualdade

• Arrogância

• Abuso de poder

• Falta de clareza

Quanto maior a injustiça,
maior o payload do golpe.

---

💡 Dicas para “ler” Malazarte hoje

• Leia como crítica social

• Observe quem sempre perde

• Perceba que ele não rouba do pobre

• Veja o humor como arma

Pedro não é ladrão.
É auditor informal do sistema.

---

💬 Comentário Bellacosa Mainframe

Pedro Malazarte não quebra o sistema.
Ele prova que o sistema já estava quebrado.

Ele é:

• O teste de stress

• O penetration test social

• O QA não contratado

Num país onde regras sempre pesaram mais para uns do que para outros, Malazarte sobreviveu séculos porque continua atual.

---

🧩 Encerramento – RC cultural

Se você já:

• Seguiu uma regra absurda só para provar um ponto

• Usou a literalidade para expor uma falha

• Sobreviveu com inteligência onde faltava poder

Então…
Você já executou um JOB MALAZARTE sem saber.

RC=0.
SPOOLED COM SUCESSO. ⚙️📜

 

Bellacosa Mainframe fala sobre restart em programa cobol mainframe

🔄 COBOL Batch no Mainframe: Checkpoint, Reprise e o Restart que salva a madrugada

“Batch não cai. Batch desmaia… e você tem que acordar ele do jeito certo.” ☕🧾🕒

No mundo distribuído, o povo reinicia “do zero” e chama isso de solução.
No Mainframe, isso é quase uma confissão de pecado técnico.

Quando dá ruim em batch, a pergunta não é “por que parou?” — isso é assunto pro pós-mortem.
A pergunta certa, ainda na especificação, é:

👉 Como eu reinicio?
👉 De onde eu reinicio?
👉 E o que eu garanto que não vai duplicar / corromper / relançar?

Bem-vindo ao trio de respeito:
✅ checkpoint
✅ reprise (restart)
✅ reposicionamento (arquivo/DB2)

---

🧠 Checkpoint: o “save game” do batch (só que aqui vale dinheiro)

Checkpoint não é “vamos salvar porque sim”. É um ponto de consistência.

Ele serve pra:

• memorizar onde o processamento estava (fase/etapa)

• guardar posições de leitura (arquivos sequenciais, VSAM, cursores/chaves DB2)

• fechar uma unidade lógica consistente (commit/rollback bem amarrado)

• permitir retomada sem retrabalho e sem “efeito duplicado”

📌 Tradução Bellacosa:

Checkpoint é onde você consegue provar pro auditor que não inventou saldo no escuro.

⚠️ O pecado mortal: checkpoint mal posicionado

Checkpoint ruim é pior que nada, porque ele te dá uma falsa sensação de segurança.

Não coloque checkpoint:

• no meio de uma atualização crítica

• antes de terminar uma consistência lógica

• em cada registro “porque sim” (CPU chorando, log estourando, IRLM te olhando feio)

Coloque checkpoint:

• depois de um bloco lógico fechado (ex.: lote de N registros com commit)

• quando “o mundo faz sentido” (estado consistente)

• antes de uma parte custosa, mas não no meio da cirurgia

---

♻️ Reprise (Restart): o batch voltando “com memória”

Reprise é o batch saber voltar sem refazer o que já foi feito e sem duplicar o que não pode duplicar.

Ela é necessária especialmente quando:

• o batch é longo (madrugada inteira)

• tem DB2 update (conta, saldo, lançamento, baixa, contabilização)

• o negócio não aceita “roda de novo e vê no que dá”

• existe risco de duplicidade (dois lançamentos iguais = fogo no parquinho)

📌 Restart não é só “rodar outra vez”.
Restart é retomar a transação do negócio, com rastreabilidade.

---

🧷 Reposicionamento: o detalhe que separa homem de menino

Restart sem reposicionamento é “restart de brincadeira”.

Você precisa voltar exatamente:

• no registro correto do arquivo

• na chave correta do VSAM

• no ponto certo do cursor DB2 (na prática: reiniciar lógica por chave/estado salvo)

🎯 O batch tem que saber:

• qual fase estava executando

• qual registro/chave estava sendo processado

• qual unidade de commit já foi confirmada

• qual parte não pode repetir

---

🧩 Arquitetura clássica de batch com reprise “de respeito”

Um ciclo bem resolvido (a operação agradece):

1. Inicialização / parâmetros

2. Validações

3. Detecta reprise (rodada normal ou restart?)

4. Carrega checkpoint (fase + posição + chaves)

5. Reposiciona entradas (arquivo/DB2)

6. Loop principal

   • regra de negócio

   • atualização (DB2/arquivos)

   • commit por unidade lógica

   • checkpoint em pontos definidos

7. Finalização

8. “Checkpoint final” (término normal)

📌 Easter egg de produção:

Se você não tem “checkpoint final de sucesso”, vai ter madrugada com restart de batch que já terminou — e ninguém acredita até acontecer.

---

🧨 O vilão silencioso: duplicidade

O inferno do batch não é “parar”.
O inferno é parar depois de atualizar metade.

Por isso, todo batch com reprise tem que decidir:

• vou garantir idempotência? (rodar de novo não duplica)

• vou garantir commit controlado? (unidades fechadas)

• vou guardar marcador de processado? (chave/flag/tabela de controle)

✅ Padrões usados:

• Tabela de controle com status por chave/lote

• Commit a cada N registros (N definido por volume, log, tempo)

• Chave de negócio + verificação (“já processei isso?”)

• Writes “safe” (criar saída nova e só no final fazer swap/rename)

---

📂 “Nem todo batch precisa de reprise” (mas todo batch precisa de juízo)

Batch que só:

• lê arquivo

• gera relatório

• faz sorting

• produz uma saída recriável

…muitas vezes reexecutar resolve.

Só que:

• nunca reexecute “por cima” de saída velha sem estratégia

• garanta limpeza/geração atômica (work datasets → output final)

📌 Dica prática:

Use datasets temporários e só “promova” pro nome final no fim. Batch que morre não deixa meia saída fingindo que tá certa.

---

🧾 Dicas Bellacosa de restart que evitam velório

• Checkpoint = fase + posição + contexto. Não guarde só o número do registro; guarde o porquê.

• Mensagem clara no log: “RESTART AT STEP X / KEY Y / FILE POS Z”. Operação ama isso.

• Commit e checkpoint têm que conversar: checkpoint sem commit consistente é cilada.

• Se atualiza DB2, trate o restart como requisito de negócio, não “extra”.

• Testar restart é obrigatório: simule abend no meio e valide se volta certo.

---

☕ Fechando no estilo madrugada

No Mainframe, reprise é arquitetura, checkpoint é disciplina, e restart é respeito.

Batch sem reprise em processo crítico é igual:

“depois eu vejo”
só que o “depois” geralmente é 03:17 com telefone tocando e gente jurando que “nunca aconteceu antes”.

 

Bellacosa Mainframe apresenta product vision com elevator pitch

🧠☕ Product Vision no Estilo Bellacosa Mainframe

Ou: por que até produto moderno precisa de disciplina de mainframe

---

🧭 Pergunta raiz (a.k.a. “JOB card do Produto”)

The most effective Product Vision format uses what methodology?
Resposta curta, direta e sem IF ELSE desnecessário:

👉 Elevator Speech (ou Elevator Pitch)

Agora segura esse commit, porque vamos explicar como um conceito de produto moderno conversa diretamente com a mentalidade do mainframe — com história, fofoca, easter eggs e aquele tempero “El Jefe” ☕💼.

---

🏛️ Origem & História (ou: nada nasce em microserviços)

🎤 Elevator Speech

O Elevator Speech nasce no mundo corporativo americano, décadas atrás, com uma premissa simples:

“Se você tivesse apenas o tempo de um elevador para convencer alguém importante, o que você diria?”

📦 Normalmente: 30 a 60 segundos
📌 Público: executivo, investidor, sponsor, board
🎯 Objetivo: clareza absoluta + impacto imediato

👉 No mundo de Product Vision, ele virou padrão porque:

• Força foco

• Elimina ruído

• Obriga o time a saber o que NÃO é o produto

📢 Mainframe feelings:
É o mesmo princípio de explicar um sistema core bancário em 3 frases antes da diretoria mandar “vamos para o próximo assunto”.

---

🧪 Comparando os formatos (como um bom JCL COMMENT)

❌ Laconic Speech

• Curto demais

• Soa vago

• Parece RACF mal documentado
  📉 “Não dá contexto, só slogan”

❌ Crisp Presentation

• Bom para slides

• Ruim para alinhar visão estratégica

• Vira PowerPoint bonito sem alma
  📉 “Muito SHOW, pouco JOB”

❌ Brief Report

• Denso

• Técnico

• Mata a inspiração
  📉 “É o SMF record do produto”

✅ Elevator Speech (O CAMPEÃO)

• Simples

• Direto

• Memorável

• Replicável pelo time inteiro
  📈 “Todo mundo consegue repetir no café”

---

🧩 Estrutura clássica do Elevator Speech (a “COPYBOOK” da Product Vision)

Modelo mais famoso (Geoffrey Moore):

For (target customer)
Who (statement of the need)
The (product name)
Is a (product category)
That (key benefit)
Unlike (primary competitor)
Our product (key differentiator)

📌 Isso é Product Vision executável, não poesia.

---

🧠 Exemplo prático (com cheiro de datacenter)

For grandes bancos brasileiros
Who precisam processar milhões de transações críticas por segundo
The CorePay Z
Is a plataforma de processamento financeiro
That garante alta disponibilidade, segurança e integridade dos dados
Unlike soluções distribuídas instáveis
Our product roda em IBM Z com confiabilidade de décadas

💥 Se o diretor entendeu isso, o produto vive.

---

🧨 Fofoca corporativa (porque Bellacosa conta bastidor)

👀 Muitas empresas:

• Dizem que têm Product Vision

• Mas na prática só têm roadmap de features

💣 Resultado?

• Produto sem identidade

• Squad puxando para lados diferentes

• “Retrabalho” (o famoso RESTART STEP=) eterno

📌 Times maduros sempre começam com Elevator Speech antes do Jira.

---

🥚 Easter Eggs (para os atentos)

• Elevator Speech ≈ Mensagem inicial de um dump

• Se não explica em 1 minuto, nem o operador vai entender

• Jeff Bezos proibiu PowerPoint → preferia narrativas curtas e claras

• Mainframe já fazia isso nos anos 70:

  “Este sistema liquida operações bancárias nacionais com consistência e disponibilidade 24x7”

👑 Isso é Product Vision raiz.

---

🧠 Comentário “El Jefe”

❝ Se você não consegue explicar seu produto em um elevador,
você não tem um produto — só um monte de código rodando. ❞

---

🧷 Dicas práticas (para aplicar amanhã)

✔️ Crie o Elevator Speech antes do backlog
✔️ Todo dev deveria saber recitar a visão
✔️ Se cada pessoa descreve diferente → ABEND de visão
✔️ Revise a Product Vision a cada grande mudança estratégica

---

🏁 Conclusão (RETURN CODE 0)

📌 A metodologia mais efetiva para Product Vision é o Elevator Speech, porque:

• Cria alinhamento

• Força clareza

• Evita desperdício

• Funciona do board ao data center

☕ E como diria o Bellacosa Mainframe:

Produto bom é aquele que até o mainframe entenderia.

🧩SMP/E: USERMOD na prática

 

Bellacosa Mainframe apresenta IBM SMP/E

🧩 USERMOD na prática

Poder absoluto nas mãos erradas (ou a salvação do sysprog)

“USERMOD é liberdade.
USERMOD sem controle é tragédia.”

---

🧠 O que é USERMOD (sem romantizar)

USERMOD é um SYSMOD criado pelo próprio cliente, não pela IBM.

Ele permite:

• Ajustes locais

• Correções temporárias

• Customizações específicas

• Patches emergenciais

👉 Em Bellacosa claro:

USERMOD é mexer no z/OS sem a IBM te segurar a mão.

---

🕰️ Origem do USERMOD

USERMOD nasceu da necessidade real:

• A IBM não entrega tudo pronto

• Ambientes são únicos

• Nem toda correção pode esperar um PTF oficial

📌 Mas a IBM sempre deixou claro:

USERMOD é por sua conta e risco.

---

🧩 Quando USERMOD faz sentido

✔ Ajuste emergencial
✔ Correção temporária
✔ Customização local
✔ Teste de solução
✔ Mitigação até PTF oficial

❌ Substituir manutenção IBM
❌ “Resolver rápido” sem documentação
❌ Correção definitiva

---

⚠️ Riscos reais do USERMOD

• Conflito com PTF futuro

• Perda de suporte IBM

• Dificuldade em upgrades

• Dependências invisíveis

• Esquecimento (o pior de todos)

👉 USERMOD mal documentado vira fantasma.

---

🧠 USERMOD e SMP/E

USERMOD:

• É tratado como SYSMOD

• Tem MCS

• Usa RECEIVE/APPLY/ACCEPT

• Entra no CSI

📌 Se não está no SMP/E, não existe.

---

🧾 Estrutura básica de um USERMOD

Exemplo simples

++USERMOD(UM0001).
++VER(Z038) FMID(HJES770).
++MOD(JES2MOD).

👉 Tradução:

• USERMOD UM0001

• Para JES2

• Modificando módulo específico

---

🔎 Boas práticas de MCS em USERMOD

Sempre usar:

• ++VER → versão correta

• ++IF → controle condicional

• ++HOLD → alertar risco

• Comentários claros

💡 Dica Bellacosa:

“USERMOD sem ++VER é roleta russa.”

---

🧪 APPLY CHECK é obrigatório

Nunca aplique USERMOD direto:

APPLY CHECK.

Avalie:

• Impacto

• Conflitos

• Pré-requisitos

• PTFs existentes

---

🔄 USERMOD x PTF futuro

Quando um PTF oficial sai:

• Ele pode sobrescrever o USERMOD

• Ele pode falhar por causa do USERMOD

• Ele pode exigir remoção do USERMOD

📌 Processo saudável:

1. Identificar USERMOD afetado

2. RESTORE USERMOD

3. APPLY PTF

4. Descartar USERMOD

---

📦 ACCEPT de USERMOD: pense duas vezes

❗ ACCEPT de USERMOD é perigoso.

Só faça se:

• For permanente

• For bem documentado

• For aprovado formalmente

👉 ACCEPT grava na história.

---

🧠 Caso real (Bellacosa clássico)

USERMOD criado em 2014
Ninguém lembra por quê
Upgrade falha em 2025
PTF não aplica

📌 Moral:

USERMOD esquecido custa caro.

---

🎓 Como aprender USERMOD com segurança

• Estudar MCS

• Praticar em laboratório

• Simular conflito

• Ler Redbooks

• Usar SMP/E Workshop

---

🧠 Curiosidades Bellacosa

• USERMOD já salvou sistemas críticos

• USERMOD já derrubou produção

• USERMOD nunca deve ser invisível

---

🧾 Comentário final – USERMOD

USERMOD é bisturi, não martelo.
Use com precisão.
Documente tudo.

🧩💾🔥