Translate

terça-feira, 6 de outubro de 2009

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.

segunda-feira, 5 de outubro de 2009

SEITOKAI NO ICHIZON — O ANIME QUE TRANSFORMOU REUNIÕES DO CONSELHO ESTUDANTIL EM UM DATACENTER DE PIADAS, OTAKICES E META-HUMOR SEM JANELA DE MANUTENÇÃO

 

Bellacosa Mainframe seitokai no ichizon 

☕💣📋 OPERADOR, O CHANGE MANAGEMENT ENTROU EM LOOP INFINITO!

SEITOKAI NO ICHIZON — O ANIME QUE TRANSFORMOU REUNIÕES DO CONSELHO ESTUDANTIL EM UM DATACENTER DE PIADAS, OTAKICES E META-HUMOR SEM JANELA DE MANUTENÇÃO


Dados da Obra

Título Original: 生徒会の一存 (Seitokai no Ichizon)

Título em Inglês: Student Council's Discretion

Autor: Aoi Sekina

Ilustrações da Light Novel: Kira Inugami

Editora Original: Fujimi Shobo

Light Novel: 2008–2012

Anime (1ª Temporada):

  • Outubro de 2009 a Dezembro de 2009

  • 12 episódios

Anime (2ª Temporada – Seitokai no Ichizon Lv.2):

  • 2012–2013

  • 10 episódios

Estúdio da 1ª Temporada: Studio Deen

Estúdio da 2ª Temporada: AIC

Direção: Takuya Satou


Classificação e Gênero

Gêneros

  • Comédia

  • Escolar

  • Slice of Life

  • Romance

  • Harém

  • Paródia

  • Metalinguagem

  • Otaku Culture

Classificação Indicativa

14 anos

Possui:

  • insinuações românticas

  • humor de duplo sentido

  • piadas otaku

  • referências a fan service

Mas sem violência pesada ou conteúdo adulto explícito.


Sinopse

Na Academia Hekiyou, os membros do Conselho Estudantil não são escolhidos por mérito administrativo.

São escolhidos por popularidade.

As garotas mais admiradas da escola ocupam os cargos do conselho.

Porém existe uma exceção.

O aluno com as melhores notas pode entrar automaticamente.

Assim surge Ken Sugisaki, um garoto que estudou obsessivamente para conseguir uma vaga.

Seu objetivo?

Criar o maior harém escolar da história.

O problema é que suas futuras pretendentes não parecem compartilhar da mesma visão estratégica do projeto.


Resumo da História

A série acompanha as reuniões do Conselho Estudantil da Academia Hekiyou.

E quando digo reuniões...

Estou falando de reuniões mesmo.

Ao contrário da maioria dos animes escolares:

  • não existem torneios

  • não existem invasões demoníacas

  • não existem poderes sobrenaturais

  • não existem guerras

Os personagens simplesmente conversam.

E é justamente aí que está o segredo da obra.

As conversas evoluem para discussões absurdas sobre:

  • animes

  • videogames

  • namoro

  • cultura geek

  • light novels

  • clichês da indústria

  • popularidade

  • sonhos pessoais

O resultado é uma das comédias mais inteligentes da década de 2000.


O Que Torna Este Anime Diferente?

1. A Sala do Conselho É o Universo Inteiro

☕ Visão Bellacosa Mainframe:

Imagine um sistema que executa toda a produção dentro de uma única LPAR.

Sem regiões externas.

Sem servidores distribuídos.

Sem cloud.

Apenas uma sala.

Esse é Seitokai no Ichizon.

Mais de 80% da série acontece no mesmo ambiente.

Mesmo assim nunca se torna entediante.


2. O Anime Sabe Que É Um Anime

A obra constantemente quebra a quarta parede.

Os personagens discutem:

  • audiência

  • roteiros

  • clichês

  • orçamento

  • rankings de popularidade

É como se os próprios programas COBOL começassem a comentar os erros do desenvolvedor durante a execução.


3. Não Existe História Principal Convencional

A maioria dos animes segue:

  • início

  • desenvolvimento

  • clímax

  • conclusão

