Translate

terça-feira, 17 de março de 2020

O Guia Definitivo para um Programador COBOL Padawan Entender por que Todo Isekai, RPG e Mangá Usa as Letras E, D, C, B, A e S para Medir o Poder

 

Bellacosa Mainframe entenda os ranks das guildas em anime e alem

☕ Um Café no Bellacosa Mainframe

Ranks dos Animes sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender por que Todo Isekai, RPG e Mangá Usa as Letras E, D, C, B, A e S para Medir o Poder

Existe uma cena que praticamente todo fã de anime, mangá, light novel ou RPG já viu dezenas de vezes.

O protagonista chega até uma Guilda dos Aventureiros.

Uma esfera mágica mede suas habilidades.

Uma placa luminosa aparece.

Todos prendem a respiração.

Então surge uma única letra.

E.

Os aventureiros riem.

O recepcionista faz uma cara de pena.

Os veteranos comentam:

— "Só um Rank E..."

Mas, algumas temporadas depois, aquele mesmo personagem derrota um dragão ancestral, salva o reino inteiro e recebe o título de Rank S.

Se você está começando agora no mundo dos animes, talvez pense que essas letras foram inventadas apenas para deixar a história mais emocionante.

Na verdade, elas representam um sistema extremamente inteligente de progressão que mistura psicologia, teoria dos jogos, design de RPG, estatística, administração e até conceitos utilizados em grandes empresas.

Curiosamente, esse sistema também pode explicar perfeitamente como evolui um programador COBOL dentro de um ambiente IBM Z.

Pegue sua caneca de café.

Hoje vamos descobrir que essa pequena letra ao lado do nome de um aventureiro diz muito mais do que parece.


Antes de tudo: o que é um Rank?

Rank significa simplesmente:

posição dentro de uma hierarquia.

É uma maneira rápida de responder perguntas como:

  • Quão experiente essa pessoa é?

  • Em quem podemos confiar?

  • Que tipo de missão ela consegue realizar?

  • Quanto perigo ela suporta?

  • Quanto ela já provou seu valor?

É exatamente igual ao mundo profissional.

Imagine um hospital.

Existem:

  • Estagiários

  • Residentes

  • Médicos

  • Especialistas

  • Chefes de equipe

Todos são médicos.

Mas possuem níveis diferentes de experiência.

Nos animes acontece exatamente a mesma coisa.


A pirâmide do poder

A maioria dos animes representa os ranks como uma pirâmide.

           S
         A
       B
     C
   D
 E

Observe uma curiosidade.

Quanto maior o rank...

menor o espaço.

Isso representa uma verdade estatística.

Pouquíssimas pessoas chegam ao topo.

Essa ideia aparece em praticamente tudo na vida.

Por exemplo:

  • Faixas do Karatê

  • Graduação Militar

  • IBM Fellow

  • Doutorado

  • Certificações técnicas

  • Cargos executivos

Sempre existe uma base enorme.

E um topo extremamente pequeno.


Rank E — O Começo da Jornada

O Rank E costuma ser o menor nível oficial.

Muita gente interpreta isso como:

"Esse personagem é fraco."

Na verdade, não.

Ele apenas ainda não teve oportunidade de provar seu potencial.

O Rank E representa:

  • iniciante

  • novato

  • aprendiz

  • aventureiro recém-registrado

Ele conhece pouco sobre:

  • monstros

  • estratégia

  • sobrevivência

  • trabalho em equipe

É o equivalente ao famoso Padawan.

No mundo COBOL seria alguém que acabou de aprender:

  • TSO

  • ISPF

  • JCL

  • Compilar um programa

Ainda não significa que seja ruim.

Significa apenas que está começando.


Rank D — O Sobrevivente

Agora o aventureiro já saiu da teoria.

Ele enfrentou monstros reais.

Já conhece armadilhas.

Aprendeu que uma espada bonita não vence batalhas.

Experiência vence.

No mercado de trabalho seria o profissional júnior.

Ele ainda pergunta bastante.

Mas já consegue executar tarefas sozinho.


Rank C — O Profissional

Aqui começa a diferença.

O aventureiro deixa de ser apenas alguém que acompanha grupos.

Agora ele passa a ser alguém confiável.

Recebe missões importantes.

Pode liderar pequenas equipes.

É respeitado.

Em empresas seria o profissional pleno.

No Mainframe:

  • desenvolve COBOL

  • conhece VSAM

  • entende Db2

  • sabe trabalhar com CICS

Ainda consulta documentação.

Mas já entrega produção.


Rank B — O Especialista

Pouca gente chega aqui.

Agora o aventureiro possui:

  • reputação

  • fama

  • dinheiro

  • respeito

As pessoas conhecem seu nome.

É chamado para missões perigosas.

Pode ensinar iniciantes.

Em tecnologia seria:

Especialista.

É aquele profissional que todos procuram quando aparece um problema complicado.


Rank A — A Elite

Agora estamos falando de aventureiros que mudam guerras.

Eles enfrentam:

  • dragões

  • reis demônios

  • calamidades

  • monstros lendários

Governos pedem sua ajuda.

Reinos oferecem recompensas.

São poucos.

Muito poucos.

Na IBM seria alguém reconhecido internacionalmente.


Rank S — A Lenda

Esse é o rank mais famoso.

O curioso é que...

ele nem faz parte do alfabeto.

Depois do A...

vem o S.

Por quê?

Existem diversas teorias.

As mais conhecidas dizem que significa:

Special

Superior

Supreme

Super

Independentemente da origem, o Japão adotou o Rank S como:

"Acima do excelente."

São pessoas praticamente únicas.


Por que quase todos os animes usam letras?

Porque o cérebro entende letras instantaneamente.

Imagine duas situações.

Situação 1

Nível de combate:
785

Situação 2

Rank A

Qual delas comunica melhor?

A segunda.

Em menos de um segundo.

Isso é linguagem visual.

Os japoneses dominam isso como poucos.


A importância da Guilda

Outro detalhe importante.

Os ranks normalmente pertencem à Guilda.

Não ao personagem.

Isso significa que existe uma instituição responsável por avaliar todos.

É como:

OAB

CRM

IBM Certification

AWS

Microsoft

Cisco

A Guilda certifica.

O aventureiro representa.


Como alguém sobe de Rank?

Não basta dizer:

"Agora sou Rank A."

É preciso provar.

Normalmente envolve:

  • quantidade de missões

  • taxa de sucesso

  • monstros derrotados

  • comportamento

  • liderança

  • experiência

Perceba.

Força é apenas um dos critérios.


A psicologia da evolução

Existe um motivo pelo qual adoramos histórias assim.

Nosso cérebro ama progresso.

Toda vez que vemos:

Rank D

↓

Rank C

Sentimos satisfação.

Isso acontece porque percebemos evolução.

Os videogames exploram exatamente esse mecanismo.

XP.

Level.

Badges.

Achievements.

Tudo gira em torno da mesma ideia.


Quando aparecem os Ranks SS, SSS e EX

Muitos animes modernos resolveram exagerar.

Então surgiram:

SS

SSS

EX

Legend

Myth

God

Divine

Isso serve para mostrar personagens que estão muito acima da média.

Às vezes existe apenas uma pessoa no mundo inteiro com aquele título.


Existem animes sem ranks?

Sim.

E isso é interessante.

Obras como:

  • Berserk

  • Vinland Saga

  • Monster

Não utilizam letras.

Mesmo assim existe hierarquia.

Ela apenas é construída pela narrativa.

Já nos isekais e RPGs, usar letras acelera a compreensão do espectador.


Alguns dos animes mais famosos que utilizam esse sistema

Praticamente virou um padrão do gênero.

Entre eles:

  • Solo Leveling

  • Overlord

  • Goblin Slayer

  • DanMachi

  • Tsukimichi

  • Arifureta

  • The Rising of the Shield Hero

  • Black Summoner

  • Failure Frame

  • I Parry Everything

  • The Unwanted Undead Adventurer

  • Infinite Dendrogram

  • The Great Cleric

  • Bofuri (para habilidades)

  • Kuma Kuma Kuma Bear

  • Boukensha ni Naritai

Cada um adapta o sistema às regras do seu universo, mas a lógica permanece a mesma.


A grande metáfora escondida

Na verdade...

esses ranks nunca falaram apenas de poder.

Eles falam sobre confiança.

Um aventureiro Rank A recebe missões importantes porque milhares de pessoas acreditam que ele será capaz de concluí-las.

No mundo corporativo acontece o mesmo.

Você não lidera um projeto crítico apenas porque sabe programar.

Você lidera porque demonstrou, ao longo do tempo, capacidade técnica, responsabilidade e maturidade.


O que isso ensina para um Programador COBOL Padawan?

Agora vem a parte mais divertida.

Imagine que o IBM Z também tivesse ranks oficiais.

🟢 Rank F — O recém-chegado

O Rank F costuma representar o nível mais baixo em alguns animes, mangás e RPGs, embora nem todos os universos o utilizem. Geralmente identifica aventureiros recém-registrados, sem experiência prática, equipamentos adequados ou feitos reconhecidos. 

Personagens nesse nível recebem missões simples, como coleta de ervas, entrega de itens ou eliminação de pequenos monstros. O objetivo é adquirir experiência, aprender trabalho em equipe e desenvolver habilidades básicas. 

Em muitos isekais, o protagonista começa no Rank F para evidenciar sua evolução ao longo da história. É a fase do aprendizado, onde persistência, disciplina e coragem valem mais do que força bruta.


🟢 Rank E — O Padawan

Você aprendeu:

  • O que é um Mainframe

  • Login no TSO

  • Navegação no ISPF

  • Criar um PDS

  • Executar um JCL simples

Você ainda pergunta muito.

E isso é ótimo.


