🧠💾 DevOps no Mainframe: Quando o COBOL Encontrou o Git

Por Vagner Bellacosa – Bellacosa Mainframe Chronicles – “Porque até o z/OS precisa de pipeline”

---

“No início, havia o JCL. E o JCL era bom.
Mas um dia o DevOps olhou para o Mainframe e disse:
‘Que tal versionar isso aí?’”
— Antigo Provérbio da Guilda dos Analistas de Produção, circa 2018.

---

⚙️ 1. A Origem da Força: Mainframe Antes do DevOps

Nos primórdios do tempo digital — década de 60 — o Mainframe era o único devops possível.
Desenvolvia, testava, implantava e executava tudo no mesmo lugar.
Sem containers, sem cloud, sem microservices. O sistema era monolítico, mas estável como uma rocha.

Os times trabalhavam em ciclos longos:

• meses para desenvolver,

• semanas para testar,

• e madrugadas inteiras para colocar em produção com medo do abençoado abend U4038.

💡 Curiosidade Bellacosa:
O termo DevOps só surgiria nos anos 2000, mas os mainframers já praticavam sua essência muito antes — colaboração, automação e controle eram o DNA natural do z/OS.

---

🔄 2. O Encontro dos Mundos: DevOps e COBOL

Quando o mundo distribuído começou a falar em Agile, CI/CD e pipelines, o Mainframe parecia o tiozão da família que ainda usava pager.
Mas o que pouca gente sabia é que o tiozão guardava o cofre dos bancos, das seguradoras e dos governos.

E então... 💥
IBM, Broadcom, Rocket e BMC perceberam: era hora de modernizar sem destruir.

Assim nasceu o DevOps para Mainframe:
A fusão entre práticas modernas (Git, Jenkins, SonarQube, API Gateway) e linguagens lendárias (COBOL, PL/I, JCL, Assembler).

---

🧰 3. As Ferramentas da Nova Ordem

O arsenal do Cavaleiro DevOps Mainframe é poderoso e variado.
Veja o comparativo entre o lado clássico e o lado moderno da força:

⚔️ Era Clássica	🛰️ Era DevOps
Librarian / Endevor	GitHub / GitLab / Bitbucket
JCL SUBMIT manual	Jenkins Pipeline / Tekton
Compilação no TSO	Build automático com DBB (Dependency Based Build)
ChangeMan / SCLM	UrbanCode Deploy / Ansible
Control-M / CA7	Orquestração via API REST
ISPF Editor	Visual Studio Code com Zowe Explorer
Spool JES2	Logs integrados no Jenkins e Splunk

🧩 Easter Egg Técnico:
O Zowe é o primeiro projeto open source oficial da IBM Z — e seu nome vem da junção de “z/OS” + “owe” (de open web).
Sim, o Mainframe virou web-friendly.

---

🔬 4. O Workflow do Padawan DevOps Mainframe

Vamos decodificar o ciclo de vida moderno de um projeto COBOL com DevOps.

🪐 Etapa 1 – Codificação

O desenvolvedor escreve o COBOL no VS Code com o plugin Zowe Explorer, salvando direto no Git.

“Adeus ISPF Edit... Olá Ctrl+S!”

⚙️ Etapa 2 – Build Automatizado

O commit aciona o Jenkins, que executa o IBM DBB — ferramenta que compila COBOL, monta COPYBOOKS e cria LOADs automaticamente.

🧪 Etapa 3 – Teste Automatizado

Entram em cena frameworks como:

• ZUnit (para testar programas COBOL)

• Topaz for Total Test (Broadcom)

• IBM zUnit + Jenkins Reports

Os testes validam não só a lógica, mas também o acesso a DB2 e VSAM.

🧭 Etapa 4 – Integração Contínua

Após os testes, o build é integrado a ambientes de QA via UrbanCode Deploy, garantindo controle e versionamento de componentes.

🚀 Etapa 5 – Deploy

Deploy automatizado no CICS, Batch, IMS ou Web Service.
Tudo monitorado com SonarQube, Splunk e SMF logs.

---

🧙‍♂️ 5. Metodologia do Caminho DevOps

Um Jedi Mainframe moderno segue quatro princípios:

1. Automatize tudo que puder — builds, testes, deploys e até submissão de JCLs.

2. Integre com respeito — nem tudo deve ser refatorado; às vezes o legado é sábio.

3. Versão é poder — o Git é o novo repositório sagrado.

4. Feedback é Força — monitore, aprenda, ajuste.

📜 Curiosidade Bellacosa:
O IBM DBB foi desenvolvido originalmente como um projeto interno chamado “Project Bluemix for z/OS”.
Ele traduz a dependência do mundo JCL em pipelines YAML. Um verdadeiro “tradutor de eras”.

