Yashahime: The Second Act : Quando um Programador COBOL Descobre que a Modernização Não Termina no Primeiro Deploy...

 

Bellacosa Mainframe apresenta yashahim the second act

☕ Um Café no Bellacosa Mainframe

Yashahime: The Second Act (半妖の夜叉姫 弐の章) sem Mistérios

Quando um Programador COBOL Descobre que a Modernização Não Termina no Primeiro Deploy... Ela Continua Até que a Nova Equipe Consiga Manter o Sistema Sozinha

"Todo projeto de modernização possui duas fases. A primeira é colocar o sistema para funcionar. A segunda, muito mais difícil, é garantir que a nova geração consiga operá-lo sem depender eternamente dos arquitetos originais. Yashahime: The Second Act é exatamente essa segunda fase."

---

Introdução

Após uma primeira temporada que dividiu opiniões, Yashahime: The Second Act chegou em 2021 com uma missão clara:

Responder às perguntas deixadas em aberto.

Expandir o passado de Sesshomaru.

Explicar o destino de Inuyasha e Kagome.

Concluir a história das três protagonistas.

O resultado foi uma temporada muito mais focada.

Mais emocional.

Mais consistente.

E muito melhor recebida pelos fãs.

Para muitos, esta segunda temporada finalmente entregou aquilo que esperavam desde o anúncio da continuação.

---

Dados Técnicos

Título Original

半妖の夜叉姫 弐の章

Han'yō no Yashahime: Ni no Shō

Tradução aproximada:

Princesas Meio-Yokai – Segundo Capítulo

Título internacional:

Yashahime: Princess Half-Demon – The Second Act

---

Universo Original

Criado por

Rumiko Takahashi

Participação:

• design dos personagens

• supervisão visual

• conceitos gerais

---

Estúdio

Sunrise

(atualmente Bandai Namco Film Works)

---

Diretor

Teruo Sato

---

Roteiro

Katsuyuki Sumisawa

---

Exibição

02 de outubro de 2021

até

26 de março de 2022

---

Episódios

24

---

Gênero

• Fantasia

• Ação

• Aventura

• Drama

• Sobrenatural

• Mitologia Japonesa

• Shōnen

---

Classificação

14 anos

Contém:

• batalhas

• violência moderada

• sangue leve

• drama familiar

• perdas

• conflitos emocionais

---

Sinopse

Depois de inúmeros confrontos...

Towa...

Setsuna...

e Moroha...

aproximam-se da verdade.

Agora precisam compreender:

o plano de Sesshomaru

o verdadeiro objetivo de Kirinmaru

a ligação entre Zero e o destino das famílias.

Enquanto isso...

novas ameaças colocam em risco tanto o Japão Feudal quanto o mundo moderno.

---

Resumo

A temporada concentra-se em:

• recuperar memórias

• unir famílias

• derrotar Kirinmaru

• compreender Zero

• concluir a jornada iniciada na primeira temporada

É praticamente um grande arco final.

---

A História

Grande parte dos mistérios deixados pela primeira temporada finalmente recebe explicações.

Descobrimos:

por que Sesshomaru tomou determinadas decisões.

Como Inuyasha e Kagome sobreviveram.

Qual o verdadeiro significado da Árvore das Eras.

Como Kirinmaru interpretou a antiga profecia.

As batalhas tornam-se muito maiores.

O desenvolvimento emocional também.

---

Os Personagens

Towa

Agora assume definitivamente o papel de protagonista.

Aprende que força também exige responsabilidade.

---

Setsuna

Sua recuperação emocional é um dos pontos altos.

Finalmente compreende sua própria identidade.

---

Moroha

Continua sendo o coração da equipe.

Mistura humor.

Coragem.

Espontaneidade.

---

Sesshomaru

Talvez receba aqui seu maior desenvolvimento desde The Final Act.

Boa parte de suas atitudes finalmente faz sentido.

---

Kirinmaru

Deixa de ser apenas um grande guerreiro.

Mostra enorme complexidade.

Seu medo do futuro conduz muitas de suas escolhas.

---

Zero

Recebe um dos encerramentos mais emocionantes da temporada.

Mostra que ressentimento pode destruir séculos de felicidade.

---

Inuyasha

Mesmo aparecendo menos do que muitos fãs gostariam, continua sendo peça importante para o desfecho da história.

---

Kagome

Mantém seu papel como elo entre gerações e símbolo de esperança.

---

O Que Tem de Diferente?

A primeira temporada apresentava muitos mistérios.

A segunda responde praticamente todos.

Também há muito mais participação dos personagens clássicos, especialmente Sesshomaru, Inuyasha e Kagome, fortalecendo a conexão entre a nova geração e o legado original.

---

Temáticas

Família

Proteção exige escolhas difíceis.

---

Herança

Os filhos não precisam repetir os erros dos pais.

---

Destino

Pode ser mudado.

---

Perdão

Liberta mais do que a vingança.

---

Memória

Mesmo esquecida...

continua moldando quem somos.

---

Crescimento

A nova geração finalmente encontra seu próprio caminho.

---

Aventuras

As protagonistas enfrentam Kirinmaru em confrontos decisivos, exploram os mistérios da Árvore das Eras, recuperam lembranças perdidas e atravessam diferentes épocas para impedir que a profecia destrua o equilíbrio entre os mundos.

Ao longo dessa jornada, reencontros aguardados pelos fãs reforçam o vínculo entre pais e filhos e encerram conflitos iniciados ainda na série original.

---

Mensagens Ocultas

Pais Também Erram

Mesmo tentando proteger os filhos.

---

O Futuro Nunca Deve Ser Temer

Ele deve ser construído.

---

O Passado Explica

Mas não determina.

---

O Conhecimento Precisa Ser Compartilhado

Senão desaparece.

---

A Nova Geração Deve Superar

E não apenas copiar.

---

Impacto Cultural

A segunda temporada foi recebida de forma mais positiva que a primeira.

Os fãs elogiaram:

• explicações para mistérios importantes;

• maior presença dos personagens clássicos;

• evolução de Sesshomaru;

• encerramento da história principal;

• qualidade da animação nas batalhas finais.

Ainda assim, parte do público considerou que alguns conflitos poderiam ter recebido mais episódios para um desenvolvimento ainda mais profundo.

---

Censura

Assim como a primeira temporada, The Second Act praticamente não sofreu alterações relevantes fora do Japão.

Os ajustes limitaram-se à classificação indicativa e a pequenas reduções de sangue em algumas transmissões televisivas.

---

Mangás

O mangá de Yashahime, ilustrado por Takashi Shiina, continua adaptando e expandindo a história, acrescentando cenas inéditas e desenvolvendo personagens com maior profundidade do que o anime em diversos momentos.

---

Light Novels

Até o momento, não existe uma continuação oficial em formato de light novel para os acontecimentos após The Second Act.

---

Games

Os personagens da segunda temporada apareceram em:

• eventos especiais da franquia;

• jogos mobile japoneses;

• colaborações promocionais.

Não foi lançado um RPG exclusivo baseado nessa fase da história.

---

Curiosidades

• Muitos dos episódios finais foram elogiados por resolver mistérios que vinham sendo discutidos pelos fãs desde 2020.

• A trilha sonora de Kaoru Wada voltou a utilizar temas clássicos de Inuyasha em momentos decisivos, reforçando o sentimento de continuidade.

• O mangá de Takashi Shiina apresenta diferenças importantes em relação ao anime e é frequentemente recomendado para quem deseja uma versão mais detalhada da narrativa.

---

Easter Eggs

• O reencontro entre personagens clássicos simboliza a passagem definitiva do bastão para a nova geração.

• A Árvore das Eras continua funcionando como uma metáfora para a ligação entre memória, tempo e destino.

• Sesshomaru mantém sua postura reservada até o fim, preservando a coerência de sua evolução iniciada décadas antes.

---

Avaliação Bellacosa Mainframe

Aspecto	Nota
História	⭐⭐⭐⭐☆ (4,5/5)
Desenvolvimento dos Personagens	⭐⭐⭐⭐⭐ (5/5)
Ação	⭐⭐⭐⭐☆ (4,5/5)
Emoção	⭐⭐⭐⭐⭐ (5/5)
Trilha Sonora	⭐⭐⭐⭐⭐ (5/5)
Encerramento	⭐⭐⭐⭐☆ (4,5/5)
Reassistir	⭐⭐⭐⭐☆ (4,5/5)

Nota Final: 9,3/10

A segunda temporada consegue fortalecer a proposta de Yashahime, aproximando a nova geração do legado de Inuyasha e oferecendo um encerramento satisfatório para a maioria dos arcos apresentados.

---

☕ Bellacosa Mainframe

Imagine um grande projeto de modernização de um ambiente IBM Z.

Na primeira fase, a equipe migra aplicações, cria pipelines de CI/CD, integra APIs e documenta processos.

Mas o verdadeiro teste começa depois do deploy.

A nova equipe precisa operar o sistema sem depender diariamente dos arquitetos veteranos.

Towa representa a desenvolvedora que finalmente domina tanto as tecnologias modernas quanto o ambiente legado.

Setsuna simboliza a especialista operacional que recupera o contexto perdido e transforma experiência em conhecimento compartilhado.

Moroha é a analista criativa que une tradição e inovação para resolver problemas inesperados.

Sesshomaru assume o papel do arquiteto sênior que observa à distância, intervindo apenas quando realmente necessário, permitindo que a nova geração conquiste sua autonomia.

No fim, Yashahime: The Second Act transmite uma lição que todo profissional de tecnologia aprende cedo ou tarde: um projeto de modernização só pode ser considerado concluído quando o conhecimento deixa de estar preso a uma única pessoa e passa a fazer parte da cultura da equipe. O legado mais valioso nunca foi o código. Sempre foi a capacidade de ensinar outros a compreendê-lo e evoluí-lo.

SECTION e PARAGRAPH no COBOL sem Mistérios

 

Bellacosa Mainframe e a section e paragraph no cobol

☕ Um Café no Bellacosa Mainframe

SECTION e PARAGRAPH no COBOL sem Mistérios

Como um Programador COBOL Padawan Aprende a Organizar seu Código como um Oficial da Frota Estelar

"A diferença entre um programa que apenas funciona e um programa que sobrevive por décadas está na sua organização."

---

Introdução — A Primeira Missão do Padawan COBOL

Imagine que você acaba de chegar à USS Enterprise.

O Capitão pede para localizar um problema em um sistema de navegação criado há 35 anos.

Você abre o código.

São 18.000 linhas de COBOL.

Não existe um comentário.

