Translate

sexta-feira, 18 de abril de 2014

No Game No Life : Quando um Sysprog Descobre que o Universo Inteiro é um Grande Sistema Operacional Baseado em Jogos

 

Bellacosa Mainframe apresenta o anime nO gAMe no Life

☕ Um Café no Bellacosa Mainframe

No Game No Life (ノーゲーム・ノーライフ)

Quando um Sysprog Descobre que o Universo Inteiro é um Grande Sistema Operacional Baseado em Jogos

"Existe uma velha máxima no mundo dos mainframes: quem conhece as regras do sistema controla o ambiente. Em Disboard, Sora e Shiro descobrem que essa filosofia não é apenas uma boa prática — é a própria lei do universo."


Introdução

Em 2014, enquanto o gênero isekai começava a se tornar um dos pilares da indústria dos animes, surgiu uma obra que decidiu seguir um caminho completamente diferente. Em vez de apostar na força física, em espadas lendárias ou em protagonistas que acumulavam níveis infinitos, No Game No Life apresentou um conceito ousado: um mundo onde guerras, disputas políticas, economia e até o destino das nações são decididos exclusivamente através de jogos.

Produzido pelo renomado estúdio Madhouse, conhecido por clássicos como Death Note, Hunter x Hunter (2011), One Punch Man (1ª temporada) e Overlord, o anime tornou-se rapidamente um fenômeno mundial. Com apenas doze episódios, conquistou milhões de fãs graças ao seu visual vibrante, personagens memoráveis, jogos inteligentes e uma narrativa repleta de metáforas sobre lógica, cooperação e estratégia.

No estilo Bellacosa Mainframe, podemos imaginar Disboard como um gigantesco ambiente IBM Z. Cada raça funciona como uma LPAR, as Dez Promessas representam o kernel do sistema operacional e Tet é o administrador supremo que garante que todas as transações sejam processadas sem conflitos físicos. Em vez de utilizar força bruta, os protagonistas aprendem a explorar as regras do sistema, exatamente como um excelente programador COBOL faz ao dominar JCL, CICS, Db2 e z/OS.


Ficha Técnica

ItemInformação
Título Originalノーゲーム・ノーライフ (Nō Gēmu Nō Raifu)
Título InternacionalNo Game No Life
AutorYuu Kamiya (Thiago Furukawa Lucas)
Light Novel25 de abril de 2012
Anime9 de abril de 2014
EstúdioMadhouse
DireçãoAtsuko Ishizuka
RoteiroJukki Hanada
MúsicaSuper Sweep
Design de PersonagensKoji Odate
Episódios12
FilmeNo Game No Life Zero (2017)
OrigemLight Novel
Classificação Indicativa+16 anos
GênerosIsekai, Fantasia, Estratégia, Comédia, Ecchi, Jogos Psicológicos, Aventura

O Estúdio Madhouse

Fundado em 1972 por ex-integrantes da Mushi Production, o Madhouse é um dos estúdios mais respeitados da animação japonesa. Conhecido por sua excelência técnica e por assumir projetos visualmente ambiciosos, o estúdio elevou No Game No Life a outro patamar.

A paleta de cores extremamente saturada, os cenários quase surreais e as transições dinâmicas criam uma identidade visual única. Disboard parece um mundo renderizado por uma GPU de última geração, onde cada cenário lembra um mapa de RPG digital.

No estilo Bellacosa Mainframe, é como observar um painel do z/OSMF com todos os indicadores funcionando perfeitamente: bonito, organizado e impressionante.


Sinopse

Sora e Shiro são dois irmãos reclusos (hikikomori), considerados verdadeiras lendas no mundo dos jogos online. Utilizando o nickname Blank (空白), eles jamais perderam uma partida.

Após derrotarem um misterioso adversário em um jogo de xadrez virtual, recebem um convite para um universo chamado Disboard, governado por Tet, o Deus dos Jogos.

Nesse mundo não existem guerras.

Não existem assassinatos.

Não existem golpes de estado.

Tudo é decidido através de jogos.

Desde uma simples aposta até o controle de um reino inteiro.


Resumo da História

Ao chegarem em Disboard, os irmãos descobrem que a humanidade, conhecida como Imanity, ocupa a última posição entre as dezesseis raças inteligentes do mundo.

Sem magia.

Sem força física.

Sem tecnologia superior.

Sua única esperança é utilizar aquilo que sempre dominou suas vidas: estratégia, lógica, criatividade e trabalho em equipe.

A partir desse momento, Sora e Shiro iniciam uma jornada para reunir aliados, conquistar territórios e desafiar as demais raças, com o objetivo final de enfrentar Tet e conquistar o direito de governar Disboard.


A História de Disboard

Milhares de anos antes da chegada dos protagonistas, o mundo foi devastado por uma guerra entre deuses e raças poderosas.

Após o conflito, Tet tornou-se o Único Deus Verdadeiro e decidiu impedir que a violência voltasse a destruir o planeta.

Para isso criou as famosas Dez Promessas, leis absolutas que regem toda a existência.


As Dez Promessas

As Dez Promessas são a base de toda a sociedade de Disboard.

Entre seus princípios estão:

  • Toda disputa será resolvida por jogos.

  • O resultado de um jogo é absoluto.

  • Ninguém pode recorrer à violência.

  • As apostas devem ser respeitadas.

  • Todos podem desafiar qualquer pessoa, desde que as regras sejam aceitas.

Essas regras funcionam como o kernel do sistema operacional de Disboard.

Nada pode ser executado fora delas.



Principais Personagens

Sora

O estrategista.

Carismático, manipulador e especialista em comportamento humano.

Sua maior arma não é a inteligência matemática.

É compreender como as pessoas pensam.

Ele lembra um arquiteto de sistemas que conhece cada detalhe da infraestrutura corporativa.


