Translate

quinta-feira, 9 de dezembro de 2010

🜂 A Roupa Nova do Rei

 

Bellacosa Mainframe e a fabula o Rei vai Nu

🜂 A Roupa Nova do Rei

Quando a ilusão entra em produção, ninguém dá o ABEND e o sistema segue… até a criança apertar ENTER
Para mainframers que gostam de anime, metáforas, sistemas legados e verdades que ninguém quer logar


1️⃣ IPL cultural: por que esse conto ainda roda em produção?

Todo mainframer raiz já viu isso acontecer:
um sistema claramente errado, cheio de gambiarra, documentação inexistente, ninguém entende direito… mas todo mundo finge que está funcionando.

A história da Roupa Nova do Rei é exatamente isso.
Um batch cultural rodando há séculos, sem manutenção, sem revisão de código, mas perfeitamente compatível com a natureza humana.

Ela fala de vaidade, medo, conformismo, hierarquia, status…
e principalmente de um bug clássico:

ninguém quer ser o primeiro a dizer que o rei está pelado.


2️⃣ Origem: quem compilou essa história?

A versão mais famosa do conto foi publicada em 1837, pelo escritor dinamarquês Hans Christian Andersen, no livro Eventyr, fortalte for Børn (Contos contados para crianças).

📜 Primeira publicação conhecida:
➡️ “Kejserens nye Klæder” (em dinamarquês)

Mas atenção, padawan…

🧠 Easter egg histórico:

Andersen não inventou a história do zero.
Ela é baseada em contos muito mais antigos, especialmente um conto espanhol do século XIII, presente no livro:

📖 El Conde Lucanor, de Don Juan Manuel (c. 1335)

Nesse conto antigo, três vigaristas prometem fazer um pano invisível para quem não fosse filho legítimo.
Ou seja: a lógica do medo social já estava lá, só mudaram os parâmetros do IF.


3️⃣ O enredo resumido (ou: o sistema que ninguém quer testar)

O rei é obcecado por roupas.
Não governa. Não cuida do povo.
Só quer status, aparência, reconhecimento.

Dois vigaristas aparecem oferecendo uma roupa mágica:

✨ “Ela só pode ser vista por pessoas inteligentes e dignas do cargo que ocupam.”

📌 Tradução mainframe:

IF USER NOT SEE CLOTHES
   THEN USER = BURRO OR INCOMPETENTE

Resultado:

  • O rei não vê nada → finge que vê

  • Os ministros não veem nada → fingem que veem

  • O povo não vê nada → aplaude

Até que…

👶 uma criança, sem medo de RACF social, diz:

“O rei está pelado!”

ABEND imediato do sistema.


4️⃣ O bug não é a roupa — é o medo

O ponto genial do conto não é a nudez do rei.
É o medo coletivo de contrariar o consenso.

No mundo mainframe, isso é clássico:

  • “Esse sistema é crítico, ninguém mexe”

  • “Sempre foi assim”

  • “Não documenta porque funciona”

  • “Não pergunta, só roda o batch”

No anime, isso aparece o tempo todo:

🎌 Exemplos de paralelos em anime

  • Neon Genesis Evangelion: adultos fingindo controle enquanto tudo desmorona

  • Attack on Titan: verdades ocultas sustentadas por consenso

  • One Piece: reis, governos e símbolos vazios mantidos pelo medo

  • Akira: poder sem responsabilidade


5️⃣ Easter eggs e curiosidades culturais

🥚 Easter egg #1 — A criança não é inocente, é livre

A criança não fala porque é “pura”.
Ela fala porque não está presa ao sistema.

Não depende:

  • do cargo

  • da hierarquia

  • da aprovação

É o estagiário que pergunta:

“Mas por que isso é assim?”

E todo mundo fica desconfortável.


🥚 Easter egg #2 — O rei sabe que está pelado

Muita gente acha que o rei é enganado.
Errado.

Ele sabe que não vê nada.
Mas escolhe seguir.

Isso é mais assustador.


🥚 Easter egg #3 — O desfile é produção

O rei não testa em homologação.
Ele vai direto pra produção.

Clássico.


6️⃣ Por que essa história dialoga tanto com mainframers?

Porque mainframe é:

  • legado

  • hierarquia

  • respeito

  • estabilidade

  • medo de quebrar

E isso é bom… até virar silêncio tóxico.

Quantos sistemas continuam rodando porque:

  • ninguém quer ser o chato

  • ninguém quer assumir o risco

  • ninguém quer dizer “isso não faz sentido”


7️⃣ A Roupa Nova do Rei no mundo dos animes

O Japão adora essa metáfora.

🎌 Em animes, ela aparece como:

  • líderes cegos pela própria imagem

  • sistemas falsamente perfeitos

  • tradições vazias

  • poderes simbólicos

Exemplo clássico:

  • Conselhos que ninguém questiona

  • Vilas que seguem regras absurdas

  • Mestres que ninguém ousa confrontar

O herói geralmente é:
➡️ o “idiota”
➡️ o “ingênuo”
➡️ o “fora do sistema”

A criança do conto é um protagonista de shonen sem saber.


8️⃣ A lição que ninguém gosta de ouvir

A história não ensina:

“Não seja vaidoso”

Ela ensina:

“Não silencie a verdade por medo de parecer incompetente.”

No mundo corporativo:

  • muita gente vê o problema

  • pouca gente fala

  • e quando fala… já é tarde


9️⃣ Bellacosa Mainframe Moment™ 🖥️

Se esse conto fosse um sistema:

  • A roupa é um software inexistente

  • O rei é o sponsor

  • Os ministros são os gestores

  • O povo é o usuário final

  • A criança é o operador experiente

A diferença?

O operador não tem medo de console.


🔟 Moral da história (em linguagem de data center)

IF TODOS FINGEM QUE FUNCIONA
   THEN ALGUÉM ESTÁ MENTINDO

E geralmente:

  • não é o sistema

  • não é a máquina

  • é o comportamento humano


🜂 Encerramento — por que esse conto nunca envelhece?

Porque ele fala menos de reis
e mais de nós.

Enquanto houver:

  • status

  • medo

  • hierarquia

  • modismos

  • buzzwords

  • tecnologias “mágicas”

A Roupa Nova do Rei continuará rodando.

E sempre precisaremos da criança…
ou do mainframer veterano…
ou do otaku questionador…

pra olhar pra tela e dizer:

“Pessoal… isso aí não está vestindo nada.”



quarta-feira, 8 de dezembro de 2010

Conan, o Bárbaro e a Arquitetura da Coragem

 

Bellacosa Mainframe apresenta Conan o Barbaro e suas lições para um programador cobol

☕ Um Café no Bellacosa Mainframe

Conan, o Bárbaro e a Arquitetura da Coragem

Quando um Programador COBOL Descobre que as Melhores Lições de Engenharia de Sistemas Também Estavam Escondidas nas Frases do Cimério

"A diferença entre um aventureiro e um analista de sistemas experiente é simples: ambos entram em lugares onde ninguém gostaria de entrar. Apenas um deles leva documentação."


Introdução – O Código Também Tem sua Era Hiboriana

Existe um motivo pelo qual Conan continua sendo um dos personagens mais influentes da literatura fantástica, mesmo quase um século após sua criação por Robert E. Howard, em 1932.

Não é apenas pela espada.

Não é pelos músculos.

Muito menos pelas batalhas.

O verdadeiro legado de Conan está em sua filosofia prática de sobrevivência.

