Bellacosa Mainframe apresenta o motor do DB2 a algebra relacional

---

🔷 Relational Algebra no Mainframe

Uma viagem raiz pelo coração do DB2 (IBM Mainframe Edition)

Se você trabalha — ou sonha em trabalhar — com IBM Mainframe, cedo ou tarde vai ouvir um termo que parece saído de um livro de matemática dos anos 70:

👉 Relational Algebra

Calma. Respira.
Não é um bicho de sete cabeças.
É, na verdade, a Força por trás do SQL.

Antes de existir SELECT * FROM SYSIBM.SYSDUMMY1, alguém precisou pensar como os dados se relacionam. Esse alguém foi Edgar F. Codd, lá na IBM, em 1970. Sim, tudo isso nasceu dentro da IBM — respeita o mainframe. 🖥️

---

🕰️ Um pouco de história (porque mainframe sem história não é mainframe)

Nos anos 60 e 70:

• Arquivos eram sequenciais

• Relatórios demoravam horas

• Qualquer mudança era dor e sofrimento

Então a IBM apresentou o Modelo Relacional:

• Dados em tabelas

• Relações matemáticas

• Independência entre dados e programas

E para manipular essas tabelas, surgiu a Relational Algebra — uma linguagem conceitual, não escrita diretamente no sistema, mas usada pelo otimizador do DB2 por baixo dos panos.

💡 Easter Egg:
Quando você escreve SQL no DB2, o que o banco realmente executa internamente é Relational Algebra otimizada.

---

⚙️ Os 5 operadores essenciais (o sabre de luz do DBA)

Vamos aos clássicos:

---

1️⃣ Projection (π) — “Me mostra só o que eu preciso”

📌 O que faz
Seleciona colunas específicas de uma tabela.

📘 Conceito:

π (COLUNA1, COLUNA2)

🧠 Tradução DB2:

SELECT COLUNA1, COLUNA2
FROM TABELA;

🖥️ Exemplo Mainframe:

SELECT EMPNO, LASTNAME
FROM EMP;

💡 Dica Bellacosa:

Projection reduz I/O.
Menos coluna = menos leitura = batch mais rápido = operador feliz.

---

2️⃣ Selection (σ) — “Filtra isso aí”

📌 O que faz
Seleciona linhas com base em uma condição.

📘 Conceito:

σ (SALARY > 50000)

🧠 Tradução DB2:

SELECT *
FROM EMP
WHERE SALARY > 50000;

💡 Easter Egg:

WHERE é Selection.
Sempre foi. Sempre será.

---

3️⃣ Union (∪) — “Junta tudo, mas sem duplicar”

📌 O que faz
Concatena duas relações compatíveis (mesmas colunas).

📘 Conceito:

R ∪ S

🧠 Tradução DB2:

SELECT EMPNO FROM EMP_2023
UNION
SELECT EMPNO FROM EMP_2024;

⚠️ Alerta Mainframe:

• UNION remove duplicados

• UNION ALL é mais rápido (menos CPU)

💡 Dica de ouro:

Em batch pesado, pense duas vezes antes de usar UNION sem ALL.

---

4️⃣ Product (×) — “Multiplicação que dá dor de cabeça”

📌 O que faz
Combina todas as linhas de uma tabela com todas as linhas da outra.

📘 Conceito:

R × S

🧠 Tradução SQL (implícita):

SELECT *
FROM EMP, DEPT;

😱 Resultado:

• 100 funcionários × 10 departamentos = 1000 linhas

💡 Bellacosa comenta:

Cartesian Product é tipo JCL sem COND.
Pode até rodar… mas você vai se arrepender.

---

5️⃣ Natural Join (⨝) — “O casamento perfeito”

📌 O que faz
Relaciona tabelas usando colunas comuns automaticamente.

📘 Conceito:

EMP ⨝ DEPT

🧠 Tradução DB2:

SELECT *
FROM EMP
JOIN DEPT
ON EMP.DEPTNO = DEPT.DEPTNO;

💡 Easter Egg Mainframe:

Todo JOIN começa como um Product + Selection.
O DB2 só faz isso de forma inteligente pra você.

---

🧪 Exemplo prático estilo chão de fábrica

🎯 Objetivo:
Listar nome do funcionário e nome do departamento para quem ganha mais de 60k.

