☕ 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

domingo, 7 de julho de 2019

🈶 Tatemae e Honne — A Arte Japonesa de Equilibrar Verdade e Harmonia

 


🈶 Tatemae e Honne — A Arte Japonesa de Equilibrar Verdade e Harmonia

Título original: 建前と本音
Leitura: Tatemae to Honne
Significado literal: “A fachada construída e o som verdadeiro”
Origem: Filosofia social japonesa
Tema: A dualidade entre o que mostramos e o que realmente sentimos


🌗 Introdução: Entre o que se sente e o que se mostra

Você já engoliu uma verdade para não ferir alguém?
Já sorriu quando por dentro só queria silêncio?
Então, sem saber, você viveu o Tatemae e o Honne.

O Japão apenas deu nome e dignidade a esse conflito universal.
Lá, viver entre o que se sente e o que se mostra não é falsidade — é sabedoria social.
É entender que a harmonia (wa, 和) é um bem tão precioso quanto a verdade.


🧩 O Que É Tatemae e O Que É Honne

ConceitoSignificadoExemplo
Tatemae (建前)“Fachada construída” — o comportamento que você adota em público para manter harmonia.Dizer “estou bem” mesmo cansado, para não preocupar os outros.
Honne (本音)“Som verdadeiro” — seus sentimentos, opiniões e desejos autênticos.Pensar “eu só queria ficar sozinho hoje”.

O equilíbrio entre os dois é a dança da convivência humana.
No Japão, isso é tão natural quanto respirar — e tão essencial quanto manter a honra.


🕰️ Um Breve Contexto Histórico

Durante o Período Edo (1603–1868), a sociedade japonesa era rigidamente hierárquica.
A sobrevivência dependia de respeitar papéis sociais e preservar a aparência de harmonia.
Foi aí que o tatemae e o honne floresceram como ferramentas de coexistência.

Quando o Japão abriu suas portas ao Ocidente, essa dualidade ganhou um novo sentido:
como equilibrar tradição e modernidade, coletividade e individualismo.

Assim, o tatemae/honne se tornou a alma invisível da etiqueta japonesa — e também, o código emocional de milhões de pessoas no mundo que buscam equilíbrio entre autenticidade e empatia.


🎎 A Filosofia Por Trás do Tatemae

O tatemae não é mentira, é respeito.
Ele existe para evitar atrito, preservar relações e proteger o espaço do outro.

O japonês não pergunta: “O que é verdade?”
Ele pergunta: “O que é apropriado dizer agora, para que ninguém se fira?”

Já o honne não é rebeldia, é essência.
Ele vive guardado no íntimo, revelado apenas aos mais próximos, como quem oferece um presente raro.

O equilíbrio entre os dois é o que torna a convivência delicada, humana e suportável.


💡 Curiosidades Bellacosa

  • Na língua japonesa, há expressões que suavizam o honne, como “chotto...” (um pouquinho...) — uma forma de dizer “não” sem dizer “não”.

  • No ambiente corporativo, o tatemae é vital: confrontar um chefe diretamente pode ser visto como falta de educação, mesmo estando certo.

  • Muitos ocidentais confundem o tatemae com hipocrisia, mas no Japão ele é prova de maturidade emocional.

  • Em animes, personagens introspectivos (como Shinji Ikari de Evangelion ou Hachiman de Oregairu) vivem o conflito tatemae/honne de forma dramática e simbólica.


🧘 Como Aplicar na Vida Real (Mesmo Sem Ser Japonês)

  1. Aprenda a medir o momento. Nem toda verdade precisa ser dita na hora.

  2. Pratique empatia silenciosa. Às vezes, compreender sem julgar é mais forte que confrontar.

  3. Reserve espaço para o seu honne. Escreva, reflita, fale com quem te entende.

  4. Não confunda diplomacia com falsidade. Ser educado não é ser falso — é ser sábio.

  5. Revele o honne com propósito. Quando falar de verdade, que seja para construir, não ferir.


💬 Comentário Bellacosa

O tatemae e o honne são o que o código-fonte é para o programa:
invisíveis, mas determinantes.

Eles mostram que viver é uma constante negociação entre autenticidade e harmonia.
E que, às vezes, manter a paz também é um ato de coragem.

No fundo, quem domina o tatemae/honne não está se escondendo — está preservando a beleza do convívio humano, mesmo quando o mundo insiste em ruídos.


🌸 Especial aos Fãs de Cultura Japonesa

Quer sentir o tatemae/honne em ação?

🎬 Animes que exploram o tema:

  • Oregairu (My Teen Romantic Comedy SNAFU) – honestidade brutal versus etiqueta social.

  • Neon Genesis Evangelion – o colapso do tatemae em meio ao caos emocional.

  • Nana – duas mulheres entre o que sentem e o que mostram ao mundo.

  • March Comes in Like a Lion – o honne tímido tentando sobreviver num mundo de aparências.

📖 Frase japonesa que resume tudo:

“Omote ni wa egao, ura ni wa namida.”
“No rosto, um sorriso. Por trás, uma lágrima.”


Bellacosa conclui:
Tatemae e Honne não são máscaras — são camadas de humanidade.
O primeiro mantém o mundo girando, o segundo o mantém verdadeiro.
E quem domina ambos… vive em paz com os outros sem trair a si mesmo.

quarta-feira, 3 de julho de 2019

☕🚀🏙️ Operador, e se aquilo nunca tivesse sido uma cidade?

Bellacosa Mainframe e uma teoria sobre Shoujo Shuumatsu Ryokou