Seitokai no Ichizon segue:

  • conversa

  • piada

  • referência

  • piada sobre a referência

  • piada sobre a piada

E milagrosamente funciona.


Os Personagens

Ken Sugisaki

O protagonista.

Autoproclamado futuro rei do harém.

Por trás da fachada de pervertido existe um personagem surpreendentemente profundo.

Seu passado revela dificuldades familiares e problemas emocionais que explicam sua obsessão por criar laços afetivos.


Kurimu Sakurano

Presidente.

Pequena.

Fofa.

Caótica.

Parece uma criança administrando um ambiente corporativo.

É o equivalente a um gerente de produção que mede 1,40 m mas controla todo o datacenter.


Chizuru Akaba

Tesoureira.

Educada.

Refinada.

Assustadora.

Especialista em tortura psicológica.

Seria facilmente promovida a administradora RACF.


Minatsu Shiina

Vice-presidente.

Atleta.

Impulsiva.

Energia infinita.

Representa aquele operador que resolve primeiro e pergunta depois.


Mafuyu Shiina

Secretária.

Otaku extrema.

Vive em um universo paralelo de games, animes e fanfics.

É praticamente a documentação viva da cultura geek.


As Aventuras

Embora não existam aventuras físicas tradicionais, existem aventuras intelectuais.

Cada episódio é uma exploração de temas como:

  • amizade

  • autoestima

  • sonhos

  • rejeição

  • amadurecimento

  • identidade

Tudo escondido atrás de uma enorme camada de humor.


As Mensagens Ocultas

O Valor das Conexões Humanas

O harém nunca foi o verdadeiro objetivo.

O verdadeiro tema é:

construir relacionamentos significativos.

Ken usa o humor para esconder sua necessidade de pertencimento.


A Solidão dos Populares

Todas as garotas do conselho são admiradas.

Mas também carregam inseguranças profundas.

A obra mostra que popularidade não elimina problemas emocionais.


A Máscara Social

Cada personagem usa uma persona pública.

Conforme a série avança descobrimos quem eles realmente são.

É uma crítica elegante à forma como as pessoas escondem fragilidades.


O Otaku Como Pessoa Normal

Em 2009 ainda existia muito preconceito contra a cultura otaku.

Seitokai no Ichizon foi uma das obras que ajudou a normalizar esse público.

A mensagem é clara:

Gostar de anime não torna ninguém estranho.


Impacto Cultural

Embora nunca tenha alcançado o nível de:

  • Haruhi Suzumiya

  • Lucky Star

  • K-On!

Tornou-se uma obra cult entre fãs de comédia escolar.

Sua influência pode ser percebida em séries posteriores que apostaram em:

  • meta-humor

  • referências internas

  • quebra da quarta parede

Foi uma das obras que ajudou a consolidar o humor autoconsciente nos animes modernos.


Houve Censura?

Não houve censura significativa.

Porém:

Algumas Referências Foram Adaptadas

Certas piadas relacionadas a outras franquias receberam alterações ou foram suavizadas em versões internacionais.

Traduções Perderam Parte do Humor

Muitas piadas dependem de:

  • trocadilhos japoneses

  • conhecimento de cultura otaku

  • referências da indústria

Isso fez com que algumas legendas ocidentais não conseguissem reproduzir completamente o material original.


Análise Técnica do Studio Deen

O Studio Deen compreendeu algo importante:

O ponto forte não era a animação.

Era o diálogo.

Por isso investiu principalmente em:

  • atuação dos dubladores

  • timing cômico

  • direção de humor

Visualmente o anime é simples.

Mas narrativamente funciona muito bem.

É um exemplo clássico de produção onde o roteiro vale mais que o orçamento.


Pontos Fortes

✅ Personagens extremamente carismáticos

✅ Humor inteligente

✅ Metalinguagem avançada

✅ Excelente química entre o elenco

✅ Muitas referências para fãs de anime

✅ Episódios leves e divertidos


Pontos Fracos

❌ Pouca ação

❌ Quase tudo acontece no mesmo local