🔵 Rank D — O Desenvolvedor Júnior

Agora você:

  • programa COBOL básico;

  • entende COPYBOOKs;

  • faz manutenção simples;

  • lê mensagens do JES2;

  • começa a entender ABENDs.

Já consegue contribuir em produção com supervisão.


🟡 Rank C — O Profissional Pleno

Neste ponto você domina:

  • COBOL estruturado;

  • JCL avançado;

  • VSAM;

  • Db2;

  • CICS;

  • SQL;

  • controle de versões.

Você entrega funcionalidades completas e entende as regras de negócio.


🟠 Rank B — O Especialista

Agora você resolve problemas que poucos conseguem.

Conhece:

  • IMS;

  • MQ;

  • RACF;

  • SMF;

  • RMF;

  • Performance;

  • tuning de SQL;

  • integração com APIs;

  • automação com Zowe e Ansible.

Quando ocorre um incidente crítico, seu telefone toca.


🔴 Rank A — O Arquiteto

Você não pensa apenas em programas.

Pensa em sistemas inteiros.

Decide arquiteturas.

Define padrões.

Mentora equipes.

Participa de modernizações e integrações com nuvem, DevOps e IA.


⭐ Rank S — A Lenda da Guilda

O Rank S não é apenas quem sabe mais comandos.

É quem inspira outros profissionais.

É o especialista que:

  • resolve incidentes aparentemente impossíveis;

  • conhece décadas de história do ambiente;

  • entende profundamente regras de negócio;

  • forma novos talentos;

  • mantém sistemas que processam milhões de transações diárias sem falhas.

É o profissional cuja maior conquista não é um certificado, mas o respeito conquistado ao longo dos anos.



O verdadeiro significado da pirâmide

Quando olhamos novamente para aquela simples imagem de um anime, percebemos que ela representa muito mais do que níveis de força.

Ela fala sobre aprendizado contínuo, confiança, responsabilidade e evolução.

Nenhum protagonista começa no topo. Os heróis mais memoráveis tropeçam, erram, treinam e acumulam experiência antes de alcançar os maiores desafios. O mesmo vale para quem escolhe uma carreira em tecnologia.

No universo IBM Z, não existe magia que transforme um iniciante em especialista da noite para o dia. Cada programa compilado, cada ABEND investigado, cada JCL corrigido, cada consulta SQL otimizada e cada madrugada de suporte em produção acrescentam um pouco mais de experiência à sua jornada.

Essa talvez seja a maior lição escondida por trás dos ranks dos animes: o verdadeiro poder não está na letra que aparece ao lado do seu nome, mas na quantidade de conhecimento, disciplina e perseverança que foi necessária para conquistá-la.

Assim como os grandes protagonistas dos isekais, todo Programador COBOL Padawan começa no Rank E. E, com estudo constante, curiosidade e prática, pode um dia tornar-se uma verdadeira lenda da sua própria guilda tecnológica.


segunda-feira, 16 de março de 2020

Teoria dos Jogos no Mainframe : Como um Programador COBOL Padawan Pode Aprender a Pensar Como um Estrategista

 

Bellacosa Mainframe e a teoria dos jogos no mainframe

☕ Um Café no Bellacosa Mainframe

Teoria dos Jogos no Mainframe

Como um Programador COBOL Padawan Pode Aprender a Pensar Como um Estrategista

"No mainframe, quase nenhum problema é apenas técnico. Quase todos envolvem pessoas tomando decisões."

Quando um desenvolvedor COBOL imagina Matemática aplicada ao desenvolvimento, normalmente pensa em algoritmos, estruturas de dados ou otimização.

Mas existe uma disciplina que explica boa parte dos conflitos encontrados diariamente dentro de um grande ambiente IBM Z:

A Teoria dos Jogos.

Não é sobre videogames.

É sobre entender como pessoas, equipes, empresas e até sistemas inteiros tomam decisões quando seus interesses dependem das escolhas dos outros.

E surpreendentemente...

Ela explica muito do que acontece dentro de um banco.


O que é Teoria dos Jogos?

A Teoria dos Jogos é um ramo da matemática aplicada que estuda situações onde vários participantes (chamados jogadores) precisam tomar decisões.

Cada decisão altera o resultado dos demais.

Ou seja...

Meu resultado depende da sua decisão.

E o seu depende da minha.

No mundo corporativo isso acontece o tempo inteiro.

No mainframe também.


Onde nasceu?

A origem moderna começa em 1944.

Dois pesquisadores publicaram um livro que mudou completamente Economia, Estratégia Militar e Ciência da Computação.

John von Neumann

Matemático brilhante.

Pai da arquitetura dos computadores modernos.

Participou do Projeto Manhattan.

Criou a primeira formulação matemática da Teoria dos Jogos.


Oskar Morgenstern

Economista.

Percebeu que economia não podia ser explicada apenas por oferta e demanda.

Era preciso considerar comportamento estratégico.


O livro histórico

Theory of Games and Economic Behavior (1944)

Foi um divisor de águas.

Mostrou que decisões racionais podem ser modeladas matematicamente.

Até hoje é considerado um dos livros mais importantes do século XX.


Depois veio John Nash

Se você assistiu ao filme Uma Mente Brilhante, conhece sua história.

John Nash revolucionou a área criando o conceito de:

Equilíbrio de Nash

É uma situação onde ninguém ganha mudando sua estratégia sozinho.

Todos ficam "presos" em uma decisão estável.

Isso acontece diariamente em TI.


Um exemplo no banco

Imagine duas equipes.

Equipe A deseja atualizar o sistema.

Equipe B deseja estabilidade.

Se A atualiza sem avisar...

B sofre.

Se B bloqueia todas as mudanças...

A nunca entrega inovação.

Ambas precisam cooperar.

Este é um jogo estratégico.


O famoso Dilema do Prisioneiro

É provavelmente o exemplo mais conhecido.

Dois suspeitos são presos.

Cada um pode:

  • colaborar

  • trair

O resultado depende da decisão dos dois.

Curiosamente...

Quando ambos tentam maximizar seu ganho individual...

Os dois acabam pior.


Isso acontece no Mainframe?

O tempo inteiro.

Exemplos:

  • desenvolvimento versus operações

  • aplicações versus infraestrutura

  • segurança versus produtividade

  • negócio versus tecnologia

  • performance versus custo

  • estabilidade versus inovação

Cada decisão influencia outra equipe.


Um Programador COBOL joga sem perceber

Imagine:

Você recebe uma alteração urgente.

Tem duas opções.

Estratégia A

Entregar rápido.

Maior risco.


Estratégia B

Testar corretamente.

Entrega mais lenta.


Agora imagine que o gestor mede apenas velocidade.

Naturalmente todos passam a entregar rápido.

Depois aparecem:

  • incidentes

  • rollback

  • retrabalho

O sistema inteiro piora.

Foi um jogo mal desenhado.


Sistemas também jogam

Não apenas pessoas.

Diversos componentes competem por recursos.

Exemplos:

  • CPU

  • memória

  • canais

  • discos

  • locks

  • threads

  • Db2

  • CICS

  • MQ

Todos disputam recursos limitados.

Isso lembra um enorme jogo cooperativo.


WLM é Teoria dos Jogos em ação

O Workload Manager não distribui CPU aleatoriamente.

Ele resolve conflitos.

Pergunta continuamente:

Quem precisa de mais recursos?

Quem pode esperar?

Quem possui maior prioridade?

É praticamente um árbitro estratégico.


Lock no Db2

Imagine dois programas.

Programa A bloqueia uma tabela.

Programa B espera.

Agora ambos aguardam recursos diferentes.

Nasce um deadlock.

O Db2 precisa decidir.

Quem perde?

Quem continua?

Existe estratégia envolvida.


Escalonamento Batch

No JES2 e nos schedulers acontece exatamente o mesmo.

Centenas de jobs.

Recursos limitados.

Dependências.

Janela batch.

Prioridades.

Cada decisão muda o resultado das demais.


Balanceamento de carga

No Sysplex:

várias LPARs compartilham carga.

Mover uma workload melhora um sistema...

mas pode piorar outro.

É otimização estratégica.


Segurança

Até segurança pode ser analisada pela Teoria dos Jogos.

O atacante escolhe:

  • onde atacar

  • quando atacar

  • quanto investir

O defensor escolhe:

  • onde proteger

  • quanto monitorar

  • quanto gastar

É um jogo contínuo.


IA também usa Teoria dos Jogos

Modelos modernos de IA utilizam conceitos relacionados em:

  • aprendizado por reforço

  • sistemas multiagentes

  • negociação entre agentes

  • coordenação

  • planejamento estratégico

Cada agente toma decisões considerando os demais.


Grandes autores que vale conhecer

John von Neumann

Fundador da área.


Oskar Morgenstern

Aplicação econômica.


John Nash

Equilíbrio de Nash.


Thomas Schelling

Estratégia militar.

Conflitos.

Negociação.

Recebeu Nobel.


Robert Aumann

Jogos repetidos.

Cooperação.

Muito útil para organizações.


John Harsanyi

Jogos com informação incompleta.

Muito importante para segurança.


Lloyd Shapley

Valor de Shapley.

Como dividir benefícios em sistemas cooperativos.

Muito usado hoje em Inteligência Artificial.


Elinor Ostrom

Estudou cooperação em recursos compartilhados.

Suas ideias aparecem em computação distribuída.


Conceitos fundamentais

Todo Padawan deveria conhecer:

  • jogadores

  • estratégias

  • payoff

  • utilidade

  • equilíbrio de Nash

  • jogos cooperativos

  • jogos não cooperativos

  • jogos repetidos

  • jogos simultâneos

  • informação perfeita

  • informação imperfeita

  • dominância

  • estratégia mista

  • minimax

  • soma zero

  • soma não zero