---

⚡ 6. O DevOps Mainframe em Ação

Um pipeline típico de DevOps COBOL pode ser visualizado assim:

GIT PUSH
   ↓
JENKINS PIPELINE
   ↓
IBM DBB BUILD
   ↓
ZUNIT / TOPAZ TESTS
   ↓
URBANCODE DEPLOY
   ↓
Z/OS CICS EXECUTION
   ↓
MONITOR / FEEDBACK LOOP

💬 Easter Egg Filosófico:
“Pipeline é o novo JCL.”
Enquanto o JCL executa passos em batch, o pipeline orquestra passos de automação.
Ambos seguem o princípio da execução sequencial controlada — separados apenas por 50 anos de sintaxe. 😎

---

🕰️ 7. A Linha do Tempo da Evolução

Ano	Marco	Descrição
1964	Lançamento do System/360	O berço da automação batch
1980	SCLM e Librarian	Controle de versão rudimentar
1990	Endevor e ChangeMan	CM integrado ao ciclo de vida
2010	IBM DBB & UrbanCode	DevOps ganha cara no z/OS
2018	Projeto Zowe	Mainframe abraça o open source
2020+	Git + Jenkins + API REST	A força se equilibra

---

☕ 8. Dicas do Mestre Bellacosa

• Sempre compile com mensagens ativas: use LIST, XREF no compilador — são o “lint” do COBOL.

• Evite mexer direto no Loadlib: agora ele é gerado automaticamente — é o artefato, não o playground.

• Integre CICS e DB2 nos testes: DevOps não é só build, é comportamento de sistema.

• Zowe CLI é sua varinha mágica: automatize submissão de JCL, consulta a spool e deploys sem entrar no ISPF.

---

🧩 9. O Lado Oculto da Força (Curiosidades)

• O primeiro pipeline DevOps para COBOL foi rodado na IBM Poughkeepsie Labs, em um z13 — com sucesso total, sem um único abend.

• Algumas empresas usam Docker simulando z/OS via ZD&T (z Development & Test Environment).
  Sim, é possível rodar um “mini mainframe” dentro de um laptop gamer! 🎮

• O termo “Mainframe Modernization” virou moda — mas quem entende sabe que modernizar ≠ migrar.
  O segredo é integrar, não substituir.

---

🌌 10. Conclusão: O Mainframe Nunca Dorme

O DevOps não é o fim do legado — é o elo entre gerações.
Hoje, um pull request pode acionar um JCL SUBMIT, e um commit pode atualizar um CICS.
O Mainframe não ficou velho: ele apenas aprendeu a conversar com os jovens.

“O Mainframe não é um dinossauro.
É o dragão que aprendeu a voar em nuvens.” 🐉☁️

 

 

Bellacosa Mainframe apresenta a Cronologia do DEVOps no IBM Mainframe

Cronologia do DEVOPS no IBM Mainframe Z

📅 2012 (± 1 ano)

📌 Por que 2012?

Porque é nesse período que três pilares do DevOps começam a convergir de forma consistente no ecossistema IBM Z:

---

🔹 1. Adoção real de Agile no mainframe (2010–2012)

• Grandes ambientes z/OS passam a adotar Scrum/Kanban para times COBOL, PL/I e Assembler.

• Integração de ferramentas como:

  • Endevor

  • Changeman

  • ISPW

• Começa a quebra do modelo puramente “batch noturno + releases trimestrais”.

👉 Sem Agile, DevOps não existe.

---

🔹 2. Automação de build e deploy (2012–2014)

• Surgimento e adoção de:

  • IBM Dependency Based Build (DBB) (embrião)

  • JCL generation automática

  • Rational Team Concert (RTC) com pipelines

• UrbanCode Deploy (adquirido pela IBM em 2013) passa a ser usado também para z/OS.

👉 Aqui nasce o “Ops automatizado” no mainframe.

---

🔹 3. Integração com ferramentas distribuídas (2013–2015)

• Introdução gradual de:

  • Git como sistema de versionamento (substituindo ou convivendo com PDS/Endevor)

  • Jenkins chamando jobs z/OS

  • REXX e scripts como glue entre mundos

👉 Esse é o ponto onde o mainframe entra oficialmente no pipeline DevOps corporativo.

---

🔹 Marco simbólico importante

📍 2013–2014

• Lançamento e evolução do z/OSMF Workflows

• Primeiros pipelines CI/CD híbridos (Linux + z/OS)

• Mainframe deixa de ser “ilha” e vira plataforma DevOps

