Changeman - View Changes

☕ Um Café no Bellacosa Mainframe

Changeman – View Changes

O “git log / git diff” raiz do z/OS, muito antes de virar moda 😉

Se você já trabalhou com CA Changeman em ambiente IBM Mainframe, sabe: ele não é apenas uma ferramenta de controle de mudanças. Ele é praticamente um guardião da sanidade do programador, do analista e do auditor.
E dentro desse universo, existe um recurso simples, poderoso e muitas vezes subestimado: View Changes.

Vamos destrinchar isso ao melhor estilo Bellacosa Mainframe: com história, passo a passo, dicas práticas, curiosidades, comandos e até alguns easter eggs que só quem já sofreu em produção entende 😄

---

1️⃣ O que é o Changeman?

O CA Changeman ZMF (Zero Migration Facility) é uma ferramenta de Change Management usada no z/OS para:

• Controlar versões de programas (COBOL, PL/I, ASM, JCL, PROC, COPY, etc.)

• Garantir rastreabilidade (quem mudou, quando, por quê)

• Organizar ambientes (DEV → QA → HML → PRD)

• Atender auditorias (SOX, PCI, ISO, BACEN feelings 😅)

👉 Antes do GitHub existir, o Changeman já fazia controle de versão sério no mainframe.

---

2️⃣ O que é o View Changes?

O View Changes permite visualizar as diferenças entre versões de um componente antes, durante ou depois de uma migração.

Em outras palavras:

“O que exatamente mudou nesse programa?”

Ele compara:

• Baseline × Working

• Package × Baseline

• Versão antiga × versão nova

• Antes da promoção × depois da promoção

📌 É o diff do mainframe, só que com gravata e crachá corporativo.

---

3️⃣ Um pouco de história 📜

Antes do Changeman:

• Alterações eram feitas direto em PDS

• Versionamento? → “Salva uma cópia com outro nome”

• Auditoria? → “Confia em mim”

• Rastreabilidade? → JES2 $HASP050 de nervoso

O Changeman surgiu para organizar o caos, trazendo:

• Processos formais

• Packages

• Approvals

• Promote / Demote

• E claro… comparação de mudanças

O View Changes nasce exatamente dessa necessidade:
👉 Mostrar claramente o impacto de cada alteração.

---

4️⃣ Onde o View Changes aparece no dia a dia?

Você vai encontrar o View Changes principalmente em:

• Component List

• Package List

• Baseline Browse

• Staging / Promotion Review

Normalmente acessado via ISPF menus do Changeman.

---

5️⃣ Passo a passo – View Changes na prática 🧭

🔹 1. Acesse o Changeman

Via ISPF:

=CM

(ou a opção configurada no seu shop)

---

🔹 2. Entre em um Package ou Application

• Selecione a Application

• Escolha o Package

• Liste os Components

---

🔹 3. Selecione o componente desejado

Exemplo:

• Programa COBOL

• JCL

• Copybook

Normalmente usando:

S  (Select)

ou

V  (View)

---

🔹 4. Escolha View Changes

Dependendo do menu, pode aparecer como:

• View Changes

• Compare

• Diff

• Browse Changes

O Changeman então:
✔ Compara a versão atual com a versão anterior
✔ Abre uma tela de comparação lado a lado ou inline

---

🔹 5. Analise as diferenças

Você verá:

• Linhas adicionadas

• Linhas removidas

• Linhas alteradas

• Numeração original do source

🎯 Aqui está a verdade nua e crua da mudança.

---

6️⃣ Como a comparação aparece? 👀

Geralmente:

• Linhas alteradas marcadas com símbolos

• Prefixos como:

  • + inclusão

  • - remoção

  • ! modificação

• Numeração antiga × nova

📌 Dica Bellacosa:

Leia o diff antes de promover. Depois não adianta chorar no console.

---

7️⃣ Comandos úteis durante o View Changes ⌨️

Dentro da tela de visualização:

• FIND 'STRING'
  🔎 Localiza mudanças específicas

• LOCATE nnnnnn
  📍 Vai direto para uma linha

• UP / DOWN
  📜 Navegação

• RFIND
  🔁 Repetir busca

• LEFT / RIGHT
  ↔ Em comparações lado a lado

---

8️⃣ Dicas práticas (experiência de trincheira) 🧠

✔ Sempre use View Changes antes do Promote
Evita aquele clássico: “Não era isso que eu tinha mudado”.

✔ Use em JCL também!
Um DISP=SHR que virou OLD já derrubou muita madrugada.

✔ Compare COPYBOOKs com carinho
Uma mudança pequena pode quebrar 20 programas.

✔ Leia o diff como auditor
Se você não consegue explicar a mudança, o auditor vai adorar perguntar 😄

---

9️⃣ Curiosidades ☕

• Changeman faz diff linha a linha, não lógico

• Espaços contam (sim, COBOL feelings)

• Comentários alterados aparecem como mudança

• Alguns shops limitam o View Changes por perfil RACF

---

🔟 Easter Eggs Bellacosa 🥚

🥚 Mudança fantasma
Você jura que não mudou nada… mas o View Changes mostra diferenças.
👉 Normalmente:

• Espaço a mais

• Tab invisível

• Fim de linha diferente

🥚 Comentário que salva auditoria
Um simples comentário bem escrito no source pode justificar toda a alteração no diff.

🥚 O “View Changes do susto”
Quando você percebe que alguém alterou algo que não estava no request…
e o Changeman virou sua testemunha oficial 😎

---

1️⃣1️⃣ Changeman vs Git (comparação inevitável)

Conceito	Changeman	Git
Diff	View Changes	git diff
Histórico	Packages	commits
Aprovação	Approvals	pull request
Produção	Promote	merge/main

👉 Moral da história:
Mainframe sempre esteve anos à frente – só não tinha hype.

---

1️⃣2️⃣ Comentário final Bellacosa Mainframe ☕

O View Changes é simples, mas poderoso.
Ele:

• Evita erros

• Salva horas de debug

• Ajuda auditorias

• Protege produção

• E ensina disciplina técnica

Se você trabalha com Changeman e não usa View Changes, está pilotando um z/OS de olhos fechados.

Mainframe não perdoa achismo. Ele exige evidência.

E o View Changes é uma das melhores evidências que você pode ter. 

Z.CH

5 – List Package

S2 – View objects in Package

VC – View Changes

 

 

 

 

 

 

 

 

 

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

---