Não precisa decorar fórmulas.

Entenda primeiro as ideias.


Como isso aparece no COBOL?

Mais do que parece.

Modelagem de regras

Quem ganha prioridade?

Quem espera?

Quem pode cancelar?

Tudo isso são decisões estratégicas.


Sistemas bancários

Fila de pagamentos.

Pix.

TED.

Cartões.

Empréstimos.

Todos possuem regras para resolver conflitos.


Controle de concorrência

Locks.

Timeout.

Retry.

Commit.

Rollback.

Tudo depende da estratégia adotada.


Escalabilidade

Quando dividir processamento?

Quando serializar?

Quando paralelizar?

Novamente...

Teoria dos Jogos.


Evolução da área

1944

Nascimento formal.

1950

Equilíbrio de Nash.

1970

Jogos evolucionários.

1980

Aplicações em Computação.

1990

Internet.

Redes.

Protocolos.

2000

Segurança.

Mercados eletrônicos.

Cloud.

2015+

Machine Learning.

IA.

Multiagentes.

Blockchain.

Robótica.


Como estudar?

Nível 1

Entenda lógica matemática.

Não precisa cálculo avançado.


Nível 2

Leia sobre:

  • Dilema do Prisioneiro

  • Equilíbrio de Nash

  • Minimax


Nível 3

Estude algoritmos.

Pesquisa Operacional.

Otimização.


Nível 4

Veja aplicações em:

  • IA

  • Redes

  • Segurança

  • Economia

  • Cloud


Nível 5

Passe a observar seu próprio ambiente de trabalho.

Você descobrirá jogos estratégicos em toda reunião.


Livros recomendados

Para iniciantes

  • The Art of Strategy — Avinash Dixit e Barry Nalebuff.

  • Thinking Strategically — Avinash Dixit e Barry Nalebuff.

Intermediário

  • Game Theory: A Very Short Introduction — Ken Binmore.

Clássicos

  • Theory of Games and Economic Behavior — John von Neumann e Oskar Morgenstern.

  • Non-Cooperative Games — John Nash.

Aplicações

  • The Evolution of Cooperation — Robert Axelrod.

  • Micromotives and Macrobehavior — Thomas Schelling.


Aplicações diretas no IBM Z

Um profissional de Mainframe pode usar Teoria dos Jogos para:

  • projetar regras de negócio mais robustas;

  • definir prioridades no IBM Workload Manager (WLM);

  • reduzir contenção de locks no Db2;

  • modelar filas no IBM MQ;

  • melhorar políticas de escalonamento em JES2 e schedulers;

  • analisar conflitos entre aplicações Batch e Online (CICS);

  • criar estratégias de segurança com RACF e gestão de privilégios;

  • otimizar uso de CPU, memória e I/O entre LPARs;

  • apoiar decisões de capacidade (Capacity Planning);

  • compreender negociações entre equipes de desenvolvimento, operações e negócio.

O resultado é menos decisões baseadas em intuição e mais decisões baseadas em incentivos, equilíbrio e cooperação.


A Trilha Bellacosa para um Padawan COBOL

Uma boa jornada de estudos pode seguir esta sequência:

  1. Lógica e Matemática Discreta.

  2. Probabilidade e Estatística.

  3. Teoria dos Jogos.

  4. Pesquisa Operacional.

  5. Algoritmos e Estruturas de Dados.

  6. Sistemas Distribuídos.

  7. Concorrência e Paralelismo.

  8. WLM, JES2 e escalonamento no z/OS.

  9. Db2: locking, isolamento e concorrência.

  10. Inteligência Artificial, aprendizado por reforço e sistemas multiagentes.

Cada etapa amplia sua capacidade de entender não apenas como o sistema funciona, mas por que ele toma determinadas decisões.


Conclusão

Muitos acreditam que um excelente programador conhece apenas COBOL, JCL, CICS ou Db2.

Os grandes profissionais vão além.

Eles entendem comportamento.

Entendem incentivos.

Entendem conflitos.

Entendem cooperação.

No fim das contas, um sistema corporativo não é apenas código executando em um IBM Z.

É um enorme conjunto de pessoas, aplicações, recursos e decisões estratégicas interagindo o tempo todo.

Quem aprende Teoria dos Jogos deixa de enxergar apenas programas.

Passa a enxergar sistemas.

E esse é um dos maiores saltos que um Padawan pode dar rumo ao caminho de um verdadeiro Mestre Mainframe.

"No IBM Z, vencer não significa consumir toda a CPU. Significa encontrar o equilíbrio onde aplicações, equipes e negócios prosperam juntos. Essa é a verdadeira estratégia — e talvez o maior jogo de todos."

 

Teoria dos Jogos no Mainframe: O Guia para Programadores COBOL

A Sociedade do Mainframe — A Primeira Jornada rumo ao Reino da Alta Disponibilidade : Descobre que o Verdadeiro Poder Não Está em Evitar Falhas, Mas em Continuar Funcionando Apesar Delas

 

Bellacosa Mainframe e a sociedade do mainframe rumo a alta disponibilidade

☕ Um Café no Bellacosa Mainframe

A Sociedade do Mainframe — A Primeira Jornada rumo ao Reino da Alta Disponibilidade

Quando um Programador COBOL Padawan Descobre que o Verdadeiro Poder Não Está em Evitar Falhas, Mas em Continuar Funcionando Apesar Delas

"Nem todos os sistemas que caem estão perdidos. Alguns apenas aguardam que outra região assuma sua missão."


Introdução

Existe um momento na carreira de todo programador COBOL em que ele deixa de pensar apenas no programa que escreveu.

Até então, seu universo era relativamente pequeno.

Recebia uma especificação.

Criava um programa COBOL.

Compilava.

Executava.

Corrigia alguns ABENDs.

Consultava um VSAM.

Executava um SQL.

Colocava em produção.

Fim da história.

Mas então surge uma pergunta aparentemente simples.

"O que acontece quando o programa está funcionando e o servidor onde ele está executando simplesmente desaparece?"

Silêncio.

Essa pergunta muda completamente a forma de enxergar um sistema corporativo.

É exatamente neste ponto que começa nossa jornada.

Como em O Senhor dos Anéis – A Sociedade do Anel, descobrimos que existe um mundo muito maior além do Condado.

O COBOL é apenas Frodo.

O CICS é Rivendell.

O z/OS é a Terra Média.

E a Alta Disponibilidade é a Sociedade que mantém o Um Anel longe das forças do caos.

Hoje atravessaremos essa Terra Média tecnológica.

Pegue seu café.

Afivele o cinto do terminal 3270.

Nossa aventura apenas começou.


Capítulo I

O Condado: Onde Todo Programador COBOL Começa

Todo iniciante acredita que um sistema funciona assim:

Cliente

↓

Programa COBOL

↓

Banco de Dados

↓

Resposta

Simples.

Bonito.

Organizado.

Funciona perfeitamente...

até acontecer a primeira falha.

Imagine um banco.

São nove horas da manhã.

Milhares de pessoas fazem PIX.

Empresas pagam fornecedores.

Cartões de crédito autorizam compras.

Caixas eletrônicos funcionam.

Aplicativos móveis recebem milhões de acessos.

De repente...

A máquina que executa aquele programa simplesmente para.

Não trava.

Não fica lenta.

Ela desaparece.

Agora faça uma pergunta.

Quanto dinheiro um banco perde por minuto parado?

Algumas instituições estimam milhões de reais por hora.

Em bolsas de valores...

alguns segundos podem representar perdas gigantescas.

Foi por isso que nasceu um dos conceitos mais importantes da computação corporativa:

High Availability.


Capítulo II

Mordor Existe

No universo da fantasia existe Sauron.

No Mainframe existem as falhas.

Elas sempre existirão.

Não importa a qualidade do hardware.

Não importa quanto custa o servidor.

Tudo pode falhar.

Discos quebram.

Fontes queimam.

Cabos são desconectados.

Switches morrem.

Processadores apresentam defeitos.

LPARs reiniciam.

Operadores cometem erros.

Programadores também.

O objetivo nunca foi impedir isso.

O objetivo sempre foi impedir que o cliente perceba.

Essa mudança de mentalidade separa iniciantes dos arquitetos de sistemas.


Capítulo III

A Sociedade do Mainframe

Assim como Frodo jamais chegaria sozinho a Mordor, um ambiente CICS nunca depende de um único componente.

A Sociedade é formada por personagens extraordinários.

Frodo — O Programa COBOL

É quem realmente executa a missão.

Ele processa contas.

Calcula juros.

Autoriza cartões.

Move dinheiro.

Mas sozinho ele não sobreviveria.


Gandalf — O WLM

O Workload Manager é um verdadeiro mago.

Ele conhece toda a Terra Média do z/OS.

Sabe onde há CPU disponível.

Onde existe memória.

Onde há menos filas.

Onde o tempo de resposta está melhor.

Enquanto os usuários apenas enviam solicitações...

Gandalf decide para onde cada missão será enviada.

Sem ele...

o reino mergulharia no caos.


Aragorn — O CICS

O verdadeiro líder da batalha.

Cada Região CICS representa um comandante.

Ela recebe transações.

Executa programas.

Coordena recursos.

Mantém a ordem.

Mas, assim como Aragorn, nenhuma região governa sozinha.

Existem várias espalhadas pelo reino.


Legolas — O Monitoramento

Legolas enxerga longe.

Muito longe.

Ele percebe um problema antes dos outros.

O monitoramento faz exatamente isso.

Analisa:

  • CPU

  • Storage

  • SOS

  • Locks

  • SQL lento

  • Esperas

  • MQ

  • Threads

  • Tempo de resposta

Antes mesmo dos usuários reclamarem.


Gimli — O Hardware IBM Z

Robusto.

Pesado.