Enquanto outros heróis fazem longos discursos sobre honra, justiça ou destino, Conan observa o ambiente, mede o inimigo, identifica a fraqueza e resolve o problema.

Curiosamente, essa forma de pensar lembra muito o cotidiano de um programador COBOL trabalhando em um grande banco.

Imagine um sistema com 45 milhões de linhas de código.

Um ABEND em produção.

CICS congestionado.

DB2 apresentando lock escalation.

MQ acumulando filas.

Um incidente iniciado às 02h37 da manhã.

Naquele momento ninguém quer ouvir discursos.

Todos querem alguém que pense como Conan.


Robert E. Howard Criou Muito Mais que um Bárbaro

Quando Howard escreveu Conan para a revista Weird Tales, pretendia criar um personagem diferente dos cavaleiros medievais tradicionais.

Conan não era perfeito.

Não era um escolhido.

Não era um príncipe escondido.

Não possuía poderes mágicos.

Era simplesmente alguém extremamente competente.

Essa competência vinha da observação.

Da experiência.

Dos fracassos.

Das cicatrizes.

No mundo corporativo chamamos isso de...

Senioridade.


Bellacosa Mainframe e a filosofia de Conan o Barbaro

Primeira Lição

"Civilized men are more discourteous than savages."

"Homens civilizados são mais descorteses que os selvagens."

Esta talvez seja uma das frases mais famosas de Robert E. Howard.

Ela aparece em diferentes versões ao longo dos contos.

A ideia é simples.

Os chamados "civilizados" frequentemente escondem traições atrás de títulos, roupas elegantes e cargos importantes.

Já os bárbaros normalmente mostram exatamente quem são.


Bellacosa Mainframe

Quem trabalha em grandes empresas percebe algo semelhante.

O maior risco raramente é o COBOL.

Nem o JCL.

Nem o VSAM.

Muito menos o Db2.

Os maiores problemas costumam nascer de:

  • reuniões mal conduzidas;

  • requisitos ambíguos;

  • documentação inexistente;

  • decisões políticas;

  • mudanças sem comunicação.

Howard provavelmente diria:

"O dragão não mora na caverna.

Mora na sala de reuniões."


Easter Egg

Conan raramente era enganado por aparência.

Da mesma forma, um analista experiente nunca julga um sistema apenas pela interface.

O verdadeiro perigo costuma estar escondido na arquitetura.


Segunda Lição

"Barbarism is the natural state of mankind."

"A barbárie é o estado natural da humanidade."

Esta talvez seja a visão mais pessimista — e ao mesmo tempo mais realista — de Howard.

Civilizações surgem.

Crescem.

Enriquecem.

Depois...

Entram em decadência.

Howard acreditava que a ordem era temporária.

O caos sempre estava esperando.


O Paralelo com Sistemas Corporativos

Todo sistema nasce organizado.

Depois de alguns anos aparecem:

  • patches;

  • gambiarras;

  • soluções temporárias;

  • correções emergenciais;

  • integrações improvisadas.

Dez anos depois...

ninguém entende completamente o sistema.

Vinte anos depois...

ninguém sabe quem escreveu metade do código.

Trinta anos depois...

aquele sistema movimenta bilhões de reais diariamente.


Conan chamaria isso de:

"O Reino caiu porque esqueceu como suas muralhas foram construídas."

Um arquiteto de software chamaria de:

Dívida Técnica.


Terceira Lição

"O medo mata mais homens do que a espada."

Embora essa frase apareça em versões diferentes ao longo das adaptações de Conan, ela representa perfeitamente sua filosofia.

Conan não era destemido.

Ele sentia medo.

A diferença é que nunca permitia que o medo decidisse.


No Mainframe

Quem nunca viu frases como:

"Não mexe."

"Está funcionando."

"Ninguém sabe o que acontece."

"Melhor deixar."

Esse medo custa milhões.

Howard entenderia imediatamente.

Porque o medo paralisa.

E sistemas paralisados envelhecem.


CSI Mainframe

Todo incidente começa igual.

Ninguém quer tocar.

Até que alguém pergunta:

"Quem conhece esse módulo?"

Silêncio.

Então aparece o velho programador COBOL.

Ele olha.

Sorri.

E responde:

"Esse COPYBOOK eu escrevi em 1998."


Quarta Lição

"Nenhum deus é tão poderoso quanto acredita."

Essa frase resume o espírito das histórias de Conan, embora não seja uma citação textual de Howard.

Conan enfrentava:

  • deuses;

  • sacerdotes;

  • feiticeiros;

  • monstros;

  • reis;

  • imperadores.

Jamais aceitava autoridade apenas porque alguém dizia ser poderoso.

Primeiro observava.

Depois testava.

Finalmente atacava.


Engenharia de Software

Todo sistema possui limitações.

Toda arquitetura possui gargalos.

Todo algoritmo possui casos extremos.

Toda infraestrutura possui ponto único de falha.

Não existe perfeição.

Existe apenas desconhecimento.


Quinta Lição

"Todo monstro tem uma fraqueza."

Conan sobrevivia porque estudava seus inimigos.

Nunca confiava apenas na força.

Antes da batalha ele observava.

Cheiros.

Pegadas.

Armadilhas.

Terreno.

Hábitos.


Sherlock Holmes?

Quase.

CSI?

Também.

Na prática Conan fazia exatamente aquilo que hoje chamamos de:

Análise de causa raiz.


No mainframe fazemos o mesmo.

RMF.

SMF.

SYSLOG.

JES.

SDSF.

Db2 Trace.

CICS Statistics.

MQ Logs.

Tudo isso serve para descobrir...

Onde o monstro realmente mora.


Sexta Lição

"Se pode ser ferido, pode ser derrotado."

Essa não é uma frase literal dos contos de Howard.

Mas resume perfeitamente Conan.

É exatamente a filosofia do personagem.

Não importa quão impossível pareça.

Existe alguma vulnerabilidade.


O Programador COBOL Descobre

Um problema aparentemente impossível normalmente possui origem simples.

Um índice.

Um parâmetro.

Um RECFM.

Um BLKSIZE.

Um COMP-3 mal definido.

Um campo desalinhado.

Uma página Db2 sem RUNSTATS.

Um enqueue esquecido.


Todo gigante possui um calcanhar de Aquiles.


Sétima Lição

"I live, I love, I slay, and am content."

"Eu vivo, amo, luto, mato e estou satisfeito."

Essa frase resume Conan melhor do que qualquer biografia.

Ele não busca riqueza infinita.

Nem fama eterna.

Muito menos poder absoluto.

Conan vive intensamente.

Aceita perdas.

Segue adiante.


No Mundo Corporativo

Há profissionais que vivem esperando:

a próxima promoção.

o próximo cargo.

o próximo reconhecimento.

Enquanto isso esquecem de apreciar o conhecimento adquirido.

Conan provavelmente diria:

"O maior tesouro é sobreviver para a próxima aventura."


A Filosofia Bellacosa Mainframe

Imagine Conan entrando em um Data Center.

Não perguntaria:

"Qual linguagem foi usada?"

Perguntaria:

"Quem realmente conhece esse sistema?"

Depois perguntaria:

"Qual parte dele ninguém tem coragem de alterar?"

Ali encontraria o verdadeiro monstro.


Curiosidades

Robert E. Howard praticamente inventou o herói moderno de fantasia.

