Translate

quinta-feira, 9 de fevereiro de 2012

😈 CAP Theorem explicado para quem já confiou em commit em duas fases

 


😈 CAP Theorem explicado para quem já confiou em commit em duas fases


00:00 — Introdução: quando a teoria virou dor real

Se você é mainframer e já confiou em Two-Phase Commit, já viveu o CAP Theorem antes dele ter nome.
A diferença é que, no mainframe, chamávamos isso de:

“Ou o dado está certo, ou o sistema fica em pé. Os dois ao mesmo tempo… depende.”

O Teorema CAP nasceu no mundo distribuído moderno, mas suas raízes estão lá atrás, nos tempos de IMS, CICS, DB2, sysplex e coordenação distribuída feita no braço.



1️⃣ O que é CAP (sem marketing)

CAP diz que, em um sistema distribuído, quando ocorre uma falha de rede, você só pode garantir duas das três propriedades:

  • C – Consistency (Consistência)
    Todos veem o mesmo dado ao mesmo tempo.

  • A – Availability (Disponibilidade)
    O sistema sempre responde.

  • P – Partition Tolerance (Tolerância a partições)
    O sistema continua funcionando mesmo com falhas de rede.

⚠️ Spoiler mainframer:
P não é opcional. Se existe rede, vai haver partição.


2️⃣ A tradução CAP → dialeto mainframe 🧠

CAPMainframe raiz entende como
ConsistencyCommit garantido, dado íntegro
AvailabilityRegião em pé, SLA preservado
PartitionLink caiu, LPAR isolada, XCF brigando

👉 CAP não é escolha ideológica.
É decisão de sobrevivência.


3️⃣ Two-Phase Commit: o trauma fundador 😵

Fase 1 – Prepare

  • Todos dizem: “posso gravar?”

  • Locks segurados

  • Esperança intacta

Fase 2 – Commit

  • Coordenador manda gravar

  • Um nó não responde…

  • Silêncio

  • Lock eterno

  • DBA acordado

😈 Easter egg:
Quem já viu in-doubt transaction sabe que CAP não é slide de PowerPoint.


4️⃣ Onde o CAP dói de verdade

🔥 Consistência vs Disponibilidade

  • Quer dado correto?
    → Pode ficar indisponível.

  • Quer sistema respondendo?
    → Pode responder com dado antigo.

No mainframe, a escolha histórica foi:

Consistência acima de tudo.

No mundo web:

Disponibilidade acima de tudo.


5️⃣ Por que P não se discute

Em ambiente distribuído:

  • Switch falha

  • Roteador reinicia

  • Zona cai

  • Cloud provider “pisca”

📌 Curiosidade:
No sysplex, a IBM passou décadas tentando domar P com hardware, coupling facility e engenharia absurda.

Mesmo assim… partição acontece.


6️⃣ Modelos modernos (com cheiro de legado)

CP – Consistent + Partition tolerant

  • DB2

  • Sistemas financeiros

  • Core banking

💬 “Se não gravar certo, melhor não gravar.”

AP – Available + Partition tolerant

  • Cassandra

  • DynamoDB

  • Sistemas de catálogo, feeds, logs

💬 “Mostra algo agora, conserta depois.”


7️⃣ Eventual Consistency: o nome chique do “daqui a pouco acerta”

Mainframer traduz:

“Batch de reconciliação”

  • Dados podem divergir temporariamente

  • Em algum momento, convergem

  • Desde que não falhe tudo 😈

📎 Easter egg:
Você já fez eventual consistency com VSAM + batch noturno e nem percebeu.


8️⃣ Passo a passo para decidir CAP na prática

1️⃣ O dado é financeiro ou regulatório?
C é obrigatório

2️⃣ O usuário pode esperar?
→ Talvez A não seja crítica

3️⃣ Se a rede cair, pode parar tudo?
→ Se não, aceite inconsistência temporária

4️⃣ Existe reconciliação posterior?
→ Batch, eventos, compensação

5️⃣ Quem assume o erro?
→ Sistema ou negócio?


9️⃣ Guia de estudo para mainframers inquietos 📚

Conceitos

  • CAP Theorem

  • PACELC (CAP com latência)

  • Eventual Consistency

  • Sagas (compensação)

Ferramentas e paralelos

  • XA / 2PC → Transaction Coordinator

  • Kafka → MQ + replay

  • Sagas → Rollback manual versão cloud

  • Observabilidade → SMF espiritual


🔟 Aplicações práticas no mundo híbrido

  • Integrar DB2 com microservices

  • Decidir quando expor APIs síncronas

  • Projetar sistemas resilientes

  • Evitar 2PC em cloud (sim, evite!)

  • Atuar como arquiteto de verdade, não só operador

🎯 Mainframer que entende CAP vira arquiteto respeitado.


1️⃣1️⃣ Comentário final (02:17 da manhã)

CAP não é teoria acadêmica.
É a explicação formal da dor que você já sentiu.

Se você já:

  • Perdeu noite por commit travado

  • Desconfiou de dado “meio gravado”

  • Escolheu derrubar tudo para não corromper

Então parabéns.
Você praticou CAP antes de virar hype.

🖤 El Jefe Midnight Lunch conclui:
Cloud é só o mainframe que esqueceu suas lições.

terça-feira, 7 de fevereiro de 2012

🍜 Gochisō-sama! — Onomatopeias japonesas à mesa, analisadas por um mainframeiro curioso

 

zuru zuru


🍜 Gochisō-sama! — Onomatopeias japonesas à mesa, analisadas por um mainframeiro curioso

Quem assiste anime com atenção (e sem pular opening, porque isso é pecado 😄) já percebeu: comer no Japão não é silencioso. Pelo contrário. É barulhento, expressivo, quase um log de execução em tempo real. E aí entram elas: as onomatopeias japonesas, aquelas palavrinhas mágicas que traduzem som, sensação, textura e até emoção — algo que a nossa língua tenta, mas raramente alcança.

No Japão, comer não é só nutrir o corpo. É experiência sensorial, e as onomatopeias são o CICS TRACE do paladar.


🍜 1. ZURU-ZURU (ずるずる) — O som sagrado do macarrão

