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

Translate

terça-feira, 23 de abril de 2024

Tensei Shitara Dai Nana Ōji Datta node, Kimama ni Majutsu o Kiwamemasu

 

Bellacosa Mainframe apresenta o anime Tensei Shitara Dai Nana

☕ Bellacosa Anime 

Tensei Shitara Dai Nana Ōji Datta node, Kimama ni Majutsu o Kiwamemasu

🧙 Quando um maluco por magia ganha acesso de administrador ao universo

Título original: 転生したら第七王子だったので、気ままに魔術を極めます
Romaji: Tensei Shitara Dai Nana Ōji Datta node, Kimama ni Majutsu o Kiwamemasu
Ocidental: I Was Reincarnated as the 7th Prince so I Can Take My Time Perfecting My Magical Ability

Autor: Kenkyo na Circle
Ilustrações da light novel: Meru
Mangá: Yōsuke Kokuzawa
Direção do anime: Jin Tamamura
Estúdio: Tsumugi Akita Animation Lab
Gêneros: fantasia, ação, aventura, comédia, reencarnação/isekai, magia
Estreia do anime: 1º de abril de 2024
Temporada 2: julho a setembro de 2025
Episódios: 12 + 12 = 24 episódios
Status do mangá: em publicação. (KManga)

E já começo com uma ressalva importante:

Lloyd é overpower para cacete.

Normalmente isso seria justamente um dos motivos para eu colocar um enorme sinal amarelo diante deste anime. Só que Dai Nana Ōji encontra uma maneira bastante inteligente — e completamente insana — de transformar o defeito em sua principal característica.

Porque Lloyd não está tentando tornar-se o homem mais poderoso do mundo.

Ele simplesmente quer saber como a magia funciona.

E isso muda tudo.



🧙‍♂️ A história

Na vida anterior, nosso protagonista era um mago comum absolutamente apaixonado por magia.

O problema era que naquele universo dedicação não bastava. Linhagem, aptidão e talento mágico importavam enormemente.

Ele não tinha os recursos necessários.

E morreu.

Seu último grande desejo não foi riqueza, vingança, mulheres ou poder político.

Era basicamente:

"Eu queria ter estudado mais magia."

Então o sujeito abre os olhos novamente.

Só que o RNG da reencarnação enlouqueceu.

Ele agora é Lloyd de Saloum, o sétimo príncipe do Reino de Saloum.

E nasceu praticamente com tudo aquilo que lhe faltava anteriormente: linhagem excepcional, recursos, acesso ao conhecimento e uma quantidade monstruosa de mana.

A própria apresentação oficial define Lloyd como um "magic otaku". (YouTube)

Imagine morrer sendo um programador que queria desesperadamente aprender mainframe e renascer dentro da IBM com:

USER-ID especial, RACF SPECIAL, acesso ao source de tudo, biblioteca inteira, CPU ilimitada e ninguém cobrando suas horas de laboratório.

Lloyd encontrou o paraíso.



👑 Só existe um pequeno problema: Lloyd é completamente maluco

Esse é o ponto em que o anime começa a ficar realmente divertido.

Um protagonista convencional encontra uma magia desconhecida:

"Isso pode ser perigoso."

Lloyd:

"QUE PORRA É ESSA? EU PRECISO DESMONTAR ISSO!"

😂

O garoto possui uma curiosidade quase patológica.

E isso produz uma inversão maravilhosa.

Os monstros começam a ter medo dele.

Demônios observam aquele garotinho aparentemente inofensivo e gradualmente percebem:

"Tem alguma coisa muito errada com essa criança."

E têm razão.



👿 Grim — quando o demônio percebe que escolheu o humano errado

Grim, ou Grimoire, é uma das melhores engrenagens dessa comédia.

Ele deveria representar o sobrenatural perigoso.

Só que encontra Lloyd.

A relação acaba subvertendo completamente a fórmula tradicional de "humano encontra demônio".

Porque existe um momento implícito recorrente na série:

o demônio começa a perceber que talvez o verdadeiro monstro da história seja aquele garotinho sorridente.

E Grim funciona também como nosso medidor.

Se até o demônio olha para alguma coisa que Lloyd está fazendo e pensa:

"Isso é absurdo!"

sabemos que o ponteiro já passou do vermelho.


⚔️ Sylpha — a espada ao lado da bomba nuclear

Sylpha é outra presença importante.

Ela é a criada e instrutora de esgrima de Lloyd e uma combatente extremamente competente.

Em praticamente qualquer outro anime, alguém com suas capacidades poderia facilmente ocupar o papel principal.

Aqui existe uma ironia interessante.

Sylpha vê Lloyd como alguém que precisa ser protegido.

Nós sabemos que isso é mais ou menos equivalente a:

proteger um IBM z17 usando um Commodore 64 como firewall.

Mas o relacionamento funciona justamente porque Lloyd continua ocupando socialmente o papel de criança/príncipe mesmo sendo uma aberração mágica.


🥋 Tao — outro sistema operacional

Tao é particularmente interessante porque introduz outra abordagem para o poder.

Ela trabalha com Qi, algo diferente da magia convencional que Lloyd conhece.

E sabemos imediatamente o que isso significa.

Lloyd não pensa:

"Não é magia, portanto não me interessa."

Ele pensa aproximadamente:

"Existe OUTRO mecanismo de energia funcionando neste universo?!"

Pronto.

Começa outra investigação.

Essa é uma característica muito boa da construção da série: novas técnicas funcionam como novas tecnologias para Lloyd estudar.

Magia, encantamento, Qi, poderes demoníacos, magia sagrada...

O anime vai acrescentando APIs ao mundo.

E Lloyd quer documentação de todas elas.


🧪 Lloyd não aprende magia. Ele faz engenharia reversa

Aqui está provavelmente a parte de 7th Prince que mais me agrada.

Lloyd não possui apenas poder.

Ele possui curiosidade técnica.

Existe uma enorme diferença.

O típico protagonista overpower recebe:

SKILL: INFINITE FIREBALL
POWER: 999999

e dispara.

Lloyd quer saber:

Como FIREBALL funciona?

Quem criou?

Qual é a estrutura?

Posso alterar?

Posso combinar?

Qual é o limite?

O que acontece se eu remover isto?

E se aumentar aquilo?

E se executar de uma maneira que ninguém jamais tentou?

Isso é muito mais interessante.

Ele transforma magia em pesquisa aplicada.


💻 Bellacosa Mainframe explica Lloyd usando COBOL

Imagine este programa:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. MAGIC01.

       PROCEDURE DIVISION.

           PERFORM FIREBALL
           PERFORM TELEPORT
           PERFORM BARRIER

           STOP RUN.

Um usuário normal executaria MAGIC01.

Lloyd perguntaria:

"Cadê o source?"

Entregamos o source.

Cinco minutos depois:

"Onde está o assembler gerado?"

Entregamos.

Depois:

"Quero entender o runtime."

Depois:

"E se eu alterar diretamente a memória?"

Depois:

"Posso executar FIREBALL dentro de TELEPORT?"

Nesse momento Grim entra correndo:

"LLOYD, PELO AMOR DOS DEUSES, PARE!"

😂

Essa é a série.


🩸 E existe algo perturbador em Lloyd

Por baixo da comédia existe uma característica que acho bastante interessante.

Lloyd tem uma relação estranha com perigo.

Quando encontra algo extraordinariamente poderoso, ele frequentemente demonstra mais fascinação do que medo.

Isso faz sentido psicologicamente dentro da premissa.

Na primeira vida, ele morreu limitado por aquilo que não podia aprender.

Agora possui uma segunda oportunidade.

Portanto, para ele, encontrar algo desconhecido é quase irresistível.

É aí que o personagem deixa de ser simplesmente:

criança overpower.

e passa a ser:

pesquisador obsessivo que casualmente possui poder suficiente para destruir o laboratório.


⛪ Segunda temporada — descobriram outra API: Holy Magic

Depois do arco de Guisarme, Lloyd descobre algo que imediatamente aciona seus neurônios:

magia sagrada.

A segunda temporada começa em 9 de julho de 2025 e leva Lloyd em direção à Igreja justamente porque ele quer compreender esse novo tipo de magia. A divulgação da Bandai Namco Filmworks descreveu explicitamente a temporada como a busca de Lloyd pelos segredos da Holy Magic. (Dai Nanao Ji)

Isso é perfeitamente coerente com o personagem.

Ele não está interessado na Igreja primeiramente pela religião.

Está interessado porque alguém mostrou uma tecnologia mágica que ele ainda não domina.

É quase:

LLOYD> DISPLAY MAGIC,SYSTEM

ARCANE     ACTIVE
QI         ACTIVE
DEMONIC    ACTIVE
HOLY       UNKNOWN

LLOYD> INVESTIGATE HOLY

GRIM> NÃO.

LLOYD> CONFIRM

SYSTEM> INVESTIGATION STARTED

Grim: "Merda."


⛪ Magia sagrada e Guitane

Aqui a série ganha uma oportunidade de explorar algo um pouco mais interessante que simplesmente "magia nova".

A magia sagrada envolve conceitos ligados a purificação, fé e Igreja.

E Lloyd novamente tenta compreender algo que tradicionalmente seria apresentado como transcendental.

Isso cria um contraste interessante:

religião trata o fenômeno como sagrado; Lloyd trata o fenômeno como pesquisável.

A temporada culmina no confronto envolvendo Guitane, com o episódio 12 trabalhando justamente a tentativa de Lloyd de usar a Purificação sobre ele. (Prime Video)

É quase o conflito eterno entre:

"É um milagre."

e

"Legal. Agora me mostre a documentação."


🎨 A estética engana bastante

Este é outro elemento peculiar.

Visualmente, Lloyd é extremamente delicado.

Pequeno.

Bonitinho.

Quase andrógino.

Olhos enormes.

Expressões exageradas.

Personagens coloridos.

Grim frequentemente parece mascote.

Então começa a batalha.

BOOOOOOM.

A animação subitamente apresenta círculos mágicos enormes, criaturas grotescas, energia, deformações, explosões e escalas de poder absurdas.

Essa diferença entre design fofo e violência mágica gigantesca é deliberada.

O mangá é especialmente conhecido pelo trabalho visual de Yōsuke Kokuzawa. Em entrevista publicada pela própria K Manga/Kodansha, ele explicou que escolheu adaptar a obra porque enxergou justamente a combinação entre momentos engraçados, batalhas intensas e a personalidade peculiar de Lloyd. (K MANGA)


📚 Light novel → mangá → anime

A genealogia da obra também é interessante.

A história começou como web novel de Kenkyo na Circle, posteriormente virou light novel da Kodansha com ilustrações de Meru.

Depois veio o mangá de Yōsuke Kokuzawa.

E finalmente o anime.

A Kodansha continua publicando oficialmente o mangá; em agosto de 2026, o K Manga estava no capítulo 222, o que deixa bastante material além daquilo que vimos nas duas temporadas do anime. (KManga)

Mangá oficial no K Manga/Kodansha

Isso também significa algo importante:

os 24 episódios não encerram a história.

Há muito mais mundo depois deles.


🎮 Games?

A franquia não nasceu de game e a estrutura narrativa também não depende daquela interface explícita de RPG encontrada em muitos isekais.