Sem Conan provavelmente não existiriam:

  • Red Sonja

  • Kull

  • Fafhrd

  • Elric

  • Druss

  • Geralt

  • Guts

  • Goblin Slayer

  • Kratos

  • inúmeros protagonistas de RPG.


Conan odeia burocracia

Durante praticamente toda sua vida:

foi ladrão.

mercenário.

pirata.

general.

rei.

Em todas essas fases desconfiava de políticos e sacerdotes.


Howard era obcecado pela História

As civilizações hiborianas foram inspiradas em:

Roma.

Grécia.

Egito.

Pérsia.

Celtas.

Vikings.

Sumérios.

Tudo misturado em uma cronologia fictícia extremamente detalhada.


Easter Egg COBOL

Conan jamais perguntaria:

"Qual framework vocês usam?"

Perguntaria:

"Quantas batalhas esse sistema já sobreviveu?"

Essa é exatamente a pergunta que um arquiteto deveria fazer antes de sugerir reescrever um sistema COBOL que processa milhões de transações por dia.


A Espada e o Debugger

Existe uma curiosa semelhança entre Conan e um bom depurador de software.

Ambos procuram:

  • rastros;

  • evidências;

  • padrões;

  • pontos fracos;

  • erros escondidos.

Conan nunca luta às cegas.

Um bom analista também não.


O Verdadeiro Bárbaro é o Especialista

Howard inverte completamente nossa percepção.

O bárbaro é quem entende como o mundo realmente funciona.

Os civilizados vivem presos às aparências.

No Data Center acontece algo semelhante.

O profissional mais valioso normalmente não é aquele que usa a tecnologia mais nova.

É aquele que entende:

  • por que ela existe;

  • como evoluiu;

  • quais problemas resolveu;

  • e principalmente...

...o que acontece quando ela falha.


Conclusão – Conan Nunca Programou COBOL... Mas Pensava Como um Arquiteto de Mainframe

É curioso perceber como frases escritas há quase cem anos continuam incrivelmente atuais.

Quando Conan afirma que homens civilizados podem ser mais perigosos que selvagens, ele está nos alertando sobre a diferença entre aparência e realidade.

Quando lembra que a barbárie é o estado natural da humanidade, ele nos ensina que ordem, estabilidade e arquitetura precisam ser continuamente preservadas. Em tecnologia, sistemas degradam, processos se deterioram e a dívida técnica cresce silenciosamente se ninguém cuidar deles.

Quando diz que o medo mata mais homens do que a espada, ele descreve exatamente o que acontece quando equipes deixam de evoluir por receio de modificar sistemas críticos. O medo da mudança pode ser mais destrutivo do que a própria mudança.

As ideias sintetizadas em frases como "Nenhum deus é tão poderoso quanto acredita", "Todo monstro tem uma fraqueza" e "Se pode ser ferido, pode ser derrotado" traduzem uma mentalidade indispensável para quem trabalha com missão crítica. Nenhuma arquitetura é perfeita, nenhum problema é insolúvel e nenhum incidente deve ser tratado como magia. Tudo pode ser compreendido quando investigado com método, disciplina e experiência.

E talvez seja essa a maior lição que Robert E. Howard deixou para engenheiros, administradores de sistemas e programadores COBOL.

Conan nunca venceu porque era o mais forte.

Venceu porque observava antes de agir.

Pensava antes de atacar.

Aprendia antes de repetir.

Em um mundo repleto de buzzwords, frameworks da moda e promessas de reescrever tudo do zero, a filosofia do cimério continua surpreendentemente moderna. Ela nos lembra que conhecimento sólido supera modismos, experiência vale mais do que propaganda e que a coragem verdadeira nasce da compreensão do problema.

No fim das contas, um bom profissional de mainframe e Conan compartilham o mesmo princípio: diante de um incidente, de um monstro ou de um sistema com cinquenta anos de história, não importa o tamanho do desafio.

Primeiro investigue.

Depois encontre a fraqueza.

E então resolva o problema com a precisão de quem sabe que toda grande batalha, assim como todo grande programa COBOL, é vencida uma instrução de cada vez.

segunda-feira, 6 de dezembro de 2010

🔥 Os 50 Principais ABENDs em CICS

 

Lista dos 50 principais erros em CICS

🔥 Os 50 Principais ABENDs em CICS
Possíveis causas, soluções e sabedoria de data center


☕ Midnight Lunch, região viva… e o ABEND aparece

14h07.
Tela congelou.
CEMT I TASK mostra status estranho.
O operador solta a clássica frase:

“Deu ABEND no CICS…”

Mas qual ABEND?
E mais importante: por quê?

Hoje vamos entrar no lado sombrio do CICS — os 50 ABENDs mais comuns, com causa raiz, solução e comentários de quem já apagou muito incêndio.


🏛️ História: ABEND não é erro, é aviso

No mundo CICS:

  • ABEND ≠ bug automático

  • ABEND = proteção

  • O sistema prefere matar a task do que corromper dados

📌 ABEND é o CICS dizendo: “daqui não passa”.


🧠 Conceito essencial

Quem entende ABEND, domina produção.


Lista de abends mais comuns em CICS


💥 Top 50 ABENDs em CICS (causas & soluções)


🔴 ABENDs de Programação

  1. AEIP – Comando CICS inválido
    👉 Causa: erro de lógica
    ✅ Solução: revisar comando EXEC CICS

  2. AEIM – Mapa inexistente
    👉 MAPSET não carregado
    ✅ Definir corretamente no CICS

  3. AEI0 – Erro de terminal
    👉 Sessão inválida
    ✅ Validar TC

  4. AEIS – Storage corrompido
    👉 Ponteiro inválido
    ✅ Revisar GETMAIN/FREEMAIN

  5. AEIN – Intervalo inválido
    👉 WAIT TIME errado
    ✅ Ajustar intervalo


🔴 ABENDs de Arquivo (File Control)

  1. AEIO – Erro de I/O
    👉 VSAM indisponível
    ✅ Verificar dataset

  2. AEIL – Arquivo não definido
    👉 FCT incorreta
    ✅ Corrigir definição

  3. AEIR – Registro não encontrado
    👉 READ sem verificação
    ✅ Tratar NOTFND

  4. AEIW – WRITE inválido
    👉 Layout errado
    ✅ Ajustar estrutura

  5. AEID – DELETE inválido
    👉 Registro inexistente
    ✅ Validar chave


🔴 ABENDs de Storage

  1. AEY9 – Falta de storage
    👉 Vazamento de GETMAIN
    ✅ Liberar storage

  2. ASRA – Protection exception
    👉 Storage corrompido
    ✅ Revisar ponteiros

  3. ASRB – Arithmetic exception
    👉 DIVIDE BY ZERO
    ✅ Validar cálculo

  4. AEYA – Storage key error
    👉 Região protegida
    ✅ Revisar chave

  5. AEYD – Stack overflow
    👉 Loop recursivo
    ✅ Corrigir lógica


🔴 ABENDs de Program Control

  1. AEIX – XCTL inválido
    👉 Programa inexistente
    ✅ Corrigir nome

  2. AEIL – LINK inválido
    👉 Parâmetros errados
    ✅ Ajustar COMMAREA

  3. AEIY – Programa não reentrante
    👉 Uso incorreto
    ✅ Tornar reentrante

  4. AEIZ – RETURN inválido
    👉 Fluxo quebrado
    ✅ Revisar lógica

  5. AEIP – LINK circular
    👉 Arquitetura ruim
    ✅ Refatorar fluxo