---

📚 Linha do tempo resumida

Ano	Marco
2008–2010	Agile começa a tocar o mainframe
2012	🔥 Início teórico do DevOps no IBM Z
2013	UrbanCode + RTC no z/OS
2014	z/OSMF workflows
2015–2017	Git, Jenkins, DBB, pipelines modernos
2018+	DevOps corporativo completo no IBM Z

---

🧠 Definição acadêmica possível

“DevOps no IBM Z começou quando práticas Agile, automação de deploy e integração contínua passaram a ser aplicadas sistematicamente ao ciclo de vida de aplicações z/OS.”

📌 Ano de referência: 2012

 

Bellacosa Mainframe apresenta CI CD e DEVOPS 

🚀 CI/CD & DevOps

Uma análise Bellacosa Mainframe (com história, bastidores e verdades inconvenientes)

“Automatize tudo. O que sobrar, automatize de novo.”
— Filosofia não oficial do DevOps

CI/CD não é moda, não é ferramenta, não é YAML bonito no GitHub.
É mudança cultural, redução de sofrimento humano e, principalmente, fim do deploy manual de sexta-feira às 18h.

---

🧠 CI e CD: irmãos, não gêmeos

🔁 Continuous Integration (CI)

CI nasceu para resolver um problema clássico:

“Funciona na minha máquina.”

CI é integração contínua de código, feita com:

• branches curtas

• commits frequentes

• pull requests pequenos

• testes automáticos

👉 Resultado?
Menos conflito, menos retrabalho e menos ódio entre desenvolvedores.

📌 Fases clássicas da CI

• Plan – o que vamos fazer

• Code – escrever o código

• Build – compilar / empacotar

• Test – validar automaticamente

💡 Dica Bellacosa:
Se seu pipeline de CI demora mais que um café passado na hora… algo está errado ☕

---

🚚 Continuous Delivery (CD)

CD entra depois da CI, quando o código já funciona.

CD garante que:

• o software esteja sempre pronto para produção

• o deploy seja repetível, confiável e sem drama

• humanos não fiquem clicando “Next, Next, Finish”

📌 Fases clássicas da CD

• Release – versionamento

• Deploy – entrega automatizada

• Operate – operação e monitoramento

⚠️ Atenção:
CD ≠ Continuous Deployment

• Delivery: pronto para produção

• Deployment: vai direto para produção (sem pedir bênção)

---

🧬 CI/CD como código: o YAML que manda na sua vida

Quando pipelines viram código:

• versionamento acontece

• rollback fica fácil

• auditoria fica feliz

🧾 GitHub Actions

📅 Lançamento: novembro de 2019

• Já vem em todo repositório GitHub

• Usa YAML

• Marketplace recheado de actions prontas

📂 Estrutura clássica:

.github/
 └── workflows/
      └── pipeline.yml

💬 Comentário Bellacosa:
“Pipeline que não está versionado é script secreto de sysadmin disfarçado.”

---

🧑‍🤝‍🧑 Social Coding: menos ego, mais qualidade

CI/CD só funciona bem quando:

• pull requests são pequenos

• revisão é colaborativa

• erro vira aprendizado, não caça às bruxas

📈 Benefícios reais:

• código melhor

• menos bugs em produção

• mais confiança no deploy

🧠 Curiosidade:
Empresas que adotam CI de verdade fazem deploy dezenas de vezes por dia.
Quem não adota… faz change freeze 😬

---

🧱 Infraestrutura como Código (IaC)

📅 Conceito popularizado: ~2011 (com Puppet, Chef, depois Terraform)

IaC permite:

• subir ambientes em minutos

• destruir tudo e recriar sem chorar

• versionar infraestrutura

💡 Dica de ouro:
Se você não consegue recriar seu ambiente do zero… você não controla seu ambiente.

---

⚙️ Tekton: CI/CD raiz, Kubernetes feelings

📅 Lançamento: 2018 (Knative Build → Tekton)

Tekton é:

• CI/CD nativo Kubernetes

• Declarativo

• Baseado em CRDs

🧩 Conceitos-chave

• Task – unidade de trabalho

• Pipeline – encadeamento

• Step – comando

• Trigger – evento externo

• PipelineRun – execução real

💬 Fofoquinha técnica:
Tekton é poderoso, mas não é para iniciantes.
Quem aprende… vira referência. Quem não aprende… chama de “complicado demais”.

---

🔄 GitOps & Argo CD: Git manda, cluster obedece

📅 Argo CD: 2018

GitOps segue um princípio simples:

“Se não está no Git, não existe.”

Argo CD:

• observa o Git

• compara com o cluster