🧠 Relational Algebra:

1. Selection (salário)

2. Join (EMP + DEPT)

3. Projection (nome + depto)

🖥️ DB2 SQL:

SELECT E.LASTNAME, D.DEPTNAME
FROM EMP E
JOIN DEPT D
  ON E.DEPTNO = D.DEPTNO
WHERE E.SALARY > 60000;

💡 O DB2 otimiza isso usando Relational Algebra internamente.

---

🧙 Primeiros passos para Padawans do Mainframe

Se você está começando:

✅ Entenda Selection vs Projection
✅ Saiba quando usar JOIN vs UNION
✅ Evite Cartesian Product sem intenção
✅ Pense sempre em I/O e CPU
✅ Lembre-se: SQL é declarativo, mas o DB2 pensa em álgebra

📚 Estude:

• DB2 Explain Plan

• Access Path

• Index usage

---

🏁 Conclusão Bellacosa Style

Relational Algebra não é coisa velha.
É fundação.

Enquanto linguagens vêm e vão,
o DB2 continua rodando batch crítico,
pagando salários,
processando bancos,
e sustentando o mundo corporativo.

E por baixo de tudo isso?

👉 Projection, Selection, Union, Product e Natural Join.

Que a Força (e o z/OS) esteja com você. 🖥️✨

 

Bellacosa Mainframe apresenta Auditoria no IBM SMP/E

📋 Checklist de Auditoria SMP/E

O que o auditor pergunta (e o que você precisa provar)

“Auditor não quer opinião.
Quer evidência.”

---

🧠 Objetivo do checklist

Garantir que:

• O z/OS está íntegro

• A manutenção é controlada

• As mudanças são rastreáveis

• O ambiente é auditável

👉 SMP/E é prova técnica, não discurso.

---

🔐 1. Controle de Acesso (RACF / ACF2 / TSS)

✔ CSI protegido (UACC=NONE)
✔ ALTER restrito a sysprogs autorizados
✔ READ para auditoria
✔ Logging ativo
✔ Revisão periódica de acessos

📌 Evidência:

• LISTDSD

• Relatórios RACF

• Perfis ativos

---

📦 2. Proteção das bibliotecas SMP/E

✔ TARGET libraries protegidas
✔ DLIB libraries protegidas
✔ SMPTLIB, SMPMTS, SMPPTS controlados
✔ Separação TEST / PROD

📌 Evidência:

• RACF profiles

• Dataset attributes

---

🔁 3. Processo RECEIVE / APPLY / ACCEPT

✔ RECEIVE documentado
✔ APPLY CHECK executado
✔ APPLY validado em teste
✔ ACCEPT autorizado formalmente

📌 Evidência:

• Outputs SMP/E

• JCL versionado

• Change records

---

🚨 4. Gestão de ++HOLD e ++ERROR

✔ HOLDS analisados
✔ Decisão documentada
✔ ERROR tratados com cautela
✔ Mitigações registradas

📌 Evidência:

• PTF cover letters

• APARs

• Decisões de risco

---

🧩 5. Gestão de USERMOD

✔ USERMOD documentado
✔ Justificativa formal
✔ Controle de APPLY/ACCEPT
✔ Revisão periódica

📌 Evidência:

• SYSMOD history

• Documentação técnica

---

🧪 6. APPLY CHECK (obrigatório)

✔ APPLY CHECK sempre executado
✔ Resultados arquivados
✔ Conflitos analisados

📌 Evidência:

• Output APPLY CHECK

• Aprovação formal

---

🧱 7. Controle de DLIB (baseline)

✔ DLIB atualizado
✔ ACCEPT consciente
✔ Baseline consistente
✔ DLIB protegido

📌 Evidência:

• CSI

• Relatórios SMP/E

---

🔄 8. Capacidade de RESTORE

✔ Processo definido
✔ Histórico preservado
✔ Testes de rollback
✔ Documentação clara

📌 Evidência:

• JCL RESTORE

• Registros históricos

---

🧠 9. Atualização e Segurança

✔ PTFs de segurança aplicados
✔ CVEs avaliados
✔ Backlog controlado
✔ Plano de atualização

📌 Evidência:

• Relatórios IBM

• Histórico SMP/E

---

🧾 10. Evidências e documentação