Não existe uma SECTION.

Não existe um PERFORM.

Apenas um gigantesco fluxo de GO TO.

Você pensa:

"Quem escreveu isso?"

A resposta normalmente é:

"Alguém extremamente inteligente...
...
...
em 1984."

Bem-vindo ao mundo real do Mainframe.

Uma das primeiras lições que um programador COBOL aprende é que escrever código é relativamente fácil.

O difícil é escrever código que outra pessoa consiga entender vinte anos depois.

É exatamente aí que entram os conceitos de PARAGRAPH e SECTION.

Eles existem desde os primórdios da linguagem e continuam presentes até hoje, mesmo em programas escritos para IBM z17, COBOL 6.5 e aplicações modernas integradas com APIs REST.

E curiosamente, muita gente usa os dois sem realmente entender por que eles existem.

Hoje vamos viajar até a origem desse conceito.

---

A origem histórica

Para entender SECTION precisamos voltar aos anos 60.

Naquela época:

• memória custava uma fortuna;

• CPU era extremamente cara;

• cartões perfurados eram comuns;

• manutenção era muito mais importante que desenvolvimento.

A equipe que criou o COBOL queria que programas fossem parecidos com documentos administrativos.

Por isso surgiram divisões naturais:

IDENTIFICATION DIVISION

ENVIRONMENT DIVISION

DATA DIVISION

PROCEDURE DIVISION

Mas logo perceberam um problema.

A PROCEDURE DIVISION podia crescer para milhares de linhas.

Era necessário organizá-la.

Assim nasceram:

• Paragraphs

• Sections

Inspirados em capítulos e subtítulos de documentos.

Ou seja:

Documento

↓

Capítulo

↓

Subcapítulo

↓

Parágrafo

Exatamente como um livro.

---

O que é um Paragraph?

Um paragraph é simplesmente um bloco de instruções identificado por um nome.

Exemplo:

CALCULA-TOTAL.

    ADD VALOR TO TOTAL.

    COMPUTE IMPOSTO = TOTAL * 0.15.

    EXIT.

O nome termina com ponto.

Depois vêm os comandos.

---

Pode ser chamado assim:

PERFORM CALCULA-TOTAL

Muito simples.

---

O que é uma SECTION?

Uma SECTION é um agrupador de paragraphs.

Exemplo

CALCULO SECTION.

CALCULA-TOTAL.

...

CALCULA-IMPOSTO.

...

VALIDACOES SECTION.

VALIDA-CPF.

...

VALIDA-DATA.

...

Ou seja

Section

↓

Paragraph

↓

Comandos

---

É uma organização hierárquica.

---

Visualizando

PROCEDURE DIVISION

MAIN SECTION

   INICIO

   PROCESSA

   FINALIZA

LEITURA SECTION

   LE-DADOS

   LE-CLIENTE

CALCULOS SECTION

   SOMA

   DESCONTO

GRAVACAO SECTION

   ESCREVE

É praticamente uma árvore.

---

Por que isso foi criado?

Porque programas COBOL começaram a ficar enormes.

Muito antes da orientação a objetos.

Muito antes de módulos.

Muito antes de classes.

A SECTION funcionava como um "módulo lógico".

---

Como funciona internamente?

Quando fazemos

PERFORM CALCULA-TOTAL

O runtime:

guarda o endereço atual

↓

salta

↓

executa

↓

volta

Semelhante a uma chamada de função.

---

Quando fazemos

PERFORM CALCULO

e CALCULO é uma SECTION...

Ele executa TODOS os paragraphs daquela section.

Exemplo

CALCULO SECTION.

SOMA.

...

IMPOSTO.

...

DESCONTO.

Resultado

SOMA

↓

IMPOSTO

↓

DESCONTO

Tudo automaticamente.

---

Este detalhe pega muitos iniciantes

Imagine

VALIDACAO SECTION.

VALIDA-A.

...

VALIDA-B.

...

VALIDA-C.

...

Se fizer

PERFORM VALIDACAO

Executará

A

↓

B

↓

C

Mesmo que você só queira A.

---

Então por que existem paragraphs?

Porque podemos chamar apenas um deles.

PERFORM VALIDA-B

Executa somente aquele.

---

O famoso EXIT

Quase todo mundo vê isso

EXIT.

e pensa

"isso encerra o paragraph."

Na verdade...

Não exatamente.

EXIT é praticamente um "não faça nada".

Uma instrução nula.

Ela existe para marcar explicitamente um ponto de saída.

---

Exemplo

CALCULA.

   ADD 1 TO TOTAL.

   EXIT.

O runtime simplesmente passa por ela.

---

Então por que usar?

Porque melhora a legibilidade.

Especialmente quando existem PERFORM THRU.

---

EXIT SECTION

Existe também

EXIT SECTION

Muito mais moderno.

Ele encerra imediatamente a section.

---

EXIT PARAGRAPH

Também existe.

EXIT PARAGRAPH

Ele retorna imediatamente daquele paragraph.

Muito mais claro.

---

Antigamente

Antes dessas instruções modernas era comum encontrar

GO TO FIM-ROTINA.

Hoje isso é considerado má prática.

---

GO TO versus PERFORM

Imagine

A

↓

GO TO C

↓

B

↓

GO TO D

↓

C

↓

GO TO A

Parece um prato de espaguete.

Daí surgiu o termo

Spaghetti Code.

---

PERFORM resolveu boa parte desse problema.

---

Curiosidade

Nos anos 70 havia programas COBOL com mais de:

300 paragraphs

100 sections

40 mil linhas

E muitos ainda funcionam hoje.

---

Performance

Uma pergunta muito comum.

"Section é mais lenta?"

Resposta:

Praticamente não.

O compilador moderno otimiza quase tudo.

A diferença costuma ser insignificante.

---

Onde realmente existe custo?

PERFORM

↓

retorno

↓

pilha

↓

controle

Mas isso é extremamente pequeno.

---

Na prática

Legibilidade vale infinitamente mais.

---

PERFORM THRU

Exemplo

PERFORM A THRU C

Executa

A

↓

B

↓

C

Muito usado antigamente.

Hoje muitos times evitam.

---

Por quê?

Porque se alguém inserir

B2

no meio...

O comportamento muda.

Sem ninguém perceber.

---

Truque interessante

Sections permitem criar fases.

INICIALIZACAO

PROCESSAMENTO

RELATORIOS

FINALIZACAO

Cada uma possui seus próprios paragraphs.

Muito organizado.

---

Outro truque

Usar prefixos.

1000-INICIO

1100-LE-DADOS

1200-PROCESSA

1300-GRAVA

9000-FIM

Muito comum em bancos.

---

Por quê?

Porque facilita localizar no editor.

---

Outro padrão clássico

A000

A100

A200

B000

B100

Também extremamente comum.

---

Cuidados

Nunca misture assuntos.

Ruim

CLIENTE

↓

GRAVA ARQUIVO

↓

FAZ SQL

↓

ENVIA MQ

↓

CALCULA IMPOSTO

Bom

CLIENTE SECTION

↓

DB2 SECTION

↓

MQ SECTION

↓

CALCULO SECTION

---

Outro cuidado

Não faça Sections gigantes.

Ruim

PROCESSA SECTION

3500 linhas

Bom

LEITURA

VALIDACAO

NEGOCIO

DB2

LOG

MQ

FINAL

---

Quantos paragraphs?

Não existe regra.

Mas normalmente:

5

10

20

é confortável.

---

Deve existir apenas uma MAIN?

Quase sempre sim.

Exemplo

MAIN.

PERFORM INICIALIZA

PERFORM PROCESSA

PERFORM FINALIZA

STOP RUN

A leitura fica excelente.

---

Curiosidade histórica

Muitos compiladores antigos geravam código praticamente na mesma ordem dos paragraphs.

Hoje isso mudou completamente.

O compilador reorganiza diversas instruções.

---

O compilador pode ignorar Sections?

Em muitos casos sim.

Principalmente quando faz otimizações.

Ele pode inline routines.

Eliminar saltos.

Fundir blocos.

---

O que IBM recomenda?

Hoje a IBM incentiva:

✔ PERFORM

✔ EXIT PARAGRAPH

✔ EXIT SECTION

✔ evitar GO TO

✔ evitar ALTER

✔ modularização

✔ nomes claros

---

Um exemplo elegante

PROCEDURE DIVISION.

MAIN.

    PERFORM INICIALIZA

    PERFORM PROCESSA-PEDIDOS

    PERFORM GERA-RELATORIO

    PERFORM FINALIZA

    GOBACK.

Depois

PROCESSA-PEDIDOS SECTION.

LE-DADOS.

VALIDA-DADOS.

ATUALIZA-DB2.

ENVIA-MQ.

EXIT.

A leitura fica praticamente uma documentação.

---

Quando NÃO usar Sections?

Existem equipes modernas que preferem apenas paragraphs.

Por quê?

Porque:

PERFORM paragraph

é suficiente.

Especialmente em programas pequenos.

---

Quando usar Sections?

Em sistemas grandes.

Com dezenas de módulos lógicos.

Principalmente:

• Bancos

• Seguradoras

• Governo

• Telecom

• ERP

---

Easter Egg Mainframe ☕

Existe uma brincadeira antiga entre programadores veteranos.

Se um programa possui:

• GO TO para todos os lados

• ALTER

• PERFORM THRU cruzando o programa inteiro

• sem SECTION

• sem comentários

ele recebe um apelido carinhoso:

"Programa Teletransporte."

Você nunca sabe exatamente onde está.

Assim como um oficial preso em um teletransporte defeituoso da Frota Estelar.

---

Analogia com a USS Enterprise

Imagine a Enterprise.

Ela possui setores.

Engenharia

Ponte

Enfermaria

Hangar

Laboratórios

Cada setor possui equipes.

Na Engenharia:

Reator

Motores

Dilithium

Warp

Isso é exatamente uma SECTION contendo diversos PARAGRAPHS.

Ninguém colocaria o controle do motor Warp dentro da enfermaria.

Da mesma forma, um programa COBOL bem projetado separa responsabilidades em áreas distintas, facilitando a manutenção e reduzindo o risco de alterações acidentais.

---

Boas práticas para o Padawan COBOL

Ao longo de décadas de evolução do COBOL, algumas práticas se mostraram consistentes em equipes de alta maturidade:

• Mantenha uma MAIN pequena, que apenas orquestre o fluxo principal.

• Agrupe rotinas relacionadas em SECTIONs com responsabilidade única.

• Dê nomes descritivos aos PARAGRAPHs, usando verbos que indiquem claramente sua função, como VALIDA-CLIENTE, CALCULA-TOTAL ou GRAVA-HISTORICO.

