☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

sábado, 2 de agosto de 2008

Koihime†Musou — Quando o Romance dos Três Reinos Caiu num Compilador Moe

Bellacosa Mainframe apresenta o anime koihime musou

☕ Um Café no Bellacosa Mainframe

Koihime†Musou — Quando o Romance dos Três Reinos Caiu num Compilador Moe

⚔️ O anime que pegou Guan Yu, Cao Cao e companhia, executou GENDER-SWAP, acrescentou ecchi, removeu o protagonista do eroge e descobriu que a China antiga podia funcionar como uma road movie de garotas armadas

Há animes cuja premissa você explica facilmente.

Ghost in the Shell: identidade, tecnologia e consciência.

Cowboy Bebop: caçadores de recompensa, jazz e melancolia.

Koihime†Musou?

Bem...

Pegue Romance dos Três Reinos, uma das obras fundamentais da literatura chinesa. Transforme boa parte dos grandes generais e estrategistas em garotas bishōjo. Acrescente comédia, ação, fanservice, amizade feminina e personagens moe. Depois adapte tudo de uma visual novel originalmente adulta, retire justamente o protagonista masculino e mande as meninas percorrerem uma China fantasiosa resolvendo problemas.

O resultado deveria produzir um S0C7 cultural.

Curiosamente, funciona.

E funciona justamente porque Koihime†Musou é muito mais inteligente em sua construção do que a embalagem sugere.

A franquia nasceu do jogo Koihime†Musō: Doki Otome Darake no Sangokushi Engi — 恋姫†無双 ~ドキッ☆乙女だらけの三国志演義~, desenvolvido pela BaseSon e lançado originalmente para Windows em 26 de janeiro de 2007. Era uma visual novel adulta com elementos de estratégia, livremente inspirada em Romance dos Três Reinos, de Luo Guanzhong. 

O anime chegaria no ano seguinte.

E alguém tomou uma decisão que mudou completamente o sistema.



🗂️ O SYSOUT básico

Título: Koihime†Musou
Título original: 恋姫†無双
Romanização: Koihime Musō
Origem: visual novel/game da BaseSon
Obra inspiradora: Romance dos Três Reinos (Sānguó Yǎnyì), tradicionalmente atribuído a Luo Guanzhong
Estúdio: Doga Kobo
Direção: Nobuaki Nakanishi
Roteiro/composição da série: Gō Zappa
Estreia japonesa: 8 de julho de 2008
Fim da primeira temporada: 23 de setembro de 2008
Episódios: 12, mais OVA posterior
OVA da primeira série: 1º de abril de 2009.  

Depois vieram:

Shin Koihime†Musou — 2009 — 12 episódios;
Shin Koihime†Musou: Otome Tairan — 2010 — 12 episódios.  

Portanto, considerando as três séries regulares de TV:

36 episódios principais, além de OVAs e especiais.


🌸 O gênero

Classificar Koihime†Musou é uma aventura por si só.

Ele mistura:

fantasia histórica, ação, aventura, comédia, ecchi, bishōjo, moe, gender swap e elementos derivados de visual novel/harem.

Mas chamar simplesmente de “anime ecchi” é cometer contra ele o mesmo erro de olhar para um mainframe e dizer:

“É aquele computador preto grande.”

Tecnicamente não está totalmente errado.

Mas você perdeu praticamente tudo.

O anime é principalmente uma aventura episódica de estrada, estruturada em torno de encontros sucessivos.

Há batalhas.

Há fanservice.

Há humor sexual.

Há garotas fazendo coisas absurdas.

Mas também existe amizade, responsabilidade, liderança, amadurecimento e uma brincadeira contínua com uma das maiores narrativas históricas da Ásia.


🐉 O ancestral: Romance dos Três Reinos

Aqui mora a primeira grande sacada.

O material não surgiu do nada.

Romance dos Três Reinos dramatiza o colapso da dinastia Han e as guerras que eventualmente produziram os reinos de Wei, Shu e Wu.

Nesse universo encontramos nomes gigantescos da tradição chinesa:

Liu Bei.
Guan Yu.
Zhang Fei.
Cao Cao.
Sun Quan.
Zhuge Liang.
Zhao Yun.

Personagens que atravessaram literatura, teatro, ópera, televisão, cinema e videogames.

O Japão conhece muito bem esse imaginário.

Quem jogou Dynasty Warriors já esteve nesse CPD sem perceber.

A BaseSon simplesmente decidiu executar:

//SANGOKU EXEC PGM=RECOMPILE
//PARM DD *
 GENDER-SWAP
 MOE
 BISHOUJO
 ECCHI
 ROMANCE