🔴 ABENDs de Terminal / BMS

  1. AEIM – Mapa não encontrado
    👉 MAPSET não carregado
    ✅ CEDA INSTALL

  2. AEIT – Erro de terminal
    👉 Sessão encerrada
    ✅ Validar conexão

  3. AEIB – Buffer overflow
    👉 Campo maior que área
    ✅ Ajustar tamanho

  4. AEIA – Atributo inválido
    👉 BMS errado
    ✅ Revisar mapa

  5. AEIC – Cursor inválido
    👉 Campo inexistente
    ✅ Corrigir IC


🔴 ABENDs de Transação / Task

  1. AEIT – Task inválida
    👉 Estado inconsistente
    ✅ Revisar RETURN

  2. AEI3 – Transação não definida
    👉 PCT ausente
    ✅ Definir TRANSID

  3. AEI4 – Security violation
    👉 Falta de autorização
    ✅ Ajustar RACF

  4. AEI5 – Time-out
    👉 Loop infinito
    ✅ Otimizar lógica

  5. AEI6 – Deadlock
    👉 Lock excessivo
    ✅ Reduzir escopo


🔴 ABENDs de Integração / Sistema

  1. APCT – Erro de Program Control
    👉 Configuração errada
    ✅ Revisar região

  2. AICA – Conversão inválida
    👉 Dados inconsistentes
    ✅ Validar formatos

  3. AICM – MQ error
    👉 Fila indisponível
    ✅ Verificar MQ

  4. AIDB – DB2 error
    👉 SQLCODE negativo
    ✅ Tratar SQL

  5. AIDS – Data inconsistente
    👉 Conversão errada
    ✅ Sanitizar dados


🔴 ABENDs “Clássicos de Guerra”

  1. ASRA – O mais temido
    👉 Memory overwrite
    ✅ Debug profundo

  2. AEIP – O mais comum
    👉 Código mal tratado
    ✅ Revisar lógica

  3. AEY7 – Storage leak
    👉 GETMAIN sem FREEMAIN
    ✅ Corrigir ciclo

  4. AEZC – CICS internal
    👉 Bug ou stress
    ✅ IBM support

  5. AFCA – File corruption
    👉 VSAM danificado
    ✅ Rebuild


🔴 ABENDs de Segurança

  1. AEI4 – RACF denial
    👉 Permissão faltando
    ✅ Ajustar perfil

  2. AESP – Security program
    👉 Violação
    ✅ Revisar acessos

  3. AEPI – Program protected
    👉 Programa não autorizado
    ✅ CEDA SET PROG

  4. AEXY – User exit failure
    👉 Exit defeituoso
    ✅ Debug exit

  5. AEXZ – Transaction denied
    👉 Perfil incorreto
    ✅ RACF


🔴 Os últimos, mas não menos perigosos

  1. AEZ9 – Resource unavailable
    👉 Falta de recurso
    ✅ Ajustar região

  2. AEZA – Internal error
    👉 Estado crítico
    ✅ Restart controlado

  3. AEZH – Program load failure
    👉 Load module ausente
    ✅ Reinstalar

  4. AEZI – System overload
    👉 Pico de tasks
    ✅ Tuning

  5. AEZZ – O “não documentado”
    👉 Algo muito errado
    ✅ Chamar o mais velho da sala 😈


📚 Guia de estudo para mainframers

Domine:

  • HANDLE ABEND

  • CEMT I TASK

  • DFHDU

  • Dumps CICS

  • SMF + logs

📖 Manual essencial: CICS Problem Determination Guide


🤓 Curiosidades de boteco mainframe

🍺 ASRA já aposentou muita gente
🍺 AEIP é quase rito de passagem
🍺 Todo ABEND ensina algo
🍺 Quem lê dump vira referência


💬 Comentário El Jefe Midnight Lunch

“ABEND não é o fim.
É o CICS pedindo para você pensar.”


🎯 Conclusão Bellacosa

Conhecer ABEND:

  • Reduz MTTR

  • Evita pânico

  • Dá respeito em produção

🔥 Quem entende ABEND, manda no CICS.


domingo, 5 de dezembro de 2010

Bellacosa Index Page: Checklist de Indexação SEO – Guia Completo

 

Check list seo page

Checklist de Indexação SEO – Guia Completo

1. Permitir indexação nos motores de busca

Antes de qualquer otimização, é essencial garantir que o site possa ser indexado. Verifique se não há bloqueios globais, como:

  • noindex aplicado ao site inteiro

  • configurações de privacidade ativadas

  • cabeçalhos HTTP do tipo X-Robots-Tag: noindex

Use o Google Search Console para confirmar se as páginas estão “Disponíveis para o Google”.


2. Robots.txt bem configurado

O arquivo robots.txt controla o rastreamento. Uma configuração correta:

  • permite acesso às páginas importantes

  • bloqueia áreas irrelevantes (ex: páginas de busca internas)

  • declara o sitemap

Exemplo recomendado:

User-agent: * Disallow: /search Allow: / Sitemap: https://www.seusite.com/sitemap.xml

Evite erros graves como Disallow: /, que bloqueia todo o site.


3. Sitemap XML funcional e enviado

O sitemap ajuda o Google a descobrir URLs.
Boas práticas:

  • gerar sitemap automático

  • incluir apenas páginas indexáveis

  • enviar no Google Search Console

  • monitorar erros de leitura

O sitemap não deve ser indexado, apenas lido por robôs.


4. Uso correto de meta robots

As tags meta robots ou regras de robôs personalizadas devem ser usadas com cautela:

  • páginas e posts importantes: index, follow

  • páginas de busca e arquivo: noindex

Nunca aplique noindex em páginas que você deseja que apareçam nos resultados.


5. Estrutura correta de títulos (Headings)

Cada página deve conter:

  • 1 único H1 (título principal)

  • H2 para subtítulos

  • H3/H4 para hierarquia interna

Os headings ajudam o Google a entender o tema e a organização do conteúdo.


6. Títulos e meta descrições otimizados

Cada página deve ter:

  • título único e descritivo (50–60 caracteres)

  • meta descrição clara e atrativa (120–160 caracteres)

Esses elementos influenciam diretamente o CTR (taxa de cliques) nos resultados de busca.


7. Conteúdo com qualidade e profundidade

Conteúdo é um dos principais fatores de SEO.
Checklist mínimo:

  • textos com 300 palavras ou mais

  • conteúdo original

  • respostas claras à intenção do usuário

  • parágrafos curtos e escaneáveis

Conteúdo fraco tende a ser ignorado ou removido do índice.


8. URLs amigáveis

Boas URLs:

  • curtas

  • sem parâmetros desnecessários

  • com palavras-chave

  • sem caracteres especiais

Exemplo bom:

/checklist-indexacao-seo.html

9. Links internos estratégicos

Links internos:

  • ajudam o Google a descobrir páginas

  • distribuem autoridade

  • aumentam tempo de permanência

Checklist:

  • cada post deve linkar para outros conteúdos relevantes

  • páginas importantes devem ser acessíveis a partir da home


10. Links externos confiáveis

Links para sites relevantes:

  • aumentam credibilidade

  • contextualizam o conteúdo

  • melhoram a experiência do usuário

Evite links quebrados ou para sites de baixa qualidade.


11. Otimização de imagens

Imagens também são indexáveis:

  • usar nomes descritivos

  • preencher o atributo alt

  • comprimir arquivos

  • evitar imagens muito pesadas

Isso melhora SEO e velocidade.


12. Performance e velocidade