• reconcilia automaticamente

🔥 Easter Egg GitOps:
Deletou algo no cluster manualmente?
O Argo recria… sem pedir desculpa 😈

---

☁️ OpenShift Pipelines & GitOps

OpenShift:

• integra Tekton nativamente

• facilita CI/CD corporativo

• conversa bem com Argo CD

📌 Padrões GitOps suportados:

• On-Cluster Reconciler

• External Reconciler

💬 Comentário Bellacosa:
Mainframe tinha controle, rastreabilidade e auditoria antes de ser cool.
DevOps só deu nome bonito.

---

🔐 Compliance contínua: segurança sem freio de mão

Pipeline moderno inclui:

• scan de código

• scan de imagem

• gestão de segredos

• trilha de auditoria

💡 Dica de sobrevivência:
Segurança manual não escala.
Compliance contínua sim.

---

🧨 Verdades inconvenientes (Bellacosa Edition)

• Ferramenta não salva cultura ruim

• CI quebrado diariamente não é CI

• Pipeline lento é gargalo oculto

• Deploy manual é dívida técnica

• YAML sem comentário é armadilha futura

---

🧠 Conclusão Bellacosa Mainframe

CI/CD não é sobre:
❌ Jenkins
❌ GitHub Actions
❌ Tekton
❌ Argo CD

É sobre:
✅ previsibilidade
✅ automação
✅ qualidade
✅ confiança
✅ dormir tranquilo após o deploy

“O melhor deploy é aquele que ninguém percebe.”

 

Bellacosa Mainframe apresenta DEVOPS e Modernização IBM Z

Bellacosa Mainframe: Série DevOps e Modernização no IBM Z

---

1️⃣ DevOps no IBM Z – Pipeline E2E com GitLab e DBB

Origem:
O pipeline end-to-end no mainframe integra GitLab, IBM DBB, IDz, UrbanCode Deploy e ADDI. Ele automatiza desde o coding até o monitoring, garantindo qualidade e velocidade na entrega.

Exemplo:

• Desenvolvedor altera um módulo COBOL

• DBB identifica dependências

• Jenkins compila apenas os módulos impactados

• UrbanCode Deploy publica o artefato nos ambientes de teste/prod

• IZOA (IBM Z Operational Analytics) monitora métricas em tempo real

Dicas:

• Use build incremental do DBB para reduzir tempo

• Crie repositórios de componentes separados para acelerar deploys

• Monitore cada fase com dashboards GitLab/IDz

Curiosidades & Easter Eggs:

• Em grandes bancos, pipelines E2E reduzem meses de entrega para semanas

• Alguns times chamam o DBB de “o Sherlock Holmes do COBOL” por identificar dependências invisíveis

Fofoquices:

• Equipes que adotam CI/CD moderno relatam menos reuniões de emergência às sextas-feiras.

---

2️⃣ Migrando z/OS para Git – Code Page & Copybooks

Origem:
A migração de código z/OS para Git envolve conversão de code pages (EBCDIC → ASCII) e gestão de copybooks compartilhados.

Exemplo:

• Migrar 1000 módulos COBOL

• DBB inicializa metadados de dependências

• Copybooks são publicados via UrbanCode Deploy garantindo compatibilidade

Dicas:

• Configure triggers de publicação de copybooks no pipeline

• Use repos Git separados para código x copybooks

• Automatize conversão de code pages para evitar erros silenciosos

Curiosidades & Easter Eggs:

• Alguns copybooks têm nomes que datam da década de 80 – um verdadeiro “Fósseis do COBOL”

• Git permite versionar copybooks e gerar histórico de mudanças detalhado, algo impossível no Changeman

Fofoquices:

• Times antigos choram quando veem um merge automático de copybooks funcionando perfeitamente — “parece mágica”.

---

3️⃣ Branching e Release-Based Development

Origem:
Modelos de branching em mainframe podem ser complexos. O uso de Feature, Development e Release branches permite controle fino e CI/CD confiável.

Exemplo:

• Branch Feature: desenvolvedor adiciona nova função

• Branch Development: integração com outros módulos

• Branch Release: build completo e deploy controlado

Dicas:

• Não use branch única em produção

• Faça merges frequentes para reduzir conflitos

• Adote release-based workflow para previsibilidade

Curiosidades & Easter Eggs:

• Alguns times chamam o branch de Release de “a linha da vida”, porque qualquer erro ali pode travar todo o mainframe

• Git no Z permite trazer práticas modernas para décadas de código legado

Fofoquices:

• Programadores mais antigos ainda guardam planilhas de branches antigas “para o caso de emergência”

---