Quase indestrutível.

Mas nem Gimli é imortal.

Até o melhor hardware pode falhar.

Por isso existem outros anões prontos para assumir.


Sam — O Db2

Frodo jamais teria chegado ao fim sem Sam.

O COBOL também não.

O Db2 acompanha todas as transações.

Protege os dados.

Mantém consistência.

Recupera informações.

Suporta milhões de acessos simultâneos.


Capítulo IV

O Portal de Rivendell

Observe o caminho percorrido por uma simples transação.

Usuário

↓

Aplicativo

↓

Rede

↓

Load Balancer

↓

WLM

↓

Região CICS

↓

COBOL

↓

DB2

↓

Resposta

O usuário nunca conversa diretamente com o COBOL.

Há diversos guardiões protegendo o caminho.

Isso é proposital.

Cada camada adiciona inteligência.

Cada camada aumenta a disponibilidade.

Cada camada reduz riscos.


Capítulo V

O Conselho de Elrond

Imagine que existem quatro Regiões CICS.

CICSA

CICSB

CICSC

CICSD

Durante um dia comum...

todas trabalham juntas.

Cada uma atende milhares de usuários.

Agora imagine que CICSB falhou.

O que acontece?

Nada.

Ou melhor...

quase nada.

O WLM simplesmente deixa de enviar novas transações para ela.

As demais assumem a carga.

Os clientes continuam utilizando o sistema.

É exatamente como retirar Boromir da Sociedade.

A missão continua.


Capítulo VI

O Um Anel da Alta Disponibilidade

Existe um erro comum entre iniciantes.

Pensar que redundância significa desperdício.

Não.

Redundância significa sobrevivência.

Ter apenas uma região é barato.

Mas extremamente perigoso.

Ter quatro regiões parece mais caro.

Até o dia da primeira falha.

Nesse instante...

descobre-se que o investimento pagou décadas de tranquilidade.


Capítulo VII

O Caminho para Mordor

Toda transação percorre diversos desafios.

Primeiro o balanceamento.

Depois o processamento.

Depois acesso ao banco.

Depois gravação em logs.

Depois confirmação.

Se qualquer etapa falhar...

existem mecanismos de recuperação.

Algumas transações reiniciam.

Outras utilizam Syncpoint.

Outras fazem rollback.

Outras repetem a operação.

Tudo pensado para preservar integridade.


Capítulo VIII

O Olho de Sauron Nunca Dorme

Monitoramento contínuo.

Esse é um conceito que muitos desenvolvedores ignoram.

Eles imaginam que basta a região responder.

Mas responder não significa estar saudável.

Uma região pode:

  • consumir 100% da CPU;

  • estar sem armazenamento (SOS);

  • aguardar locks;

  • enfrentar lentidão no Db2;

  • acumular filas no MQ.

Ela ainda responde.

Mas lentamente.

O monitoramento detecta esses sinais antes que o usuário perceba.

Ferramentas como OMEGAMON, RMF, SMF, CICS Explorer e soluções de observabilidade modernas funcionam como os sentinelas de Gondor: vigiam continuamente o horizonte em busca de qualquer ameaça.


Capítulo IX

A Fortaleza Invisível: Shared Db2 e VSAM

Uma pergunta importante surge.

Se existem várias regiões...

como todas enxergam os mesmos dados?

A resposta está no compartilhamento.

O Db2, utilizando Data Sharing, permite que diferentes regiões CICS acessem o mesmo conjunto de informações com consistência.

O VSAM, quando configurado com Record Level Sharing (RLS), também possibilita acesso concorrente seguro.

Imagine uma conta bancária.

Saldo:

R$ 1.000

Se uma região enxergasse R$ 1.000 e outra R$ 950, o caos seria inevitável.

É por isso que a consistência dos dados é tão importante quanto a disponibilidade da aplicação.


Capítulo X

O Reino Além do Reino: Parallel Sysplex

Aqui chegamos ao verdadeiro ápice da engenharia IBM.

O Parallel Sysplex.

Imagine várias fortalezas espalhadas pela Terra Média.

Cada uma possui seus soldados.

Cada uma possui seus recursos.

Entretanto...

todas trabalham como se fossem uma única cidade.

É exatamente isso que acontece.

Diversos sistemas IBM Z compartilham recursos através do Coupling Facility, coordenando locks, caches e estruturas compartilhadas.

O resultado?

Escalabilidade quase linear.

Disponibilidade extraordinária.

Capacidade de crescimento contínuo.

É uma das arquiteturas mais elegantes já construídas na história da computação.


Capítulo XI

Alta Disponibilidade não é Disaster Recovery

Esse tema costuma aparecer em entrevistas técnicas.

E muitos candidatos confundem os conceitos.

High Availability (HA) trata de falhas locais.

Uma região caiu?

Outra assume.

Um processador apresentou defeito?

Outro continua executando.

Disaster Recovery (DR) lida com eventos muito maiores.

Incêndios.

Enchentes.

Falhas elétricas generalizadas.

Ataques físicos.

Perda completa de um Data Center.

Nesses casos, outro ambiente — muitas vezes localizado em outra cidade ou país — assume as operações.

Uma boa analogia é imaginar um castelo.

Se uma torre desmorona, os soldados continuam defendendo a fortaleza.

Isso é HA.

Mas se o castelo inteiro é destruído por um dragão...

é necessário recuar para outra fortaleza.

Isso é DR.


Curiosidades que Pouca Gente Conhece

🏰 Curiosidade 1

Grandes bancos frequentemente operam com dezenas de Regiões CICS simultaneamente.


🏰 Curiosidade 2

Alguns ambientes processam dezenas de milhares de transações por segundo.


🏰 Curiosidade 3

É comum realizar manutenção em hardware IBM Z sem desligar aplicações críticas.


🏰 Curiosidade 4

Muitos clientes nunca percebem que uma região inteira foi reiniciada durante o expediente.


🏰 Curiosidade 5

Grande parte da confiabilidade do Mainframe vem da combinação entre hardware, sistema operacional, middleware e processos operacionais — não de um único componente.


Passo a Passo para o Padawan COBOL Entender HA

Se você está começando agora, siga esta trilha de estudos:

  1. Aprenda a arquitetura básica do z/OS.

  2. Entenda o papel do CICS.

  3. Estude a diferença entre TOR, AOR e FOR.

  4. Aprenda como funciona o WLM.

  5. Conheça o Db2 Data Sharing.

  6. Estude VSAM RLS.

  7. Entenda Syncpoint e Commit.

  8. Aprenda conceitos de rollback e recuperação.

  9. Descubra como funciona o Parallel Sysplex.

  10. Explore ferramentas de monitoramento como RMF, SMF e OMEGAMON.

Essa sequência fará muito mais sentido do que tentar estudar todos os componentes isoladamente.


Easter Egg Bellacosa Mainframe ☕

Existe uma antiga lenda entre os Sysprogs.

Ela diz que, em algum lugar escondido dentro do Coupling Facility, existe um Palantír Digital.

Apenas os arquitetos mais experientes conseguem enxergar através dele o fluxo de todas as transações da Terra Média do Mainframe. Enquanto um programador iniciante vê apenas um programa COBOL executando um EXEC CICS LINK, o velho mago observa regiões inteiras assumindo cargas, WLM redistribuindo trabalho, Db2 sincronizando dados e o Sysplex mantendo o reino unido.

Dizem ainda que Gandalf jamais utilizou magia para derrotar Sauron.

Na verdade...

ele apenas configurou corretamente o WLM, distribuiu as transações entre múltiplas regiões CICS e deixou que a Alta Disponibilidade fizesse o restante.

Claro... nenhum manual da IBM confirma essa história.

Mas todo bom Sysprog sorri discretamente quando alguém menciona que "o sistema simplesmente não pode parar".


Conclusão

Assim como A Sociedade do Anel não era formada por heróis isolados, a Alta Disponibilidade em um ambiente CICS também é resultado da cooperação entre diversos componentes. O COBOL executa a lógica de negócio, o CICS coordena as transações, o WLM distribui inteligentemente a carga, o Db2 e o VSAM garantem a consistência dos dados, o monitoramento identifica problemas antes que eles afetem os usuários e o Parallel Sysplex transforma múltiplos sistemas em uma infraestrutura única e resiliente.

Para o programador COBOL iniciante, compreender esses conceitos representa uma mudança profunda de perspectiva. Você deixa de enxergar apenas linhas de código e passa a entender o ecossistema que mantém bancos, companhias aéreas, seguradoras, bolsas de valores e governos funcionando ininterruptamente.

No fim da jornada, a maior lição não é aprender a escrever um programa perfeito, mas compreender que, em computação corporativa, a verdadeira excelência está em construir sistemas capazes de continuar servindo milhões de pessoas mesmo quando partes da infraestrutura falham. Esse é o espírito do Mainframe: transformar redundância em confiança, engenharia em continuidade de negócios e tecnologia em um serviço tão confiável que a maioria das pessoas sequer percebe que ele existe.

Porque, como diria um velho mago da Terra Média adaptado ao universo IBM Z:

"Um grande sistema não é aquele que nunca enfrenta falhas. É aquele cuja missão continua, mesmo quando uma parte da Sociedade precisa ficar para trás."

domingo, 15 de março de 2020

☕💥 Fluxogramas no Mundo Mainframe

 

Bellacosa Mainframe e o fluxograma no mundo mainframe

☕💥 Fluxogramas no Mundo Mainframe

Ou como um Padawan COBOL descobre que antes do IF WS-SALDO > ZERO, existia um desenhinho que salvava projetos milionários

"Um programa COBOL sem fluxograma é como um JCL sem JOB CARD. Talvez execute. Talvez funcione. Mas ninguém vai entender daqui seis meses."

— Mestre Bellacosa Mainframe