Shiro

A contraparte perfeita de Sora.

Possui memória fotográfica, capacidade absurda de cálculo e reconhecimento instantâneo de padrões.

Se Sora representa a criatividade humana, Shiro representa a precisão de um supercomputador IBM Z.


Stephanie Dola

Neta do antigo rei de Elkia.

Inicialmente parece apenas uma personagem cômica, mas simboliza a humanidade comum tentando sobreviver em um ambiente dominado por gênios.

Sua perseverança é uma das mensagens mais importantes da obra.


Tet

O Deus dos Jogos.

Criador das Dez Promessas.

Sua filosofia é simples:

A inteligência deve substituir a violência.


Jibril

Uma integrante da raça Flügel.

Poderosíssima, extremamente inteligente e apaixonada pelo conhecimento.

Ao longo da série torna-se uma importante aliada dos protagonistas.


Izuna Hatsuse

Representante da raça Werebeast.

Uma adversária brilhante, especialista em velocidade e jogos de reação.

Sua personalidade carismática transformou-a em uma das personagens mais populares da franquia.


Temática

Embora seja vendido como um anime de fantasia, No Game No Life discute temas muito mais profundos.

Entre eles:

  • teoria dos jogos;

  • psicologia comportamental;

  • liderança;

  • confiança absoluta;

  • trabalho em equipe;

  • criatividade;

  • lógica;

  • manipulação estratégica;

  • diplomacia;

  • uso inteligente da informação.


O Que Tem de Diferente?

Grande parte dos isekais segue uma estrutura tradicional:

  • protagonista recebe poderes;

  • derrota monstros;

  • aumenta de nível;

  • enfrenta um rei demônio.

No Game No Life rompe completamente esse modelo.

Os protagonistas não vencem porque são mais fortes.

Eles vencem porque compreendem melhor as regras do sistema.

No universo Bellacosa Mainframe, isso equivale a dizer que um bom analista resolve um problema entendendo a arquitetura do ambiente antes de alterar qualquer parâmetro.


As Grandes Aventuras

Cada arco apresenta desafios únicos.

Entre os mais marcantes estão:

A conquista de Elkia

Sora derrota adversários utilizando apenas lógica e manipulação psicológica.


O duelo contra Jibril

Uma batalha intelectual envolvendo conhecimento histórico e raciocínio estratégico.


O jogo de Shiritori

Talvez o episódio mais criativo do anime.

As palavras pronunciadas alteram literalmente a realidade.

Se alguém diz "fogo", fogo aparece.

Se alguém diz "ar", o ar pode desaparecer.

É uma demonstração brilhante de criatividade narrativa.


O confronto contra os Werebeasts

Mistura realidade virtual, leitura corporal e teoria das probabilidades.


A expansão do reino humano

Cada vitória representa não apenas uma conquista territorial, mas também um avanço político dentro da complexa estrutura de Disboard.


Bellacosa Mainframe

Imagine Disboard como um ambiente IBM Z.

Tet é o Hardware.

As Dez Promessas são o z/OS.

Cada raça representa uma LPAR.

Os jogos são APIs.

As apostas são transações.

Quem entende o funcionamento interno do sistema consegue otimizar recursos sem jamais quebrar as regras.

É exatamente assim que trabalham os melhores especialistas em mainframe.


Mensagens Ocultas

O verdadeiro poder é compreender o sistema

Força física pode vencer batalhas.

Conhecimento vence civilizações.


Cooperação supera genialidade individual

Separados, Sora e Shiro possuem limitações.

Juntos tornam-se praticamente invencíveis.


Toda regra possui brechas

Não existem sistemas perfeitos.

Existem sistemas profundamente compreendidos.


Informação é o recurso mais valioso

Conhecimento bem utilizado sempre supera poder bruto.


Jogos representam negociações humanas

Cada partida simboliza conflitos políticos, econômicos e sociais do mundo real.


Easter Eggs e Curiosidades

  • O nome Blank (空白) significa "espaço em branco", indicando que os irmãos podem assumir qualquer estratégia ou identidade.

  • O autor Yuu Kamiya nasceu no Brasil, na cidade de Brasília, e possui ascendência japonesa.

  • Muitas partidas fazem referência direta à Teoria dos Jogos, de John von Neumann e Oskar Morgenstern.

  • O design das dezesseis Exceed lembra um grande tabuleiro de xadrez, no qual cada raça desempenha um papel específico.

  • O visual altamente saturado reforça a sensação de que Disboard é um universo artificial, quase como um mundo digital.


Impacto Cultural

Mesmo com apenas uma temporada, No Game No Life tornou-se um dos maiores fenômenos dos isekais modernos.

Seu impacto inclui:

  • milhões de cópias vendidas das light novels;

  • enorme sucesso internacional;

  • influência em diversas obras posteriores focadas em estratégia;

  • milhares de cosplays de Sora, Shiro e Jibril;

  • memes duradouros na comunidade otaku;

  • uma base de fãs extremamente ativa, que continua pedindo uma segunda temporada.

A expressão "Where is Season 2?" tornou-se praticamente um meme oficial da franquia.


Censura e Polêmicas

A obra enfrentou algumas controvérsias ao longo dos anos.

Fanservice

Algumas cenas envolvendo personagens jovens receberam críticas pelo excesso de fanservice, resultando em versões editadas para determinados mercados.

Ilustrações

Em 2014, Yuu Kamiya reconheceu que algumas ilustrações das light novels apresentavam poses muito semelhantes às de outros artistas. O autor pediu desculpas publicamente e revisou parte do material em edições posteriores.

Adaptação Incompleta

O anime adapta apenas os três primeiros volumes da light novel, deixando muitos acontecimentos importantes sem animação.


Mangás, Light Novels e Games

Light Novel