Sites lentos têm pior desempenho nos rankings.
Verifique:

  • tempo de carregamento

  • excesso de scripts

  • imagens não otimizadas

Ferramenta recomendada: Google PageSpeed Insights.


13. Mobile-friendly (responsivo)

A indexação do Google é mobile-first.
Checklist:

  • layout responsivo

  • textos legíveis no celular

  • botões clicáveis

  • sem pop-ups intrusivos


14. Evitar conteúdo duplicado

Conteúdo duplicado confunde os buscadores.
Cuidados:

  • não repetir textos inteiros

  • usar canonical quando necessário

  • evitar múltiplas URLs com o mesmo conteúdo


15. Dados estruturados (Schema)

Sempre que possível, use dados estruturados para:

  • artigos

  • breadcrumbs

  • reviews

  • vídeos

Isso pode gerar rich snippets e aumentar o CTR.


16. Frequência de publicação

Sites atualizados com frequência são rastreados com mais regularidade.

  • mantenha consistência

  • evite longos períodos sem novos conteúdos


17. Monitoramento constante

SEO não é tarefa única.
Checklist de acompanhamento:

  • revisar relatórios do Search Console

  • corrigir páginas excluídas

  • atualizar conteúdos antigos

  • acompanhar desempenho


18. Experiência do usuário

O Google avalia sinais de uso:

  • tempo na página

  • taxa de rejeição

  • navegação intuitiva

Conteúdo bom e bem estruturado retém o visitante.


Conclusão

Um Checklist de Indexação SEO bem aplicado garante que seu site:

  • seja rastreável

  • seja indexado corretamente

  • tenha conteúdo compreendido pelos motores de busca

  • ofereça boa experiência ao usuário

SEO não é sobre truques, mas sobre clareza, qualidade e consistência.
Ao seguir este checklist, você cria uma base sólida para crescer organicamente, ganhar visibilidade e construir autoridade nos motores de busca de forma sustentável.


sexta-feira, 3 de dezembro de 2010

🧱 IBM Mainframe Storage Management no z/OS

Bellacosa Mainframe apresenta Storage Management no IBM z/OS



🧱 IBM Mainframe Storage Management no z/OS

DFSMS, SMS x non-SMS, ISMF, ACS, DASD, TAPE, JCL, VSAM, PS e PO

O disco não é só espaço. É política, disciplina e sobrevivência.


☕ Introdução – Quando o disco manda mais que o código

Todo mainframe nasce vazio.
Nenhum COBOL roda, nenhum CICS responde, nenhum batch fecha balanço sem que alguém tenha decidido onde os dados vão morar.

E é aqui que muita gente erra:

“Ah, storage é só pedir espaço no JCL…”

❌ Errado.
No IBM Mainframe, storage é governança, automação, história, política corporativa e, muitas vezes, briga silenciosa entre times.

Este artigo é para você que:

  • Já sofreu com SMS override

  • Já ouviu “o ACS mandou”

  • Já viu dataset ir parar num disco que você nem sabia que existia

  • Ou ainda acha que VOL=SER ainda manda em tudo

Senta, pega o café, que a aula começa agora.


🏛️ Origem e História – Do ferro bruto ao cérebro automático

📼 Anos 60–70: tudo era manual

  • Disco era caro

  • Poucos volumes

  • Programador escolhia tudo

  • Erro humano era rotina

💣 Anos 80: o caos

  • Explosão de dados

  • Batch gigante

  • Fragmentação absurda

  • Discos cheios às 03:00 da manhã

🧠 Anos 90: nasce o DFSMS

A IBM percebeu:

“Não dá para deixar cada programador decidir disco.”

Surge o DFSMS (Data Facility Storage Management Subsystem).

Objetivo:

  • Padronizar

  • Automatizar

  • Controlar

  • Evitar desastre operacional

📌 DFSMS não é luxo. É resposta ao caos.


🧠 DFSMS – O cérebro do armazenamento no z/OS

DFSMS é:

  • Parte nativa do z/OS

  • Gerente de dados

  • Juiz das decisões de disco

  • Guarda-costas da infraestrutura

Ele cuida de:

  • DASD

  • TAPE

  • Migração

  • Backup

  • Alocação

  • Performance

  • Disponibilidade


💽 DASD – O chão onde tudo pisa

DASD = Direct Access Storage Device

Tradução Bellacosa:

“É o HD do mainframe, só que sério.”

Tudo mora em DASD:

  • z/OS

  • SYS1

  • Aplicações

  • VSAM

  • Logs

  • Catálogos

📌 Volume = Disco = DASD

Exemplos reais:

PRD001
TSO123
CICS45

📼 TAPE – O ancião que ainda reina

Muita gente subestima, mas:

  • Tape é barato

  • Tape é denso

  • Tape é confiável

  • Tape é rei do backup

DFSMS controla:

  • Migração HSM

  • Recall automático

  • Arquivamento

📌 Easter egg:
Muitos bancos ainda têm dados mais velhos que o programador, morando felizes em fita.


🧩 SMS x non-SMS – O conflito eterno

🔴 Non-SMS (old school)

Você manda:

  • VOL=SER

  • SPACE

  • UNIT

Vantagem:

  • Controle total

Desvantagem:

  • Risco total

📌 Hoje: usado só em casos muito específicos.


🟢 SMS-Managed (mundo real)

O sistema manda.

Você pede:

  • Nome do dataset

O SMS decide:

  • Onde fica

  • Quanto espaço

  • Performance

  • Migração

📌 Naming convention é lei.


🧬 ACS – O código que manda mais que o JCL

ACS Routine = cérebro do SMS

Ela decide:

  • Data Class

  • Storage Class

  • Storage Group

Baseado em:

  • Nome do dataset

  • Usuário

  • Programa

  • Ambiente

Exemplo simplificado:

IF &DSN = 'PRD.*'
   SET &STORCLAS = 'HIGH'

💣 Easter egg cruel:

Você pode pedir CYL(1000).
O ACS pode te dar TRK(10).
E ainda sorrir.


🖥️ ISMF – Onde o poder mora

ISMF = Interactive Storage Management Facility

Ferramenta do:

  • Storage admin

  • Infra

  • Arquitetura

Aqui você vê:

  • Volumes

  • Classes

  • Storage Groups

  • ACS

  • Espaço real

📌 Programador geralmente não entra aqui.


🧱 Data Class – O DNA do dataset

Define:

  • RECFM (FB, VB…)

  • LRECL

  • DSORG

Exemplo:

RECFM=FB
LRECL=80
DSORG=PS

📌 Template padrão corporativo.


🚀 Storage Class – Performance e SLA

Define:

  • Prioridade

  • Backup

  • Migração

  • Disponibilidade

📌 Onde o negócio fala mais alto que o código.


🗄️ Storage Group – O endereço físico

  • Conjunto de volumes

  • Abstração total

  • Usuário não escolhe disco

📌 Você não precisa saber qual disco.
📌 O SMS sabe.


📂 Tipos de Data Set – PS, PO, VSAM

📄 PS (Sequential)

  • Batch

  • Relatórios

  • Entrada/Saída simples


📚 PO / PDS / PDSE

  • Código

  • JCL

  • Copybooks

📌 PDSE > PDS (sempre que possível).


🧬 VSAM

  • KSDS

  • ESDS

  • RRDS

Alta performance, alta complexidade.

📌 VSAM mal dimensionado = pesadelo.


📜 JCL x DFSMS – Quem manda?