❌ Humor depende de conhecimento otaku

❌ Algumas piadas envelheceram

❌ Pode parecer repetitivo para quem busca uma trama tradicional


Veredito Bellacosa Mainframe

☕💣 OPERADOR, IMAGINE UMA REUNIÃO DE CHANGE MANAGEMENT QUE DURA DUAS TEMPORADAS, ONDE NINGUÉM APROVA NADA, NINGUÉM IMPLEMENTA NADA, MAS TODOS SAEM MAIS FELIZES DO QUE ENTRARAM.

Isso é Seitokai no Ichizon.

Um anime que provou algo quase impossível:

não é necessário salvar o mundo para criar uma história memorável.

Basta colocar cinco personagens carismáticos em uma sala e deixá-los conversar.

O resultado é uma obra que continua divertida mais de uma década após seu lançamento.

Nota Bellacosa Mainframe

CritérioNota
Humor10/10
Personagens9,5/10
Originalidade10/10
Romance7,5/10
Animação7/10
Reassistibilidade9/10
Impacto Cultural8/10

Nota Final

9,0/10 — STATUS DA PRODUÇÃO: ESTÁVEL

Uma das melhores comédias escolares da era das light novels e um verdadeiro clássico cult para qualquer operador otaku que já participou de uma reunião interminável que, misteriosamente, acabou se tornando divertida.

domingo, 4 de outubro de 2009

🔷 INNER JOIN no IBM DB2 Mainframe – A Arte de Relacionar Tabelas

 

Bellacosa Mainframe apresenta IBM Mainframe DB2 Inner Join

🔷 INNER JOIN no IBM DB2 Mainframe – A Arte de Relacionar Tabelas

Se você trabalha com IBM Mainframe, provavelmente já precisou combinar dados de diferentes tabelas. E para isso existe o INNER JOIN, que é o clássico entre os joins em SQL.

Mas antes de entrar nos detalhes, vamos à história…


🕰️ História e Origem

O conceito de INNER JOIN vem diretamente do Modelo Relacional de Codd (1970), criado dentro da IBM.

  • Edgar F. Codd, um cientista da IBM, imaginou que dados deveriam ser armazenados em tabelas relacionais e manipulados por álgebra relacional.

  • Ele não inventou “INNER JOIN” como conhecemos hoje, mas a ideia de combinar tabelas via chaves comuns nasceu com ele.

  • SQL evoluiu nos anos 80 para suportar explicitamente joins:

    • Sintaxe implícita: FROM A, B WHERE A.key = B.key

    • Sintaxe explícita: FROM A INNER JOIN B ON A.key = B.key

No DB2 para Mainframe, o INNER JOIN é altamente otimizado para lidar com milhões de linhas em transações batch ou OLTP, mantendo a performance crítica.


⚙️ O que é INNER JOIN?

INNER JOIN é a operação que retorna somente as linhas onde existe correspondência em ambas as tabelas, baseado em uma chave comum.

🔹 Sintaxe padrão DB2

-- Explicit INNER JOIN (recomendado) SELECT E.EmployeeID, E.LastName, O.OrderID FROM Employees E INNER JOIN Orders O ON E.EmployeeID = O.EmployeeID;
-- Implicit INNER JOIN (estilo antigo) SELECT E.EmployeeID, E.LastName, O.OrderID FROM Employees E, Orders O WHERE E.EmployeeID = O.EmployeeID;

🔹 Observações

  • Chave comum: não precisa ter o mesmo nome, apenas valores compatíveis.

  • Sem correspondência → linha é descartada.

  • Pode usar múltiplas tabelas → INNER JOIN é associativo.


💡 Dicas Bellacosa para Mainframe

  1. Prefira joins explícitos (INNER JOIN ON) em DB2 → facilita leitura e manutenção.

  2. Sempre qualifique colunas se houver nomes repetidos → evita ambiguidade (E.EmployeeID, O.EmployeeID).

  3. Use aliases curtos → economiza digitação e deixa o código limpo.

  4. Evite cartesian products sem intenção → FROM A, B sem WHERE é um Product, que explode linhas.

  5. Verifique estatísticas de tabela → DB2 otimiza join usando índices.


