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

Translate

quinta-feira, 6 de junho de 2019

OS ANDARES DE SHOUJO SHUUMATSU RYOKOU E A JORNADA PELOS ÚLTIMOS LOGS DA CIVILIZAÇÃO

 

Bellacosa Mainframe e analise do mundo em Shoujo Shuumatsu Ryokou

☕🖥️🏙️ OPERADOR, A HUMANIDADE CONSTRUIU UM DATACENTER TÃO GRANDE QUE ESQUECEU COMO SAIR DELE

OS ANDARES DE SHOUJO SHUUMATSU RYOKOU E A JORNADA PELOS ÚLTIMOS LOGS DA CIVILIZAÇÃO

Quando assistimos Shoujo Shuumatsu Ryokou pela primeira vez, uma dúvida surge naturalmente.

Afinal:

O que são aqueles andares?

Por que Chito e Yuuri estão sempre subindo?

Por que a cidade parece não ter fim?

Por que existem elevadores gigantescos?

Por que tudo parece empilhado verticalmente?

A resposta simples é:

Não sabemos.

E essa ausência de resposta é justamente uma das maiores genialidades da obra.

Tsukumizu não construiu apenas um cenário.

Ele construiu uma metáfora.

Uma metáfora tão gigantesca que muitos espectadores passam o anime inteiro sem perceber.


Bellacosa Mainframe e os mapas teoricos de Shoujo Shuumatsu Ryokou

O Mundo Não É Um Mundo

Essa é a primeira coisa importante.

Muita gente imagina que Chito e Yuuri estão viajando por um planeta.

Mas a sensação transmitida pela obra é outra.

O cenário parece uma única megacidade infinita.

Uma estrutura vertical.

Camadas sobre camadas.

Andares sobre andares.

Plataformas sobre plataformas.

Como se a humanidade tivesse continuado construindo para cima durante séculos.

Talvez milênios.

Até perder completamente a escala.


A Cidade Como Um Mainframe

☕🖥️

Imagine um datacenter.

Não um datacenter comum.

Imagine todos os datacenters da humanidade fundidos em uma única estrutura.

Agora empilhe novos andares.

E novos andares.

E novos andares.

Durante centenas de anos.

O resultado seria algo próximo da cidade de Shoujo Shuumatsu Ryokou.

A sensação constante é que ninguém mais entende o sistema inteiro.

Existem apenas fragmentos.

Assim como em muitos sistemas legados.

Os criadores morreram.

Os arquitetos desapareceram.

A documentação foi perdida.

Restaram apenas usuários tentando sobreviver dentro de algo que ninguém mais compreende.


Os Andares Inferiores

Os níveis mais baixos possuem uma característica marcante.

São escuros.

Apertados.

Claustrofóbicos.

Cheios de ferrugem.

Cheios de máquinas.

Cheios de tubulações.

São quase subterrâneos.

Lembram os níveis físicos de uma infraestrutura.

É como caminhar dentro do hardware da civilização.

Ali não existe beleza.

Existe funcionamento.

Motores.

Engrenagens.

Energia.

Logística.

Distribuição.

A impressão é que estamos vendo o esqueleto do sistema.


A Camada da Sobrevivência

Nesses níveis inferiores encontramos algo interessante.

Quase tudo está relacionado às necessidades básicas.

Comida.

Água.

Combustível.

Abrigo.

É como a base da Pirâmide de Maslow.

Antes da arte.

Antes da filosofia.

Antes da religião.

Existe a sobrevivência.

Yuuri se sente extremamente confortável nesses ambientes.

Porque ela representa exatamente isso.

A parte da humanidade que sobrevive.


Os Andares Industriais

À medida que a jornada avança encontramos enormes instalações industriais.

Fábricas.

Máquinas automatizadas.

Linhas de produção.

Equipamentos gigantescos.

Mas existe algo estranho.

Quase ninguém sabe mais para que servem.

As máquinas continuam lá.

Mas seus operadores desapareceram.

É uma imagem assustadoramente semelhante a muitas ruínas industriais reais.

Quem visita antigas minas, siderúrgicas ou fábricas abandonadas frequentemente sente a mesma coisa.

Parece impossível que milhares de pessoas tenham vivido ali.

Mas viveram.

E desapareceram.


A Camada da Produção

☕🖥️

Se a cidade fosse um ambiente mainframe:

Os níveis inferiores seriam o hardware.

Os níveis industriais seriam os jobs batch.

Tudo funcionando.

Tudo processando.

Tudo produzindo.

Mas sem usuários.

Sem propósito.

Sem demanda.

Sem significado.

A produção continua.

Mas ninguém sabe por quê.


Os Andares Urbanos

Esses talvez sejam os mais melancólicos.

Ali vemos:

Escolas.

Residências.

Comércio.

Bibliotecas.

Praças.

Locais onde seres humanos viveram.

Esses andares representam a civilização em seu auge.

São os registros arqueológicos da vida cotidiana.

O curioso é que a destruição parece antiga.

Muito antiga.

A ponto de nem mesmo Chito e Yuuri conseguirem imaginar como aquelas pessoas viviam.


A Biblioteca

Um dos locais mais importantes da jornada.

Quando encontramos livros, encontramos memória.

Quando encontramos memória, encontramos humanidade.

Mas a biblioteca também revela uma verdade dolorosa.

Conhecimento não é imortal.

Ele depende de preservação.

Depende de transmissão.

Depende de leitores.

Sem leitores, uma biblioteca é apenas um depósito de papel.

Essa é uma das mensagens mais brutais do anime.


A Camada da Memória

Chito representa essa camada.

Ela registra.

Anota.

Desenha.

Fotografa.

Questiona.

Quer entender.

Ela é a última bibliotecária do mundo.

Mesmo sem perceber.


Os Andares Militares

Conforme avançamos percebemos algo desconfortável.

O mundo de Shoujo Shuumatsu Ryokou está cheio de vestígios militares.

Armas.

Munições.

Tanques.

Instalações defensivas.

Equipamentos bélicos.

Isso sugere que o colapso não foi natural.

Talvez tenha sido resultado de conflitos.

Talvez guerras sucessivas.

Talvez uma guerra tão grande que ninguém sobreviveu para registrar seu nome.


O Que Aconteceu Com a Humanidade?

A obra nunca responde claramente.

E talvez nunca devesse responder.

O mistério é parte da narrativa.

Mas os indícios sugerem:

  • guerra

  • esgotamento de recursos

  • declínio populacional

  • colapso tecnológico gradual

Não parece um único desastre.

Parece uma longa sequência de falhas acumuladas.


Os Elevadores Gigantes

Os elevadores são fascinantes.

Parecem absurdamente desproporcionais.

Como se tivessem sido construídos para movimentar cidades inteiras.

Isso sugere que a estrutura vertical cresceu tanto que a locomoção comum se tornou impossível.

Os elevadores são os antigos sistemas de transporte da civilização.

São os barramentos de comunicação do sistema.

Os links entre camadas.

As conexões entre módulos.


A Ascensão

Existe algo importante.

Chito e Yuuri estão constantemente subindo.

Fisicamente.

Mas também simbolicamente.

Cada novo nível representa uma camada diferente da experiência humana.

É quase uma peregrinação.

Uma arqueologia vertical.


Os Andares Superiores

Quando finalmente alcançamos níveis mais elevados, a atmosfera muda.

Existe mais luz.

Mais espaço.

Mais céu.

Menos peso.

Menos concreto.

Menos escuridão.

Parece que a cidade está ficando para trás.

Como se estivéssemos saindo das profundezas do sistema.


A Jornada Como Uma Pilha Tecnológica

☕🖥️

Sempre imaginei os andares como uma pilha de software.

Camadas inferiores:

Hardware.

Acima:

Sistema operacional.

Acima:

Middleware.