Introdução

Uma das maiores diferenças entre um desenvolvedor COBOL júnior de hoje e um analista de sistemas da década de 1970, 1980 ou 1990 não está na linguagem.

Não está no z/OS.

Não está no DB2.

Não está no CICS.

Está na forma de pensar software.

Hoje aprendemos:

  • Fazer código

  • Testar

  • Commitar

  • Fazer Pull Request

Antigamente aprendíamos:

  • Analisar

  • Modelar

  • Desenhar

  • Revisar

  • Aprovar

  • Codificar

E neste mundo existia um personagem muito poderoso.

O Fluxograma.


O nascimento dos fluxogramas

A ideia é muito antiga.

Vem dos trabalhos de engenharia industrial.

Frank Gilbreth

Henry Gantt

Por volta de 1921 começaram a desenhar processos industriais.

Exemplo:

Receber matéria-prima

Produzir

Inspecionar

Embalar

Enviar

Décadas depois os computadores apareceram.

E alguém percebeu:

"Programas são processos."

Logo...

Processos industriais

viraram

Processos computacionais.


O modelo Waterfall

Se você trabalha em Mainframe bancário provavelmente ainda verá isso.

Waterfall.

As fases clássicas:

Requisitos

Análise

Fluxogramas

Especificação Técnica

Codificação

Teste

Implantação


Documentos clássicos do Waterfall

Documento Funcional

O que o sistema faz.

Exemplo:

Pagamento de boleto

Regra:

Se vencido

cobrar multa

Se pago em dia

valor normal


Documento Técnico

Como será implementado.

Exemplo:

Programa:

PAGBOL01

Tabela:

TB_BOLETO

Transação:

PB01

Copybooks

CPBOLETO


Fluxograma

É a ponte entre os dois.

Negócio

Fluxograma

COBOL


Bellacosa Mainframe e os simbolos de fluxograma

O que é um Fluxograma?

É uma representação gráfica de um algoritmo.

Ao invés de escrever:

IF SALDO > ZERO
   DISPLAY "OK"
ELSE
   DISPLAY "NEGADO"
END-IF

Desenhamos.

        ◇
SALDO > 0 ?
   /    \
 SIM    NÃO
 ↓       ↓
OK    NEGADO

Nosso cérebro entende imagens mais rapidamente.

Por isso funcionam.


Símbolos principais

Oval

Significado:

Início

Fim

Exemplo

 _______
(START )
 -------

ou

 _______
( END  )
 -------

Retângulo

Processamento.

Fazer algo.

Exemplo:

Calcular juros

Atualizar cadastro

Mover campos


Exemplo COBOL

COMPUTE JUROS =
SALDO * 0.05

Fluxograma

□ Calcular juros


Losango

Decisão.

Pergunta.

Tem duas saídas.

SIM

NÃO

Exemplo

Cliente VIP?


COBOL

IF CLIENTE-VIP='S'

Paralelogramo

Entrada e saída.

DISPLAY

ACCEPT

RECEIVE

SEND


Batch

Ler arquivo

Online

Receber PFKEY


Seta

Fluxo.

Indica sequência.

Sem seta.

Existe caos.

Com seta.

Existe entendimento.


Círculo

Conector.

Liga páginas.

Muito usado em especificações gigantes.

Página 1

○A

Página 10

○A

continuação


Bellacosa Mainframe e um fluxograma cobol batch

Fluxograma de Batch COBOL

Imagine:

Pagar folha salarial.


Desenho

START

Abrir arquivo

Ler funcionário

Fim Arquivo?

Sim

Gerar relatório

END

Não

Calcular salário

Gravar saída

Ler próximo


COBOL

OPEN INPUT FUNCIONARIO

PERFORM UNTIL EOF='S'

 READ FUNCIONARIO

   AT END
      MOVE 'S' TO EOF

   NOT AT END

      PERFORM CALCULA

      WRITE REG-SAIDA

 END-READ

END-PERFORM

Bellacosa Mainframe exemplo de fluxograma cobol vsam


Fluxograma para VSAM

Abrir KSDS

READ

FOUND?

SIM

UPDATE

REWRITE

NÃO

WRITE

END


Bellacosa Mainframe exemplo de fluxograma online cics

Fluxograma Online CICS

Exemplo.

Consulta saldo.


START

Receber tela

ENTER?

SIM

Validar conta

Conta existe?

SIM

Ler DB2

Enviar tela

NÃO

Mensagem erro

END


COBOL

EXEC CICS RECEIVE MAP


EXEC SQL

SELECT SALDO

INTO :WS-SALDO

FROM CONTA


END-EXEC


EXEC CICS SEND MAP


END-EXEC

Bellacosa Mainframe exemplo de fluxograma db2

Fluxograma com DB2

Exemplo.

Transferência bancária.


START

Receber origem

Receber destino

Valor válido?

SIM

BEGIN UNIT OF WORK

SELECT

UPDATE

UPDATE

COMMIT

NÃO

ROLLBACK

END


Fluxograma das tabelas DB2

Tabela

CLIENTE

Tabela

CONTA

Tabela

MOVIMENTO

Fluxo

CLIENTE

CONTA

MOVIMENTO


Exemplo SQL

SELECT
C.NOME,
M.VALOR

FROM CLIENTE C

JOIN CONTA CT

ON...

JOIN MOVIMENTO M

Fluxograma ajuda a enxergar joins.


Workflow

Muitos confundem.

Fluxograma

não é

Workflow

Mas workflow pode usar fluxograma.


Exemplo

Solicitação crédito

Cliente

Análise

Aprovação gerente

Compliance

Liberação


Hoje isso está em:

IBM BPM

Camunda

ServiceNow

Power Automate


Fluxos de diálogo

Muito usado em CICS.

Tela login

Senha válida?

Sim

Menu

Não

Mensagem erro


Chatbots fazem isso.

ChatGPT faz isso.

URA faz isso.

PIX faz isso.


Boas práticas

1 Não cruzar linhas

Errado

Linhas embaralhadas.

Causa dor psicológica.


2 Usar nomes claros

Errado

Processo 1

Correto

Calcular IOF


3 Uma decisão por vez

Evita confusão.


4 Modularizar

Subfluxos.

Exemplo

Pagamento

Calcular imposto

Fluxograma separado


Curiosidades

Easter Egg 1

COBOL nasceu em 1959.

Fluxogramas já eram padrão.


Easter Egg 2

Muitos programadores COBOL dos anos 80 codificavam olhando apenas para fluxogramas.

Nem tinham acesso ao usuário.


Easter Egg 3

Ferramentas CASE prometiam gerar COBOL automaticamente.

Excelerator

ADW

CoolGen

IEF

Pacbase

A ideia era:

Desenhar

Gerar programa

Compilar


Easter Egg 4

IBM usou fluxogramas extensivamente na documentação do OS/360.

Centenas de páginas.


Easter Egg 5

DFSORT pode ser representado perfeitamente por fluxograma.

INPUT

SORT

SUM

OUTREC

OUTPUT


Por que ainda usamos em Mainframe?

Porque sistemas bancários possuem:

Centenas de regras

Milhares de IFs

Milhões de contas

Um código COBOL pode ter:

30000 linhas

500 parágrafos

200 IFs

Ler isso é cansativo.

Ver um desenho leva segundos.


O Fluxograma como ferramenta de sobrevivência do Padawan COBOL

Imagine receber:

Programa:

FINA0345

38 mil linhas.

Criado em 1994.

Sem documentação.

Sem analista.

Sem usuário.

Sem autor.

Você abre.

Encontra:

PERFORM P1120

PERFORM P1130

PERFORM P1140

PERFORM P1150

O que fazem?

Ninguém sabe.

Mas após desenhar:

START

↓

Validar Cliente

↓

Consultar DB2

↓

Calcular Limite

↓

Atualizar Histórico

↓

Gerar Extrato

↓

END

Tudo fica claro.

É por isso que arquitetos, analistas de sistemas, especialistas em CICS, DB2, IMS, MQ, BPM e até equipes DevOps continuam utilizando fluxogramas.

Eles não substituem COBOL.

Não substituem UML.

Não substituem documentação funcional.

Mas fazem algo extremamente valioso: transformam milhares de linhas de código em uma história visual que qualquer pessoa consegue seguir.

E, no universo Bellacosa Mainframe, talvez esta seja a melhor definição possível:

Fluxograma é o mapa da dungeon. COBOL é a espada. DB2 é o tesouro. CICS é o portal de entrada. E o programador júnior que aprende a desenhar processos deixa de ser apenas um codificador e começa a pensar como um verdadeiro Analista de Sistemas do Reino IBM Z. ☕🚀

 

sábado, 14 de março de 2020

NEKOMATA (猫又) O Gato de Duas Caudas do Folclore Japonês

 

Bellacosa Mainframe e a lenda da Nekomata

NEKOMATA (猫又)

O Gato de Duas Caudas do Folclore Japonês

"Nas montanhas envoltas pela névoa do Japão antigo, existia o temor de que alguns gatos vivessem além do tempo natural. Quando envelheciam demais, algo mudava. Seus olhos tornavam-se mais inteligentes, seus movimentos mais humanos e suas caudas se dividiam em duas. Nesse momento, deixavam de ser simples animais para se tornar uma das criaturas mais temidas do folclore japonês: o Nekomata."


Introdução

Entre todos os yōkai (妖怪) do Japão, poucos despertam tanto fascínio quanto o Nekomata (猫又). Considerado um dos espíritos felinos mais poderosos da mitologia japonesa, ele representa a evolução sobrenatural de um gato comum que acumulou idade, experiência e energia espiritual suficiente para ultrapassar as fronteiras do mundo natural.