4️⃣ IBM ADDI – Business Rule Discovery e Integração CI/CD

Origem:
ADDI permite descobrir regras de negócio ocultas em sistemas legados, mapear dependências e alimentar pipelines CI/CD.

Exemplo:

• Projeto de exemplo gera workbook de regras de negócio

• Keywords são mapeadas e inventário de termos é criado

• Pipeline Jenkins lê essas informações para validar mudanças

Dicas:

• Integre ADDI antes do build para shift-left

• Gere inventário de pacotes de negócio para rastreabilidade

• Use ADDI junto com DBB para builds inteligentes

Curiosidades & Easter Eggs:

• Alguns nomes de regras vêm de decisões dos anos 70 – dá para descobrir a história da empresa!

• Ferramenta ajuda a revelar “regra oculta” que ninguém sabia que existia

Fofoquices:

• Times chamam ADDI de “detective de regras”. Quando falha, todo mundo olha para o DBA como se fosse culpado.

---

5️⃣ Azure DevOps + Wazi as a Service no IBM Z

Origem:
Com Wazi aaS e Azure DevOps, é possível provisionar instâncias z/OS na nuvem e integrá-las em pipelines modernos.

Exemplo:

• IDz conectado a Wazi aaS

• Git + Azure DevOps Pipeline executa build e deploy

• Time remoto pode trabalhar sem precisar acessar LPAR físico

Dicas:

• Wazi aaS acelera onboarding de novos desenvolvedores

• Padronize pipelines híbridos para mainframe + cloud-native

• Aproveite isolamento de ambientes para testes seguros

Curiosidades & Easter Eggs:

• O nome Wazi vem do termo “simplicidade” em alguns dialetos africanos

• Times contam que criar instância z/OS em nuvem é mais rápido que abrir café no mainframe físico

Fofoquices:

• Novos devs acham mágico ver COBOL compilando em cloud, achando que o mainframe “viajou no tempo”.

---

6️⃣ Testes Unitários e Code Coverage no IBM Z

Origem:
O uso de zUnit e Code Coverage integrado ao CI/CD é essencial para qualidade e confiabilidade.

Exemplo:

• zUnit executa testes unitários

• DBB identifica módulos impactados

• Code Coverage gera métricas e falha o build se critério mínimo não for atendido

Dicas:

• Configure build incremental para testes rápidos

• Versione testes no Git como qualquer outro código

• Combine zUnit + DBB + Jenkins para pipeline robusto

Curiosidades & Easter Eggs:

• COBOL unit tests eram considerados “impossíveis” até alguns anos atrás

• Alguns times chamam zUnit de “pequeno herói silencioso”, porque pega bugs que ninguém percebe

Fofoquices:

• Equipes que adotam testes unitários relatam menos reuniões de emergência às sextas-feiras (repetido, mas verdadeiro!).

---

7️⃣ Packaging e Deployment Modernos

Origem:
Para CI/CD moderno, é crucial desacoplar build, packaging e deploy, usando repositórios de artefatos e componentização.

Exemplo:

• Build → Package → Deploy em pipeline desacoplado

• Artifact Repository armazena pacotes prontos para múltiplos ambientes

• UrbanCode Deploy realiza deploy controlado e rastreável

Dicas:

• Crie artefatos versionados

• Mantenha build independente do deploy

• Adoção de padrões reduz falhas em produção

Curiosidades & Easter Eggs:

• Alguns times chamam artefatos versionados de “legado moderno”

• Pipeline desacoplado permite experimentar deploy em paralelo sem arriscar produção

Fofoquices:

• Desenvolvedores que criam pipelines desacoplados ganham fama de “magos do COBOL” no time

---

✅ Resumo do Estilo Bellacosa Mainframe

O que aprendemos nesta série:

1. Pipelines E2E + GitLab + DBB aumentam produtividade e confiabilidade

2. Migração para Git requer atenção a code pages e copybooks

3. Branching e release-based workflows tornam CI/CD previsível

4. ADDI descobre regras de negócio e alimenta pipelines

5. Wazi aaS + Azure DevOps traz mainframe para a nuvem

6. zUnit + Code Coverage garante qualidade e shift-left

7. Build, packaging e deploy desacoplados promovem flexibilidade

Curiosidades gerais:

• Alguns copybooks têm mais de 40 anos

• Pipelines modernos reduzem meses de entrega para dias

• Ferramentas modernas tornam mainframe mais “cool” para novos devs

Easter Eggs & Fofoquices:

• Times chamam DBB de Sherlock Holmes

• ADDI de detective de regras

• zUnit de herói silencioso

• Artefatos versionados de “legado moderno”

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

---