Acima:

Aplicações.

Acima:

Usuários.

Acima:

Propósito.

O anime faz exatamente o caminho inverso.

Ele começa nos restos da infraestrutura.

E sobe em direção às perguntas fundamentais.


O Último Andar

Talvez a maior sacada de Tsukumizu seja que o último andar nunca foi o objetivo real.

Porque o anime não é sobre chegar.

É sobre compreender.

Se Chito e Yuuri encontrassem uma placa dizendo:

"Fim da jornada."

Nada mudaria.

As perguntas continuariam existindo.


O Significado Filosófico da Subida

Em muitas tradições humanas, subir significa:

  • evolução

  • iluminação

  • transcendência

  • descoberta

Mas Shoujo Shuumatsu Ryokou subverte isso.

Quanto mais alto elas sobem, menos respostas encontram.

O topo não contém conhecimento.

O topo contém silêncio.


A Cidade Como a História Humana

Talvez a interpretação mais interessante seja esta.

Cada andar representa uma camada da própria civilização.

As fundações representam sobrevivência.

Os níveis industriais representam produção.

Os níveis urbanos representam sociedade.

As bibliotecas representam memória.

Os níveis militares representam conflito.

Os andares superiores representam reflexão.

E o topo representa a inevitabilidade do fim.


A Leitura Bellacosa Mainframe

☕🖥️🏙️

Depois de assistir várias vezes, cheguei a uma conclusão curiosa.

A cidade de Shoujo Shuumatsu Ryokou não parece uma cidade.

Ela parece um gigantesco dump da humanidade.

Um snapshot congelado de tudo que fomos.

Cada andar é um dataset.

Cada corredor é um log.

Cada biblioteca é um backup.

Cada fábrica é um job batch abandonado.

Cada elevador é um canal de comunicação entre gerações.

E Chito e Yuuri são as últimas operadoras do ambiente.

Não estão tentando restaurar o sistema.

Não estão tentando reiniciar a civilização.

Não estão procurando um administrador.

Estão apenas percorrendo os registros.

Lendo os logs.

Observando os artefatos.

Tentando entender quem foram os usuários que criaram aquele sistema colossal.

No fim das contas, os andares não são apenas lugares.

São camadas da própria condição humana.

E talvez por isso a jornada seja tão fascinante.

Porque ao subir aqueles níveis não estamos explorando uma cidade.

Estamos explorando a nós mesmos.

E a pergunta silenciosa que ecoa em cada elevador continua sendo a mesma:

"Se toda a humanidade fosse reduzida a ruínas, o que sobraria de nós nos andares superiores da memória?"


quarta-feira, 5 de junho de 2019

Yōjo Senki Gekijōban: O Filme Que Mostra o Que Acontece Quando o RCA é Ignorado Até Virar uma Catástrofe Continental

 

Bellacosa Mainframe e o filme Yojo Senki Gekijoban Tanya

☕💣🚀 PADAWAN, O INCIDENTE ESCALOU PARA GUERRA TOTAL!

Yōjo Senki Gekijōban: O Filme Que Mostra o Que Acontece Quando o RCA é Ignorado Até Virar uma Catástrofe Continental


🎬 Ficha Técnica

Título Original: 幼女戦記 劇場版 (Yōjo Senki Gekijōban)

Título Internacional: Saga of Tanya the Evil: The Movie

Baseado na Obra: Yōjo Senki

Autor Original: Carlo Zen

Ilustrações Originais: Shinobu Shinotsuki

Estúdio: NUT

Diretor: Yutaka Uemura

Roteiro: Kenta Ihara

Data de Lançamento: 8 de fevereiro de 2019 (Japão)

Duração: 101 minutos

Classificação Indicativa: 16+

Gêneros:

  • Isekai

  • Militar

  • Guerra

  • Fantasia

  • Drama

  • Estratégia

  • Política

  • Psicológico


🎯 Sinopse

Depois dos eventos da série de TV, Tanya acredita que finalmente poderá colher os frutos de suas vitórias militares.

Mas existe um problema.

Toda vez que Tanya acha que a produção estabilizou...

O universo abre um novo incidente crítico.

A guerra se expande.

Novos inimigos aparecem.

E surge alguém disposta a destruir Tanya a qualquer custo:

Mary Sioux

Uma jovem movida por vingança e fé absoluta.


☕ Bellacosa Mainframe Resume o Filme

Padawan...

Imagine que você acabou de resolver:

  • Um S0C7

  • Um Abend U4038

  • Um DB2 Deadlock

  • Uma falha de spool JES2

Então você registra:

INCIDENTE ENCERRADO

Cinco minutos depois surge:

PRIORIDADE 1 GLOBAL

Foi exatamente isso que aconteceu com Tanya.


🌎 O Contexto da História

O Império venceu várias campanhas.

Mas como acontece em muitos projetos corporativos...

As vitórias criam novos problemas.

A expansão militar gera:

  • Mais inimigos

  • Mais frentes de batalha

  • Mais custos

  • Mais desgaste político

O filme explora exatamente isso.


👧 Tanya Está Mudando?

Essa é uma das partes mais interessantes.

Na série, Tanya era vista principalmente como:

  • Fria

  • Calculista

  • Eficiente

No filme percebemos algo diferente.

Apesar de negar constantemente, Tanya começa a desenvolver:

  • Responsabilidade pelos subordinados

  • Lealdade

  • Liderança

Ela continua pragmática.

Mas não é mais apenas uma sobrevivente.

Está se tornando uma comandante.


👿 Mary Sioux

O Filme Pertence a Ela

Se Tanya representa:

Razão

Mary representa:

Emoção

Se Tanya representa:

Planejamento

Mary representa:

Impulso

Se Tanya representa:

Ciência

Mary representa:


⚔️ A Grande Guerra Filosófica

Muitos espectadores acreditam que o filme é sobre batalhas.

Na realidade:

As batalhas são apenas a superfície.

O verdadeiro conflito é:

Fé versus Racionalidade


🧠 Tanya e Mary São Dois Sistemas Operacionais

Tanya

Funciona como um ambiente IBM Z.

Tudo é:

  • Planejado

  • Testado

  • Monitorado

  • Controlado


Mary

Funciona como um usuário desesperado em produção.

Tudo é:

  • Emocional

  • Impulsivo

  • Imediato

Ela não quer resolver o problema.

Ela quer vingança.


🚀 O Que o Filme Tem de Diferente da Série?

Escala

A série parece uma operação regional.

O filme parece uma guerra mundial.


Qualidade Visual

O estúdio NUT elevou o nível.

As cenas aéreas estão entre as melhores já produzidas para um anime militar.


Ritmo

A série alterna:

  • Política

  • Estratégia

  • Treinamento

O filme praticamente não tira o pé do acelerador.


Profundidade Psicológica

Mary e Tanya funcionam como espelhos invertidos.

Uma mostra o que acontece quando a razão domina tudo.

A outra mostra o que acontece quando a emoção domina tudo.


💣 A Mensagem Oculta Mais Importante

Pouca gente percebe.

O filme inteiro fala sobre:

Consequências

Tanya acredita que:

Se uma decisão é lógica, ela é correta.

O filme questiona isso.

Porque uma decisão lógica ainda pode gerar:

  • Sofrimento

  • Ódio

  • Ressentimento

Mary é literalmente o resultado das decisões de Tanya.


🎭 A Crítica Política

O filme apresenta uma crítica extremamente sofisticada sobre:

Escalada de Conflitos

Nenhum país quer guerra total.

Mas decisões pequenas criam:

  • Reações

  • Contra-reações

  • Retaliações

Até que ninguém mais controla o processo.

É praticamente um incidente corporativo escalado sem governança.


🏢 O Filme Como Metáfora Empresarial

Carlo Zen trabalhou em ambiente corporativo japonês.