☕🚀🏙️ Operador, e se aquilo nunca tivesse sido uma cidade?

A interpretação mais comum é:

"Uma megacidade construída sobre as ruínas de si mesma."

Mas existem vários elementos estranhos.

Não existe horizonte natural

Praticamente nunca vemos:

  • florestas

  • rios

  • oceanos

  • montanhas

  • animais selvagens

Tudo é:

  • concreto

  • aço

  • tubulações

  • plataformas

  • elevadores

  • corredores

É como se o ambiente inteiro tivesse sido projetado.


O Problema da Escala

Uma cidade normal cresce horizontalmente.

A de Shoujo cresce verticalmente.

E cresce de forma absurda.

Existem momentos em que:

  • não vemos o fundo

  • não vemos as laterais

  • não vemos o limite da estrutura

Isso lembra muito mais:

  • uma arcologia (cidade fechada)

  • um habitat orbital

  • uma nave geracional

do que uma cidade convencional.


Os Elevadores Gigantes

Esse detalhe sempre me chamou atenção.

Os elevadores são enormes.

Muito maiores do que seria necessário para pessoas.

Parecem projetados para transportar:

  • veículos

  • cargas industriais

  • módulos inteiros

É exatamente o tipo de infraestrutura que esperaríamos em uma colônia espacial.

Num planeta você pode construir estradas.

Num habitat vertical, você depende de transporte interno.


A Ausência de Corpos

Essa observação é excelente.

Se houve uma guerra apocalíptica que exterminou bilhões de pessoas, onde estão os restos?

Encontramos:

  • armas

  • tanques

  • aviões

  • fábricas

Mas quase nunca encontramos cadáveres.

Nem mesmo esqueletos.

Isso é muito estranho.


O Cemitério

O cemitério da série é uma pista fascinante.

O que encontramos?

Objetos.

Pertences.

Memórias.

Não corpos.

É quase um memorial simbólico.

Como se os mortos tivessem desaparecido completamente.


A Hipótese da Reciclagem Total

Imagine uma sociedade extremamente avançada.

Fechada.

Sem acesso fácil a recursos externos.

Talvez espacial.

Nesse ambiente seria lógico reciclar tudo.

Inclusive matéria orgânica.

Inclusive corpos.

Inclusive resíduos biológicos.

Uma estação espacial não pode desperdiçar recursos.

Tudo vira matéria-prima.

Tudo retorna ao sistema.


O Mundo Como Um Navio

Essa foi provavelmente sua observação mais interessante.

A arquitetura lembra muito mais um navio do que uma cidade.

Observe:

  • compartimentos

  • escotilhas

  • corredores estreitos

  • plataformas técnicas

  • elevadores verticais

  • ausência de ruas convencionais

Tudo parece modular.

Funcional.

Projetado.

Não orgânico.


A Hierarquia Vertical

Outro ponto forte da teoria.

Historicamente:

Nas cidades

A elite costuma ocupar áreas específicas.

Em habitats artificiais

A hierarquia frequentemente é vertical.

Os níveis superiores:

  • mais luz

  • mais conforto

  • melhor qualidade de vida

Os níveis inferiores:

  • indústria

  • manutenção

  • logística

Shoujo parece exatamente isso.

Quanto mais sobem:

  • mais espaço

  • mais luz

  • menos maquinário pesado


O Topo É Estranho

Sem entrar em spoilers do mangá.

Mas existe uma sensação crescente de que o topo não foi construído para a vida cotidiana.

Ele parece quase uma camada de observação.

Uma interface.

Uma fronteira.

Como o convés superior de um navio.

Ou a seção externa de uma estação orbital.


A Questão Filosófica

Curiosamente, talvez Tsukumizu tenha feito isso de propósito.

Ele nunca explica claramente:

  • planeta?

  • estação espacial?

  • arcologia?

  • nave geracional?

Porque a explicação técnica não é o foco.

O foco é a sensação.

A sensação de viver dentro de um sistema tão gigantesco que ninguém mais entende sua finalidade original.


A Leitura Bellacosa Mainframe

☕🖥️🚀

Depois de assistir várias vezes, comecei a pensar que Chito e Yuuri não estão explorando uma cidade.

Estão explorando um sistema.

Um sistema fechado.

Autônomo.

Possivelmente milenar.

Onde os usuários desapareceram há tanto tempo que apenas os processos continuam executando.

Os elevadores são barramentos.

Os andares são módulos.

As fábricas são subsistemas.

As bibliotecas são backups.

Os memoriais são arquivos históricos.

E a ausência de corpos sugere algo ainda mais inquietante:

o sistema continuou funcionando depois que os usuários desapareceram.

Exatamente como em Apocalypse Hotel.

Exatamente como uma nave geracional abandonada.

Exatamente como um mainframe que continua executando jobs décadas após a saída de seus desenvolvedores.

Por isso sua teoria da estação espacial é tão sedutora. Ela explica várias anomalias visuais e arquitetônicas da obra. Talvez não seja a interpretação definitiva de Tsukumizu, mas é uma das leituras mais coerentes para aquele mundo artificial, vertical, fechado e estranhamente limpo de vestígios biológicos.

E talvez a pergunta mais assustadora nem seja "onde estão os corpos?".

Mas sim:

Quem estava pilotando esse navio — e quando ele foi abandonado? ☕🚀🖥️

terça-feira, 2 de julho de 2019

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

 

Bellacosa Mainframe explica o CALL em COBOL Parte VII