E isso é uma vantagem.

Não precisamos assistir Lloyd abrindo constantemente:

LEVEL 999
MAGIC +500
SKILL ACQUIRED

O sistema de poder pode ser exagerado, mas a graça está mais em descobrir, compreender e modificar magia do que simplesmente acumular pontos.


🧠 A mensagem escondida que eu encontro em 7th Prince

Por trás de toda a palhaçada existe uma ideia curiosamente bonita:

ter capacidade não elimina a necessidade de continuar aprendendo.

Lloyd poderia simplesmente aceitar:

"Sou o mais poderoso."

Fim.

Mas não.

Quanto mais sabe, mais coisas descobre que ainda não sabe.

Isso é extremamente próximo da experiência de alguém que trabalha décadas com tecnologia.

Você aprende COBOL.

Descobre CICS.

Aprende CICS.

Descobre Db2.

Aprende Db2.

Descobre RACF.

Depois MQ.

IMS.

REXX.

JCL.

USS.

APIs.

Containers.

DevOps.

IA.

E finalmente percebe:

o mapa ficou maior conforme você aprendeu.

Essa talvez seja a melhor mensagem escondida de Dai Nana Ōji.


🥚 Easter egg Bellacosa

Imagino Lloyd entrando pela primeira vez num datacenter IBM.

Ele observa o mainframe.

Silêncio.

Encosta a mão no rack.

Seus olhos começam a brilhar.

Grim imediatamente pergunta:

"Lloyd... o que você está pensando?"

Lloyd:

"Uma arquitetura criada há mais de 60 anos ainda executa aplicações antigas e modernas no mesmo ecossistema..."

Grim:

"Lloyd..."

Lloyd:

"Quero ver o microcode."

Grim:

"LLOYD, NÃO!"

Às 03:17, surge no console:

ICH408I USER(LLOYD)
ACCESS DENIED

Cinco segundos depois:

ICH408I USER(GRIM)
ACCESS DENIED

Grim:

"POR QUE MEU USER-ID ESTÁ AQUI?!"

😂


⚖️ Classificação Bellacosa Anime

Eu colocaria assim:

História: ⭐⭐⭐⭐☆
Construção do mundo: ⭐⭐⭐⭐☆
Personagens: ⭐⭐⭐⭐☆
Animação nas batalhas: ⭐⭐⭐⭐⭐
Comédia: ⭐⭐⭐⭐☆
Originalidade dentro da reencarnação: ⭐⭐⭐⭐☆
Protagonista: ⭐⭐⭐⭐☆
Perigo real para Lloyd: ⭐☆☆☆☆
Síndrome overpower: ⭐⭐⭐⭐⭐
Diversão: ⭐⭐⭐⭐⭐
Vontade de descobrir a próxima maluquice: ⭐⭐⭐⭐⭐

Nota Bellacosa: 8,4/10

O overpower continua sendo seu maior problema. Quem procura tensão semelhante a Goblin Slayer, consequências brutais como em Teogonia ou evolução sofrida como em Mushoku Tensei provavelmente vai sentir falta de risco.

Mas 7th Prince faz algo inteligente:

não tenta fingir que Lloyd não é overpower.

Abraça completamente o absurdo.

E troca a pergunta:

"Será que Lloyd conseguirá derrotar o inimigo?"

por uma muito mais divertida:

"O que esse pequeno psicopata científico vai fazer quando descobrir como o poder do inimigo funciona?"

Aí o anime encontrou sua personalidade.

E é justamente por isso que Tensei Shitara Dai Nana Ōji consegue sobreviver ao pecado que mata tantos isekais:

Lloyd não quer chegar ao nível máximo.

Ele quer abrir o sistema e descobrir como foi programado.

E para um programador, isso é perigosamente fácil de entender. 😈

segunda-feira, 22 de abril de 2024

Uncharted Entra no CPD — A IA Encontrou o COBOL, Mas o Tesouro Estava Escondido no JCL

 

Bellacosa Mainframe e a ia encontrou o mainframe cobol

☕ Um Café no Bellacosa Mainframe

Uncharted Entra no CPD — A IA Encontrou o COBOL, Mas o Tesouro Estava Escondido no JCL

Ou: por que Nathan Drake consegue ler o mapa, mas ainda precisa descobrir a passagem secreta, o CALL dinâmico, a PROC esquecida e o scheduler que alguém alterou em 2009

Existe uma cena clássica em qualquer aventura de Uncharted.

Nathan Drake encontra um mapa.

O papel está amarelado.

Há símbolos misteriosos.

Uma anotação feita há duzentos anos aponta para algum lugar impossível.

Sully olha para aquilo e provavelmente pensa:

— Garoto, isso vai dar problema.

Nathan responde alguma coisa otimista, pega a mochila, recarrega a arma e vai atrás do tesouro.

O erro seria imaginar que, porque ele encontrou o mapa, a aventura acabou.

Na realidade, foi exatamente naquele momento que ela começou.

Bem-vindo à modernização de aplicações mainframe com Inteligência Artificial.

Hoje temos ferramentas fantásticas capazes de pegar milhões de linhas COBOL, PL/I, Assembler, JCL e copybooks e fazer coisas que vinte anos atrás exigiriam equipes inteiras.

Elas podem:

  • explicar programas;

  • encontrar referências;

  • montar árvores de chamadas;

  • gerar documentação;

  • sugerir regras de negócio;

  • criar testes;

  • traduzir código;

  • localizar dependências;

  • produzir diagramas;

  • auxiliar numa migração.

Um programador COBOL iniciante olha para isso e pensa:

“Pronto. Coloca o repositório na IA e ela descobre o sistema.”

Calma, jovem explorador.

Você encontrou o mapa do tesouro.

Não encontrou necessariamente o tesouro.

E talvez nem saiba ainda onde estão as cobras.



Prólogo — Nathan Drake encontrou o COBOL

Imagine que chegamos a uma empresa fictícia chamada Bellacosa International Treasure Bank.

O banco possui:

18.000 programas COBOL
9.400 copybooks
26.000 JCLs
4.000 PROCs
centenas de tabelas Db2
milhares de datasets
CICS
IMS
MQ
VSAM
Assembler
REXX
sort cards
scheduler

Além disso, algumas pessoas que criaram partes importantes do sistema já se aposentaram.

Outras trabalham ali há trinta anos e sabem coisas que nunca foram documentadas.

A diretoria anuncia:

“Vamos modernizar.”

A palavra ecoa pelo CPD.

Modernizar.

Maravilhosa palavra.

Pode significar desde:

compilar COBOL com versão mais nova

até:

migrar metade da empresa para cloud
e descobrir seis meses depois
que alguém esqueceu um arquivo EBCDIC.

Para ajudar, chega a Inteligência Artificial.

Jogamos nela:

PAY001.CBL

A IA analisa o programa.

Encontra:

CALL 'PAY002'
CALL 'PAY003'

EXEC SQL
   SELECT ...
END-EXEC

Ela produz:

PAY001
 ├── PAY002
 ├── PAY003
 └── DB2

Excelente.

Nathan Drake encontrou o primeiro pedaço do mapa.

Só que existe isto:

CALL WS-PROGRAM USING WS-AREA

Sully imediatamente pergunta:

“E quem diabos é WS-PROGRAM?”

Ótima pergunta.


1. O primeiro templo — programa não é aplicação

Essa é provavelmente uma das lições mais importantes para quem começa em mainframe.

Quando estudamos programação, pensamos:

programa = aplicação

Isso pode funcionar num pequeno exercício.

Você tem:

CALCULA.CBL

O programa lê valores, calcula alguma coisa e termina.

Mas aplicações corporativas que nasceram há décadas são outra criatura.

Um sistema real pode ser:

COBOL
+
COPYBOOK
+
JCL
+
PROC
+
DB2
+
VSAM
+
CICS
+
IMS
+
MQ
+
Scheduler
+
Control Tables
+
Assembler
+
REXX
+
Configuração
+
Dados
+
Operação
+
Conhecimento humano

O COBOL é importante.

Mas ele é apenas uma sala do templo.

E algumas das passagens secretas ficam fora dela.


2. O mapa encontrado pela IA

Vamos usar um programa simples.

IDENTIFICATION DIVISION.
PROGRAM-ID. PAY001.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-PROGRAM PIC X(8).

PROCEDURE DIVISION.

    MOVE 'PAY002' TO WS-PROGRAM

    CALL WS-PROGRAM

    GOBACK.

Um analisador consegue identificar:

CALL variável

Mas o destino pode depender de lógica anterior.

Agora imagine:

EXEC SQL
   SELECT PROGRAM_NAME
     INTO :WS-PROGRAM
     FROM CONTROL_TABLE
    WHERE OPERATION = :WS-OPERATION
END-EXEC

CALL WS-PROGRAM.

O programa chamado não está literalmente escrito no comando CALL.

Pode ser:

PAY002
PAY003
PAY099
PAY777

dependendo do conteúdo da tabela.

A IA pode perceber que existe uma chamada dinâmica.

Mas sem conhecer os valores possíveis daquela tabela, ela não consegue afirmar com certeza qual programa será chamado.

Portanto:

SOURCE CODE

diz:

“Existe uma chamada dinâmica.”

Enquanto:

RUNTIME

pode dizer:

“Nas últimas 48 horas, PAY002 foi chamado 800 mil vezes e PAY777 foi chamado três vezes.”

Essas três execuções podem ser exatamente as três que movem cinquenta milhões de reais.

Agora você entende por que quantidade de execução e importância de negócio não são a mesma coisa.


3. Curiosidade Bellacosa — o código que quase nunca executa pode ser o mais importante

Um iniciante normalmente pensa:

“Se roda pouco, deve ser pouco importante.”

Não necessariamente.

Imagine:

ROTINA-A

executa 4 milhões de vezes por dia.

Ela formata um nome.

Agora:

ROTINA-B

executa uma vez por ano.

Ela fecha o exercício fiscal.

Qual você prefere quebrar?

Pois é.

Modernização exige algo que Uncharted ensina muito bem:

Nem toda porta escondida guarda o mesmo perigo.


4. O segundo templo — COPYBOOK não é só Ctrl+C corporativo

No começo, copybook parece simples.

COPY CLIENTE.

E dentro:

01 CLIENTE.
   05 CODIGO PIC 9(08).
   05 TIPO   PIC X.
   05 SALDO  PIC S9(11)V99 COMP-3.

Você pensa:

“É apenas uma estrutura compartilhada.”

Sim.

E não.

Esse layout pode ser usado por:

programa COBOL online
batch noturno
Easytrieve
SORT
MQ
arquivo VSAM
interface externa
warehouse
Java
Python
ETL

Agora alguém altera:

01 CLIENTE.
   05 CODIGO PIC 9(08).
   05 PAIS   PIC X(02).
   05 TIPO   PIC X.
   05 SALDO  PIC S9(11)V99 COMP-3.

Do ponto de vista da aplicação que recompilou:

Tudo certo.

Mas talvez exista um programa distante que não tenha copybook algum.

Ele simplesmente sabe:

byte 9 = tipo do cliente

Você inseriu dois bytes antes desse campo.

Agora:

byte 9

não significa mais a mesma coisa.

Parabéns.

Você acabou de descobrir uma armadilha do templo.