Ao longo dos séculos, histórias sobre Nekomatas foram registradas em livros, pinturas, lendas populares e peças teatrais. Essas criaturas eram descritas como seres inteligentes, capazes de falar, controlar os mortos, lançar maldições e assumir forma humana.

O Nekomata tornou-se uma figura tão influente que continua presente em animes, mangás, videogames e obras modernas de fantasia, sendo um dos maiores símbolos do imaginário sobrenatural japonês.


Origem do Nome

A palavra Nekomata (猫又) é composta por:

  • 猫 (Neko) = gato

  • 又 (Mata) = bifurcação, divisão

O significado mais aceito é:

"Gato de Cauda Dividida"

A característica principal do Nekomata é justamente possuir duas caudas, resultado de uma transformação sobrenatural.


Classificação Mitológica

Categoria:

  • Yōkai (妖怪)

Subcategoria:

  • Kaibyō (怪猫)

  • Espírito Felino

Natureza:

  • Sobrenatural

  • Metamórfico

  • Espiritual

Habitat tradicional:

  • Montanhas

  • Florestas antigas

  • Templos abandonados

  • Vilarejos isolados

Origem:

  • Japão Medieval


A Evolução do Gato Comum

Segundo as crenças populares japonesas, qualquer gato poderia se transformar em um Nekomata.

Essa transformação ocorreria quando o animal:

  • Alcançasse idade avançada

  • Acumulasse energia espiritual

  • Desenvolvesse inteligência incomum

  • Permanecesse muito tempo entre humanos

Diversas regiões afirmavam que um gato precisava viver:

  • 13 anos

  • 20 anos

  • 30 anos

para iniciar sua metamorfose.


A Importância da Cauda

Os japoneses antigos acreditavam que a cauda era um canal de energia espiritual.

Quanto maior fosse a cauda:

  • Maior seria o poder acumulado.

  • Maior seria o risco da transformação.

Por isso, algumas famílias cortavam parcialmente a cauda de seus gatos para evitar que se tornassem Nekomatas.

Muitos estudiosos acreditam que essa superstição ajudou a popularizar o Bobtail Japonês, raça naturalmente conhecida pela cauda curta.


Os Dois Tipos de Nekomata

Ao longo da história, surgiram duas versões distintas da criatura.


Nekomata das Montanhas

Conhecido como:

Sankai Nekomata

Vivia em:

  • Florestas profundas

  • Regiões montanhosas

  • Áreas isoladas

Características:

  • Gigantesco

  • Selvagem

  • Extremamente agressivo

Relatos descrevem criaturas do tamanho de tigres.


Nekomata Doméstico

Conhecido como:

Kaineko

Era originalmente um gato de estimação.

Após décadas vivendo com humanos:

  • Desenvolvia inteligência sobrenatural

  • Aprendia a falar

  • Passava a andar sobre duas patas

Esse é o Nekomata mais presente nas lendas urbanas.


Aparência

A descrição varia conforme a região.

As características mais comuns incluem:

  • Duas caudas

  • Olhos brilhantes

  • Pelagem escura

  • Presença intimidadora

Em algumas histórias:

  • Possui tamanho humano

  • Usa roupas tradicionais

  • Caminha como uma pessoa


Poderes Sobrenaturais

O Nekomata é considerado mais poderoso que o Bakeneko.


Necromancia

Seu poder mais famoso.

Ele pode:

  • Reanimar cadáveres

  • Controlar mortos

  • Manipular espíritos

Por isso era associado aos cemitérios.


Metamorfose

Pode assumir a forma de:

  • Homens

  • Mulheres

  • Monges

  • Nobres

Muitas histórias narram encontros com desconhecidos que depois revelavam ser Nekomatas.


Controle de Fogo Fantasma

O Nekomata pode produzir:

  • Chamas azuis

  • Fogo espiritual

  • Luzes sobrenaturais

Essas manifestações eram vistas como presságios.


Manipulação Mental

Algumas lendas afirmam que ele pode:

  • Criar ilusões

  • Alterar percepções

  • Confundir viajantes


Comunicação com os Mortos

Diferentemente de outros yōkai, o Nekomata teria acesso ao mundo espiritual.

Ele seria capaz de:

  • Conversar com fantasmas

  • Invocar espíritos

  • Obter conhecimento oculto


Inteligência Superior

As lendas frequentemente descrevem o Nekomata como:

  • Astuto

  • Paciente

  • Estratégico

Ao contrário de monstros impulsivos, ele planeja suas ações cuidadosamente.


A Lenda da Velha Montanha

Uma das histórias mais conhecidas conta que um caçador encontrou uma aldeia abandonada.

Ao entrar:

  • As casas estavam intactas.

  • Nenhum corpo foi encontrado.

  • Apenas pegadas de gatos gigantes permaneciam.

Dias depois, moradores da região afirmaram ouvir vozes humanas vindas da floresta.

Quando investigaram, descobriram que eram Nekomatas imitando pessoas desaparecidas.

A lenda tornou-se uma das mais famosas histórias de terror rural do Japão.


O Nekomata e os Mortos

Em diversas regiões japonesas, acreditava-se que gatos não deveriam ficar próximos de cadáveres.

O motivo era simples:

Temia-se que um Nekomata:

  • Possuísse o corpo.

  • O reanimasse.

  • O transformasse em um servo.

Essa superstição influenciou práticas funerárias durante séculos.


Locais de Culto

O Nekomata não possui um culto oficial como os kami do xintoísmo.

Porém existem locais associados às suas lendas.


Montanhas da Prefeitura de Fukushima

Algumas histórias antigas situam Nekomatas gigantes nessa região.


Região de Tohoku

Diversas aldeias preservam contos sobre gatos sobrenaturais.


Templos Felinos

Alguns templos dedicados a gatos homenageiam o papel espiritual desses animais no folclore japonês.


Relação com o Xintoísmo

Embora não seja um kami, o Nekomata é frequentemente associado à crença de que todos os seres vivos possuem energia espiritual.

Essa visão permitiu que gatos fossem vistos como potenciais entidades sobrenaturais.


Simbolismo

O Nekomata simboliza:

O Poder da Idade

A sabedoria acumulada ao longo do tempo.


A Dualidade

Representada pelas duas caudas.

Vida e morte.

Humano e animal.

Mundo físico e espiritual.


O Desconhecido

A natureza misteriosa dos gatos.


Curiosidades

Alguns Nekomatas Eram Benevolentes

Nem todas as histórias os retratam como monstros.

Alguns:

  • Protegiam famílias

  • Afugentavam espíritos malignos

  • Guardavam templos


Eles Gostavam de Música

Diversas lendas afirmam que Nekomatas:

  • Tocavam shamisen

  • Cantavam

  • Dançavam

durante a noite.


Podiam Formar Comunidades

Alguns contos descrevem aldeias inteiras habitadas por Nekomatas.


Eram Temidos por Samurai

Relatos do Período Edo mostram guerreiros evitando certas montanhas consideradas território dessas criaturas.


Nekomata na Arte Japonesa

Durante os séculos XVII e XVIII, artistas criaram inúmeras gravuras mostrando:

  • Gatos dançando

  • Gatos usando quimonos

  • Gatos tocando instrumentos

Essas imagens ajudaram a popularizar o mito.


Nekomata nos Animes


Mononoke

Lançamento:

2007

Um dos animes mais famosos envolvendo espíritos felinos e yōkai.


GeGeGe no Kitarō

Primeira versão:

1968

Inclui diversos espíritos felinos inspirados em Nekomatas.


Natsume Yuujinchou

2008

Apresenta vários yōkai relacionados ao folclore dos gatos.


Nurarihyon no Mago

2010

Possui personagens inspirados diretamente em Nekomatas.


InuYasha

2000

Inclui referências a espíritos felinos e entidades semelhantes.


The Morose Mononokean

2016

Explora criaturas do folclore japonês.


Kakuriyo no Yadomeshi

2018

Apresenta seres sobrenaturais ligados às tradições japonesas.


Yokai Watch

2014

Popularizou diversos yōkai para uma nova geração.


Nekomata nos Mangás

A criatura aparece frequentemente em:

  • xxxHolic

  • Nura: Rise of the Yokai Clan

  • GeGeGe no Kitarō

  • Touhou

  • InuYasha


Nekomata nos Videogames

Nioh

2017

Possui referências a vários yōkai clássicos.


Nioh 2

2020

Expande significativamente a presença de espíritos felinos.


Shin Megami Tensei

Diversas versões incluem Nekomatas.

Primeiro jogo:

1992


Persona

A série utiliza criaturas derivadas do folclore japonês.


Yokai Watch

2013

Inclui versões inspiradas no Nekomata.


Como Identificar um Nekomata Segundo as Lendas

Os antigos japoneses acreditavam que um gato poderia estar se tornando um Nekomata se:

  • Ficasse excessivamente inteligente.

  • Observasse pessoas por horas.

  • Demonstrasse hábitos humanos.

  • Caminhasse sobre duas patas.

  • Produzisse sons semelhantes à fala.


Dicas para Estudiosos do Folclore Japonês

Estude os Yōkai Clássicos

O Nekomata faz parte de um sistema muito maior de entidades sobrenaturais.


Analise as Diferenças Regionais

Cada província desenvolveu versões próprias da lenda.


Compare com o Bakeneko

Entender um ajuda a compreender o outro.


Pesquise o Período Edo

Grande parte das narrativas surgiu nessa época.


Comparação entre Bakeneko e Nekomata

CaracterísticaBakenekoNekomata
CaudaUmaDuas
PoderAltoMuito Alto
NecromanciaOcasionalFrequente
TransformaçãoSimSim
InteligênciaElevadaExtremamente Elevada
PerigoVariávelMaior

Comentários Finais