Isso aparece em toda a obra.

O Império funciona como uma empresa gigante.

Os generais funcionam como:

  • Diretores

  • Executivos

  • Gestores

As campanhas militares são projetos.

As tropas são recursos.

As perdas são custos operacionais.


☕ O Verdadeiro Vilão Não é Mary

Nem Tanya.

Nem os Aliados.

Nem o Império.

O verdadeiro vilão é:

A Escalada Automática dos Sistemas Humanos

Uma decisão leva a outra.

Uma vingança leva a outra.

Uma guerra leva a outra.

Ninguém consegue parar a máquina.


🎬 Qualidade Técnica

O estúdio NUT entregou uma produção impressionante.

Destaques:

Animação

Excelente.

Efeitos Visuais

Espetaculares.

Direção

Muito cinematográfica.

Trilha Sonora

Uma das melhores da franquia.

Batalhas Aéreas

Absolutamente memoráveis.


🌍 Impacto Cultural

O filme consolidou Yōjo Senki como um dos isekais mais respeitados da década.

Passou a ser referência para:

  • Isekais militares

  • Protagonistas anti-heróis

  • Narrativas estratégicas

  • Obras de guerra com profundidade filosófica

Também reforçou Tanya como uma das personagens femininas mais icônicas dos animes modernos.


🚨 Houve Censura?

Não houve censura significativa.

Mas a obra gerou discussões por:

  • Uniformes inspirados em exércitos europeus históricos.

  • Forte influência visual do período das guerras mundiais.

  • Temas religiosos.

  • Violência militar explícita.

Alguns críticos interpretaram a obra como militarista.

Na prática ocorre o oposto.

O filme mostra constantemente:

  • O custo humano da guerra.

  • O sofrimento dos envolvidos.

  • As consequências da vingança.


🔥 A Maior Lição Bellacosa Mainframe

Padawan...

O filme ensina algo que todo profissional de TI aprende cedo ou tarde.

Você pode resolver o incidente.

Mas se não resolver a causa raiz...

O problema volta.

Mary Sioux é o RCA que nunca foi executado.

Ela é a consequência acumulada de decisões anteriores.

Ela é o ticket encerrado sem análise.

Ela é o erro recorrente que retorna meses depois para derrubar a produção inteira.


🏆 Veredito Bellacosa Mainframe

Yōjo Senki Gekijōban não é apenas um filme de anime.

É uma aula sobre:

  • Consequências

  • Liderança

  • Estratégia

  • Escalada de conflitos

  • Gestão de riscos

  • Natureza humana

Se a série é um incidente crítico em produção...

O filme é o War Room reunido às 3 da manhã enquanto o ambiente inteiro está pegando fogo e todos descobrem que o problema era muito maior do que imaginavam.

Nota Bellacosa Mainframe: ⭐⭐⭐⭐⭐ (10/10)

Nível de Recomendação para Profissionais de Mainframe: EXTREMAMENTE ALTO ☕💣🚀

Porque, assim como em TI, a maior batalha raramente é contra o problema visível.

É contra as consequências invisíveis das decisões tomadas muito tempo atrás.


terça-feira, 4 de junho de 2019

☕💥 A Jornada do Padawan COBOL – Parte 6 Desvendando o Universo dos CALLs no Mainframe

 

Bellacosa Mainframe apresenta o CALL em Cobol Parte VI

☕💥 A Jornada do Padawan COBOL – Parte 6

Desvendando o Universo dos CALLs no Mainframe

CICS LINK, XCTL, COMMAREA, Channels, Containers, APIs REST, MQ, Java e os Segredos dos Arquitetos da Nova República IBM Z

Ou como descobrir que um programa COBOL escrito em 1987 pode responder uma API REST em menos tempo do que muita startup consegue carregar um framework

Por Vagner Bellacosa – Bellacosa Mainframe


O dia em que o Padawan descobre que CALL não é a única forma de chamar programas

Até agora aprendemos:

✅ CALL estático

✅ CALL dinâmico

✅ Binder

✅ RENT

✅ CEEDUMP

✅ LPA

✅ LE

Mas um dia o Padawan entra em um ambiente CICS.

Abre um programa.

E encontra isto:

EXEC CICS LINK
     PROGRAM('PGM0001')
     COMMAREA(WS-COMM)
END-EXEC

E pensa:

Ué...

Cadê o CALL?


O universo paralelo do CICS

Em Batch usamos:

CALL 'VALIDA'

No CICS temos:

LINK

XCTL

START

RETURN

LOAD

DELETE


LINK

É praticamente o CALL do CICS.

Exemplo

EXEC CICS LINK
     PROGRAM('CPFVAL')
     COMMAREA(WS-COMMAREA)
END-EXEC

Visualmente


CLIENTE01


↓

LINK


↓

CPFVAL


↓

RETORNA


↓

CLIENTE01



Programa chamador continua vivo.

Igual ao CALL.


Vantagens

Retorna controle

Compartilha contexto

Excelente modularização

Pode executar milhares de vezes


XCTL

Agora a coisa muda.


Exemplo

EXEC CICS XCTL
     PROGRAM('MENU0001')
END-EXEC

Visualmente


TELA01

↓

XCTL

↓

MENU0001



TELA01 morre




Não retorna.

Nunca.


É quase um:

exit();

Quando usar?

Troca definitiva.

Menu.

Workflow.

Navegação.


LINK versus XCTL

CaracterísticaLINKXCTL
RetornaSimNão
Consome stackSimNão
PerformanceBoaExcelente
WorkflowMédioIdeal

COMMAREA

A rainha do CICS.


Ela transporta dados.


Exemplo

01 WS-COMM.

05 WS-CPF PIC X(11).

05 WS-NOME PIC X(30).

05 WS-RC PIC 99.

LINK

EXEC CICS LINK
PROGRAM('CPFVAL')
COMMAREA(WS-COMM)
LENGTH(100)
END-EXEC

Subprograma

DFHCOMMAREA.

O limite

64 KB


Padawan feliz.

Arquiteto preocupado.


Channels e Containers

IBM resolveu.


Nasce o conceito:

CHANNEL

CONTAINER


Praticamente JSON.

Mas IBM.


Exemplo

EXEC CICS PUT CONTAINER
CONTAINER('CLIENTE')
CHANNEL('CANAL1')
FROM(WS-CLIENTE)
END-EXEC

Ler

EXEC CICS GET CONTAINER
CONTAINER('CLIENTE')
CHANNEL('CANAL1')
INTO(WS-CLIENTE)
END-EXEC

Vantagens

Gigabytes.

Múltiplos objetos.

Flexível.


MQ

Padawan evolui.

Conhece IBM MQ.


Exemplo

CALL 'MQPUT'

Visualmente



COBOL

↓

MQPUT


↓

QUEUE


↓

JAVA


↓

API




Assíncrono.

Bonito.

Elegante.

IBM aprova.


APIs REST

O grande sonho.


"Posso expor COBOL como API?"

Sim.


Muito.


zOS Connect

O mago moderno.


Ele converte

REST

em

COBOL


Visualmente



POST /cliente



↓

zOS Connect



↓

COBOL



↓

DB2



↓

JSON




Cliente pensa:

Microserviço.


Realidade:

COBOL 1989.


Exemplo

API

{
"id":123
}

COBOL

01 WS-ID PIC 9(9).

Java

Sim.

Java conversa.


JNI.

LE.

DLL.


Exemplo

CobolService.executar();

COBOL

CALL 'PROCESSA'

Python

Sim.

Também.


API REST.

MQ.

Kafka.


Tudo possível.


Metal C

Território avançado.


Muito usado.

IBM Z.

Baixa latência.


zIIP

Arquiteto sorri.

Financeiro também.


Pode descarregar CPU.


Exemplo

JSON parsing.

REST.

MQ.

