COBOL Estruturado: disciplina, elegância e sobrevivência no mundo mainframe

Ao melhor estilo Bellacosa Mainframe, direto dos porões do CPD para o El Jefe Midnight Lunch

---

☕ Introdução: quando o COBOL aprendeu a pensar

Durante décadas, o COBOL foi injustamente carimbado como uma linguagem verborrágica, rígida e cheia de GOTOs selvagens pulando de parágrafo em parágrafo como gremlins em madrugada de fechamento mensal. O COBOL estruturado surge justamente como a vacina contra esse caos.

Mais do que uma evolução sintática, COBOL estruturado é postura, disciplina mental e, acima de tudo, respeito ao próximo programador — normalmente você mesmo daqui a 6 meses.

---

🧠 O que é COBOL Estruturado, afinal?

COBOL estruturado é a aplicação dos princípios da programação estruturada ao COBOL clássico:

• Nada de saltos caóticos com GO TO

• Fluxo lógico previsível

• Blocos com início, meio e fim bem definidos

Ele se apoia em três pilares universais:

1. Sequência – código executado em ordem natural

2. Seleção – decisões claras (IF, EVALUATE)

3. Iteração – repetição controlada (PERFORM UNTIL, PERFORM VARYING)

Se você domina isso, domina qualquer código mainframe.

---

📜 Por que o COBOL estruturado é mais legível?

Porque ele conta uma história.

Compare:

• Parágrafos pequenos e objetivos

• END-IF, END-PERFORM explícitos

• Nomes semânticos (CALCULA-TOTAL, VALIDA-CPF)

O código deixa de ser um labirinto e vira um manual técnico executável.

💡 Dica Bellacosa: se o código parece um romance russo, algo está errado.

---

🛠️ Passo a passo para escrever COBOL estruturado

1️⃣ Planeje antes de codar

Desenhe o fluxo:

• O que entra?

• Quais decisões existem?

• Onde o processamento termina?

2️⃣ Quebre tudo em parágrafos pequenos

Um parágrafo = uma responsabilidade.

Errado:

• PROCESSA-TUDO

Certo:

• LE-ARQUIVO

• VALIDA-DADOS

• CALCULA-VALORES

• GRAVA-SAIDA

3️⃣ Use PERFORM como se fosse uma chamada de função

PERFORM VALIDA-DADOS
PERFORM CALCULA-TOTAL

Isso é COBOL estruturado em sua forma mais pura.

4️⃣ Elimine GO TO (sem dó)

Se você precisa de GO TO, provavelmente:

• O parágrafo está grande demais

• O fluxo está mal pensado

---

🧪 Segredos que veteranos não contam

🔹 Menos é mais: COBOL estruturado prefere muitos parágrafos pequenos a poucos gigantes.

🔹 IF aninhado demais é cheiro de problema: use EVALUATE.

🔹 Comentários explicam o porquê, não o como:

* Validação exigida pelo Bacen após incidente de 2009

🔹 Código bem estruturado envelhece melhor que documentação externa.

---

🧾 Curiosidades de bastidor (fofoca técnica)

• O impulso pela programação estruturada veio forte nos anos 70, após sistemas críticos se tornarem impossíveis de manter.

• Grandes bancos só aceitaram novas rotinas COBOL sem GO TO.

• Há sistemas em produção hoje que seguem padrões estruturados criados nos anos 80 — e funcionam melhor que muito microserviço moderno.

---

🥚 Easter Eggs do mundo mainframe

🕵️‍♂️ Já reparou que muitos sistemas usam parágrafos chamados MAIN-PARA ou 0000-INICIO? Isso é herança direta da transição do COBOL não estruturado.

🐘 Alguns compiladores modernos avisam quando você usa GO TO. É o mainframe te julgando silenciosamente.

☕ Programadores COBOL estruturado costumam dormir melhor em fechamento contábil.

---

✅ Boas práticas Bellacosa Mainframe (anote!)

✔ Um parágrafo não deve passar de uma tela
✔ Nomeie tudo com significado de negócio
✔ Prefira EVALUATE a IF encadeado
✔ Evite variáveis globais desnecessárias
✔ Código deve ser lido como um roteiro lógico

---

🌙 Conclusão: COBOL estruturado não é velho — é sábio