JCL pede.
DFSMS decide.

Exemplo clássico:

SPACE=(CYL,(100,50))

Resultado:

SPACE=(TRK,(10,5))

Mensagem:

“Some attributes were overridden by ACS routine.”

📌 Tradução:

“Você tentou. Eu mandei.”


🧪 Passo a passo prático (vida real)

  1. Dataset criado

  2. ACS roda

  3. Classes atribuídas

  4. Volume escolhido

  5. Espaço ajustado

  6. Catálogo atualizado

Tudo automático.


🧙‍♂️ Dicas Bellacosa Mainframe

✔ Naming convention é tudo
✔ Nunca confie só no JCL
✔ Leia o ACS antes de reclamar
✔ ISMF é seu melhor amigo
✔ Storage admin é aliado, não inimigo
✔ PDSE sempre que possível
✔ VSAM exige respeito


🥚 Easter Eggs & Curiosidades

🥚 Existem ACS routines com 20+ anos em produção
🥚 Já houve banco parado porque alguém mexeu no ACS sem change
🥚 Muitos datasets “fantasmas” existem só porque ninguém sabe quem usa
🥚 Tape ainda salva mais empresa que cloud hype


☕ Conclusão – A frase que resume tudo

“No mainframe, código faz o sistema funcionar.
Storage faz o negócio sobreviver.”

Se quiser, posso:

  • 📚 Transformar isso em curso

  • 🧪 Criar labs práticos

  • 🎓 Adaptar para aula corporativa

  • 🔐 Criar versão bancária real

  • 📊 Montar mapa mental DFSMS

Só chamar.
O café está quente ☕🖥️


quarta-feira, 10 de novembro de 2010

Battle Beyond the Stars (1980) — Quando um Mainframe Ensina que Nem Todo Tesouro Cabe em um Data Center

 

Bellacosa Mainframe apresenta Battle Beyond the Stars

☕ Um Café no Bellacosa Mainframe

Battle Beyond the Stars (1980) — Quando um Mainframe Ensina que Nem Todo Tesouro Cabe em um Data Center

"Às vezes pensamos que a maior riqueza é aumentar a capacidade do disco. Até descobrir que um velho arquivo esquecido vale mais que todos os terabytes do mundo."


Uma viagem para 1980

Existe uma categoria de filmes que envelhece.

E existe outra que simplesmente ganha novas camadas conforme envelhecemos.

Battle Beyond the Stars, lançado em 26 de setembro de 1980 nos Estados Unidos, pertence à segunda categoria.

Na adolescência você assiste pelas explosões.

Aos vinte anos, pelas naves.

Aos quarenta, pelos personagens.

Aos cinquenta...

...você entende Gelt.

E percebe que talvez ele sempre tenha sido o verdadeiro protagonista.



Ficha Técnica

ItemInformação
Título originalBattle Beyond the Stars
BrasilMercenários das Galáxias
Ano1980
DiretorJimmy T. Murakami
ProduçãoRoger Corman
RoteiroJohn Sayles
MúsicaJames Horner
Duração104 minutos
GêneroSpace Opera
EstúdioNew World Pictures
ClassificaçãoPG (EUA)

Curiosamente...

Este foi um dos primeiros trabalhos importantes de James Horner.

Sim...

O mesmo compositor que mais tarde faria:

  • Star Trek II

  • Aliens

  • Willow

  • Braveheart

  • Titanic

  • Avatar

Muitos temas musicais que ele reutilizaria ao longo da carreira começaram aqui.


Roger Corman

Se Hollywood fosse um mainframe...

Roger Corman seria aquele engenheiro capaz de fazer um IBM 3090 competir com um z17 usando metade da memória.

Era conhecido por produzir filmes com orçamento baixíssimo.

Mas conseguia descobrir talentos como ninguém.

Por seus filmes passaram:

  • James Cameron

  • Francis Ford Coppola

  • Martin Scorsese

  • Joe Dante

  • Jonathan Demme

  • Ron Howard

Battle Beyond the Stars foi um verdadeiro laboratório de futuros gigantes do cinema.



A História

O planeta agrícola Akir vive em paz.

Até surgir o conquistador espacial:

Sador

Interpretado por John Saxon.

Ele possui um gigantesco couraçado espacial.

Seu objetivo?

Conquistar.

Pilhar.

Destruir.

Ou receber tributo.

Akir não possui exército.

Então o jovem:

Shad

recebe uma antiga nave espacial.

E parte em busca de guerreiros.

Exatamente como...

Os Sete Samurais.



A verdadeira inspiração

Battle Beyond the Stars não nasceu do nada.

Sua árvore genealógica é quase perfeita.

Os Sete Samurais (1954)

↓

Sete Homens e um Destino (1960)

↓

Battle Beyond the Stars (1980)

↓

Rebel Moon (2023)

A estrutura narrativa permanece praticamente intacta.

Apenas muda o cenário.

Samurais.

Cowboys.

Mercenários espaciais.



Os Mercenários

Cada personagem representa um arquétipo clássico.

Shad

O herói inocente.

Ainda acredita que bondade resolve problemas.


Nestor

Uma nave senciente.

Metade computador.

Metade consciência.

Algo entre HAL 9000...

e R2-D2.


Cayman

Um cowboy espacial.

Atira antes de pensar.


Saint-Exmin

Uma guerreira valquíria interestelar.

Elegância.

Precisão.

Honra.


Gelt

Aqui...

o filme muda completamente de nível.


Gelt

Gelt é um criminoso.

Assassino.

Contrabandista.

Mercenário.

Extremamente rico.

Talvez o homem mais rico da galáxia.

Mas vive sozinho.

Ninguém o visita.

Não possui amigos.

Não pode aparecer em nenhuma cidade.

Não consegue gastar seu dinheiro.

Imagine um bilionário...

condenado ao isolamento perpétuo.

Shad oferece pagamento.

Gelt ri.

Mostra montanhas de ouro.

Então o jovem diz:

"Só podemos oferecer um lar."

E tudo muda.

Ali percebemos:

A fortuna dele nunca comprou aquilo que realmente desejava.


O Plot Twist Emocional

O maior plot twist não é uma batalha.

Não é uma explosão.

É descobrir que o homem mais rico do filme...

...é também o mais pobre.

Ele aceita lutar.

Não pelo dinheiro.

Mas porque deseja experimentar novamente:

  • amizade;

  • confiança;

  • uma refeição compartilhada.

Essa transformação silenciosa é uma das maiores forças do roteiro.



Estrutura Narrativa

Podemos dividir o filme em cinco atos:

Problema

↓

Viagem

↓

Recrutamento

↓

Preparação

↓

Batalha Final

É uma estrutura usada até hoje.

Star Wars.

Os Vingadores.

Sete Homens e um Destino.

Rebel Moon.

The Magnificent Seven (2016).

Tudo bebe desta fonte.


Easter Eggs

Os fãs encontram diversos detalhes interessantes:

  • várias naves lembram modelos de Star Wars;

  • o design orgânico da nave de Nestor foi pensado para parecer quase "viva";

  • James Cameron trabalhou nos efeitos especiais e na direção de arte de miniaturas, antes de dirigir seus próprios sucessos;

  • James Horner reutilizou ideias musicais que mais tarde apareceriam em filmes como Star Trek II e Aliens.


Curiosidades

James Cameron

Antes de Terminator.

Antes de Aliens.

Antes de Titanic.

Ele trabalhou aqui construindo miniaturas e cenários.