DB2 DRDA.


SMF 110

O espião do CICS.


Captura:

Tempo

CPU

LINK

XCTL

DB2

MQ


APA

Application Performance Analyzer


Mostra:

Hotspots

CALLs

Loops

CPU


Strobe

Ferramenta lendária.


Veteranos adoram.


Exemplo real

Programa

1000 LINKs

Tempo

5 segundos

Após otimização

400 ms


Truques Bellacosa

Dica 1

LINK

Retorna.


Dica 2

XCTL

Não retorna.


Dica 3

Channels > COMMAREA

Projetos novos.


Dica 4

MQ desacopla.


Dica 5

REST não mata COBOL.

REST promove COBOL.


Easter Egg Mainframe

Muitos bancos possuem.

Programa.

APIGEN01

Dentro.

EXEC CICS LINK

PROGRAM('LEG1987')

END-EXEC

API moderna.

Swagger.

OAuth.

OpenAPI.

JWT.

Kubernetes.

No final...

Executa.

MOVE SALDO TO WS-SALDO

Escrito em 1987.

Funciona.

Processa bilhões.

Ninguém reclama.


Checklist Jedi da Integração

✅ Preferir LINK

✅ XCTL para troca definitiva

✅ Evitar COMMAREA grande

✅ Usar Channels

✅ Monitorar SMF110

✅ Medir CPU

✅ Utilizar MQ

✅ Explorar zOS Connect

✅ Aproveitar zIIP

✅ Testar latência

✅ Documentar APIs


A Filosofia Jedi do CALL – Parte 6

O Padawan iniciante acredita:

COBOL só conversa com COBOL.

O desenvolvedor intermediário pensa:

COBOL pode consumir APIs.

O Arquiteto IBM Z entende:

COBOL conversa com qualquer tecnologia capaz de trocar bytes, mensagens, estruturas, JSON, XML ou eventos.

E é exatamente por isso que alguns dos sistemas mais modernos do planeta possuem uma arquitetura semelhante a esta:

Mobile

↓

API Gateway

↓

REST

↓

zOS Connect

↓

CICS LINK

↓

COBOL

↓

DB2

↓

MQ

↓

Analytics

↓

IA

Enquanto o cliente enxerga apenas um botão escrito "Consultar Saldo", um pequeno exército de programas COBOL, escritos ao longo de quarenta anos, continua executando silenciosamente milhões de chamadas por segundo, provando mais uma vez que, no Mainframe, a Força nunca esteve na moda da tecnologia, mas na sua capacidade de durar décadas sem perder desempenho, segurança e confiabilidade.


Próxima aventura do Padawan COBOL – Parte 7

Assembler, BALR, BASSM, PC-Bit, SVC, LE Internals, SRBs, TCBs, Cross Memory Services, zIIP, HiperDispatch e os segredos obscuros dos Sysprogs Jedi do IBM Z.


segunda-feira, 3 de junho de 2019

🐒 Detetive Chimp e o Mistério do Banco de Dados que Jurava Ser Consistente

 

Bellacosa Mainframe apresenta DBMS

☕ Um Café no Bellacosa Mainframe

🐒 Detetive Chimp e o Mistério do Banco de Dados que Jurava Ser Consistente

DBMS, modelagem ER, SQL, normalização, índices, ACID, locks, concorrência, COMMIT, ROLLBACK e recovery investigados por um detetive que sabe que os dados sempre deixam pistas



Há uma coisa que aprendi observando sistemas durante muito tempo: quando um programa diz que “não fez nada”, comece procurando o log.

Quando um usuário afirma que “clicou apenas uma vez”, procure duas transações.

Quando uma aplicação garante que “ninguém alterou aquele registro”, procure um UPDATE.

E quando um banco de dados afirma que está tudo consistente...

...chame o Detetive Chimp.

Nosso investigador chega ao data center usando seu tradicional chapéu, examina o terminal 3270 e encontra a primeira pista:

03:17:00.001  TRANSACTION T1
03:17:00.003  TRANSACTION T2

Dois milissegundos.

Uma diferença ridiculamente pequena para um humano.

Uma eternidade para um computador.

Sobre a mesa há ainda cinco folhas intituladas DBMS Quick Revision Sheet. Elas falam de DBMS, ER Model, SQL, normalização, ACID, transações, concorrência e índices.

Chimp olha para aquilo.

— Interessante.

Acende seu cachimbo imaginário.

— Temos vários suspeitos.

E assim começa nosso caso.



🕵️ CAPÍTULO 1 — O cadáver era um banco de dados

Antes de investigar o crime precisamos entender a vítima.

DBMS significa:

Database Management System — Sistema Gerenciador de Banco de Dados.

Para o iniciante, é tentador pensar:

banco de dados = lugar onde guardamos informações.

Não está errado.

Mas é tão incompleto quanto dizer que um aeroporto é um lugar onde estacionamos aviões.

Um DBMS precisa armazenar, organizar, localizar, proteger, compartilhar, alterar e recuperar dados, além de arbitrar o que acontece quando diversos usuários tentam mexer neles simultaneamente.

Imagine:

              USUÁRIOS
                 │
                 ▼
          ┌─────────────┐
          │ APLICAÇÕES  │
          └──────┬──────┘
                 │
                 ▼
          ┌─────────────┐
          │    DBMS     │
          └──────┬──────┘
                 │
                 ▼
          ┌─────────────┐
          │    DADOS    │
          └─────────────┘

O DBMS fica entre as aplicações e os dados.

Mas Detetive Chimp imediatamente acrescentaria vários departamentos escondidos naquele retângulo:

                  DBMS
                    │
       ┌────────────┼─────────────┐
       │            │             │
     SQL        Segurança     Transações
       │            │             │
   Optimizer     Controle      Logging
       │                          │
   Access Path                  Recovery
       │
     Storage

É uma pequena cidade funcionando atrás de uma palavra de quatro letras.



🐒 CAPÍTULO 2 — O primeiro suspeito: SQL

Chimp encontra uma consulta:

SELECT NOME, LIMITE
FROM CLIENTE
WHERE CPF = :WS-CPF;

— Parece inocente.

O programador COBOL iniciante concorda.

Chimp continua:

— É exatamente por isso que devemos investigá-la.

SQL é uma linguagem declarativa.

Quando escrevemos:

SELECT NOME
FROM CLIENTE
WHERE CPF = '123';

estamos essencialmente dizendo:

“Db2, quero o nome do cliente cujo CPF é 123.”

Não estamos necessariamente dizendo:

“vá até determinado cilindro, encontre determinada página, leia o registro número 427...”

O DBMS precisa descobrir uma estratégia eficiente.

Simplificando:

SQL
 │
 ▼
PARSER
 │
 ▼
OPTIMIZER
 │
 ▼
ACCESS PATH
 │
 ├── INDEX?
 │
 ├── SCAN?
 │
 └── JOIN?
 │
 ▼
DADOS

Aqui aparece um personagem que aquelas folhas introdutórias mal conseguem explorar: o optimizer.

Ele analisa possibilidades para executar a consulta.

Portanto, duas consultas SQL que produzem resultados semelhantes podem apresentar comportamentos de performance radicalmente diferentes.

Saber escrever SQL é uma habilidade.

Entender como o banco chega aos dados é outra.



🧩 CAPÍTULO 3 — Antes do banco havia o mundo real

Chimp desenha três objetos no quadro:

CLIENTE
CONTA
TRANSAÇÃO

Antes de existir tabela, índice ou SELECT, alguém precisou transformar uma realidade de negócio em um modelo de dados.

É aí que entra o ER Model — Entity Relationship Model.

Temos três conceitos fundamentais:

ENTITY
ATTRIBUTE
RELATIONSHIP

Uma entidade pode ser:

CLIENTE

Seus atributos:

ID_CLIENTE
CPF
NOME
DATA_NASCIMENTO

Outra entidade:

CONTA

Com:

ID_CONTA
AGENCIA
SALDO

Existe então uma relação:

CLIENTE ───── POSSUI ───── CONTA

Um cliente pode possuir várias contas.

Podemos representar:

CLIENTE 1 ───────── N CONTA

Chimp bate o cachimbo no quadro.

— Eis uma pista importante: muitos crimes de dados começam antes de existir código.

Um modelo ruim acaba contaminando tabelas, programas, APIs, relatórios e integrações.



🔑 CAPÍTULO 4 — O caso das chaves desaparecidas

A apostila apresenta:

Super Key, Candidate Key, Primary Key, Alternate Key e Foreign Key.

Parece matéria de prova.

Não é.

Imagine:

CLIENTE
-----------------------
ID_CLIENTE
CPF
NOME

Escolhemos:

ID_CLIENTE → PRIMARY KEY

Outra tabela:

CONTA
-----------------------
ID_CONTA
ID_CLIENTE
SALDO

Aqui:

ID_CONTA   → PRIMARY KEY
ID_CLIENTE → FOREIGN KEY

Agora existe uma relação:

CLIENTE
 ID_CLIENTE
     │
     │
     ▼
CONTA
 ID_CLIENTE

A chave estrangeira representa uma relação entre os dados.

Sem integridade adequada poderíamos encontrar:

CONTA 999999
CLIENTE 777777

mas descobrir que:

CLIENTE 777777

não existe.

Chimp imediatamente pergunta:

— Então de quem é essa conta?

Silêncio no data center.

Temos um órfão de dados.


🧹 CAPÍTULO 5 — Normalização: arrumando a cena do crime

Agora encontramos uma tabela criada por alguém numa sexta-feira às 17:58:

PEDIDO
---------------------------------
CLIENTE
ENDERECO
PRODUTO1
PRECO1
PRODUTO2
PRECO2
PRODUTO3
PRECO3

Chimp olha horrorizado.

— Quem fez isso?

Ninguém responde.

Naturalmente.

A normalização procura organizar estruturas de dados reduzindo redundâncias e dependências problemáticas.

A apostila percorre:

1NF
 ↓
2NF
 ↓
3NF
 ↓
BCNF

Uma modelagem mais organizada poderia resultar em:

CLIENTE
   │
   │
   ▼
PEDIDO
   │
   │
   ▼
ITEM_PEDIDO
   │
   │
   ▼
PRODUTO

Isso reduz problemas clássicos de:

INSERT
UPDATE
DELETE

Imagine armazenarmos o endereço do cliente repetidamente em 30 mil pedidos.

Ele muda de endereço.

Quantas ocorrências precisam ser alteradas?

Esse tipo de redundância é terreno fértil para inconsistência.

Mas Chimp deixa uma observação importante no relatório:

Normalização é ferramenta de engenharia, não religião.

Projetos reais também consideram performance, padrões de acesso, volume, frequência de atualização e características específicas do workload.


🏦 CAPÍTULO 6 — Finalmente encontramos o dinheiro

Agora o caso fica sério.

Temos:

CONTA A = R$ 1.000
CONTA B = R$   500

Queremos transferir:

R$ 100

Conceitualmente:

A = A - 100
B = B + 100

Depois:

A = 900
B = 600

Perfeito.

Um programa COBOL poderia executar uma sequência equivalente a:

LER A
SUBTRAIR 100
UPDATE A

LER B
SOMAR 100
UPDATE B

Mas Chimp coloca uma banana exatamente entre os dois updates.

UPDATE A
   │
   ▼
A = 900

💥 ABEND S0C7

UPDATE B
   │
   X

Agora temos:

A = 900
B = 500

Os R$100 desapareceram.

Não foram transferidos.

Foram sacrificados aos deuses do processamento de dados.

É aqui que surge um dos conceitos mais importantes de toda a apostila:

TRANSACTION


🔄 CAPÍTULO 7 — A transação é o verdadeiro suspeito

Uma transação representa uma unidade lógica de trabalho.

Queremos que:

DEBITAR A
CREDITAR B

sejam tratados como parte de uma operação coerente.

Conceitualmente:

┌──── UNIT OF WORK ─────┐
│                       │
│ UPDATE A              │
│ UPDATE B              │
│                       │
│ COMMIT                │
│                       │
└───────────────────────┘

Se tudo funcionar:

COMMIT

Se alguma coisa der errado antes da confirmação apropriada:

ROLLBACK

Chimp sorri.

— Agora encontramos o mecanismo que impede o dinheiro de desaparecer.

Mas ainda não resolvemos o crime.

Porque existem outros usuários.


🧪 CAPÍTULO 8 — ACID entra para interrogatório

Na parede aparecem quatro letras:

A C I D

Não é uma banda psicodélica de mainframe.

São propriedades fundamentais das transações.

A — Atomicity

Tudo ou nada.

A - 100
B + 100

Não queremos:

A - 100 ✓
B + 100 ✗

A operação lógica deve ser tratada atomicamente.


C — Consistency

Antes:

A = 1000
B = 500

TOTAL = 1500

Depois:

A = 900
B = 600

TOTAL = 1500

O sistema deve preservar as regras de consistência definidas para os dados.

Mas cuidado: consistência não significa que o DBMS magicamente conhece todas as regras do negócio.

Se uma regra diz:

clientes menores de determinada idade não podem contratar determinado produto,

alguém precisa expressar e implementar essa regra adequadamente.

O banco não consulta uma bola de cristal.


I — Isolation

Chimp finalmente encontra a pista decisiva.

Temos limite disponível:

R$ 1.000

Duas compras chegam:

T1 → R$700
T2 → R$600

Quase simultaneamente.

T1 pergunta:

LIMITE?

Resposta:

1000

T2 pergunta:

LIMITE?

Resposta:

1000

T1 pensa:

700 < 1000

APROVADO

T2 pensa:

600 < 1000

APROVADO

Resultado:

700 + 600 = 1300

Oops.

É por isso que concorrência não é detalhe acadêmico.


D — Durability

Depois que uma transação é confirmada, esperamos que sua alteração sobreviva a falhas previstas pelo mecanismo transacional.

Não queremos:

COMMIT

e cinco minutos depois:

“Desculpe, perdemos sua transferência.”

Logging e recovery existem justamente porque computadores, discos, processos e aplicações podem falhar.


🔐 CAPÍTULO 9 — As impressões digitais chamadas LOCKS

A apostila apresenta dois conceitos:

S LOCK
X LOCK

Simplificando didaticamente:

Shared Lock permite compartilhamento compatível para determinados acessos de leitura.

Exclusive Lock protege recursos que estão sendo modificados contra acessos incompatíveis.

Chimp desenha:

TRANSACTION A
     │
     ▼
   RESOURCE
     ▲
     │
TRANSACTION B

Agora temos concorrência.

Um sistema empresarial não pode simplesmente dizer:

“Só uma pessoa pode usar o banco por vez.”

Imagine um banco com milhões de clientes operando assim.

CLIENTE 1 → terminou?
CLIENTE 2 → pode entrar.
CLIENTE 3 → espere.
CLIENTE 4 → senha 493827.

😂

Precisamos permitir enorme paralelismo enquanto preservamos integridade.

Esse é um dos grandes desafios do DBMS.


💀 CAPÍTULO 10 — Deadlock: encontramos dois cadáveres

Chimp encontra:

T1 possui LOCK A
T2 possui LOCK B

Depois:

T1 precisa de B
T2 precisa de A

Visualmente:

       espera
   ┌──────────────►
   │
  T1              T2
   ▲               │
   ◄───────────────┘
       espera

Parabéns.

Criamos um deadlock.

T1 espera T2.

T2 espera T1.

Nenhum resolve voluntariamente a situação.