5. Nathan Drake encontra REDEFINES e quase cai num abismo

Agora chegamos numa das maravilhas do COBOL:

01 WS-REGISTRO.
   05 WS-TIPO PIC X.
   05 WS-DADOS PIC X(100).

01 WS-CLIENTE REDEFINES WS-REGISTRO.
   05 ...

01 WS-CONTA REDEFINES WS-REGISTRO.
   05 ...

O mesmo conjunto de bytes pode ser interpretado de formas diferentes.

Para um analisador estático:

layout CLIENTE existe
layout CONTA existe

Perfeito.

Mas qual deles é usado em produção?

Talvez:

CLIENTE = 99,98%
CONTA   = 0,02%

O problema é que aqueles 0,02% podem aparecer somente no encerramento anual.

Você migra o sistema em maio.

Testa maio.

Testa junho.

Testa julho.

Tudo verde.

Chega dezembro.

O velho sistema olha para você e diz:

SOC7

Feliz Natal.


6. Terceiro templo — JCL é parte da aplicação

Aqui muitos programadores iniciantes cometem um erro.

Eles estudam COBOL e enxergam JCL como:

“A coisa estranha que executa meu programa.”

Só que JCL pode mudar drasticamente o comportamento real.

Considere:

//STEP10 EXEC PGM=PAY001
//INPUT  DD DSN=PROD.PAY.INPUT

Você conclui:

PAY001 recebe PROD.PAY.INPUT

Agora descubra que o job verdadeiro chama uma PROC:

//STEP10 EXEC PROC=PAYPROC

e depois faz override:

//STEP10.RUN.INPUT DD DSN=PROD.SPECIAL.PAY.INPUT

Pronto.

A informação originalmente lida na PROC não corresponde necessariamente ao dataset utilizado naquela execução.

É exatamente como encontrar um mapa do templo mostrando uma porta.

Só que alguém construiu uma passagem lateral em 2004.

E nunca atualizou o mapa.


7. PROC — a passagem secreta atrás da estante

Cataloged procedures existem para reutilizar JCL.

Ótimo conceito.

Mas imagine décadas de alterações.

Temos:

JOB
 ↓
PROC
 ↓
PROC
 ↓
override
 ↓
symbolic parameter
 ↓
dataset

A IA precisa resolver isso tudo.

Porque:

JCL que você vê

não é necessariamente:

JCL efetivamente executado

Antes de modernizar um fluxo batch, tente produzir a versão resolvida do JCL.

Ou seja:

qual PGM?
qual PARM?
qual dataset?
qual DISP?
qual STEPLIB?
qual PROC?
qual override?

Essa é uma excelente prática de discovery.


8. Quarto templo — scheduler contém lógica de negócio

A primeira vez que alguém percebe isso geralmente fica olhando para a tela alguns segundos.

Imagine:

JOBB

executa somente se:

JOBA terminou OK
AND hoje é último dia útil
AND FILE-X chegou
AND país != feriado
AND JOBZ não está rodando

Onde está essa lógica?

Talvez não esteja no COBOL.

Talvez nem no JCL.

Está no:

Control-M
IBM Workload Scheduler
CA-7
ESP
ou outro scheduler

Portanto:

scheduler configuration

é parte da aplicação.

Se durante uma migração você copiar:

COBOL
JCL
DB2

mas não reproduzir corretamente a orquestração, você poderá ter um sistema funcional que executa na hora errada.

E em processamento financeiro, “certo na hora errada” costuma significar simplesmente:

ERRADO

9. Quinto templo — control table é código disfarçado de dado

Aqui Nathan Drake acende a tocha.

Imagine esta tabela:

OPERATION   PROGRAM
---------------------
PAYMENT     PAY001
REFUND      REF010
REVERSAL    REV777

E o COBOL:

SELECT PROGRAM
INTO WS-PROGRAM
FROM CONTROL_TABLE
WHERE OPERATION = WS-OPERATION.

CALL WS-PROGRAM.

Agora alguém executa:

UPDATE CONTROL_TABLE
SET PROGRAM = 'PAY900'
WHERE OPERATION = 'PAYMENT';

Pergunta:

O source COBOL mudou?

Não.

Houve novo compile?

Não.

Houve link-edit?

Não.

O comportamento da aplicação mudou?

SIM.

Logo:

Alguns dados são, na prática, configuração executável.

Essa é uma das razões pelas quais repositório de source não representa obrigatoriamente todo o sistema.


10. Sexto templo — compiler options também importam

Agora entramos numa área que muitos iniciantes ignoram.

Você possui:

PAY001.CBL

e imagina que o source define tudo.

Mas programas COBOL são compilados.

E opções do compilador podem alterar comportamento.

Entre elas encontramos temas relacionados a:

aritmética
truncamento
debug
otimização
chamadas
compatibilidade
representação
runtime checking

Ou seja:

mesmo source
+
configuração diferente
=
possível comportamento diferente

É por isso que discovery sério deve coletar:

source
compiler listing
compiler options
binder information
load module information

A IA não deveria simplesmente olhar um .CBL solitário e proclamar:

“Eu compreendi tudo.”

Nathan Drake olhando uma inscrição na parede não sabe automaticamente qual mecanismo ela aciona.

Ele precisa olhar o chão também.


11. Sétimo templo — Db2 Package: o mapa que lembra como chegar ao dado

Com SQL estático em COBOL, existe outra peça importante.

Você escreve:

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CONTA
    WHERE CONTA_ID = :WS-CONTA
END-EXEC

Mas o ecossistema de execução envolve também elementos de Db2 como:

DBRM
BIND
PACKAGE
PLAN
access path

Dependendo do ambiente e da arquitetura.

Para modernization discovery, você quer saber:

qual programa usa qual package?
qual package referencia quais objetos?
qual versão?
qual bind?

Porque a arquitetura real não termina no EXEC SQL.


12. Oitavo templo — runtime é o chão onde as pegadas aparecem

Chegamos ao conceito mais poderoso do artigo original.

Static analysis diz:

“Isso pode acontecer.”

Runtime diz:

“Isso aconteceu.”

É uma diferença brutal.

Considere:

PGMA pode chamar:
PGMB
PGMC
PGMD

Static analysis apresenta três caminhos.

Mas produção mostra:

PGMB = 9.000.000 execuções
PGMC = 37 execuções
PGMD = 0 execuções

Agora temos evidência operacional.

Podemos olhar:

SMF
logs
CICS
Db2 traces
IMS
MQ
scheduler history
dataset activity
job history
APM

Cada plataforma terá fontes diferentes.

O objetivo é confrontar:

POSSIBLE

contra:

OBSERVED

Isso é ouro para discovery.


13. Mas cuidado: “não observado” não significa “não existe”

Essa é outra armadilha.

Suponha:

PGMD = 0 execuções em 90 dias

Podemos aposentá-lo?

Talvez.

Mas pergunte:

ele roda mensalmente?
trimestralmente?
anualmente?
só em desastre?
somente em fechamento?
somente em contingência?

Um programa DR pode não executar durante cinco anos e continuar essencial.

Portanto:

NOT OBSERVED

não significa automaticamente:

DEAD CODE

Isso precisa virar hipótese.


14. A grande tabela do explorador: D, R, H e U

Uma técnica extremamente útil seria classificar cada descoberta.

Use:

[D] Deterministic
[R] Runtime observed
[H] Hypothesis
[U] Unknown

Por exemplo:

[D] PAY001 contém CALL PAY002.

[D] JOBPAY executa PAY001.

[R] PAY001 executou 8.231 vezes em 30 dias.

[R] PAY002 foi carregado 7.994 vezes.

[H] Parte das demais execuções seleciona PAY010 dinamicamente.

[U] 237 targets ainda não resolvidos.

Isso muda completamente a conversa.

Em vez de dizer:

“Mapeamos a aplicação.”

Você diz:

“Temos 91% das relações críticas confirmadas, 7% observadas apenas em runtime e quatro dependências de alto impacto ainda não resolvidas.”

Muito mais profissional.


15. Curiosidade — 100% de linhas analisadas pode significar quase nada

Imagine o relatório:

18 milhões de linhas analisadas
100% repository coverage

Executivo feliz.

PowerPoint verde.

Mas escondido numa nota:

11 dynamic CALLs unresolved
3 vendor modules sem source
2 interfaces externas desconhecidas
1 scheduler condition não documentada

Então temos:

100% CODE SCANNED

mas não:

100% SYSTEM UNDERSTOOD

Por isso o objetivo de discovery não deveria ser obsessão por “completude”.

Deveria ser redução controlada de incerteza.


16. O conceito Bellacosa de UNKNOWN WITH CONSEQUENCE

Nem todo desconhecido merece a mesma energia.

Imagine:

UnknownContextoRisco
CALL desconhecidorelatório internobaixo
arquivo desconhecidoprocesso mensalmédio
consumidor desconhecidopagamentocrítico
módulo sem sourcesettlementcrítico

Agora discovery passa a priorizar risco.

Podemos usar uma heurística:

RISCO =
PROBABILIDADE
× IMPACTO
× INCERTEZA

Não precisa ser ciência matemática perfeita.

É uma ferramenta de decisão.

Exemplo:

Dynamic CALL X

Probabilidade: 5
Impacto:       5
Incerteza:     4

Risco = 100

Compare com:

Relatório antigo

Probabilidade: 1
Impacto:       1
Incerteza:     4

Risco = 4

Você sabe onde colocar Nathan Drake primeiro.


17. Nono templo — conhecimento tribal

Agora chegamos ao inimigo final.

Pergunte:

“Por que JOBABC não pode rodar antes do JOBXYZ?”

Resposta:

“Porque dá problema.”

Pergunte:

“Onde está documentado?”

Resposta:

“Não está.”

“Scheduler?”

“Também não.”

“JCL?”

“Não.”

“Então como vocês sabem?”

Resposta:

“O Cláudio sabe.”

Cláudio está na empresa desde 1987.

Cláudio sabe que:

quando último dia útil cai numa sexta-feira
e segunda é feriado
JOBABC precisa esperar arquivo X

Onde está essa regra?

Na cabeça do Cláudio.

Isso se chama:

institutional knowledge

ou, informalmente:

conhecimento tribal.

É patrimônio operacional.

E é também um risco enorme.


18. Aqui IA pode virar Indiana Jones... quer dizer, Nathan Drake corporativo

Entrevistas com SMEs podem ser transcritas.

A IA pode extrair afirmações.

Exemplo:

Cláudio diz:

“PAY099 só roda quando há reversão manual.”

Transformamos isso em:

[H] PAY099 executa apenas em reversões manuais.

Depois verificamos:

runtime history
scheduler
transactions
JCL
Db2

Se confirmar:

[D/R] CONFIRMED

Se não:

CONTRADICTION

Isso é muito mais poderoso do que simplesmente produzir atas de reunião.

Estamos transformando memória humana em hipóteses verificáveis.


19. O grande perigo — IA verificando IA

Agora chegamos à armadilha mais moderna de todas.

Imagine:

IF STATUS = 'A'

A IA interpreta:

A = ACTIVE

Só que no sistema:

A = AWAITING SETTLEMENT

A IA gera documentação:

STATUS A means ACTIVE

Depois cria teste:

Given an active account
STATUS = A

Depois gera Java.

