Bellacosa Mainframe visita Akihabara

🗼 AKIHABARA – O MAINFRAME OTAKU DO JAPÃO

Se Tóquio fosse um datacenter, Akihabara seria aquele andar barulhento, cheio de LEDs piscando, cabos aparentes, cheiro de eletrônico quente… e personagens de anime te oferecendo panfleto na porta. Bem-vindo a Akihabara (秋葉原), ou simplesmente Akiba, o bairro que começou como loja de rádio e virou o hub definitivo da cultura otaku mundial.

---

🏯 ORIGEM – DO RÁDIO AO WAIFU

No pós-guerra, anos 1940–50, Akihabara nasceu como um mercado informal de eletrônicos.
Peças usadas, rádios, válvulas, fios — era o camelódromo high-tech da época.

📻 Décadas depois:

• anos 70–80 → eletrônicos e computadores

• anos 90 → videogames, PCs, doujinshi

• anos 2000 → anime, mangá, idols, maid cafés

Ou seja: Akihabara evoluiu como software legado bem mantido.

---

👀 O QUE VER (DEBUG VISUAL)

🔹 Lojas de eletrônicos (Yodobashi Camera – um monstro)
🔹 Prédios de 6 a 10 andares, cada piso um universo
🔹 Arcades gigantes (SEGA, Taito, GIGO)
🔹 Vitrines absurdas com figures raríssimas
🔹 Placas neon disputando atenção como batch concorrente

---

🎮 O QUE FAZER (INTERACTIVE MODE)

✔ Caçar figures (novas e usadas)
✔ Jogar claw machines até perder a dignidade
✔ Entrar em lojas de doujin (mangas independentes)
✔ Explorar andares escondidos (EASTER EGGS reais)
✔ Fotografar cosplayers (com respeito!)

💡 Dica Bellacosa: sempre olhe os andares de cima. O tesouro nunca está no térreo.

---

🍜 O QUE COMER (BUFFER DE ENERGIA)

🍛 Curry japonês
🍜 Ramen temático
🍙 Onigiri raiz
🍺 Bares minúsculos escondidos
☕ Maid cafés (experiência cultural — não é só zoeira)

👉 Maid café é tipo CICS: quem não conhece acha estranho, quem entende respeita.

---

🧠 CURIOSIDADES & EASTER EGGS

🟡 Algumas lojas vendem hardware obsoleto funcional
🟡 Tem prédios inteiros só de um único jogo
🟡 Muitas lojas mudam layout semanalmente
🟡 Mangás pornôs ficam separados (com censura pixelada 😏)
🟡 Você pode comprar um parafuso raro ou uma waifu em escala 1/4

---

🧩 AKIHABARA EM ANIMES

📺 Aparece em:

• Steins;Gate (literalmente o coração da história)

• Love Live

• Durarara!!

• Oreimo

• Genshiken

Em anime, Akiba é sempre:
➡️ lugar de encontros
➡️ caos criativo
➡️ refúgio dos “estranhos”
➡️ palco de revelações

---

🧠 COMENTÁRIO BELLACOSA

Akihabara não é só consumo.
É pertencimento.

Ali ninguém te julga por:

• gostar de coisa velha

• colecionar obsessivamente

• se apaixonar por pixels

• viver em universos paralelos

Akihabara entende legado, respeita versão antiga e celebra customização extrema.

---

🏁 CONCLUSÃO

Akihabara é:

• um Sysplex cultural

• um cluster de paixões

• um mainframe humano

Não é bairro.
É estado de espírito.

E como todo bom sistema antigo:
faz barulho, esquenta…
mas nunca cai.

🗼💾

 

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

---