Programando COBOL no GitHub com VS Code Sem Mainframe. Sem Compilar. Apenas Aprendendo como um Desenvolvedor Moderno.

 

Bellacosa Mainframe usando o vs code para programar cobol numa ide moderna

☕ Um Café no Bellacosa Mainframe

Programando COBOL no GitHub com VS Code

Sem Mainframe. Sem Compilar. Apenas Aprendendo como um Desenvolvedor Moderno.

"Todo Jedi começa treinando com um sabre de luz desligado. Todo desenvolvedor Mainframe também pode começar sem um z/OS."

---

Antes de começarmos...

Existe um mito enorme no mundo Mainframe.

"Para aprender COBOL preciso de um IBM Z."

Não.

Outro mito:

"Para editar programas COBOL preciso de um emulador."

Também não.

Outro:

"Preciso instalar um compilador."

Ainda não.

Hoje vamos aprender exatamente como milhares de desenvolvedores modernos trabalham quando estão estudando, revisando código ou preparando alterações para um projeto.

Você vai usar apenas:

• GitHub

• Visual Studio Code

• IBM Z Open Editor

• Git

Nada mais.

Nenhum z/OS.

Nenhum TSO.

Nenhum ISPF.

Nenhuma licença IBM.

E, ainda assim, estará utilizando praticamente o mesmo editor utilizado por desenvolvedores COBOL profissionais.

Pegue seu café.

Vamos montar nosso laboratório.

---

Bellacosa Mainframe passo a passo na instalacao

A grande mudança de mentalidade

Imagine um mecânico.

Ele não liga um caminhão para trocar o volante.

Primeiro ele trabalha na peça.

Depois instala.

No Mainframe acontece exatamente igual.

Você pode editar, estudar, revisar e versionar milhares de programas COBOL sem sequer possuir acesso ao IBM Z.

O Mainframe só entra quando chega a hora de:

• compilar

• executar

• testar online

• acessar DB2

• acessar CICS

• executar JCL

Até lá...

Tudo pode ser feito localmente.

---

Nossa arquitetura

Imagine esta jornada.

GitHub
     │
git clone
     │
VS Code
     │
IBM Z Open Editor
     │
Editar COBOL
     │
Git Commit
     │
Git Push
     │
GitHub

Perceba.

O Mainframe nem apareceu.

---

O que vamos instalar

Nosso kit Bellacosa Mainframe será composto por:

✅ Visual Studio Code

✅ Git

✅ IBM Z Open Editor

✅ GitHub Pull Requests

✅ Error Lens

✅ Material Icon Theme

✅ Markdown All in One

✅ Code Spell Checker

✅ Todo Tree

✅ Peacock

Opcionalmente:

• GitLens

• Better Comments

• YAML

• XML

• Rainbow CSV

• Hex Editor

• REST Client

Você perceberá que quase tudo é gratuito.

---

Passo 1 — Instale o Git

Sem Git...

não existe GitHub.

Baixe:

https://git-scm.com

Durante a instalação aceite praticamente tudo.

Depois abra um terminal.

Digite:

git --version

Se aparecer algo parecido com:

git version 2.51

Parabéns.

Seu sabre de luz foi montado.

---

Passo 2 — Instale o VS Code

Baixe em

https://code.visualstudio.com

Instale normalmente.

Abra.

Você verá uma tela praticamente vazia.

É aqui que a mágica acontece.

---

Passo 3 — Faça login no GitHub

No canto inferior esquerdo existe o ícone da conta.

Clique.

Escolha:

Sign In with GitHub

O navegador abrirá.

Autorize.

Volte ao VS Code.

Pronto.

Agora seu VS Code conversa diretamente com o GitHub.

---

Passo 4 — Instale o IBM Z Open Editor

Abra Extensions.

Pesquise:

IBM Z Open Editor

Instale.

Este plugin entende COBOL.

Ele conhece:

• DIVISION

• SECTION

• PARAGRAPH

• COPY

• EXEC SQL

• EXEC CICS

• comentários

• copybooks

É praticamente um ISPF moderno.

---

O que ele faz?

Quando você abre:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.

Ele já entende que aquilo é COBOL.

Você ganha:

✔ Colorização

✔ Outline

✔ Auto Complete

✔ Navegação

✔ Hover

✔ Referências

✔ Folding

✔ Sintaxe

Tudo gratuitamente.

---

Passo 5 — Instale GitHub Pull Requests

Esse plugin é fantástico.

Ele permite:

• abrir Pull Requests

• revisar código

• comentar linhas

• aprovar alterações

Sem sair do VS Code.

---

Passo 6 — Material Icon Theme

Pequeno detalhe.

Grande diferença.

Agora:

📄 COBOL

📄 COPYBOOK

📄 JCL

📄 REXX

ganham ícones.

Seu projeto fica muito mais agradável.

---

Passo 7 — Error Lens

Esse plugin faz algo simples.

Mostra erros diretamente na linha.

Sem precisar olhar outro painel.

Economiza muito tempo.

---

Passo 8 — Better Comments

Imagine:

*> TODO

vira verde.

*> WARNING

fica amarelo.

*> BUG

fica vermelho.

Seu código passa a conversar com você.

---

Passo 9 — Todo Tree

Agora imagine possuir 3.000 programas.

Você procura:

TODO

Ele encontra todos.

Fantástico para projetos enormes.

---

Passo 10 — Clone seu GitHub

No terminal:

git clone https://github.com/seuusuario/IBMLearnCOBOL.git

ou simplesmente:

No VS Code:

Clone Repository

Cole a URL.

Pronto.

---

Estrutura típica

COBOL/
    HELLO.CBL
    CLIENTE.CBL
COPY/
    CLIENTE.CPY
JCL/
    COMPILA.JCL
REXX/
README.md

Tudo organizado.

---

Abrindo o projeto

Arquivo

Open Folder

Escolha:

IBMLearnCOBOL

Agora tudo aparece na lateral.

Exatamente como Java.

Exatamente como Python.

---

Editando um programa

Abra:

HELLO.CBL

Modifique:

DISPLAY "HELLO WORLD".

para

DISPLAY "HELLO BELLACOSA MAINFRAME".

Salve.

Só isso.

---

Observe o Git

Na lateral existe:

Source Control

Aparecerá:

M HELLO.CBL

M significa:

Modified.

---

Veja a diferença

Clique no arquivo.

O VS Code mostra:

esquerda

arquivo antigo

direita

arquivo novo.

Em verde:

linhas adicionadas.

Em vermelho:

linhas removidas.

É maravilhoso.

---

Criando um Commit

Na caixa superior escreva:

Alterado texto do HELLO WORLD

Clique:

Commit

Pronto.

---

Fazendo Push

Agora clique:

Sync

ou

Push

O Git envia tudo para o GitHub.

Seu código agora está online.

---

Histórico

Clique:

Timeline

Você verá:

• quem alterou

• quando

• qual commit

• diferença

É uma máquina do tempo.

---

GitLens

Se instalar GitLens...

fica ainda melhor.

Você passa o mouse.

Ele mostra:

Vagner Bellacosa

14 dias atrás

Commit:

Correção cálculo IRRF

Parece mágica.

---

Trabalhando com Branches

Nunca altere diretamente a Main.

Crie:

feature/curso-cobol

bugfix/cliente

feature/json

feature/db2

Isso é padrão de mercado.

---

Commits bons

Ruim:

teste

Ruim:

aaaa

Ruim:

mudança

Bom:

Inclui validação do CPF

Corrige cálculo de juros

Refatora rotina de leitura VSAM

Atualiza documentação

---

Organização Bellacosa

COBOL
COPY
JCL
BMS
DBRM
SQL
DOCS
LABS
QUIZZES

Tudo separado.

Tudo fácil.

---

Markdown

Documente tudo.

README.

Arquitetura.

Fluxo.

Exemplos.

O VS Code possui preview fantástico.

---

Dica de Ouro

Ative:

Auto Save

Você nunca esquecerá de salvar.

---

Outra dica

Use:

Minimap.

Você enxerga programas COBOL gigantes.

---

Outra

Breadcrumbs.

Você sabe exatamente:

DIVISION

SECTION

PARAGRAPH

onde está.

---

Outra

Outline.

Clique:

CALCULA-TOTAL

Vai direto para o parágrafo.

Adeus Page Down.

---

Outra

CTRL+P

Digite:

cliente

Abre CLIENTE.CBL imediatamente.

---

Outra

CTRL+SHIFT+O

Lista todos os parágrafos.

Fantástico.

---

Outra

CTRL+SHIFT+F

Procura em TODOS os programas.

Imagine localizar:

EXEC SQL

em 12.000 fontes.

Leva segundos.

---

Easter Egg nº 1

Troque o tema.

Experimente:

IBM Carbon Theme

ou

One Dark Pro.

Seu COBOL fica lindíssimo.

---

Easter Egg nº 2

Instale Peacock.

Cada Workspace ganha uma cor.

Nunca mais confundirá produção e laboratório.

---

Easter Egg nº 3

Digite:

>Preferences: Open Keyboard Shortcuts

Personalize tudo.

---

Easter Egg nº 4

Use emojis nos commits.

✨ Novo programa

🐞 Corrige bug

📚 Atualiza documentação

♻ Refatoração

🚀 Nova funcionalidade

---

Easter Egg nº 5

Use Copilot apenas para sugerir código.

Nunca aceite sem entender.

O bom desenvolvedor continua pensando.

---

Quando chegar o Mainframe...

Nada muda.

Você apenas instala:

IBM Zowe Explorer.

Então passa a acessar:

PDS

PDSE

USS

JES

Jobs

Datasets

O editor continua exatamente o mesmo.

É como aprender a dirigir em um simulador e depois entrar no carro real: os comandos principais permanecem familiares.

---

O verdadeiro objetivo

Aprender COBOL nunca foi decorar comandos do ISPF.

O objetivo é entender:

• lógica de negócio;

• arquitetura de sistemas;

• qualidade de código;

• versionamento;

• colaboração;

• documentação.

Essas habilidades acompanham você em qualquer plataforma.

---

Conclusão

Durante décadas, muitos imaginaram que o desenvolvimento Mainframe dependia de telas verdes, terminais 3270 e comandos memorizados. Hoje, essa realidade mudou. O Visual Studio Code, aliado ao IBM Z Open Editor e ao GitHub, oferece uma experiência moderna, produtiva e acessível para estudar, revisar e evoluir programas COBOL sem a necessidade imediata de um ambiente z/OS.

Ao dominar Git, commits bem escritos, branches, documentação em Markdown e a organização de projetos, você desenvolve competências valorizadas em qualquer equipe de engenharia de software. Quando chegar o momento de conectar-se a um IBM Z com o Zowe Explorer, a curva de aprendizado será muito menor, pois o editor, os atalhos e o fluxo de trabalho continuarão praticamente os mesmos.

Você não está abandonando o Mainframe tradicional. Está adicionando ferramentas modernas à sua caixa de ferramentas. Como costumo dizer no Bellacosa Mainframe: o terminal pode mudar, mas a excelência em engenharia de software continua sendo a mesma. ☕

UrbanCode DBB: Controle de Versionamento no Mainframe, do Jeito Certo

Se você já trabalhou em mainframe, sabe que cada linha de código é sagrada. Um erro de versionamento e você pode acordar com todo o departamento olhando para você como se tivesse errado o compilador na sexta-feira à tarde. Foi justamente pensando nisso que nasceu o UrbanCode DBB, o guardião do código COBOL, PL/I, Assembler, JCL e tudo mais que roda em z/OS.

História e Origem

O DBB, que significa Dependency Based Build, começou sua vida nos laboratórios da IBM como uma forma de modernizar o build de aplicações mainframe. A ideia era simples: parar de depender de scripts complicados de JCL e REXX espalhados pelo servidor e criar algo que entendesse as dependências reais do seu código.

Em 2016, o UrbanCode comprou a tecnologia e integrou no seu portfólio de DevOps, transformando o DBB numa peça central para mainframe moderno, pronto para integração com pipelines CI/CD, Git, Jenkins e até o mundo do container e cloud.

Para que serve e por que usar

Imagine o seu sistema legado com dezenas de programas COBOL interdependentes. Alterou um copybook ou uma tabela DB2? Então você precisa recompilar tudo que depende disso, mas somente o que realmente depende. Aqui entra o DBB:

• Detecção de dependências: Ele analisa seu código e entende as relações entre programas, módulos e copybooks.

• Build incremental inteligente: Só recompila o que precisa, economizando horas de batch.

• Integração DevOps: Pode ser chamado por Jenkins, GitLab, UrbanCode Deploy, tornando o mainframe parte do fluxo ágil.

Em resumo: DBB é o cupido do build, unindo o que mudou com o que precisa mudar.

Como usar: dicas práticas

1. Estrutura de projetos: Organize seu código como projetos, módulos e pacotes. DBB adora clareza.

2. Dependência declarativa: Marque copybooks, DB2 DDL e includes. Quanto mais informação ele tiver, mais eficiente será o build.

3. Log e rastreabilidade: Sempre revise os logs. DBB é detalhista — ele te conta cada recompilação que fez.

4. Pipeline CI/CD: Integre DBB ao Jenkins ou UrbanCode Deploy para builds automáticos e consistentes.

Exemplo básico

Imagine que você tem um programa PAYROLL que depende de EMPLOYEE e SALARY. Se você altera apenas SALARY, DBB identifica que apenas PAYROLL precisa de recompilação, poupando tempo e evitando que outros programas sejam recompilados desnecessariamente.

PROJECT PAYROLL
   MODULE EMPLOYEE
   MODULE SALARY
   MODULE PAYROLL
   DEPENDS_ON SALARY, EMPLOYEE
ENDPROJECT

Simples, mas poderoso.

Curiosidade e Easter Egg

Você sabia que o DBB foi inspirado em técnicas de build usadas em ambientes UNIX? A diferença é que ele traduziu essas ideias para o z/OS, entendendo a complexidade do JCL, copybooks e DB2.

E o easter egg? Se você examinar os logs detalhados, verá pequenos comentários de debug deixados pelos engenheiros: mensagens como "Aqui mora o fantasma do COBOL" ou "Não acorde o compilador antes do café"… só quem vive de batch entende.

Comentários finais

O DBB é um salvavidas para equipes que querem DevOps sem abandonar o mainframe. Ele reduz erros, agiliza deploys e ainda preserva aquela aura mística de que o código mainframe “funciona sozinho, mas precisa de respeito”.

Se você ainda não experimentou, vale a pena. Modernizar builds não é apenas um luxo, é sobre manter a sanidade e ganhar tempo para o café da tarde.

Changeman x Endevor: Briga de gigantes

 

Bellacosa Mainframe e a briga de gigantes no controle de versão Changeman Versus Endevor

☕ Um Café no Bellacosa Mainframe

Changeman x Endevor

A briga boa do Mainframe (com gravata, RACF e auditor olhando) 😄

Se existe uma discussão eterna no mundo IBM Mainframe — quase tão antiga quanto JCL vs PROC ou COBOL fixo vs free — ela atende pelo nome:

CA Changeman ZMF x CA Endevor SCM

Não é guerra.
É clássico.
É derby.
É mainframe raiz.

Vamos colocar os dois frente a frente ao melhor estilo Bellacosa Mainframe: com história, passo a passo, comandos, dicas práticas, curiosidades, easter eggs e comentários de quem já suou em janela de produção.

---

1️⃣ Antes de tudo: eles fazem a MESMA coisa?

❌ Não exatamente.

✔ Ambos fazem Software Change Management
✔ Ambos controlam código, versões e promoção
❌ Mas a filosofia é completamente diferente

👉 Changeman é processo e pacote
👉 Endevor é ambiente e mapa

Pense assim:

• Changeman: “Vou criar um pacote com tudo que muda.”

• Endevor: “Vou mover o elemento dentro do fluxo do sistema.”

---

2️⃣ Um pouco de história 📜

🕰️ Endevor (o veterano)

• Nasceu nos anos 70/80

• Criado para ambientes grandes, complexos e altamente integrados

• Muito usado em bancos, seguradoras e telecom

• Filosofia: onde o código vive importa

🕰️ Changeman (o organizado)

• Surge depois, focado em governança e auditoria