🔍 Curiosidades & Easter Eggs

  • No DB2, todas as joins são INNER por padrão se você não usar OUTER.

  • Internamente, o otimizador transforma INNER JOIN em operações de álgebra relacional: Product + Selection.

  • Usar JOIN explícito ajuda o Explain Plan a gerar caminhos de acesso mais eficientes.

  • Combinar índices corretos + INNER JOIN = batch mais rápido, menos I/O.


🧪 Exemplo prático

Imagine que temos duas tabelas no z/OS DB2:

EMPLOYEES

EmployeeIDLastNameDeptID
101Smith10
102Jones20

DEPARTMENTS

DeptIDDeptName
10Accounting
20HR
30IT

Query: INNER JOIN

SELECT E.LastName, D.DeptName FROM Employees E INNER JOIN Departments D ON E.DeptID = D.DeptID;

Resultado:

LastNameDeptName
SmithAccounting
JonesHR

Observe: DeptID = 30 não aparece porque não há funcionário correspondente.


📈 Uso e Razão de Uso

  • Combinar tabelas relacionadas → RELACIONAL puro

  • Resumir informações em relatórios ou dashboards OLAP

  • Criar answer sets consistentes para análises

  • Fundamental para consultas em ERP, finanças e logística

No mainframe, INNER JOIN é usado em:

  • Batch → processa milhões de registros rapidamente

  • Online Transaction Processing (OLTP) → respostas rápidas e consistentes


⚡ Impacto na Performance e Otimização

  1. Indexes importam muito:

    • JOIN em colunas indexadas = leitura rápida, menos I/O

    • Sem índice → DB2 faz table scan → lento em tabelas grandes

  2. Estatísticas DB2:

    • RUNSTATS ajuda o otimizador a escolher o caminho ideal

  3. Número de tabelas no JOIN:

    • Mais joins = mais complexidade e consumo de CPU

    • Prefira joins em cascata controlados, evite joins desnecessários

  4. Filtros antes do JOIN:

    • Use WHERE/qualificação para reduzir linhas antes do INNER JOIN

    • Isso diminui o volume de dados processados e acelera o batch


🔑 Comentários finais Bellacosa

  • INNER JOIN é a base do SQL relacional, especialmente no DB2 do mainframe.

  • Sintaxe explícita + colunas qualificadas + índices corretos = performance top de linha.

  • Mesmo em 2026, ele é indispensável em sistemas críticos da IBM.

  • Dica bônus: use EXPLAIN PLAN para ver como DB2 executa seus INNER JOINs.

💡 Easter Egg:

Por baixo do capô, o DB2 transforma cada INNER JOIN em Product + Selection + Projection na álgebra relacional — a magia acontece silenciosa enquanto você apenas digita INNER JOIN.

 

sábado, 3 de outubro de 2009

🗼 AKIHABARA – O MAINFRAME OTAKU DO JAPÃO

 

Bellacosa Mainframe visita Akihabara

🗼 AKIHABARA – O MAINFRAME OTAKU DO JAPÃO


Se Tóquio fosse um datacenter, Akihabara seria aquele andar barulhento, cheio de LEDs piscando, cabos aparentes, cheiro de eletrônico quente… e personagens de anime te oferecendo panfleto na porta. Bem-vindo a Akihabara (秋葉原), ou simplesmente Akiba, o bairro que começou como loja de rádio e virou o hub definitivo da cultura otaku mundial.


🏯 ORIGEM – DO RÁDIO AO WAIFU

No pós-guerra, anos 1940–50, Akihabara nasceu como um mercado informal de eletrônicos.
Peças usadas, rádios, válvulas, fios — era o camelódromo high-tech da época.

📻 Décadas depois:

  • anos 70–80 → eletrônicos e computadores

  • anos 90 → videogames, PCs, doujinshi

  • anos 2000 → anime, mangá, idols, maid cafés

Ou seja: Akihabara evoluiu como software legado bem mantido.