John Sayles

O roteiro foi escrito em poucos dias.

Mesmo assim...

continua surpreendentemente sólido.


Orçamento

Cerca de US$ 2 milhões.

Pouquíssimo.

Mesmo para 1980.


Bilheteria

Arrecadou aproximadamente US$ 11 milhões em todo o mundo.

Foi considerado um bom retorno para uma produção independente e consolidou mais um sucesso de Roger Corman.


A Censura

Recebeu classificação PG nos EUA.

Hoje provavelmente seria equivalente a uma classificação para maiores de 12 anos em muitos países, por conter violência de fantasia e batalhas espaciais, mas sem excesso de sangue ou conteúdo adulto.


Impacto Cultural

Na época...

foi visto como um "Star Wars barato".

Hoje...

é considerado um clássico cult.

Isso acontece porque as pessoas passaram a enxergar o roteiro.

E não apenas os efeitos especiais.


Serviu de inspiração para...

É difícil provar influência direta em todos os casos, mas sua marca aparece em diversas obras:

  • Rebel Moon

  • jogos de RPG espacial

  • quadrinhos de mercenários espaciais

  • séries de recrutamento de equipes improváveis

Mais do que copiar cenas, herdaram a ideia de reunir especialistas muito diferentes para enfrentar um inimigo impossível.


Críticas

Os efeitos especiais não competiam com os de Star Wars.

Alguns diálogos são simples.

Alguns personagens aparecem pouco.

Mas...

o filme possui algo raro.

Personagens memoráveis.

E isso sobrevive ao tempo.


A Filosofia Escondida

Aqui está a verdadeira mensagem.

Imagine Gelt como um enorme banco de dados.

Milhões de registros.

Petabytes de riqueza.

Capacidade infinita.

Mas...

nenhuma aplicação utilizando aquelas informações.

No mundo do mainframe diríamos:

Storage

≠

Valor

Valor nasce quando existe uso.

Quando existe compartilhamento.

Quando existe comunidade.

O mesmo vale para conhecimento.

Você pode acumular milhares de PDFs.

Milhares de cursos.

Centenas de badges.

Mas, se esse conhecimento nunca ajudar alguém, ele continuará sendo apenas armazenamento.


Bellacosa Mainframe

Sempre digo aos novos profissionais:

"Não estudem para colecionar certificados. Estudem para um dia alguém lembrar do seu nome quando surgir um problema difícil."

Gelt passou a vida colecionando riqueza.

No fim, descobriu que preferia colecionar amigos.

Nós passamos anos colecionando conhecimento técnico.

No fim da carreira, percebemos que as melhores lembranças não são do compilador COBOL ou do CICS que salvamos em uma madrugada, mas das conversas no café, das risadas na sala de operações, dos colegas que confiaram em nós e das pessoas que ajudamos a formar.


Por que você deve assistir?

Porque Battle Beyond the Stars não é apenas uma aventura espacial.

É um filme sobre envelhecer.

Sobre propósito.

Sobre descobrir que existe uma diferença enorme entre ter valor e ter preço.

Você verá naves de design curioso, batalhas feitas com criatividade e um elenco cheio de figuras marcantes. Mas o que provavelmente permanecerá na memória é a jornada de Gelt: um homem que possuía tudo o que o dinheiro podia comprar e, ainda assim, atravessou a galáxia por algo que nenhum tesouro podia oferecer.

Talvez seja por isso que o filme continua vivo mais de quatro décadas depois. No fundo, ele nos lembra que todos buscamos a mesma coisa: um lugar onde sejamos bem-vindos, pessoas com quem possamos dividir uma boa conversa e, quem sabe, um café.

E essa é uma lição que continua tão atual quanto em 1980.

domingo, 7 de novembro de 2010

Isekai no Seikishi Monogatari : Quando um Programador COBOL Padawan é Transportado para Outro Mundo e Descobre que Experiência Vale Mais do que Poder

Bellacosa Mainframe apresenta isekai no seikishi monogatari


☕ Um Café no Bellacosa Mainframe

Isekai no Seikishi Monogatari (異世界の聖機師物語)

Quando um Programador COBOL Padawan é Transportado para Outro Mundo e Descobre que Experiência Vale Mais do que Poder

"No Mainframe, um bom profissional não nasce sabendo JCL, CICS ou Db2. Ele aprende observando, servindo, errando pouco e evoluindo todos os dias. Kenshi Masaki segue exatamente esse caminho."


Introdução

Quando se fala em isekai, normalmente pensamos em protagonistas superpoderosos, sistemas de RPG, telas de status, habilidades infinitas e reis demônios.

Mas anos antes dessa fórmula dominar a indústria, surgiu uma obra que seguia um caminho completamente diferente.

Isekai no Seikishi Monogatari talvez seja um dos isekais mais subestimados já produzidos.

Ao mesmo tempo em que apresenta batalhas de mechas, política internacional, tecnologia ancestral, fantasia medieval e humor, também constrói um protagonista cuja maior habilidade não é lutar.

É aprender.

Para quem trabalha com tecnologia — principalmente no universo IBM Mainframe — essa mensagem é extremamente poderosa.


Ficha Técnica

ItemInformação
Título Original異世界の聖機師物語
RomanizaçãoIsekai no Seikishi Monogatari
Título internacionalTenchi Muyo! War on Geminar
CriadorMasaki Kajishima
DiretorKoji Yoshikawa
RoteiroHideki Shirane
EstúdiosAIC Spirits e BeSTACK
Lançamento20 de março de 2009 a 19 de março de 2010
FormatoOVA
Episódios13
Duraçãocerca de 45 minutos cada
OrigemObra original (spin-off do universo Tenchi Muyo!) (Wikipedia)

O Studio

A AIC (Anime International Company) foi um dos estúdios mais influentes das décadas de 1990 e 2000.

Foi responsável por obras como:

  • Tenchi Muyo!

  • El Hazard

  • Bubblegum Crisis

  • Ah! My Goddess

  • Dual! Parallel Trouble Adventure

A parceria com a BeSTACK elevou a qualidade visual da série, especialmente nas animações dos Sacred Mechanoids, que continuam impressionantes para um OVA daquela época. (Wikipedia)


O Autor

Masaki Kajishima é conhecido principalmente por criar o universo Tenchi Muyo!

Seu estilo sempre mistura:

  • ficção científica;

  • civilizações antigas;

  • humor;

  • política;

  • romance;

  • tecnologia extremamente avançada escondida sob aparência fantástica.

Geminar é praticamente uma continuação dessa filosofia.


Sinopse

Kenshi Masaki é transportado para um planeta chamado Geminar.

Sem entender por quê, é forçado a participar de uma conspiração para assassinar a jovem imperatriz Lashara Earth XXVIII utilizando um poderoso Sacred Mechanoid.

Depois que a conspiração fracassa, Kenshi passa de assassino a protegido da imperatriz.

A partir daí começa uma longa jornada envolvendo academias, reinos, tecnologia perdida, guerras, amizades e descobertas sobre sua própria origem. (Wikipedia)


A História

Ao contrário da maioria dos isekais modernos, Kenshi não chega como um herói predestinado.

Ele simplesmente...

...trabalha.

Cozinha.

Limpa.

Constrói.

Conserta equipamentos.

Ajuda qualquer pessoa.

Isso faz com que todos passem a confiar nele.

A história mostra algo extremamente raro:

a competência cotidiana.

Kenshi conquista respeito antes de conquistar poder.



Os Personagens