• Prefira PERFORM a GO TO para manter o fluxo previsível.

• Utilize EXIT PARAGRAPH e EXIT SECTION quando desejar uma saída explícita e fácil de entender.

• Evite PERFORM THRU em novos desenvolvimentos, pois pequenas alterações podem modificar o comportamento sem chamar atenção.

• Procure manter cada paragraph relativamente curto. Se ele começa a fazer muitas coisas diferentes, provavelmente merece ser dividido.

• Separe regras de negócio, acesso a banco, manipulação de arquivos e integração com outros sistemas em blocos distintos.

• Comente o motivo das decisões mais complexas, e não apenas o que o código faz.

---

Pontos para Fixar

✔ Paragraph é uma rotina identificada por um nome.

✔ Section é um agrupamento de paragraphs relacionados.

✔ PERFORM paragraph executa apenas aquele bloco.

✔ PERFORM section executa todos os paragraphs pertencentes àquela section, em sequência.

✔ EXIT. é uma instrução nula usada tradicionalmente como marcador de fim.

✔ EXIT PARAGRAPH e EXIT SECTION tornam o fluxo de saída mais explícito e legível.

✔ O ganho de organização quase sempre supera qualquer preocupação com desempenho.

✔ O compilador Enterprise COBOL moderno realiza diversas otimizações, tornando diferenças de performance entre uma boa organização em sections e paragraphs praticamente irrelevantes na maioria das aplicações.

✔ Código legível reduz tempo de manutenção, facilita revisões e diminui a probabilidade de defeitos em sistemas que frequentemente permanecem em produção por décadas.

---

Conclusão — Organizando a Ponte de Comando

No universo de Jornada nas Estrelas, a USS Enterprise não funciona porque possui apenas motores potentes. Ela funciona porque cada setor conhece sua responsabilidade, cada oficial sabe quando agir e a cadeia de comando é clara.

Um programa COBOL de qualidade segue exatamente essa filosofia.

As SECTIONs representam os grandes departamentos da nave. Os PARAGRAPHs são as equipes especializadas que executam cada missão. O PERFORM atua como a ordem do capitão, chamando apenas a rotina necessária no momento certo. Já o EXIT PARAGRAPH e o EXIT SECTION funcionam como um retorno organizado ao posto de comando, sem desvios inesperados.

Muitos sistemas críticos escritos há mais de quarenta anos continuam processando milhões de transações diárias justamente porque foram estruturados com disciplina. A tecnologia evoluiu, o compilador ficou mais inteligente, surgiram otimizações, integração com APIs, DevOps e inteligência artificial, mas um princípio permaneceu praticamente inalterado desde o nascimento do COBOL: um código bem organizado é um código que atravessa gerações.

Como diria o Sr. Spock, adaptando sua lógica ao mundo do IBM Z:

"A elegância de um programa não está na quantidade de instruções, mas na clareza com que cada uma cumpre seu propósito."

E esse talvez seja o maior aprendizado para todo Programador COBOL Padawan: escrever para o computador é fácil; escrever para os próximos cinquenta anos de manutenção é a verdadeira arte do Mainframe.