Depois executa seus próprios testes.

Resultado:

PASS
PASS
PASS
PASS

A diretoria comemora.

Só existe um pequeno problema.

Tudo está errado.

Mas está coerentemente errado.

Esse é um dos maiores perigos da geração automática.


20. Regra Bellacosa: quem escreve a prova não pode sozinho corrigir a própria prova

Ou, tecnicamente:

Verification must exist outside the generation loop.

Se IA:

interpreta
gera
testa
valida

tudo usando a mesma hipótese inicial, ela pode perpetuar o erro.

Precisamos de fontes externas de verdade.

Exemplos:

compiler output
runtime traces
immutable specs
regression suites
parallel run
production reconciliation
known datasets
SME validation

Ou seja:

AI OUTPUT
     ↓
INDEPENDENT EVIDENCE

e não:

AI OUTPUT
     ↓
AI CHECKS AI
     ↓
PARABÉNS

21. O décimo templo — parallel run

Uma técnica poderosíssima em modernização é executar:

sistema antigo

e:

sistema novo

em paralelo.

Mesmas entradas.

Depois comparar:

saídas
saldos
transações
contagens
erros
tempos
efeitos

Exemplo:

LEGACY:
10.000.000 transações
resultado financeiro X

NEW:
10.000.000 transações
resultado financeiro X

Excelente.

Agora imagine:

NEW divergiu em 17 transações

Essas 17 são lixo?

Ou são justamente:

clientes judiciais
contas especiais
operações antigas
casos de fechamento

A reconciliação encontra justamente as pequenas exceções que documentação gerada pode esconder.


22. O verdadeiro mapa: Evidence Graph

Se eu estivesse montando uma arquitetura de discovery moderna, criaria um grafo.

Nós:

PROGRAM
COPYBOOK
JOB
PROC
STEP
DATASET
TABLE
PACKAGE
TRANSACTION
QUEUE
API
SCHEDULER
CONTROL TABLE
LOAD MODULE

Relacionamentos:

CALLS
READS
WRITES
EXECUTES
USES
BINDS
TRIGGERS
CONSUMES
PRODUCES
DEPENDS ON

Mas não basta guardar a relação.

Precisamos guardar a evidência.

Exemplo:

PAY001
   |
   | CALLS
   |
PAY002

Metadata:

source: compiler listing
type: deterministic
confidence: 100%

Outro:

PAY001
   |
   | CALLS
   |
PAY099

Metadata:

source: runtime trace
observed: 37 times
type: runtime

Outro:

PAY001
   |
   | POSSIBLY CALLS
   |
PAY777

Metadata:

source: LLM inference
type: hypothesis
confidence: 63%

Agora sim temos algo valioso.

Não apenas:

knowledge graph.

Mas:

evidence-backed knowledge graph.


23. Passo a passo para um iniciante fazer discovery

Vamos transformar tudo isso numa sequência prática.

Passo 1 — escolha uma capacidade pequena

Não comece:

“Vamos entender o banco inteiro.”

Comece:

“Vamos entender consulta de saldo.”

Ou:

“Vamos entender pagamento.”

Passo 2 — encontre os pontos de entrada

Pode ser:

CICS transaction
JCL
API
MQ
IMS transaction
batch

Pergunte:

como essa capacidade começa?

Passo 3 — descubra os programas

Mapeie:

programas chamados
CALLs estáticos
CALLs dinâmicos
subprogramas
assembler
utilities

Passo 4 — expanda COPYBOOKs

Não analise apenas:

COPY ACCOUNT.

Resolva o conteúdo real.

Observe:

offset
length
REDEFINES
OCCURS
COMP
COMP-3

Passo 5 — resolva JCL e PROC

Descubra o job efetivo.

Inclua:

symbolics
overrides
datasets
STEPLIB
PARM
COND

Passo 6 — analise acesso a dados

Procure:

Db2
VSAM
QSAM
IMS
MQ
files

Passo 7 — busque configuração externa

Inclua:

scheduler
control tables
CICS definitions
IMS definitions
Db2 package info
MQ configuration

Passo 8 — olhe produção

Pergunte:

o que realmente executou?

Use evidência disponível.


Passo 9 — registre unknowns

Exemplo:

U-001 Dynamic CALL unresolved
U-002 Consumer of dataset unknown
U-003 Vendor module source unavailable

Passo 10 — classifique risco

Algo como:

LOW
MEDIUM
HIGH
CRITICAL

Passo 11 — use IA para correlação

Agora sim.

Entregue os fatos.

Peça:

explique
correlacione
documente
sugira testes
aponte inconsistências

A IA passa a trabalhar sobre evidência.


Passo 12 — valide fora da IA

Use:

compiler
runtime
SME
tests
parallel run

24. Easter egg — “Sic Parvis Magna”

Fãs de Uncharted reconhecerão imediatamente:

Sic Parvis Magna

“Grandeza a partir de pequenos começos.”

É praticamente uma metodologia perfeita para modernização.

Não tente modernizar:

30 milhões de linhas

de uma vez.

Comece:

1 capability
1 fluxo
1 domínio
1 slice

Descubra.

Valide.

Execute.

Aprenda.

Atualize o mapa.

Depois avance.

small slice
↓
evidence
↓
deployment
↓
observation
↓
new evidence
↓
next slice

Sic Parvis Magna, versão z/OS.


25. Discovery não deve terminar numa enciclopédia

Outro erro comum:

Passamos nove meses criando:

4.000 páginas de documentação

Todos ficam felizes.

Seis meses depois:

20% já está desatualizado.

Discovery não existe para produzir a Wikipédia definitiva do mainframe.

Existe para permitir decisão.

Exemplo:

RETAIN
EXPOSE
REPLACE
RETIRE
REIMAGINE

26. RETAIN — não mexa no templo que está funcionando

Às vezes você descobre:

COBOL
estável
rápido
barato
confiável
bem testado

Então por que reescrever?

Modernização pode significar:

novo compiler
CI/CD
APIs
testes
observabilidade
Git
DevOps

mantendo o core.


27. EXPOSE — abra uma porta moderna

Imagine:

CICS → COBOL

que funciona há vinte anos.

Talvez a necessidade moderna seja:

Mobile
   ↓
REST API
   ↓
CICS
   ↓
COBOL

Você não precisa necessariamente destruir o castelo.

Talvez baste construir uma ponte.


28. REPLACE — troque o que realmente perdeu sentido

Existem partes que podem ser substituídas.

Exemplo:

relatório antigo
utility obsoleto
interface redundante

Mas a decisão deve nascer da descoberta.

Não do preconceito:

“É COBOL, portanto precisa morrer.”


29. RETIRE — finalmente aposente o fantasma

Discovery pode encontrar programas que:

não executam
não são chamados
não têm consumidores
não possuem valor

Ótimo candidato a aposentadoria.

Mas lembre:

not observed
≠
not needed

Cheque ciclos anuais, contingência e requisitos regulatórios.


30. REIMAGINE — não traduza o passado linha por linha

Aqui mora uma das maiores confusões de modernization.

Você pega:

COBOL

e traduz para:

Java

Parabéns.

Agora você pode ter:

um sistema COBOL escrito em Java.

As mesmas:

dependências
batch windows
control tables
arquivos
acoplamentos
processos

continuam lá.

Modernizar não é necessariamente trocar linguagem.

Reimaginar significa perguntar:

“Como essa capacidade deveria existir hoje?”

Isso pode gerar uma arquitetura completamente diferente.


31. Migration e modernization são parentes, não gêmeos

Migrar:

A → B

Modernizar:

A → algo melhor

Às vezes coincidem.

Às vezes não.

Você pode migrar sem modernizar.

Pode modernizar sem migrar.

E pode realizar uma migração tão ruim que termina com um sistema mais complexo do que antes.

Nathan Drake também sabe disso.

Nem todo caminho novo leva ao tesouro.

Alguns levam ao precipício.


32. Métricas que não impressionariam Sully

Evite celebrar apenas:

20 milhões de linhas escaneadas
50 milhões de tokens
900 diagramas gerados
10 mil páginas documentadas

Essas são métricas de atividade.

Pergunte:

Quantos riscos críticos fechamos?

Quantas decisões foram tomadas?

Quantas dependências foram confirmadas?

Quantos unknowns de alto impacto restam?

Quantas mudanças chegaram com segurança à produção?

Qual KPI melhorou?

Isso é resultado.


33. A aventura completa

No final, nosso mapa fica assim:

SOURCE
   ↓
STATIC ANALYSIS
   ↓
CONFIGURATION
   ↓
RUNTIME
   ↓
EVIDENCE
   ↓
AI
   ↓
INTERPRETATION
   ↓
HYPOTHESES
   ↓
VALIDATION
   ↓
RISK
   ↓
DECISION

E finalmente:

RETAIN
EXPOSE
REPLACE
RETIRE
REIMAGINE

Essa é uma metodologia muito mais saudável do que:

COBOL
 ↓
LLM
 ↓
Java
 ↓
PRODUCTION

Se alguém propuser exatamente esse último diagrama numa reunião, recomendo verificar se Sully já está preparando o avião para fugir.


Epílogo — o tesouro nunca esteve apenas no COBOL

O programador iniciante chega ao mainframe e pensa:

“Preciso aprender COBOL.”

Correto.

Depois descobre:

JCL

Depois:

Db2

Depois:

VSAM

Depois:

CICS

Depois:

IMS

Depois:

MQ

Depois:

scheduler

Depois:

RACF

Depois vê control tables, compiler options, PROCs, SMF, load libraries, binder, copybooks e pessoas que conhecem regras de 1993.

Nesse momento ele entende:

Mainframe não é uma linguagem. É um ecossistema.

E aplicações antigas são frequentemente organismos históricos.

Foram construídas em camadas.

Uma mudança em 1988.

Outra em 1994.

Um workaround em 1999.

Euro em 2002.

Regulatório em 2008.

Novo canal em 2013.

API em 2018.

Cloud em 2024.

IA em 2026.

Cada geração deixou alguma coisa no templo.

O trabalho da Inteligência Artificial não é fingir que conhece todas as câmaras escondidas.

É ajudar você a encontrá-las.

Ela pode ler inscrições numa velocidade impossível para uma equipe humana.

Pode conectar copybooks.

Pode explicar COBOL.

Pode comparar milhares de programas.

Pode gerar hipóteses.

Pode localizar padrões.

Pode transformar documentação ruim em algo utilizável.

Pode auxiliar na geração de testes.

Pode tornar discovery dramaticamente mais rápido.

Mas ainda precisamos perguntar:

De onde veio essa afirmação?

É fato?

É runtime?

É hipótese?

É unknown?

Qual o risco se estiver errada?

Essa é a diferença entre demonstração bonita e engenharia de modernização.

Portanto, quando alguém disser:

“Nossa IA analisou 100% do COBOL.”

Sorria.

Tome um gole de café.

Olhe para o horizonte como Nathan Drake olhando para mais uma cidade perdida.

E pergunte:

“Ótimo. Agora me mostre os CALLs dinâmicos, os overrides de JCL, as tabelas de controle, o histórico do scheduler, os consumidores dos arquivos, os packages Db2, o runtime e aquilo que ainda não sabemos.”

Se a sala ficar silenciosa...

parabéns.

