Bellacosa Mainframe apresente IBM Mainframe Quiesce

🔷 QUIESCE no DB2: Congelando Tabelas com Segurança

No DB2 para IBM z/OS, QUIESCE é uma operação usada para garantir consistência de dados durante operações administrativas, especialmente quando você precisa fazer backup, reorganização ou manutenção de tabelas sem corromper os dados.

---

🕰️ Origem e Contexto

• Em ambientes mainframe, tabelas DB2 são acessadas 24/7, com milhares de transações simultâneas.

• Antigamente, para garantir integridade, os DBAs precisavam parar o sistema inteiro para fazer backups ou reorganizações.

• A IBM introduziu o QUIESCE para “congelar” temporariamente uma tabela ou partição, permitindo:

  • Manutenção de tabelas

  • Criação de backups consistentes

  • Redução do impacto nas transações online

---

⚙️ O que o QUIESCE faz?

Quando você executa um QUIESCE TABLE, o DB2:

1. Impede alterações na tabela

   • Nenhum INSERT, UPDATE ou DELETE é permitido.

2. Permite leitura

   • Transações de SELECT ainda podem ser executadas normalmente (dependendo da configuração).

3. Cria um ponto de consistência

   • Ideal para backup ou reorganização.

Pense no QUIESCE como uma pausa temporária e controlada na tabela, sem desligar o banco ou impactar outras tabelas.

---

🔹 Sintaxe básica

-- Congela a tabela para manutenção
QUIESCE TABLE schema.tabela;

• schema.tabela → tabela que você quer “congelar”

• DB2 mantém o estado consistente até que você libere a tabela.

Liberando a tabela:

QUIESCE TABLE schema.tabela RELEASE;

• Permite que transações de escrita voltem ao normal.

---

💡 Dicas e Boas Práticas

1. Use somente quando necessário

   • Congelar muitas tabelas por muito tempo = impacto em aplicações.

2. Combine com backups offline

   • QUIESCE + COPY OUT = backup consistente sem travar o banco inteiro.

3. Evite longos períodos de quiesce

   • Transações concorrentes ficam bloqueadas, podendo causar timeout ou deadlocks.

4. Verifique o status

SELECT * FROM SYSIBM.SYSTABLES
WHERE NAME = 'TABELA' AND CREATOR = 'SCHEMA';

• O estado QUIESCED indica que a tabela está congelada.

---

🔍 Curiosidades / Easter Eggs Bellacosa

• O comando QUIESCE só existe no DB2 para z/OS. Em DB2 LUW (Linux/Unix/Windows), a abordagem é diferente (LOCK + BACKUP).

• Internamente, DB2 usa locks especiais e pontos de consistência para garantir que mesmo transações longas não corrompam o backup.

• Alguns DBAs chamam o QUIESCE de “pause mágico”, porque a tabela parece congelada, mas outras operações continuam normalmente.

---

⚡ Impacto na Performance

• Transações de escrita ficam suspensas, então:

  • Muitas sessões concorrentes → podem acumular espera

  • Bancos com alto volume de updates → planejar QUIESCE fora do horário de pico

• Transações de leitura não são bloqueadas (depende do tipo de lock).

• É mais leve que DB2 LOCK TABLE ou downtime total.

---

🔑 Resumo Bellacosa

Conceito	Detalhe
O que é	Congela temporariamente uma tabela para manutenção/backup
Sintaxe	QUIESCE TABLE schema.tabela; e RELEASE
Permite SELECT?	Sim (dependendo do lock)
Permite INSERT/UPDATE/DELETE?	Não durante o quiesce
Quando usar	Backup consistente, reorganização, manutenção de dados
Impacto	Leve se curto; bloqueia transações de escrita

---

💡 Easter Egg:

Se você fizer QUIESCE de uma tabela grande, é quase como colocar a tabela em “hibernação”: DB2 mantém tudo consistente internamente, e você nem sente nada até liberar.

 

 

Bellacosa Mainframe explica como funciona uma query no Db2

☕ DB2 no IBM Mainframe: o que realmente acontece quando você executa um SQL

---

🧠 Introdução – “É só um SELECT”… será mesmo?

Para quem está começando, parece simples:

SELECT * FROM CONTA WHERE SALDO > 1000;

Mas no IBM Mainframe, esse comando aciona uma cadeia de decisões complexas, refinadas por décadas de engenharia.
Antes de qualquer dado ser lido, o DB2 passa por um verdadeiro ritual técnico — silencioso, preciso e implacável.

Hoje vamos abrir a caixa-preta e entender, passo a passo, o que o DB2 faz quando recebe um SQL:

1. Parse da query e validação de sintaxe

2. Bind de tabelas e colunas

3. Criação do executável

4. Cálculo do plano de execução

5. Execução do plano

Tudo isso antes do primeiro byte sair do disco.

---

🧩 Passo 1 – Parse da query: o DB2 vira professor de português

Parse the query and check for proper syntax

Neste primeiro momento, o DB2:

• Analisa a sintaxe SQL