Como se escreve: ずるずる
Como se usa: “Zuru-zuru taberu”
O que significa: Som de puxar macarrão, lámen ou udon

Essa é clássica. O barulho de sugar o macarrão não é falta de educação, é elogio ao cozinheiro. Quanto mais zuru-zuru, mais gostoso está.

🎬 Animes:

  • Naruto — Naruto Uzumaki no Ichiraku Ramen

  • Gintama — praticamente um festival de zuru-zuru

  • Food Wars (Shokugeki no Soma) — close sonoro garantido

💡 Curiosidade: sugar o macarrão ajuda a esfriar e realçar o sabor. É engenharia térmica aplicada à culinária.


paku paku



🍖 2. PAKU-PAKU (ぱくぱく) — Comer com vontade

Como se escreve: ぱくぱく
Uso: “Paku-paku taberu”
Significado: Comer repetidamente, com fome ou entusiasmo

É aquele personagem que está faminto, devora tudo rápido, quase sem respirar.

🎬 Animes:

  • One Piece — Luffy é praticamente o mascote do paku-paku

  • My Neighbor Totoro — crianças comendo felizes

🥚 Easter egg: Paku-paku também descreve bocas abrindo e fechando — tipo peixinhos. Simples, visual, japonês até o osso.


mogu mogu


🍙 3. MOGU-MOGU (もぐもぐ) — Mastigação feliz

Como se escreve: もぐもぐ
Uso: “Mogu-mogu shiteru”
Significado: Mastigar calmamente

Essa é quase um ASMR linguístico. Indica alguém comendo concentrado, satisfeito, em silêncio respeitoso.

🎬 Animes:

  • K-On! — cenas de lanche são puro mogu-mogu

  • Yuru Camp — comida + paz = mogu-mogu zen

💡 Dica cultural: usado até em personagens tímidos, que comem sem falar. Comunicação sem palavras.


saku saku

🍰 4. SAKU-SAKU (さくさく) — Crocância perfeita

Como se escreve: さくさく
Uso: “Saku-saku shiteru”
Significado: Algo crocante e leve

Tempurá, tonkatsu, biscoitos. Se está saku-saku, está no ponto.

🎬 Animes:

  • Food Wars — descrição técnica + poesia

  • March Comes in Like a Lion — doces tradicionais

🥢 Curiosidade: o japonês tem dezenas de palavras só para textura. Nós dizemos “crocante”. Eles fazem firmware dedicado.


toro toro

🍡 5. TORO-TORO (とろとろ) — Cremoso, derretendo

Como se escreve: とろとろ
Uso: “Tamago ga toro-toro”
Significado: Macio, cremoso, quase líquido

Ovo com gema mole, curry, ensopados longamente cozidos.

🎬 Animes:

  • Oishinbo — tratado acadêmico da culinária

  • Food Wars — câmera lenta + toro-toro

💡 Bellacosa insight: toro-toro é o oposto de batch rígido. É processamento suave, em fluxo contínuo.


goku goku

🍺 6. GOKU-GOKU (ごくごく) — Beber com sede

Como se escreve: ごくごく
Uso: “Biiru o goku-goku nomu”
Significado: Beber grandes goles

Depois do trabalho, do treino ou da batalha contra demônios.

🎬 Animes:

  • Dragon Ball — Goku bebendo qualquer coisa

  • Salaryman Kintaro

🍶 Easter egg: aparece muito em propagandas japonesas. Marketing sonoro puro.


umai umai

😋 7. UMA! / UMAI! (うま! / うまい!) — O veredito final

Significado: “Delicioso!”

Curto, direto, sincero. É o return code 0 da refeição.

🎬 Animes:

  • Naruto

  • Demon Slayer — Tengen Uzui é um festival de exageros


🍱 Conclusão — Comer também é linguagem

No Japão (e nos animes), comer é narrado em som. As onomatopeias funcionam como logs detalhados do prazer gastronômico. Não é infantil, é sofisticado. É quase um JCL do paladar, onde cada etapa da experiência é registrada.

Da próxima vez que você ouvir um zuru-zuru ou um mogu-mogu, não estranhe. Sorria. Você está ouvindo cultura, história e emoção — tudo servido numa tigela fumegante.

E como diria qualquer personagem depois da refeição:

ごちそうさまでした — Gochisō-sama deshita! 🍜


domingo, 5 de fevereiro de 2012

🖥️🤖🎬 WESTWORLD (1973/1978): quando o parque temático vira ambiente produtivo

 


🖥️🤖🎬 WESTWORLD (1973/1978): quando o parque temático vira ambiente produtivo


Antes de IA generativa, antes de machine learning virar buzzword, Michael Crichton já rodava simulações perigosas. Westworld nasce como filme em 1973, escrito e dirigido por Crichton, e ganha romance em 1978, quando o autor transforma o roteiro em literatura técnica disfarçada de ficção. Aqui não existe “se”: existe quando o sistema sai do controle.



🧠 A história (ou: quando o batch não encerra)

Em Westworld, turistas ricos visitam parques temáticos hiper-realistas povoados por androides — versões humanas de NPCs programados para nunca ferir clientes. Velho Oeste, Roma Antiga, Idade Média. Escolha o ambiente, rode o cenário, consuma a experiência.

O problema começa quando pequenas falhas se acumulam. Nada explode de imediato. Primeiro, um comportamento estranho. Depois, um atraso na resposta. Até que o sistema simplesmente não aceita mais comandos administrativos.

📌 Mainframe insight: todo desastre começa com um warning ignorado.



📚 Filme vs Livro (diferença de arquitetura)

  • 🎬 Filme (1973): direto, seco, quase documental. O terror vem da frieza técnica.

  • 📘 Livro (1978): expande o pensamento sistêmico, o medo do complexity creep e a arrogância corporativa.

Ambos tratam os androides não como vilões, mas como processos que executam exatamente o que foram projetados para fazer.



🧩 Ideias centrais (Crichton em estado puro)

  • Sistemas complexos não falham de forma isolada

  • Automação sem auditoria vira ameaça

  • Segurança “garantida” é apenas marketing

  • Humanos confiam demais em painéis verdes

“Nada pode dar errado” é a frase mais perigosa de qualquer datacenter.