✔ Outputs armazenados
✔ Logs disponíveis
✔ Histórico preservado
✔ Responsáveis identificados

📌 Evidência:

• CSI

• JCL

• Relatórios

---

🚨 Red flags para auditor

❌ ALTER irrestrito
❌ ACCEPT sem teste
❌ USERMOD esquecido
❌ CSI sem proteção
❌ Falta de APPLY CHECK

👉 Tudo isso gera não conformidade.

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• SMP/E é trilha de auditoria nativa

• Segurança começa no controle de mudança

---

🧾 Comentário final – Checklist SMP/E

Quem tem SMP/E bem cuidado
não teme auditoria.

📋 Checklist de Auditoria SMP/E, no estilo Bellacosa Mainframe, pensado para auditoria interna, externa, SOX, PCI, ISO, ou simplesmente para dormir tranquilo. 

📋💾🛡️

☕ Um Café no Bellacosa Mainframe — z/OS 1.11: o sistema operacional que trouxe o mainframe para a era da automação e integração inteligente

☕ Um Café no Bellacosa Mainframe — z/OS 1.11: o sistema operacional que trouxe o mainframe para a era da automação e integração inteligente

---

🕰️ Ano de lançamento

O IBM z/OS 1.11 foi lançado em setembro de 2009, acompanhando o System z10 e já projetado para explorar os novos recursos do futuro zEnterprise z196.
Essa versão marcou o início de uma nova filosofia da IBM: transformar o mainframe em uma plataforma de nuvem corporativa, com automação, padronização e serviços integrados.

Se o z/OS 1.9 foi o cérebro que aprendeu a se ajustar, o 1.11 foi o que começou a conversar com o mundo — do batch ao web service, do COBOL ao Java.

---

⚙️ Introdução técnica

O z/OS 1.11 foi uma das versões mais importantes na linha evolutiva do sistema operacional da IBM.
Seu foco foi automação, integração e modernização de workloads, incluindo:

• Melhorias em Parallel Sysplex, WLM e Sysplex Distributor;

• Suporte estendido para Java 6 e J2EE workloads;

• Inovação com o z/OS Management Facility (z/OSMF) — a primeira interface web administrativa nativa;

• Preparação do sistema para ambientes de nuvem privada com gerenciamento centralizado.

Foi o primeiro passo concreto rumo ao conceito de z/OS como um serviço, uma base sólida para DevOps e administração simplificada.

---

🧠 Avanços na memória e arquitetura

O z/OS 1.11 consolidou o uso inteligente da memória com diversas melhorias:

• Suporte ampliado ao 64-bit Real Memory (memória física acima de 2 TB nos novos mainframes);

• Introdução de Large Memory Workload Management, otimizando o balanceamento entre LPARs e processadores zIIP/zAAP;

• Novo modelo de páginas grandes (1MB e 2GB) — reduzindo TLB misses e melhorando performance para Java, DB2 e IMS;

• HiperDispatch aprimorado, permitindo que o sistema entenda afinidade entre processadores e cache L3 — essencial no z10.

Esses avanços permitiram que o z/OS 1.11 alcançasse níveis inéditos de throughput e paralelismo, mantendo latência mínima mesmo sob carga mista (CICS, batch e WebSphere simultaneamente).

---

🧩 Aplicativos internos e softwares embarcados

O ecossistema do z/OS 1.11 foi um verdadeiro salto de modernização.
Alguns destaques:

• z/OS Management Facility (z/OSMF):
  Primeira interface web oficial para administração do sistema, com painéis para automação, diagnóstico, configuração e gerenciamento de políticas WLM.
  Simplificou tarefas antes realizadas apenas via TSO/ISPF.

• RACF (Security Server):
  Suporte a Kerberos, LDAPv3 aprimorado, autenticação forte e integração com certificados X.509 e tokens digitais.
  Introduziu segurança contextual (baseada em aplicação e identidade).

• DFSMS:
  Recursos de automated data tiering e policy management que ajustam classes de armazenamento automaticamente conforme o uso.
  O sistema agora entende se um dataset é “quente” (muito acessado) ou “frio”.

• JES2/JES3:
  Novas funções de checkpoint automático, otimização de spool e integração direta com WLM.
  Suporte a batch pipes aprimorado — essencial em grandes ambientes financeiros.