A obra original continua expandindo o universo de Disboard, apresentando novas raças, desafios e revelações sobre Tet e as Dez Promessas.

Mangá

Existe uma adaptação em mangá e materiais derivados que complementam a história principal.

Filme

No Game No Life Zero (2017)

Baseado no sexto volume da light novel, mostra a Grande Guerra ocorrida milhares de anos antes da série principal. É considerado por muitos fãs uma obra-prima por aprofundar a origem de Disboard e apresentar uma narrativa mais dramática.

Games

A franquia recebeu jogos para dispositivos móveis e diversas colaborações com outros títulos japoneses, embora ainda não possua um grande RPG próprio para consoles.


Conclusão

No Game No Life permanece como um dos isekais mais inteligentes e visualmente marcantes já produzidos. Sua proposta de substituir batalhas físicas por confrontos estratégicos transformou a série em uma referência para obras que exploram lógica, psicologia e teoria dos jogos.

Sob a ótica do Bellacosa Mainframe, Disboard é um enorme ambiente de missão crítica. Tet atua como o administrador do sistema, as Dez Promessas são o kernel que garante estabilidade e as dezesseis raças representam diferentes subsistemas especializados. Sora e Shiro triunfam porque fazem aquilo que todo grande profissional de tecnologia aprende com a experiência: antes de tentar mudar o sistema, compreenda profundamente sua arquitetura.

"No Game No Life ensina que a maior habilidade não é vencer pela força, mas entender as regras tão profundamente que o próprio sistema passa a jogar a seu favor. Essa é a verdadeira filosofia de um mestre em estratégia — e também de um mestre do Mainframe."

quinta-feira, 17 de abril de 2014

☕🔥 ABEND S837 — O “CEMITÉRIO DOS DATASETS” NO z/OS

 

Bellacosa Mainframe e o abend s837

☕🔥 ABEND S837 — O “CEMITÉRIO DOS DATASETS” NO z/OS

Quando o Mainframe Diz:

“EU NÃO CONSIGO ALOCAR ESSE DATASET.”

Se existe um ABEND que faz o Junior Padawan perceber que:

espaço em disco no mainframe é um ritual sagrado…

é o lendário:

🚨 S837

E normalmente ele aparece assim:

IEF450I JOBNAME STEP01 - ABEND=S837

ou:

SPACE ALLOCATION FAILED

ou ainda:

NO SPACE LEFT ON VOLUME

E então começa o caos existencial:

“O dataset não nasceu?”
“O disco acabou?”
“O SMS ficou bravo?”
“Meu SORT criou um buraco negro?”
“Como um mainframe GIGANTE pode ficar sem espaço?!”

☕ Respira.

Porque o S837 é um dos ABENDs MAIS IMPORTANTES para entender:

SPACE allocation

DASD

extents

SMS

secondary allocation

SORT work datasets

volumes z/OS


🔥 O QUE É O S837?

O S837 é um:

🚨 SPACE ALLOCATION FAILURE

Traduzindo:

O z/OS NÃO CONSEGUIU ENCONTRAR ESPAÇO EM DISCO PARA O DATASET.


☕ A FILOSOFIA DO S837

No mainframe:

datasets ocupam espaço físico controlado rigorosamente.

Nada é “solto” como em PCs modernos.

Tudo precisa de:

  • cylinders

  • tracks

  • extents

  • volumes

  • allocation units


🔥 ANALOGIA BELLACOSA MAINFRAME

Imagine um estacionamento corporativo.

Seu caminhão chega precisando:

50 vagas contínuas.

Mas:

  • estacionamento lotado

  • vagas fragmentadas

  • limite atingido

Resultado:

❌ sem espaço.

Isso é o:

☠️ S837


🔥 O GRANDE SEGREDO

S837 NÃO significa necessariamente:

“acabou disco no datacenter.”

Frequentemente significa:

não existe espaço adequado para aquela alocação.


☕ O MOMENTO EXATO DO S837

Fluxo:

JCL solicita dataset
 ↓
z/OS tenta alocar espaço
 ↓
DASD/SMS procura área livre
 ↓
Falha
 ↓
S837

🔥 O MAIOR VILÃO DO S837

🚨 SPACE MAL DIMENSIONADO

O clássico absoluto.


☕ EXEMPLO JCL

//OUTFILE DD DSN=TESTE.ARQ,
// SPACE=(CYL,(5000,5000))

Mas o volume NÃO possui isso disponível.

Resultado:

💥 S837


🔥 O SORT DA MORTE

Lenda absoluta do z/OS.


☕ EXEMPLO

//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(9999,9999))

DFSORT tenta criar work datasets gigantescos.

O disco entra em sofrimento espiritual.

Resultado:

☠️ S837


🔥 O S837 E O “SECONDARY SPACE”

Agora nasce o conhecimento Jedi.


☕ PRIMARY SPACE

Espaço inicial.


☕ SECONDARY SPACE

Expansão dinâmica.


🔥 O PROBLEMA

Primary cabe.

Mas durante crescimento:

secondary allocation falha

Resultado:

💥 S837


☕ O S837 FANTASMA

O mais traiçoeiro.

Job roda:

30 minutos normal

E explode depois.

Porque dataset cresceu além do previsto.


🔥 O S837 E O “EXTENTS”

Modo arquimago ativado.


☕ O QUE É EXTENT?

Bloco contínuo de espaço em disco.

Datasets possuem limite de extents.


🔥 O DRAMA

Disco possui espaço.

Mas fragmentado demais.

Sistema não consegue criar novo extent adequado.

Resultado:

☠️ S837


☕ O S837 E O SMS

Hoje muitos ambientes usam:

SMS (Storage Management Subsystem)

Ele decide:

  • volume

  • classe

  • performance

  • gerenciamento