☕💥 A Jornada do Padawan COBOL – Parte 7

Desvendando o Universo dos CALLs no Mainframe

BALR, BASR, BASSM, SVC, PC, TCB, SRB, Cross Memory, zIIP e os Segredos dos Sysprogs Jedi do IBM Z

Ou como descobrir que, por trás de um simples CALL COBOL, existe um universo de instruções Assembly capaz de processar bilhões de transações por dia

Por Vagner Bellacosa – Bellacosa Mainframe


O dia em que o Padawan descobre que COBOL é apenas uma ilusão confortável

Até agora descobrimos:

✔ Static CALL

✔ Dynamic CALL

✔ Binder

✔ LE

✔ CICS

✔ APIs

✔ MQ

✔ REST

Mas existe algo que poucos desenvolvedores COBOL enxergam.

Quando você escreve:

CALL 'SUBPGM'

O hardware IBM Z não entende COBOL.

Ele entende.

Instruções Assembly

E é aqui que começa a verdadeira aventura.


O que existe por trás do CALL

Imagine:

Programa COBOL

Compilador

LE

Assembler

CPU z16


O processador executa algo semelhante a:

BALR R14,R15

ou

BASR R14,R15

BALR

Branch and Link Register

O avô do CALL.


Exemplo

BALR 14,15

O que faz?

Salva endereço retorno.

Desvia execução.


Visualmente


MAIN


00010000


BALR


↓


SUBPGM


00025000


EXECUTA


RETORNA




BASR

Mais moderno.


Branch and Save Register


Mesmo conceito.

Melhor otimização.


BASSM

Território Jedi.

Poucos entram.


Branch And Save And Set Mode


Troca modo.

24 bits.

31 bits.

64 bits.


Exemplo

BASSM R14,R15

Por que existe?

Compatibilidade.

Programas antigos.

AMODE mistos.


O conceito de Supervisor

Padawan acredita.

Programa faz tudo.

IBM sorri.


Usuário

não faz quase nada.


Sistema faz.


SVC

Supervisor Call


Programa pede ajuda.


Exemplo

SVC 99

Sistema operacional assume.

Executa.

Retorna.


Exemplos famosos

SVC 13

ABEND


SVC 99

Dynamic Allocation


SVC 19

OPEN


O Program Call

PC Instruction


Mais rápido.

Mais seguro.

Cross Memory.


Muito usado por:

RACF

DB2

JES2

SAF


Cross Memory

Território dos Sysprogs.


Endereço A

fala com

Endereço B


Visualmente


USER SPACE


↓


PC


↓


DB2 SPACE


↓


RETORNA



TCB

Task Control Block


Representa.

Uma tarefa.


CICS

Muitos TCBs.


Batch

Normalmente um.


SRB

Service Request Block


Mais leve.

Mais rápido.


Menos overhead.


Muito usado.

RMF

SMF

DB2


TCB versus SRB

CaracterísticaTCBSRB
PesoMédioLeve
CPUNormalMelhor
WAITSimNão
PerformanceBoaExcelente

zIIP

O sonho do financeiro.


Specialty Engine


Pode executar:

XML

Java

MQ

DRDA

REST

Analytics


CPU geral agradece.


HiperDispatch

Poucos conhecem.

IBM adora.


Mantém afinidade.

CPU cache.


Melhora latência.


LE Internals

Language Environment.


Controla.

Heap

Stack

Condition Handler

Exceptions

Threads

Storage


O Condition Handler

Exemplo

ON EXCEPTION

LE intercepta.

Processa.

Retorna.


Como nasce um S0C4

Programa

CALL

LE

Assembler

PSW

Address Exception

ABEND


O PSW

Program Status Word


Coração do processador.


Guarda

Modo

Estado

Máscaras

Endereço


IPCS mostra.


Registradores

IBM Z possui

16 registradores


R14

Retorno


R15

Entrada


R13

Save Area


Veteranos decoram.


Save Area

Mágica antiga.


Assembler

STM 14,12,12(13)

Salva contexto.


Retorna depois.


Porque COBOL parece mágico

O compilador faz.

Tudo isso.

Automaticamente.


Padawan escreve

CALL 'PAGTO'

IBM executa.

Milhares.

De instruções.


Dicas Bellacosa

Dica 1

Nunca ignore PSW.


Dica 2

Aprenda registradores.


Dica 3

Entenda LE.


Dica 4

Conheça SVC99.


Dica 5

Estude TCB.


Dica 6

SRB é ouro.


Dica 7

zIIP economiza dinheiro.


Easter Egg Mainframe

Existe um grupo de profissionais.

Que olha isto.

BALR 14,15

E imediatamente sabe.

AMODE.

RMODE.

PSW.

TCB.

Offset.

Storage Key.

Cross Memory.

PC Bit.

SRB.


São conhecidos pelos desenvolvedores COBOL como:

Os Sysprogs Jedi


Checklist Jedi da Parte 7

✅ Entender BALR

✅ Entender BASR

✅ Conhecer BASSM

✅ Saber SVC99

✅ Estudar LE

✅ Aprender TCB

✅ Aprender SRB

✅ Conhecer Cross Memory

✅ Entender PSW

✅ Conhecer IPCS

✅ Aproveitar zIIP

✅ Ler Assembly sem medo


A Filosofia Jedi do CALL – Parte 7

O Padawan iniciante acredita:

COBOL chama COBOL.

O desenvolvedor intermediário pensa:

COBOL usa LE.

O especialista entende:

COBOL é uma linguagem elegante construída sobre décadas de engenharia do z/Architecture, Assembly, supervisão do z/OS e mecanismos extremamente otimizados de gerenciamento de contexto.

E o Mestre Mainframe compreende algo ainda mais profundo:

Um simples CALL 'SUBPGM' é apenas a ponta visível de uma cadeia tecnológica refinada ao longo de mais de cinquenta anos, permitindo que um IBM Z execute bilhões de instruções por segundo com níveis de disponibilidade, segurança e eficiência que ainda hoje servem de referência para toda a indústria.


Próxima aventura do Padawan COBOL – Parte 8

"As Últimas Runas do Mainframe: DLLs Avançadas, Metal C, Callable Services, SAF, RACF, PC-Bit, APF, Dataspaces, Hiperspaces, Coupling Facility e os segredos que poucos profissionais IBM Z dominam."


segunda-feira, 17 de junho de 2019

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

 

Bellacosa Mainframe e a quebra do contrato social parte v

☕ Um Café no Bellacosa Mainframe

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

Depois de escrever os capítulos anteriores, resolvi fazer um pequeno exercício.

Peguei dezenas de isekais.

Comecei a anotar quem eram seus protagonistas antes da reencarnação.

O resultado me surpreendeu.

Na verdade...

Nem tanto.

A maioria absoluta era formada por pessoas completamente comuns.

Funcionários de escritório.

Salarymen.

Programadores.

Estudantes.

Desempregados.

Hikikomori.

NEETs.

Pouquíssimos eram milionários.

Pouquíssimos eram celebridades.

Pouquíssimos eram políticos.

Quase nenhum era um grande empresário.

Foi aí que percebi uma coisa.

O isekai nunca foi escrito para quem está no topo da pirâmide.

Ele foi escrito para quem acorda cedo na segunda-feira.


O Salaryman é o Guerreiro Moderno

No Ocidente, quando pensamos em heróis, imaginamos cavaleiros.

Cowboys.

Super-heróis.

No Japão...

Existe outro personagem.

O salaryman.

Ele veste terno.

Carrega uma pasta.

Pega trem lotado.

Chega cedo.

Sai tarde.

Volta para casa exausto.

Repete tudo no dia seguinte.

Sem espada.

Sem armadura.

Sem magia.

Seu chefe final chama-se:

Meta.


A Armadura Virou Gravata

É curioso perceber como os símbolos mudam.

O cavaleiro medieval carregava escudo.

O trabalhador moderno carrega notebook.

O aventureiro tinha espada.

O analista tem crachá.

O mago possuía grimório.

O desenvolvedor possui documentação.

O arqueiro carregava flechas.

O consultor carrega PowerPoint.

Mudam os equipamentos.

As batalhas continuam existindo.


O Reino Corporativo

Quanto mais observo...

Mais vejo semelhanças.

Existe um rei.

Chamado CEO.

Existem nobres.

Chamados diretores.

Existem lordes.

Chamados gerentes.

Existem cavaleiros.

Chamados coordenadores.

Existem aldeões.

Chamados funcionários.

Existe um castelo.

Chamado escritório.

Existe uma guilda.

Chamada Recursos Humanos.

Existe um imposto.

Chamado desconto em folha.

E existe um dragão.

Chamado prazo.


O NPC do Próprio Sistema

Talvez o maior medo do trabalhador moderno seja outro.

Não é perder o emprego.

É descobrir que virou um NPC da própria vida.

Acorda.

Trabalha.

Paga contas.

Dorme.

Repete.

Os dias deixam de ser lembranças.

Viram apenas datas no calendário.

É exatamente nesse momento que aparece o portal do isekai.


O Herói Nunca Foi Especial

Repare.

Na maioria das histórias.

O protagonista não era extraordinário.

Era justamente o contrário.

Era invisível.

Ninguém prestava atenção.

Ninguém reconhecia seu esforço.

Ninguém o admirava.

Então ele muda de mundo.

Pela primeira vez...

Alguém diz.

"Precisávamos de você."

Essa frase vale mais do que qualquer espada lendária.


O Japão Também Está Cansado

Às vezes imaginamos que o sucesso do isekai aconteceu porque os japoneses gostam de fantasia medieval.

Acho que a explicação é mais profunda.

O Japão conhece muito bem palavras como:

Karōshi.

Morte por excesso de trabalho.

Hikikomori.

Isolamento social.

Kodokushi.

Morte solitária.

Esses fenômenos não surgiram do nada.

Eles refletem tensões reais de uma sociedade altamente exigente.

O isekai talvez seja uma forma de responder emocionalmente a essas pressões.


O Programador Também Sonha

Talvez por isso tantos protagonistas sejam desenvolvedores.

Ou analistas.

Ou profissionais de TI.

Nós entendemos algo muito específico.

Passamos anos resolvendo problemas dos outros.

Corrigindo sistemas.

Otimizando processos.

Automatizando tarefas.

Mas existe uma pergunta que raramente fazemos.

Quem está corrigindo o sistema da nossa própria vida?


O Holerite Nunca Conta a História Completa

Chega o quinto dia útil.

O salário entra.

Antes mesmo de você respirar.

Uma parte já foi embora.

Contribuições.

Impostos.

Descontos.

Financiamentos.

Contas.

Depois vem o supermercado.

Combustível.

Pedágio.

Plano de saúde.

Mensalidades.

IPTU.

IPVA.

Conta de energia.

Conta de água.

Internet.

No fim...

Você percebe que passou mais um mês inteiro trabalhando.

E a sensação de liberdade continua exatamente igual.