Você acabou de encontrar a entrada da próxima ruína.

E, lá no fundo do CPD, provavelmente existe uma placa antiga dizendo:

SIC PARVIS MAGNA

Grandeza a partir de pequenos começos.

Ou, em português de mainframe:

Não tente mapear o planeta inteiro antes de descobrir quem está alterando o DDNAME do STEP030.

Alan Turing Entra na Sala de Mudanças — O Dia em que o Agile Descobriu que um Programa COBOL Não Chega Sozinho à Produção

 

Bellacosa Mainframe e as metodologias Ageis para um coboleiro

☕ Um Café no Bellacosa Mainframe

Alan Turing Entra na Sala de Mudanças — O Dia em que o Agile Descobriu que um Programa COBOL Não Chega Sozinho à Produção

Ou: por que uma sprint não termina quando o compilador sorri, o que RACF, Db2, JCL, UX e Operação estão fazendo na mesma história e como não transformar Agile em Waterfall de post-it

 

Imagine Alan Turing entrando numa sala de projeto em 2026. Há um quadro com colunas coloridas: To do, Doing, Done. Alguém aponta para um cartão e anuncia, muito satisfeito: “acabou; o COBOL compilou”. Turing olha para o cartão, para o café frio ao lado do terminal e faz a pergunta que estraga metade das celebrações corporativas:

“Acabou para quem?”

O programa compilou. Ótimo. Mas o pacote Db2 foi validado? O acesso RACF existe e obedece ao menor privilégio? O job está no scheduler correto? A operação sabe interpretar um RC=8? A massa de testes representa o volume de fim de mês? A interface explica ao cliente que o processamento é assíncrono? Existe um plano de retorno se a alteração abrir um buraco no universo — ou, pior, na conciliação financeira?

Para o programador COBOL iniciante, esta é uma descoberta importante: em um projeto mainframe, você não entrega apenas um programa. Você entrega uma mudança dentro de um ecossistema que processa dados valiosos, conversa com muitas plataformas e, em vários casos, não pode errar por cinco minutos sem alguém perceber no extrato, no caixa, na folha ou no jornal.

Este artigo é um mapa para entender a diferença entre Agile e Waterfall, o papel dos dados e da IA, e por que o mainframe exige uma forma mais adulta de agilidade: rápida para aprender, rigorosa para produzir.



1. Agile não é correria; Waterfall não é vilão

O modelo Waterfall — a famosa cascata — costuma organizar o projeto em grandes etapas sequenciais:

Requisitos → análise → desenho → desenvolvimento → testes → implantação.

Ele faz sentido quando o problema é estável e bem conhecido. Uma adequação regulatória com regras fechadas, uma troca controlada de infraestrutura ou uma alteração obrigatória de layout podem exigir muito planejamento antes de escrever a primeira linha. Em sistemas críticos, isso não é burocracia por esporte; é controle de risco.

O defeito aparece quando tratamos algo incerto como se estivesse completamente decidido. O time passa meses documentando, desenvolve por meses adicionais e só no fim descobre que o cliente não entendia o fluxo, que uma integração não suporta a carga ou que a regra de negócio tinha uma exceção escondida num e-mail de 2017.

O Agile trabalha diferente. Ele divide a jornada em partes pequenas: construir, testar, mostrar, aprender e ajustar. Não é ausência de planejamento. É planejamento em fatias, com aprendizado antecipado.

PerguntaWaterfallAgile maduro
Quando aprendemos se a solução serve?Mais perto do fimEm entregas curtas
O requisito pode mudar?Tende a virar exceção formalPode ser repriorizado com evidência
Como o risco aparece?Às vezes tardeDeve surgir em cada ciclo
O que significa progresso?Fase concluídaValor entregue, testado e operável

Nem todo projeto precisa ser 100% de um modelo. No mainframe, o mais comum e sensato é um híbrido: Agile para construir e validar valor; controles mais sequenciais para governança, auditoria, segurança, janela de mudança e produção.

O problema não é usar Waterfall. O problema é fingir que ele continua funcionando quando o negócio ainda está descobrindo o que quer. E o problema do Agile não é ter ritos; é fingir que uma daily de quinze minutos resolve uma dependência que atravessa cinco departamentos.



2. Quando os dados entram: a agilidade deixa de ser opinião

O infográfico que motivou nossa conversa diz que o futuro do Agile será orientado por dados e IA. A frase é boa, desde que não seja traduzida como “compremos uma plataforma e ela decidirá por nós”.

Dados úteis respondem perguntas simples e duras:

  • Quanto tempo uma mudança leva desde o pedido até a produção?

  • Em qual fila o trabalho fica parado?

  • Quantos defeitos escapam para produção?

  • O cliente usa a funcionalidade entregue?

  • O batch ainda cabe na janela?

  • A nova consulta Db2 aumentou CPU ou I/O?

  • Qual permissão RACF foi solicitada, por quem, para quê e até quando?

No Kanban, por exemplo, lead time mede a espera do solicitante; cycle time, o tempo de trabalho ativo; throughput, quantos itens foram concluídos; e WIP (work in progress), quantos itens estão abertos ao mesmo tempo. Se há trinta histórias abertas e três concluídas por semana, o quadro não está “agitado”: está congestionado.

Em Scrum, a velocidade pode ajudar o próprio time a planejar. Mas cuidado: story point não é hora, salário, inteligência nem medalha. Comparar a velocidade de duas equipes é como comparar o número de páginas de dois livros para decidir qual é melhor. A métrica serve para observar tendência local, não para fabricar ranking e medo.

IA pode resumir incidentes, classificar chamados, sugerir testes, localizar padrões em logs e apontar que uma fila está crescendo. Ela é um ótimo Dr. Watson de silício: organiza pistas. Mas não substitui Sherlock, muito menos o dono da regra de negócio. Um modelo pode prever atraso; não sabe, sozinho, que a causa real é a única DBA estar em férias ou que a regra depende de um contrato assinado há vinte anos.



3. XP, Scrum, Kanban e os parentes menos convidados para o café

As metodologias citadas no infográfico não são feitiços concorrentes. Cada uma ilumina uma parte do problema.

Extreme Programming (XP) reforça engenharia: TDD, integração contínua, programação em pares, pequenas mudanças e refatoração. Para COBOL, isso significa abandonar a ideia de que teste é apenas executar um job e olhar se “não deu abend”. Teste unitário, dados conhecidos, validação de regras e regressão tornam uma mudança mais segura. Se alterou juros, decimal, data, sinal ou arredondamento, tenha casos que provem o comportamento antes e depois.

Scrum organiza trabalho em sprints: backlog priorizado, planejamento, revisão e retrospectiva. É útil quando há produto evoluindo e necessidade de alinhamento frequente. Mas uma história Scrum não pode ser “codificar o programa X” se a produção depende também de autorização, bind, operação e homologação. Isso é só uma tarefa de desenvolvimento disfarçada de entrega.

Kanban é excelente para sustentação e fluxo contínuo: incidentes, pequenas manutenções, pedidos de acesso e correções. Ele mostra onde o serviço enrosca. Se todo cartão fica parado em “aguardando validação”, não adianta cobrar mais velocidade de quem codifica; é necessário corrigir o gargalo.

Feature-Driven Development (FDD) puxa a conversa para funcionalidades de negócio: “consultar saldo”, “calcular limite”, “emitir boleto”. Isso protege o time de entregar componentes tecnicamente elegantes que não resolvem nada importante. Dados de uso e feedback ajudam a priorizar, mas não eliminam criticidade: um processo usado uma vez por mês pode ser vital para uma obrigação legal.

APF, ASD, DSDM e XPM lembram que há projetos onde a incerteza é parte do trabalho. Eles valorizam adaptação, protótipos, colaboração e aprendizado. Em modernização, isso é ouro: primeiro confirme se a API atende, se a tela faz sentido e se o legado suporta a carga; depois escale. Um protótipo bonito não prova que há segurança, transação, recuperação ou capacidade de produção.

4. A história que atravessa o mainframe

Uma funcionalidade bancária aparentemente modesta — “permitir consultar uma fatura no aplicativo” — pode envolver Business Analyst, UX/UI, desenvolvedor, DBA, RACF, qualidade, gerente de sistemas e operações.

O Business Analyst traduz objetivo em regra. Não basta escrever “mostrar fatura”; é preciso dizer quais clientes podem consultar, quais períodos, o que acontece para fatura fechada, renegociada, indisponível ou protegida por sigilo.

O UX/UI desenha a jornada. Mas precisa saber se a resposta é imediata, se depende de batch, se há limites de consulta e qual mensagem humana será exibida quando um serviço estiver indisponível. A tela não pode prometer “pronto agora” quando o processo real conclui à noite.

O System Developer implementa lógica, integrações, programas COBOL, copybooks, APIs, CICS, MQ, JCL ou o que a arquitetura pedir. Seu trabalho inclui analisar impacto: quem chama este programa? Qual layout será alterado? Um campo novo quebra um consumidor antigo? Há tratamento para valor nulo, arquivo ausente e retorno inesperado?

O DBA olha além do resultado correto. A consulta funciona com cem registros? E com cinquenta milhões? Ela usa índice? Há risco de lock, timeout, deadlock, aumento de CPU ou alteração de plano de acesso após o BIND? Uma query que “funciona na homologação” pode virar o monstro da janela noturna em produção.

O especialista de RACF e segurança desenha identidade e autorização. Quem acessa? Pessoa, aplicação, job batch ou ID de serviço? Qual dataset, transação CICS, recurso Db2 ou certificado é necessário? A regra é menor privilégio, segregação de funções e prazo claro para acessos temporários. RACF não é uma cancela colocada no fim da estrada; é parte da arquitetura.

Qualidade cria cenários positivos, negativos, integrados e de volume. “O caminho feliz funcionou” é apenas o primeiro capítulo. E se o arquivo chegar vazio? E se houver caractere inválido e surgir um S0C7? E se o job receber RC=8? E se a atualização parcial precisar de rollback?

System Manager avalia plataforma, versões, capacidade, configuração e impacto de mudança. Operações prepara execução, agendamento, monitoração e resposta ao incidente. Se a equipe operacional precisa telefonar ao desenvolvedor para descobrir o que significa um erro, a mudança chegou sem manual de sobrevivência.

5. O cadáver na sprint: “pronto” para desenvolvimento, incompleto para produção

Eis o defeito mais comum: cada área usa uma definição privada de pronto.

Para Desenvolvimento, pronto é código compilado. Para Qualidade, teste executado. Para Segurança, perfil aprovado. Para Operações, job agendado e monitorado. Para o negócio, pronto é cliente receber o resultado correto. Todas as definições são legítimas — mas isoladas formam um Frankenstein organizacional.

Uma Definition of Done comum deve estabelecer, proporcionalmente ao risco, que a mudança possui:

  • regra e critérios de aceite validados;

  • código revisado, versionado, compilado e testado;

  • análise de impacto em copybooks, programas, arquivos, APIs e consumidores;

  • revisão Db2, EXPLAIN e BIND quando aplicável;

  • permissões RACF e segregação de funções definidas;

  • testes integrados, negativos e de regressão;

  • JCL, PROC, GDG, dataset, parâmetros e scheduler revisados;

  • plano de implantação e backout;

  • monitoração, logs, códigos de retorno e runbook operacional;

  • evidência de homologação e validação pós-produção.