Políticas SMS inadequadas podem causar:

💥 S837


🔥 O S837 E O GDG

Outro clássico.

Gerações antigas:

  • não apagadas

  • acumuladas

  • espaço esgotado

Nova geração tenta nascer.

Resultado:

☠️ S837


☕ O S837 E O RLSE

Parâmetro mágico:

RLSE

Libera espaço não usado ao final do job.

Sem isso:

desperdício silencioso.


🔥 O S837 E O UNIT=SYSDA

Outro cenário clássico.

Todos jobs disputando:

mesmos volumes.

Ambiente congestionado.

Resultado:

💥 falha de alocação.


☕ O S837 E O DB2

Utilities DB2 podem gerar datasets temporários gigantes:

  • SORT

  • REORG

  • UNLOAD

  • LOAD

Space errado?

☠️ S837


🔥 O S837 E O CICS

Menos comum diretamente.

Mas logs/journals/datasets auxiliares também podem sofrer.


☕ O S837 E O “VOLUME FULL”

Às vezes o volume realmente está:

LOTADO.

Operador olha:

D U,VOL=XXXX

E percebe:

sem espaço restante.


🔥 COMO INVESTIGAR O S837 PASSO A PASSO


✅ PASSO 1 — VERIFIQUE JESMSGLG

Procure:

S837
SPACE ALLOCATION FAILED
B37
E37

✅ PASSO 2 — IDENTIFIQUE O DDNAME

Qual dataset falhou?

SORTWK01
OUTFILE
TEMP001

✅ PASSO 3 — ANALISE SPACE=

Veja:

SPACE=(CYL,(x,y))

ou:

SPACE=(TRK,(x,y))

✅ PASSO 4 — VERIFIQUE VOLUME

Talvez:

  • cheio

  • fragmentado

  • limitado


✅ PASSO 5 — VERIFIQUE EXTENTS

Datasets podem atingir:

limite máximo de extents.


🔥 O SEGREDO DOS B37/E37

Parentes sombrios do S837.


☕ B37

Sem espaço durante escrita.


☕ E37

Sem extents disponíveis.


☕ S837

Falha de alocação/expansão.


🔥 O DUMP DO S837

Normalmente pouco útil.

O ouro está em:

  • mensagens IEC

  • SMS reports

  • allocation messages

  • JESMSGLG


☕ MENSAGENS IMPORTANTES


☕ IEC030I

Problemas de espaço/extents.


☕ IEC070I

Falha de allocation.


☕ IGDxxxx

Mensagens SMS.


🔥 O MAIOR ERRO DO PADAWAN

Resolver tudo assim:

SPACE=(CYL,(9999,9999))

Agora o job pede:

MAIS ESPAÇO DO QUE O DATACENTER POSSUI.


☕ O VERDADEIRO JEDI

Não apenas aumenta espaço.

Ele pergunta:

“QUAL O CRESCIMENTO REAL DO DATASET?”


🔥 COMO EVITAR S837


✅ Dimensionar SPACE corretamente


✅ Revisar secondary allocation


✅ Usar RLSE


✅ Monitorar SORTs gigantes


✅ Limpar GDGs antigos


✅ Revisar SMS classes


✅ Evitar datasets monstruosos desnecessários


✅ Monitorar extents


☕ O SEGREDO DOS VETERANOS

Veteranos respeitam profundamente:

SPACE planning.

Porque no z/OS:

storage físico ainda importa MUITO.


🔥 CURIOSIDADE HISTÓRICA

Nos anos 60/70:

discos eram:

  • pequenos

  • caríssimos

  • lentos

Programadores literalmente calculavam:

trilhas e cilindros manualmente.

O S837 nasceu dessa realidade brutal.


☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S837 significa:

Seu Dataset Tentou Crescer Mais do Que o Universo Permitia.”


🔥 O MAIOR ENSINAMENTO DO S837

Ele ensina algo profundo:

no z/OS, armazenamento é engenharia matemática.

Não basta:

“salvar arquivo”

É preciso entender:

  • cylinders

  • tracks

  • extents

  • SMS

  • crescimento

  • fragmentação

  • alocação física


☕ A VERDADE FINAL

O S80A pune falta de memória.
O S878 pune fragmentação de storage virtual.
O S913 pune falta de autorização.

Mas…

☕ O S837 É O MOMENTO EM QUE O z/OS OLHA PARA O DISCO… E DESCOBRE QUE NÃO EXISTE MAIS ESPAÇO ADEQUADO PARA O SEU DATASET NASCER.


quarta-feira, 16 de abril de 2014

☕🏔️ “QUANDO O JAPÃO CRIOU O PRIMEIRO ‘DESCARTE LEGADO HUMANO’ DA HISTÓRIA” — UBASUTEYAMA, A LENDA SOMBRIA QUE TRANSFORMOU IDOSOS EM ‘SISTEMAS OBSOLETOS’ MUITO ANTES DO MAINFRAME EXISTIR 💀🇯🇵

 

Bellacosa Mainframe e os periodos de escassez e fome Ubasuteyama

☕🏔️ “QUANDO O JAPÃO CRIOU O PRIMEIRO ‘DESCARTE LEGADO HUMANO’ DA HISTÓRIA” — UBASUTEYAMA, A LENDA SOMBRIA QUE TRANSFORMOU IDOSOS EM ‘SISTEMAS OBSOLETOS’ MUITO ANTES DO MAINFRAME EXISTIR 💀🇯🇵

Existe uma verdade desconfortável que poucos gostam de admitir:

Toda civilização, em algum momento, precisou decidir o que fazer com aquilo que já não conseguia sustentar.

No mundo corporativo moderno, empresas aposentam aplicações.
Desligam servidores.
Arquivam sistemas legados.
Migran dados críticos.
Congelam ambientes antigos.