• Verifica comandos, cláusulas e ordem

• Garante que a query está gramaticalmente correta

Exemplo de erro clássico:

SELEC * FROM CLIENTE;

⛔ Resultado: erro imediato.
O DB2 não tenta adivinhar sua intenção.

☕ Comentário Bellacosa
Mainframe não é Google.
Se escreveu errado, aprende rápido — na marra.

---

🧩 Passo 2 – Bind lógico: tabelas e colunas entram em cena

Bind the tables and columns

Aqui o DB2 pergunta:

• Essa tabela existe?

• Esse schema está correto?

• Essa coluna pertence a essa tabela?

• Você tem permissão para isso?

Exemplo:

SELECT CPF FROM ELJEFE.CLIENTE;

Se:

• Schema errado

• Coluna inexistente

• Falta de autorização RACF

⛔ Falha antes da execução.

🧠 Curiosidade Bellacosa
Grande parte dos erros “objeto não encontrado” não é objeto inexistente —
é SQLID e schema mal resolvidos.

---

🧩 Passo 3 – Criar o executável: SQL vira código de verdade

Create an executable and hand it to the optimizer

Aqui acontece a mágica que muitos ignoram.

No DB2 z/OS:

• SQL não é interpretado a cada execução

• Ele é transformado em um executável

• Esse executável é armazenado em um PACKAGE

💡 Em programas COBOL:

• O BIND cria o package

• O package faz parte de um PLAN

• O programa executa o PLAN

☕ Comentário El Jefe
No mainframe, SQL não é script descartável.
É artefato compilado, tratado com o mesmo respeito que código fonte.

---

🧩 Passo 4 – O Otimizador entra em ação

Calculate the optimal execution plan

Agora o DB2 pensa — muito.

O otimizador avalia:

• Índices disponíveis

• Estatísticas do catálogo

• Volume de dados

• Ordem de joins

• Tipo de acesso (index scan, table scan, etc.)

Ele calcula:
👉 o plano de execução mais eficiente possível

🧠 Easter Egg técnico
O otimizador do DB2 z/OS é considerado um dos mais sofisticados do mundo, porque:

• Precisa decidir rápido

• Precisa acertar

• E não pode errar em escala bilionária

---

🧩 Passo 5 – Execução do plano: agora sim, o dado anda

Run the execution plan

Somente agora:

• O DB2 acessa tablespaces

• Usa índices (ou não)

• Aplica filtros

• Retorna os dados

Importante:

• O DB2 não executa o SQL

• Ele executa o plano previamente calculado

☕ Comentário Bellacosa
Você escreve SQL.
Quem manda é o plano de execução.

---

🧠 Visão Jedi – o fluxo completo

Tudo isso acontece nesta ordem:

SQL
 ↓
Parse (sintaxe)
 ↓
Bind lógico (tabelas / colunas / segurança)
 ↓
Criação do executável (PACKAGE)
 ↓
Otimizador calcula o plano
 ↓
Execução do plano

Se algo falhar em qualquer etapa…
👉 nada executa.

---

🧪 Dicas práticas Bellacosa Mainframe

✔ Erro de SQL geralmente é erro de modelagem ou schema
✔ Estatísticas ruins = plano ruim
✔ BIND mal feito vira problema eterno
✔ Não confunda SQL bonito com SQL eficiente
✔ EXPLAIN é seu melhor amigo

---

🥚 Curiosidades finais

• Um mesmo SQL pode ter planos diferentes em ambientes distintos

• ALTER de índice pode mudar performance sem mudar código

• Em produção, o DB2 prefere estabilidade a “milagre”

• Otimizador não é mágico — ele só decide com base no que você fornece

---

☕ Conclusão – SQL no Mainframe é disciplina

No IBM Mainframe:

• SQL não é improviso

• Execução não é tentativa

• Performance não é sorte

Cada SELECT passa por um pipeline rigoroso, desenhado para não falhar.

No El Jefe, a verdade é simples:

Quem entende o caminho do SQL dentro do DB2, para de culpar o banco e começa a dominar o sistema.

Até o próximo café ☕
— Bellacosa Mainframe

🐉 DB2 Compilação, DBRM, BIND, PACKAGE e PLAN

Bellacosa Mainframe apresenta compilaçao COBOL com DB2 plan e package

🐉 DB2 + COBOL no Mainframe

Compilação, DBRM, BIND, PACKAGE e PLAN

Ao estilo Bellacosa Mainframe – do big bang ao SELECT

---

☕ Introdução (pegue seu café)

Todo padawan que entra no mundo do IBM Mainframe + COBOL + DB2 escuta termos quase místicos:

DBRM, BIND, PACKAGE, PLAN…

No começo parecem nomes de monstros de RPG 🧙‍♂️, mas na prática eles formam o coração da integração entre COBOL e DB2.

Este artigo explica de onde isso veio, por que existe, como funciona, como compilar, como errar (e sobreviver) e como pensar como um Jedi do Mainframe.

---

🕰️ Origem e História (por que tudo isso existe?)