Não é uma crítica à existência de impostos em si, que financiam serviços essenciais em qualquer sociedade organizada. A inquietação aparece quando muitos trabalhadores sentem que o retorno percebido não acompanha o esforço exigido para gerar aquela renda.


O Nível Não Sobe

Nos RPGs.

Você trabalha.

Fica mais forte.

No mercado moderno.

Às vezes acontece algo diferente.

Você trabalha.

Aprende.

Estuda.

Faz cursos.

Obtém certificações.

Assume novas responsabilidades.

Mas a percepção é que a qualidade de vida evolui muito menos do que o conhecimento adquirido.

É como jogar durante cinquenta horas...

...e descobrir que seu personagem continua preso no mesmo mapa.


O Sonho Nunca Foi Ser Rico

Existe um equívoco enorme.

As pessoas imaginam que o trabalhador quer riqueza.

Talvez não.

A maioria quer apenas tranquilidade.

Dormir sem ansiedade.

Viajar uma vez por ano.

Comprar um livro sem fazer contas.

Ter tempo para os filhos.

Ter saúde.

Ter algum dinheiro guardado.

Aposentar-se com dignidade.

Curiosamente...

Esses desejos parecem muito mais modestos do que derrotar um dragão.


Bellacosa Mainframe

Depois de tantos anos escrevendo COBOL, percebi que todo sistema precisa obedecer a uma regra fundamental.

A entrada deve produzir uma saída previsível.

Se você alimenta um programa corretamente durante quarenta anos...

Espera um resultado coerente.

Quando isso deixa de acontecer...

Chamamos de erro lógico.

Talvez seja exatamente essa a sensação de muitos trabalhadores.

Eles executaram corretamente o programa que lhes ensinaram.

Estudaram.

Trabalharam.

Pagaram impostos.

Contribuíram para a previdência.

Cumpriram horários.

Aceitaram responsabilidades.

Mesmo assim...

O resultado esperado parece cada vez mais distante.

É nesse instante que o portal mágico começa a fazer sentido.

Não porque exista um dragão esperando do outro lado.

Mas porque, pela primeira vez em muito tempo, alguém olha para aquele trabalhador cansado e diz:

"Você não é apenas mais um número na folha de pagamento."

Talvez essa seja a verdadeira magia do isekai.

Não lançar meteoros.

Não derrotar demônios.

Mas devolver ao protagonista algo que ele perdeu muito antes de atravessar o portal.

A sensação de que sua existência tem valor.

Continua na Parte VI — "O Reino da Fantasia ou a Sociedade Perdida? Por Que o Mundo Medieval dos Isekais Parece Mais Humano do que as Grandes Cidades Modernas".

☕ 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 ↗

domingo, 16 de junho de 2019

☕🔥 DESIGN PATTERNS NO IBM MAINFRAME — O SEGREDO “INVISÍVEL” QUE SEMPRE ESTEVE DENTRO DO COBOL, CICS E DB2

 

Bellacosa Mainframe e o design patterns orientados ao mainframe

☕🔥 DESIGN PATTERNS NO IBM MAINFRAME — O SEGREDO “INVISÍVEL” QUE SEMPRE ESTEVE DENTRO DO COBOL, CICS E DB2

Muita gente olha para Design Patterns e pensa imediatamente em:

  • Java

  • Spring

  • Microservices

  • APIs modernas

  • Orientação a Objetos

Mas existe uma ironia histórica gigantesca aqui:

👉 O Mainframe já utilizava vários conceitos de Design Patterns ANTES MESMO DO TERMO “DESIGN PATTERN” VIRAR MODA.

Sim.

Muito do que a Gang of Four formalizou em 1994 já existia de forma arquitetural em:

  • CICS

  • IMS

  • JES2

  • VTAM

  • RACF

  • COBOL corporativo

  • Batch Processing

  • Transaction Processing

O programador mainframe veterano talvez nunca tenha chamado isso de “Factory”, “Facade” ou “Template Method”…

…mas ele já aplicava esses conceitos há décadas.

E aqui está a verdade que poucos falam:

🔥 O Mainframe é provavelmente um dos ambientes que MAIS UTILIZA padrões arquiteturais de forma disciplinada.


☕ O QUE É UM DESIGN PATTERN DE VERDADE?

Design Pattern não é código pronto.

É:

Uma solução recorrente para um problema recorrente.

É experiência transformada em arquitetura.

É o equivalente computacional de:

  • engenharia civil

  • arquitetura predial

  • aviação

  • medicina

Porque sistemas gigantes NÃO sobrevivem sem padrões.

E adivinha qual ambiente mais precisava disso?

👉 O Mainframe.

Porque ele sempre lidou com:

  • milhões de transações

  • altíssima disponibilidade

  • integridade financeira

  • processamento distribuído

  • desacoplamento

  • segurança crítica

  • integração entre sistemas legados


☕ 1. SINGLETON — O “ÚNICO RECURSO” DO MAINFRAME

No mundo OO:

O Singleton garante apenas uma instância da classe.

No Mainframe?

Isso existe desde os primórdios.

Exemplos clássicos:

🔹 JES2

Existe apenas:

  • um spool manager central

  • um checkpoint principal

  • um controlador global

Isso é comportamento Singleton.


🔹 ENQ/DEQ

Controle exclusivo de recurso.

Exemplo:

EXEC CICS ENQ
     RESOURCE('CLIENTE001')
END-EXEC

O sistema garante:

  • uma única posse do recurso

  • integridade transacional