🤖 O pistoleiro (Yul Brynner)

O androide pistoleiro é um daemon imortal. Ele não se cansa, não hesita, não questiona. Ele não odeia. Ele executa.

🥚 Easter egg histórico: seu visual inspirou diretamente o T-800 de Exterminador do Futuro.
🤫 Fofoquice: Brynner aceitou o papel justamente por parecer “anti-humano”.



🥚 Curiosidades técnicas

  • Westworld foi um dos primeiros filmes a usar imagem digital processada por computador

  • A falha do parque é explicada como efeito cascata, conceito raro no cinema da época

  • O centro de controle parece mais um NOC do que uma sala de vilões


☕ Dicas de leitura e exibição (modo operador)

  • Observe como ninguém entende o sistema por completo

  • Repare no desdém da gerência pelos técnicos

  • Preste atenção no excesso de confiança

  • Compare com incidentes reais de TI


🧠 Filosofia oculta (o verdadeiro bug)

Westworld não é sobre robôs assassinos. É sobre governança. Sobre criar sistemas que funcionam tão bem que ninguém mais sabe desligá-los.

Crichton nos alerta:

  • Complexidade cresce mais rápido que controle

  • Segurança absoluta não existe

  • Humanos terceirizam responsabilidade para máquinas

🖥️ Comentário final Bellacosa
Westworld é obrigatório para todo profissional que trabalha com sistemas críticos, automação ou IA. Porque no fim, o perigo não é o androide ganhar consciência — é o humano perder a sua.

MAINFRAME ONLINE. PARQUE ABERTO. SAÍDA INDISPONÍVEL.

sábado, 4 de fevereiro de 2012

Zero no Tsukaima F — Quando o Sistema Entra na Última Execução e o Destino Recebe o Commit Final

 

Bellacosa Mainframe e a quarte temporada do zero no tsukaima f

☕ Um Café no Bellacosa Mainframe

Zero no Tsukaima F — Quando o Sistema Entra na Última Execução e o Destino Recebe o Commit Final

"Todo grande sistema chega ao seu último processamento. O importante não é apenas encerrar o JOB sem ABEND, mas garantir que toda a história faça sentido quando o log for arquivado."

Depois de três temporadas construindo um universo repleto de magia, guerras, romance e conspirações, Zero no Tsukaima F representa o grande encerramento da adaptação em anime. É aqui que Louise, Saito e seus companheiros enfrentam a maior ameaça de Halkeginia e, ao mesmo tempo, precisam concluir suas jornadas pessoais.

Para um programador COBOL, esta temporada lembra o momento em que um sistema legado, desenvolvido ao longo de décadas, recebe sua última grande atualização antes do encerramento do projeto. Todas as dependências precisam funcionar, nenhum módulo pode falhar e o resultado precisa justificar anos de desenvolvimento.

Assim é Zero no Tsukaima F: o deploy definitivo.



Ficha Técnica

ItemInformação
Título originalゼロの使い魔F (Zero no Tsukaima F)
Título internacionalThe Familiar of Zero F
Autor originalNoboru Yamaguchi
IlustraçõesEiji Usatsuka
EstúdioJ.C.Staff
DireçãoYoshiaki Iwasaki
Exibição7 de janeiro de 2012 a 24 de março de 2012
Episódios12
OrigemLight Novel (adaptação parcial dos volumes finais disponíveis na época)
GêneroIsekai, Fantasia, Romance, Comédia, Aventura, Ecchi
Classificação+14

O Studio J.C.Staff

Após um intervalo de quase quatro anos desde a terceira temporada, o J.C.Staff retornou para produzir o encerramento da série.

O estúdio preservou o estilo visual característico, mas entregou:

  • batalhas em maior escala;

  • efeitos mágicos mais refinados;

  • animação mais consistente;

  • maior foco nas emoções dos protagonistas;

  • um ritmo acelerado para concluir a adaptação.

Apesar das limitações de episódios, a temporada consegue transmitir a sensação de grande final.


Sinopse

Louise e Saito finalmente compreendem a verdadeira dimensão dos poderes que carregam.

A ameaça final coloca Halkeginia em risco.

Enquanto antigos aliados se unem para enfrentar o inimigo definitivo, o casal precisa decidir entre dever, sacrifício e amor.

O destino dos dois mundos torna-se inseparável.


Resumo da história

A quarta temporada reúne praticamente todos os elementos desenvolvidos anteriormente.

Magia ancestral.

Artefatos lendários.

Linhagens reais.

Familiares.

Gandálfr.

Void Magic.

Tudo converge para um único conflito.

Ao mesmo tempo, Louise e Saito finalmente enfrentam seus próprios sentimentos de maneira mais madura.

É uma temporada de despedidas.


O que muda nesta temporada?

Enquanto as anteriores construíam o universo, Zero no Tsukaima F concentra-se em responder perguntas e concluir arcos narrativos.

O foco está em:

  • resolução dos mistérios;

  • conclusão do romance;

  • batalha final;

  • destino de Halkeginia;

  • encerramento da jornada de Saito.


Os personagens

Louise

A jovem insegura conhecida como "Louise Zero" transforma-se definitivamente em uma poderosa maga.

Sua evolução emocional é completa.

Agora ela lidera, protege e assume suas responsabilidades.


Saito Hiraga

Chega ao auge de seu desenvolvimento.

Já não é apenas um estudante perdido em outro mundo.

Torna-se um verdadeiro herói.

Suas decisões passam a influenciar o destino de todos.


Tiffania

Recebe papel importante nesta fase.

Sua ligação com a magia Void torna-se fundamental para os acontecimentos finais.


Henrietta

Consolida-se como rainha.

Mostra maturidade política e capacidade de liderança.


Tabitha

Conclui seu arco pessoal iniciado nas temporadas anteriores.


Kirche

Permanece fiel aos amigos até o fim.

Mesmo mantendo seu humor característico.


Siesta

Continua representando a vida simples que Saito poderia ter escolhido.

Seu papel reforça os conflitos românticos da temporada.


Temática

Destino

É possível escapar daquilo que parecia escrito?

Toda a temporada gira em torno dessa questão.


Amor verdadeiro