Mas no Japão feudal…
a lenda diz que fizeram isso com pessoas.

E é exatamente aí que nasce uma das histórias mais perturbadoras, filosóficas e simbólicas da cultura japonesa:

☠️ Ubasuteyama — A Montanha do Abandono

“Ubasute” (姥捨て) significa literalmente:

“abandonar uma velha mulher”.

Já “Yama” (山) significa montanha.

O termo completo se refere à lenda segundo a qual idosos eram levados para montanhas isoladas e deixados lá para morrer durante épocas de fome extrema, miséria ou colapso social.

Sim…
é tão brutal quanto parece.

Mas como toda grande lenda japonesa, a história vai muito além do horror superficial.

Ela fala sobre:

  • sobrevivência;

  • culpa coletiva;

  • peso social;

  • utilitarismo;

  • memória;

  • tradição;

  • legado;

  • e principalmente…
    o medo humano de se tornar “inútil”.

E honestamente?

Poucas histórias conversam tanto com o universo dos sistemas legados quanto essa.


🖥️ O Japão Feudal Já Sofria Com “CAPACIDADE LIMITADA”

Hoje falamos sobre:

  • limite de CPU;

  • storage;

  • licensing;

  • capacity planning;

  • gargalos operacionais;

  • tuning de workload.

Mas no Japão medieval o recurso crítico era outro:

comida.

A agricultura japonesa antiga era extremamente vulnerável:

  • invernos rigorosos;

  • solo montanhoso;

  • terremotos;

  • tufões;

  • secas;

  • guerras civis;

  • impostos feudais.

Uma única safra perdida podia destruir vilas inteiras.

Então surgia a lógica cruel:

“quem produz deve sobreviver”.

Idosos eram vistos por algumas narrativas folclóricas como “peso operacional”.

É quase como se certas comunidades tratassem seres humanos como:

  • processos inativos;

  • workloads sem retorno;

  • datasets frios;

  • recursos sem throughput.

Desumano?

Completamente.

Mas exatamente por isso a lenda sobrevive há séculos:
ela obriga o Japão a encarar o lado sombrio da própria história.


🏔️ A LENDA MAIS FAMOSA: A MÃE QUE QUEBRAVA GALHOS

A versão mais conhecida da história acontece em Shinshu, atual província de Nagano.

Um jovem recebe ordem de levar sua mãe idosa até a montanha para abandoná-la.

Durante o trajeto ele percebe algo estranho:
a mãe vai quebrando galhos de árvores pelo caminho.

Quando pergunta por quê…

ela responde:

“Estou marcando o caminho para que você consiga voltar para casa sem se perder.”

Mesmo sendo levada para morrer…
ela ainda estava preocupada com o filho.

Esse momento destrói emocionalmente o rapaz.

Então ele desafia a ordem da vila e leva a mãe de volta escondida para casa.

Mais tarde, um senhor feudal impõe desafios impossíveis à população.
A mãe idosa resolve todos usando sua sabedoria acumulada.

A vila então percebe algo fundamental:

experiência vale mais que força.


☕ O MESMO ERRO QUE MUITAS EMPRESAS COMETEM COM O MAINFRAME

Agora observe algo fascinante.

Durante décadas, muitas corporações cometeram exatamente o mesmo erro conceitual com profissionais mainframe:

  • “isso é velho”

  • “isso é caro”

  • “isso é ultrapassado”

  • “ninguém mais usa”

  • “vamos substituir tudo”

Então começaram:

  • aposentadorias em massa;

  • perda de conhecimento;

  • abandono de documentação;

  • migração sem estratégia;

  • desprezo pela engenharia histórica.

E anos depois descobriram uma realidade dolorosa:

o legado sustentava tudo.

Bancos.
Cartões.
Companhias aéreas.
Seguros.
Governos.
Bolsa de valores.
Folha de pagamento.
PIX.
ATM.
Processamento financeiro global.

Assim como na lenda de Ubasuteyama…

muitos só perceberam o valor dos antigos quando quase era tarde demais.


🧠 UBASUTE NÃO É HISTÓRIA CONFIRMADA — E ISSO TORNA TUDO MAIS INTERESSANTE

Aqui vem uma parte importante.

Historiadores debatem até hoje se o ubasute realmente aconteceu de forma sistemática.

Não existe comprovação ampla de que o Japão praticava isso oficialmente.

Muitos especialistas acreditam que:

  • parte da narrativa é folclore;

  • parte é exagero moral;

  • parte é metáfora budista;

  • parte é crítica social;

  • parte é literatura popular.

Mas existem registros históricos de abandono de idosos em situações extremas de fome em diversas culturas do mundo.

Então o ubasute provavelmente nasce da mistura entre:

  • tragédias reais;

  • medo coletivo;

  • pobreza extrema;

  • simbolismo religioso;

  • tradição oral.

Ou seja:
mesmo que não tenha sido comum…

o fato de o Japão preservar essa lenda por séculos diz muito sobre os medos da sociedade japonesa.


⛩️ O JAPÃO TEM UMA RELAÇÃO MUITO DIFERENTE COM MEMÓRIA E LEGADO

No Ocidente, o “novo” normalmente é celebrado.

No Japão…
o antigo pode ser sagrado.

Espadas herdadas.
Templos milenares.
Cerimônias preservadas.
Caligrafias ancestrais.
Famílias tradicionais.
Artes mantidas por gerações.

E curiosamente…

o Japão moderno também virou um dos países mais dependentes de sistemas legados do planeta.

Isso não é coincidência cultural.

A sociedade japonesa frequentemente prioriza:

  • estabilidade;

  • continuidade;

  • precisão;

  • confiança;

  • preservação.

Exatamente os mesmos princípios que fizeram o mainframe sobreviver por décadas.