👀 O QUE VER (DEBUG VISUAL)

🔹 Lojas de eletrônicos (Yodobashi Camera – um monstro)
🔹 Prédios de 6 a 10 andares, cada piso um universo
🔹 Arcades gigantes (SEGA, Taito, GIGO)
🔹 Vitrines absurdas com figures raríssimas
🔹 Placas neon disputando atenção como batch concorrente


🎮 O QUE FAZER (INTERACTIVE MODE)

✔ Caçar figures (novas e usadas)
✔ Jogar claw machines até perder a dignidade
✔ Entrar em lojas de doujin (mangas independentes)
✔ Explorar andares escondidos (EASTER EGGS reais)
✔ Fotografar cosplayers (com respeito!)

💡 Dica Bellacosa: sempre olhe os andares de cima. O tesouro nunca está no térreo.


🍜 O QUE COMER (BUFFER DE ENERGIA)

🍛 Curry japonês
🍜 Ramen temático
🍙 Onigiri raiz
🍺 Bares minúsculos escondidos
Maid cafés (experiência cultural — não é só zoeira)

👉 Maid café é tipo CICS: quem não conhece acha estranho, quem entende respeita.


🧠 CURIOSIDADES & EASTER EGGS

🟡 Algumas lojas vendem hardware obsoleto funcional
🟡 Tem prédios inteiros só de um único jogo
🟡 Muitas lojas mudam layout semanalmente
🟡 Mangás pornôs ficam separados (com censura pixelada 😏)
🟡 Você pode comprar um parafuso raro ou uma waifu em escala 1/4


🧩 AKIHABARA EM ANIMES

📺 Aparece em:

  • Steins;Gate (literalmente o coração da história)

  • Love Live

  • Durarara!!

  • Oreimo

  • Genshiken

Em anime, Akiba é sempre:
➡️ lugar de encontros
➡️ caos criativo
➡️ refúgio dos “estranhos”
➡️ palco de revelações


🧠 COMENTÁRIO BELLACOSA

Akihabara não é só consumo.
É pertencimento.

Ali ninguém te julga por:

  • gostar de coisa velha

  • colecionar obsessivamente

  • se apaixonar por pixels

  • viver em universos paralelos

Akihabara entende legado, respeita versão antiga e celebra customização extrema.


🏁 CONCLUSÃO

Akihabara é:

  • um Sysplex cultural

  • um cluster de paixões

  • um mainframe humano

Não é bairro.
É estado de espírito.

E como todo bom sistema antigo:
faz barulho, esquenta…
mas nunca cai.

🗼💾


🔷 Relational Algebra no Mainframe

 

Bellacosa Mainframe apresenta o motor do DB2 a algebra relacional


🔷 Relational Algebra no Mainframe

Uma viagem raiz pelo coração do DB2 (IBM Mainframe Edition)

Se você trabalha — ou sonha em trabalhar — com IBM Mainframe, cedo ou tarde vai ouvir um termo que parece saído de um livro de matemática dos anos 70:

👉 Relational Algebra

Calma. Respira.
Não é um bicho de sete cabeças.
É, na verdade, a Força por trás do SQL.

Antes de existir SELECT * FROM SYSIBM.SYSDUMMY1, alguém precisou pensar como os dados se relacionam. Esse alguém foi Edgar F. Codd, lá na IBM, em 1970. Sim, tudo isso nasceu dentro da IBM — respeita o mainframe. 🖥️


🕰️ Um pouco de história (porque mainframe sem história não é mainframe)

Nos anos 60 e 70:

  • Arquivos eram sequenciais

  • Relatórios demoravam horas

  • Qualquer mudança era dor e sofrimento

Então a IBM apresentou o Modelo Relacional:

  • Dados em tabelas

  • Relações matemáticas

  • Independência entre dados e programas

E para manipular essas tabelas, surgiu a Relational Algebra — uma linguagem conceitual, não escrita diretamente no sistema, mas usada pelo otimizador do DB2 por baixo dos panos.

💡 Easter Egg:
Quando você escreve SQL no DB2, o que o banco realmente executa internamente é Relational Algebra otimizada.