COBOL estruturado é como um bom uísque: não precisa de modinha, precisa de respeito. Ele entrega previsibilidade, estabilidade e clareza — exatamente o que sistemas críticos exigem.

No fim das contas, não é sobre COBOL.
É sobre engenharia, disciplina e responsabilidade.

E como todo bom código mainframe…

Ele não faz barulho. Ele simplesmente funciona.

— Bellacosa Mainframe, servido à meia-noite no El Jefe Midnight Lunch 🌙

Changeman x Endevor: Briga de gigantes

 

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

☕🚀

Visitando a fabrica de chocolate do Xuxa Park

Yes, nos tinhamos fabrica de chocolate.

Após perdermos os chocolates da Montanha Encantada do Playcenter, na capital só restou a fabrica de Chocolate do Xuxa Park.

Infelizmente me decepcionei, esperava algo parecido com os chocolates do Playcenter, esta versão foi bem mais simples. Um trenzinho que entrava num labirinto e percorria as instalações.

Infelizmente ou felizmente não me recordo muito do percurso, mas foi bem bobinho e ao final fiquei com a sensação de ter entrado numa furada.

Com o encerramento do parque esta atraçao ja foi tarde. Poderiam ter feito tantas coisas legais. Pena

Polvo maluco e seus peixinhos no carrosel do Parque da Xuxa

Parque da Xuxa o Polvo Carrosel

Passamos um dia diferente, a Ju viu no Facebook que tinha o parque da Xuxa no Shopping Interlagos em São Paulo, apos estudarmos como chegar resolvemos ir levar o formiguinha para se divertir um pouquinho.

Saímos de Itatiba numa viagem de quase 2 horas ate chegar no extremo sul da Capital, nos deparamos com um parque meio caquéctico, com muito a desejar, nem parecia que estava associado a imagem milionária dos produtos Xuxa.

O Xuxa Park provavelmente um dia foi um super parque, porem agora no seu apagar das luzes (ele encerrou as actividade no ano seguinte). Deixa muito a desejar aos olhos críticos de um adulto.

Para as crianças foi diversao garantida, o formiguinha brincou em todos os briquedos possiveis, ou seja permitidos para seu tamanho/idade. Por acaso este polvo ele riu bastante, fazendo bastante caretas e zoeiras.

 

Bellacosa Mainframe apresenta o CICS 5.2

🔥 CICS Transaction Server for z/OS 5.2 — Evolução e Transformação

 

---

☕ Midnight Lunch em 2014 — o momento em que o CICS começou a falar JSON

Imagine um green screen tradicional, movimentando milhões de transações por dia… De repente, chegam dispositivos móveis, APIs modernas e JSON por todo lado.
O CICS TS 5.2 foi o release que realmente intensificou a integração com o mundo Web e móvel, mantendo a robustez que só o mainframe entrega.

---

📅 Datas importantes

📌 Data de Lançamento (General Availability): 7 de abril de 2014
📌 Fim de Vida / End of Service: Versão já está fora de suporte oficial há alguns anos, substituída por releases posteriores (5.3, 5.4, 5.5, etc.).

---

🆕 O que há de novo — trilha de evolução

O CICS TS 5.2 não reinventa a roda. Em vez disso, refina e amplia os temas iniciados em 5.1 — especialmente a integração com a Internet e a service agility.

---

CICS 5.2

🌐 1) JSON e REST nativos

Uma das mudanças mais marcantes foi o suporte ao JSON (JavaScript Object Notation) e a capacidade de se expor serviços RESTful diretamente no CICS, sem depender apenas de SOAP ou tecnologia legada.
Isso veio da incorporação de recursos que antes estavam apenas no Feature Pack for Mobile Extensions. ◆

📌 Bellacosa comenta:

“Aqui o CICS começou a falar a língua da web moderna — JSON já não era só buzzword, era prática em produção.”

---

📡 2) Flexibilidade de data mapping para Web Services

O CICS TS 5.2 ampliou o mapeamento de dados para:

• JSON e XML com mais tipos de dados

• UTF-16 e estruturas mais complexas

• TRANSFORM API para conversão automática
  Isso facilita a interoperabilidade com aplicações Web e móveis.

---

🔗 3) Alto suporte a high availability com IPIC