• RMF (Resource Measurement Facility):
  Painéis gráficos via z/OSMF e suporte a monitoramento em tempo real.
  Agora o RMF conversa com o WLM, ajudando a ajustar prioridades de forma preditiva.

• UNIX System Services (USS):
  Suporte a NFSv4, POSIX Threads 2008, 64-bit shared libraries e novas APIs para Java e CICS TS 4.1.
  O USS finalmente se torna um “Unix de verdade” dentro do z/OS.

---

🔬 Instruções de máquina e PR/SM

Com o System z10, o z/OS 1.11 pôde explorar um conjunto poderoso de novas instruções:

• Decimal Floating Point (DFP) — um divisor de águas para cargas financeiras e científicas, agora executadas nativamente em hardware.

• Improved Branch Prediction e Pipeline Control, otimizando ciclos por instrução.

• Criptografia CPACF v3 com suporte a SHA-2 e AES-256 de alta velocidade.

• Hardware-based time synchronization (STCKE) — precisão de microssegundos entre LPARs.

No firmware, o PR/SM ganhou refinamentos que transformaram a administração:

• Dynamic Logical Processor Management, permitindo ligar/desligar CPUs sem IPL;

• Group Capacity Capping Inteligente, ajustando limites conforme a carga;

• HiperDispatch Awareness — o PR/SM entende quais threads se beneficiam de caches próximos, reduzindo cross-LPAR latency.

Essas mudanças deram ao z/OS 1.11 o status de sistema operacional consciente de hardware, capaz de usar cada ciclo de CPU de forma estratégica.

---

🧮 Créditos de CPU e virtualização

O z/OS 1.11 trouxe um dos avanços mais finos em gerenciamento de CPU:

• O WLM (Workload Manager) foi redesenhado para funcionar com HiperDispatch e PR/SM inteligente.

• Créditos de CPU dinâmicos agora são realocados em tempo real com base em service classes e goals.

• Integração mais profunda com zAAPs e zIIPs, permitindo que workloads Java e DB2 usem processadores especializados sem penalizar o uso geral.

• Introdução do Soft Capping Dinâmico 2.0 — controle fino de MIPS por LPAR com base em carga real, não apenas limite estático.

Esse conjunto de recursos transformou o z/OS 1.11 em um ambiente de computação previsível, otimizado e autocorretivo.

---

🧭 Curiosidades e bastidores

• O projeto interno da IBM foi apelidado de “Aurora”, simbolizando o nascer de uma nova era de gerenciamento visual e automação.

• O z/OS 1.11 foi o primeiro sistema operacional IBM com interface web embarcada (z/OSMF) — um marco histórico.

• Também foi a primeira versão compatível nativamente com Java 6, o que revolucionou o uso do WebSphere Application Server no mainframe.

• O RMF começou a gerar dados exportáveis via XML e HTTP, prenúncio da integração com ferramentas de monitoramento modernas.

---

☕ Dica Bellacosa Mainframe

Quer ver o z/OS conversar com o operador?
O z/OSMF é o ponto de virada. Se você nunca testou, vale rodar em um zPDT ou zD&T.
Além disso, o z/OS 1.11 é excelente para quem quer entender a transição do mainframe clássico (verde e 3270) para o mundo Web, API e automação.

---

📜 Resumo técnico rápido

Item	Descrição
Versão	z/OS 1.11
Ano de lançamento	2009
Hardware principal	IBM System z10 / início do z196
Arquitetura	z/Architecture (64-bit total)
PR/SM	Dynamic LPAR, HiperDispatch, Soft Capping 2.0
Instruções novas	Decimal Floating Point, SHA-2, AES-256
WLM	HiperDispatch-aware, credit realocation em tempo real
Segurança	RACF com Kerberos e autenticação forte
Rede	NFSv4, IPv6, IPsec e QoS avançado
Curiosidade	Primeira versão com z/OSMF (interface web nativa)

---

💬 “O z/OS 1.11 não apenas gerenciava o mainframe — ele aprendeu a mostrá-lo ao mundo.”

🌍 Tricksters do Mundo

Bellacosa Mainframe revisa e encontra os Tricksters 

🌍 Tricksters do Mundo

Explicados para Mainframers (com logs, falhas e bypass autorizados pelo caos)

Se o mundo fosse um mainframe cósmico, os tricksters seriam aqueles programas que:

• Não seguem o fluxo esperado

• Exploram regras mal definidas

• Nunca causam ABEND técnico, só ABEND moral

• E sempre deixam o operador confuso olhando o SYSOUT

Eles não são heróis clássicos.
Não são vilões tradicionais.
São testes de stress ambulantes do sistema social, divino e humano.

---

🧠 O que é um Trickster? (definição estilo manual IBM)

Trickster é um arquétipo universal que aparece em praticamente todas as culturas humanas.

Características comuns:

• Inteligência acima da média

• Moral flexível (ISO = UR total)

• Uso de ironia, mentira e ambiguidade

• Capacidade de virar o jogo sem força

• Exposição das falhas do sistema

📌 Em linguagem mainframe:

Tricksters existem para provar que a regra estava errada, não o código.

---

⚙️ Trickster ≠ Hacker (mas quase)

Comparação rápida:

Hacker	Trickster
Explora falha técnica	Explora falha humana
Precisa de acesso	Precisa de arrogância alheia
Pode ser barrado	Sempre passa
Age oculto	Age à vista de todos

O trickster não invade.
Ele recebe permissão sem que o sistema perceba.

---

🌎 Tricksters pelo mundo (versão “data center global”)

🇧🇷 Pedro Malazarte – Brasil

Função: Auditor informal da desigualdade
Falha explorada: Ganância, ignorância, abuso de poder

Pedro segue ordens literalmente.
Resultado:

• Quem mandou se arrepende

• Ele sobrevive

• O sistema continua errado

➡️ Literal execution bug.

---

🇯🇵 Kitsune – Japão

Raposas mágicas que:

• Mudam de forma

• Enganam humanos

• Testam caráter

No Japão, o trickster é:

• Elegante

• Espiritual

• Ambíguo

Kitsune pune:

• Arrogância

• Falta de respeito

• Desejo excessivo

➡️ Security test espiritual.

---

🇳🇴 Loki – Mitologia Nórdica

O mais mainframe de todos.

Loki:

• Ajuda os deuses

• Quebra tudo

• Conserta depois

• Ou piora

Ele é:

• O desenvolvedor brilhante sem documentação

• O cara que resolve hoje e explode amanhã

➡️ Change sem CAB approval.

---

🇩🇪 Till Eulenspiegel – Alemanha

Especialista em:

• Interpretar ordens literalmente

• Humilhar autoridades com lógica pura

Exemplo clássico:

“Ensine as pessoas a ver.”

Ele pinta óculos nos muros.

➡️ Manual mal escrito, execução perfeita.

---

🇳🇬 Anansi – África Ocidental

Aranha-trickster.

Anansi:

• Usa histórias como arma

• Ensina lições morais

• Vence deuses maiores

É o DBA da narrativa:

• Controla quem sabe o quê

• Quando sabe

• E como usa

➡️ Gestão de conhecimento como poder.

---

🇨🇳 Sun Wukong – China (Rei Macaco)

Sim, o avô espiritual de Goku.

Sun Wukong:

• Engana o Céu

• Enfrenta burocracia divina

• Ri das regras cósmicas

Ele literalmente:

• Se recusa a aceitar hierarquia

• Burla imortalidade

• Sobrevive a punições absurdas

➡️ Usuário root no universo.

---

🇺🇸 Coyote – Povos indígenas norte-americanos

Coyote:

• Cria o mundo… errando

• Ensina falhando

• Aprende quebrando

Ele não é sábio.
Ele vira sábio depois do erro.

➡️ Ambiente de testes permanente.

---

🎌 Tricksters e Anime: não é coincidência

Todo fã de anime já conhece tricksters, mesmo sem chamar assim:

• Goku (início) → Sun Wukong

• Luffy → Trickster caótico

• Hisoka → Trickster sombrio

• Gojo → Quebra regras conscientemente

Anime ama tricksters porque:

• Eles desafiam hierarquia

• Crescem fora do sistema

• Revelam hipocrisia

➡️ Shōnen inteiro é um grande test case contra autoridade absoluta.

---

🧩 Easter eggs culturais

🥚 Tricksters quase sempre:

• Fingem ser burros

• Caem em armadilhas que eles mesmos criam

• Morrem… e voltam

• Nunca aprendem totalmente

🥚 Eles não querem destruir o sistema
👉 Querem mostrar que ele não funciona como promete