O DBMS precisa detectar e solucionar esse tipo de conflito, normalmente escolhendo uma transação como vítima para quebrar o ciclo.

E aí o programador descobre uma lição maravilhosa:

ROLLBACK não significa necessariamente que o DBMS está quebrado.

Às vezes o rollback é justamente o mecanismo impedindo que o sistema permaneça preso.


🚦 CAPÍTULO 11 — Isolation Level: quanta privacidade você quer?

Aqui começamos a sair definitivamente da apostila de revisão e entrar na engenharia.

No Db2 encontramos níveis como:

UR
CS
RS
RR

Conceitualmente podemos imaginar um controle:

MAIS ISOLAMENTO
      ▲
      │
      │ proteção
      │
      │
      │ concorrência
      ▼
MENOS ISOLAMENTO

Isso não significa simplesmente:

“mais isolamento é melhor.”

Um sistema transacional gigantesco precisa equilibrar:

integridade
concorrência
latência
throughput
CPU
locks
tempo de resposta

O programador que escolhe mecanismos de isolamento sem entender o workload está fazendo engenharia com os olhos vendados.


💾 CAPÍTULO 12 — SAVEPOINT, a máquina do tempo

Chimp encontra:

SAVEPOINT SP1

— Finalmente uma testemunha inteligente.

Imagine:

PASSO A
PASSO B
PASSO C

SAVEPOINT SP1

PASSO D
PASSO E
PASSO F

O passo F falha.

Dependendo da situação e do desenho da aplicação, podemos voltar a um savepoint apropriado:

A ✓
B ✓
C ✓

--- SP1 ---

D ↶
E ↶
F ↶

É quase um:

SAVE GAME

do processamento transacional.

Só não diga isso durante entrevista para DBA.

Ou diga.

Talvez ele goste.


🔎 CAPÍTULO 13 — O índice não matou ninguém... provavelmente

Chimp encontra uma tabela gigantesca:

CLIENTE
100.000.000 ROWS

Consulta:

SELECT NOME
FROM CLIENTE
WHERE CPF = :CPF;

Como encontramos aquele CPF?

Sem uma estrutura de acesso adequada, poderíamos ter um trabalho enorme de procura.

Com um índice apropriado:

CPF
 │
 ▼
INDEX
 │
 ▼
LOCALIZAÇÃO
 │
 ▼
DADO

Muito melhor.

Então surge a ideia perigosa:

“Vamos criar índice para tudo!”

Chimp imediatamente fecha o notebook.

— Não.

Índices também possuem custo.

Precisam ser armazenados e mantidos quando dados são inseridos, removidos ou alterados.

Temos novamente um compromisso:

MAIS ÍNDICES
     │
     ├── potencial de melhores acessos
     │
     └── maior custo de manutenção/espaço

Banco de dados é uma sucessão de decisões de engenharia.


🧠 CAPÍTULO 14 — O verdadeiro cérebro estava escondido: Optimizer

Finalmente encontramos o personagem que faltava nas folhas.

O programador escreve:

SELECT ...
FROM CLIENTE C
JOIN CONTA A
  ON C.ID_CLIENTE = A.ID_CLIENTE
WHERE C.CPF = :CPF;

O DBMS precisa descobrir como executar aquilo.

Conceitualmente:

SQL
 │
 ▼
OPTIMIZER
 │
 ├── estatísticas
 ├── cardinalidade
 ├── índices
 ├── predicates
 ├── joins
 └── estimativas
 │
 ▼
ACCESS PATH

É por isso que:

SQL correto

não implica necessariamente:

SQL eficiente

Ele pode retornar exatamente os dados solicitados e ainda assim fazer um trabalho absurdamente maior do que o necessário.

Chimp escreve no relatório:

O suspeito tinha álibi funcional, mas não tinha álibi de performance.


🏭 CAPÍTULO 15 — Agora tragam CICS, COBOL e Db2

Chegamos ao Bellacosa Mainframe.

Coloque tudo junto:

                    CLIENTE
                       │
                       ▼
                ┌────────────┐
                │    CICS    │
                └─────┬──────┘
                      │
                      ▼
                ┌────────────┐
                │   COBOL    │
                └─────┬──────┘
                      │
                     SQL
                      │
                      ▼
                ┌────────────┐
                │Db2 for z/OS│
                └─────┬──────┘
                      │
            ┌─────────┴─────────┐
            ▼                   ▼
          INDEX                DATA

Agora multiplique por milhares de transações.

T000001
T000002
T000003
...
T999999

Todas querem:

READ
INSERT
UPDATE
DELETE
COMMIT

O problema deixa de ser:

“Como salvo um cliente?”

Passa a ser:

Como milhares de operações podem alterar um universo compartilhado simultaneamente sem destruir sua coerência?

Essa pergunta explica boa parte da existência dos mecanismos transacionais.


💳 CAPÍTULO 16 — Chimp investiga uma compra de cartão

Compra:

R$100

A mensagem chega ao sistema.

             COMPRA
                │
                ▼
              CICS
                │
                ▼
              COBOL
                │
       ┌────────┼─────────┐
       ▼        ▼         ▼
    CLIENTE   CARTÃO    PRODUTO
       │        │         │
       └────────┼─────────┘
                ▼
              LIMITE
                │
                ▼
             FRAUDE?
                │
                ▼
          AUTORIZAÇÃO
                │
         ┌──────┴──────┐
         ▼             ▼
      APPROVE        DECLINE

Parece simples.

Agora chegam duas compras:

03:17:00.001 → R$700
03:17:00.003 → R$600

Limite:

R$1000

Eis o easter egg.

03:17.

Chimp olha para o relógio.

— Sempre é 03:17 quando algo interessante acontece no mainframe.

Dois milissegundos separam um fluxo trivial de um excelente caso de concorrência.

Agora fazem sentido:

ACID
LOCK
ISOLATION
COMMIT
ROLLBACK
LOG
RECOVERY

Cada palavra da apostila ganhou consequências financeiras.


🧯 CAPÍTULO 17 — “Mas funcionou no teste!”

Chimp fecha os olhos.

Essa é uma das frases favoritas do culpado.

No teste:

1 usuário
1 transação
100 registros

Produção:

10.000 usuários
milhares de transações
milhões/bilhões de registros
concorrência
timeout
deadlock
falhas
rede
batch
online
APIs

O programa:

SELECT
UPDATE
COMMIT

funciona maravilhosamente sozinho.

Coloque centenas de instâncias disputando os mesmos recursos e você descobrirá características que nunca apareceram no teste simplificado.

É por isso que engenharia transacional exige pensar não apenas:

MEU PROGRAMA

mas:

              SISTEMA
                 │
     ┌───────────┼───────────┐
     ▼           ▼           ▼
  ONLINE       BATCH        APIs
     │           │           │
     └───────────┼───────────┘
                 ▼
                DB2

Seu programa nunca está realmente sozinho.


🐒 CAPÍTULO 18 — Detetive Chimp apresenta os suspeitos

Depois de horas investigando, Chimp monta o quadro:

              O CASO DBMS
                   │
       ┌───────────┼────────────┐
       ▼           ▼            ▼
    MODELAGEM     SQL       TRANSAÇÃO
       │           │            │
       ▼           ▼            ▼
      ER       OPTIMIZER       ACID
       │           │            │
       ▼           ▼            ▼
     KEYS       INDEXES      LOCKING
       │                        │
       ▼                        ▼
 NORMALIZATION              ISOLATION
                                │
                       ┌────────┴────────┐
                       ▼                 ▼
                    COMMIT           ROLLBACK
                       │                 │
                       └────────┬────────┘
                                ▼
                              LOG
                                │
                                ▼
                            RECOVERY

Nenhum deles isoladamente matou o banco.

O problema estava na interação entre todos eles.