📜 Anos 70–80: quando DB2 nasceu

• IBM precisava de um banco relacional para rodar junto com aplicações COBOL críticas.

• COBOL não entende SQL nativamente.

• Solução: criar um pré-compilador.

👉 Nasce o conceito de SQL EMBUTIDO (EXEC SQL).

Mas…

💥 Problema:

• O compilador COBOL não sabe o que é SQL.

💡 Solução IBM:

• Criar um artefato intermediário → DBRM (Database Request Module).

---

🧩 Visão Geral do Fluxo (o mapa do tesouro)

COBOL + EXEC SQL
        |
        v
DB2 PRECOMPILER
        |
        +--> COBOL PURO
        +--> DBRM
                  |
                  v
               BIND
                  |
                  v
               PACKAGE
                  |
                  v
                PLAN
                  |
                  v
              EXECUÇÃO

👉 Nada aqui é opcional.

---

📦 O que é DBRM (Database Request Module)?

🎯 Definição

DBRM é o arquivo que contém todas as instruções SQL extraídas do seu programa COBOL.

📌 Características

• Criado pelo pré-compilador do DB2

• Contém:

  • SELECT

  • INSERT

  • UPDATE

  • DELETE

  • CURSORS

• Não contém código COBOL

🧠 Pense assim:

DBRM = “O livro de feitiços SQL do programa”

---

🧱 O que é PACKAGE?

🎯 Definição

PACKAGE é o DBRM já compilado e otimizado pelo DB2.

📌 Por que PACKAGE existe?

Antigamente:

• Um PLAN gigante para tudo ❌

Hoje:

• Um PACKAGE por programa ✔️

• Melhor performance

• Melhor controle de versão

🧠 Analogia Bellacosa

PACKAGE = prato pronto na cozinha do DB2 🍝
DBRM = receita

---

🧠 O que é PLAN?

🎯 Definição

PLAN é o conjunto de PACKAGES que uma aplicação pode executar.

📌 Importante

• Quem executa é o PLAN

• O PLAN aponta para vários PACKAGES

• Normalmente 1 PLAN por aplicação/sistema

🧠 Jedi Tip:

Programa não executa PACKAGE direto. Executa PLAN.

---

🔨 Passo a Passo para um Padawan

🥋 Passo 1 – Escrever o COBOL com SQL

EXEC SQL
   SELECT NOME
     INTO :WS-NOME
     FROM CLIENTES
    WHERE ID = :WS-ID
END-EXEC.

---

🥋 Passo 2 – Pré-compilação DB2

• Remove SQL

• Gera:

  • COBOL puro

  • DBRM

👉 Executado via DSNHPC

---

🥋 Passo 3 – Compilação COBOL

• Compila o código gerado

• Produz objeto (.OBJ)

---

🥋 Passo 4 – Linkedição

• Gera LOAD MODULE

---

🥋 Passo 5 – BIND PACKAGE

• Entrada: DBRM

• Saída: PACKAGE

---

🥋 Passo 6 – BIND PLAN

• Associa PACKAGES ao PLAN

---

🥋 Passo 7 – Executar

🎉 O programa roda feliz no CICS ou Batch.

---

📜 Exemplo de JCL – BIND PACKAGE

//BINDPKG EXEC PGM=IKJEFT01
//STEPLIB  DD DISP=SHR,DSN=DB2.DSNLOAD
//SYSTSPRT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN  DD *
  DSN SYSTEM(DB2P)
  BIND PACKAGE(MEUSCHEMA.PKGPROG1)
       MEMBER(PROG1)
       ACTION(REPLACE)
       ISOLATION(CS)
       VALIDATE(BIND)
       OWNER(MEUSCHEMA)