🖥️ MAINFRAME: O “IDOSO” QUE A INTERNET NÃO CONSEGUIU MATAR

Existe uma ironia fantástica aqui.

Durante anos, a tecnologia mainstream tratou o mainframe como:

  • velho;

  • ultrapassado;

  • condenado;

  • antiquado.

Mas quando o volume global explodiu…
quem aguentou?

O legado.

Enquanto startups caíam por overload…
o z/OS continuava processando milhões de transações silenciosamente.

Enquanto APIs modernas quebravam…
o COBOL seguia firme.

Enquanto ambientes distribuídos enfrentavam caos operacional…
o mainframe mantinha consistência transacional absurda.

O mundo inteiro descobriu algo que a mãe da lenda já sabia:

experiência acumulada tem valor invisível.


🎎 UBASUTEYAMA VIROU CINEMA, TEATRO E TERROR PSICOLÓGICO

A lenda inspirou:

  • filmes japoneses;

  • peças tradicionais;

  • contos budistas;

  • mangás;

  • dramas históricos;

  • terror psicológico.

O exemplo mais famoso é:

“A Balada de Narayama”

Romance adaptado para cinema mostrando uma aldeia onde idosos aos 70 anos eram levados à montanha para morrer.

O filme é brutal.
Silencioso.
Frio.
Humano.

E funciona quase como um dump emocional da miséria humana.

Nada de monstros sobrenaturais.
O verdadeiro horror é social.


☕ O QUE UBASUTE ENSINA PARA O MUNDO DA TECNOLOGIA?

Talvez a maior lição dessa lenda seja simples:

descartar conhecimento é perigoso.

Toda empresa corre risco quando:

  • ignora veteranos;

  • despreza legado;

  • abandona documentação;

  • substitui experiência por hype;

  • trata estabilidade como “coisa velha”.

Porque infraestrutura crítica não sobrevive só de inovação.

Ela sobrevive de:

  • memória operacional;

  • disciplina;

  • engenharia;

  • continuidade;

  • experiência acumulada.

Exatamente como o ecossistema mainframe.


🏯 O VERDADEIRO FANTASMA DE UBASUTE

No fim…
a montanha nunca foi sobre idosos.

A montanha representa o medo humano de perder relevância.

E talvez por isso essa história continue tão poderosa mil anos depois.

Porque no fundo:

  • empresas fazem isso com tecnologias;

  • sociedades fazem isso com pessoas;

  • gerações fazem isso com conhecimento;

  • e o mundo moderno faz isso diariamente com tudo que considera “antigo”.

Mas às vezes…

o legado que parece pesado demais para carregar…
é justamente aquilo que impede a civilização de se perder no caminho de volta para casa.


terça-feira, 15 de abril de 2014

💣🔥 AFTER-ANIME DEPRESSION — QUANDO O JOB TERMINA… MAS O SISTEMA FICA EM LOOP 🔥💣

 

Bellacosa Mainframe mergulha no mundo obscuro do after anime depression

💣🔥 AFTER-ANIME DEPRESSION — QUANDO O JOB TERMINA… MAS O SISTEMA FICA EM LOOP 🔥💣

No mundo mainframe, você roda um job pesado, ele termina com RC=00, tudo certo…
Mas no emocional? ABEND S0C4.

É exatamente isso que acontece com a chamada after-anime depression — aquele vazio estranho depois de terminar um anime que te consumiu por completo.


🧠 O QUE É ESSE “BUG EM PRODUÇÃO”?

After-anime depression não é frescura — é um efeito psicológico real:

  • Você criou vínculo emocional com personagens
  • Viveu uma jornada intensa (às vezes por dias seguidos)
  • Seu cérebro recebeu dopamina constante
  • E de repente… END OF FILE

Resultado:
👉 sensação de vazio
👉 desmotivação
👉 dificuldade de começar outro anime
👉 saudade absurda de algo que nem existe

É como se o sistema perdesse o contexto de execução.


🔥 ANIMES QUE MAIS GERAM ESSE “CRASH EMOCIONAL”

💀 Devilman Crybaby

  • Final devastador
  • Questiona humanidade, amor e existência
  • Te deixa olhando pro nada depois dos créditos

👉 Aqui não é tristeza… é reset existencial


⚔️ Attack on Titan

  • Anos acompanhando personagens
  • Reviravoltas morais pesadas
  • Final que divide, mas impacta

👉 Sensação: “o mundo acabou… e agora?”


😭 Your Lie in April

  • Beleza + tragédia
  • Trilha sonora que destrói o coração
  • Final inevitável

👉 Aqui o ABEND vem com trilha sonora


🌌 Steins;Gate

  • Construção lenta → payoff absurdo
  • Sacrifícios pesados
  • Loop temporal emocional

👉 Você sai diferente de como entrou


🧩 Neon Genesis Evangelion


  • Filosofia + depressão + simbolismo
  • Final confuso e introspectivo
  • Te obriga a olhar pra dentro

👉 Não termina quando acaba — continua na sua cabeça


⚙️ POR QUE ISSO ACONTECE? (VERSÃO MAINFRAME)

Pensa assim:

Conceito AnimeEquivalente Mainframe
Imersão totalJob batch de longa duração
PersonagensDados críticos em memória
Final do animeEND JOB
EmoçãoBuffer não descarregado
After-anime depressionLoop sem próximo job

👉 Seu cérebro estava rodando um “programa emocional contínuo”…
Quando termina, não tem próximo step no JCL.


🧯 COMO “RECUPERAR O SISTEMA”

  • 🔄 Comece algo leve (slice of life ou comédia)
  • 🧠 Reassista cenas (dump analysis emocional)
  • 💬 Converse com alguém (log compartilhado)
  • ✍️ Escreva sobre o anime (persistência em disco 😄)
  • ⏳ Dê tempo — o sistema estabiliza