⚙️ Os 5 operadores essenciais (o sabre de luz do DBA)

Vamos aos clássicos:


1️⃣ Projection (π) — “Me mostra só o que eu preciso”

📌 O que faz
Seleciona colunas específicas de uma tabela.

📘 Conceito:

π (COLUNA1, COLUNA2)

🧠 Tradução DB2:

SELECT COLUNA1, COLUNA2 FROM TABELA;

🖥️ Exemplo Mainframe:

SELECT EMPNO, LASTNAME FROM EMP;

💡 Dica Bellacosa:

Projection reduz I/O.
Menos coluna = menos leitura = batch mais rápido = operador feliz.


2️⃣ Selection (σ) — “Filtra isso aí”

📌 O que faz
Seleciona linhas com base em uma condição.

📘 Conceito:

σ (SALARY > 50000)

🧠 Tradução DB2:

SELECT * FROM EMP WHERE SALARY > 50000;

💡 Easter Egg:

WHERE é Selection.
Sempre foi. Sempre será.


3️⃣ Union (∪) — “Junta tudo, mas sem duplicar”

📌 O que faz
Concatena duas relações compatíveis (mesmas colunas).

📘 Conceito:

R ∪ S

🧠 Tradução DB2:

SELECT EMPNO FROM EMP_2023 UNION SELECT EMPNO FROM EMP_2024;

⚠️ Alerta Mainframe:

  • UNION remove duplicados

  • UNION ALL é mais rápido (menos CPU)

💡 Dica de ouro:

Em batch pesado, pense duas vezes antes de usar UNION sem ALL.


4️⃣ Product (×) — “Multiplicação que dá dor de cabeça”

📌 O que faz
Combina todas as linhas de uma tabela com todas as linhas da outra.

📘 Conceito:

R × S

🧠 Tradução SQL (implícita):

SELECT * FROM EMP, DEPT;

😱 Resultado:

  • 100 funcionários × 10 departamentos = 1000 linhas

💡 Bellacosa comenta:

Cartesian Product é tipo JCL sem COND.
Pode até rodar… mas você vai se arrepender.


5️⃣ Natural Join (⨝) — “O casamento perfeito”

📌 O que faz
Relaciona tabelas usando colunas comuns automaticamente.

📘 Conceito:

EMP ⨝ DEPT

🧠 Tradução DB2:

SELECT * FROM EMP JOIN DEPT ON EMP.DEPTNO = DEPT.DEPTNO;

💡 Easter Egg Mainframe:

Todo JOIN começa como um Product + Selection.
O DB2 só faz isso de forma inteligente pra você.


🧪 Exemplo prático estilo chão de fábrica

🎯 Objetivo:
Listar nome do funcionário e nome do departamento para quem ganha mais de 60k.

🧠 Relational Algebra:

  1. Selection (salário)

  2. Join (EMP + DEPT)

  3. Projection (nome + depto)

🖥️ DB2 SQL:

SELECT E.LASTNAME, D.DEPTNAME FROM EMP E JOIN DEPT D ON E.DEPTNO = D.DEPTNO WHERE E.SALARY > 60000;

💡 O DB2 otimiza isso usando Relational Algebra internamente.


🧙 Primeiros passos para Padawans do Mainframe

Se você está começando:

✅ Entenda Selection vs Projection
✅ Saiba quando usar JOIN vs UNION
✅ Evite Cartesian Product sem intenção
✅ Pense sempre em I/O e CPU
✅ Lembre-se: SQL é declarativo, mas o DB2 pensa em álgebra

📚 Estude:

  • DB2 Explain Plan

  • Access Path

  • Index usage


🏁 Conclusão Bellacosa Style

Relational Algebra não é coisa velha.
É fundação.

Enquanto linguagens vêm e vão,
o DB2 continua rodando batch crítico,
pagando salários,
processando bancos,
e sustentando o mundo corporativo.

E por baixo de tudo isso?

👉 Projection, Selection, Union, Product e Natural Join.

Que a Força (e o z/OS) esteja com você. 🖥️✨