/*

---

🚨 Erros Comuns (e como sobreviver)

❌ -805

DBRM ou PACKAGE não encontrado

✔️ Solução:

• PACKAGE não está no PLAN

• PLAN não foi rebindado

---

❌ -818

Timestamp mismatch

✔️ Solução:

• Rebind do PACKAGE

• Código recompilado mas DBRM antigo

---

❌ -204

Objeto não existe

✔️ Solução:

• Tabela/view não existe

• Schema errado

---

💡 Dicas de Ouro Bellacosa

☕ 1 DBRM = 1 PACKAGE

☕ Nunca use PLAN gigante com tudo

☕ Sempre versionar PACKAGE

☕ Nomeie PACKAGE com ambiente:

PKGPROG1_DEV
PKGPROG1_HML
PKGPROG1_PRD

---

🥚 Easter Eggs (curiosidades)

🥚 DBRM é tão antigo que veio do System R, o avô do DB2

🥚 Muitos ambientes ainda têm PLAN criados nos anos 90 😱

🥚 Rebind pode melhorar performance sem recompilar COBOL

🥚 EXPLAIN do PACKAGE mostra o plano de acesso

---

🧙 Comentários de Mestre Jedi

Se você entende DBRM, PACKAGE e PLAN…
Você já saiu do nível Padawan.

Quem domina BIND domina o DB2.

---

📌 Conclusão

DB2 + COBOL não é magia negra.

É:

• Engenharia

• História

• Performance

• Disciplina

E quando bem feito…

🚀 Roda por décadas sem cair.

---

☕ Um Café no Bellacosa Mainframe

 

Bellacosa Mainframe apresenta Guia de Auditoria Z/OS

📘 Guia de Auditoria z/OS Completo

Do RACF ao SMP/E: como provar que seu mainframe é confiável

“Auditoria em z/OS não é caça ao erro.
É validação de maturidade operacional.”

---

🎯 Objetivo deste guia

Este guia serve para:

• Preparar ambientes para auditoria

• Responder auditores com evidência técnica

• Evitar não conformidades

• Padronizar governança em z/OS

👉 Não é teoria. É prática de campo.

---

🧠 Visão geral da auditoria em z/OS

Auditoria em z/OS gira em torno de 5 pilares:

1️⃣ Controle de acesso
2️⃣ Integridade do sistema
3️⃣ Gestão de mudanças
4️⃣ Rastreabilidade
5️⃣ Continuidade operacional

Cada pilar tem ferramentas nativas do mainframe.

---

🔐 Pilar 1 – Controle de Acesso (RACF / ACF2 / TSS)

O auditor verifica:

• IDs privilegiados

• Perfis genéricos

• UACC

• Logging

• Segregação de funções

Evidências:

• LISTUSER

• RLIST

• Relatórios SMF

• Revisão periódica de acessos

📌 Privilégio excessivo reprova auditoria.

---

🛡️ Pilar 2 – Integridade do Sistema

Ferramentas-chave:

• SMP/E

• CSI

• DLIB

• TARGET libraries

O auditor quer saber:

• Quem muda o sistema

• Como muda

• Se há controle

📌 Aqui o SMP/E reina absoluto.

---

🔁 Pilar 3 – Gestão de Mudanças

Avaliação típica:

• Processo RECEIVE/APPLY/ACCEPT

• APPLY CHECK obrigatório

• Análise de ++HOLD e ++ERROR

• USERMOD documentado

Evidências:

• Outputs SMP/E

• Change records

• APARs e PTFs

---

🧩 Pilar 4 – Rastreabilidade e Evidência

O auditor exige:

• Histórico preservado

• Logs acessíveis

• Responsáveis identificados

Ferramentas:

• CSI

• SMF

• Logs RACF

• Versionamento de JCL

📌 Sem evidência, não existe controle.

---

🔄 Pilar 5 – Continuidade e Recuperação

Avaliação:

• Backup de CSI

• Capacidade de RESTORE

• Planos de contingência

• Testes documentados

📌 Auditoria não aceita “nunca testamos”.

---

📦 Auditoria por componente (check rápido)

🔹 SMP/E

✔ Controle de acesso
✔ APPLY CHECK
✔ ACCEPT consciente
✔ USERMOD controlado

🔹 RACF

✔ UACC=NONE
✔ Logging ativo
✔ Revisão periódica

🔹 JES / System

✔ Parâmetros controlados
✔ Alterações documentadas

🔹 SMF

✔ Coleta ativa
✔ Retenção definida

---

🚨 Red flags clássicos em auditoria z/OS

❌ IDs genéricos
❌ ALTER irrestrito
❌ USERMOD esquecido
❌ PTFs de segurança atrasados
❌ Falta de documentação

👉 Tudo isso vira finding.

---

🧠 Caso real (estilo Bellacosa)

Auditor pergunta sobre um módulo alterado
Não há registro no SMP/E
Ninguém sabe quem fez

📌 Conclusão:

Ambiente sem governança.

---

🎓 Como se preparar para auditoria

• Trate auditoria como rotina

• Use SMP/E como aliado

• Automatize evidências

• Documente decisões

• Revise acessos

💡 Dica Bellacosa:

“Auditoria bem-sucedida começa meses antes.”

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• Mainframe já nasce auditável

• Falha é quase sempre humana, não técnica

---

🧾 Encerramento – Guia de Auditoria z/OS

z/OS não é inseguro.
Inseguro é rodar sem controle.

Quem domina:

• RACF

• SMP/E

• Processos

👉 passa em qualquer auditoria.

📘💾🛡️🔥

 

Bellacosa Mainframe impressionado com Umineko no Naku Koro ni

☕💣🦋 Umineko no Naku Koro ni — O Anime Que Transformou um Assassinato em um Debate Entre Lógica e Magia

Se você gostou de YU-NO, Noein, Steins;Gate, ou histórias que misturam mistério, múltiplas interpretações e realidades aparentemente incompatíveis, então Umineko no Naku Koro ni é uma das obras mais fascinantes já criadas.

Mas existe um detalhe importante:

👉 O anime de 2009 é considerado apenas uma adaptação parcial da história.

A verdadeira experiência de Umineko está na Visual Novel criada pela equipe japonesa 07th Expansion, liderada por Ryukishi07, o mesmo autor de Higurashi no Naku Koro ni.

---

A História Sem Spoilers

Em outubro de 1986, a poderosa família Ushiromiya reúne-se na ilha particular de Rokkenjima para discutir a herança do patriarca Kinzo.

Tudo parece uma reunião familiar comum.

Então uma tempestade isola a ilha.

Pouco depois começam assassinatos impossíveis.

Portas fechadas.

Salas trancadas.

Corpos surgindo em circunstâncias absurdas.

E acima de tudo:

Uma misteriosa mulher chamada Beatrice, a Bruxa Dourada, parece reivindicar a autoria dos crimes.

Mas ela existe mesmo?

Ou tudo pode ser explicado pela lógica?

Essa é a pergunta central da obra.

---

O Grande Conflito

Diferente de um anime policial comum, Umineko apresenta dois lados:

Battler Ushiromiya

Representa a lógica.

Ele acredita que:

• Bruxas não existem

• Magia não existe

• Tudo possui explicação racional

Beatrice

Representa o fantástico.

Ela afirma:

• Os assassinatos foram feitos por magia

• Bruxas são reais

• O impossível existe

A obra inteira se transforma em uma batalha intelectual.

Não uma luta física.

Uma guerra de argumentos.

---

O Que Torna Umineko Especial?

A maioria dos mistérios funciona assim:

Existe uma resposta.

Umineko faz algo diferente.

Ele pergunta:

O que é uma resposta?

A história brinca constantemente com:

• Verdade objetiva

• Interpretação

• Memória

• Narrativas

• Ponto de vista

• Metaficção

Em muitos momentos você não sabe mais se está vendo:

• fatos

• metáforas

• mentiras

• magia

• imaginação

ou tudo ao mesmo tempo.

---

O Mainframe de Umineko

Se eu fosse explicar para um operador z/OS:

Imagine um sistema que possui dois logs.

Log A

Diz:

JOB TERMINOU NORMALMENTE

Log B

Diz:

UMA BRUXA DESTRUÍU O JOB

Os dois registros aparecem simultaneamente.

Os dois parecem válidos.

Os dois possuem evidências.

Sua missão não é descobrir qual está certo.

Sua missão é entender:

Por que ambos existem.

Esse é o coração de Umineko.

---

O Conceito de "Tabuleiro"

Uma das ideias mais brilhantes da obra é o conceito de:

Game Board

Os eventos são apresentados como partidas.

Beatrice monta um tabuleiro.

Battler tenta resolvê-lo.

Quando uma explicação falha:

Novo tabuleiro.

Nova partida.

Novas peças.

Novas regras.

Cada arco revela uma camada maior do quebra-cabeça.

---

A Verdade Vermelha

Uma das mecânicas mais famosas.

Quando alguém usa a:

Red Truth

A declaração torna-se absolutamente verdadeira.

Por exemplo:

"Ninguém entrou naquela sala."

A partir daí, o jogador precisa descobrir como o crime ocorreu sem violar essa regra.

É quase um desafio lógico formal.

---

O Anime é Bom?

Aqui existe uma polêmica.

A comunidade costuma dizer:

Visual Novel: Obra-prima

Mangá: Excelente

Anime: Incompleto

O anime cobre apenas parte da história e deixa muitas perguntas sem resposta.

Por isso muitos fãs recomendam:

1. Visual Novel

2. Mangá

3. Anime apenas como complemento

---

Tem Viagem Temporal?

Não exatamente.

Mas possui elementos que lembram obras como:

• YU-NO

• Noein

• Steins;Gate

• Higurashi

porque trabalha com:

• múltiplas possibilidades

• linhas narrativas alternativas

• realidades conflitantes

• interpretação da verdade

---

Curiosidades

A obra possui mais de 1 milhão de palavras

É maior que muitos romances clássicos.

Ryukishi07 era funcionário público

Ele escrevia histórias nas horas vagas.

O nome Umineko significa

"Gaivota"

Por isso você verá gaivotas constantemente associadas à obra.

A trilha sonora é lendária

Músicas como:

• Hope

• Dreamenddischarger

• Goldenslaughterer

• Worldend Dominator

são extremamente famosas entre os fãs.

---

Vale a Pena?

Se você gosta de:

✅ Mistérios complexos

✅ Filosofia

✅ Narrativas não lineares

✅ Metaficção

✅ Histórias que exigem atenção

✅ Obras como YU-NO e Noein

Então Umineko pode se tornar uma das experiências mais marcantes que você já teve.

Mas entre preparado:

Este não é um anime para desligar o cérebro.

É um quebra-cabeça gigantesco disfarçado de história de assassinato.

E quando você finalmente entende o que realmente aconteceu em Rokkenjima...

percebe que a pergunta nunca foi:

"Quem matou?"

Mas sim:

"O que significa conhecer a verdade?"

Classificação Bellacosa Mainframe: ☕☕☕☕☕ (5/5 cafés)

Nível de Complexidade: JCL simples ❌

Nível Real: Debug de dump S0C4 sem documentação às 3 da manhã em pleno fechamento bancário. ☕💣🦋

Bellacosa Mainframe e as memorias da doce Giovanna

☕ Um Café no Bellacosa Mainframe

Campinas — Quando a Vida Parecia Mais Colorida

Há épocas da vida em que tudo parece mais doce.

As cidades parecem mais coloridas, os dias mais compridos e até as coisas mais simples carregam uma importância que só descobrimos muitos anos depois.

Entre 1999 e 2002 namorei Giovanna, de Amparo.

Já escrevi outras vezes sobre aqueles dias, sobre Amparo e sobre as lembranças que ficaram daquele período. Mas hoje, em 2009, foi Campinas que resolveu bater à porta da memória.

Giovanna havia se mudado para a região da Andrade Neves, no Castelo, para fazer cursinho no Anglo.

E, sem percebermos, nosso pequeno mapa particular ficou maior.

Até então, nossa geografia sentimental estava mais ou menos limitada ao eixo Itatiba–Amparo. De repente, Campinas entrou novamente em minha vida.

Digo novamente porque Campinas sempre apareceu em capítulos diferentes da minha história.

Nos anos 1970, passei por ela com meus pais.

Nos anos 1980, vieram os passeios com meus tio-avós Guiomar e Francisco.

Depois, já em outra fase da vida, veio Cris.

E então Giovanna.

É curioso perceber como uma mesma cidade pode pertencer a tantas versões diferentes de nós mesmos.

Da Campinas daqueles dias, não me lembro apenas dos lugares.

Lembro-me principalmente das pequenas coisas.

De jantar com Giovanna em um restaurante japonês no Castelo.

De ir até a porta do cursinho encontrá-la.

De bater perna despreocupadamente entre a antiga rodoviária e a casa dela.

Nosso acordo era simples:

quem chegasse primeiro esperava o outro.

Só isso.

Nenhum aplicativo avisando localização. Nenhuma mensagem dizendo “estou chegando”. Nenhum pontinho se movimentando sobre um mapa.

Um esperava.

O outro aparecia.

E a vida funcionava.

Também me lembro das despedidas apressadas, quando precisava correr para apanhar o fretado e seguir para São Paulo para trabalhar.

Naquele momento aquilo era apenas rotina.

Hoje virou memória.

E existem algumas lembranças que o tempo, por algum motivo, decidiu guardar com uma nitidez quase cruel.

Fecho os olhos e ainda consigo enxergar a doce odalisca mostrando os passos que aprendera em um curso de dança em Amparo.

Uma pequena apresentação particular.

Um instante absolutamente banal para o restante do planeta.

Para mim, não.

Também me lembro, e confesso que ainda com a face um pouco corada, da doce colegial de rabo de cavalo, camisa branca e saia xadrez.

São fotografias que não precisam existir em papel.

A memória resolveu revelá-las sozinha.

Talvez seja isso que chamamos de saudade.

Não necessariamente vontade de voltar.

Não necessariamente arrependimento pelos caminhos que cada um escolheu.

É simplesmente perceber que existiu um tempo que não existe mais — e que fomos felizes dentro dele sem saber que, um dia, sentiríamos falta até das caminhadas mais comuns.

Hoje Campinas é outra.

Eu também sou outro.

Giovanna certamente seguiu seus próprios caminhos.

Mas existe uma Campinas que nenhuma reforma urbana conseguirá modificar.

Aquela Campinas continua parada em algum lugar entre 1999 e 2002.

Nela, existe um rapaz caminhando da antiga rodoviária em direção ao Castelo.

Existe uma garota saindo do cursinho.

Existe um restaurante japonês esperando pelos dois.

Existe um fretado que ainda precisa ser alcançado.

E existe aquele velho combinado:

quem chegar primeiro espera o outro.

Talvez seja justamente isso que a memória esteja fazendo todos esses anos depois.

Esperando.

Saudosa Giovanna.

Seguimos por caminhos diferentes, como tantas pessoas que um dia dividiram um pedaço da vida.

Mas algumas pessoas não desaparecem completamente quando partem de nossa história.

Elas permanecem associadas a uma rua, uma música, uma estação, um restaurante, uma roupa, um perfume, uma cidade.

E basta fechar os olhos para que tudo volte por alguns segundos.

Campinas.

Castelo.

Andrade Neves.

O Anglo.

A antiga rodoviária.

A caminhada.

O restaurante japonês.

A odalisca.

A colegial de rabo de cavalo.

O fretado esperando.

Há épocas da vida em que tudo realmente parece mais doce e mais colorido.

Talvez não fossem.

Talvez nós é que fôssemos.

E quando uma dessas lembranças atravessa inesperadamente décadas para nos visitar, o coração aperta um pouquinho.

A gente sorri.

E deixa aquela inevitável lagriminha aparecer no canto do olho.

 

Inuyasha: The Final Act : Quando um Programador COBOL Descobre que Todo Sistema Legado Precisa de um Último Deploy...

 

Bellacosa Mainframe apresenta inuyasha the final act

☕ Um Café no Bellacosa Mainframe

Inuyasha: The Final Act (犬夜叉 完結編) sem Mistérios

Quando um Programador COBOL Descobre que Todo Sistema Legado Precisa de um Último Deploy... e que Resolver 500 Anos de Bugs Nunca é Apenas um PTF

"Existem projetos que nunca terminam porque ninguém sabe como encerrá-los. Inuyasha: The Final Act é aquele raro momento em que a equipe finalmente recebe orçamento para concluir o sistema, remover o bug principal e fechar todos os chamados abertos desde 1996."

---

Introdução

Poucos animes conseguiram entregar um encerramento tão aguardado quanto Inuyasha: The Final Act (犬夜叉 完結編).

Durante cinco anos, milhares de fãs permaneceram sem conhecer o verdadeiro destino de Inuyasha, Kagome, Sesshomaru, Naraku e da lendária Shikon no Tama.

A série original terminou em 2004 porque o mangá ainda estava em publicação.

Somente em 2008, quando Rumiko Takahashi concluiu a obra, tornou-se possível adaptar o restante da história.

Assim nasceu The Final Act, responsável por adaptar aproximadamente os últimos 20 volumes do mangá em apenas 26 episódios.

Para muitos fãs, trata-se do verdadeiro final de Inuyasha.

---

Dados Técnicos

Título Original

犬夜叉 完結編

(Inuyasha Kanketsu-hen)

Significado:

"Inuyasha — O Capítulo Final"

---

Autora

Rumiko Takahashi (高橋 留美子)

Uma das maiores autoras da história dos mangás.

Outras obras:

• Urusei Yatsura

• Maison Ikkoku

• Ranma ½

• Mermaid Saga

• Rin-ne

• Mao

---

Estúdio

Sunrise

(atualmente Bandai Namco Film Works)

Mesmo estúdio responsável pela série original.

---

Direção

Yasunao Aoki

---

Exibição

Japão

03 de outubro de 2009

até

29 de março de 2010

---

Episódios

26

---

Mangá Adaptado

Volumes finais

aproximadamente

37 ao 56

---

Gênero

• Fantasia

• Aventura

• Romance

• Drama

• Sobrenatural

• Ação

• Shōnen

• Mitologia Japonesa

---

Classificação

14 anos

Contém:

• violência

• sangue

• batalhas intensas

• morte

• drama psicológico

---

Sinopse

A busca pelos fragmentos da Joia de Quatro Almas aproxima-se do fim.

Naraku finalmente reúne poder suficiente para transformar todo o Japão.

Enquanto isso, Inuyasha precisa dominar completamente a Tessaiga.

Sesshomaru inicia sua maior transformação.

Kagome descobre seu verdadeiro papel na história.

E todos finalmente enfrentam o passado que os perseguiu durante séculos.

---

Resumo

Toda a série converge para um único objetivo:

Derrotar Naraku.

Mas vencer o vilão não é suficiente.

Também é preciso:

• compreender a Joia

• romper o ciclo de ódio

• aceitar perdas

• abandonar ressentimentos

---

A História

A narrativa acelera bastante em relação à série original.

Os acontecimentos tornam-se mais densos.

Quase não existem episódios isolados.

Cada capítulo leva diretamente ao próximo.

Os confrontos finais envolvem:

• Naraku

• Magatsuhi

• Kohaku

• Sesshomaru

• Kikyō

• Kagome

• Tessaiga

• Tenseiga

• Meidō Zangetsuha

Tudo converge para a resolução definitiva dos conflitos iniciados décadas antes.

---

Os Personagens

Inuyasha

Agora deixa de ser apenas impulsivo.

Aprende responsabilidade.

Aceita suas duas naturezas.

Finalmente compreende o verdadeiro significado da força.

---

Kagome

Talvez a personagem que mais amadurece.

Sua ligação espiritual supera a de Kikyō.

Ela deixa de ser apenas "a garota do futuro".

Torna-se peça essencial para salvar ambos os mundos.

---

Sesshomaru

Provavelmente recebe o melhor desenvolvimento de toda a franquia.

Sua jornada deixa de ser baseada em orgulho.

Passa a compreender:

empatia

proteção

família

sacrifício

Seu relacionamento com Rin muda completamente sua visão da humanidade.

---

Naraku

Agora mostra sua verdadeira natureza.

Não busca apenas poder.

Busca preencher um vazio impossível.

O amor não correspondido de Onigumo continua sendo sua prisão.

---

Kikyō

Sua despedida é uma das cenas mais emocionantes do anime.

Representa finalmente:

aceitação

perdão

liberdade

---

Kohaku

Finalmente encerra sua tragédia.

---

Rin

Continua sendo a pequena luz capaz de transformar Sesshomaru.

---

O Que Tem de Diferente?

A maior diferença é o ritmo.

Enquanto a série original possuía muitos episódios de aventura, humor e exploração do folclore, The Final Act é quase uma sequência contínua de revelações e confrontos decisivos.

Não há espaço para longos desvios. Cada episódio aproxima os personagens do desfecho e resolve conflitos que estavam em aberto desde o início da obra.

---

Temáticas

Encerramento

Tudo termina.

Até grandes jornadas.

---

Perdão

Nenhuma vingança dura para sempre.

---

Crescimento

Todos mudaram.

Até Sesshomaru.

---

Escolhas

Não existe destino absoluto.

---

Amor

Não é posse.

É liberdade.

---

Sacrifício

O verdadeiro heroísmo exige abrir mão de algo importante.

---

Aventuras

A reta final reúne as maiores batalhas da franquia: a conclusão da busca pelos fragmentos da Joia, o aperfeiçoamento da Tessaiga, a evolução de Sesshomaru com a Tenseiga, o confronto contra Magatsuhi e, por fim, a batalha definitiva contra Naraku.

As viagens deixam de ser apenas exploração do Japão Feudal e tornam-se uma corrida contra o tempo para impedir que a corrupção da Joia destrua tudo.

---

Mensagens Ocultas

O Verdadeiro Inimigo Nunca Foi Naraku

Naraku nasce da incapacidade de abandonar desejos destrutivos.

O inimigo é o apego.

---

A Joia Nunca Foi Boa Nem Má

Ela apenas reflete quem a utiliza.

Assim como qualquer tecnologia poderosa.

---

Sesshomaru Aprende Humanidade

Sem nunca deixar de ser um yokai.

---

Kagome Rompe o Ciclo

Ela faz aquilo que ninguém antes conseguiu.

Recusa o poder absoluto.

---

Impacto Cultural

Apesar de ter apenas 26 episódios, The Final Act foi recebido como a conclusão que os fãs esperaram por anos.

A adaptação é frequentemente elogiada por ser fiel ao desfecho do mangá e por encerrar os principais arcos narrativos.

Também consolidou Sesshomaru como um dos personagens mais populares da franquia, o que influenciou diretamente a criação de Yashahime, série centrada na geração seguinte.

---

Censura

Por ser exibido em um horário mais voltado ao público adolescente e adulto, The Final Act preservou a maior parte da violência e do conteúdo dramático do mangá.

Em alguns mercados internacionais houve pequenas reduções de sangue e ajustes de classificação indicativa, mas o conteúdo principal permaneceu praticamente intacto.

---

Mangá

The Final Act não possui um mangá separado.

Ele adapta os capítulos finais do mangá original Inuyasha, publicados entre os volumes finais da coleção.

---

Novels

Não existe uma série principal de light novels que continue oficialmente os acontecimentos após o final do mangá.

A narrativa canônica permanece centrada no mangá original e em sua adaptação animada.

---

Games

Após The Final Act, a franquia continuou aparecendo em jogos de celular, eventos comemorativos e crossovers.

Entre os títulos clássicos relacionados à série estão:

• Inuyasha: A Feudal Fairy Tale (PlayStation)

• Inuyasha: The Secret of the Cursed Mask (PlayStation 2)

• Inuyasha: Feudal Combat (PlayStation 2)

• Inuyasha: Secret of the Divine Jewel (Nintendo DS)

Também houve colaborações em jogos mobile no Japão com personagens da franquia.

---

Curiosidades

• A série foi produzida para adaptar apenas o material restante do mangá, sem criar episódios filler.

• A trilha sonora de Kaoru Wada mantém a identidade da série original, mas com arranjos mais dramáticos.

• O encerramento do anime é considerado por muitos fãs um dos finais mais satisfatórios dos grandes shōnen dos anos 2000.

• O romance entre Inuyasha e Kagome finalmente recebe uma conclusão clara, encerrando um dos triângulos amorosos mais famosos dos animes.

---

Easter Eggs

• A evolução das espadas Tessaiga e Tenseiga simboliza a maturidade de seus portadores.

• A decisão final de Kagome diante da Joia ecoa antigas histórias budistas sobre desapego e iluminação.

• O desfecho de Sesshomaru prepara discretamente elementos que seriam retomados anos depois em Yashahime.

---

☕ Bellacosa Mainframe

Imagine que Naraku seja um defeito registrado no sistema desde a primeira versão do software, em 1540. Durante séculos, dezenas de equipes tentaram corrigi-lo apenas aplicando pequenos patches, contornos e gambiarras.

The Final Act representa o grande projeto de modernização. Chega o momento de revisar a arquitetura, eliminar dependências ocultas e encerrar definitivamente o incidente raiz.

Inuyasha é o programa legado que finalmente compreende toda a documentação perdida.

Sesshomaru assume o papel do arquiteto experiente que descobre que liderança não significa apenas desempenho, mas também proteger quem depende do sistema.

Kagome é a analista que entende que a melhor solução nem sempre é usar mais poder computacional, e sim fazer a escolha correta no momento decisivo.

No final, Inuyasha: The Final Act ensina uma lição valiosa para qualquer profissional de tecnologia: não basta corrigir os sintomas de um sistema legado. É preciso enfrentar a causa original do problema. Enquanto o defeito permanecer escondido na arquitetura, novos ABENDs continuarão surgindo, por mais modernos que sejam os servidores ou as ferramentas de desenvolvimento.