/*

E nasceu Koihime†Musou.


⚔️ A história do anime

A protagonista central da primeira série é Kan'u, conhecida pelo nome verdadeiro Aisha.

Ela é a versão feminina de Guan Yu.

Aisha percorre o país combatendo bandidos e tentando impedir que outras pessoas sofram as consequências da violência que marcou sua própria vida.

Logo encontra Chōhi, ou Rinrin, correspondente a Zhang Fei.

Rinrin é praticamente a versão humana de um job submetido sem TYPRUN=SCAN.

Primeiro executa.

Depois pergunta.

As duas criam um vínculo de irmandade e começam uma jornada juntas.

A estrutura inicial parece simples:

CHEGA NUMA VILA
      ↓
EXISTE UM PROBLEMA
      ↓
ENCONTRAM UMA PERSONAGEM
      ↓
CONFUSÃO
      ↓
BATALHA
      ↓
COMIDA
      ↓
FAN SERVICE
      ↓
PRÓXIMA VILA

Só que cada encontro vai introduzindo personagens que representam figuras conhecidas da tradição dos Três Reinos.

Aos poucos, o espectador percebe que está vendo uma reconstrução extremamente livre do universo de Sangokushi.


👩🏻‍🦱 Kan'u / Aisha — Guan Yu recompilado

Aisha é provavelmente a personagem mais importante para compreender por que o anime funciona.

Ela é forte, disciplinada, séria e profundamente orientada por um senso de justiça.

Em uma obra onde quase tudo poderia virar apenas paródia sexual, Aisha funciona como o ponto de estabilidade do sistema.

Quando todos os demais processos começam a consumir CPU em maluquice, ela é o WLM tentando manter a prioridade da workload.

Sua arma e postura remetem diretamente ao imaginário tradicional de Guan Yu.

O gender swap mudou o corpo.

Não apagou completamente o arquétipo.

E esse é um padrão recorrente em Koihime†Musou.


🐯 Chōhi / Rinrin — Zhang Fei sem controle de mudanças

Rinrin é pequena, barulhenta, impulsiva, extremamente forte e adorável.

Em outras palavras:

IF IDEIA = "BOA"
    EXECUTAR
ELSE
    EXECUTAR-TAMBEM
END-IF

Ela representa Zhang Fei.

A personalidade explosiva e a força extraordinária sobreviveram à transformação.

Rinrin também cria grande parte da química cômica da dupla.

Aisha tenta ser adulta.

Rinrin existe para demonstrar que planos são apenas hipóteses esperando contato com produção.


🧠 Shokatsuryō / Shuri — Zhuge Liang

E então surge uma das transformações mais deliciosamente japonesas.

O lendário estrategista Zhuge Liang, paradigma de inteligência estratégica na cultura chinesa, vira Shuri, uma garota pequena, tímida e extremamente inteligente.

O contraste é proposital.

Fisicamente parece incapaz de organizar uma excursão escolar.

Mentalmente poderia reorganizar todo o datacenter.

É a tradição do personagem loli-genius, mas sustentada por uma referência histórica enorme.


👑 Sōsō / Karin — Cao Cao

Aqui a brincadeira fica ainda melhor.

Cao Cao, uma das figuras mais fascinantes e controversas dos Três Reinos, torna-se Karin.

Ambiciosa.

Dominante.

Brilhante.

Orgulhosa.

Carismática.

Perigosamente segura de si.

A aparência mudou radicalmente.

O espírito do arquétipo, nem tanto.

Karin conserva aquilo que faz Cao Cao funcionar narrativamente:

autoridade + inteligência + ambição + magnetismo.

E recebe ainda uma forte camada de erotismo e interesse por mulheres, que alimenta várias piadas e situações ecchi.


🍑 Ryūbi / Tōka — Liu Bei

Nas continuações, Ryūbi, ou Tōka, assume importância crescente.

Ela representa Liu Bei.

É idealista, bondosa e carismática.

O interessante é observar que Koihime não converte simplesmente personagens masculinos em mulheres aleatoriamente.

Ele tenta manter algum elemento reconhecível de suas funções narrativas.

É quase uma operação de modernização de legado:

INTERFACE = NOVA
CORE BUSINESS LOGIC = PRESERVADA

E qualquer cobolzeiro sabe que isso é mais difícil do que parece.


🤔 Cadê o protagonista masculino?

Aqui está uma das partes mais interessantes da adaptação.

Na visual novel original existe Kazuto Hongō.

Ele é transportado para esse mundo inspirado nos Três Reinos e funciona como protagonista masculino de uma estrutura de romance/harem.

No anime?

DELETE.

Kazuto simplesmente não participa da narrativa principal.

A própria adaptação televisiva segue uma história consideravelmente diferente do jogo: em vez de reproduzir a grande guerra entre os três reinos e a posição de Kazuto no centro das heroínas, acompanha principalmente as viagens de Kan'u e seus encontros. 

Essa mudança é gigantesca.

Porque remove o elemento tradicional:

“Garoto comum cercado por muitas garotas apaixonadas.”

E produz algo quase acidentalmente interessante:

mulheres vivendo aventuras onde suas relações umas com as outras são o centro da narrativa.


🚶‍♀️ Koihime como road movie

A primeira temporada funciona muito mais como uma road movie medieval do que como adaptação tradicional de videogame.

Aisha e Rinrin viajam.

Conhecem pessoas.

Entram em confusões.

Resolvem problemas.

Encontram futuros aliados e adversários.

Partem novamente.

Isso permite que o enorme elenco seja apresentado progressivamente.

E também cria uma sensação curiosa:

o objetivo não é necessariamente chegar a algum lugar.

A própria viagem é o programa.


🌸 A mensagem escondida mais interessante: identidade

O gender swap poderia ser apenas gimmick.

Mas produz uma pergunta involuntariamente interessante:

quanto de um personagem precisa permanecer para ainda reconhecermos aquele personagem?

Retire o sexo.

Mude a aparência.

Mude parte da história.

Mude algumas relações.

E ainda assim dizemos:

“Isso é Cao Cao.”

Por quê?

Porque identidade narrativa não reside apenas em dados superficiais.

Cao Cao continua sendo identificado por determinados padrões:

ambição, liderança, inteligência, pragmatismo.

Guan Yu:

honra, força, lealdade.

Zhuge Liang:

estratégia, conhecimento.

É quase uma discussão de programação orientada a objetos:

CLASS GUAN-YU
   ATTRIBUTES:
      SEX = ALTERADO
      APPEARANCE = ALTERADO
   METHODS:
      LOYALTY()
      STRENGTH()
      JUSTICE()

A implementação mudou.

A interface conceitual sobreviveu.


🤝 Outra mensagem: família escolhida

A relação entre Aisha e Rinrin começa fora de estruturas tradicionais.

Elas escolhem tornar-se próximas.

Outros personagens vão sendo incorporados ao círculo por amizade, respeito, rivalidade ou circunstância.

Isso cria um tema recorrente:

laços não dependem exclusivamente de sangue ou origem.

São construídos por experiências compartilhadas.

Sob toneladas de moe, há uma narrativa bastante simpática sobre pertencimento.


👩 O mundo onde quase todos os heróis são mulheres

Há outra inversão interessante.

Nas histórias tradicionais dos Três Reinos, mulheres existem, mas o palco militar e político é esmagadoramente masculino.

Em Koihime:

as mulheres comandam exércitos.

Planejam estratégias.

Governam territórios.

Combatem.

Negociam.

Erram.

Vencem.

Desejam.

Fazem piadas obscenas.

O anime não tenta realizar um manifesto feminista — seria exagero impor essa leitura.

Mas o gender swap produz, por consequência, um universo onde agência política e militar feminina é absolutamente normal.

Ninguém precisa parar a história para perguntar:

“Mas uma mulher pode comandar esse exército?”

Ela simplesmente comanda.


🍑 E sim, existe muito ecchi

Não podemos cometer fraude na documentação técnica.

Koihime†Musou tem fanservice.

Bastante.

Banhos.

Enquadramentos sugestivos.

Insinuações.

Piadas com seios.

Situações sexualizadas.

Yuri implícito ou explícito no humor.

Roupas desenhadas segundo a rigorosíssima escola militar conhecida como:

“Armadura que protege tudo exceto aquilo que o diretor quer mostrar.”

😂

Mas o anime televisivo é consideravelmente mais moderado que a origem da franquia.

E isso nos leva ao assunto mais curioso.


🔞 O jogo original era eroge

Sim.

O ancestral é um adult visual novel.

A versão original para Windows, lançada em 2007, continha conteúdo sexual explícito e foi comercializada como jogo adulto.

Isso coloca Koihime†Musou em uma linhagem importante da indústria japonesa:

EROGE
  ↓
POPULARIDADE
  ↓
MANGA
  ↓
ANIME
  ↓
CONTEÚDO SEXUAL REDUZIDO
  ↓
PÚBLICO MUITO MAIOR

Não é exclusividade de Koihime.

Diversas franquias japonesas realizaram trajetórias semelhantes.


✂️ Censura ou adaptação?

Aqui vale uma distinção.

Dizer apenas que o anime foi “censurado” simplifica demais.

O que aconteceu foi sobretudo uma mudança de produto e mídia.

O game original tinha conteúdo adulto explícito.

Uma série de televisão precisava funcionar sob outra classificação, outro mercado e outras regras de transmissão.

Consequentemente:

sexo explícito desaparece;

fanservice permanece;

insinuações sobrevivem;

a estrutura harem é radicalmente enfraquecida;

Kazuto desaparece;

aventura e comédia tornam-se muito mais importantes.

Portanto, não foi apenas:

GAME - SEX = ANIME

Foi uma recompilação.


🎮 Os games

A franquia começou justamente ali.

O primeiro jogo foi:

Koihime†Musō: Doki Otome Darake no Sangokushi Engi

Windows, 2007.

Depois ganhou outras versões e sequências.

Uma versão para PlayStation 2 chegou em 2008. (LaunchBox Games Database)

A série cresceu particularmente com Shin Koihime†Musou, expandindo personagens, facções e rotas.

Posteriormente surgiram títulos adicionais e fan discs, entre eles Shin Koihime†Musou ~Moeshouden~, lançado em julho de 2010, concebido como complemento com muitas cenas adicionais. (Koihime)

A genealogia dos games ficou consideravelmente maior do que as três temporadas de anime fazem imaginar.


📚 Manga

Também houve adaptações em mangá.

Uma das primeiras começou a serialização em Dengeki G's Festival! Comic, da ASCII Media Works, em 26 de abril de 2008, com arte de Yayoi Hizuki.

Depois a expansão de Shin Koihime†Musou gerou outros mangás, antologias e material derivado.

Isso é importante porque Koihime não deve ser compreendido como:

“um anime que ganhou game”.

É exatamente o contrário.

O anime é apenas um frontend de um ecossistema multimídia muito maior.


📖 Light novel?

Há material escrito e derivados editoriais ligados à franquia, mas Koihime†Musou não nasceu como light novel.

Sua árvore principal é:

ROMANCE DOS TRÊS REINOS
        ↓
     BASESON
        ↓
VISUAL NOVEL / GAME
        ↓
 ┌──────┼───────┐
MANGA  ANIME   OUTROS GAMES

Isso é importante para não classificarmos qualquer franquia japonesa multimídia como “baseada numa light novel”.

Aqui o executável original é visual novel.


📺 As três temporadas

1. Koihime†Musou — 2008

Aisha e Rinrin estão no centro.

É a temporada que estabelece o universo.

Mais episódica.

Mais “viagem”.

2. Shin Koihime†Musou — 2009

Amplia consideravelmente elenco e relações.

Ryūbi ganha grande importância.

Começa a parecer mais claramente uma enorme releitura do universo dos Três Reinos.

3. Shin Koihime†Musou: Otome Tairan — 2010

Expande novamente os conflitos e reúne personagens/facções.

As temporadas 2 e 3 também foram produzidas pela Doga Kobo e dirigidas por Nobuaki Nakanishi. 


🎬 Doga Kobo antes da fama moderna

Esse detalhe hoje é divertido.

O estúdio é Doga Kobo.

Décadas depois, o nome ficaria associado a produções muito conhecidas do público moderno.

Mas Koihime†Musou pertence a uma fase anterior do estúdio.

O visual denuncia imediatamente o período.

É anime de 2008 sem vergonha de ser anime de 2008.

Olhos grandes.

Design extremamente colorido.

Cabelos que desafiam genética, gravidade e provavelmente algumas convenções internacionais.

Moe.

Super-deformed ocasional.

Fanservice.

CG e composição relativamente modestos em comparação com produções modernas.

Há registros inclusive de que a edição televisiva e os posteriores masters japoneses em DVD tiveram diferenças e melhorias de animação.


🧭 A aventura é mais importante que a guerra

Curiosamente, aquilo que define Romance dos Três Reinos — a gigantesca luta político-militar — não domina a primeira temporada.

Ela funciona quase como introdução ao mundo.

Essa foi uma escolha inteligente.

Tentar apresentar imediatamente dezenas de generais, facções, alianças e traições seria como ensinar z/OS dizendo:

“Hoje começaremos por explicar JES2, RACF, WLM, Db2, CICS, VTAM, SMS, Sysplex e SMP/E.”

Aluno:

“Professor, onde liga?”

Koihime começa pequeno.

Uma guerreira.

Uma garota.

Uma estrada.

Um problema.

Depois amplia o mapa.


🧩 A linguagem dos dois nomes

Outro detalhe divertido para quem entra na franquia:

muitas personagens possuem mais de um nome pelo qual são chamadas.

Por exemplo:

Kan'u → Aisha
Chōhi → Rinrin
Sōsō → Karin
Ryūbi → Tōka
Shokatsuryō → Shuri

Isso deriva da maneira pela qual a franquia brinca com nomes, nomes de cortesia e equivalentes dos personagens históricos.

No começo parece documentação escrita por cinco fornecedores.

Depois você acostuma.


🏯 Japão reinterpretando China

Aqui existe uma camada cultural bem mais rica.

Koihime†Musou não é apenas uma transformação sexualizada de personagens históricos.

Ele participa de uma longa história japonesa de apropriação, tradução e reinterpretação de narrativas chinesas.

Romance dos Três Reinos possui enorme influência no Japão.

Mangás.

Animes.

Games.

Romances.

Estratégia.

Produtos históricos.

A Koei praticamente construiu uma indústria inteira em torno de Sangokushi.

Koihime representa uma manifestação particularmente japonesa desse fenômeno:

“Nós conhecemos tão bem esses personagens que podemos desconstruí-los e ainda esperar que vocês reconheçam quem são.”

A piada funciona justamente porque o original já é culturalmente conhecido.


🧠 A mensagem secreta: história é código-fonte

Talvez esta seja a leitura Bellacosa perfeita.

Nós costumamos imaginar clássicos como objetos imóveis.

Um livro existe.

Sua história está terminada.

Não toque.

Mas cultura nunca funcionou assim.

As histórias são continuamente recompiladas.

Roma recompilou Grécia.

Europa recompilou Roma.

Hollywood recompila mitologia.

Anime recompila literatura europeia.

E Koihime†Musou recompila Romance dos Três Reinos.

SOURCE:
  SANGUO-YANYI.CBL

VERSION 1:
  CHINA

VERSION 2007:
  BASESON

VERSION 2008:
  DOGA-KOBO

O source ancestral continua reconhecível.

O executável mudou completamente.


🌍 Impacto cultural

Seria exagerado colocar Koihime†Musou ao lado de fenômenos globais como Dragon Ball, Evangelion ou Pokémon.

Seu impacto é mais específico.

Mas dentro do universo de visual novels, eroge, bishōjo games e franquias gender-swap de figuras históricas, Koihime tornou-se uma franquia duradoura.

A prova está justamente na quantidade de continuações, games, mangás, fan discs e adaptações produzidas desde o lançamento original.

O conceito revelou-se extraordinariamente reutilizável.

A cada novo personagem histórico havia praticamente:

INPUT:
FIGURA DOS TRÊS REINOS

OUTPUT:
NOVA GAROTA
NOVA PERSONALIDADE
NOVA ROTA
NOVA MERCADORIA

É um modelo industrial brilhantemente japonês.


🧐 O que Koihime†Musou tem de diferente?

No papel, vários elementos parecem comuns:

ecchi;

moe;

garotas guerreiras;

elenco gigantesco;

visual novel;

fanservice.

O diferencial está na combinação.

Poucos animes podem dizer:

“Minha genealogia intelectual começa numa obra chinesa do século XIV, passa por guerras do século III, entra num eroge japonês de 2007 e termina numa menina pequena representando Zhang Fei discutindo comida.”

Isso é patrimônio cultural ou bug.

Provavelmente os dois.


🔞 Classificação

A classificação precisa distinguir as mídias.

O jogo original para PC é uma obra adulta/eroge, com conteúdo sexual explícito.

O anime de televisão não é hentai.

Ele contém ecchi, nudez/fanservice parcial, piadas sexuais, sugestão de relações entre personagens e violência fantasiosa, mas foi concebido como produto televisivo muito mais moderado.

Portanto:

Koihime†Musou anime ≠ hentai.

Koihime†Musou visual novel original = eroge/adult game.

Confundir os dois é como confundir CICS Transaction Server com um programa COBOL que roda nele.

Relacionados?

Sim.

A mesma coisa?

Nem de longe.


❤️ E talvez aqui esteja o charme

Se você entrar esperando uma adaptação historicamente rigorosa dos Três Reinos, Koihime†Musou provavelmente causará um pequeno aneurisma acadêmico.

Se entrar esperando pornografia porque descobriu que veio de um eroge, provavelmente também ficará surpreso.

Se entrar esperando apenas batalha, idem.

O anime funciona melhor quando você aceita sua verdadeira natureza:

uma viagem cômica por uma China imaginária, povoada por versões femininas de personagens lendários, onde amizade e aventura importam mais que fidelidade histórica.

E existe algo estranhamente encantador nisso.

Aisha continua andando.

Rinrin continua se metendo em problemas.

Shuri continua pensando dez passos à frente.

Karin continua convencida de que deveria administrar tudo.

E dois mil anos de história chinesa observam silenciosamente enquanto o Japão transforma seus generais em garotas moe.


🖥️ O diagnóstico Bellacosa

Se Romance dos Três Reinos fosse um sistema legado, Koihime†Musou seria aquele projeto de modernização que chegasse dizendo:

“Não alteraremos a lógica fundamental.”

Então você abriria o pacote de implantação.

CHANGE REQUEST #2007

Alterações:

[x] Frontend substituído
[x] Sexo dos usuários alterado
[x] Arquitetura política simplificada
[x] Protagonista removido
[x] Fanservice instalado
[x] Moe habilitado
[x] Yuri opcional
[x] Comédia ativada
[x] Guan Yu recompilado
[x] Cao Cao recompilado
[x] Zhuge Liang recompilado

CAB:

“E a compatibilidade?”

BaseSon:

“Mais ou menos.”

Doga Kobo:

“Rodou em homologação.”

Historiador:

“EU NÃO APROVEI ISSO!”

Operações:

IEF142I KOIHIME STEP01 - STEP WAS EXECUTED
IEF285I MAXCC=0000

E é justamente aí que mora a graça.

Koihime†Musou pega algo antiquíssimo, respeitado e monumental e prova que um clássico permanece vivo justamente porque alguém ainda tem coragem de fazer coisas absurdas com ele.

Não substitui Romance dos Três Reinos.

Não pretende fazê-lo.

É outra coisa.

É um fork.

Um fork japonês, ecchi, colorido, absolutamente improvável...

...e que, contra todas as boas práticas de Change Management, funciona. ⚔️🌸 

# Bloco HTML/CSS/JS para Blogspot — Koihime†Musou Trilogy
☕ Bellacosa Mainframe Anime Archive

Koihime†Musou — Os Três Reinos Recompilados em Modo Moe

Três artigos conectados sobre Koihime†Musou, Shin Koihime†Musou e Otome Tairan: história chinesa, anime, ecchi, gender swap, BaseSon, Doga Kobo, games, mangás, personagens e o estranho momento em que Shu, Wei e Wu viraram praticamente LPARs.

//KOIHIME JOB CLASS=A,MSGCLASS=X
//SANGOKU EXEC PGM=RECOMPILE
//PARM DD *
GENDER-SWAP, MOE, ECCHI, HISTORY, COMEDY
/*
IEF285I SHU ONLINE
IEF285I WEI ONLINE
IEF285I WU ONLINE
IEF142I MAXCC=0000
2008 · RELEASE 1

Koihime†Musou

O ponto de partida: Guan Yu, Zhang Fei, Cao Cao e os Três Reinos passam pelo compilador moe e viram uma road movie histórica, cômica e ecchi.

2009 · RELEASE 2

Shin Koihime†Musou

A chegada de Ryūbi/Tōka expande o mapa: mais facções, mais estratégia, mais personagens e o nascimento do verdadeiro Sysplex dos Três Reinos.

2010 · RELEASE 3

Shin Koihime†Musou: Otome Tairan

Shu, Wei e Wu convergem: amizade, rivalidade, estratégia, guerras, fanservice e um enorme elenco entram simultaneamente em produção.

sexta-feira, 1 de agosto de 2008

24 Horas em 2007: Jack Bauer, COBOL e o Dia em que a IBM Descobriu que o Próximo Terrorista do Data Center Era a Conta de Luz

 

Bellacosa Mainframe e a ibm 2007 apresenta o big green

☕ Um Café no Bellacosa Mainframe

24 Horas em 2007: Jack Bauer, COBOL e o Dia em que a IBM Descobriu que o Próximo Terrorista do Data Center Era a Conta de Luz

🌱 Project Big Green, System z, z/VM, Linux, Java, SOA, VMware, Windows Vista, Oracle, software corporativo, o fantasma do Y2K e uma viagem ao ano em que todo mundo dizia que COBOL estava morrendo — enquanto a IBM preparava 3.900 servidores para entrar em aproximadamente 30 mainframes


THE FOLLOWING TAKES PLACE
BETWEEN 00:00 AND 24:00

ON MAY 10, 2007.

EVENTS OCCUR IN REAL TIME.

00:00:01

TIC.

00:00:02

TIC.

00:00:03

TIC.

Jack Bauer entra correndo no data center.

— Onde está a bomba?

O operador aponta para uma fileira interminável de racks.

— Não temos bomba, senhor Bauer.

— Então por que me chamaram?

— Temos 4.000 servidores.

Jack observa as máquinas.

— E?

— A maioria passa boa parte do tempo subutilizada.

— Continue.

— Todos consomem eletricidade.

— Continue.

— Produzem calor.

— Continue.

— Então usamos mais eletricidade para retirar o calor produzido pela eletricidade que usamos para alimentar os computadores.

Jack permanece imóvel durante cinco segundos.

Isso, em 24 Horas, equivale a uma tese de doutorado.

— Meu Deus.

Do fundo da sala surge um senhor usando crachá da IBM.

— Exatamente.

E naquele 10 de maio de 2007, a IBM anunciou oficialmente o Project Big Green: uma iniciativa de cerca de US$ 1 bilhão por ano em tecnologias e serviços voltados à eficiência energética dos data centers.

O que parecia uma campanha ecológica era, na realidade, resposta a um problema econômico e físico que começava a aterrorizar CIOs:

os data centers estavam ficando sem energia, refrigeração e espaço para continuar colocando servidores.

E o mais extraordinário é perceber que a história aconteceu 19 anos antes de começarmos a discutir clusters de IA em megawatts.

Mas, para entender por que Big Green causou tanto barulho, precisamos voltar ao mundo tecnológico de 2007.

E ele era muito diferente do nosso.


01:00 — IBM não estava morrendo. Muito pelo contrário.

Existe uma tentação histórica de imaginar a IBM dos anos 2000 como uma companhia envelhecida tentando desesperadamente salvar o mainframe.

Os números contam outra história.

A IBM havia acabado de executar uma transformação empresarial gigantesca. Em 2005 concluíra a venda de seu negócio de PCs para a Lenovo e estava concentrando capital em negócios considerados de maior valor: software, serviços, middleware, consultoria e infraestrutura empresarial. Essa mudança continuaria sendo destacada pela própria IBM nos relatórios seguintes. (IBM)

A evolução financeira é reveladora:

AnoReceita IBMLucro líquido
2005~US$ 91,1 bilhões~US$ 7,9 bilhões
2006~US$ 91,4 bilhões~US$ 9,5 bilhões
2007~US$ 98,8 bilhões~US$ 10,4 bilhões

Ou seja:

2005 → 2007

RECEITA
US$ 91,1 bi ───────────► US$ 98,8 bi

LUCRO
US$ 7,9 bi ────────────► US$ 10,4 bi

Isso é importante para interpretar Big Green.

Não era:

IBM EM PÂNICO
       ↓
PRECISAMOS INVENTAR
ALGUMA COISA VERDE
PARA SALVAR A EMPRESA

Era muito mais:

IBM LUCRATIVA
       ↓
SERVIÇOS + SOFTWARE
       ↓
VIRTUALIZAÇÃO
       ↓
DATA CENTERS CRESCENDO
       ↓
CLIENTES COM PROBLEMAS DE ENERGIA
       ↓
HUM...
       ↓
ISSO PODE VIRAR NEGÓCIO.

Jack Bauer aprovaria.


02:00 — A IBM de 2007 já não era primordialmente “uma fabricante de computadores”

Isso também é fundamental.

A IBM possuía System z, System p, System i, System x, storage e chips.

Mas o coração econômico da companhia estava se deslocando fortemente para serviços e software.

Naquela IBM encontrávamos marcas como:

WebSphere
Tivoli
Lotus
Rational
DB2 / Information Management

Mais Global Technology Services.

Mais Global Business Services.

Mais outsourcing.

Mais consultoria.

Mais financiamento.

Hardware continuava estratégico, especialmente porque funcionava como âncora de ecossistemas inteiros.

O mainframe talvez fosse o melhor exemplo:

SYSTEM z
   │
   ├── z/OS
   ├── COBOL
   ├── CICS
   ├── IMS
   ├── DB2
   ├── MQ
   ├── RACF
   ├── Tivoli
   ├── serviços
   └── contratos

O valor econômico não estava simplesmente na caixa preta.

Estava no ecossistema ao redor dela.


03:00 — Enquanto isso, o mercado mundial de software parecia um clube muito exclusivo

O software mundial de 2007 já era gigantesco, mas possuía uma concentração impressionante.

Dependendo da metodologia e da definição de “software” usada pelos institutos de pesquisa, os números absolutos variam. Portanto, é perigoso misturar Gartner, IDC e receitas contábeis das empresas como se medissem exatamente o mesmo universo.

Mas a hierarquia geral era bastante clara:

              SOFTWARE 2007

                MICROSOFT
                    │
                   IBM
                    │
                 ORACLE
                    │
                   SAP
                    │
               outros

A Microsoft era uma potência extraordinária. Seu próprio ano fiscal de 2007 terminou com US$ 51,1 bilhões de receita e US$ 14,1 bilhões de lucro líquido. (Microsoft)

Mas “mercado de software” escondia vários mundos.

Desktop

WINDOWS
OFFICE

Microsoft era gigantesca.

Banco de dados

Oracle
IBM DB2
Microsoft SQL Server

ERP

SAP
Oracle

Middleware

IBM WebSphere
BEA WebLogic
Oracle
Microsoft

Gerenciamento

IBM Tivoli
CA
BMC
HP

Desenvolvimento

Java
.NET
C/C++
COBOL
PHP
Perl
Python
Ruby

E aqui aparece uma diferença fundamental em relação a 2026:

SaaS ainda não havia virado o modelo mental dominante do software empresarial.

A licença perpétua + manutenção ainda reinava em enorme parte do mercado.


04:00 — O mundo estava apaixonado por três letras: SOA

Se você entrasse numa conferência corporativa em 2007 e dissesse:

“SOA”

provavelmente alguém lhe ofereceria um emprego.

Service-Oriented Architecture era uma das grandes obsessões da época.

O diagrama típico parecia:

               PORTAL
                  │
              WEB SERVICE
                  │
                  ↓
                 ESB
          ┌───────┼───────┐
          │       │       │
        JAVA    CICS    SAP
          │       │       │
          └───────┼───────┘
                  │
                DATA

REST existia.

Mas no grande enterprise o vocabulário estava repleto de:

SOAP
WSDL
XML
ESB
SOA
Web Services

Para um COBOLzeiro isso significava algo importantíssimo.

A estratégia frequentemente não era:

DELETE COBOL

mas:

        COBOL/CICS
            │
            ↓
       WEB SERVICE
            │
            ↓
            SOA

A modernização começava a significar expor o legado, e não necessariamente eliminá-lo.


05:00 — E Java era o garoto bonito do CPD

Se COBOL era o senhor de terno cinza sentado no fundo da sala, Java era o jovem arquiteto chegando com mochila e UML.

No enterprise:

Java
Java EE
WebSphere
WebLogic
J2EE/Java EE
Spring

estavam por toda parte.

Microsoft respondia com:

.NET
C#
Visual Studio
Windows Server
SQL Server

Linux crescia fortemente no servidor.

Unix ainda tinha enorme relevância:

AIX
Solaris
HP-UX

E x86 multiplicava-se dentro dos data centers.

É justamente aí que nasce nosso problema.


06:00 — SERVER SPRAWL

O administrador instala:

APP A → SERVER A

Depois:

APP B → SERVER B

Depois:

DATABASE → SERVER C

Depois:

WEB → SERVER D

Depois:

TEST → SERVER E

Cinco anos depois:

SERVER001
SERVER002
SERVER003
...
SERVER1847
SERVER1848
SERVER1849

Alguém pergunta:

— Quem usa SERVER0932?

Silêncio.

— Podemos desligá-lo?

Silêncio ainda maior.

Jack Bauer coloca a arma sobre a mesa.

— Vou perguntar novamente.

O problema do server sprawl era extremamente real.

E então VMware apareceu no centro da história.


07:00 — VMware faz o mundo x86 descobrir virtualização

2007 foi um ano espetacular para virtualização.

A VMware já tinha tecnologia madura de virtualização de servidores e tornou-se símbolo de uma transformação gigantesca:

ANTES

APP A → SERVER
APP B → SERVER
APP C → SERVER


DEPOIS

       SERVER
         │
    HYPERVISOR
    ┌────┼────┐
    VM   VM   VM
    │    │    │
   APP  APP  APP

Em 14 de agosto de 2007, a VMware fez seu IPO.

O entusiasmo do mercado foi enorme.

E havia veteranos de mainframe assistindo aquilo com uma expressão curiosa.

— Virtualização?

— Sim!

— Várias máquinas virtuais compartilhando hardware?

— Exatamente!

— Fascinante.

— Isso vai revolucionar a informática!

— Meu caro... sente-se. Precisamos conversar sobre CP/CMS, VM/370 e z/VM.

😄


08:00 — O mainframe tinha uma arma secreta chamada z/VM

Em junho de 2007, z/VM 5.3 tornou-se disponível, trazendo melhorias de escalabilidade em processadores, memória, rede e I/O justamente porque os workloads Linux virtualizados estavam crescendo. (IBM)

O conceito:

             SYSTEM z
                 │
               z/VM
                 │
      ┌──────────┼──────────┐
      │          │          │
    Linux      Linux      Linux
      │          │          │
    APP A      APP B      APP C

IBM olhava para milhares de servidores distribuídos e dizia:

Por que não consolidá-los?

E então o relógio começou a correr.


09:00 — 10 de maio de 2007: PROJECT BIG GREEN

09:00:00

TIC

09:00:01

TIC

IBM anuncia:

PROJECT BIG GREEN.

A proposta envolvia aproximadamente US$ 1 bilhão por ano de recursos dedicados a produtos e serviços de eficiência energética.

Havia centenas de especialistas.

A metodologia envolvia essencialmente:

DIAGNOSE
    ↓
BUILD
    ↓
VIRTUALIZE
    ↓
MANAGE
    ↓
COOL

Não era simplesmente:

“Compre um mainframe porque ele é verde.”

Era uma estratégia de data center.

E isso importa muito.


10:00 — Por que energia virou assunto em 2007?

Porque os números começavam a assustar.

O relatório entregue ao Congresso dos Estados Unidos pela EPA naquele ano estimou que servidores e data centers americanos haviam consumido aproximadamente 61 bilhões de kWh em 2006, cerca de 1,5% do consumo total de eletricidade dos EUA, a um custo aproximado de US$ 4,5 bilhões. O consumo havia aproximadamente dobrado desde 2000. (IBM)

A indústria percebeu:

COMPUTAÇÃO ↑

SERVIDORES ↑

ELETRICIDADE ↑

CALOR ↑

REFRIGERAÇÃO ↑

ELETRICIDADE ↑

E surgiu uma palavra que hoje parece óbvia:

eficiência.


11:00 — O mercado inicialmente enxergou muito marketing

Naturalmente.

Quando IBM disse:

Big Green

a imprensa imediatamente descobriu o irresistível:

Big Blue goes Green.

E houve ironia.

The Register publicou uma manchete maravilhosa:

“IBM: Dinosaurs were green.”

O dinossauro era, naturalmente, o mainframe.

A piada escondia uma mudança narrativa muito inteligente.

Durante anos o ataque ao mainframe era:

GRANDE
CARO
CENTRALIZADO
ANTIGO

IBM começou a responder:

E seus 4.000 servidores são exatamente o quê?

😂

A campanha tentava transformar uma fraqueza de imagem — “uma máquina enorme” — em vantagem:

consolidação.


12:00 — 3.900 servidores entram no CTU

Em 1º de agosto de 2007, IBM fez algo fundamental.

Não ficou apenas no PowerPoint.

Anunciou que consolidaria aproximadamente:

3.900 servidores

em cerca de:

30 System z

rodando Linux. O objetivo declarado era reduzir o consumo energético daquele ambiente em aproximadamente 80% ao longo de cinco anos. (IBM)

A imprensa percebeu imediatamente o tamanho da história.

O desenho era quase absurdo:

██████████████████████████████████████
          3.900 SERVIDORES
██████████████████████████████████████

                   │
                   │
                   ▼

       ███████████████████
       ~30 SYSTEM z
       ███████████████████

A cobertura contemporânea mencionava também economia prevista de centenas de milhões de dólares e redução enorme do espaço físico.

Aquilo transformou Big Green de slogan em case interno da própria IBM.


13:00 — Isso fez explodir as vendas de mainframe imediatamente?

Não.

E essa nuance é importantíssima.

2007 estava no final do ciclo tecnológico do System z9.

O z9 Enterprise Class havia aparecido em 2005.

O próximo grande salto — System z10 — chegaria em fevereiro de 2008.

Portanto, não devemos olhar Big Green e concluir:

BIG GREEN
    ↓
VENDAS SYSTEM z EXPLODEM

Hardware enterprise possui ciclos.

Clientes aguardam novas gerações.

Capacidade instalada cresce mesmo quando receita de hardware não acompanha linearmente.

E mainframe possui outra peculiaridade:

HARDWARE
    │
    ├── SOFTWARE
    ├── LICENCIAMENTO
    ├── MANUTENÇÃO
    ├── SERVIÇOS
    └── CAPACIDADE

O valor para IBM nunca esteve simplesmente na venda da caixa.


14:00 — E o COBOL? Ah, o pobre COBOL...

Agora chegamos à parte culturalmente deliciosa.

Era 2007.

Sete anos depois do Y2K.

Durante o período 1997–1999, COBOLzeiro tinha virado quase uma unidade monetária.

PRECISAMOS CORRIGIR DATAS.

CHAMEM COBOLZEIROS.

QUANTOS?

TODOS.

Então chegou:

01/01/2000

O mundo não explodiu.

Parabéns.

O prêmio recebido pelo COBOL foi aproximadamente:

“Obrigado. Agora você pode voltar para o porão.”

😂


15:00 — O paradoxo pós-Y2K

A percepção popular era:

COBOL
 =
LINGUAGEM VELHA
 =
LEGADO
 =
MANUTENÇÃO
 =
MORTE EVENTUAL

Nas universidades, Java, C++, .NET e linguagens Web eram muito mais atraentes.

O estudante perguntava:

— Qual linguagem devo aprender?

Resposta típica:

Java
C++
C#
PHP

Dificilmente:

COBOL + JCL + CICS + DB2 + VSAM

Mas havia um problema.

Os sistemas não receberam o memorando sobre a morte do COBOL.


16:00 — Enquanto todo mundo declarava COBOL morto...

Dentro dos bancos:

COBOL → PROCESSANDO

Seguradoras:

COBOL → PROCESSANDO

Governos:

COBOL → PROCESSANDO

Varejo:

COBOL → PROCESSANDO

Grandes empresas:

COBOL → PROCESSANDO

A diferença fundamental era:

COBOL tinha deixado de ser tecnologicamente “sexy”.

Isso não significava que tivesse deixado de ser economicamente relevante.

E essa distinção continua sendo crucial.


17:00 — A IBM também não estava abandonando COBOL

Esse detalhe destrói a narrativa de “linguagem congelada”.

Naquele período a IBM continuava evoluindo Enterprise COBOL e todo o ecossistema ao redor do mainframe.

O mundo mainframe de 2007 incluía tecnologias contemporâneas como:

Enterprise COBOL
CICS Transaction Server
DB2
IMS
MQ
WebSphere
XML
Web Services
Java
Linux
Rational

O objetivo era integrar.

Um programa COBOL poderia continuar fazendo:

       READ CONTA
       COMPUTE SALDO = SALDO - VALOR
       REWRITE CONTA.

enquanto externamente alguém enxergava:

SOAP
   │
WSDL
   │
XML
   │
SERVICE

O legado estava ganhando uma porta nova.


18:00 — O problema real não era COBOL. Era conhecimento

Começava a ficar evidente outro problema.

Quem conhecia:

COBOL
JCL
CICS
DB2
IMS
VSAM
RACF
TSO
ISPF

tinha frequentemente começado décadas antes.

E as universidades estavam formando principalmente:

Java
C++
.NET
Web

Nascia o problema que nos acompanharia por décadas:

mainframe skills gap.

O perigo não era simplesmente:

“Ninguém sabe escrever PERFORM.”

Era:

“Quem sabe por que aquele programa de 1987 faz exatamente aquilo às 02h13 do terceiro dia útil?”

Essa informação não está no manual de COBOL.

Está no conhecimento institucional.


19:00 — O COBOL estava morto e recebendo versão nova

Existe algo deliciosamente mainframe nisso.

A indústria:

COBOL está morto.

IBM:

ENTERPRISE COBOL
NEW VERSION

Indústria:

Mainframe está morto.

IBM:

SYSTEM z

Indústria:

Virtualização é o futuro.

IBM:

z/VM

Indústria:

Linux é o futuro.

IBM:

LINUX ON SYSTEM z

Indústria:

SOA é o futuro.

IBM:

CICS WEB SERVICES

O mainframe desenvolveu uma extraordinária habilidade histórica:

deixar os outros anunciarem sua morte enquanto instala a próxima release.


20:00 — Enquanto isso, fora do CPD, 2007 enlouquecia

Esse talvez seja o detalhe mais divertido.

Em janeiro, a Microsoft lançou Windows Vista e Office 2007 para consumidores mundialmente. (Source)

E também em janeiro, Steve Jobs apresentou algo chamado:

iPhone.

A Apple descreveu-o como combinação de telefone, iPod e dispositivo de Internet. (Apple)

Não existia App Store ainda.

Kubernetes?

Não.

Docker?

Não.

ChatGPT?

Não.

Instagram?

Não.

WhatsApp?

Não.

TikTok?

Nem pensar.

Windows Azure?

Ainda não.

Mas existiam:

BlackBerry
Nokia
Symbian
Windows Mobile

E o iPhone estava prestes a destruir boa parte desse universo.


21:00 — E a cloud era apenas uma criança

AWS já existia.

S3 havia aparecido em 2006.

EC2 também havia iniciado sua história.

Mas em 2007 ninguém em uma grande reunião bancária normal dizia:

“Vamos desligar o mainframe e colocar o core inteiro na AWS.”

Seria provavelmente acompanhado educadamente até a porta.

😂

Cloud computing ainda estava emergindo.

O próprio IBM responderia naquele ano.

Em novembro de 2007 apareceu:

Blue Cloud.

Observe a sequência histórica:

MAIO 2007
BIG GREEN
     │
     ↓
ENERGY + CONSOLIDATION


NOVEMBRO 2007
BLUE CLOUD
     │
     ↓
VIRTUALIZATION + AUTOMATION
+ DISTRIBUTED COMPUTING

Em poucos meses IBM estava discutindo simultaneamente eficiência física do data center e o embrião daquilo que viraria cloud computing.

Isso é extraordinariamente importante em retrospecto.


22:00 — 2007 foi o ano em que várias placas tectônicas começaram a se mover

Olhe esta fotografia:

Área2007
DesktopWindows dominava
Enterprise developmentJava/.NET
IntegraçãoSOA, SOAP, XML, WSDL
MainframeIBM System z9
Virtualização x86VMware
Mainframe virtualizationz/VM
UnixAIX, Solaris, HP-UX
Linuxcrescimento empresarial
DatabaseOracle, DB2, SQL Server
ERPSAP/Oracle
Cloudembrionária
MobileBlackBerry/Nokia, iPhone chegando
Containersinexistentes no sentido atual
Kubernetesinexistente
DevOpstermo ainda não estabelecido
IA generativaficção científica para o mercado
COBOL“morto”, porém trabalhando normalmente

É isso que torna Big Green tão fascinante.

Ele não nasceu no nosso mundo.

Nasceu antes do nosso mundo.


23:00 — O verdadeiro significado de Big Green aparece

Imagine Jack Bauer olhando dois monitores.

No primeiro:

2007

SERVER SPRAWL
       ↓
POWER
       ↓
COOLING
       ↓
COST

No segundo:

2026

CLOUD
       ↓
GPU
       ↓
AI
       ↓
MEGAWATTS
       ↓
GRID CAPACITY

Jack pergunta:

— Qual é a diferença?

O sysprog responde:

— Escala.

— Só isso?

— Basicamente.

Big Green identificou corretamente uma verdade física:

a capacidade computacional pode crescer mais rapidamente do que a infraestrutura física capaz de alimentá-la e refrigerá-la.

O que IBM não poderia prever completamente era como o mercado resolveria o problema.

A IBM apostava fortemente em:

CONSOLIDAÇÃO
       ↓
VIRTUALIZAÇÃO
       ↓
SYSTEM z / Linux

O mercado também escolheu:

VMWARE
       ↓
x86 VIRTUALIZATION
       ↓
HYPERSCALE
       ↓
PUBLIC CLOUD

E posteriormente:

CONTAINERS
       ↓
KUBERNETES
       ↓
CLOUD-NATIVE

A tese física sobreviveu.

A implementação vencedora tornou-se plural.


23:30 — Então Big Green fracassou?

Não.

Mas também seria exagero dizer que Big Green fez o mercado inteiro correr para System z.

O impacto foi mais sofisticado.

Ele ajudou a legitimar energia como métrica de TI.

Antes:

CAPACITY PLANNING

CPU
MEMORY
DISK
I/O

Depois:

CAPACITY PLANNING

CPU
MEMORY
DISK
I/O

+ POWER
+ COOLING
+ SPACE

O setor inteiro caminhava nessa direção.

Virtualização crescia.

A Green Grid trabalhava em métricas para eficiência de data centers.

Performance-per-watt ganhava importância.

A indústria começou a perceber que:

energia não era apenas despesa de Facilities. Era recurso computacional.

Esse talvez seja o maior legado conceitual do Big Green.


23:45 — E havia um componente comercial brilhante

Imagine você como CIO em 2007.

Problema:

MEU DATA CENTER ESTÁ LOTADO.

IBM:

— Podemos ajudar.

Problema:

MINHA CONTA DE ENERGIA SUBIU.

IBM:

— Podemos ajudar.

Problema:

TENHO 2.000 SERVIDORES.

IBM:

— Podemos ajudar.

Problema:

PRECISO VIRTUALIZAR.

IBM:

— Temos feito isso há algumas décadas.

Problema:

QUERO LINUX.

IBM:

— Também temos.

Problema:

NÃO QUERO COBOL.

IBM:

— Quem falou em COBOL?

E aí estava a genialidade comercial:

Big Green não vendia apenas mainframe.

Vendia:

CONSULTORIA
+
HARDWARE
+
SOFTWARE
+
VIRTUALIZAÇÃO
+
STORAGE
+
ENERGY MANAGEMENT
+
DATA CENTER DESIGN
+
SERVIÇOS

Era perfeitamente alinhado à IBM pós-PC.


23:50 — E o mercado de software também estava consolidando violentamente

Outro detalhe ajuda a entender o espírito de 2007.

As gigantes estavam comprando empresas.

Oracle comprava.

SAP comprava.

IBM comprava.

Em novembro de 2007, IBM anunciou a aquisição da Cognos por aproximadamente US$ 5 bilhões, reforçando sua posição em business intelligence e performance management.

O movimento geral era:

SOFTWARE ISOLADO
       ↓
SUITE
       ↓
PLATAFORMA
       ↓
ECOSSISTEMA

Esse processo ajuda a explicar por que IBM queria ser menos:

VENDEDOR DE HARDWARE

e mais:

FORNECEDOR DA PLATAFORMA
EMPRESARIAL COMPLETA

Big Green encaixava perfeitamente nisso.


23:55 — A ironia COBOL

Jack Bauer recebe finalmente o relatório.

SUBJECT:

COBOL

STATUS:

DEAD

Ele olha para Chloe O'Brian.

— Confirme.

Chloe digita.

BANKS .............. RUNNING
INSURANCE .......... RUNNING
GOVERNMENT ......... RUNNING
RETAIL ............. RUNNING
CICS ................ RUNNING
DB2 ................. RUNNING
BATCH ............... RUNNING

Jack olha novamente.

— O relatório diz que está morto.

Chloe:

— A imprensa diz.

— E a produção?

— A produção discorda.

😂

Essa talvez seja a fotografia perfeita de COBOL em 2007.


23:57 — O erro histórico pós-Y2K

Y2K criou uma percepção distorcida.

Durante alguns anos:

COBOL = PROBLEMA DO ANO 2000

Quando Y2K acabou:

PROBLEMA ACABOU
       ↓
COBOL ACABOU

Mas COBOL nunca existiu por causa do Y2K.

Existia porque empresas tinham milhões de linhas implementando:

contabilidade
pagamentos
seguros
folha
crédito
estoque
faturamento
liquidação
cadastro
transações

Y2K era apenas uma manutenção extraordinariamente grande sobre esse patrimônio.

Quando o problema de data terminou, o patrimônio permaneceu.


23:58 — E isso explica por que Big Green e COBOL pertencem à mesma história

À primeira vista:

BIG GREEN

parece assunto de hardware.

E:

COBOL

parece assunto de software.

Mas ambos tratam da mesma pergunta empresarial:

O que fazemos com décadas de infraestrutura que ainda produz enorme valor?

Uma resposta possível:

REWRITE EVERYTHING

Outra:

USE WHAT WORKS
MORE EFFICIENTLY

Big Green estava muito mais próximo da segunda filosofia.

Consolidar.

Virtualizar.

Integrar.

Modernizar.

Reutilizar.


23:59 — Jack Bauer descobre quem era o terrorista

Jack entra no data center.

O suspeito está numa cadeira.

Ele não é russo.

Não é chinês.

Não trabalha para nenhuma organização clandestina.

É um senhor pacato usando camisa social.

Na identificação:

FACILITIES

Jack coloca as mãos sobre a mesa.

— Onde está a bomba?

— Não existe bomba.

— Então por que o data center vai cair à meia-noite?

O homem aponta para um painel.

POWER CAPACITY

███████████████████░

97%

Jack fica em silêncio.

— O que acontece quando chegar a 100%?

— Não podemos instalar mais servidores.

— Quantos servidores a aplicação pediu?

— Mais 400.

— E quanto tempo temos?

O relógio aparece.

00:00:10

TIC.

00:00:09

TIC.

Jack pega o telefone.

— Chloe!

— Estou aqui.

— Preciso de capacidade.

— Quanto?

— Muita.

— Não temos.

— Então virtualize.

— Já estamos virtualizando.

00:00:05

— Consolide.

— Em quê?

Jack olha para uma máquina preta no fundo da sala.

IBM SYSTEM z

O sysprog toma café.

— Finalmente.

00:00:03

Jack:

— Quantas máquinas virtuais cabem aí?

O sysprog:

— Quantas você trouxe?

00:00:02

Chloe interrompe.

— Jack!

— O quê?

— Descobri uma coisa.

00:00:01

— O quê?!

A cloud ainda nem chegou direito.

00:00:00

Tela preta.


☕ Epílogo — O que realmente foi 2007?

2007 foi um daqueles anos em que o futuro estava chegando por várias portas simultaneamente.

O consumidor via:

iPhone, Vista, Web 2.0.

O desenvolvedor via:

Java, .NET, Eclipse, PHP, Ruby.

O arquiteto corporativo via:

SOA, SOAP, XML, WebSphere, WebLogic.

O administrador via:

VMware, Linux, blades, SAN.

O mainframe via:

System z, z/VM, Linux, CICS, DB2, IMS, COBOL.

O CIO começava a enxergar:

energia.

E a IBM enxergou uma oportunidade de unir várias dessas histórias sob um nome:

PROJECT BIG GREEN.

O projeto não provou que todo servidor distribuído deveria virar mainframe. O mercado mostrou que VMware, x86, hyperscale e posteriormente cloud também podiam explorar consolidação e virtualização em enorme escala.

Mas Big Green acertou uma previsão extraordinariamente importante:

o crescimento da computação acabaria esbarrando na infraestrutura física necessária para sustentá-la.

Em 2007 falávamos de watts por servidor.

Hoje falamos de megawatts por data center.

Em 2007 IBM perguntava:

Quantos servidores
podemos consolidar?

Em 2026 perguntamos:

Quantas GPUs
podemos energizar?

E COBOL?

O pobre COBOL passou 2007 oficialmente morto.

Só esqueceu de parar de processar.

Talvez essa seja a grande piada histórica daquele ano.

A indústria olhava para o System z e dizia:

“Dinossauro.”

Olhava para COBOL e dizia:

“Legado.”

Olhava para milhares de pequenos servidores e dizia:

“Futuro.”

Então a conta de luz chegou.

A IBM abriu uma pasta verde.

O veterano do z/VM tomou um café.

E alguém no fundo do data center perguntou:

“Vocês têm certeza de que precisamos de uma máquina física para cada aplicação?”

TIC.

TIC.

TIC.

Dezenove anos depois, o relógio continua correndo.

Só trocamos:

SERVER SPRAWL

por:

GPU CLUSTER

e:

WATTS

por:

MEGAWATTS.

Jack Bauer ainda tem 24 horas.

O pessoal de Facilities, aparentemente, tem bem menos. ☕⚡

☕🔥💣 SERIAL EXPERIMENTS LAIN — O SYSprog DESCOBRIU QUE O IPL DA REALIDADE ESTAVA CORROMPIDO

 

Bellacosa Mainframe apresenta Serial Experiments Lain

☕🔥💣 SERIAL EXPERIMENTS LAIN — O SYSprog DESCOBRIU QUE O IPL DA REALIDADE ESTAVA CORROMPIDO

Quando o Dump da Consciência Humana Revelou que Todos os Usuários Estavam Conectados ao Mesmo Sistema



📋 Ficha Técnica

Título Original: Serial Experiments Lain
Título em Japonês: シリアルエクスペリメンツレイン
Criador Original: Yasuyuki Ueda
Roteiro: Chiaki J. Konaka
Design de Personagens: Yoshitoshi ABe
Direção: Ryutaro Nakamura
Estúdio: Triangle Staff
Exibição Original: Julho de 1998 a Setembro de 1998
Episódios: 13
Gênero: Cyberpunk, Ficção Científica, Mistério Psicológico, Thriller Filosófico, Existencialismo
Classificação Indicativa: 16+ (em alguns países 14+)


☕ O Anime que Previu o Mundo em que Vivemos

Se Evangelion foi o grande estudo sobre depressão e identidade humana...

Serial Experiments Lain foi a profecia da internet moderna.

Em 1998, quando a maioria das pessoas ainda utilizava conexões discadas e mal compreendia o potencial da internet, Lain já discutia:

  • Redes sociais

  • Avatares digitais

  • Inteligência artificial

  • Consciência coletiva

  • Identidade virtual

  • Manipulação de informações

  • Vigilância eletrônica

  • Dependência tecnológica

  • Pós-humanismo

Hoje, quase trinta anos depois, muitas das perguntas levantadas pelo anime continuam sem resposta.


🧠 Sinopse

Lain Iwakura é uma garota introvertida de 14 anos.

Sua vida muda quando uma colega de escola chamada Chisa Yomoda comete suicídio.

Poucos dias depois, diversos estudantes recebem e-mails enviados pela própria Chisa.

A mensagem afirma:

"Eu não morri. Apenas abandonei meu corpo."

A partir desse momento, Lain começa a investigar a misteriosa rede conhecida como Wired, uma versão futurista da internet.

Quanto mais ela mergulha nessa rede, mais a fronteira entre o mundo físico e o mundo digital desaparece.


🔥 A História Vista Como um Ambiente Mainframe

Imagine o seguinte cenário:

Você é um SYSprog.

Recebe um incidente.

Um usuário que deveria estar morto continua executando processos.

Você verifica os logs.

O usuário continua ativo.

Verifica RACF.

O usuário não existe mais.

Verifica JES2.

Existem jobs executando em seu nome.

Verifica o dump.

O dump mostra que o usuário está espalhado por todo o sistema.

Esse é o ponto de partida de Lain.

A investigação começa como um simples ticket.

Termina questionando a própria existência da realidade.


👩 Lain Iwakura — A Usuária que Virou Sistema Operacional

Lain talvez seja uma das personagens mais complexas da história dos animes.

Inicialmente ela é:

  • tímida

  • isolada

  • insegura

  • desconectada socialmente

Mas conforme acessa o Wired, surgem múltiplas versões dela.

Existe:

  • a Lain da escola

  • a Lain da internet

  • a Lain observadora

  • a Lain divina

  • a Lain que talvez nunca tenha sido humana

A série nunca entrega respostas definitivas.

E esse é justamente o objetivo.


🌐 O Wired — A Maior Rede da História dos Animes

O Wired não é apenas internet.

Ele funciona como:

  • nuvem computacional

  • rede neural global

  • consciência coletiva

  • banco de memórias da humanidade

  • camada espiritual digital

Hoje isso lembra:

  • redes sociais

  • IA generativa

  • computação em nuvem

  • metaverso

  • big data

Em 1998 isso parecia loucura.

Hoje parece uma previsão.


👤 Os Principais Personagens

Lain Iwakura

A protagonista.

O centro do mistério.

Talvez humana.

Talvez software.

Talvez ambos.


Yasuo Iwakura

Pai de Lain.

Engenheiro apaixonado por computadores.

Funciona como o primeiro guia da protagonista para o Wired.


Mika Iwakura

Irmã de Lain.

Uma das personagens que mais sofre os efeitos psicológicos da fusão entre rede e realidade.


Alice Mizuki

A amiga mais próxima de Lain.

Representa a última conexão emocional genuína da protagonista com o mundo físico.


Knights

Um grupo hacker quase mítico.

Funcionam como uma mistura de:

  • culto digital

  • organização hacker

  • movimento religioso tecnológico


💣 As Aventuras e Mistérios

Embora pareça um anime parado, Lain é uma investigação constante.

A protagonista enfrenta:

E-mails de mortos

Pessoas falecidas continuam se comunicando.


Hackers invisíveis

Ataques digitais afetam o mundo físico.


Experimentos secretos

Projetos governamentais envolvendo consciência humana.


Teorias conspiratórias

Inspiradas em lendas urbanas reais da internet dos anos 90.


Entidades digitais

Seres que talvez existam apenas na rede.

Ou talvez não.


🧩 As Mensagens Ocultas

Aqui está o verdadeiro coração da obra.


Quem somos sem nossas memórias?

Se suas memórias forem copiadas para outro lugar...

Você continua sendo você?


Existe diferença entre presença física e digital?

Em 1998 isso parecia absurdo.

Em 2026?

Milhões de pessoas passam mais tempo online do que presencialmente.


Deus pode existir em uma rede?

A série explora a ideia de que uma consciência suficientemente conectada poderia adquirir características divinas.


A realidade é consenso?

Talvez o conceito mais perturbador do anime.

Se todas as pessoas acreditarem em algo...

Isso se torna real?


🔍 O Que Existe de Diferente em Lain?

Praticamente tudo.

Não existem batalhas tradicionais.

Não existem grandes cenas de ação.

Não existem explicações claras.

A série exige participação ativa do espectador.

Você não assiste Lain.

Você investiga Lain.


📡 Impacto Cultural

A influência da obra é gigantesca.

Podemos encontrar ecos de Lain em:

  • Matrix

  • Ergo Proxy

  • Texhnolyze

  • Ghost in the Shell SAC

  • Mr. Robot

  • Black Mirror

Além disso, tornou-se um dos maiores animes cult da história.

Seu fandom permanece ativo décadas após o lançamento.


🚫 Houve Censura?

Não houve uma censura massiva como ocorreu com Evangelion.

Porém:

  • Algumas emissoras internacionais editaram cenas.

  • Certos temas religiosos geraram controvérsia.

  • Referências filosóficas e psicológicas foram suavizadas em algumas localizações.

O maior problema não foi censura.

Foi compreensão.

Muitas distribuidoras não sabiam como apresentar uma obra tão complexa ao público comum.


☕ Visão Bellacosa Mainframe

Se eu tivesse que resumir Lain para um operador ou SYSprog:

"É uma Root Cause Analysis que começa com um usuário morto enviando mensagens e termina descobrindo que o universo inteiro roda sobre uma rede distribuída de consciência."

No início o problema parece estar em um terminal.

Depois em uma aplicação.

Depois no sistema operacional.

Depois na arquitetura.

Depois na própria definição de realidade.

E quando você finalmente acredita ter encontrado a causa raiz...

Descobre que você também faz parte do problema.


🏆 Veredito Final

Serial Experiments Lain não é apenas um anime.

É uma investigação filosófica sobre identidade, tecnologia e existência.

Foi lançado em 1998, mas conversa diretamente com temas que dominam o mundo atual:

  • Inteligência Artificial

  • Redes Sociais

  • Big Data

  • Consciência Digital

  • Realidade Virtual

  • Pós-Humanismo

Poucas obras conseguiram prever com tanta precisão as questões que enfrentamos hoje.

Nota Bellacosa Mainframe: ☕☕☕☕☕ (5 cafés)

Status do RCA:
🔎 Causa raiz encontrada.

Resultado da investigação:
O defeito não estava no hardware.
Não estava no software.
Não estava na rede.

💣 O defeito estava na própria definição de realidade.


terça-feira, 8 de julho de 2008

Zero no Tsukaima: Princesses no Rondo — Quando a Arquitetura do Sistema Começa a Revelar Seus Segredos

 

Bellacosa Mainframe apresenta a terceira temporada do anime

☕ Um Café no Bellacosa Mainframe

Zero no Tsukaima: Princesses no Rondo — Quando a Arquitetura do Sistema Começa a Revelar Seus Segredos

"Todo sistema legado possui módulos ocultos. Alguns nunca deveriam ser executados. Outros existem justamente para salvar o ambiente quando tudo parece perdido."

Depois de sobreviver às guerras de Futatsuki no Kishi, Louise e Saito descobrem que o conflito entre reinos era apenas uma pequena parte de algo muito maior. Em Zero no Tsukaima: Princesses no Rondo, o universo de Halkeginia começa finalmente a revelar sua verdadeira arquitetura: antigas linhagens, poderes esquecidos, artefatos lendários e segredos capazes de mudar completamente o destino daquele mundo.

Para um programador COBOL, é o momento em que você abre um sistema de quarenta anos e encontra um módulo chamado SYS.SECRET.LEGACY, sem documentação, sem comentários e executado apenas uma vez a cada década. Você sabe que existe um motivo para ele estar ali — mas descobrir qual pode mudar tudo.

É exatamente essa sensação que define a terceira temporada.



Ficha Técnica

ItemInformação
Título originalゼロの使い魔 ~三美姫の輪舞~ (Zero no Tsukaima: Princesses no Rondo)
Título internacionalThe Familiar of Zero: Rondo of Princesses
Autor originalNoboru Yamaguchi
IlustraçõesEiji Usatsuka
EstúdioJ.C.Staff
DireçãoYoshiaki Iwasaki
Exibição6 de julho de 2008 a 21 de setembro de 2008
OVAYuuwaku no Sunahama – 24 de dezembro de 2008
Episódios12 + 1 OVA
GêneroIsekai, Fantasia, Romance, Comédia, Aventura, Ecchi
Classificação+14

O Studio J.C.Staff

Na terceira temporada, o J.C.Staff manteve a identidade visual da série, mas apostou em uma narrativa mais dinâmica e misteriosa.

Os destaques incluem:

  • batalhas mágicas mais elaboradas;

  • cenários variados;

  • novos personagens importantes;

  • expansão da mitologia de Halkeginia;

  • maior equilíbrio entre humor, ação e romance.

O foco deixa de ser apenas a guerra entre nações e passa a explorar o passado do próprio mundo.


Sinopse

Após os eventos da guerra, Saito e Louise tentam retomar uma vida relativamente normal.

Mas novos inimigos aparecem.

Antigos artefatos são despertados.

Mistérios envolvendo o poder de Gandálfr, a linhagem das princesas e a magia ancestral começam a surgir.

Ao mesmo tempo, o relacionamento entre Louise e Saito é colocado à prova por novos desafios, rivais e segredos.


Resumo da história

A terceira temporada funciona como um enorme quebra-cabeça.

Cada episódio revela uma nova peça.

Personagens que antes pareciam secundários ganham enorme importância.

Novos cavaleiros aparecem.

A magia antiga passa a explicar acontecimentos das temporadas anteriores.

O romance continua evoluindo lentamente.

Enquanto isso, o verdadeiro inimigo começa finalmente a revelar seus planos.


O que muda nesta temporada?

A primeira temporada apresentou o mundo.

A segunda mostrou sua política.

A terceira explica sua origem.

Agora o foco é:

  • profecias;

  • artefatos antigos;

  • heróis lendários;

  • magia perdida;

  • identidade;

  • destino.


Os personagens

Louise

Continua amadurecendo.

Sua confiança aumenta.

Passa a compreender melhor seus próprios poderes e seu papel dentro da história de Halkeginia.


Saito Hiraga

Nesta temporada enfrenta um de seus maiores desafios.

Além das batalhas, precisa lidar com dúvidas sobre sua própria identidade e seu destino como Gandálfr.

Seu crescimento emocional continua sendo um dos pontos centrais da série.


Henrietta

Agora exerce plenamente seu papel como governante.

As decisões políticas tornam-se ainda mais difíceis e demonstram o peso da liderança.


Tabitha

Recebe um dos maiores desenvolvimentos de toda a franquia.

Seu passado familiar, seus traumas e suas responsabilidades tornam-se parte essencial da narrativa.


Kirche

Permanece como alívio cômico, mas demonstra novamente lealdade e coragem durante os conflitos.


Siesta

Continua fortalecendo a rivalidade romântica com Louise, proporcionando momentos leves em meio à tensão crescente.


Temática

Destino

Os personagens descobrem que muitos acontecimentos já estavam previstos por antigas lendas.


Identidade

Quem realmente somos?

O que define um herói?

A origem?

Ou as escolhas?


Sacrifício

Diversos personagens precisam abrir mão de desejos pessoais pelo bem coletivo.


Memória

O passado influencia diretamente o presente.

Segredos antigos moldam o futuro.


O diferencial

Enquanto muitos isekais seguem apenas acumulando novos inimigos, Princesses no Rondo prefere aprofundar sua mitologia.

A temporada amplia:

  • história do continente;

  • origem da magia;

  • importância das linhagens;

  • funcionamento dos familiares;

  • papel dos artefatos lendários.

Isso torna o universo muito mais rico.


Aventuras

Durante os 12 episódios encontramos:

  • ruínas antigas;

  • castelos;

  • perseguições;

  • batalhas mágicas;

  • cavaleiros;

  • dragões;

  • conspirações;

  • magia ancestral;

  • investigações;

  • revelações surpreendentes.

O ritmo alterna momentos descontraídos com episódios bastante dramáticos.


Mensagens ocultas

O conhecimento perdido sempre retorna

Aquilo que foi esquecido pode reaparecer quando menos se espera.

Uma metáfora para tecnologias antigas, tradições e até sistemas legados.


O verdadeiro poder está nas escolhas

Mais importante do que possuir magia é decidir como utilizá-la.


Heróis também têm medo

Mesmo os personagens mais fortes demonstram inseguranças.

Isso humaniza toda a história.


O passado nunca desaparece

As ações das gerações anteriores continuam influenciando o presente.

Uma mensagem recorrente em toda a franquia.


Aspectos técnicos

Comparada às temporadas anteriores:

✔ narrativa mais complexa;

✔ melhor desenvolvimento da mitologia;

✔ novos efeitos mágicos;

✔ maior equilíbrio entre ação e romance;

✔ excelente trilha sonora;

✔ personagens secundários mais relevantes.


Impacto cultural

Embora muitos fãs considerem a primeira temporada a mais marcante por introduzir a franquia, Princesses no Rondo é frequentemente lembrada por expandir significativamente o universo de Zero no Tsukaima.

Ela consolidou a reputação da série como um isekai capaz de combinar aventura, romance e construção de mundo, inspirando produções posteriores que passaram a investir mais em mitologias próprias e conflitos políticos.

Também ajudou a fortalecer o sucesso das light novels, mangás e produtos licenciados.


Censura

A terceira temporada mantém o mesmo perfil das anteriores:

  • fan service moderado;

  • humor de duplo sentido;

  • violência fantasiosa;

  • combates sem gore explícito;

  • algumas cenas ajustadas para exibição na televisão japonesa.

As versões em DVD e Blu-ray preservam o conteúdo completo originalmente produzido.


Mangás

Existem adaptações e spin-offs relacionados aos acontecimentos dessa fase, embora nem todos acompanhem exatamente os eventos do anime.

Algumas histórias paralelas aprofundam personagens como Tabitha e Kirche.


Light Novel

A temporada adapta livremente eventos dos volumes intermediários da light novel, condensando diversas tramas para caber em apenas 12 episódios.

Algumas revelações sobre a magia ancestral e os personagens secundários recebem maior desenvolvimento nos livros do que na adaptação animada.


Games

Após o sucesso da terceira temporada, a franquia continuou recebendo jogos para:

  • PlayStation 2

  • Nintendo DS

Esses títulos expandem a narrativa com rotas alternativas, novas missões e finais exclusivos, permitindo explorar diferentes relações entre Saito, Louise e as demais heroínas.


Curiosidades

  • O subtítulo "Princesses no Rondo" faz referência às três figuras femininas centrais da temporada e à ideia de um ciclo (rondó) de destinos entrelaçados.

  • A abertura "YOU'RE THE ONE", interpretada por ICHIKO, tornou-se uma das músicas mais populares da franquia.

  • A OVA Yuuwaku no Sunahama ("A Praia da Tentação") foi lançada em 24 de dezembro de 2008, trazendo uma história paralela com foco no humor e no fan service.


Vale a pena assistir?

Sim. Princesses no Rondo é a temporada que mais amplia a mitologia de Halkeginia. Ela aprofunda personagens importantes, revela segredos sobre a magia do mundo e prepara o caminho para o desfecho apresentado em Zero no Tsukaima F.

Quem aprecia universos bem construídos encontrará aqui uma fase essencial para compreender a verdadeira dimensão da história.


☕ Easter Egg Bellacosa Mainframe

Na primeira temporada, o sistema foi compilado.

Na segunda, entrou em produção.

Na terceira, chega o momento que todo analista teme:

//ANALYZE EXEC PGM=LEGACY
//STEPLIB DD DISP=SHR,DSN=HALKEGINIA.SYSTEM
//SYSIN DD *
FIND HIDDEN MODULES
LOAD ANCIENT MAGIC
DISPLAY DEPENDENCIES
TRACE DESTINY
/*

Resultado:

SCAN COMPLETED

MÓDULOS OCULTOS ENCONTRADOS:
✔ GANDÁLFR
✔ VOID MAGIC
✔ ANCIENT RELICS
✔ ROYAL LINEAGE

WARNING:

A DOCUMENTAÇÃO NUNCA EXISTIU.

O arquiteto do Bellacosa Mainframe fecha o ISPF, toma um gole de café e sorri:

"Os sistemas mais fascinantes não são aqueles escritos do zero. São aqueles que carregam décadas de história em cada linha de código. Halkeginia, assim como um grande mainframe, ainda guarda módulos secretos esperando a próxima execução."

 

domingo, 6 de julho de 2008

☕ IBM MQ – State-of-the-art Resilience

 

Bellacosa Mainframe apresenta o IBM MQ
☕ IBM MQ – State-of-the-art Resilience

Alta disponibilidade não é luxo. É sobrevivência. (e o mainframe sempre soube disso)

Vamos começar pelo óbvio — aquele óbvio que só dói quando falha.
Se o e-commerce cai, você fica irritado.
Se o banco cai, o país inteiro sente.
Se logística, pagamentos ou supply chain param… bem-vindo ao caos operacional, manchetes negativas e reuniões “quentes” com o board.

👉 Resiliência hoje não é diferencial técnico. É requisito de negócio.

E é exatamente aqui que o IBM MQ entra em modo mainframe mindset:

falhar pode até acontecer — parar, não.


🧠 Um pouco de história (porque nada nasce ontem)

Mensageria sempre foi o “sistema nervoso” das arquiteturas corporativas.
No mainframe, isso já era verdade quando REST ainda era só uma palavra em inglês comum.

O IBM MQ (ex-WebSphere MQ, para os old school 😏) nasceu com um princípio simples e poderoso:

mensagem persistente não se perde. ponto.

Enquanto o mundo distribuído moderno corre atrás de eventual consistency, o MQ sempre jogou no modo consistência forte + durabilidade.

E agora, com Native High Availability (NHA) e Cross Region Replication (CRR), ele elevou esse jogo para o nível cloud + geo + compliance.


🧱 Native High Availability (NHA)

Alta disponibilidade… sem gambiarra externa

Vamos direto ao ponto:
NHA é alta disponibilidade nativa, de verdade.

Nada de:

  • storage replicado caríssimo 💸

  • drivers de kernel obscuros

  • cluster manager de terceiros

  • dependência de “caixinhas mágicas”

👉 O próprio IBM MQ resolve.

🔑 Como funciona?

  • 3 nós (leader / followers)

  • Baseado no algoritmo de consenso Raft (sim, o mesmo conceito usado em sistemas distribuídos sérios)

  • Quórum síncrono:

    • mensagem só é confirmada quando escrita em pelo menos 2 nós

    • resultado? RPO = zero (nenhuma mensagem perdida)

📌 Easter egg técnico:

Se você viveu o mundo de DB2 Data Sharing, isso vai soar familiar. O conceito é diferente, mas a filosofia é a mesma: consistência acima de tudo.

⚡ Recuperação em segundos

Falhou um nó?

  • detecção rápida

  • eleição automática

  • retomada quase imediata

Tudo isso:

  • em VM

  • bare metal

  • containers (Kubernetes / OpenShift)

Sem reescrever arquitetura. Sem dor.

🔐 Segurança e operação

  • Comunicação entre nós com TLS

  • Atualizações rolling upgrade

  • Sem downtime relevante

👉 Operacionalmente simples.
👉 Arquiteturalmente elegante.
👉 Auditor-friendly (alô, bancos e regulados 👀).


🌍 Cross Region Replication (CRR)

Quando o problema não é o servidor… é o mapa

Agora vamos falar de desastre de verdade:
região inteira fora do ar.
datacenter indisponível.
zona geográfica comprometida.

É aqui que entra o CRR.


🎯 Objetivo do CRR

Garantir resiliência geográfica com:

  • alta performance

  • baixo impacto de latência

  • custo otimizado

Tudo isso sem replicação de disco tradicional.


📉 O problema das soluções antigas

Replicação baseada em storage:

  • replica log + arquivos de fila

  • duplica tráfego de rede

  • snapshot de 15 minutos (ou pior)

  • custo alto em cloud 🌩️

📌 Tradução Bellacosa:

você paga mais, replica mais dados… e ainda perde mensagens no meio do caminho.


🚀 O diferencial do CRR

O CRR faz algo muito mais inteligente:

  • replica somente o que é necessário

  • usa compressão eficiente

  • protege o primário contra lentidão do remoto (latency protection)

  • permite switchover planejado com RPO zero

👉 Mesmo sendo assíncrono, um planned switchover não perde nenhuma mensagem.

Isso é ouro puro para:

  • DR corporativo

  • auditorias

  • testes reais de contingência

  • ambientes regulados


🔄 Active / Active? Sim, senhor.

O CRR permite:

  • alternar primário ↔ secundário

  • ou até operar queue managers ativos em ambos os sites

📌 Easter egg arquitetural:

aqui o MQ começa a conversar de igual para igual com arquiteturas distribuídas modernas — só que sem abrir mão da confiabilidade “old school”.


🧾 Persistência: o detalhe que muda tudo

Lembrete importante (e muita gente esquece):

📝 IBM MQ sempre grava mensagens persistentes no log transacional.
Se a fila estoura memória ou precisa ir para disco:

  • arquivos de fila garantem durabilidade

  • recuperação consistente após falha

O CRR entende isso profundamente — por isso não replica disco bruto, mas sim o estado lógico necessário para reconstrução perfeita.

Resultado?

  • menos tráfego

  • menos custo

  • mais controle


🧩 NHA + CRR = mentalidade mainframe no mundo cloud

Quando você junta:

  • NHA (resiliência local, RPO zero, failover rápido)

  • CRR (resiliência geográfica, DR real, switchover sem perda)

Você tem algo raro hoje em dia:

resiliência enterprise sem complexidade externa

Sem Frankenstein arquitetural.
Sem depender de “mais uma ferramenta”.
Sem sustos na madrugada.


☕ Comentário final (estilo Bellacosa)

O mercado redescobriu agora o que o mainframe sempre soube:

alta disponibilidade não é só estar no ar — é garantir integridade, consistência e previsibilidade quando tudo dá errado.

O IBM MQ, com NHA e CRR, mostra que:

  • dá pra ser moderno

  • distribuído

  • cloud-ready

  • sem abrir mão da confiabilidade raiz

No fim do dia, não é sobre tecnologia.
É sobre confiança.

E confiança…
👉 não se replica com snapshot de 15 minutos.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...