Isso é Singleton aplicado a lock de recurso.


🔹 DB2 Subsystem

Um subsystem DB2:

DB2P
DB2T
DB2D

atua como entidade centralizada.

Toda aplicação referencia a mesma infraestrutura lógica.


☕ 2. FACTORY METHOD — O MAINFRAME CRIA OBJETOS HÁ DÉCADAS

No Java:

Factory cria objetos sem expor a implementação.

No Mainframe:

isso aparece MUITO em arquiteturas transacionais.


🔥 Exemplo clássico: CICS Transaction Routing

Usuário chama:

TRN1

Mas o CICS decide:

  • qual programa carregar

  • qual região executar

  • qual recurso utilizar

O chamador não conhece a implementação real.

Isso é Factory.


Outro exemplo:

Dynamic CALL COBOL

CALL WS-PGM-NAME USING AREA.

O programa chamado é decidido dinamicamente.

Isso desacopla:

  • lógica

  • implementação

  • versão

Exatamente como Factory Method.


☕ 3. BUILDER — O JCL É UM BUILDER GIGANTE

Essa talvez exploda a mente de muita gente.

O JCL inteiro é praticamente um padrão Builder.

Por quê?

Porque ele monta um processamento complexo passo a passo.


Veja isso:

//STEP1 EXEC PGM=SORT
//STEP2 EXEC PGM=IDCAMS
//STEP3 EXEC PGM=IEFBR14

Cada STEP constrói parte do processo final.


O Builder no Mainframe:

  • constrói pipelines batch

  • monta datasets

  • prepara ambientes

  • cria fluxos de ETL

  • organiza utilitários

O resultado final é “montado” progressivamente.

Exatamente o conceito Builder.


☕ 4. ADAPTER — O REI ABSOLUTO DAS INTEGRAÇÕES

Se existe um pattern que domina o Mainframe…

é Adapter.

Porque o Mainframe SEMPRE precisou conversar com mundos diferentes.


🔥 Exemplos históricos:

EBCDIC ↔ ASCII

Conversão clássica.

Adapter puro.


COBOL ↔ JSON

Hoje usamos:

  • z/OS Connect

  • CICS Web Services

  • IBM MQ

  • API Connect

Tudo isso são adapters modernos.


VTAM ↔ TCP/IP

O Mainframe adaptou protocolos antigos ao mundo IP.

Isso é engenharia absurda.


☕ 5. DECORATOR — O CICS FAZ ISSO O TEMPO TODO

Decorator adiciona comportamento sem alterar o núcleo.

CICS faz isso há décadas.


Exemplos:

Monitoring exits

Você adiciona:

  • auditoria

  • tracing

  • logging

  • segurança

sem alterar a aplicação original.


RACF Exit

Você “decora” autenticação.

O núcleo continua igual.


☕ 6. FACADE — O CICS É UMA FACADE MONSTRUOSA

O usuário faz:

EXEC CICS READ

Mas por trás existe:

  • VSAM

  • locking

  • journaling

  • recovery

  • buffer pools

  • syncpoint

  • dispatching

O CICS simplifica toda a complexidade.

Isso é literalmente Facade.


☕ 7. PROXY — A ALMA DO PROCESSAMENTO DISTRIBUÍDO

Proxy controla acesso a outro objeto.

O Mainframe faz isso desde os anos 70.


Exemplos:

Distributed Program Link (DPL)

Programa local chama remoto como se fosse local.

Isso é Proxy puro.


MQ

Fila representa comunicação indireta.

Você não fala diretamente com o sistema remoto.

Existe um intermediário.


☕ 8. COMPOSITE — JES2 E SPOOL

Composite trata grupos e indivíduos igualmente.

O JES2 faz isso magistralmente.


JOB → STEPS → DDs

Hierarquia perfeita:

JOB
 ├── STEP
 │    ├── DD

Estrutura em árvore.

Exatamente Composite.


☕ 9. OBSERVER — O MAINFRAME SEMPRE FOI EVENT-DRIVEN

Muito antes do termo “event streaming”.


Exemplos:

WTO/WTOR

Eventos geram reações.


SMF

Subsistemas “observam” eventos do sistema.


Automation (NetView / System Automation)

Mensagens disparam ações automáticas.

Observer clássico.


☕ 10. STRATEGY — O SORT É UMA AULA DE DESIGN PATTERN

Você muda estratégia sem alterar o fluxo principal.


DFSORT

Dependendo dos parâmetros:

SORT FIELDS=
OPTION COPY
SUM FIELDS=

o mecanismo muda completamente.

Mesmo motor.

Estratégias diferentes.


☕ 11. COMMAND — O UNIVERSO OPERACIONAL

Mainframe é praticamente uma civilização baseada em Command Pattern.


Exemplos:

MVS Commands

D A,L
P JOB123
CEMT I TASK

Cada comando encapsula:

  • ação

  • parâmetros

  • execução


☕ 12. ITERATOR — VSAM E DB2

Iterator percorre coleções.

Mainframe nasceu fazendo isso.


COBOL Sequential Read

READ ARQ NEXT RECORD

DB2 Cursor

FETCH NEXT

Iterator clássico.


☕ 13. STATE — O CICS É OBCECADO POR ESTADO

Estados mudam comportamento.

CICS inteiro vive disso.


Transações:

  • Enabled

  • Disabled

  • Quiesced

  • Purged


Tasks:

  • Running

  • Waiting

  • Suspended

Cada estado altera comportamento do sistema.


☕ 14. TEMPLATE METHOD — O DNA DO COBOL CORPORATIVO