O Nekomata é muito mais do que um simples gato monstruoso. Ele representa um dos aspectos mais fascinantes da cultura japonesa: a crença de que tudo possui espírito e que o tempo pode transformar qualquer ser em algo extraordinário.

Durante séculos, aldeões temeram encontrar um Nekomata nas montanhas. Samurai evitavam determinadas regiões por medo de suas maldições. Monges registravam histórias sobre gatos capazes de falar e controlar os mortos.

Hoje, embora a criatura pertença ao campo da mitologia, ela continua viva na imaginação popular. Sua imagem aparece em animes, jogos, mangás e filmes, atravessando gerações sem perder o encanto.

Talvez o segredo de sua longevidade esteja justamente na natureza dos gatos. Eles permanecem misteriosos, silenciosos e observadores. Agem como se compreendessem algo que os humanos jamais poderão saber.

E, segundo o folclore japonês, alguns realmente compreendem.

Quando um gato vive tempo suficiente para atravessar os limites da existência comum, dividir sua cauda em duas e enxergar o mundo dos espíritos, ele deixa de ser apenas um animal.

Ele se torna uma lenda.

Ele se torna o Nekomata (猫又). 🐈‍⬛🌙👁️🐾


sexta-feira, 13 de março de 2020

☕💣 APIs RESTful: O Dia em Que os Sistemas Descobriram Como Conversar Sem Trocar JCL

Bellacosa Mainframe introdução a API RestFul


☕💣 APIs RESTful: O Dia em Que os Sistemas Descobriram Como Conversar Sem Trocar JCL

Imagine a seguinte situação.

Você está em um banco em 1985. Um programa COBOL executando em um IBM Mainframe processa milhões de transações diariamente. Tudo funciona perfeitamente.

Agora avance para 2026.

O mesmo banco continua utilizando COBOL, CICS, DB2 e z/OS para movimentar bilhões de dólares todos os dias. Porém, existe um detalhe importante: os clientes não acessam mais o sistema através de terminais 3270.

Eles utilizam aplicativos móveis, internet banking, chatbots, APIs, inteligência artificial e até relógios inteligentes.

A pergunta é:

Como um aplicativo moderno conversa com um sistema desenvolvido há décadas?

A resposta, em grande parte dos casos, está em uma tecnologia chamada API RESTful.

Hoje vamos conhecer sua história, origem, criador, funcionamento, curiosidades e entender por que ela se tornou uma das tecnologias mais importantes da computação moderna.


O Que é uma API?

API significa:

Application Programming Interface

ou

Interface de Programação de Aplicações.

Uma API é um conjunto de regras que permite que dois sistemas conversem entre si.

Pense nela como um atendente de restaurante.

Você não entra na cozinha para preparar sua comida.

Você faz um pedido ao garçom.

O garçom leva o pedido.

A cozinha processa.

O garçom retorna o resultado.

A API faz exatamente isso.

Ela recebe solicitações.

Encaminha para o sistema responsável.

Obtém uma resposta.

Entrega o resultado ao solicitante.


O Que Significa REST?

REST significa:

Representational State Transfer

O termo surgiu oficialmente em:

Ano: 2000

Criado por:

Roy Thomas Fielding

Durante sua tese de doutorado na Universidade da Califórnia (UC Irvine).

O trabalho recebeu o nome:

Architectural Styles and the Design of Network-based Software Architectures

Nele, Fielding descreveu um conjunto de princípios para criar sistemas distribuídos mais simples, escaláveis e independentes.

Curiosamente, REST não é uma tecnologia.

Não é um produto.

Não é um software.

Não é um protocolo.

É um estilo arquitetural.


Quem é Roy Fielding?

Roy Fielding é uma das figuras mais importantes da história da Internet.

Além de criar o conceito REST, ele também participou da especificação de tecnologias fundamentais da Web.

Entre elas:

  • HTTP 1.0

  • HTTP 1.1

  • URI

  • Apache HTTP Server

Sim.

O mesmo protocolo HTTP que usamos diariamente para acessar sites recebeu contribuições diretas do criador do REST.

Poucas pessoas sabem disso.


Data de Criação

O conceito REST foi publicado oficialmente em:

2000

Portanto, em 2026, o REST possui:

26 anos de existência

Mesmo assim continua sendo a arquitetura dominante para integração de sistemas.

Algo raro em tecnologia.


Existe uma Versão do REST?

Não.

Esse é um detalhe interessante.

REST não possui:

  • Release 1

  • Release 2

  • Versão 10

REST é apenas um conjunto de princípios arquiteturais.

O que evolui são as tecnologias utilizadas ao seu redor:

  • HTTP

  • JSON

  • XML

  • OpenAPI

  • Swagger

  • OAuth

  • JWT

Por isso não existe algo como:

"REST versão 3.0"


Como Funciona uma API RESTful?

Uma API RESTful utiliza recursos identificados por URLs.

Exemplos:

/clientes
/contas
/cartoes
/emprestimos

Cada URL representa um recurso.

O cliente realiza operações utilizando métodos HTTP.


Os Principais Métodos HTTP

GET

Utilizado para consultar informações.

Exemplo:

GET /clientes/1001

Resposta:

{
  "codigo":1001,
  "nome":"João Silva"
}

POST

Utilizado para criar registros.

Exemplo:

POST /clientes

PUT

Atualiza um recurso existente.

Exemplo:

PUT /clientes/1001

DELETE

Remove um recurso.

Exemplo:

DELETE /clientes/1001

Uma Analogia Mainframe

Imagine um sistema CICS.

No passado, um terminal 3270 enviava uma transação.

Hoje um aplicativo celular faz uma chamada REST.

Fluxo:

App Mobile
      |
      v
API REST
      |
      v
CICS
      |
      v
COBOL
      |
      v
DB2

Para o programa COBOL, pouco muda.

Ele continua processando regras de negócio.

A diferença está na forma de acesso.


Por Que REST Ficou Tão Popular?

Antes do REST, muitas integrações utilizavam:

  • RPC

  • CORBA

  • DCOM

  • SOAP

Essas tecnologias eram poderosas, porém complexas.

REST trouxe:

  • Simplicidade

  • Escalabilidade

  • Facilidade de implementação

  • Menor consumo de recursos

O resultado foi uma adoção massiva.


O Papel do JSON

Embora REST não exija JSON, ambos praticamente cresceram juntos.

JSON significa:

JavaScript Object Notation

Exemplo:

{
  "conta":"12345",
  "saldo":1500.75
}

Comparado ao XML:

<conta>
   <numero>12345</numero>
   <saldo>1500.75</saldo>
</conta>

JSON é menor, mais simples e mais rápido de processar.

Por isso tornou-se o padrão de mercado.


Características Obrigatórias do REST

Roy Fielding definiu restrições importantes.


Cliente-Servidor

Cliente e servidor são independentes.

O aplicativo não precisa conhecer detalhes internos do sistema.


Stateless

Cada requisição deve conter todas as informações necessárias.

O servidor não depende de estados anteriores.

Essa característica facilita escalabilidade.


Cache

Respostas podem ser armazenadas temporariamente.

Isso reduz processamento e tráfego.


Interface Uniforme

Todas as APIs seguem padrões semelhantes.

Isso facilita aprendizado e manutenção.


Sistema em Camadas

O cliente não sabe quantos componentes existem entre ele e o servidor.

Pode haver:

  • Firewalls

  • Gateways

  • Balanceadores

  • Proxies

Tudo permanece transparente.


REST e o Mundo Mainframe

Muitos profissionais acreditam que REST e Mainframe são mundos diferentes.

Nada poderia estar mais distante da realidade.

Hoje encontramos APIs REST acessando:

  • COBOL

  • PL/I

  • Natural

  • CICS

  • IMS

  • DB2

  • VSAM

Praticamente todos os grandes bancos utilizam essa arquitetura.


Exemplo Real

Imagine um aplicativo bancário.

Quando o cliente consulta saldo:

GET /contas/123456/saldo

A API recebe a solicitação.

Ela chama um serviço no CICS.

O CICS executa um programa COBOL.

O COBOL consulta DB2.

O resultado retorna em JSON.

O cliente vê o saldo instantaneamente.

Tudo em poucos milissegundos.


REST no z/OS

Atualmente existem diversas tecnologias IBM para expor aplicações como APIs.

Entre elas:

  • z/OS Connect

  • CICS Web Services

  • CICS REST APIs

  • IBM API Connect

  • IMS Connect

  • MQ REST Gateway

Essas ferramentas transformam aplicações legadas em serviços modernos.


Curiosidade Histórica

Muitos dos sistemas considerados "modernos" dependem diretamente de aplicações desenvolvidas há décadas.

Quando você:

  • Faz um PIX

  • Passa cartão

  • Compra passagem aérea

  • Faz saque bancário

Existe uma grande chance de um programa COBOL estar envolvido.

E frequentemente o acesso ocorre através de APIs REST.


REST vs SOAP

Uma comparação clássica.

RESTSOAP
SimplesComplexo
LevePesado
JSONXML
Fácil adoçãoConfiguração extensa
Mais popular atualmenteMuito usado em legado corporativo

Apesar disso, SOAP continua presente em diversos ambientes bancários.


Segurança em APIs REST

Uma API aberta seria extremamente perigosa.

Por isso existem mecanismos de proteção.

Os principais:

  • HTTPS

  • OAuth 2.0

  • JWT

  • API Keys

  • OpenID Connect

Eles garantem:

  • Autenticação

  • Autorização

  • Criptografia

  • Auditoria


REST e a Era da Inteligência Artificial

A explosão da IA aumentou ainda mais a importância das APIs.

Quando um chatbot consulta informações de um sistema corporativo, normalmente utiliza APIs.

Quando um assistente virtual consulta saldo bancário, utiliza APIs.

Quando aplicações integram modelos de IA com sistemas empresariais, utilizam APIs.