• Ideal para ambientes com:

  • Muitos desenvolvedores

  • Processos rígidos

  • Separação clara de responsabilidades

• Filosofia: o pacote é a unidade da mudança

---

3️⃣ Conceitos fundamentais (lado a lado)

Conceito	Changeman	Endevor
Unidade principal	Package	Element
Controle	Por pacote	Por ambiente
Promoção	Promote Package	Move Element
Versão	Baseline	Level
Auditoria	Muito forte	Forte, mas diferente
Curva de aprendizado	Média	Alta 😅

---

4️⃣ Changeman em 3 passos (vida real)

🔹 1. Criar Package

Você cria um Package contendo:

• Programas

• JCLs

• Copybooks

Tudo que muda vai dentro dele.

---

🔹 2. Trabalhar nos componentes

• Edita

• Compila

• Testa

• Usa View Changes para validar

---

🔹 3. Promote

• DEV → QA → HML → PRD

• Aprovações

• Auditoria feliz

• Produção protegida

👉 O pacote é rei.

---

5️⃣ Endevor em 3 passos (vida real)

🔹 1. Localizar o Element

O código já vive dentro de:

• Environment

• System

• Subsystem

• Type

• Stage

---

🔹 2. Editar e gerar

Você:

• EDIT o Element

• GENERATE

• Endevor cria versões (Levels)

---

🔹 3. Move

• MOVE Stage 1 → Stage 2

• O elemento sobe no fluxo

• Tudo rastreado pelo caminho

👉 O mapa do sistema é rei.

---

6️⃣ Comandos clássicos (raiz mesmo) ⌨️

🔹 Endevor (linha de comando ISPF)

• ADD – adicionar elemento

• EDIT – editar

• GENERATE – compilar

• MOVE – promover

• BROWSE – visualizar

• HISTORY – ver histórico

💬 “Sem GENERATE, não existe Endevor.”

---

🔹 Changeman (menu-driven)

• Create Package

• Add Components

• Edit

• Build

• Test

• Promote

• View Changes

💬 “Sem Package, não existe Changeman.”

---

7️⃣ Dicas Bellacosa (quem já caiu em produção) 🧠

✔ Quando escolher Changeman

• Ambientes com auditoria pesada

• Times grandes

• Mudanças agrupadas

• Governança forte

• Muitas áreas envolvidas

👉 Ideal para bancos e órgãos regulados

---

✔ Quando escolher Endevor

• Sistemas gigantes

• Fluxos complexos

• Dependência entre componentes

• Times técnicos maduros

👉 Ideal para core systems antigos e robustos

---

8️⃣ Curiosidades ☕

• Endevor não precisa de pacote

• Changeman vive de pacote

• Endevor é extremamente customizável

• Changeman é mais user friendly

• Ambos integram com RACF

• Ambos deixam rastro (log) até do seu suspiro 😄

---

9️⃣ Easter Eggs de quem viveu 🥚

🥚 O “MOVE errado” no Endevor
Mover o elemento para o stage errado é como:

“scp direto em produção”

🥚 O pacote Frankenstein no Changeman
Package com:

• 1 programa

• 2 JCLs

• 3 COPYs

• 1 PROC

• E ninguém lembra por quê

🥚 Auditor vs Desenvolvedor
Auditor ama Changeman.
Arquiteto raiz ama Endevor.
E o programador… só quer ir pra casa 😂

---

🔟 Changeman x Endevor em linguagem moderna

Hoje	Mainframe
Git Flow	Endevor
Pull Request	Changeman Package
CI/CD Pipeline	Generate / Promote
Diff	View Changes / History

---

1️⃣1️⃣ Quem ganha a briga?

Resposta honesta Bellacosa:

Depende do ambiente, da cultura e do tamanho do monstro.

❌ Não existe vencedor absoluto
✔ Existe ferramenta certa para o problema certo

Mainframe não é moda.
É engenharia.

---

1️⃣2️⃣ Comentário final ☕

Changeman e Endevor não são inimigos.
São filosofias diferentes para o mesmo objetivo:

Proteger produção, garantir rastreabilidade e manter o caos sob controle.

Se você domina os dois, você não é só programador:
👉 Você é guardião do sistema.

☕🚀

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