Isso não obriga uma correção de rótulo de tela a passar pelo mesmo rito de uma alteração de saldo. O segredo é uma matriz de impacto. Marque, no refinamento: toca Db2? RACF? CICS? MQ? VSAM? JCL? dados pessoais? scheduler? interface externa? auditoria? Quanto maior o impacto, maior a necessidade de envolvimento antecipado.

6. Passo a passo: como levar uma história até produção sem ritual de pânico

1. Comece pelo valor e pelas exceções. O BA e o dono do negócio descrevem o que muda e como medir sucesso. “Reduzir ligações sobre segunda via” é melhor que “criar tela de segunda via”. Acrescente cenários de erro e regras de borda.

2. Faça análise de impacto antes de prometer a data. Desenvolvimento identifica módulos, layouts, chamadas, tabelas, jobs e interfaces. Segurança, DBA e operação entram cedo somente quando houver impacto real. Não coloque vinte pessoas na daily; coloque as pessoas certas no refinamento certo.

3. Divida verticalmente. Em vez de uma sprint para tela, outra para API e outra para COBOL, entregue uma pequena jornada completa. Talvez apenas consulta de uma fatura recente, com autorização, rastreabilidade e erro bem tratado. A fatia prova valor e reduz a hipótese.

4. Automatize o repetível. Build, testes, análise estática, promoção de artefatos e registro de evidências não deveriam depender de e-mails e memória humana. Em ambiente z/OS, ferramentas e pipelines modernos ajudam, mas automação só presta se respeitar os controles da organização.

5. Teste como se a produção fosse real. Use massa protegida e representativa. Teste volume, falha de integração, retorno inesperado, recuperação e janela batch. O objetivo não é provar que o sistema funciona em condições ideais; é descobrir como ele falha e se recupera.

6. Entregue para operação antes da operação precisar socorrer você. O runbook deve informar o que mudou, jobs e transações afetados, entradas e saídas, RCs esperados, alertas, validação pós-implantação e retorno. É conhecimento operacional, não papelada decorativa.

7. Observe e aprenda. Após produção, acompanhe uso, tempo de resposta, erro, custo e chamados. Se o recurso foi entregue e ninguém o usa, a equipe produziu software; ainda não produziu valor.

7. Easter egg de Turing: a máquina não entende intenção

Turing nos deixou uma lição que vale para COBOL e para IA: máquinas executam regras e padrões; intenção humana precisa ser expressa, validada e verificada.

Um compilador não sabe que um campo deveria ter duas casas decimais. Ele só sabe o que foi codificado. Um modelo de IA não sabe que uma permissão concedida por conveniência viola segregação de funções. Ele só encontra padrões nos dados que recebeu. Um dashboard não sabe que um item parado há dez dias representa o pagamento de pensão de milhares de pessoas.

Portanto, use IA como copiloto: para sugerir cenários de teste, resumir tickets, encontrar padrões em logs e apontar anomalias. Não a use como autorização para abandonar revisão humana, testes, controles de acesso ou responsabilidade profissional.

Epílogo — o verdadeiro Done

O jovem programador COBOL costuma imaginar que seu programa termina no GOBACK. Em uma empresa real, ele só começa ali. A alteração atravessa banco de dados, controles de acesso, testes, operação, negócio, tela, integração, auditoria e pessoas que acordarão se algo der errado às duas da manhã.

Agile bem aplicado ao mainframe não é um ataque à governança. É a forma de trazer segurança, DBA, qualidade e operações para mais perto do momento em que a decisão ainda é barata.

Turing provavelmente olharia novamente para o cartão marcado como Done e faria a pergunta final:

“O sistema apenas executa, ou a organização consegue explicar, operar, proteger e recuperar o que acabou de mudar?”

Quando a resposta for “sim”, então o cartão pode, finalmente, atravessar a última coluna.




domingo, 21 de abril de 2024

Sokushi Cheat — Quando o Garoto Quieto Recebeu Autoridade para Dar CANCEL no Universo

 

Bellacosa Mainframe e o anime sokushi cheat

☕ Um Café no Bellacosa Mainframe

Sokushi Cheat — Quando o Garoto Quieto Recebeu Autoridade para Dar CANCEL no Universo

Ou: uma turma inteira recebeu poderes de RPG, uma sábia instalou software sem autorização, quinze candidatos a protagonista abriram seus monólogos de vilão — e Yogiri respondeu a todos com um único comando em produção

Existem protagonistas poderosos.

Existem protagonistas exageradamente poderosos.

Existem protagonistas que começam fracos, treinam durante vinte episódios, encontram um mestre alcoólatra, descobrem uma espada ancestral, perdem um amigo, desbloqueiam uma transformação proibida e finalmente derrotam o primeiro dos sete generais do Rei Demônio.

E existe Yogiri Takatō.

Yogiri não derrota o inimigo. Ele encerra o processo.

Não importa se o adversário é um dragão, um vampiro imortal, um espírito, uma entidade divina, uma criatura fora do espaço-tempo ou um sujeito que escreveu três páginas explicando por que sua habilidade é absolutamente invencível. Se Yogiri decidir que aquilo deve morrer, a discussão terminou antes de o narrador conseguir localizar a vírgula.

À primeira vista, Sokushi Cheat ga Saikyō Sugite, Isekai no Yatsura ga Marude Aite ni Naranai n desu ga parece mais um daqueles isekais cujo título já funciona como sinopse, manual de operação e pedido de desculpas.

Mas existe uma pequena sabotagem escondida no pacote.

O anime não tenta perguntar se o protagonista conseguirá vencer. Ele pergunta por que tantos personagens, sistemas e instituições acreditam que possuir poder lhes concede o direito de tratar outras pessoas como objetos.

Yogiri não é propriamente o herói que vai subir na hierarquia daquele mundo.

Ele é a falha fundamental que demonstra que toda a hierarquia estava construída sobre areia.


📋 Registro do sistema

CampoInformação
Título original即死チートが最強すぎて、異世界のやつらがまるで相手にならないんですが。
RomanizaçãoSokushi Chīto ga Saikyō Sugite, Isekai no Yatsura ga Marude Aite ni Naranai n desu ga
Título internacionalMy Instant Death Ability Is So Overpowered, No One in This Other World Stands a Chance Against Me!
Título abreviadoInstant Death ou Sokushi Cheat
AutorTsuyoshi Fujitaka
Ilustradora da light novelChisato Naruse
Ilustrador do mangáHanamaru Nanto
OrigemWeb novel publicada no Shōsetsuka ni Narō
Início da web novel21 de fevereiro de 2016
Light novel14 volumes principais e um volume extra
MangáSokushi Cheat —AΩ—
Estúdio do animeOkuruto Noboru
DireçãoMasakazu Hishida
Design de personagensSayuri Sakimoto
Estreia japonesa5 de janeiro de 2024
Encerramento22 de março de 2024
Episódios12
GênerosIsekai, fantasia, aventura, comédia, paródia, ação e humor negro
Classificação indicativa sugerida15 anos ou mais
Estado da primeira temporadaConcluída


A edição inglesa da obra é catalogada pela própria J-Novel Club como fantasia, comédia, aventura, isekai, LitRPG, protagonista overpower e representações de violência, com recomendação para maiores de 15 anos. J-Novel Club



🚌 Uma excursão escolar entra num túnel e sai do outro lado do SLA

Yogiri Takatō dorme durante uma viagem escolar.

Enquanto ele cochila, o ônibus atravessa um túnel e aparece em outro mundo. Uma mulher chamada Sion, que se apresenta como Sábia, entra no veículo e anuncia que os estudantes foram convocados para participar de um processo de seleção.

O professor tenta questioná-la.

Sion explode a cabeça dele.

Está encerrada a reunião de alinhamento.

A Sábia instala nos alunos uma estrutura chamada Battle Song, uma espécie de sistema operacional mágico capaz de conceder classes, níveis, habilidades e missões. Os escolhidos recebem o chamado Gift. Quem não recebe é considerado inútil.

Yogiri, Tomochika Dannoura e alguns colegas aparentemente fracassam na instalação.

Quando dragões se aproximam, os alunos “úteis” abandonam os demais dentro do ônibus para servirem de isca. Não foi um acidente, uma fuga desorganizada ou uma decisão tomada em pânico. Foi capacity planning:

“O dragão comerá os sem poderes enquanto os recursos prioritários escapam.”

Só esqueceram de verificar o inventário antes de classificar Yogiri como equipamento obsoleto.

Quando a criatura ataca, ele pronuncia uma palavra:

“Morra.”

O dragão morre.

Não perde pontos de vida. Não recebe dano crítico. Não é selado, purificado ou transportado para outra dimensão. Apenas deixa de funcionar.

O site oficial do anime resume justamente essa inversão: os estudantes sem Gift são abandonados como isca, mas Yogiri possui uma capacidade capaz de matar qualquer alvo instantaneamente.


💀 A habilidade que não pertence ao sistema

O primeiro detalhe importante é que Yogiri não recebeu o poder naquele mundo.

Ele já o possuía na Terra.

Isso significa que sua habilidade não faz parte da Battle Song, não depende de mana, classe, nível, bênção divina ou das regras administrativas dos Sábios.

É como levar um notebook para dentro de uma empresa, descobrir que todos os funcionários possuem permissões controladas pelo Active Directory e então perceber que o garoto sonolento sentado no corredor carrega acesso físico ao disjuntor do prédio.

A habilidade de Yogiri pode:

  • matar seres vivos;

  • eliminar mortos-vivos;

  • encerrar movimentos ou partes específicas de um corpo;

  • atingir espíritos e entidades incorpóreas;

  • perceber intenções assassinas;

  • reagir a perigos antes que o ataque se complete;

  • ultrapassar regeneração, ressurreição e imortalidade;

  • alcançar criaturas protegidas por barreiras dimensionais;

  • atingir fenômenos e conceitos quando ele os reconhece como algo que pode “terminar”.

Aqui o anime começa a sair do terreno do simples overpower.

Yogiri não parece ser um adolescente que recebeu uma magia extremamente forte. O adolescente pode ser apenas a aparência humana de uma entidade associada ao fim inevitável de todas as coisas.

Ele não possui a morte.

Talvez ele seja a morte oferecendo uma interface gráfica simplificada.


👦 Yogiri Takatō — o operador que sabe que está em produção

Yogiri é frio, sonolento, econômico nas palavras e assustadoramente calmo.

Essa personalidade pode ser confundida com apatia, mas existe nela uma lógica. Desde criança, ele precisou aprender que uma irritação momentânea poderia produzir uma consequência irreversível. Uma pessoa comum pode gritar, empurrar uma cadeira ou bater uma porta. Yogiri não possui o luxo de agir impulsivamente.

Por isso ele segue regras próprias:

  • não matar por mero incômodo;

  • reagir quando alguém pretende matá-lo;

  • proteger quem está sob sua responsabilidade;

  • evitar violência desnecessária;

  • não torturar;

  • não brincar com o adversário;

  • não transformar a morte em espetáculo.

Curiosamente, muitos “heróis” daquele mundo são mais cruéis do que ele. Eles escravizam, humilham, manipulam, estupram, sacrificam inocentes e tratam pessoas fracas como recursos consumíveis.