Talvez o mais usado de todos.


Estrutura clássica:

1000-INICIO.
2000-PROCESSA.
3000-FINALIZA.

Framework fixo.

Etapas customizáveis.


Batch corporativo inteiro usa isso

  • abertura

  • validação

  • processamento

  • commit

  • fechamento

Template Method puro.


☕ 15. CHAIN OF RESPONSIBILITY — O MAINFRAME É UMA CADEIA GIGANTE

Request passa por múltiplos componentes.


Fluxo real:

TSO
 ↓
RACF
 ↓
JES2
 ↓
WLM
 ↓
DB2
 ↓
CICS

Cada camada decide:

  • tratar

  • validar

  • encaminhar

  • rejeitar

Isso é Chain of Responsibility em escala industrial.


☕🔥 A GRANDE VERDADE QUE NINGUÉM CONTA

O Mainframe não ficou ultrapassado.

O que aconteceu foi:

👉 A indústria moderna reaprendeu conceitos que o Mainframe já dominava há décadas.

Quando alguém fala:

  • microservices

  • event driven

  • observability

  • middleware

  • transaction manager

  • resilience

  • orchestration

…o profissional mainframe experiente muitas vezes pensa:

“Nós já fazíamos isso nos anos 80.”

E não é arrogância.

É história da computação.


☕🔥 O MAIOR ERRO DOS NOVOS PROFISSIONAIS

Muitos estudam Design Patterns apenas em:

  • Java

  • C#

  • Python

Mas ignoram o ambiente onde esses conceitos foram colocados à prova em escala planetária.

Porque é fácil fazer pattern em sistema pequeno.

Difícil é fazer funcionar:

  • em banco

  • bolsa de valores

  • governo

  • aviação

  • seguradoras

  • telecom

  • processamento mundial

por 40 anos sem parar.

O Mainframe fez isso.


☕🔥 CONCLUSÃO — O MAINFRAME NÃO É “LEGADO”

Ele é:

Engenharia sobrevivente.

Cada pattern desses dentro do z/OS nasceu de necessidade real:

  • performance

  • segurança

  • disponibilidade

  • recuperação

  • escalabilidade

  • integridade

E talvez essa seja a maior lição do Mainframe para a computação moderna:

🔥 “Arquitetura boa não é a mais bonita.
É a que continua funcionando décadas depois.”

sábado, 15 de junho de 2019

🔥☕ “O TIOZÃO DO MAINFRAME REENCARNOU NO ISEKAI?” — O FENÔMENO Isekai Ojisan E O ANIME MAIS CAÓTICO, NOSTÁLGICO E GENIAL DOS ÚLTIMOS ANOS ☕🔥

 

Bellacosa Mainframe e as aventuras do Tiozao Isekai Ojisan do outro mundo

🔥☕ “O TIOZÃO DO MAINFRAME REENCARNOU NO ISEKAI?” — O FENÔMENO Isekai Ojisan E O ANIME MAIS CAÓTICO, NOSTÁLGICO E GENIAL DOS ÚLTIMOS ANOS ☕🔥

Se existe um anime capaz de unir:

  • nostalgia dos anos 90,
  • humor nonsense,
  • referências obscuras de videogame,
  • trauma social,
  • magia,
  • SEGA,
  • e um protagonista mais estranho que operador de JES2 em blackout de datacenter...

…esse anime é Isekai Ojisan.

E sinceramente?

Esse anime parece ter sido escrito por alguém que passou 20 anos em produção de mainframe e acordou um dia preso num universo fantasy.


🎌 Título Original

異世界おじさん (Isekai Ojisan)

Tradução aproximada:

“Tio do Outro Mundo”

Também conhecido em inglês como:

Uncle from Another World


👤 Criador

Hotondoshindeiru

Sim…
esse é literalmente o pseudônimo do autor.

O nome pode ser traduzido de forma aproximada como:

“Quase Morto”

O que combina PERFEITAMENTE com a energia mental do anime.


📅 Data de Lançamento

Mangá

  • Início: 2018
  • Publicado pela Kadokawa

Anime

  • Estreia: Julho de 2022

Produção:

Studio AtelierPontdarc


📺 Mídias Existentes

📚 Mangá

  • Em publicação
  • Diversos volumes tankōbon

📺 Anime

  • 1 temporada
  • 13 episódios

🌎 Streaming

Disponível oficialmente na:

  • Netflix

⚠️ O “DESASTRE OPERACIONAL” DA PRODUÇÃO

O anime ficou FAMOSO por:

  • atrasos,
  • pausas,
  • episódios adiados,
  • problemas de produção.

Parecia IPL falhando em feriado prolongado.

A COVID afetou fortemente o cronograma do estúdio.

Resultado:

  • o anime parava,
  • voltava,
  • sumia,
  • reaparecia.

Quase um job preso em HOLD no JES2.


☕ A HISTÓRIA — O “OPERADOR DE PRODUÇÃO” DO ISEKAI

Imagine isto:

Um homem entra em coma nos anos 2000.

Acorda DEZESSETE ANOS depois.

Mas durante o coma…
ele estava consciente em OUTRO MUNDO.

Sim.

O tio do protagonista literalmente viveu um isekai completo:

  • magia,
  • monstros,
  • reinos,
  • aventuras,
  • guerras,
  • waifus apaixonadas…

…e volta para o Japão moderno totalmente quebrado mentalmente.


🔥 O DIFERENCIAL GENIAL

A maioria dos isekais mostra:

“o protagonista overpower salvando o mundo.”

Mas Isekai Ojisan pergunta:

“E se o protagonista fosse socialmente incapaz, traumatizado e obcecado por SEGA?”

E isso muda TUDO.


🎮 O ANIME QUE É UMA CARTA DE AMOR À SEGA

Esse anime é praticamente propaganda emocional do:

  • Sega Saturn
  • Dreamcast
  • Mega Drive
  • Sonic
  • Virtua Fighter

O Ojisan é um fanático por SEGA.

Num nível quase religioso.

Ele defende a SEGA como veterano defendendo COBOL em reunião cloud.


💣 O HUMOR É ABSURDAMENTE INTELIGENTE

O anime funciona em várias camadas:

Camada 1 — Comédia

As situações são completamente ridículas.

Camada 2 — Crítica social

O anime zomba:

  • da cultura otaku,
  • da solidão,
  • do escapismo,
  • da incapacidade social.

Camada 3 — Paródia de isekai

Ele destrói vários clichês do gênero.

Camada 4 — Nostalgia

Quem viveu os anos 90 sente uma pancada emocional absurda.


⚔️ QUANTIDADE DE EPISÓDIOS

Anime

  • 13 episódios

Duração média

  • ~24 minutos

📚 QUANTIDADE DE CAPÍTULOS DO MANGÁ

O mangá continua em publicação.

Já ultrapassou dezenas de capítulos e múltiplos volumes.


🧠 PERSONAGENS MAIS IMPORTANTES

🧔 Ojisan

O protagonista.

Mistura de:

  • mago supremo,
  • hikikomori,
  • jogador hardcore,
  • veterano traumatizado,
  • fã fanático da SEGA.

Energia de:

“analista de produção que sobreviveu a 30 anos de incidentes.”


👦 Takafumi

O sobrinho.

Ele funciona como:

  • audiência,
  • intérprete do caos,
  • operador do “console emocional” do anime.

❄️ Elf-san

Uma das personagens mais famosas.

Tsundere lendária.

O Ojisan NÃO percebe absolutamente NADA do que ela sente.

ZERO.

Capacidade social menor que documentação de sistema legado.


🔥 O QUE TORNA O ANIME ESPECIAL?

1️⃣ O protagonista NÃO é cool

Ele é estranho.
Desconfortável.
Socialmente quebrado.

E isso torna tudo mais humano.


2️⃣ O anime entende solidão masculina

Poucos animes falam disso tão bem.


3️⃣ A nostalgia é REAL

As referências não parecem marketing.
Parecem memórias verdadeiras.


4️⃣ O timing cômico é perfeito

As pausas…
os silêncios…
as reações…

Tudo é calculado.


🎮 EASTER EGGS E REFERÊNCIAS ESCONDIDAS

🔵 Sonic

Há inúmeras referências visuais e sonoras.


🕹️ Sega Saturn

Quase um personagem secundário do anime.


⚔️ JRPGs clássicos

O anime ironiza:

  • Final Fantasy,
  • Dragon Quest,
  • jogos dos anos 90.

💀 Cultura gamer antiga

Memory cards.
Locadoras.
Revistas de games.
Consoles esquecidos.

Isso bate forte em quem viveu a época.


☕ CURIOSIDADES

💣 A Netflix ajudou a popularizar o anime mundialmente

Muita gente descobriu a obra fora do Japão graças ao streaming.


💣 O anime viralizou em memes

Principalmente:

  • expressões do Ojisan,
  • obsessão pela SEGA,
  • incapacidade social extrema.

💣 O autor quase não aparece publicamente

Existe um ar misterioso ao redor do criador.


📺 GUIA PARA ASSISTIR

Ordem correta:

Muito simples.

1️⃣ Assista a temporada única

  • Episódios 1 ao 13

2️⃣ Continue no mangá

O anime não cobre tudo.


🔥 PARA QUEM ESSE ANIME É INDICADO?

✔️ Quem gosta de:

  • humor nonsense,
  • cultura gamer retrô,
  • isekai,
  • comédia inteligente,
  • referências obscuras,
  • personagens quebrados emocionalmente.

❌ Talvez NÃO agrade:

  • quem busca ação séria,
  • fantasia épica tradicional,
  • romance convencional.

💣 O “EFEITO MAINFRAME” DO ANIME

Existe algo MUITO curioso aqui.

O Ojisan lembra vários veteranos de tecnologia:

  • extremamente inteligentes,
  • dominam sistemas complexos,
  • mas completamente desconectados socialmente.

Ele parece aquele especialista lendário que:

  • conhece assembler de cabeça,
  • resolve dump em minutos,
  • mas responde e-mail com uma frase de 1998.

☕ RESUMO FINAL

Isekai Ojisan é:

  • uma paródia,
  • uma comédia,
  • uma crítica social,
  • uma carta de amor aos games antigos,
  • e um estudo sobre isolamento.

Tudo embrulhado num caos absoluto.

É um anime que parece piada…
mas esconde MUITA melancolia por trás do humor.

E talvez seja exatamente isso que o torna tão memorável.


🔥 NOTA BELLACOSA MAINFRAME

☕ Curiosidade Técnica:

Se o Ojisan trabalhasse num datacenter IBM Z provavelmente:

  • defenderia COBOL com a alma,
  • brigaria pela SEGA no horário do almoço,
  • faria IPL usando magia elemental,
  • e resolveria incidente crítico enquanto discute Dreamcast.

E sinceramente?

Eu assistiria esse spin-off. ☕🔥


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