Kenshi Masaki

Talvez um dos protagonistas mais completos dos isekais.

É extremamente forte.

Mas nunca depende apenas da força.

Possui enorme inteligência emocional.

Aprende rapidamente qualquer profissão.

Nunca reclama.

Nunca demonstra arrogância.

Se precisasse trabalhar em um CPD dos anos 80, provavelmente começaria organizando JCLs antes de querer alterar um sistema crítico.


Lashara Earth XXVIII

Imperatriz extremamente inteligente.

Carismática.

Politicamente habilidosa.

Percebe rapidamente que Kenshi é muito mais valioso como aliado do que como inimigo.


Chiaia Flan

Guarda-costas da imperatriz.

Excelente piloto.

Orgulhosa.

Inicialmente desconfia de Kenshi.

Depois torna-se uma de suas maiores aliadas.


Aura Shurifon

Uma das personagens mais criativas do anime.

Sua personalidade muda conforme o período do dia.

Serve tanto para humor quanto para explorar diferentes comportamentos humanos.


Maria Nanadan

Assistente da imperatriz.

Responsável por boa parte do humor.


O Mundo de Geminar

Geminar parece medieval.

Mas isso é apenas aparência.

Na prática existe:

  • tecnologia perdida;

  • engenharia extremamente avançada;

  • biotecnologia;

  • energia cristalina;

  • robôs gigantes;

  • política internacional;

  • academias militares.

É quase como visitar uma instalação IBM de 1980 e descobrir um IBM z17 funcionando atrás de uma parede antiga.


Os Sacred Mechanoids

Os Seikijin não são robôs comuns.

São máquinas antigas.

Pouquíssimos conseguem pilotá-las.

Cada piloto imprime sua personalidade no combate.

As lutas são rápidas, estratégicas e exigem habilidade, não apenas força.


O que torna este anime diferente?

Enquanto quase todos os isekais modernos seguem uma estrutura semelhante, este faz escolhas incomuns:

1. O protagonista trabalha

Não passa os episódios apenas lutando.

Ele aprende profissões.

Ajuda pessoas.

Resolve problemas.


2. O mundo parece vivo

Cada reino possui:

  • economia;

  • cultura;

  • diplomacia;

  • interesses próprios.

Nada existe apenas para servir ao protagonista.


3. O protagonista não domina tudo

Apesar de poderoso, Kenshi continua aprendendo constantemente.


4. O humor é natural

Não depende apenas de fan service.

Grande parte da comédia surge das diferenças culturais entre Kenshi e Geminar.


5. Mechas fazem sentido

Os Sacred Mechanoids não existem apenas para criar cenas de ação.

São parte fundamental da política, da economia e do equilíbrio de poder.


As Aventuras

Durante a série acompanhamos:

  • guerras entre nações;

  • conspirações políticas;

  • missões diplomáticas;

  • treinamentos;

  • torneios;

  • descobertas arqueológicas;

  • exploração tecnológica;

  • desenvolvimento dos relacionamentos.

É uma aventura muito mais ampla do que simplesmente derrotar um vilão.


Temáticas

A obra discute vários temas interessantes:

Trabalho

O esforço diário vale mais do que talento.


Humildade

Quanto mais Kenshi aprende, mais humilde se torna.


Liderança

Ele nunca exige respeito.

Ele conquista respeito.


Cooperação

Nenhum personagem resolve tudo sozinho.


Adaptação

O verdadeiro poder não é destruir.

É conseguir viver em qualquer ambiente.


As Mensagens Ocultas

O verdadeiro herói serve primeiro

Antes de comandar, Kenshi aprende a servir.

No mundo corporativo isso lembra os melhores líderes técnicos.

Primeiro entendem o sistema.

Depois lideram mudanças.


Conhecimento é acumulativo

Toda habilidade aprendida por Kenshi reaparece futuramente.

Nada é desperdiçado.


Poder sem disciplina é perigoso

Diversos antagonistas possuem mais recursos.

Mesmo assim fracassam.

Porque não possuem equilíbrio emocional.


Civilizações desaparecem quando esquecem seu conhecimento

Geminar está repleto de tecnologias antigas.

Esse tema lembra diretamente um problema enfrentado por muitas empresas:

sistemas críticos sobrevivem por décadas, mas poucos entendem como realmente funcionam.


A Filosofia Bellacosa Mainframe

Este anime parece contar a jornada de um Padawan COBOL.

Observe a evolução:

Chegada ao ambiente
→ tudo é estranho.

Aprende observando.

Aceita tarefas simples.

Ganha confiança.

Conhece a arquitetura.

Resolve pequenos problemas.

Recebe responsabilidades maiores.

Torna-se especialista.

É exatamente o caminho de um novo programador IBM Z.

Ninguém começa alterando um sistema bancário de milhões de clientes.

Primeiro aprende o ambiente.

Depois entende os processos.

Só então recebe autonomia.


Impacto Cultural

Embora nunca tenha alcançado o sucesso comercial de Sword Art Online, Re:Zero ou Mushoku Tensei, a obra conquistou status de cult entre fãs de mechas e isekais clássicos. Muitos a consideram uma precursora de vários elementos que se tornariam comuns no gênero, especialmente a combinação de fantasia, tecnologia e protagonista transportado para outro mundo. (Reddit)


Curiosidades

  • Faz parte do universo expandido de Tenchi Muyo!, mas funciona muito bem como obra independente.

  • Os OVAs têm duração próxima à de um longa-metragem dividido em capítulos.

  • A tecnologia de Geminar lembra mais uma civilização altamente avançada em decadência do que uma fantasia medieval tradicional.

  • O design dos mechas, de Naohiro Washio, foge do estilo clássico de Gundam e busca uma aparência mais orgânica. (Wikipedia)


Classificação Bellacosa Mainframe

CritérioNota
História⭐⭐⭐⭐⭐ 9,4/10
Construção do Mundo⭐⭐⭐⭐⭐ 9,8/10
Personagens⭐⭐⭐⭐⭐ 9,5/10
Mechas⭐⭐⭐⭐⭐ 9,6/10
Política⭐⭐⭐⭐⭐ 9,2/10
Desenvolvimento do protagonista⭐⭐⭐⭐⭐ 9,9/10
Trilha sonora⭐⭐⭐⭐☆ 8,8/10
Humor⭐⭐⭐⭐☆ 8,7/10
Originalidade⭐⭐⭐⭐⭐ 9,3/10
Valor para fãs de isekai clássico⭐⭐⭐⭐⭐ 9,8/10

Considerações finais

Isekai no Seikishi Monogatari não é apenas um anime sobre outro mundo. É uma história sobre crescimento profissional, humildade e aprendizado contínuo. Enquanto muitos protagonistas modernos recebem poder instantâneo, Kenshi Masaki conquista seu espaço trabalhando, observando e ajudando quem está ao seu redor.

Sob a ótica do Bellacosa Mainframe, Geminar funciona como um grande datacenter corporativo: há tecnologias antigas, regras rígidas, sistemas críticos e profissionais experientes. Kenshi representa o Padawan que chega sem conhecer aquele universo, mas que evolui por curiosidade, disciplina e disposição para aprender. A verdadeira mensagem da obra é clara: o maior diferencial de um especialista não é a força, e sim a capacidade de aprender continuamente, colaborar com a equipe e transformar conhecimento em confiança. Essa lição permanece tão atual para um piloto de Sacred Mechanoid quanto para um engenheiro de software no IBM Z.


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