Yogiri mata com facilidade, mas não sente prazer nisso.

A obra constrói assim um paradoxo: o personagem com a habilidade mais assustadora possui maior autocontrole do que quase todos aqueles que se apresentam como salvadores.


👧 Tomochika Dannoura — a analista de negócios no meio do apocalipse

Tomochika é a verdadeira ponte entre Yogiri e o público.

Ela não é apenas a menina que precisa ser salva. Sua família preserva o estilo marcial Dannoura, dando-lhe capacidade física, reflexos e disciplina muito acima de uma estudante comum. Ela também possui algo extremamente raro naquele universo: bom senso.

Tomochika pergunta o que nós perguntaríamos:

  • Por que esse sujeito morreu?

  • Como alguém pode matar uma coisa que já estava morta?

  • Por que há outro protagonista de isekai entrando pela janela?

  • Por que todo homem com uma classe especial resolve imediatamente fundar um harém?

  • Será que podemos chegar à próxima cidade sem destruir a infraestrutura nacional?

Ela é o monitoramento humano do sistema.

Sem Tomochika, Yogiri atravessaria o anime como uma rotina batch silenciosa. Com ela, surge a dupla de comédia: ele executa o absurdo com naturalidade; ela abre o incidente, classifica a severidade e pergunta quem aprovou aquilo.

Também existe uma relação afetiva em construção. Não é um harém convencional nem um romance histérico. O vínculo nasce da convivência, da proteção mútua e da confiança. Yogiri, que poderia atravessar o mundo sozinho, começa a levar em consideração os desejos de Tomochika.

E isso é mais importante do que parece.

O ser capaz de encerrar qualquer coisa começa a escolher algo que deseja preservar.


👻 Mokomoko Dannoura — a avó fantasma que ninguém incluiu no inventário

Mokomoko Dannoura é uma ancestral espiritual da família de Tomochika.

Ela funciona como guia, comentarista, mestre marcial e fonte permanente de confusão. Sua presença amplia o lado cômico da série, mas também reforça a herança cultural da família Dannoura.

Mokomoko e Tomochika representam uma força desenvolvida pela tradição humana. Yogiri representa uma força anterior às regras humanas.

O anime coloca essas duas estruturas lado a lado: o conhecimento transmitido entre gerações e o poder absoluto que não precisou ser aprendido.

Naturalmente, Mokomoko também serve para lembrar que até o além-vida possui aquele parente que aparece sem ser convidado e começa a dar opinião sobre o relacionamento.


👑 Sion — a recrutadora que transformou alunos em recursos computacionais

Sion é a Sábia responsável pela convocação.

Bonita, educada, poderosa e completamente indiferente ao sofrimento alheio, ela encarna uma das críticas centrais da obra: o poder institucional que converte pessoas em números.

Os estudantes não são convidados. São sequestrados.

Os Gifts não são presentes. São mecanismos de controle.

As missões não são aventuras. São testes de sobrevivência.

E quem falha pode ser convertido em gado produtor de energia.

Sion acredita dominar o sistema porque distribui as permissões. Yogiri é perigoso justamente porque existe fora dele. Ela não pode revogar uma credencial que nunca emitiu.

No Bellacosa Mainframe, isso receberia o nome técnico de:

“Descobriram uma conta privilegiada sem owner, sem expiração e sem registro no RACF.”


🧛 Lain, os Sábios e a aristocracia da imortalidade

A Sábia Lain é uma vampira poderosa, capaz de criar cópias e preservar sua existência por métodos que deveriam torná-la praticamente impossível de eliminar.

Ela representa outro padrão recorrente: o personagem que acredita ter vencido a morte por meio de redundância.

Backups, clones, corpos substitutos e regeneração parecem formar uma arquitetura de alta disponibilidade. Mas toda alta disponibilidade depende de alguma coisa continuar existindo.

Yogiri não derruba apenas a instância ativa.

Ele pode encerrar aquilo que permite à arquitetura retornar.

A pergunta deixa de ser “como matar um imortal?” e passa a ser “o que significa estar vivo quando o próprio conceito de continuidade pode receber um CANCEL?”.


🤖 Ayaka Shinozaki — a isca que se recusou a permanecer descartável

Ayaka é uma das personagens mais interessantes da primeira temporada.

Inicialmente deixada para morrer no ônibus, ela parece apenas mais uma vítima. Posteriormente descobrimos que não é uma estudante comum, mas um ser artificial extremamente avançado, associado a um projeto terrestre criado para lidar com Yogiri.

Depois de sobreviver e adquirir características do dragão que a atacou, Ayaka inicia uma campanha de vingança contra os colegas que a abandonaram.

Ela é um espelho de Yogiri.

Os dois foram tratados como objetos por instituições. Os dois possuem naturezas que escapam à normalidade. Os dois poderiam destruir quase tudo ao redor.

A diferença está na resposta.

Yogiri estabelece limites. Ayaka permite que a traição defina sua identidade.

A vingança dela é compreensível, mas deixa de distinguir culpados, cúmplices, covardes e pessoas simplesmente arrastadas pela situação. Em certo momento, a vítima começa a reproduzir a lógica de descarte de seus algozes.

Isso torna seu destino cruel: ela sobrevive ao dragão, supera a condição de isca e quase se torna protagonista de outro anime — apenas para descobrir que entrou na área de atuação de uma força contra a qual evolução, adaptação e ódio não oferecem resistência.


🗡️ As principais aventuras da temporada

1. O ônibus e o dragão

A apresentação estabelece a brutalidade daquele mundo, a traição dos colegas e a verdadeira natureza do poder de Yogiri.

Também elimina a expectativa de progressão tradicional. O primeiro dragão, que em outro anime ocuparia quatro episódios, é tratado como uma notificação inconveniente.

2. Os colegas retornam

Alguns alunos voltam ao ônibus não para resgatar os abandonados, mas para explorar Tomochika e eliminar possíveis testemunhas.

O Gift não apenas concede poder: ele parece amplificar arrogância, agressividade e a percepção de que os demais se tornaram NPCs.

Yogiri demonstra que consegue identificar intenções assassinas e agir antes que uma ameaça se concretize.

3. O dominador e seu harém escravizado

Yūki Tachibana recebe uma habilidade de dominação e imediatamente constrói um grupo de mulheres subordinadas.

A situação parodia o harém isekai. Em muitas obras, garotas se apaixonam inexplicavelmente pelo protagonista. Aqui, o mecanismo de submissão é exposto sem o verniz romântico: trata-se de controle.

O anime pergunta silenciosamente quantos “haréns espontâneos” do gênero não passam de fantasias de poder com consentimento escrito pelo roteirista depois do contrato.

4. A cidade, os cavaleiros e a espada

Yogiri e Tomochika seguem a trilha dos colegas na esperança de encontrar Sion e descobrir um caminho de volta ao Japão.

No percurso, encontram guerreiros, cavaleiros e candidatos a Swordmaster. Cada nova facção possui sua mitologia, seus níveis de autoridade e um personagem convencido de estar no topo da cadeia alimentar.

O problema é que Yogiri não participa da cadeia alimentar.

5. O Deus das Trevas

Um ser antigo e selado começa a despertar. Em qualquer fantasia normal, isso exigiria a união de reinos, a localização de artefatos e uma temporada inteira.

Yogiri percebe a ameaça e encerra o processo antes da inicialização completa.

É um dos melhores exemplos da proposta satírica: o anime constrói o início de uma saga épica e depois remove a saga do spool.

6. A Sábia Lain

Lain tenta compreender, testar e neutralizar Yogiri empregando imortalidade, duplicação e planejamento.

O confronto demonstra que o poder dele não é apenas uma magia de dano muito alto. Não existe barra de HP suficiente, porque a habilidade atua sobre a existência do alvo.

7. A origem terrestre de Yogiri

Flashbacks revelam que ele passou parte da infância confinado e observado por uma organização.

Na Terra, o garoto era tratado como uma anomalia de contenção — quase um documento perdido da Fundação SCP que resolveu frequentar o ensino médio.

É nesse núcleo que aparece Asaka Takatō, sua cuidadora e figura materna. Ela não consegue controlar Yogiri pela força; ensina-lhe convivência, empatia e limites.

Asaka é provavelmente a pessoa mais importante da história.

Sem ela, Yogiri teria poder.

Graças a ela, desenvolveu critério.

8. O reencontro com a turma e Sion

As diferentes linhas narrativas convergem. A classe se fragmenta, alianças entram em colapso e personagens que acreditavam dominar o jogo percebem que eram peças descartáveis de um experimento maior.

Yogiri finalmente enfrenta Sion.

Não há grande duelo equilibrado, porque equilíbrio nunca foi a proposta. A tensão está em saber quanto do mundo será destruído pelas conspirações paralelas antes que alguém pare de provocar o único ser que não deveria ser provocado.

Ao final, Yogiri e Tomochika obtêm pistas sobre as Pedras Filosofais, necessárias para viabilizar o retorno à Terra.

A temporada termina, portanto, sem concluir toda a jornada. Ela encerra um grande arco e abre a missão de coleta que ocupará a continuação da light novel.


🎭 O que o anime possui de diferente?

O protagonista não cresce em poder

Yogiri já começa no limite.

Não há treinamento, evolução de classe ou arma lendária. O desenvolvimento dele precisa ocorrer no campo emocional e moral.

Os antagonistas parecem protagonistas de outras histórias

Esse é o mecanismo mais divertido da obra.

Diversos personagens surgem com:

  • histórias de reencarnação;

  • bênçãos exclusivas;

  • regressão temporal;

  • contratos divinos;

  • imortalidade;

  • exércitos particulares;

  • títulos heroicos;

  • habilidades de copiar poderes;

  • monólogos sobre a superioridade de sua classe.

Cada um poderia estrelar uma light novel própria.

Então encontra Yogiri.

O resultado é quase uma antologia de isekais cancelados no episódio piloto.

A Terra também contém elementos sobrenaturais

O mundo original não é apresentado como completamente normal. Organizações governamentais, seres artificiais e agentes especiais conheciam a natureza de Yogiri.

Assim, o mistério não está apenas no mundo fantástico. A Terra talvez seja tão estranha quanto ele, apenas possuindo procedimentos burocráticos melhores.

A morte não é apresentada como uma luta

Quando Yogiri utiliza sua habilidade, muitas vítimas simplesmente caem.

A ausência de espetáculo produz dois efeitos opostos: humor e desconforto. O inimigo preparou sua entrada triunfal, mas a morte real raramente respeita dramaturgia.


🧠 Mensagens ocultas atrás da carnificina

1. Poder sem limite não produz maturidade

Os Gifts transformam adolescentes comuns em pequenos tiranos porque lhes dão autoridade antes de responsabilidade.

A habilidade não cria a personalidade. Ela remove as consequências que antes mantinham certos impulsos escondidos.

2. O sistema define quem é “útil”

Quem não recebe um Gift é abandonado como peso morto.

É a velha confusão corporativa entre valor e aquilo que o sistema consegue medir. Yogiri recebe nota zero porque a ferramenta de avaliação é incapaz de detectá-lo.

Ele não falhou no teste.

O teste falhou diante dele.

3. A imortalidade é uma questão de infraestrutura