💣 VEREDITO FINAL

After-anime depression é o preço de consumir algo bom demais.

Se um anime te deixou assim…
👉 ele não foi só entretenimento
👉 foi uma experiência

No fim das contas:

Alguns animes não acabam…
Eles ficam rodando em background na sua mente.

 

segunda-feira, 14 de abril de 2014

🎯 O guia mínimo que separa curiosos de verdadeiros Data Scientists

 

Bellacosa Mainframe apresenta Python na Ciencia de Dados

🎯 O guia mínimo que separa curiosos de verdadeiros Data Scientists

Python é a principal linguagem utilizada em Data Science, permitindo transformar grandes volumes de dados em insights valiosos para negócios e pesquisa. 

Com bibliotecas essenciais como NumPy, Pandas, Matplotlib, Seaborn e Scikit-learn, é possível realizar todo o ciclo analítico: carregamento, limpeza, exploração, visualização e modelagem de dados.

O Pandas oferece DataFrames poderosos para manipulação eficiente de informações, enquanto o NumPy garante cálculos vetorizados de alta performance. Ferramentas de visualização ajudam a identificar padrões, tendências e outliers, fundamentais para a análise exploratória. Já o Scikit-learn possibilita a criação de modelos de Machine Learning para previsões e classificações. 

Esse ecossistema torna Python indispensável em áreas como finanças, marketing, saúde, engenharia e Big Data. Aprender esses fundamentos é o primeiro passo para atuar como cientista de dados, analista ou engenheiro de dados, acompanhando a crescente demanda por profissionais capazes de extrair valor estratégico a partir dos dados.

🐍🔥 Cheatsheet Python para Data Science

🧠 Stack Essencial

import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns

👉 90% dos projetos começam assim.


📊 NumPy — Matemática Vetorizada (Base de Tudo)

Criar arrays

a = np.array([1, 2, 3])
b = np.zeros(5)
c = np.ones((2,3))
d = np.arange(0,10)
e = np.linspace(0,1,5)

Operações vetoriais

a * 2
a + b
np.sqrt(a)
np.mean(a)
np.sum(a)

👉 Sem loops → extremamente rápido.


📚 Pandas — DataFrames (o coração da Data Science)

Criar DataFrame

df = pd.DataFrame({
"nome": ["Ana", "João"],
"idade": [25, 30]
})

Ler arquivos

pd.read_csv("dados.csv")
pd.read_excel("dados.xlsx")
pd.read_json("dados.json")

Visualização inicial

df.head()
df.tail()
df.info()
df.describe()
df.shape
df.columns

👉 Primeiros comandos após carregar dados.


🔎 Seleção de dados

Coluna

df["idade"]

Múltiplas colunas

df[["nome", "idade"]]

Filtro

df[df["idade"] > 25]

Filtro múltiplo

df[(df["idade"] > 25) & (df["cidade"] == "SP")]

✏️ Modificação de dados

Nova coluna

df["idade_futura"] = df["idade"] + 5

Remover coluna

df.drop("idade", axis=1)

Valores ausentes

df.isna()
df.dropna()
df.fillna(0)

📈 Agrupamento (Group By)

df.groupby("cidade")["salario"].mean()

👉 Essencial para análise exploratória.


🔄 Ordenação

df.sort_values("idade")
df.sort_values("idade", ascending=False)

📊 Estatísticas rápidas

df.mean()
df.median()
df.std()
df.min()
df.max()
df.corr()

📉 Visualização com Matplotlib

Linha

plt.plot(df["idade"])
plt.show()

Histograma

plt.hist(df["idade"])
plt.show()

Scatter

plt.scatter(df["idade"], df["salario"])
plt.show()

🎨 Seaborn — Gráficos bonitos por padrão

sns.histplot(df["idade"])
sns.boxplot(x=df["idade"])
sns.scatterplot(x="idade", y="salario", data=df)

🧹 Limpeza de dados

Remover duplicatas

df.drop_duplicates()

Converter tipos

df["idade"] = df["idade"].astype(int)

Datas

df["data"] = pd.to_datetime(df["data"])
df["ano"] = df["data"].dt.year

🤖 Machine Learning básico (Scikit-Learn)

from sklearn.model_selection import train_test_split
from sklearn.linear_model import LinearRegression

Dividir treino/teste

X_train, X_test, y_train, y_test = train_test_split(
X, y, test_size=0.2, random_state=42
)

Treinar modelo

model = LinearRegression()
model.fit(X_train, y_train)

Previsão

pred = model.predict(X_test)

🧠 Pipeline mental da Data Science

1️⃣ Carregar dados
2️⃣ Explorar
3️⃣ Limpar
4️⃣ Transformar
5️⃣ Visualizar
6️⃣ Modelar
7️⃣ Avaliar


⚡ Truques poderosos

Aplicar função em coluna

df["log_salario"] = np.log(df["salario"])

Apply personalizado

df["categoria"] = df["idade"].apply(
lambda x: "Adulto" if x >= 18 else "Menor"
)

Amostra aleatória

df.sample(5)

Contagem de valores

df["cidade"].value_counts()

💾 Exportar dados

df.to_csv("saida.csv", index=False)
df.to_excel("saida.xlsx")

🔥 Ferramentas mais usadas na indústria

🐍 Python
📊 Pandas
⚡ NumPy
📈 Matplotlib / Seaborn
🤖 Scikit-Learn
🧠 TensorFlow / PyTorch
☁️ Spark / Databricks


☕ Frase de cientista de dados

👉 “Sem Pandas, Python é só uma linguagem.
Com Pandas, vira uma ferramenta de descoberta.”

domingo, 13 de abril de 2014

Changeman x Endevor: Briga de gigantes

 