🎓 CAPÍTULO 19 — A trilha para o programador COBOL iniciante

Se eu transformasse aquelas cinco folhas em uma trilha de estudo, seguiria esta ordem:

  1. Entenda DBMS e a diferença entre dado, banco e gerenciador. Depois modele entidades, atributos, relacionamentos, cardinalidades e chaves. Aprenda SQL básico — SELECT, INSERT, UPDATE, DELETE e JOIN — e só então entre em normalização e integridade referencial.

  2. Em seguida estude transações profundamente: Unit of Work, COMMIT, ROLLBACK, SAVEPOINT e ACID. Depois avance para concorrência, locks, isolamento, timeout e deadlock. Finalmente estude índices, optimizer, access paths, logging, backup/recovery e performance.

  3. Só então faça o exercício realmente divertido: implemente mentalmente tudo isso em COBOL + CICS + Db2, primeiro com um usuário e depois imaginando 10.000 usuários concorrentes.

Nesse ponto o estudante deixa de decorar definições e começa a pensar como engenheiro.


☕ EPÍLOGO — O banco nunca mentiu

O sol começa a nascer sobre o data center.

Chimp termina seu café.

O jovem programador pergunta:

— Então quem era o assassino?

Chimp coloca o chapéu.

— Ninguém.

— Como assim?

— O banco fez exatamente aquilo que mandaram fazer.

Silêncio.

Essa talvez seja uma das maiores lições de sistemas.

Computadores são extraordinariamente obedientes.

Se você modelar mal, eles executarão rapidamente um modelo ruim.

Se escrever uma transação incorreta, executarão corretamente a transação incorreta.

Se criar SQL ineficiente, poderão produzir exatamente o resultado esperado — lentamente.

Se esquecer concorrência, o sistema poderá funcionar perfeitamente durante meses...

...até duas transações chegarem juntas.

03:17:00.001
03:17:00.003

E então você descobrirá que dois milissegundos podem revelar um erro arquitetural escondido durante anos.

Chimp deixa sobre a mesa as cinco folhas de revisão.

No começo da investigação elas diziam:

DBMS
ER MODEL
NORMALIZATION
SQL
ACID
TRANSACTION
INDEX

Agora significam:

REALIDADE
   ↓
MODELAGEM
   ↓
DADOS
   ↓
TRANSAÇÕES
   ↓
CONCORRÊNCIA
   ↓
INTEGRIDADE
   ↓
RECUPERAÇÃO
   ↓
PERFORMANCE
   ↓
NEGÓCIO

É essa a diferença entre decorar banco de dados para uma prova e compreender por que bancos, seguradoras, companhias aéreas, governos e sistemas de cartões investem tanto em engenharia transacional.

Aquelas quatro letras — ACID — parecem matéria de apostila.

Um COMMIT parece apenas um comando.

Um LOCK parece detalhe técnico.

Um índice parece somente uma maneira de procurar dados mais rapidamente.

Até o dia em que você percebe que do outro lado daqueles registros existem dinheiro, passagens, pedidos, pagamentos, estoques, contratos e pessoas.

Detetive Chimp abre a porta.

Antes de sair, olha novamente para o terminal.

READY

Caso encerrado?

Claro que não.

Em mainframe sempre existe outro JOB esperando na fila.

E provavelmente existe algum programador jurando:

“Mas eu não alterei nada...”

Chimp sorri.

Procure o log. 🐒🔎☕



sábado, 25 de maio de 2019

Sempre um Isekai : O Isekai e o Contrato Social Quebrado – Parte IV

 

Bellacosa Mainframe e a quebra do contrato social parte iv

☕ Um Café no Bellacosa Mainframe

O Isekai e o Contrato Social Quebrado – Parte IV

Quando um Programador COBOL Descobre que o Truck-kun Nunca Foi um Caminhão... Mas um Botão de CANCEL JOB para uma Geração Inteira

Existe um personagem que aparece em centenas de animes.

Ele nunca fala.

Nunca recebe desenvolvimento.

Nunca possui um arco dramático.

Mesmo assim...

É um dos personagens mais famosos da cultura pop japonesa.

Truck-kun.

O caminhão mais eficiente da história dos animes.

Bastam alguns segundos.

Um impacto.

Tela branca.

Pronto.

Começa outro mundo.

Durante anos tratamos isso como uma enorme piada.

Hoje...

Já não tenho tanta certeza de que seja apenas humor.


O Caminhão Nunca Foi o Protagonista

Pense comigo.

Por que justamente um caminhão?

Por que não um raio?

Um terremoto?

Uma doença?

Uma explosão?

Porque o caminhão representa algo muito específico.

A rotina.

O deslocamento.

O trajeto diário.

Ele aparece justamente quando o protagonista está...

Voltando do trabalho.

Saindo da escola.

Atravessando uma rua.

Fazendo exatamente aquilo que repetiu centenas de vezes.

O Truck-kun nasce da repetição.


O Loop Infinito

Existe um detalhe curioso.

Quase todos os protagonistas vivem uma rotina absolutamente comum.

Acordar.

Estudar.

Trabalhar.

Dormir.

Repetir.

Como um JOB batch.

//VIDA     JOB
//STEP01   EXEC PGM=ACORDAR
//STEP02   EXEC PGM=TRABALHAR
//STEP03   EXEC PGM=PAGAR-CONTAS
//STEP04   EXEC PGM=DORMIR

No dia seguinte...

SUBMIT novamente.

Depois novamente.

Depois novamente.

Até o operador esquecer que existe alguém executando aquele JOB.


O Ser Humano Não Nasceu para Ser Apenas Produtivo

Vivemos numa época curiosa.

Tudo precisa gerar resultado.

Ler precisa gerar produtividade.

Viajar precisa render conteúdo.

Dormir precisa melhorar desempenho.

Academia precisa aumentar performance.

Até descansar virou obrigação.

Se você relaxa...

Logo aparece alguém dizendo que poderia estar estudando uma nova tecnologia.

Aprendendo outra linguagem.

Obtendo mais uma certificação.

Otimizando sua carreira.

É como se a CPU humana nunca pudesse entrar em IDLE.


Burnout

O ABEND da Alma

Programadores conhecem bem a palavra ABEND.

Algo falhou.

O programa simplesmente não consegue continuar.

O burnout parece exatamente isso.

Você continua comparecendo ao trabalho.

Continua respondendo e-mails.

Continua participando de reuniões.

Mas internamente...

O sistema já entrou em falha crítica.

Não existe dump que resolva.

Não existe PTF.

Não existe IPL emocional que devolva imediatamente a energia perdida.


O Mundo Nunca Desliga

No passado...

Quando alguém saía do escritório...

O trabalho permanecia na empresa.

Hoje...

O escritório cabe no bolso.

WhatsApp.

Teams.

Slack.

E-mail.

VPN.

Notebook.

A empresa pode atravessar a porta da sua casa sem pedir licença.

O expediente termina.

Mas a disponibilidade continua.


O Truck-kun é um RESET

Talvez seja justamente isso que ele simbolize.

Não a morte.

Mas o fim do loop.

Fim da repetição.

Fim da cobrança.

Fim do relógio.

Fim da agenda.

Fim da reunião marcada para segunda-feira às oito.

O protagonista não sorri porque morreu.

Ele sorri porque, pela primeira vez em muito tempo...

Não precisa voltar ao escritório.


A Primeira Coisa Que Todo Herói Faz

Repare.

Quando acorda no outro mundo...

Quase ninguém pergunta.

"Meu chefe conseguiu terminar aquele projeto?"

"Será que responderam meus e-mails?"

"Quem assumiu minhas tarefas?"

Ninguém lembra da planilha.

Da apresentação.

Do relatório.

Do KPI.

Da meta.

Curiosamente...

Todos esses problemas desaparecem imediatamente.