sexta-feira, 2 de outubro de 2009

📋 Checklist de Auditoria SMP/E

 

Bellacosa Mainframe apresenta Auditoria no IBM SMP/E


📋 Checklist de Auditoria SMP/E

O que o auditor pergunta (e o que você precisa provar)

“Auditor não quer opinião.
Quer evidência.”


🧠 Objetivo do checklist

Garantir que:

  • O z/OS está íntegro

  • A manutenção é controlada

  • As mudanças são rastreáveis

  • O ambiente é auditável

👉 SMP/E é prova técnica, não discurso.


🔐 1. Controle de Acesso (RACF / ACF2 / TSS)

✔ CSI protegido (UACC=NONE)
✔ ALTER restrito a sysprogs autorizados
✔ READ para auditoria
✔ Logging ativo
✔ Revisão periódica de acessos

📌 Evidência:

  • LISTDSD

  • Relatórios RACF

  • Perfis ativos


📦 2. Proteção das bibliotecas SMP/E

✔ TARGET libraries protegidas
✔ DLIB libraries protegidas
✔ SMPTLIB, SMPMTS, SMPPTS controlados
✔ Separação TEST / PROD

📌 Evidência:

  • RACF profiles

  • Dataset attributes


🔁 3. Processo RECEIVE / APPLY / ACCEPT

✔ RECEIVE documentado
✔ APPLY CHECK executado
✔ APPLY validado em teste
✔ ACCEPT autorizado formalmente

📌 Evidência:

  • Outputs SMP/E

  • JCL versionado

  • Change records


🚨 4. Gestão de ++HOLD e ++ERROR

✔ HOLDS analisados
✔ Decisão documentada
✔ ERROR tratados com cautela
✔ Mitigações registradas

📌 Evidência:

  • PTF cover letters

  • APARs

  • Decisões de risco


🧩 5. Gestão de USERMOD

✔ USERMOD documentado
✔ Justificativa formal
✔ Controle de APPLY/ACCEPT
✔ Revisão periódica

📌 Evidência:

  • SYSMOD history

  • Documentação técnica


🧪 6. APPLY CHECK (obrigatório)

✔ APPLY CHECK sempre executado
✔ Resultados arquivados
✔ Conflitos analisados

📌 Evidência:

  • Output APPLY CHECK

  • Aprovação formal


🧱 7. Controle de DLIB (baseline)

✔ DLIB atualizado
✔ ACCEPT consciente
✔ Baseline consistente
✔ DLIB protegido

📌 Evidência:

  • CSI

  • Relatórios SMP/E


🔄 8. Capacidade de RESTORE

✔ Processo definido
✔ Histórico preservado
✔ Testes de rollback
✔ Documentação clara

📌 Evidência:

  • JCL RESTORE

  • Registros históricos


🧠 9. Atualização e Segurança

✔ PTFs de segurança aplicados
✔ CVEs avaliados
✔ Backlog controlado
✔ Plano de atualização

📌 Evidência:

  • Relatórios IBM

  • Histórico SMP/E


🧾 10. Evidências e documentação

✔ Outputs armazenados
✔ Logs disponíveis
✔ Histórico preservado
✔ Responsáveis identificados

📌 Evidência:

  • CSI

  • JCL

  • Relatórios


🚨 Red flags para auditor

❌ ALTER irrestrito
❌ ACCEPT sem teste
❌ USERMOD esquecido
❌ CSI sem proteção
❌ Falta de APPLY CHECK

👉 Tudo isso gera não conformidade.


🧠 Curiosidades Bellacosa

  • Auditor confia mais no CSI do que em planilha

  • SMP/E é trilha de auditoria nativa

  • Segurança começa no controle de mudança


🧾 Comentário final – Checklist SMP/E

Quem tem SMP/E bem cuidado
não teme auditoria.

📋 Checklist de Auditoria SMP/E, no estilo Bellacosa Mainframe, pensado para auditoria interna, externa, SOX, PCI, ISO, ou simplesmente para dormir tranquilo

📋💾🛡️

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...