---

🧠 O Trickster no ambiente corporativo (cuidado!)

Existe o trickster moderno:

• O cara que responde e-mail literalmente

• O analista que segue processo ruim até quebrar

• O dev que pergunta “é isso mesmo?”

⚠️ Atenção:
Nem todo ambiente aceita tricksters.
Alguns preferem sistemas injustos funcionando do que sistemas questionados.

---

💬 Comentário Bellacosa Mainframe

Mainframers entendem tricksters porque vivem em ambientes onde:

• Regras antigas ainda mandam

• Documentação nem sempre reflete a realidade

• Quem entende o sistema sobrevive melhor que quem manda

O trickster é o COBOL humano:

• Velho

• Subestimado

• Mas essencial

---

🏁 Encerramento – JOB STATUS

Tricksters existem porque:

• Sistemas são feitos por humanos

• Humanos erram

• E alguém precisa provar isso sem derrubar tudo

Eles são:

• O riso no meio da opressão

• A inteligência do fraco

• O teste de integridade cultural

JOB FINALIZADO
RC=0
SYSOUT: “Sistema exposto, mas ainda rodando.”

📉 Por que o MS Project caiu em desuso nas equipes modernas?

Bellacosa Mainframe apresenta o fim do Ms Project

Ao estilo Bellacosa Mainframe — direto, pragmático e sem romantizar ferramenta legada:

---

📉 Por que o MS Project caiu em desuso nas equipes modernas?

O MS Project nasceu em um mundo onde planejar era mais importante do que aprender.
Projetos eram previsíveis, lineares e comandados por um Project Manager centralizador.
Esse mundo acabou.

Hoje, projetos mudam toda semana.
E o MS Project não lida bem com mudança constante.

---

⚙️ O que mudou no jogo

1️⃣ Do Plano Fixo para o Fluxo Contínuo

• MS Project → cronograma fechado, dependências rígidas

• Mundo atual → backlog vivo, prioridades dinâmicas

Atualizar um Gantt a cada mudança:

• consome tempo

• não gera valor

• cria falsa sensação de controle

---

2️⃣ Do Comando e Controle para Times Autônomos

• MS Project pressupõe:

  • um dono do plano

  • tarefas atribuídas de cima para baixo

• Agile / DevOps exigem:

  • auto-organização

  • visibilidade compartilhada

  • decisão no nível do time

O MS Project não conversa com times auto-geridos.

---

3️⃣ Planejamento por Datas vs Planejamento por Valor

• MS Project pergunta: “quando termina?”

• Agile pergunta: “qual valor entregamos agora?”

Hoje, valor entregue > cronograma perfeito.

---

🔁 Quem ocupou o lugar do MS Project?

O MS Project não teve um substituto direto.
Ele foi desmontado em partes.

🔹 Planejamento e Backlog

• Jira

• Azure DevOps

• Rally

👉 substituíram o planejamento detalhado por backlog priorizado

---

🔹 Fluxo de Trabalho

• Kanban Boards

• Trello

• Jira Boards

👉 substituíram o Gantt por fluxo visual em tempo real

---

🔹 Roadmap e Visão

• Product Roadmap

• Product Vision

• OKRs

👉 substituíram o cronograma mestre por direção estratégica flexível

---

🔹 Execução e Métricas

• Velocity

• Lead Time

• Cycle Time

• Burnup / Burndown

👉 substituíram o % completo do MS Project, que nunca refletiu a realidade

---

🧠 O verdadeiro motivo do desuso

O MS Project não é ruim.
Ele só resolve um problema que quase não existe mais.

Projetos previsíveis, estáveis, com escopo fechado.

Hoje temos:

• produto em evolução

• requisitos emergentes

• integração contínua

• entrega contínua

MS Project não acompanha ritmo de pipeline.

---

🧾 Onde o MS Project ainda sobrevive

Ele não morreu.
Virou ferramenta de exceção:

• Engenharia pesada

• Construção civil

• Infraestrutura tradicional

• Projetos regulatórios com escopo fechado

👉 Onde mudança é inimiga, não aliada.

---

🔚 Conclusão Bellacosa

MS Project planeja projetos.
Agile gerencia incerteza.

Quando a incerteza virou regra,
o MS Project virou peça de museu corporativo.

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.