Louise e Saito deixam de ser apenas um casal cômico.

Agora enfrentam escolhas que exigem confiança absoluta.


Sacrifício

Ser herói implica abrir mão de desejos pessoais.

Diversos personagens aprendem essa lição.


Esperança

Mesmo diante da destruição, ainda existe espaço para reconstrução.


O diferencial

Ao contrário de muitos isekais que continuam indefinidamente, Zero no Tsukaima F oferece uma conclusão.

Ela encerra:

  • o crescimento de Louise;

  • a jornada de Saito;

  • os conflitos políticos;

  • o mistério da magia Void;

  • a ameaça principal.

Poucas séries do gênero conseguem finalizar tantos arcos em apenas uma temporada.


Aventuras

Os 12 episódios apresentam:

  • batalhas finais;

  • magia em larga escala;

  • dragões;

  • fortalezas;

  • artefatos lendários;

  • confrontos decisivos;

  • perseguições;

  • estratégias militares;

  • momentos emocionantes;

  • despedidas.

A ação é constante do início ao fim.


Mensagens ocultas

O verdadeiro herói escolhe servir

Saito nunca buscou poder.

Mesmo assim torna-se o maior defensor de Halkeginia.


Amar também é confiar

Louise aprende finalmente a confiar plenamente em Saito.

Sem orgulho.

Sem medo.


O fim também faz parte da jornada

Todo ciclo precisa terminar.

E isso não diminui sua importância.


O passado prepara o futuro

As escolhas feitas desde a primeira temporada encontram consequências nesta última fase.


Aspectos técnicos

Comparada às anteriores:

✔ melhor qualidade visual;

✔ efeitos mágicos superiores;

✔ trilha sonora emocionante;

✔ ritmo acelerado;

✔ batalhas mais grandiosas;

✔ conclusão satisfatória para os protagonistas.


Impacto cultural

Zero no Tsukaima F encerrou uma das franquias mais importantes da primeira geração dos isekais modernos.

Mesmo antes do enorme boom do gênero na década de 2010, a série já havia estabelecido diversos elementos que seriam reutilizados em inúmeras obras posteriores:

  • protagonista transportado para outro mundo;

  • academia de magia;

  • romance entre invocador e familiar;

  • sistema de poderes especiais;

  • mistura de humor e fantasia.

Embora a adaptação em anime tenha sido concluída antes da finalização da light novel, ela permaneceu como uma referência para fãs do gênero e ajudou a consolidar a reputação da franquia.


Censura

A quarta temporada mantém o padrão das anteriores:

  • fan service moderado;

  • humor sugestivo;

  • violência fantasiosa;

  • combates sem gore;

  • pequenas adaptações para a exibição televisiva.

As versões em Blu-ray preservam integralmente o conteúdo produzido.


Mangás

As adaptações em mangá continuam oferecendo versões alternativas e histórias paralelas, aprofundando personagens que receberam menos tempo de tela no anime.

Existem ainda antologias oficiais e spin-offs focados em diferentes heroínas.


Light Novel

Quando Zero no Tsukaima F foi produzido, a light novel original ainda não havia sido concluída devido à doença de Noboru Yamaguchi. Por isso, o anime encerra a história com um final próprio, inspirado no material disponível e em parte dos planos do autor.

Após o falecimento de Yamaguchi em 2013, o escritor Yu Shimizu concluiu oficialmente os volumes 21 e 22 com base nas anotações deixadas pelo criador, oferecendo aos leitores um encerramento mais próximo da visão original.


Games

A franquia recebeu diversos jogos para:

  • PlayStation 2

  • Nintendo DS

Esses títulos exploram rotas alternativas, histórias inéditas e finais diferentes para vários personagens, expandindo o universo além do anime.


Curiosidades

  • O "F" do título costuma ser interpretado pelos fãs como "Final", embora oficialmente também represente a identidade da última fase da franquia.

  • A abertura "I'll Be There For You", interpretada por ICHIKO, tornou-se um símbolo da despedida da série.

  • O encerramento "Kiss Shite Agenai", cantado por Rie Kugimiya (Louise), reforça o tom romântico da temporada.


Vale a pena assistir?

Sim. Zero no Tsukaima F é uma conclusão emocionante para um dos isekais mais influentes dos anos 2000. Mesmo condensando parte do material da light novel, entrega batalhas épicas, respostas para os principais mistérios e um encerramento digno para Louise e Saito.

Para quem acompanhou a jornada desde a primeira temporada, é o momento em que todas as linhas de código finalmente convergem para um único resultado.


☕ Easter Egg Bellacosa Mainframe

Depois de anos de desenvolvimento, chega o último processamento:

//FINALJOB EXEC PGM=HALKEGINIA
//STEPLIB DD DISP=SHR,DSN=ZERO.TSUKAIMA.FINAL
//SYSIN DD *
COMMIT LOVE
COMMIT DESTINY
COMMIT VOID
COMMIT GANDALFR
ARCHIVE HISTORY
END SYSTEM
/*

Resultado da execução:

JOB FINALIZADO

RETURN CODE = 0000

ABENDS = 0
PERDAS = MÍNIMAS
ROMANCE = CONCLUÍDO
HERÓI = APROVADO
HALKEGINIA = ESTÁVEL

SYSTEM SHUTDOWN COMPLETED

O operador do Bellacosa Mainframe fecha a sessão do ISPF, observa a última linha do log e comenta:

"Os melhores sistemas não são aqueles que nunca mudam. São aqueles que conseguem terminar sua execução deixando um legado para a próxima geração de desenvolvedores. Zero no Tsukaima fez exatamente isso: compilou ideias que seriam reutilizadas por quase todos os grandes isekais que vieram depois."

sexta-feira, 3 de fevereiro de 2012

Os 3 Onis Peraltas e o Leite Ninho Proibido

 


Os 3 Onis Peraltas e o Leite Ninho Proibido

(por Bellacosa Oni, sobrevivente do chinelo voador e degustador profissional de leite em pó)

Existem memórias que não moram num endereço fixo.
Elas estão espalhadas por todos os lugares onde crescemos — nas casas que alugamos, nas salas onde brincamos, nos quintais onde aprontamos, nos corredores onde corríamos para escapar do chinelo justiceiro.

E uma dessas memórias é tão insistente, tão viva, tão doce quanto o próprio protagonista dessa história:
o Leite Ninho dos anos 1970/1980.

Sim, Jefe… hoje eu vou te contar sobre as aventuras clandestinas dos 3 Onis peraltas e seu vício proibido.




🍼 Quando o leite estragava… e a tentação começava

Naquela época, antes da revolução do Tetra Pak, leite de padaria virava queijo em 48 horas.
Minha mãe, sempre prática e visionária (como toda boa sysadmin da vida doméstica), tinha a solução:

Leite em pó. Mas não qualquer leite. O Leite Ninho.

Era ouro branco.
Era tesouro de faraó.
Era o upgrade supremo da época.

E, para tristeza da autoridade parental, era também…
um convite à contravenção infanto-oni.

Porque, Jefe:
Uma lata de Leite Ninho aberta era como uma DSN sem password.




🍯 O subuso secreto: a massinha dos deuses

O manual oficial dizia:

“Adicionar duas colheres e misturar com água.”

Mas os Onis sabiam a verdade oculta:
O jeito mais gostoso era não adicionar nada.

Só a colher.
Direto na boca.
Deixar dissolver devagar, como se a vida fosse feita de pequenas felicidades granuladas.

E quando a criatividade batia?

Aí entrava a alquimia proibida:

  • Leite Ninho

  • Açúcar

  • Chocolate do Padre (sim, aquele da lata preta, o chefão final das sobremesas de infância)

Misturávamos tudo até virar uma massinha doce e pegajosa, digna de festa de aniversário clandestina.

Era ilegal?
Era imoral?
Era calórico?
Sim.
Sim.
ABSURDAMENTE.
Mas também era… perfeito.




🔊 O maior inimigo: o barulho do “PLOC”

Porque, Jefe, a lata do Leite Ninho tinha personalidade.
Ela era uma espécie de NPC vigilante da casa.

Abrir a tampa produzia um som que ecoava por dimensões paralelas:

PLOC!
E lá ia o vácuo estourando como sirene.

Podia ser 3 da tarde ou 3 da manhã.
Uma coisa era certa:

Se a lata fez “ploc”, algum adulto ouviu.

E aí começava o protocolo ninja-oni:

  1. Uma colherada rápida.

  2. Uma corrida em velocidade warp.

  3. Esconderijo estratégico atrás da mesa.

  4. Limpar o bigode branco para não deixar evidências.

  5. Rezar para o chinelo não ser invocado no modo boomerang.




👡 O terror absoluto: o grito que precedia o chinelo

Existem palavras que marcam o DNA da infância.
No meu caso, era uma só:

“VAGNER-R-R-R-R!”

Era como se a casa inteira tremesse.
As cortinas balançavam.
As galinhas do vizinho silenciavam.

E eu sabia que o barulho do “PLOC” tinha sido rastreado, logado e auditado.

Sim, o chinelo vinha.
Sim, ardia.
Sim, fazia parte da vida.
Sim, eu repetia tudo de novo na semana seguinte.

Porque, convenhamos…
Aquela colherada de Leite Ninho dissolvendo na boca valeu cada byte de castigo.




🥣 O dulcíssimo pós-crédito

Hoje, adulto, analista, professor, Bellacosa Mainframe, viajante do tempo e sobrevivente do tigrão havaiana…
ainda compro Leite Ninho.

E cada colherada — sem água, sem receita, sem nada —
me devolve por alguns segundos aos tempos dos três Onis:

  • correndo pela casa

  • inventando culinária proibida

  • vivendo perigosamente

  • sentindo o mundo girar ao som de um simples ploc

Alguns sabores não pertencem ao paladar.
Pertencem à alma.

E o Leite Ninho…
ah, Jefe…
esse é puro firmware da infância.

quarta-feira, 1 de fevereiro de 2012

 


Otsuten: O Santuário Onde o Profano Beija o Sagrado

Um mergulho Bellacosa Mainframe para o blog El Jefe Midnight Lunch

Quando o Japão resolve criar um santuário, ele não constrói apenas um templo — ele ergue um lore, um universo expandido, um portal cultural onde história, mitologia, urbanismo e um toque de maluquice coexistem em harmonia.
E entre os muitos templos que fazem o Japão ser esse RPG de mundo aberto chamado Japão, existe um que virou febre entre jovens, otakus, turistas espirituais e influenciadores: Otsuten — às vezes chamado de Otsu Tenmangu, outras vezes apelidado de “o santuário que realiza desejos… mas só se você não for afobado”.

Hoje, no estilo Bellacosa Mainframe para o El Jefe Midnight Lunch, vamos destrinchar esse fenômeno espiritual-pop-cultural com história, curiosidades, folclore, easter-eggs e aquele toque investigativo que faria até o CICS levantar uma sobrancelha.



1. Origem: Onde Começa o Código-Fonte do Otsuten

O Otsuten é um santuário xintoísta dedicado, como muitos da mesma linhagem, a Sugawara no Michizane, patrono da sabedoria, caligrafia, estudos e… vingança educada (sim, ele virou um kami depois de morrer injustiçado e causar tempestades até receber seu devido reconhecimento).

Otsuten, porém, ganhou fama mais recente graças a três fatores:

  1. Proximidade com rotas de estudantes indo para exames importantes;

  2. História oral sobre pedidos que “só funcionam se feitos com calma e sinceridade” (quase um timeout ajustado no JCL espiritual);

  3. Internet, que fez nascer o “Otsuten Challenge”.

E aqui começa o mix de tradição + viralização que só o Japão sabe produzir.



2. Estrutura e Simbologia: O Santuário Que Parece um Save Point

O Otsuten é famoso por seu torii vermelho vibrante, um portão tão icônico que virou ponto de selfie obrigatório.
Abaixo, a tríade sagrada do Otsuten:

  • Torii Vermelho: segundo o folclore local, quanto mais forte a cor, mais forte o pedido entra no “mainframe divino”.

  • A Pedra de Acalmar o Coração: uma rocha polida onde estudantes tocam para “resetar o nervosismo”.

  • O Caminho do Silêncio: um corredor estreito entre árvores antigas onde ninguém deve falar — se falar, perde o buff.

Easter-egg: dizem que, à noite, o caminho do silêncio produz eco mesmo quando ninguém pisa ali.
Debug espiritual? Talvez.



3. Cultura Pop: Otsuten Como Cenário de Anime, Dorama e Mangá

O local ficou famoso por aparições discretas em produções:

  • Uma versão estilizada aparece em Kyou no Go no Ni.

  • O torii foi recriado (quase idêntico) em um episódio de Bungou Stray Dogs, referência ao próprio Michizane.

  • Muitas VN, especialmente as de romance colegial, usam o modelo do torii como cenário de “confissões”.

Easter-egg cultural: vários gacha games japoneses adicionaram amuleto de Otsuten como item de buff para “sorte em summons”.


4. A Experiência: Como Funciona a “Interface Sagrada”

Visitar o Otsuten segue o protocolo tradicional:

  1. Passar pelo torii com respeito;

  2. Fazer purificação na fonte;

  3. Soar o sino;

  4. Fazer o pedido em silêncio;

  5. Amarrar um ema com o desejo escrito.

Mas o Otsuten tem um twist:

O pedido deve ser reescrito três vezes — como se fosse SUBMIT, HOLD e RELEASE.
Sim. É sério.
Dizem que isso “estabiliza” o desejo para que o kami entenda sua intenção.


5. Curiosidades no Estilo Bellacosa Mainframe

  • A cor do torii já foi laranja, mas foi repintado após uma pesquisa viral dizer que o “vermelho forte aumenta 12% a chance do pedido funcionar”. Zero base científica, mas muito marketing espiritual.

  • O Otsuten já recebeu mais de 100 mil pedidos digitalizados por turistas que escanearam seus emas (porque claro que alguém criou um OCR de desejos).

  • Existe um ritual moderno chamado “ping-bell”: bater o sino duas vezes e mandar mensagem para um amigo desejando boa sorte.

  • Amuletos especiais para programadores são vendidos lá, com o kanji de “erro” cortado ao meio — para simbolizar debug divino.


6. Problemas, Polêmicas e Lendas Urbanas

Nenhum lugar místico moderno escapa do lado B:

❖ Polêmica da fila de selfies

Turistas transformaram o torii em estúdio fotográfico, criando discussões entre visitantes sérios e influencers.

❖ Amuletos pirateados

Sim, existe mercado paralelo de omamori falsificados, vendidos em Shibuya e Akihabara.

❖ Lenda do “pedido rejeitado”

Dizem que, se você mentir no pedido ou fizer sem convicção, uma brisa gelada passa por trás do seu pescoço — “o kami te deslogou”.


7. O Easter-Egg Supremo: A Runa Oculta na Base do Torii

Essa é para os arqueólogos de cultura pop:

Na base direita do torii existe um pequeno símbolo, quase invisível, que alguns estudiosos identificam como um antigo caractere grego estilizado.
Teorias:

  • Homenagem a um arquiteto estudante de filologia;

  • Um charme para proteção contra espíritos ocidentais;

  • Apenas decoração.

A comunidade geek jura que é uma referência secreta a RPGs de mesa dos anos 80.


8. Conclusão: Otsuten Como “Mainframe Espiritual do Japão”

O Otsuten não é apenas um santuário.
É um hub cultural, um servidor de desejos, um checkpoint emocional para estudantes, românticos, sonhadores e curiosos.

Ele mistura:

  • tradição xintoísta,

  • cultura pop,

  • estética instagramável,

  • lendas urbanas,

  • e aquele je ne sais quoi japonês que transforma um templo em fenômeno global.

Se você for visitar, lembre-se:

No Otsuten, tudo funciona melhor quando você faz com calma.
Sem pressa, sem barulho, sem gambiarras.

Como um bom submit no mainframe.


quinta-feira, 12 de janeiro de 2012

IBM System/360: Licença para Compatibilidade : Quando um Programador COBOL Descobre que o Verdadeiro Agente Secreto da Computação Não Era James Bond...

 

Bellacosa Mainframe e o legado do ibm system 360

☕ Um Café no Bellacosa Mainframe

IBM System/360: Licença para Compatibilidade

Quando um Programador COBOL Descobre que o Verdadeiro Agente Secreto da Computação Não Era James Bond... Era um Computador Lançado em 1964

"Meu nome é System. IBM System/360."


Missão Recebida

Londres.

Quartel-General do MI6.

Ano de 1964.

James Bond entra na sala de reuniões imaginando que enfrentará mais um vilão tentando dominar o mundo.

"M" coloca sobre a mesa uma pasta marcada como:

TOP SECRET – PROJECT 360

Bond pergunta:

— Quem é o inimigo?

M responde calmamente:

— Desta vez não existe inimigo, 007...

Existe uma invenção.

Uma máquina tão revolucionária que mudará para sempre a maneira como o planeta trabalha, faz ciência, movimenta dinheiro, envia foguetes ao espaço e processa bilhões de transações diariamente.

Seu codinome...

IBM System/360.

Bond sorri.

— Parece apenas um computador.

Q interrompe.

— Não, 007...

É muito mais perigoso que isso.


Introdução

Todo programador COBOL aprende cedo algumas palavras mágicas.

MOVE.

READ.

WRITE.

PERFORM.

OPEN.

CLOSE.

Mas poucos sabem que essas palavras só continuam existindo, praticamente inalteradas há mais de sessenta anos, porque um grupo de engenheiros da IBM tomou uma das decisões mais ousadas da história da tecnologia.

A maioria acredita que a computação moderna nasceu com:

  • Windows

  • Linux

  • Internet

  • Google

  • AWS

  • Smartphones

Na realidade...

Todos esses são apenas capítulos posteriores de uma história iniciada oficialmente em 7 de abril de 1964.

Naquele dia nasceu o IBM System/360.

E como em todo bom filme de James Bond, o verdadeiro plano do vilão não aparece nos primeiros minutos.

Da mesma forma, o verdadeiro legado do System/360 demoraria décadas para ser compreendido.


A Operação Antes de 1964

Imagine o cenário.

Você trabalha em um banco.

Sua empresa compra um computador.

Tudo funciona perfeitamente.

Cinco anos depois chega um equipamento mais moderno.

Excelente notícia?

Nem tanto.

Naquela época significava praticamente começar do zero.

Os programas precisavam ser reescritos.

Os operadores reaprendiam comandos.

Os compiladores mudavam.

Os sistemas operacionais desapareciam.

Era como trocar um Aston Martin por um submarino e descobrir que nenhuma peça servia.

Cada computador era um universo isolado.

Cada fabricante criava suas próprias regras.

Era um verdadeiro caos tecnológico.


O Plano do Vilão

Todo filme de James Bond possui um plano secreto.

Na computação dos anos 60, o "vilão" era justamente a incompatibilidade.

Ela consumia dinheiro.

Tempo.

Equipes inteiras.

Imagine construir um prédio inteiro.

Depois demolir tudo apenas porque o elevador mudou de fabricante.

Era exatamente isso que acontecia com os computadores.


Entra em Cena o Agente 360

A IBM aparece discretamente.

Sem explosões.

Sem lasers orbitais.

Sem carros invisíveis.

Mas com uma ideia muito mais poderosa.

Compatibilidade.

Pela primeira vez na história, uma família inteira de computadores compartilhava a mesma arquitetura.

O software deixava de pertencer ao hardware.

Parece simples.

Na época foi revolucionário.


O Nome 360 Não Foi Escolhido por Acaso

Muitos imaginam que seja apenas um número.

Na verdade representa um círculo completo.

360 graus.

A mensagem era clara.

Este computador serviria para:

  • ciência

  • engenharia

  • universidades

  • bancos

  • seguros

  • governo

  • indústria

  • defesa

  • comércio

Era uma máquina para tudo.

Até hoje essa filosofia permanece viva.


O Primeiro Gadget de Q

Nos filmes de Bond sempre existe um equipamento aparentemente comum.

Depois descobrimos que ele faz algo extraordinário.

O System/360 era exatamente isso.

Por fora:

Um computador.

Por dentro:

Uma plataforma completa.


O Manual Secreto

Uma das maiores armas do System/360 não era seu hardware.

Era sua documentação.

Hoje isso parece banal.

Na época era quase inacreditável.

A IBM documentou cuidadosamente:

  • arquitetura

  • registradores

  • instruções

  • formatos de dados

  • entrada e saída

  • interrupções

  • convenções

Isso permitiu que outras empresas desenvolvessem:

  • compiladores

  • linguagens

  • sistemas operacionais

  • ferramentas

  • utilitários

Nascia um ecossistema.


O Primeiro Easter Egg

Existe uma curiosidade fantástica.

O projeto custou aproximadamente US$ 5 bilhões na época.

Corrigindo pela inflação atual...

Estamos falando de dezenas de bilhões de dólares.

Foi um dos maiores investimentos industriais do século XX.

A IBM literalmente apostou sua sobrevivência.

Se desse errado...

Talvez hoje nem existisse IBM.

Nem COBOL.

Nem IBM Z.

Nem boa parte da indústria corporativa.


O Grande Segredo: ISA

Todo computador possui uma identidade.

Ela recebe o nome de:

Instruction Set Architecture.

Ou simplesmente ISA.

Imagine um idioma.

O processador entende palavras como:

ADD

SUB

LOAD

STORE

COMPARE

BRANCH

O System/360 definiu esse idioma.

E fez uma promessa praticamente impossível.

"Mesmo que construamos computadores muito mais rápidos no futuro...

Eles continuarão entendendo esta mesma linguagem."

Sessenta anos depois...

Ainda cumprem essa promessa.


Licença para Escalar

Antes do System/360, crescer significava recomeçar.

Depois dele...

Bastava trocar de modelo.

Imagine começar com um computador pequeno.

Sua empresa cresce.

Você compra outro maior.

Os programas continuam funcionando.

Hoje chamamos isso de:

Escalabilidade.

Na época...

Era magia.


Missão Decimal

Aqui está uma das maiores genialidades da arquitetura.

Ela atendia simultaneamente dois mundos.

O Mundo Científico

Precisava calcular:

  • órbitas

  • foguetes

  • satélites

  • engenharia

  • física nuclear

Utilizava ponto flutuante.


O Mundo Financeiro

Precisava calcular:

  • juros

  • salários

  • impostos

  • seguros

  • aplicações

Utilizava aritmética decimal.

Isso evitava erros de arredondamento.

Por isso bancos continuam utilizando Packed Decimal até hoje.


Dica Bellacosa nº 1

Todo iniciante em COBOL deveria estudar:

  • DISPLAY

  • COMP

  • COMP-3

Antes mesmo de aprender CICS.

Antes mesmo de aprender Db2.

Entender representação de dados explica metade dos "mistérios" da linguagem.


O Verdadeiro Aston Martin

James Bond possuía um Aston Martin cheio de equipamentos.

O System/360 também.

Só que seus gadgets eram invisíveis.

Entre eles:

✔ canais de entrada e saída

✔ arquitetura modular

✔ compatibilidade

✔ interrupções

✔ múltiplos dispositivos

✔ independência entre CPU e periféricos

Era tecnologia extremamente avançada para 1964.


Os Agentes Secretos Chamados Canais

Um dos componentes mais brilhantes eram os Channel Processors.

Enquanto a CPU trabalhava...

Os canais conversavam com:

  • discos

  • fitas

  • impressoras

  • leitores de cartão

Sozinhos.

Hoje chamaríamos isso de:

Processamento paralelo.

DMA.

Offloading.

Hardware Acceleration.

Em 1964.


Curiosidade de Espião

Muitos engenheiros modernos acreditam que aceleração de hardware nasceu recentemente.

Na realidade...

Os canais do System/360 já faziam isso há mais de meio século.


O Cofre Suíço da Compatibilidade

Imagine guardar dinheiro em um banco.

Sessenta anos depois...

Ele continua aceitando exatamente a mesma chave.

Parece impossível.

Mas isso acontece diariamente.

Programas COBOL escritos nos anos 70 ainda executam em IBM Z modernos.

Alguns sofreram manutenção.

Outros permanecem incrivelmente próximos da versão original.

Pouquíssimas plataformas oferecem essa continuidade.


Dica Bellacosa nº 2

Nunca pense:

"COBOL é antigo."

Pense:

"COBOL possui estabilidade arquitetural."

São conceitos completamente diferentes.


A Organização SPECTRE

Nos filmes de Bond existe a SPECTRE.

Na informática havia outra ameaça.

A fragmentação.

Cada fabricante queria criar seu próprio universo.

IBM fez exatamente o contrário.

Criou uma arquitetura comum.

Isso permitiu o nascimento de um mercado inteiro.


O Nascimento dos Parceiros

Sem uma arquitetura estável dificilmente existiriam:

  • softwares comerciais

  • bancos de dados

  • ERPs

  • compiladores independentes

  • ferramentas CASE

  • produtos de terceiros

Foi o início do conceito moderno de ecossistema.


Easter Egg nº 2

O autor do texto original comenta que levou vinte e nove anos para compreender a importância do System/360 em sua própria vida.

Isso acontece com quase todo profissional de TI.

Quando começamos a estudar COBOL, JCL ou CICS, enxergamos apenas ferramentas.

Décadas depois percebemos que estamos trabalhando dentro de uma filosofia criada muito antes de nascermos.


Da Plataforma ao Universo

O System/360 não criou apenas computadores.

Criou um conceito.

Plataforma.

Hoje usamos essa palavra o tempo todo.

Windows é plataforma.

Linux é plataforma.

Android é plataforma.

AWS é plataforma.

IBM Z é plataforma.

Tudo isso possui raízes na arquitetura concebida em 1964.


CSI Bellacosa — Investigando as Pistas

Vamos analisar algumas tecnologias atuais.

Cloud

Escalar sem reescrever.

Origem?

System/360.


x86

Compatibilidade entre gerações.

Origem conceitual?

System/360.


Linux

Arquitetura estável.

Mesmo software durante décadas.

Influência?

System/360.


Containers

Separação entre aplicação e infraestrutura.

Ideia amadurecida posteriormente graças à evolução da virtualização dos mainframes.


Kubernetes

Mover aplicações sem alterar código.

Filosofia semelhante.


AWS EC2

Trocar hardware sem afetar aplicações.

Mesmo conceito.


Azure

Escalabilidade transparente.

Mesmo princípio.


IBM Cloud

Continuação natural dessa evolução.


Dica Bellacosa nº 3

Sempre que surgir uma tecnologia nova pergunte:

"Qual problema ela resolveu?"

Depois pergunte novamente:

"Será que o Mainframe já resolvia isso de outra forma?"

Você ficará surpreso.


O Próximo Filme

Todo filme de James Bond termina deixando um gancho.

O texto original faz exatamente isso.

O autor anuncia o próximo capítulo.

O protagonista deixa de investigar compatibilidade.

Agora investigará outra invenção.

Virtualização.

O famoso conceito:

"Um computador dentro de outro computador."

Sem ele provavelmente nunca existiriam:

  • VMware

  • Hyper-V

  • Docker (indiretamente)

  • Kubernetes (indiretamente)

  • AWS

  • Azure

  • Google Cloud

Tudo começa com outra revolução silenciosa.

O IBM System/370.


Curiosidades que Pouca Gente Conhece

🍸 Curiosidade 1 — O brinde que mudou o mundo

Enquanto muitos celebravam o lançamento de um novo computador em abril de 1964, poucos perceberam que estavam testemunhando o nascimento da arquitetura que sustentaria bancos, bolsas de valores, companhias aéreas e governos por décadas.

🕵️ Curiosidade 2 — A aposta mais cara da IBM

O desenvolvimento do System/360 envolveu milhares de engenheiros, diversas fábricas e uma reorganização completa da empresa. Foi uma decisão empresarial comparável a colocar todas as fichas em uma única missão.

💾 Curiosidade 3 — Compatibilidade como patrimônio

Empresas que investiram em software para System/360 puderam evoluir para System/370, S/390 e IBM Z preservando boa parte do conhecimento e dos investimentos realizados.

🎯 Curiosidade 4 — O COBOL encontrou seu lar

Embora o COBOL tenha sido criado antes do System/360, foi nessa plataforma que a linguagem encontrou o ambiente ideal para crescer e se tornar sinônimo de processamento corporativo.


Missão Cumprida

No universo de James Bond, o herói salva o mundo impedindo uma explosão nuclear, derrotando uma organização criminosa ou desativando um satélite orbital.

Na história da computação, o herói foi muito mais silencioso.

Não usava smoking.

Não dirigia um Aston Martin.

Não carregava uma Walther PPK.

Seu nome era IBM System/360.

Sua missão não era destruir vilões.

Era eliminar a maior ameaça da informática dos anos 1960: a incompatibilidade.

Ao introduzir uma arquitetura comum, um conjunto de instruções estável, proteção ao investimento, escalabilidade e a separação entre hardware e software, ele estabeleceu os alicerces da computação empresarial moderna. O que hoje parece natural — trocar servidores, atualizar sistemas, ampliar capacidade sem reescrever aplicações — começou com essa filosofia lançada em 7 de abril de 1964.

Para o programador COBOL iniciante, compreender o System/360 é como James Bond descobrir, no fim da missão, quem era o verdadeiro mentor por trás de todos os acontecimentos. De repente, tudo faz sentido: o COBOL, o z/OS, o JCL, o CICS, o Db2, o IBM Z e até conceitos modernos como virtualização, computação em nuvem e arquiteturas compatíveis deixam de ser peças isoladas e passam a formar uma única narrativa.

E existe um último easter egg digno de um filme de espionagem: talvez o maior segredo do System/360 nunca tenha sido sua velocidade, sua memória ou seu hardware.

Seu verdadeiro "dispositivo secreto" foi uma ideia.

A ideia de que o software deveria sobreviver ao hardware.

Sessenta anos depois, essa missão continua ativa.

E, como toda boa operação do MI6, ela permanece funcionando silenciosamente nos bastidores, protegendo bilhões de transações todos os dias.

Missão cumprida, Agente COBOL. A próxima pasta confidencial já está sobre a mesa: IBM System/370 — o computador que aprendeu a ser muitos computadores ao mesmo tempo.

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