REST tornou-se o idioma universal da integração digital.


O Futuro do REST

Novas tecnologias surgiram.

Entre elas:

  • GraphQL

  • gRPC

  • AsyncAPI

Mesmo assim, REST continua dominante.

O motivo é simples.

Bilhões de aplicações já utilizam esse modelo.

Sua simplicidade continua sendo sua maior vantagem.


Conclusão

APIs RESTful representam uma das maiores revoluções silenciosas da computação moderna.

Criadas por Roy Fielding em 2000, elas permitiram que sistemas de diferentes gerações passassem a conversar de maneira simples, eficiente e padronizada.

Graças ao REST, aplicativos móveis conseguem acessar programas COBOL.

Plataformas de IA conseguem consultar sistemas bancários.

Empresas integram milhares de aplicações diariamente.

E o mais curioso:

Enquanto muita gente acredita que o Mainframe ficou preso ao passado, ele continua movimentando a economia mundial utilizando tecnologias modernas de integração.

Afinal, por trás de muitos aplicativos considerados revolucionários existe algo extremamente familiar para nós, mainframeiros:

um programa COBOL processando regras de negócio com a mesma confiabilidade de décadas atrás.

A diferença é que agora ele conversa com o mundo através de APIs RESTful.

☕💣 Moral da história: REST não substituiu o Mainframe. Pelo contrário. Tornou-se uma das principais pontes que conectam a robustez do COBOL, CICS e DB2 ao universo de aplicativos, nuvem, microsserviços e inteligência artificial. 

quinta-feira, 12 de março de 2020

☕🔥 ANIMES QUE QUEBRAM A REALIDADE — PSICOLOGIA, IDENTIDADE E COLAPSO EXISTENCIAL

 

Bellacosa Mainframe e animes que quebram a realidade

☕🔥 ANIMES QUE QUEBRAM A REALIDADE — PSICOLOGIA, IDENTIDADE E COLAPSO EXISTENCIAL

Este post reúne alguns dos animes mais intelectuais, simbólicos e psicologicamente complexos já produzidos no Japão.

Essas obras não foram feitas para:

  • consumo rápido,

  • ação simples,

  • entretenimento casual.

São animes que operam como:

“debuggers da mente humana”.

Eles desmontam:

  • identidade,

  • memória,

  • ego,

  • percepção,

  • realidade,

  • trauma,

  • e consciência.

Muitos espectadores terminam essas obras com sensação de:

  • confusão,

  • fascínio,

  • desconforto,

  • crise existencial.

E isso é INTENCIONAL.


01 — THE TATAMI GALAXY

Título original

四畳半神話大系
(Yojouhan Shinwa Taikei)

Studio

  • Madhouse

Autor

  • Tomihiko Morimi

Lançamento

  • 2010

Diretor

  • Masaaki Yuasa

Gênero

  • Psicológico

  • Comédia existencial

  • Romance

  • Surrealismo

Classificação

  • +14


O ANIME DA PARALISIA EXISTENCIAL


Sinopse

Um estudante universitário revive diferentes versões de sua vida tentando encontrar o “campus perfeito”.


Temática

  • arrependimento,

  • ansiedade social,

  • possibilidades infinitas,

  • procrastinação,

  • vazio existencial.


O diferencial

A narrativa funciona como:

  • loops mentais,

  • realidades paralelas,

  • simulações emocionais.

Parece literalmente:

um sistema entrando em recursion infinita.


Personagens

Watashi

Representa o jovem perdido na própria indecisão.

Ozu

O “caos” personificado.


O que torna especial?

A direção de Masaaki Yuasa quebra TODAS as convenções visuais tradicionais.


02 — PERFECT BLUE

Título original

パーフェクトブルー

Studio

  • Madhouse

Autor

  • Yoshikazu Takeuchi

Diretor

  • Satoshi Kon

Lançamento

  • 1997

Gênero

  • Thriller psicológico

  • Horror psicológico

Classificação

  • +18


O ANIME QUE HOLLYWOOD “COPIOU”


Sinopse

Uma idol abandona a carreira musical para virar atriz, mas começa a perder a percepção entre realidade e delírio.


Temática

  • obsessão,

  • fama,

  • sexualização,

  • dissociação,

  • colapso psicológico.


O diferencial

Perfect Blue destrói a linha entre:

  • sonho,

  • realidade,

  • memória,

  • paranoia.


Influência cultural

Inspirou:

  • Black Swan,

  • Requiem for a Dream,

  • inúmeros thrillers psicológicos modernos.


03 — PAPRIKA

Título original

パプリカ

Studio

  • Madhouse

Autor

  • Yasutaka Tsutsui

Diretor

  • Satoshi Kon

Lançamento

  • 2006

Gênero

  • Sci-Fi

  • Psicológico

  • Surrealismo

Classificação

  • +16


O “INCEPTION” ANTES DE INCEPTION


Sinopse

Uma tecnologia permite entrar nos sonhos das pessoas.

Quando ela é roubada, realidade e sonho começam a colapsar.


Temática

  • subconsciente,

  • identidade,

  • desejo,

  • escapismo,

  • sonhos.


O diferencial

Paprika parece:

  • um sonho lúcido,

  • um delírio visual,

  • uma pane cognitiva coletiva.


Visualmente

É uma das animações mais criativas já feitas.


04 — ID: INVADED

Título original

イド:インヴェイデッド

Studio

  • NAZ

Lançamento

  • 2020

Gênero

  • Investigação

  • Sci-Fi

  • Psicológico

Classificação

  • +16


CSI CYBERPUNK EXISTENCIAL


Sinopse

Detetives entram no subconsciente fragmentado de serial killers para resolver crimes.


Temática

  • trauma,

  • psicopatia,

  • memória,

  • fragmentação mental.


O diferencial

Cada mente investigada vira:

  • um mundo abstrato,

  • um “database psicológico”.


05 — SCHOOL-LIVE!

Título original

がっこうぐらし!

Studio

  • Lerche

Lançamento

  • 2015

Gênero

  • Slice of Life

  • Horror psicológico

  • Pós-apocalipse

Classificação

  • +16


O MAIOR “CHOQUE NARRATIVO” DOS ANIMES


Sinopse

Garotas vivem normalmente na escola…

ou pelo menos é isso que uma delas acredita.


O diferencial

Mistura:

  • moe,

  • fofura,

  • trauma,

  • negação psicológica,

  • horror.


Temática

  • PTSD,

  • dissociação,

  • negação emocional,

  • sobrevivência psicológica.


06 — PENGUINDRUM

Título original

輪るピングドラム

Studio

  • Brain’s Base

Diretor

  • Kunihiko Ikuhara

Lançamento

  • 2011

Gênero

  • Drama psicológico

  • Surrealismo

  • Mistério

Classificação

  • +16


O ANIME MAIS SIMBÓLICO DA LISTA


Sinopse

Dois irmãos tentam salvar a irmã usando um objeto misterioso chamado Penguindrum.


Temática

  • destino,

  • terrorismo,

  • família,

  • trauma coletivo,

  • sacrifício.


O diferencial

Tudo é metáfora.

TUDO.


07 — BOOGIEPOP PHANTOM

Título original

ブギーポップは笑わない

Studio

  • Madhouse

Lançamento

  • 2000

Gênero

  • Horror psicológico

  • Sobrenatural

  • Mistério

Classificação

  • +17


O ANIME QUE DEFINIU O “URBAN PSYCHO HORROR”


Sinopse

Eventos sobrenaturais conectam estudantes traumatizados.


Temática

  • isolamento,

  • medo,

  • adolescência,

  • identidade fragmentada.


O diferencial

Narrativa extremamente não linear.


08 — ERGO PROXY

Studio

  • Manglobe

Lançamento

  • 2006

Gênero

  • Cyberpunk

  • Filosofia

  • Sci-Fi

Classificação

  • +17


O ANIME MAIS FILOSÓFICO DA LISTA


Sinopse

Em um mundo pós-apocalíptico, humanos coexistem com androides enquanto entidades chamadas Proxies ameaçam a realidade.


Temática

  • existencialismo,

  • consciência,

  • identidade,

  • humanidade artificial.


Influências

  • Descartes,

  • Nietzsche,

  • Freud,

  • cyberpunk clássico.


O diferencial

É praticamente:

Blade Runner + Serial Experiments Lain + filosofia continental.


09 — TEXHNOLYZE

Studio

  • Madhouse

Lançamento

  • 2003

Gênero

  • Cyberpunk

  • Experimental

  • Psicológico

Classificação

  • +18


O ANIME MAIS SOMBRIO DESSA LISTA


Sinopse

Em uma cidade subterrânea decadente, humanos modificados tecnologicamente vivem em colapso social absoluto.


Temática

  • niilismo,

  • decadência,

  • transumanismo,

  • vazio existencial.


O diferencial

Texhnolyze parece:

  • morto,

  • silencioso,

  • desesperançoso.

Quase não existem diálogos no início.

O anime quer que você:

  • sinta desconforto,

  • vazio,

  • decadência.


☕🔥 CONCLUSÃO — O QUE UNE TODAS ESSAS OBRAS?

Esses animes exploram a ideia de que:

a mente humana é mais assustadora que qualquer monstro.

Todos abordam:

  • colapso da identidade,

  • realidade fragmentada,

  • trauma,

  • alienação,

  • hiperestimulação moderna,

  • medo existencial.

São obras que exigem:

  • atenção,

  • interpretação,

  • maturidade emocional.

No estilo Bellacosa Mainframe:
esses animes funcionam como sistemas críticos operando além do limite seguro.

Quando:

  • memória corrompe,

  • processos entram em loop,

  • identidade perde integridade,

  • percepção falha…

…o resultado não é apenas erro de sistema.

É o colapso completo da consciência humana.

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