Shūmatsu no Hāremu (終末のハーレム / World's End Harem)

 

Bellacosa Mainframe apresenta shumatsu no haremu

☕ Um Café no Bellacosa Mainframe

Shūmatsu no Hāremu (終末のハーレム / World's End Harem)

Quando um Programador COBOL Descobre que a Continuidade do Sistema Depende de Apenas Cinco Recursos Críticos

---

Dados da Obra

• Título original: 終末のハーレム (Shūmatsu no Hāremu)

• Título internacional: World's End Harem

• Autor (roteiro): LINK

• Ilustrador: Kotaro Shōno

• Mangá: 8 de maio de 2016

• Anime: estreia em 8 de outubro de 2021, com os episódios seguintes adiados e reestreia completa em 7 de janeiro de 2022, encerrando em 18 de março de 2022. (Wikipedia)

• Estúdios: Studio Gokumi × AXsiZ

• Diretor: Yuu Nobuta

• Roteiro: Tatsuya Takahashi

• Episódios: 11

• Duração: cerca de 24 minutos por episódio

• Gênero: Ficção científica, suspense, drama, romance, ecchi, harém, mistério. (Wikipedia)

---

Sinopse

Em 2040, um vírus chamado MK (Male Killer) extermina aproximadamente 99,9% da população masculina mundial.

Cinco homens sobrevivem graças à criogenia.

Ao despertar cinco anos depois, Reito Mizuhara descobre um planeta governado quase exclusivamente por mulheres.

Agora ele possui duas escolhas:

• participar do programa de reprodução da humanidade;

• descobrir quem criou o vírus e encontrar sua amada Erisa.

A partir daí, começa uma conspiração mundial muito maior do que aparenta. (Wikipedia)

---

Resumo

À primeira vista, parece apenas um anime de fanservice.

Na prática, é um thriller de ficção científica.

A narrativa mistura:

• pandemia;

• manipulação genética;

• conspirações internacionais;

• controle populacional;

• ética científica;

• biopolítica.

O ecchi funciona como consequência da premissa, não como único objetivo da história.

---

História

Após o desaparecimento quase completo dos homens, surge uma nova ordem mundial administrada pela organização UW (United Women).

Ela controla:

• governos;

• pesquisas;

• informações;

• sobreviventes;

• reprodução humana.

Os cinco sobreviventes recebem o título de Numbers, homens naturalmente imunes ao vírus.

Cada um reage de maneira diferente ao novo mundo.

Enquanto alguns aceitam os privilégios oferecidos, Reito desconfia que existe algo profundamente errado.

Sua investigação revela uma conspiração envolvendo poder, ciência e manipulação da própria evolução humana.

---

Principais Personagens

Reito Mizuhara

O protagonista.

Estudante de medicina.

Representa ética, racionalidade e curiosidade científica.

Recusa-se inicialmente a cumprir seu papel reprodutivo porque continua apaixonado por Erisa.

---

Mira Suou

Assistente oficial designada para acompanhar Reito.

Inicialmente parece apenas uma funcionária da UW.

Com o passar da história demonstra grande evolução emocional.

---

Erisa Tachibana

Namorada de infância de Reito.

Seu desaparecimento impulsiona toda a investigação.

É uma das maiores peças do mistério.

---

Shota Doi

Talvez o personagem mais interessante psicologicamente.

Antes era vítima de bullying.

Depois torna-se um dos homens mais poderosos do planeta.

Mostra como poder absoluto pode transformar completamente uma pessoa.

---

Reito Kuroda

Outro sobrevivente.

Segue um caminho completamente diferente do protagonista.

Serve para mostrar que pessoas distintas respondem de maneiras diferentes à mesma crise.

---

O que diferencia World's End Harem?

O diferencial não é o ecchi.

É a premissa.

Enquanto muitos animes harém utilizam situações escolares ou mágicas, Shūmatsu no Hāremu cria uma justificativa científica para todo o cenário.

Além disso, a obra aborda:

• engenharia genética;

• pandemias;

• propaganda estatal;

• experimentação humana;

• ética médica;

• manipulação da informação.

Tudo isso lembra bastante romances de ficção científica clássicos.

---

Temática

Os grandes temas incluem:

• sobrevivência da humanidade;

• liberdade individual;

• responsabilidade científica;

• ética da reprodução;

• abuso do poder;

• engenharia genética;

• desigualdade de informação;

• corrupção institucional;

• manipulação política.

---

Classificação

Faixa etária: +18

Motivos:

• nudez;

• erotismo;

• violência;

• conteúdo psicológico;

• temas adultos.

Apesar disso, existe uma narrativa consistente por trás do fanservice.

---

Aventuras

Durante a série encontramos:

• laboratórios secretos;

• organizações internacionais;

• espionagem;

• investigações científicas;

• perseguições;

• ataques biológicos;

• conspirações políticas;

• descobertas sobre o vírus MK.

Conforme a história avança, o romance perde espaço para o suspense.

---

Mensagens Ocultas

1. Recursos escassos mudam toda a arquitetura

No anime existem apenas cinco homens férteis.

No IBM Z acontece algo parecido.

Imagine um banco perder praticamente todos os especialistas COBOL.

Os poucos restantes tornam-se recursos estratégicos.

Toda a organização passa a depender deles.

---

2. Informação vale mais que força

Reito não vence por lutar.

Ele vence porque faz perguntas.

No mundo corporativo acontece exatamente o mesmo.

Quem entende o negócio possui vantagem muito maior que quem apenas conhece tecnologia.

---

3. A ética precisa acompanhar a inovação

A ciência cria possibilidades.

Mas quem decide como utilizá-las são pessoas.

O anime questiona constantemente:

"Até onde podemos ir para garantir a sobrevivência da espécie?"

---

4. Sistemas fechados escondem riscos

A UW controla praticamente todas as informações.

Sem transparência, qualquer sistema pode ser manipulado.

É um excelente paralelo com governança de TI.

---

5. Nem toda crise é apenas uma crise

O vírus parece ser o problema.

Depois descobrimos que ele também se tornou instrumento político.

Grandes eventos frequentemente produzem novas estruturas de poder.

---

Bellacosa Mainframe

Imagine um banco mundial.

Uma falha elimina 99,9% dos programadores COBOL experientes.

Restam apenas cinco.

Esses cinco passam a decidir:

• continuidade operacional;

• modernização;

• recuperação de incidentes;

• conhecimento institucional.

É exatamente essa lógica de escassez extrema que move toda a narrativa de World's End Harem.

O verdadeiro protagonista não é o harém.

É a administração de um recurso crítico.

---

Studio Gokumi × AXsiZ

A animação apresenta:

Pontos fortes

• personagens visualmente bem desenhados;

• boa iluminação;

• excelente direção de arte;

• trilha sonora competente;

• atmosfera futurista.

Pontos fracos

• animação limitada em cenas de ação;

• ritmo irregular;

• adaptação acelerada;

• várias partes do mangá ficaram de fora.

Mesmo assim, a produção entrega uma ambientação convincente para um thriller de ficção científica. (Wikipedia)

---

Impacto Cultural

World's End Harem chamou atenção antes mesmo da estreia por sua premissa provocativa. Após a exibição antecipada do primeiro episódio em outubro de 2021, a produção foi adiada para janeiro de 2022 para revisão da qualidade, o que gerou intensa discussão entre fãs. A série também impulsionou debates sobre pandemia, bioética, liberdade individual e manipulação científica, especialmente em um período em que o mundo ainda vivia os reflexos da COVID-19. (Wikipedia)

---

Curiosidades

• O mangá começou em Shōnen Jump+ em 2016.

• A franquia ganhou derivados como World's End Harem: Fantasia, ambientado em um universo de fantasia medieval, e outras obras paralelas. (Wikipedia)

---

Veredito Bellacosa

Categoria	Nota
História	⭐⭐⭐⭐☆ (8,5)
Ficção Científica	⭐⭐⭐⭐⭐ (9,2)
Suspense	⭐⭐⭐⭐☆ (8,7)
Construção de Mundo	⭐⭐⭐⭐☆ (8,6)
Personagens	⭐⭐⭐⭐☆ (8,4)
Ecchi/Fanservice	⭐⭐⭐⭐⭐
Originalidade	⭐⭐⭐⭐⭐ (9,5)

Nota Final

⭐⭐⭐⭐☆ (8,8/10)

Shūmatsu no Hāremu costuma ser lembrado pelo fanservice, mas sua verdadeira força está na combinação de suspense, ficção científica e dilemas éticos. Para um leitor ou espectador disposto a olhar além da superfície, a obra levanta questões relevantes sobre poder, ciência, governança e o valor estratégico dos recursos mais escassos — uma metáfora que conversa surpreendentemente bem com o universo dos grandes sistemas corporativos e do IBM Mainframe.

ABEND sem Mistérios — Parte VIII

 

Bellacosa Mainframe e o abend sem misterios parte viii

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios — Parte VIII

Muito Além do ABEND

Como Pensam os Grandes Especialistas em Mainframe e Por Que Resolver Erros é Apenas uma Pequena Parte da Engenharia de Software no IBM Z

"O iniciante aprende a corrigir ABENDs. O especialista aprende a construir sistemas onde eles se tornam cada vez mais raros."

---

Introdução

Chegamos ao último capítulo desta jornada.

Ao longo desta série, percorremos praticamente todo o universo dos ABENDs no Mainframe.

Começamos compreendendo o significado da palavra ABEND e conhecendo os principais erros encontrados no COBOL, no JCL, no CICS e no z/OS.

Depois aprendemos a investigar mensagens do JES2, utilizar o SDSF, interpretar CEEDUMPs, analisar dumps, compreender o funcionamento da CPU IBM Z, conhecer registradores, PSW, TCB, RB, arquitetura do sistema operacional e até explorar como Inteligência Artificial e Observabilidade estão revolucionando a investigação de incidentes.

Também criamos laboratórios, reproduzimos erros, estudamos engenharia de confiabilidade e analisamos dezenas de práticas utilizadas pelos maiores bancos do mundo.

Mas existe uma pergunta que ainda precisa ser respondida.

Depois de dominar os ABENDs... o que realmente muda?

A resposta é simples.

Tudo.

Porque, na verdade, esta série nunca foi apenas sobre ABENDs.

Ela sempre foi sobre aprender a pensar.

---

O verdadeiro objetivo nunca foi decorar códigos

Existe uma armadilha muito comum entre iniciantes.

Depois de conhecer:

• S0C4

• S0C7

• S013

• S806

• SB37

• ASRA

alguns acreditam que aprenderam a resolver problemas.

Na realidade,

eles aprenderam apenas os sintomas.

O especialista faz outra pergunta.

"Por que esse sistema permitiu que esse problema chegasse até aqui?"

Essa pergunta muda completamente a forma de enxergar software.

---

O Mainframe nunca foi apenas COBOL

Existe outro equívoco bastante comum.

Muitos profissionais dizem:

"Eu sou programador COBOL."

Mas observemos uma execução típica.

Usuário

↓

Canal Digital

↓

API

↓

Load Balancer

↓

Firewall

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

Db2

↓

MQ

↓

Storage

↓

Discos

↓

IBM Z

Onde exatamente termina o COBOL?

A resposta é:

Ele nunca esteve sozinho.

O Mainframe sempre foi um ecossistema.

---

O Programador Padawan

No início da carreira,

a maior preocupação costuma ser:

"Meu programa compilou?"

Depois evolui para:

"Meu programa executou?"

Mais tarde:

"Meu programa funciona?"

O especialista vai além.

Ele pergunta:

"Meu programa continuará funcionando daqui a dez anos?"

Essa é a diferença entre escrever código e construir sistemas.

---

A evolução do pensamento técnico

Observe como um profissional amadurece.

Nível 1

Escreve código.

↓

Nível 2

Corrige erros.

↓

Nível 3

Investiga ABENDs.

↓

Nível 4

Entende arquitetura.

↓

Nível 5

Previne incidentes.

↓

Nível 6

Melhora processos.

↓

Nível 7

Ensina outras pessoas.

É nesse último estágio que nasce um verdadeiro especialista.

---

O valor da curiosidade

Existe uma característica comum entre praticamente todos os grandes profissionais de Mainframe.

Eles fazem perguntas.

Muitas perguntas.

Por exemplo.

Por que existe um PSW?

Por que o CICS funciona dessa maneira?

Como o Dispatcher escolhe a próxima tarefa?

Por que um dump possui milhares de páginas?

Como o WLM distribui CPU?

Como o Db2 gerencia locks?

Por que um S0C4 acontece exatamente naquele endereço?

A curiosidade é um acelerador de carreira.

---

Os profissionais mais respeitados não decoram comandos

Eles compreendem conceitos.

Imagine dois programadores.

O primeiro decorou:

DISPLAY

LISTCAT

IDCAMS

ALLOC

FREE

LISTDSI

O segundo entende:

• armazenamento;

• catálogo;

• datasets;

• buffers;

• VSAM;

• acesso sequencial;

• acesso direto.

Quem terá mais facilidade para aprender novas ferramentas?

Naturalmente o segundo.

Conceitos sobrevivem.

Comandos mudam.

---

O papel da documentação

Em muitas empresas,

resolver um incidente é apenas metade do trabalho.

A outra metade é responder:

Como documentar?

Como compartilhar?

Como evitar novamente?

Um incidente que não gera conhecimento provavelmente voltará a acontecer.

---

A importância da humildade técnica

Existe uma frase muito conhecida na Engenharia.

"Todo software suficientemente complexo possui comportamentos que seus próprios autores não conseguem explicar."

Isso vale para Mainframe.

Vale para Cloud.

Vale para Inteligência Artificial.

Ninguém sabe tudo.

Os melhores profissionais estudam continuamente.

---

O conhecimento coletivo

Os maiores bancos do mundo não dependem apenas de profissionais brilhantes.

Eles dependem de equipes.

Uma investigação normalmente envolve:

• Desenvolvimento;

• Operação;

• SysProg;

• DBA;

• Redes;

• Segurança;

• Middleware;

• Negócio.

Cada grupo observa o incidente por um ângulo diferente.

É essa diversidade que produz as melhores soluções.

---

O papel da IA

Existe muito entusiasmo em torno da Inteligência Artificial.

Ela realmente está mudando o desenvolvimento de software.

Hoje conseguimos:

• resumir dumps;

• explicar SQLCODEs;

• interpretar mensagens IEC;

• sugerir causas prováveis;

• gerar documentação;

• produzir testes.

Mas existe algo que continua exclusivamente humano.

Julgamento.

A IA trabalha com probabilidades.

O engenheiro trabalha com responsabilidade.

---

O especialista não procura culpados

Quando um incidente acontece,

existem duas culturas.

A primeira pergunta:

"Quem escreveu esse programa?"

A segunda pergunta:

"O que precisamos melhorar para que isso nunca mais aconteça?"

A primeira cria medo.

A segunda cria evolução.

As organizações mais maduras escolhem sempre a segunda.

---

A engenharia de software no IBM Z

Hoje um profissional Mainframe trabalha com muito mais do que COBOL.

Ele precisa compreender:

• APIs REST;

• JSON;

• Git;

• DevOps;

• Containers;

• OpenShift;

• z/OS Connect;

• MQ;

• Kafka;

• Observabilidade;

• Automação;

• Inteligência Artificial.

Curiosamente,

isso não diminuiu a importância do COBOL.

Pelo contrário.

Aumentou.

Porque agora ele conversa com praticamente todo o restante da empresa.

---

A cultura da melhoria contínua

Os melhores ambientes seguem um ciclo permanente.

Desenvolver

↓

Testar

↓

Implantar

↓

Monitorar

↓

Aprender

↓

Melhorar

↓

Automatizar

↓

Repetir

Perceba que nunca existe um "fim".

Sempre existe uma próxima evolução.

---

O Mainframe continua ensinando

Existe algo fascinante no IBM Z.

Mesmo profissionais com quarenta anos de experiência continuam aprendendo.

Sempre aparece:

• um novo recurso;

• uma nova arquitetura;

• um novo compilador;

• uma nova API;

• uma nova forma de integrar sistemas;

• uma nova ferramenta de observabilidade.

Essa evolução constante mantém o Mainframe extraordinariamente atual.

---

O legado que realmente importa

No final da carreira,

ninguém será lembrado apenas pelos programas que escreveu.

Será lembrado por:

• sistemas que ajudou a construir;

• incidentes que resolveu;

• pessoas que formou;

• conhecimento que compartilhou.

O código envelhece.

O conhecimento permanece.

---

O Bellacosa Mainframe

Quando comecei a compartilhar conhecimento sobre Mainframe,

o objetivo nunca foi apenas explicar comandos.

Sempre acreditei que tecnologia pode ser ensinada de maneira humana.

Com café.

Com histórias.

Com analogias.

Com curiosidade.

Com respeito por quem está começando.

Todo especialista já foi um Padawan.

E ninguém chega longe sozinho.

Se esta série ajudou você a compreender um pouco melhor o universo dos ABENDs, então ela já cumpriu sua missão.

---

O próximo passo do Programador Padawan

Depois desta série, minha sugestão é continuar explorando temas que complementam a investigação de incidentes:

• Enterprise COBOL 6.x e otimizações do compilador.

• JCL avançado e utilitários do z/OS.

• VSAM em profundidade.

• CICS Transaction Server.

• Db2 for z/OS.

• Language Environment.

• IPCS avançado.

• Fault Analyzer e Debug Tool.

• SMF e RMF.

• WLM e desempenho.

• z/OS Connect e APIs REST.

• Observabilidade no IBM Z.

• DevOps e Git para Mainframe.

• Inteligência Artificial aplicada ao desenvolvimento COBOL.

Cada um desses assuntos amplia sua capacidade de compreender por que um sistema funciona, por que falha e como pode evoluir.

---

Uma última reflexão

Existe uma frase muito conhecida entre os engenheiros aeronáuticos.

"Todo acidente é um relatório técnico esperando para ser escrito."

No Mainframe, podemos adaptar essa ideia.

"Todo ABEND é uma aula de Engenharia de Software esperando para ser compreendida."

Cada S0C7 ensina a validar dados.

Cada S0C4 ensina a respeitar a memória.

Cada S013 ensina que aplicações dependem do ambiente onde executam.

Cada ASRA lembra que uma transação faz parte de um sistema muito maior.

Cada U4038 mostra que uma mensagem nem sempre revela toda a verdade.

E cada investigação bem conduzida torna o profissional mais preparado para o próximo desafio.

---

Conclusão

Esta série não teve como objetivo transformar você em alguém capaz de decorar centenas de códigos de ABEND. Seu propósito foi muito maior: desenvolver uma forma de pensar.

Pensar de maneira sistêmica.

Pensar orientado por evidências.

Pensar em causas, não apenas em sintomas.

Pensar em prevenção antes da correção.

Pensar em qualidade antes da urgência.

Esse é o verdadeiro diferencial dos grandes especialistas em IBM Z.

Porque o melhor engenheiro Mainframe não é aquele que resolve o maior número de ABENDs.

É aquele que projeta sistemas, processos e equipes capazes de impedir que eles aconteçam.

E quando um dia eles inevitavelmente surgirem, saberá que cada incidente representa uma oportunidade de aprender, compartilhar conhecimento e tornar o próximo sistema ainda melhor do que o anterior.

Enquanto existir um IBM Z processando milhões de transações com segurança, sempre haverá espaço para profissionais curiosos, disciplinados e apaixonados por aprender. Afinal, no Mainframe, a tecnologia evolui continuamente — e nós evoluímos junto com ela.

Working-Storage vs Local-Storage em COBOL: Muito Além do Static e Dynamic — A Engenharia Invisível que Mantém Milhões de Transações Funcionando

 

Bellacosa Mainframe evoluindo o data division trabalhando com o working-storage vrs local-storage

☕ Um Café no Bellacosa Mainframe

Working-Storage vs Local-Storage em COBOL: Muito Além do Static e Dynamic — A Engenharia Invisível que Mantém Milhões de Transações Funcionando

"Todo programador COBOL aprende cedo que existe a Working-Storage Section e a Local-Storage Section. Quase todos decoram que uma é 'estática' e a outra é 'dinâmica'. Poucos entendem que essa diferença define como um programa se comporta quando milhares de pessoas o executam simultaneamente em um IBM Z."

Existe um momento curioso na vida de todo desenvolvedor COBOL.

Logo nas primeiras aulas aparece alguém dizendo:

"Working-Storage é memória estática."

Logo depois vem outra frase:

"Local-Storage é memória dinâmica."

O aluno anota.

Decora.

Passa na prova.

Continua programando.

Anos depois ainda acredita que toda a história termina aí.

Mas não termina.

Na verdade, essa é apenas a primeira página de um assunto que influencia desempenho, escalabilidade, consumo de memória, concorrência, reentrância e até mesmo a disponibilidade dos maiores sistemas bancários do planeta.

Hoje vamos tomar um café e conversar sobre algo que acontece silenciosamente dentro do IBM Z toda vez que um programa COBOL começa a executar.

Vamos falar sobre memória.

Mas não qualquer memória.

Vamos falar da memória que ninguém vê.

Aquela que decide se um programa será elegante ou problemático.

Aquela que pode suportar dez usuários... ou cem mil.

---

O que realmente acontece quando um programa COBOL inicia?

Imagine que um programa COBOL seja um restaurante.

O código-fonte representa o projeto arquitetônico.

As instruções são as receitas.

Os parágrafos são os cozinheiros.

Mas falta algo essencial.

Onde ficam os ingredientes?

Eles precisam ser armazenados em algum lugar.

É exatamente esse o papel das áreas de dados.

Quando o programa é carregado, o sistema operacional reserva espaços de memória para armazenar todas as variáveis declaradas.

Essas áreas são cuidadosamente organizadas.

Algumas existirão durante toda a vida do programa.

Outras nascerão e morrerão constantemente.

É justamente aqui que entram a Working-Storage e a Local-Storage.

---

Working-Storage: a grande despensa do restaurante

Imagine a despensa principal de um restaurante.

Ela foi montada antes da abertura.

Os armários já estão organizados.

Os ingredientes estão separados.

Os utensílios permanecem sempre nos mesmos lugares.

Nada disso precisa ser montado toda vez que um cliente chega.

É exatamente essa a filosofia da Working-Storage.

WORKING-STORAGE SECTION.

01 WS-CLIENTE.
   05 WS-NOME        PIC X(40).
   05 WS-CONTA       PIC 9(10).

01 WS-SALDO          PIC S9(11)V99 COMP-3.

01 WS-CONTADOR       PIC 9(6).

Quando o programa é carregado pelo z/OS, essa área recebe memória.

A partir desse instante ela permanece disponível.

Não importa quantos PERFORM sejam executados.

Não importa quantos IF existam.

Não importa quantas SECTIONS sejam chamadas.

As variáveis continuam existindo.

O endereço de memória continua sendo o mesmo.

Isso torna o acesso extremamente rápido.

---

O verdadeiro significado de "estático"

Muitos iniciantes imaginam que "estático" significa "imutável".

Não.

Static não significa que o valor nunca muda.

Significa que o espaço de memória permanece o mesmo.

Observe:

MOVE 100 TO WS-TOTAL.

Depois:

ADD 50 TO WS-TOTAL.

Depois:

SUBTRACT 20 FROM WS-TOTAL.

O conteúdo mudou diversas vezes.

Mas o endereço da variável permaneceu exatamente igual.

É como uma gaveta.

Você pode trocar o que está dentro dela.

Mas continua sendo a mesma gaveta.

---

O custo invisível da criação de memória

Toda vez que um sistema precisa criar memória, ele realiza diversas operações internas.

Ele precisa:

• localizar espaço livre;

• reservar esse espaço;

• inicializar a região;

• atualizar tabelas internas;

• controlar proteção;

• posteriormente liberar aquela memória.

Tudo isso consome CPU.

A Working-Storage evita esse trabalho.

Ela nasce uma vez.

E permanece viva.

Por isso é extremamente eficiente para dados permanentes durante a execução.

---

Onde ela é usada?

Praticamente em todos os programas Batch.

Imagine um processamento de folha de pagamento.

Durante horas o programa percorre milhões de registros.

Ele precisa manter:

• total de salários;

• quantidade de funcionários;

• número do lote;

• estatísticas;

• indicadores;

• buffers de leitura;

• tabelas carregadas em memória.

Nenhum desses dados precisa ser recriado continuamente.

Logo, Working-Storage é perfeita.

---

Agora imagine outro cenário...

Você desenvolveu um programa chamado CALCULA-IMPOSTO.

Ele é chamado por:

• Internet Banking;

• Aplicativo Mobile;

• Caixa eletrônico;

• Central de Atendimento;

• PIX;

• TED;

• DOC;

• Sistema interno do banco.

Milhares de chamadas por segundo.

Todos executando exatamente o mesmo programa.

Agora surge uma pergunta interessante.

Como impedir que um cliente altere os dados do outro?

---

Bem-vindo ao mundo da Local-Storage

É aqui que entra a Local-Storage Section.

LOCAL-STORAGE SECTION.

01 LS-TOTAL-IMPOSTO PIC S9(9)V99.

Essa variável possui um comportamento completamente diferente.

Ela não existe durante toda a vida do programa.

Ela nasce.

É utilizada.

E desaparece.

Cada nova ativação do programa recebe uma nova cópia.

Não existe compartilhamento.

É como um bloco de anotações entregue individualmente para cada cliente que entra no restaurante.

Quando o cliente vai embora...

O bloco é descartado.

O próximo recebe outro completamente limpo.

---

A diferença parece pequena...

...mas muda tudo.

Imagine três clientes acessando simultaneamente um sistema bancário.

Cliente A:

Saldo:

R$ 5.000

Cliente B:

Saldo:

R$ 18.000

Cliente C:

Saldo:

R$ 730

Se todos utilizassem exatamente a mesma variável para armazenar o saldo temporário...

Teríamos um desastre.

Enquanto um cliente calcula juros...

Outro altera o saldo.

Enquanto outro faz um PIX...

A variável já contém informações diferentes.

Resultado?

Corrupção de memória.

Valores inconsistentes.

Falhas imprevisíveis.

Esse tipo de problema recebe até um nome em computação:

Race Condition.

---

O IBM Z foi construído para evitar exatamente isso

O mainframe nasceu para executar milhares de tarefas simultaneamente.

Ele não foi criado pensando em um único usuário.

Foi projetado para atender cidades inteiras.

Bancos.

Companhias aéreas.

Seguradoras.

Governos.

Empresas de cartão.

Operadoras de saúde.

Enquanto você lê este artigo, existem programas COBOL sendo executados milhares de vezes por segundo.

Muitas vezes o mesmo módulo está atendendo centenas de usuários ao mesmo tempo.

Como isso é possível?

Porque o código é compartilhado.

Mas os dados não.

---

Código compartilhado

Imagine um livro.

Mil pessoas podem ler exatamente o mesmo livro.

O livro não muda.

Agora imagine que todas escrevessem anotações na mesma página.

Seria um caos.

É exatamente essa diferença.

O código pode ser compartilhado.

Os dados precisam ser privados.

---

Reentrância: um conceito muito maior que Local-Storage

Aqui chegamos a uma palavra que todo programador COBOL deveria conhecer.

Reentrant.

Um programa reentrante pode ser executado simultaneamente por inúmeras tarefas.

Existe apenas uma cópia do código.

Mas cada execução possui sua própria área de dados.

Isso reduz consumo de memória.

Melhora desempenho.

Aumenta escalabilidade.

Permite milhares de transações concorrentes.

Em ambientes CICS, isso é praticamente obrigatório.

---

O compilador RENT

Quem já compilou programas Enterprise COBOL provavelmente encontrou a opção:

RENT

Muitos imaginam que ela apenas altera um parâmetro de compilação.

Na verdade, ela muda toda a filosofia de utilização da memória.

O compilador passa a gerar código preparado para múltiplas execuções concorrentes.

Isso exige disciplina.

Variáveis compartilhadas precisam ser evitadas.

Dados específicos da execução devem permanecer em áreas privadas.

É justamente aqui que Local-Storage ganha enorme importância.

---

Batch e CICS não vivem exatamente no mesmo mundo

Essa é outra confusão comum.

No processamento Batch, normalmente existe apenas uma instância daquele programa executando.

Logo, Working-Storage atende perfeitamente.

Já no CICS...

Milhares de usuários podem chamar o mesmo programa.

Ao mesmo tempo.

Nesse ambiente, utilizar inadequadamente áreas compartilhadas pode gerar problemas extremamente difíceis de reproduzir.

Aquele famoso erro que "acontece uma vez por semana" muitas vezes nasce justamente da utilização incorreta da memória.

---

Um exemplo simples

Imagine este contador.

WORKING-STORAGE SECTION.

01 WS-CONTADOR PIC 9(5).

Cada chamada faz:

ADD 1 TO WS-CONTADOR.

Em Batch isso pode funcionar exatamente como esperado.

Agora imagine centenas de transações simultâneas.

Quem garante qual usuário alterou o contador primeiro?

Quem garante que nenhuma atualização será perdida?

É exatamente por isso que programas transacionais precisam ser cuidadosamente projetados.

---

Local-Storage também tem custo

É tentador imaginar que basta substituir tudo por Local-Storage.

Não é tão simples.

Toda criação de memória possui custo.

A cada ativação do programa, o sistema precisa:

• reservar memória;

• inicializar valores;

• preparar a área;

• liberar recursos posteriormente.

Esse trabalho é pequeno.

Mas quando falamos em milhões de chamadas por dia...

Pequenos custos tornam-se grandes números.

É por isso que engenharia de software nunca trabalha com respostas absolutas.

Tudo depende do contexto.

---

E o VALUE?

Outro detalhe frequentemente ignorado.

Observe:

01 WS-TOTAL PIC 9 VALUE 5.

O valor inicial é definido quando a área é inicializada.

Depois disso, o programa pode alterá-lo quantas vezes desejar.

Já na Local-Storage:

01 LS-TOTAL PIC 9 VALUE 5.

Cada nova ativação recebe novamente o valor cinco.

Parece um detalhe.

Mas em subprogramas reutilizados milhares de vezes isso muda completamente o comportamento da aplicação.

---

CALL e Subprogramas

Imagine um módulo de cálculo.

CALCULA-JUROS

Ele é chamado por dezenas de sistemas.

Se utilizar apenas Working-Storage para dados temporários, o comportamento dependerá da forma como o ambiente gerencia essa área e do modelo de execução adotado.

Se utilizar Local-Storage para as variáveis temporárias, cada ativação começa com uma área própria e limpa, reduzindo o risco de interferência entre execuções.

Por isso, muitos subprogramas modernos utilizam Local-Storage para cálculos intermediários e Working-Storage apenas para estruturas que realmente precisam existir durante toda a ativação do programa.

---

A analogia do hotel

Imagine um hotel.

A Working-Storage é o prédio.

Sempre está lá.

As paredes continuam no mesmo lugar.

Os corredores não mudam.

Agora pense nos quartos.

Cada hóspede recebe um quarto limpo.

Quando vai embora...

Outro hóspede ocupa o mesmo espaço.

Não leva a bagagem do anterior.

A Local-Storage funciona exatamente assim.

Cada execução recebe seu próprio "quarto".

---

E quando falamos de desempenho?

Uma das maiores virtudes do IBM Z sempre foi a eficiência.

O sistema operacional conhece profundamente como seus programas utilizam memória.

O compilador Enterprise COBOL também foi otimizado durante décadas para produzir código extremamente eficiente.

Por isso, a escolha entre Working-Storage e Local-Storage não deve ser feita por hábito, mas por necessidade.

Variáveis permanentes?

Working-Storage.

Dados temporários exclusivos de uma ativação?

Local-Storage.

Subprogramas reentrantes?

Planejamento cuidadoso das áreas de dados.

---

O erro mais comum dos iniciantes

Existe uma pergunta que aparece frequentemente em cursos.

"Professor, então devo usar Local-Storage em tudo?"

A resposta é simples.

Não.

Assim como não existe um único tipo de dataset para todas as situações, não existe uma única área de memória adequada para todos os cenários.

A escolha depende do ambiente de execução, do tipo de aplicação, da necessidade de concorrência, do ciclo de vida dos dados e dos requisitos de desempenho.

Conhecer essas diferenças é o que separa quem apenas escreve código de quem projeta soluções robustas para ambientes corporativos.

---

O verdadeiro aprendizado

Aprender COBOL não é decorar sintaxes.

Não é memorizar comandos.

Não é saber onde fica a vírgula do PIC.

Programar COBOL é entender como o sistema operacional conversa com o compilador.

Como o compilador organiza a memória.

Como o programa compartilha recursos.

Como milhares de usuários podem executar exatamente o mesmo módulo sem que um interfira na execução do outro.

Quando compreendemos a diferença entre Working-Storage e Local-Storage, deixamos de enxergar apenas duas seções da Data Division.

Passamos a enxergar a arquitetura invisível que sustenta aplicações responsáveis por movimentar trilhões de dólares diariamente.

Na próxima vez que declarar uma variável em seu programa COBOL, lembre-se: você não está apenas escolhendo onde armazenar um número ou um texto. Está tomando uma decisão de arquitetura que pode impactar desempenho, escalabilidade, reentrância e confiabilidade de todo o sistema.

E é justamente esse tipo de detalhe, aparentemente simples, que transforma um programador COBOL em um verdadeiro engenheiro de software para IBM Z.

Porque, no fim das contas, a excelência no mainframe não nasce das grandes decisões. Ela é construída por milhares de pequenas escolhas corretas, feitas todos os dias, muitas delas invisíveis para quem apenas olha o código.

 

🎺 A Música do Cambuí

Por Vagner Bellacosa Mainframe

Em meio ao medo, havia som.
Não o som das panelas — que soava como protesto —
mas o som da beleza tentando sobreviver.

No Cambuí, em Campinas, músicos anônimos começaram a sair às ruas, mantendo o distanciamento,
andando devagar pelas calçadas vazias, tocando saxofones, violinos, flautas e tambores.
As notas ecoavam entre os prédios, subindo pelas varandas,
encontrando rostos cansados e olhos marejados.

Era um gesto simples — e talvez por isso, tão comovente.
As pessoas, isoladas em seus apartamentos, aplaudiam das janelas,
outras choravam, outras acompanhavam batendo palmas no ritmo.
Por um instante, a rua voltou a ter alma.

O vírus estava por toda parte — invisível e letal.
Os telejornais mostravam hospitais de campanha, leitos improvisados,
médicos exaustos, corpos enrolados em lençóis,
e números que pareciam não ter fim.
Era como assistir a uma guerra sem som,
até que esses músicos decidiram devolver o som ao mundo.

Naquele tempo, a música era uma prece.
E o Cambuí virou uma pequena catedral a céu aberto,
onde cada nota dizia o que as palavras não podiam:
“Estamos com medo, mas ainda estamos vivos.”

A cena era surreal: ruas vazias, janelas iluminadas,
o som flutuando sobre o asfalto molhado,
e o coração, por alguns minutos, esquecendo as estatísticas.
Talvez fosse isso o que Deus esperava de nós —
não heroísmo, nem fé cega,
mas a capacidade de ainda se comover.

Lembro-me da história que minha bisavó Isabel contava —
a gripe espanhola, os corpos enrolados em lençóis,
o homem da carrocinha puxada a burro, recolhendo os mortos pelas ruas.
Cem anos depois, o mesmo medo, a mesma dor, o mesmo silêncio.
Mudaram as roupas, os carros, os prédios —
mas o susto diante da morte continua igual.

E no entanto, havia música.
E enquanto houvesse música,
a humanidade ainda tinha chance.

Technical Debt Rules : Quando um Programador COBOL Descobriu que Cada Atalho Criava um Agente Smith Dentro do Sistema

 

Bellacosa Mainframe e as technical debt rules

☕ Um Café no Bellacosa Mainframe

Technical Debt Rules sem Mistérios

Quando um Programador COBOL Descobriu que Cada Atalho Criava um Agente Smith Dentro do Sistema

"Infelizmente, ninguém pode explicar o que é a Dívida Técnica. Você precisa vê-la por si mesmo." — inspirado no universo de Matrix

---

Bem-vindo à Matrix do Desenvolvimento

Imagine que você acorda em uma sala escura.

Na sua frente existe um monitor verde.

Linhas de caracteres descem como chuva.

Um homem de óculos escuros aproxima-se.

Não é Morpheus.

É o Analista de Sistemas mais antigo da empresa.

Ele coloca duas fitas magnéticas sobre a mesa.

Uma vermelha.

Outra azul.

— A azul compila hoje.

— A vermelha exige refatoração, testes, documentação e arquitetura.

Você pergunta:

— Qual delas devo escolher?

Ele sorri.

— A azul entrega o projeto este mês.

— A vermelha salva os próximos dez anos.

Naquele instante você entende que toda equipe de desenvolvimento vive diariamente essa escolha.

Esse é o universo da Technical Debt, ou Dívida Técnica, um dos conceitos mais importantes — e mais mal compreendidos — da Engenharia de Software.

Para quem trabalha com COBOL, CICS, Db2, JCL e sistemas legados, entender a Dívida Técnica é quase tão importante quanto saber interpretar um ABEND. Ela explica por que alguns sistemas envelhecem com dignidade enquanto outros se tornam um labirinto impossível de manter.

---

O que é Technical Debt?

Technical Debt é o custo futuro provocado por decisões técnicas tomadas para ganhar velocidade no presente.

Em outras palavras:

É quando você economiza tempo hoje emprestando tempo do seu próprio futuro.

Assim como um empréstimo bancário, a dívida técnica pode ser útil quando administrada conscientemente.

O problema não é contrair uma dívida.

O problema é esquecer que ela existe.

---

A origem do termo

O termo Technical Debt foi criado em 1992 por Ward Cunningham, um dos autores do Manifesto Ágil e criador do primeiro Wiki da história.

Ward percebeu que muitos gestores entendiam dinheiro, juros e empréstimos, mas tinham dificuldade para compreender problemas de arquitetura de software.

Então fez uma analogia brilhante.

Ele disse:

"Entregar um software antes de terminar sua arquitetura é como fazer um empréstimo. Pode ser uma boa decisão, desde que você pague rapidamente."

O problema aparece quando os juros começam.

E em software...

...os juros aparecem em forma de:

• bugs

• retrabalho

• lentidão

• dificuldades para alterar regras

• aumento do tempo de testes

• aumento de incidentes

---

Matrix explica melhor que muitos livros

Imagine que cada linha de código seja parte da Matrix.

Quando tudo é desenvolvido corretamente...

a simulação permanece estável.

Mas sempre existe alguém dizendo:

"Depois a gente arruma."

Esse "depois" nunca chega.

Cada pequeno atalho cria pequenas distorções.

No começo parecem insignificantes.

Depois surgem pequenos defeitos.

Mais tarde aparecem exceções.

Finalmente...

a Matrix inteira começa a produzir Agentes Smith.

---

Quem são os Agentes Smith?

No mundo do software, os Agentes Smith representam problemas que surgem continuamente.

Cada vez que um desenvolvedor resolve um bug rapidamente sem corrigir sua causa...

nasce um novo Smith.

Cada IF duplicado...

mais um Smith.

Cada variável mal nomeada...

outro Smith.

Cada programa COBOL de cinquenta mil linhas...

centenas deles.

Eles continuam se multiplicando até dominar todo o sistema.

---

Um exemplo COBOL

Imagine este código:

IF TIPO = "A"
    MOVE 15 TO DESCONTO
END-IF

Alguns meses depois.

Nova regra.

IF TIPO = "A"
    MOVE 20 TO DESCONTO
END-IF

Mais tarde.

Outro programador.

IF CLIENTE-PREMIUM
    MOVE 25 TO DESCONTO
END-IF

Depois.

Outro módulo.

Mesmo código.

Depois outro.

E outro.

Agora existem quinze versões diferentes da mesma regra.

Toda alteração exige procurar manualmente.

Esse é um clássico exemplo de dívida técnica.

---

O que gera Technical Debt?

Pressão por prazo

"Entrega sexta."

Mesmo sabendo que deveria levar três semanas.

---

Falta de testes

"Depois escrevemos."

Nunca escrevem.

---

Documentação inexistente

"Todo mundo entende."

Dois anos depois ninguém entende.

---

Copiar código

CTRL+C

CTRL+V

CTRL+C

CTRL+V

Assim nasce o caos.

---

Arquitetura improvisada

Funciona.

Mas ninguém sabe explicar.

---

Falta de revisão

Sem Code Review...

os problemas entram em produção.

---

Falta de treinamento

Programadores repetem erros porque nunca aprenderam alternativas melhores.

---

A dívida nem sempre é ruim

Essa é uma curiosidade interessante.

Nem toda dívida técnica é um erro.

Imagine um banco.

Existe uma exigência legal.

Prazo:

48 horas.

A equipe decide criar uma solução provisória.

Entrega.

Banco evita multas.

Depois reserva tempo para refatorar.

Excelente decisão.

Foi uma dívida consciente.

---

Dívida consciente x dívida inconsciente

Dívida consciente

"Sabemos que esse código está temporário."

Existe plano.

Existe prazo.

Existe orçamento.

---

Dívida inconsciente

"Nunca percebemos que fizemos errado."

Muito mais perigosa.

---

Os juros da dívida

Todo empréstimo possui juros.

Software também.

Os juros aparecem como:

Mais tempo para manutenção

Uma alteração simples leva dias.

---

Bugs recorrentes

Conserta um.

Quebra outro.

---

Medo

"Não mexe."

Frase clássica do legado.

---

Performance

Cada remendo adiciona processamento.

No mainframe isso significa:

• CPU

• MIPS

• consumo

• custo

---

Novos profissionais demoram meses

Porque entender ficou difícil.

---

Como a dívida cresce?

Imagine um cartão de crédito.

Primeiro mês:

100 reais.

Segundo mês:

Terceiro:

Depois:

Depois:

Software faz exatamente isso.

Cada nova funcionalidade construída sobre código ruim aumenta exponencialmente a complexidade.

---

O Mainframe sofre muito?

Curiosamente...

sim.

E não.

Mainframes normalmente possuem código extremamente robusto.

Mas muitos sistemas existem há quarenta anos.

Durante quatro décadas...

centenas de programadores passaram por eles.

Cada geração deixou pequenas modificações.

O resultado pode ser:

• GOTO esquecidos

• IFs duplicados

• COPYBOOKS redundantes

• programas gigantescos

• tabelas obsoletas

• JCLs nunca revisados

---

Um exemplo realista

Imagine um programa COBOL chamado:

PGMFIN01

1988

2.300 linhas.

1992

3.800 linhas.

1998

6.500 linhas.

2007

11.000 linhas.

2016

19.000 linhas.

2026

41.000 linhas.

Ninguém teve coragem de dividir.

Cada manutenção ficou mais cara.

A dívida cresceu silenciosamente.

---

O Oráculo explica

No universo Matrix, o Oráculo nunca entrega respostas prontas.

Ela oferece entendimento.

Na Engenharia de Software acontece igual.

A dívida técnica raramente aparece em relatórios.

Ela aparece nos sintomas.

Equipe cansada.

Prazo aumentando.

Mudanças simples demorando semanas.

Clientes reclamando.

ABENDs aparecendo após pequenas alterações.

Esses são os sinais.

---

Como reduzir a dívida?

Refatoração

Melhorar código sem alterar comportamento.

É a principal arma.

---

Testes automatizados

Permitem mudar com segurança.

---

Revisão de código

Dois olhos veem mais que um.

---

Arquitetura

Planejamento evita improvisos.

---

Documentação viva

Nunca deixe conhecimento apenas na memória.

---

Pair Programming

Conhecimento compartilhado.

---

Mentoria

Programadores experientes aceleram iniciantes.

---

Limpeza contínua

Nunca espere uma grande reescrita.

Melhore um pouco todos os dias.

---

A Regra do Escoteiro

Robert C. Martin popularizou uma ideia simples:

Deixe o código um pouco melhor do que encontrou.

Imagine milhares de desenvolvedores fazendo isso durante anos.

A dívida diminui naturalmente.

---

Atenção!

Existe um erro muito comum.

Confundir:

Refatoração

com

Reescrita.

São coisas completamente diferentes.

Refatorar melhora.

Reescrever substitui.

Nem sempre reescrever é inteligente.

Muitos projetos falharam tentando "começar do zero".

---

O perigo da Grande Reescrita

Na Matrix Reloaded, Neo descobre que destruir tudo não resolve.

Em software acontece igual.

Jogar fora um sistema COBOL de quarenta anos pode significar perder décadas de conhecimento de negócio.

O ideal é evoluir gradualmente.

---

Ferramentas que ajudam

Hoje existem excelentes ferramentas.

• IBM ADDI

• IBM Application Discovery

• SonarQube

• IBM COBOL Check

• IBM Z Open Editor

• IBM Developer for z/OS

• GitHub Copilot

• ChatGPT

• Claude

• ZUnit

Elas ajudam a identificar:

• duplicações

• complexidade

• dependências

• código morto

• riscos

---

Sinais de alerta

Você deve investigar dívida técnica quando ouvir frases como:

"Não sabemos por que funciona."

"Não mexe nesse módulo."

"Compila assim mesmo."

"Só o João entende."

"Depois documentamos."

"Tem um GOTO aí... mas deixa."

"É gambiarra temporária."

Seis meses depois...

continua igual.

---

O papel do Programador COBOL Padawan

Um Padawan costuma pensar:

"Meu trabalho é escrever código."

Na verdade, não.

Seu trabalho é entregar soluções sustentáveis.

Sempre pergunte:

• Isso poderá ser entendido daqui cinco anos?

• Outro programador conseguirá manter?

• Existe teste?

• Existe documentação?

• Existe duplicação?

• Essa regra deveria estar em um COPYBOOK?

• Esse programa precisa mesmo crescer mais mil linhas?

Essas perguntas evitam que você alimente a Matrix com novos Agentes Smith.

---

Curiosidades sobre a Dívida Técnica

• Existem empresas que dedicam 20% do tempo de desenvolvimento apenas para pagar dívida técnica.

• Grandes bancos mantêm backlogs exclusivos de refatoração, separados das novas funcionalidades.

• Algumas organizações medem a dívida técnica com ferramentas que estimam quantos dias de trabalho seriam necessários para corrigir todos os problemas encontrados.

• Em projetos críticos, reduzir dívida técnica pode gerar economia significativa em horas de manutenção, consumo de CPU, incidentes e retrabalho.

---

Outros "parentes" da Dívida Técnica

Ela costuma caminhar ao lado de diversos conceitos conhecidos:

• Code Smell – sinais de que algo pode estar mal projetado.

• Big Ball of Mud – sistema sem arquitetura definida.

• Spaghetti Code – código confuso e altamente acoplado.

• God Object – um único módulo faz tudo.

• Bus Factor – conhecimento concentrado em poucas pessoas.

• Shotgun Surgery – uma pequena alteração exige modificar dezenas de arquivos.

• Lava Flow – código antigo que ninguém remove por medo.

Todos esses conceitos frequentemente aparecem juntos.

---

A Grande Escolha: Pílula Azul ou Pílula Vermelha?

No final de Matrix, Neo percebe que conhecer a verdade traz responsabilidade.

Na Engenharia de Software acontece exatamente o mesmo.

Você pode escolher a pílula azul:

• copiar código;

• ignorar testes;

• adiar documentação;

• aceitar "gambiarras permanentes";

• acreditar que "funcionando está bom".

Ou pode escolher a pílula vermelha:

• compreender a arquitetura;

• investir em refatoração;

• escrever código legível;

• compartilhar conhecimento;

• documentar regras de negócio;

• pensar no próximo programador que abrirá aquele programa COBOL daqui a dez anos.

A primeira opção parece mais rápida, mas cobra juros crescentes. A segunda exige disciplina, porém constrói sistemas resilientes que atravessam décadas — exatamente como os grandes sistemas IBM Z que sustentam bancos, seguradoras, governos e companhias aéreas ao redor do mundo.

No universo Bellacosa Mainframe, a maior lição é clara: o inimigo não é o legado; é o legado abandonado. Sistemas COBOL envelhecem muito bem quando recebem manutenção consciente, arquitetura sólida e equipes comprometidas em reduzir continuamente a dívida técnica. Assim como Neo precisou aprender a enxergar além do código verde da Matrix, o Programador COBOL Padawan precisa aprender a enxergar além da próxima entrega e pensar no impacto que cada linha escrita hoje terá no futuro da organização.

Porque, no fim, toda dívida será paga. A única dúvida é quem pagará a conta: você hoje ou toda a equipe amanhã?

Yashahime: Princess Half-Demon – 2ª Temporada : Quando um Programador COBOL Descobre que um Projeto de Modernização Só Termina Quando a Nova Equipe Consegue Resolver um ABEND Sem Telefonar para o Programador

 

Bellacosa Mainframe e a segunda temporada de yashahime princess half-demon

☕ Um Café no Bellacosa Mainframe

Yashahime: Princess Half-Demon – 2ª Temporada (半妖の夜叉姫 弐の章) sem Mistérios

Quando um Programador COBOL Descobre que um Projeto de Modernização Só Termina Quando a Nova Equipe Consegue Resolver um ABEND Sem Telefonar para o Programador que se Aposentou Há Dez Anos

"O primeiro deploy coloca o sistema em produção. O segundo garante que ele sobreviva pelas próximas décadas. A segunda temporada de Yashahime é exatamente essa fase da modernização."

---

Introdução

Quando Yashahime estreou em 2020, a recepção foi bastante dividida.

Os fãs ficaram felizes por reencontrar o universo de Inuyasha, mas muitos sentiram falta de respostas importantes.

Quem realmente era Kirinmaru?

Por que Sesshomaru parecia agir de maneira tão fria?

Onde estavam Inuyasha e Kagome?

O que realmente aconteceu com Zero?

A segunda temporada, chamada oficialmente Yashahime: Princess Half-Demon – The Second Act, foi produzida justamente para responder essas perguntas.

Ao contrário da primeira temporada, que construía mistérios, esta trabalha principalmente com resoluções.

É a fase em que todas as peças começam finalmente a se encaixar.

Para quem trabalha com tecnologia, é semelhante à etapa de um projeto em que toda a documentação é revisada, os módulos antigos são compreendidos e o conhecimento passa definitivamente para a nova equipe.

---

Dados Técnicos

Título Original

半妖の夜叉姫 弐の章

Han'yō no Yashahime: Ni no Shō

Tradução:

Princesas Meio-Yokai – Segundo Capítulo

Título internacional:

Yashahime: Princess Half-Demon – The Second Act

---

Universo Original

Criado por

Rumiko Takahashi

Participação:

• supervisão geral

• design dos personagens

• aprovação visual

A história continua sendo um roteiro original da equipe do anime.

---

Estúdio

Sunrise

(atualmente Bandai Namco Film Works)

---

Diretor

Teruo Sato

---

Roteiro

Katsuyuki Sumisawa

O mesmo roteirista responsável por grande parte da adaptação de Inuyasha.

---

Exibição

02 de outubro de 2021

até

26 de março de 2022

---

Episódios

24

---

Total da franquia

Primeira temporada

24 episódios

Segunda temporada

24 episódios

Total

48 episódios

---

Gênero

• Fantasia

• Aventura

• Ação

• Drama

• Romance (leve)

• Sobrenatural

• Mitologia Japonesa

---

Classificação

14 anos

Contém:

• batalhas

• violência moderada

• sangue leve

• temas familiares

• conflitos psicológicos

---

Sinopse

Após descobrir parte da verdade sobre suas origens...

Towa...

Setsuna...

e Moroha...

continuam sua jornada.

Agora precisam enfrentar definitivamente:

• Kirinmaru

• Zero

• o destino da Árvore das Eras

• as consequências das decisões de Sesshomaru

Enquanto isso...

os antigos heróis finalmente retornam à história.

---

Resumo

Esta temporada encerra praticamente todos os grandes arcos iniciados desde a primeira temporada.

É nela que descobrimos:

• o verdadeiro plano de Sesshomaru

• os motivos de Kirinmaru

• o destino de Zero

• o reencontro das famílias

• o futuro da nova geração

---

A História

Grande parte da temporada gira em torno da antiga profecia.

Segundo ela...

um hanyō seria capaz de destruir Kirinmaru.

Esse medo faz Kirinmaru tomar diversas decisões equivocadas.

Enquanto isso...

Sesshomaru parece agir de forma fria.

Mas aos poucos o público percebe que suas atitudes sempre tiveram um único objetivo:

proteger suas filhas.

A narrativa culmina em uma série de confrontos que unem definitivamente a geração clássica de Inuyasha com a nova geração representada por Towa, Setsuna e Moroha.

---

Os Personagens

Towa

É quem mais evolui.

Aprende liderança.

Controle emocional.

Responsabilidade.

Deixa definitivamente de ser apenas uma estudante do Japão moderno.

---

Setsuna

Recupera parte de sua memória.

Seu desenvolvimento emocional é um dos mais fortes da temporada.

---

Moroha

Continua sendo a personagem mais carismática.

Mistura humor.

Coragem.

Espontaneidade.

Herda claramente características de Inuyasha e Kagome.

---

Sesshomaru

Talvez o personagem que mais ganha profundidade.

O espectador finalmente entende que seu aparente distanciamento era uma forma de proteger a família.

Sua postura permanece reservada, mas suas motivações tornam-se claras.

---

Kirinmaru

Muito mais complexo do que aparentava.

Seu verdadeiro inimigo nunca foi Towa.

Foi seu medo do futuro.

---

Zero

Recebe um encerramento digno.

Representa:

ciúme

amor impossível

ressentimento

apego

---

Inuyasha

Retorna à história.

Mesmo sem dominar a narrativa.

Sua presença simboliza continuidade.

---

Kagome

Volta como elo entre duas gerações.

Continua sendo uma das personagens mais equilibradas da franquia.

---

O Que Tem de Diferente?

Ao contrário da primeira temporada, que se concentrava em construir mistérios, The Second Act dedica-se a resolvê-los.

Há menos episódios de introdução e mais foco nas relações familiares, nos confrontos finais e na passagem do legado para as novas protagonistas.

Também aumenta significativamente a participação de Inuyasha, Kagome e Sesshomaru, aproximando a continuação do espírito da série clássica.

---

Temáticas

Família

Pais fazem escolhas difíceis.

---

Herança

Nem toda herança é material.

---

Memória

Somos também aquilo que lembramos.

---

Destino

Profecias podem ser quebradas.

---

Amor

Proteção também é amor.

---

Tempo

O passado nunca desaparece.

---

Aventuras

As heroínas enfrentam os servos de Kirinmaru, exploram os mistérios da Árvore das Eras, recuperam lembranças perdidas e participam de batalhas que definem o destino do Japão Feudal.

Os reencontros entre pais e filhos acrescentam uma carga emocional que diferencia essa temporada da anterior.

---

Mensagens Ocultas

A Nova Geração Deve Superar a Antiga

Não apenas imitá-la.

---

Pais Também Sentem Medo

Mesmo quando parecem invencíveis.

---

Conhecimento Deve Ser Compartilhado

Senão desaparece.

---

O Futuro Não Deve Ser Temido

Deve ser construído.

---

O Amor Também Exige Sacrifícios

Nem toda proteção é compreendida imediatamente.

---

Impacto Cultural

A segunda temporada foi melhor recebida do que a primeira por responder perguntas aguardadas desde o anúncio da continuação.

Os fãs destacaram:

• maior desenvolvimento de Sesshomaru;

• presença ampliada de Inuyasha e Kagome;

• confrontos finais mais emocionantes;

• encerramento consistente dos principais arcos.

Ainda assim, parte do público considerou que alguns antagonistas poderiam ter sido desenvolvidos por mais tempo.

---

Censura

Assim como a primeira temporada, The Second Act sofreu poucas alterações fora do Japão.

As mudanças limitaram-se principalmente à classificação indicativa e à suavização de algumas cenas de violência em transmissões televisivas.

---

Mangás

O mangá ilustrado por Takashi Shiina continua expandindo a história.

Em vários momentos:

• altera acontecimentos;

• aprofunda personagens;

• apresenta explicações mais detalhadas do que a versão animada.

Muitos fãs recomendam acompanhar tanto o anime quanto o mangá para uma experiência mais completa.

---

Light Novels

Até o momento, não existe uma light novel oficial que continue os acontecimentos após a segunda temporada.

---

Games

As personagens de Yashahime participaram de:

• eventos comemorativos;

• jogos mobile japoneses;

• colaborações especiais da Bandai Namco.

Não foi lançado um RPG exclusivo dedicado à segunda temporada.

---

Curiosidades

• Kaoru Wada reutilizou temas clássicos de Inuyasha durante momentos decisivos, reforçando a ligação emocional entre as duas gerações.

• O desenvolvimento de Sesshomaru nesta temporada ajudou a consolidá-lo ainda mais como um dos personagens mais populares da franquia.

• O mangá de Takashi Shiina recebeu elogios por aprofundar passagens que o anime resolveu de forma mais rápida.

---

Easter Eggs

• A Árvore das Eras continua simbolizando a conexão entre passado, presente e futuro.

• As técnicas herdadas por Towa, Setsuna e Moroha refletem a influência direta de seus pais.

• Diversos enquadramentos e referências visuais homenageiam cenas clássicas de Inuyasha e The Final Act.

---

Avaliação Bellacosa Mainframe

Aspecto	Nota
História	⭐⭐⭐⭐⭐ (5/5)
Desenvolvimento dos Personagens	⭐⭐⭐⭐⭐ (5/5)
Emoção	⭐⭐⭐⭐⭐ (5/5)
Ação	⭐⭐⭐⭐☆ (4,5/5)
Trilha Sonora	⭐⭐⭐⭐⭐ (5/5)
Encerramento	⭐⭐⭐⭐☆ (4,5/5)
Reassistir	⭐⭐⭐⭐⭐ (5/5)

Nota Final: 9,4/10

A segunda temporada consegue fortalecer a proposta de Yashahime, entregar respostas aguardadas pelos fãs e consolidar a nova geração sem apagar o legado de Inuyasha.

---

☕ Bellacosa Mainframe

Imagine um projeto de transformação digital em um grande ambiente IBM Z.

Na primeira fase, a equipe cria pipelines de CI/CD, automatiza deploys, integra APIs e moderniza aplicações.

Mas isso não basta.

O verdadeiro sucesso chega apenas quando a nova equipe consegue operar todo o ambiente sem depender do especialista que escreveu o sistema há trinta anos.

Towa representa a desenvolvedora que domina tanto GitOps quanto COBOL.

Setsuna simboliza a analista que recupera a documentação perdida e transforma experiência em conhecimento acessível.

Moroha é a engenheira criativa que conecta tradição e inovação para resolver problemas inesperados.

Sesshomaru assume o papel do arquiteto veterano que observa de longe. Ele intervém apenas quando necessário, permitindo que a nova geração conquiste autonomia.

No fim, Yashahime: The Second Act ensina uma das maiores lições da engenharia de software: modernizar não é apenas atualizar tecnologias. É garantir que o conhecimento sobreviva às pessoas, que a arquitetura seja compreendida pelas novas gerações e que o sistema continue evoluindo muito depois de seus criadores deixarem o projeto.