A conectividade IPIC foi estendida para suportar cenários avançados de alta disponibilidade, permitindo que grupos de regiões CICS trabalhem como um cluster com um ponto de entrada compartilhado.
Assim, se uma região cair, outra assume sem impacto visível para o cliente.

💬 Bellacosa ri:

“Cluster de CICS nos anos 2010? Era coisa de mestre Jedi do mainframe.”

---

🛠️ 4) Instalação mais flexível e opções de edição

Agora era possível escolher entre:
✔ CICS TS for z/OS — produção completa
✔ Developer Trial — ambiente try-before-you-buy
✔ VUE (Value Unit Edition) — modelo de licenciamento alternativo
Essa modularização facilitou experimentação e adoção.

---

📊 5) Gestão por policies ampliada

O modelo de policy-based management foi expandido para cobrir mais tipos de limiares (thresholds) — como filas temporárias, tempo de execução, syncpoints, TASKs e muito mais. Isso permite automação real na operação diária.

---

🔐 6) Segurança fortalecida

CICS 5.2 trouxe suporte mais profundo a padrões como SAML e Kerberos para Web Services, além de capacidades de TLS 1.2 e conformidade com padrões de segurança modernos. Isso consolidou o CICS como uma plataforma segura para serviços corporativos.

---

🧠 Melhorias “por baixo dos panos”

✔ APIs e SPI threadsafe foram ampliadas, melhorando concorrência e performance para grandes workloads.
✔ Parâmetros de initialization foram ajustados para melhorar desempenho geral.
✔ Mais estatísticas e campos de monitoramento foram expostos nas métricas SMF e instrumentos de performance.

---

🧪 Curiosidades e Eastereggs Particulares

🍺 JSON vindo para ficar:
Antes do 5.2, JSON ainda era “mobile add-on”. Aqui ele se torna funcionalidade central, pavimentando o caminho para APIs modernas.

🍺 Clusters nativos CICS com IPIC:
A possibilidade de agrupar regiões sob um único ponto de entrada foi um passo silencioso, mas enorme, para resiliência corporativa.

🍺 Edição VUE — precinho esperto:
Nem todo cliente queria full enterprise. O modelo VUE abriu portas para novos workloads com custo mais previsível.

---

🤓 Exemplo de impacto real

Imagine uma operadora de pagamentos em 2015:

✳ Antes:
Aplicações CICS atendiam telas e SOAP para integração back-office.

➡ Com CICS TS 5.2:

• O app mobile passa a chamar endpoints REST com JSON

• O backend CICS responde diretamente sem middleware extra

• Métricas mais ricas permitem operações em tempo real

• Clusters CICS garantem resiliência 24×7

💬 Bellacosa resume:

“De um lado a transação, do outro JSON — e no meio o CICS gerenciando tudo com a mesma disciplina de sempre.”

---

💡 Dicas Bellacosa para quem encara 5.2

✅ Aproveite JSON e TRANSFORM APIs para integração com microsserviços.
✅ Use policy thresholds para automatizar alertas e ações.
✅ Explore IPIC para alta disponibilidade.
✅ Teste as edições Developer Trial antes de ir à produção.

---

📌 Conclusão — Bellacosa Mainframe

O CICS TS 5.2 é a iteração que consolidou a modernização do CICS:

🔥 JSON e REST se tornam primeiros cidadãos
🔥 Alta disponibilidade com clusters nativos
🔥 Políticas automáticas para gestão
🔥 Segurança moderna integrada
🔥 Flexibilidade de instalação e uso

📌 5.2 não foi apenas incremental — foi um passo estratégico para integrar CICS com o novo mundo de serviços e aplicações móveis.

🧔‍♂️ Caricaturas, Pastelões e o Doce Zigue-Zague da Saudade

 

📝 El Jefe Midnight Lunch — Crônica Bellacosa Mainframe
Caricaturas, Pastelões e o Doce Zigue-Zague da Saudade

---

Às vezes, meus caros Oni-Readers, a saudade dá aquele estouro de SVC no peito — uma interrupção emocional tão forte que trava o sistema, obriga o coração a rodar um pequeno abend S013 de lembranças, antes de voltar para o fluxo normal. E é nesses momentos que o Bellacosa aqui mergulha fundo nos arquivos do SMF da infância, lá no final dos anos 1970 e início dos anos 1980 — quando o mundo era simples, compacto, leve, como um JCL bem escrito.