Vampiros, deuses, clones e regeneradores possuem diferentes estratégias de continuidade.

A obra trata cada uma como uma arquitetura que acredita ter eliminado o ponto único de falha. Yogiri funciona como a descoberta de que todos os diagramas dependiam do mesmo datacenter metafísico.

4. Autocontrole é maior do que força

Yogiri não impressiona apenas porque pode matar qualquer coisa.

Ele impressiona porque quase sempre escolhe não fazê-lo.

O elemento humano não está na habilidade, mas na contenção.

5. A sociedade teme aquilo que não consegue classificar

Na Terra, tentam estudá-lo e confiná-lo. No outro mundo, tentam medi-lo, copiá-lo, manipulá-lo ou destruí-lo.

Instituições diferentes repetem a mesma reação: quando algo não cabe no formulário, o primeiro impulso é transformá-lo em ameaça.

6. O verdadeiro horror é administrativo

Dragões são previsíveis. Reis Demônios anunciam seus planos.

Sion é assustadora porque converte sequestro, seleção, sacrifício e escravidão em procedimentos normais. O mal mais eficiente da série usa linguagem de processo.


🎨 O estúdio Okuruto Noboru e a adaptação

A animação foi produzida pelo Okuruto Noboru, com direção de Masakazu Hishida e character design de Sayuri Sakimoto.

O estúdio não recebeu um orçamento capaz de colocar cada batalha no mesmo nível das maiores produções do mercado. Há limitações perceptíveis:

  • movimentos simplificados;

  • confrontos curtos;

  • uso frequente de enquadramentos estáticos;

  • criaturas digitais irregulares;

  • transições muito rápidas entre núcleos;

  • redução do impacto visual de certas entidades.

Entretanto, existe uma defesa possível: uma adaptação de Instant Death não precisa transformar cada batalha em espetáculo, porque a piada está justamente na interrupção do espetáculo.

O maior problema não é a duração das lutas, mas a compressão narrativa.

Doze episódios precisam apresentar uma quantidade absurda de personagens, facções, poderes, flashbacks e tramas paralelas. O resultado parece uma sala de operações em que quinze incidentes Sev-1 foram abertos simultaneamente e cada responsável fala durante vinte segundos antes de morrer.

A própria dubladora de Sion descreveu oficialmente a narrativa como semelhante a uma montanha-russa, com muitos personagens e problemas acontecendo em diferentes lugares. Outros integrantes do elenco destacaram a combinação entre comédia, mortes frequentes e ritmo acelerado. Site oficial

A trilha sonora reúne Hanae Nakamura, Tatsuhiko Saiki, Kanade Sakuma e Daisuke Kadowaki. A abertura é “Killer Bars”, do Hilcrhyme, enquanto o encerramento é “Haze”, interpretado por Anna Suzuki.


🔞 Violência, fanservice, classificação e censura

A obra possui:

  • mortes frequentes;

  • assassinatos súbitos;

  • corpos e sangue;

  • escravidão;

  • ameaças sexuais;

  • violência contra estudantes;

  • manipulação mental;

  • humor envolvendo situações levemente ecchi;

  • tratamento deliberadamente banal da morte.

Apesar do título e da quantidade de cadáveres, a violência costuma ser rápida. Muitas vítimas simplesmente desabam, o que reduz a exposição gráfica sem diminuir o peso conceitual.

O fanservice existe, principalmente em piadas envolvendo Tomochika e em personagens construídos como paródias do harém, mas não domina a série.

Não encontrei evidência confiável de que o anime tenha sido oficialmente proibido, mutilado por censura governamental ou lançado em versões radicalmente diferentes. O que existe é adequação normal de violência e sexualização ao formato televisivo.

Portanto, convém não confundir três fenômenos:

  • censura oficial: não há um caso relevante documentado;

  • adaptação televisiva: certas cenas são menos explícitas ou mais rápidas;

  • compressão: o anime corta contexto, diálogos e explicações presentes nas novels e no mangá.

A J-Novel Club recomenda a obra para maiores de 15 anos e marca explicitamente a presença de violência. J-Novel Club


📚 Web novel, light novel e mangá

Web novel

Tsuyoshi Fujitaka começou a publicar a história no portal Shōsetsuka ni Narō em 21 de fevereiro de 2016.

A web novel foi concluída em 2023 e serviu como laboratório original da narrativa.

Light novel

A Earth Star Entertainment publicou a edição comercial com ilustrações de Chisato Naruse.

A série principal possui 14 volumes, acompanhados por uma edição extra lançada posteriormente. A história completa vai muito além da primeira temporada do anime e expande:

  • a verdadeira natureza de Yogiri;

  • as organizações existentes na Terra;

  • a escala cosmológica da habilidade;

  • os Sábios e as Pedras Filosofais;

  • mundos, dimensões e entidades superiores;

  • o relacionamento entre Yogiri e Tomochika;

  • o retorno ao mundo original.

A J-Novel Club publica a tradução digital em inglês, enquanto a edição impressa está associada à Yen Press.

Mangá

O mangá recebe o subtítulo —AΩ—, reforçando a ideia de alfa e ômega, começo e fim.

A adaptação é ilustrada por Hanamaru Nanto e começou na Comic Earth Star em março de 2018. Até janeiro de 2026, seus capítulos haviam sido reunidos em 13 volumes.

Para quem achou o anime rápido demais, o mangá oferece melhor respiração visual. A light novel, entretanto, continua sendo a versão mais completa para compreender as regras, pensamentos e implicações metafísicas.


🎮 Existem jogos?

Até agosto de 2026, não há um jogo eletrônico próprio de grande porte oficialmente anunciado para a franquia — nada equivalente a um RPG para consoles, jogo de luta, visual novel ou MMORPG dedicado exclusivamente a Instant Death.

Também não encontrei confirmação oficial suficientemente sólida de um projeto autônomo para celulares.

Isso não significa que a obra seja incompatível com jogos. Pelo contrário, ela vive satirizando mecânicas de RPG:

  • classes;

  • níveis;

  • atributos;

  • missões;

  • habilidades especiais;

  • chefes;

  • ressurreição;

  • condições de vitória;

  • sistemas administrados por entidades superiores.

O problema de adaptar Yogiri para um jogo é técnico e filosófico. Um botão capaz de matar qualquer chefe instantaneamente destruiria o balanceamento. Enfraquecer Yogiri para preservar o gameplay destruiria o personagem.

Seria o primeiro jogo em que o maior desafio do desenvolvedor não seria derrotar o chefe final, mas impedir o protagonista de encerrar o executável.


🌍 Impacto cultural

Instant Death não alcançou o impacto popular de Sword Art Online, Re:Zero, KonoSuba ou Mushoku Tensei. Seu impacto é mais específico.

A obra conquistou espaço principalmente em três conversas:

A saturação dos isekais

Ela chegou num momento em que o público já reconhecia automaticamente:

  • o caminhão;

  • a convocação;

  • o Gift;

  • o aventureiro Rank S;

  • a escrava que vira companheira;

  • o harém;

  • o protagonista secreto;

  • a guilda;

  • o Rei Demônio.

Fujitaka utiliza essa alfabetização coletiva para apresentar e desmontar os clichês em alta velocidade.

As discussões de power scaling

Yogiri tornou-se presença frequente em debates sobre personagens mais poderosos dos animes e light novels.

Essas discussões às vezes perdem o ponto da obra. Yogiri foi construído justamente para ridicularizar a comparação infinita de atributos. Quando alguém pergunta se determinado personagem resistiria à morte instantânea, já entrou na piada criada pelo autor.

A transformação do overpower em horror cósmico

O anime começa parecendo uma comédia de poder e lentamente revela que Yogiri talvez seja algo incompreensível ocupando uma forma humana.

Esse cruzamento entre isekai, paródia e horror cósmico diferencia a série de protagonistas que apenas possuem números maiores.

A recepção ficou dividida. Parte do público percebeu a sátira e apreciou o humor seco. Outra parte viu apenas batalhas sem tensão, produção limitada e excesso de personagens descartáveis.

As duas leituras possuem fundamento.

O anime é simultaneamente uma paródia inteligente e uma adaptação apressada.


⚖️ Então ele é herói, anti-herói ou desastre natural?

Yogiri não busca governar, enriquecer, formar um harém ou ser reconhecido.

Ele quer voltar para casa.

Isso o aproxima do herói clássico, mas seu método e sua natureza dificultam a classificação. Ele não salva todo mundo, não procura corrigir todas as injustiças e raramente intervém em conflitos que não o atingem.

Também não é um anti-herói vingativo como Touka Mimori, de Failure Frame.

Touka utiliza crueldade, estratégia e ressentimento como ferramentas para sobreviver e buscar justiça. Yogiri não precisa de estratégia de combate. Seu conflito está em decidir quando o uso de uma solução absoluta é moralmente aceitável.

Ele se parece menos com um guerreiro e mais com uma lei natural.

Um terremoto não é herói nem vilão.

Mas Yogiri possui algo que o terremoto não tem: Asaka ensinou-lhe a perguntar se alguém merece ser preservado.


🖥️ A analogia para o coboleiro

Imagine um ambiente gigantesco:

  • os Sábios administram o sistema;

  • a Battle Song é o sistema operacional;

  • os Gifts são perfis de acesso;

  • os níveis são métricas de consumo;

  • os dragões são workloads críticos;

  • os heróis são usuários privilegiados;

  • os deuses são fornecedores que juram controlar a infraestrutura;

  • Sion é a administradora que instala agentes sem change;

  • Tomochika é a analista que ainda lê o manual;

  • Mokomoko é aquela rotina legada que ninguém documentou, mas que mantém tudo funcionando.

Yogiri?

Yogiri não possui user ID.

Ele é o botão vermelho instalado atrás do prédio.


☕ Veredicto do Bellacosa Mainframe

Sokushi Cheat parece um isekai preguiçoso sobre um adolescente invencível, mas funciona melhor quando entendido como uma sátira sobre o abuso do poder e a obsessão do gênero por hierarquias.

Seu maior acerto está em transformar cada novo personagem numa pergunta:

O que uma pessoa faria se acreditasse ser intocável?

Quase todos respondem mal.

Então encontram Yogiri — a prova viva de que sempre pode existir uma camada acima daquela que julgamos controlar.

A primeira temporada sofre com orçamento limitado, ritmo acelerado e excesso de material comprimido. Algumas histórias parecem começar no meio; personagens entram, explicam três habilidades e desaparecem antes de o espectador aprender seus nomes.

Porém, esse caos também produz sua identidade.

É como se quinze animes diferentes tivessem sido carregados no mesmo LPAR. Cada protagonista chega convencido de possuir prioridade máxima, exige mais memória, abre uma disputa por recursos e ameaça derrubar a operação.

Yogiri consulta o painel.

Tomochika pergunta se aquilo é realmente necessário.

Mokomoko faz um comentário inconveniente.

E mais um candidato a Deus descobre, tarde demais, que “imortal” era apenas um campo mal preenchido no cadastro.

Porque, no final, Sokushi Cheat não é exatamente uma história sobre o homem mais poderoso do mundo.

É a história de um mundo inteiro descobrindo que nunca teve autoridade sobre o comando STOP.

E Yogiri Takatō, ainda com sono, acabou de localizar o console.

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