A Liberdade Tem um Rosto

Existe outra curiosidade.

Os protagonistas caminham.

Muito.

Viajam semanas.

Dormem em acampamentos.

Conhecem cidades.

Conversam com desconhecidos.

Descobrem florestas.

Montanhas.

Ruínas.

Hoje isso parece um luxo.

Quantas pessoas conseguem simplesmente desaparecer por uma semana sem olhar o celular?


O Tempo Virou Artigo de Luxo

Talvez o recurso mais raro do século XXI não seja dinheiro.

Seja tempo.

Tempo sem notificações.

Tempo sem cobrança.

Tempo sem metas.

Tempo para conversar.

Tempo para observar uma paisagem.

Tempo para não fazer absolutamente nada.

Os aventureiros possuem exatamente isso.

Mesmo enfrentando monstros.


O Reino Tem Problemas...

Mas Não Tem Reunião por Videoconferência

Os reinos dos isekais possuem guerras.

Dragões.

Pragas.

Demônios.

Conspirações.

Mas existe algo que raramente aparece.

Uma reunião que poderia ter sido resolvida com três linhas de mensagem.

Às vezes penso que derrotar um Rei Demônio deve ser menos cansativo do que algumas reuniões corporativas.


O Caminhão Nunca Matou Ninguém

Talvez essa seja a frase mais estranha que já escrevi.

O Truck-kun nunca matou ninguém.

Quem matou foi o esgotamento acumulado.

O caminhão apenas abriu o portal.

O verdadeiro acidente aconteceu muito antes.

Quando viver começou a significar apenas cumprir agenda.


Bellacosa Mainframe

Depois de tantos anos trabalhando com computadores, aprendi uma lição curiosa.

Nenhum sistema permanece saudável funcionando permanentemente a cem por cento da CPU.

Existe gerenciamento de carga.

Existe balanceamento.

Existe manutenção preventiva.

Existe janela de descanso.

Existe IPL.

Existe WLM.

Até o z/OS sabe que recursos precisam de limites para continuar operando de forma confiável.

Curiosamente...

Nós parecemos exigir dos seres humanos exatamente o contrário.

Queremos disponibilidade permanente.

Produtividade crescente.

Atualização constante.

Resultados imediatos.

Como se pessoas fossem máquinas.

Talvez seja por isso que o Truck-kun tenha se tornado um símbolo tão poderoso.

Ele nunca foi um caminhão.

Foi um enorme botão vermelho escrito:

CANCEL JOB

Porque milhões de trabalhadores não sonham em morrer.

Sonham apenas em interromper, por alguns instantes, um processamento que parece nunca terminar.

E talvez essa seja a maior crítica escondida dos isekais.

O portal mágico não representa uma fuga da realidade.

Representa o desejo desesperado de recuperar algo que deveria ser um direito básico de qualquer ser humano.

O direito de viver... antes que a vida termine executando apenas o próximo STEP do JOB.

Continua na Parte V — "Por Que Quase Todo Protagonista de Isekai é um Salaryman? A Crítica Silenciosa do Japão ao Mundo Corporativo".

☕ UM CAFÉ NO BELLACOSA MAINFRAME

O Isekai e o Contrato Social Quebrado

Quando um Programador COBOL Descobre que Talvez Nunca Tenhamos Querido Fugir para Outro Mundo... Apenas Entender Este.

PRIMEIRA REGRA DO PORÃO NENHUM ARTIGO DEVE FICAR ESCONDIDO DOS LEITORES

Entre nesta série sobre trabalho, impostos, burnout, sociedade, salarymen, guildas, promessas quebradas e o verdadeiro significado da fuga para mundos paralelos. Escolha um capítulo, abra a prévia ou leia diretamente no Bellacosa Mainframe.

00
SYSTEM DIAGNOSIS

O Verdadeiro Rei Demônio Talvez Seja o Holerite

Quando um Programador COBOL Descobre que o Isekai Não Vende Magia... Vende um Mundo Onde o Esforço Ainda Vale Alguma Coisa.

Uma introdução à relação entre o sucesso do gênero isekai, a exaustão do trabalhador moderno, os descontos no salário, a perda de propósito e o desejo de recomeçar em outro mundo.

HOLERITE TRABALHO ISEKAI CONTRATO SOCIAL
Ler artigo completo ↗
01
CONTRACT ABEND

O Isekai e o Contrato Social Quebrado — Parte I

Quando um Programador COBOL Descobre que Talvez o Verdadeiro Bug Nunca Tenha Estado no Código... Mas na Promessa Feita ao Trabalhador.

A promessa de trabalhar, contribuir, construir uma carreira e receber segurança no futuro começa a apresentar falhas de processamento.

CONTRATO SOCIAL APOSENTADORIA DIGNIDADE
Ler artigo completo ↗
02
ECONOMY IPL

O Isekai e o Contrato Social Quebrado — Parte II

Quando um Programador COBOL Descobre que os Anos 1990 Talvez Tenham Sido o Grande IPL da Economia Mundial... e Nem Todos os JOBs Voltaram a Executar.

Globalização, tecnologia, automação, terceirização e produtividade reinicializaram a economia mundial, mas muitos trabalhadores ficaram aguardando uma resposta do sistema.

ANOS 1990 GLOBALIZAÇÃO AUTOMAÇÃO
Ler artigo completo ↗
03
MISSION ACCEPTED

O Isekai e o Contrato Social Quebrado — Parte III

Quando um Programador COBOL Descobre que a Guilda dos Aventureiros Talvez Tenha um RH Muito Melhor que o Nosso.

Na guilda existem missões claras, riscos conhecidos, recompensas publicadas e liberdade para escolher o próximo trabalho. No escritório moderno, nem sempre.

GUILDA RH RECOMPENSA
Ler artigo completo ↗
04
CANCEL JOB

O Isekai e o Contrato Social Quebrado — Parte IV

Quando um Programador COBOL Descobre que o Truck-kun Nunca Foi um Caminhão... Mas um Botão de CANCEL JOB para uma Geração Inteira.

Truck-kun representa a interrupção brutal de uma vida repetitiva, exausta e sem perspectiva. Um símbolo sombrio do desejo de cancelar a rotina e recomeçar.

TRUCK-KUN BURNOUT CANCEL JOB
Ler artigo completo ↗
05
SALARYMAN MODE

O Isekai e o Contrato Social Quebrado — Parte V

Quando um Programador COBOL Descobre que Quase Todo Protagonista de Isekai é um Salaryman... e Isso Está Muito Longe de Ser Coincidência.

Programadores, funcionários de escritório e trabalhadores invisíveis protagonizam histórias de recomeço porque representam milhões de pessoas presas em rotinas semelhantes.

SALARYMAN ESCRITÓRIO PROPÓSITO
Ler artigo completo ↗
06
TIME AVAILABLE

O Isekai e o Contrato Social Quebrado — Parte VI

Quando um Programador COBOL Descobre que Talvez o Verdadeiro Feitiço do Isekai Não Seja a Magia... Mas o Tempo para Viver.

O maior luxo de um mundo fantástico talvez não seja lançar feitiços, mas ter tempo para conversar, descansar, conviver, caminhar e participar de uma comunidade.

TEMPO COMUNIDADE QUALIDADE DE VIDA
Ler artigo completo ↗
07
RETURN CODE 00

O Isekai e o Contrato Social Quebrado — Parte VII

Quando um Programador COBOL Descobre que Talvez Nunca Tenhamos Querido Fugir para Outro Mundo... Apenas Recuperar Este.

A conclusão da série propõe que talvez o verdadeiro sonho nunca tenha sido abandonar o mundo real, mas recuperar dignidade, propósito, tempo, comunidade e esperança.

ESPERANÇA RECONSTRUÇÃO FUTURO
Ler artigo completo ↗
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...