Era um tempo em que as pessoas conviviam de verdade. A vizinhança era um CICS de portas abertas: todo mundo falando, todo mundo se vendo, todo mundo participando. Nada de DM no WhatsApp, nada de notificação push — era bater na porta, gritar no portão ou chegar de chinelo arrastando pelo corredor.

Tínhamos quatro canais de televisão. Quatro. E ainda assim parecia mais que suficiente. Aos sábados, depois de cumprir a “rotina batch doméstica” (leia-se: arrumar cama, guardar brinquedos, levar lixo), chegava a hora mágica dos pastelões americanos. O Gordo e o Magro, Os Três Patetas, os Irmãos Marx, Jerry Lewis rodando suas rotinas em preto e branco, com um humor tão puro e eficiente quanto um COBOL bem indentado. Imagine horas de riso facil, com torta na cara, lutas hilariantes, música de primeira e confusão sem igual, clássico dos clássicos, cenário de papelão meia boca, figurino modesto e orçamento menor ainda, mas riso garantido. O mais gostoso de tudo era estar na companhia dos meus avôs Pedro e Anna, sempre tinha um bolo delicioso, uma nova receita experimental e aquele carinho maravilhoso, que deixa lagriminhas nos olhos.

Era pastelão, era trapalhada, era perseguição no estilo GO TO sem PERFORM. E eu ria — oh, como ria! Até hoje, quando encontro um desses clássicos perdidos num super canal da vida, sinto o coraçãozinho dar aquele upgradinho gostoso, como se estivesse aplicando um PTF de alegria.

E aí, nesse batch job de memórias, minha fita magnética me leva direto para a casa do bisavô Francisco — o espanhol. Um homem durão, cara fechada, pose de Security Officer de RACF, mas com um coração mole escondido sob aquela casca rígida. Ele adorava minhas artes, meus rabiscos, meus desenhos, que ele chamava carinhosamente de “caricaturas”. E olha que naquela época eu rabiscava em qualquer superfície que não estivesse correndo, respirando ou gritando.

Mas o maior carinho era o ritual:
Sempre que o bisavô ia ao banco pegar a aposentadoria, pedia ao gerente listagens de formulário contínuo já usadas — aquelas enormes, brancas, com o contorno verde zebrado. E levava pra mim. Um pacotão. Um mainframe delivery de pura felicidade.

Engraçado pensar que dez anos depois eu estaria exatamente ali, adulto, vivendo profissionalmente entre listagens contínuas, formulários carbonados, 80, 130 e 255 colunas… Era como se o bisavô tivesse enviado um pequeno JOB para o futuro, preparando meu DESTINY. Ou pelo menos meu DDN.

E falando em doçuras do passado — como não lembrar da bisavó Isabel? Ah, a rotina dela guardando a nata que subia no leite fervido para fazer manteiga… aquilo era alquimia culinária. Um assembler culinário, instrução por instrução, mexendo devagarinho, apertando o tempo certo, virando uma manteiga artesanal que parecia carregar um pedacinho de céu.

E os bolinhos de chuva da tia-avó Maria? Aquilo não era receita. Era magia. Você via a chuvinha fina batendo no quintal, o cheiro invadindo a casa, açúcar caindo devagar como spool sendo liberado pelo JES2, e pronto: os Onis já estavam todos reunidos no entorno da panela, como programadores à espera de um dump para examinar.

Tudo era doce. Tudo era alegre. Tudo era travessura. Eu estava sempre em alguma casa de parente, rodando meus “programas infantis”, criando caos, sorrindo, vivendo. Nada de logs, nada de monitoramento — era pura execução em tempo real.

Hoje, quando a saudade aperta aquele botão interno e chama essas memórias para a memória central, percebo como esses pequenos instantes construíram o backup emocional do que sou.

E fico feliz…
Porque, no fundo, ainda sou aquele pequeno Oni rabiscador, que ria dos pastelões, que pedia lista contínua do banco e que acreditava que a vida sempre teria cheiro de bolinho de chuva.

E, com licença… acho que preciso ir ali fazer café.

Esse dump emocional mereceu.

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