Bellacosa Mainframe e a briga de gigantes no controle de versão Changeman Versus Endevor

Um Café no Bellacosa Mainframe

Changeman x Endevor

A briga boa do Mainframe (com gravata, RACF e auditor olhando) 😄

Se existe uma discussão eterna no mundo IBM Mainframe — quase tão antiga quanto JCL vs PROC ou COBOL fixo vs free — ela atende pelo nome:

CA Changeman ZMF x CA Endevor SCM

Não é guerra.
É clássico.
É derby.
É mainframe raiz.

Vamos colocar os dois frente a frente ao melhor estilo Bellacosa Mainframe: com história, passo a passo, comandos, dicas práticas, curiosidades, easter eggs e comentários de quem já suou em janela de produção.



1️⃣ Antes de tudo: eles fazem a MESMA coisa?

Não exatamente.

✔ Ambos fazem Software Change Management
✔ Ambos controlam código, versões e promoção
❌ Mas a filosofia é completamente diferente

👉 Changeman é processo e pacote
👉 Endevor é ambiente e mapa

Pense assim:

  • Changeman: “Vou criar um pacote com tudo que muda.”

  • Endevor: “Vou mover o elemento dentro do fluxo do sistema.”



2️⃣ Um pouco de história 📜

🕰️ Endevor (o veterano)

  • Nasceu nos anos 70/80

  • Criado para ambientes grandes, complexos e altamente integrados

  • Muito usado em bancos, seguradoras e telecom

  • Filosofia: onde o código vive importa

🕰️ Changeman (o organizado)

  • Surge depois, focado em governança e auditoria

  • Ideal para ambientes com:

    • Muitos desenvolvedores

    • Processos rígidos

    • Separação clara de responsabilidades

  • Filosofia: o pacote é a unidade da mudança


3️⃣ Conceitos fundamentais (lado a lado)

ConceitoChangemanEndevor
Unidade principalPackageElement
ControlePor pacotePor ambiente
PromoçãoPromote PackageMove Element
VersãoBaselineLevel
AuditoriaMuito forteForte, mas diferente
Curva de aprendizadoMédiaAlta 😅

4️⃣ Changeman em 3 passos (vida real)

🔹 1. Criar Package

Você cria um Package contendo:

  • Programas

  • JCLs

  • Copybooks

Tudo que muda vai dentro dele.


🔹 2. Trabalhar nos componentes

  • Edita

  • Compila

  • Testa

  • Usa View Changes para validar


🔹 3. Promote

  • DEV → QA → HML → PRD

  • Aprovações

  • Auditoria feliz

  • Produção protegida

👉 O pacote é rei.


5️⃣ Endevor em 3 passos (vida real)

🔹 1. Localizar o Element

O código já vive dentro de:

  • Environment

  • System

  • Subsystem

  • Type

  • Stage


🔹 2. Editar e gerar

Você:

  • EDIT o Element

  • GENERATE

  • Endevor cria versões (Levels)


🔹 3. Move

  • MOVE Stage 1 → Stage 2

  • O elemento sobe no fluxo

  • Tudo rastreado pelo caminho

👉 O mapa do sistema é rei.


6️⃣ Comandos clássicos (raiz mesmo) ⌨️

🔹 Endevor (linha de comando ISPF)

  • ADD – adicionar elemento

  • EDIT – editar

  • GENERATE – compilar

  • MOVE – promover

  • BROWSE – visualizar

  • HISTORY – ver histórico

💬 “Sem GENERATE, não existe Endevor.”


🔹 Changeman (menu-driven)

  • Create Package

  • Add Components

  • Edit

  • Build

  • Test

  • Promote

  • View Changes

💬 “Sem Package, não existe Changeman.”


7️⃣ Dicas Bellacosa (quem já caiu em produção) 🧠

✔ Quando escolher Changeman

  • Ambientes com auditoria pesada

  • Times grandes

  • Mudanças agrupadas

  • Governança forte

  • Muitas áreas envolvidas

👉 Ideal para bancos e órgãos regulados


✔ Quando escolher Endevor

  • Sistemas gigantes

  • Fluxos complexos

  • Dependência entre componentes

  • Times técnicos maduros

👉 Ideal para core systems antigos e robustos


8️⃣ Curiosidades ☕

  • Endevor não precisa de pacote

  • Changeman vive de pacote

  • Endevor é extremamente customizável

  • Changeman é mais user friendly

  • Ambos integram com RACF

  • Ambos deixam rastro (log) até do seu suspiro 😄


9️⃣ Easter Eggs de quem viveu 🥚

🥚 O “MOVE errado” no Endevor
Mover o elemento para o stage errado é como:

“scp direto em produção”

🥚 O pacote Frankenstein no Changeman
Package com:

  • 1 programa

  • 2 JCLs

  • 3 COPYs

  • 1 PROC

  • E ninguém lembra por quê

🥚 Auditor vs Desenvolvedor
Auditor ama Changeman.
Arquiteto raiz ama Endevor.
E o programador… só quer ir pra casa 😂


🔟 Changeman x Endevor em linguagem moderna

HojeMainframe
Git FlowEndevor
Pull RequestChangeman Package
CI/CD PipelineGenerate / Promote
DiffView Changes / History

1️⃣1️⃣ Quem ganha a briga?

Resposta honesta Bellacosa:

Depende do ambiente, da cultura e do tamanho do monstro.

❌ Não existe vencedor absoluto
✔ Existe ferramenta certa para o problema certo

Mainframe não é moda.
É engenharia.


1️⃣2️⃣ Comentário final ☕

Changeman e Endevor não são inimigos.
São filosofias diferentes para o mesmo objetivo:

Proteger produção, garantir rastreabilidade e manter o caos sob controle.

Se você domina os dois, você não é só programador:
👉 Você é guardião do sistema.

☕🚀


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