☕ 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

quarta-feira, 3 de julho de 2024

💫 10 Animes que Exploraram o Escapismo Virtual — A Realidade Dentro da Tela


Bellacosa Mainframe e o escapismo virtual no mundo dos animes


💫 10 Animes que Exploraram o Escapismo Virtual — A Realidade Dentro da Tela

O escapismo virtual é um dos temas mais fascinantes da cultura otaku moderna. Esses animes não falam apenas sobre mundos digitais, mas sobre pessoas que se perdem (ou se encontram) dentro deles.
Abaixo, uma lista ao estilo Bellacosa — com sinopses, curiosidades e pequenas doses de reflexão.

Prefacio

O escapismo virtual é o ato de buscar, por meio de jogos, animes, realidade virtual, redes sociais ou mundos digitais, uma pausa das pressões e dificuldades da vida cotidiana. Longe de ser um fenômeno exclusivamente moderno, o ser humano sempre utilizou histórias, literatura e fantasia para imaginar outras realidades. A tecnologia apenas tornou essa experiência mais imersiva e interativa.

As razões para esse comportamento são variadas. Estresse, ansiedade, solidão, excesso de responsabilidades ou simplesmente o desejo de viver aventuras impossíveis levam muitas pessoas a explorar universos fictícios. Animes isekai, MMORPGs e experiências em realidade virtual oferecem a oportunidade de assumir novas identidades, superar desafios e conquistar objetivos que podem parecer inalcançáveis no mundo real.

Quando praticado com equilíbrio, o escapismo traz benefícios importantes. Ele estimula a criatividade, reduz temporariamente o estresse, fortalece amizades em comunidades online e pode servir como fonte de inspiração para estudos, carreira e desenvolvimento pessoal. Muitas pessoas encontram motivação em personagens que enfrentam dificuldades semelhantes às suas.

Entretanto, o excesso pode causar isolamento social, dependência digital, prejuízo aos estudos, ao trabalho e aos relacionamentos. O desafio está em transformar a fantasia em combustível para a vida real, e não em um substituto dela. 

O melhor caminho é aproveitar o entretenimento como uma forma saudável de descanso e aprendizado, mantendo o equilíbrio entre o mundo virtual e as responsabilidades do cotidiano. Afinal, as melhores histórias não são apenas aquelas que assistimos, mas também as que construímos em nossa própria jornada.


1️⃣ Sword Art Online (2012)

Autor: Reki Kawahara
Personagens: Kirito, Asuna, Klein, Sinon
Sinopse: Em 2022, jogadores ficam presos em um MMORPG onde morrer no jogo significa morrer na vida real. Kirito precisa lutar para sobreviver e reencontrar Asuna.
Dica Bellacosa: Observe como o anime trata o vício e o amor como forças de sobrevivência.
Curiosidade: O conceito de “full dive” influenciou diversas obras posteriores sobre VR e metaverso.


2️⃣ Log Horizon (2013)

Autor: Mamare Touno
Personagens: Shiroe, Akatsuki, Naotsugu, Nyanta
Sinopse: Após uma atualização do jogo Elder Tale, milhares de jogadores ficam presos. Diferente de SAO, aqui o foco é na construção de sociedade e ética digital.
Dica Bellacosa: Repare no discurso político — é uma aula sobre governança e convivência.
Curiosidade: A guilda “Log Horizon” simboliza o equilíbrio entre razão e emoção dentro do caos.


3️⃣ No Game No Life (2014)

Autor: Yuu Kamiya
Personagens: Sora, Shiro, Stephanie Dola, Jibril
Sinopse: Irmãos prodígios são transportados para um mundo onde tudo é decidido por jogos — inclusive guerras.
Dica Bellacosa: Um espetáculo visual e filosófico sobre meritocracia e genialidade.
Curiosidade: O autor é brasileiro naturalizado japonês — um dos raros casos no mundo dos animes.


4️⃣ Re:Zero – Starting Life in Another World (2016)

Autor: Tappei Nagatsuki
Personagens: Subaru, Emilia, Rem, Ram
Sinopse: Subaru é transportado para outro mundo e descobre que morre e revive em ciclos. Cada “reset” o leva à beira da loucura.
Dica Bellacosa: Um retrato profundo da culpa, trauma e redenção.
Curiosidade: O autor escreveu os primeiros capítulos como webnovel antes do sucesso editorial.


5️⃣ Overlord (2015)

Autor: Kugane Maruyama
Personagens: Ainz Ooal Gown, Albedo, Shalltear, Demiurge
Sinopse: O jogador Momonga decide permanecer logado no último dia de um MMORPG e acorda no corpo de seu personagem — agora em um mundo real.
Dica Bellacosa: Analise o poder absoluto e o vazio existencial que ele traz.
Curiosidade: O anime mistura política e fantasia com uma filosofia sombria sobre controle e identidade.


6️⃣ Accel World (2012)

Autor: Reki Kawahara
Personagens: Haruyuki, Kuroyukihime, Takumu, Chiyuri
Sinopse: Um jovem inseguro descobre um programa secreto que acelera o tempo mental e o transporta para batalhas em realidade aumentada.
Dica Bellacosa: Um olhar delicado sobre autoestima e desejo de ser notado.
Curiosidade: O anime se passa no mesmo universo de Sword Art Online, anos depois.


7️⃣ Serial Experiments Lain (1998)

Autor: Chiaki J. Konaka
Personagens: Lain Iwakura, Arisu, Eiri Masami
Sinopse: Lain mergulha na rede “Wired”, onde a consciência humana e a internet começam a se fundir.
Dica Bellacosa: Experimente assistir mais de uma vez — é denso, filosófico e perturbador.
Curiosidade: Antecipou conceitos de metaverso e IA décadas antes do termo existir.


8️⃣ Digimon Adventure (1999)

Autor: Akiyoshi Hongo
Personagens: Tai, Matt, Sora, Agumon
Sinopse: Crianças são transportadas para o “Mundo Digital” e precisam equilibrar coragem e amizade para retornar.
Dica Bellacosa: Apesar do público infantil, traz reflexões adultas sobre amadurecimento.
Curiosidade: O primeiro grande anime a popularizar o conceito de “mundo digital paralelo”.


9️⃣ Btooom! (2012)

Autor: Junya Inoue
Personagens: Ryouta, Himiko, Taira
Sinopse: Jogadores são sequestrados e levados a uma ilha onde precisam jogar Btooom! — agora em sua versão mortal.
Dica Bellacosa: Uma metáfora sobre vício e violência como forma de validação.
Curiosidade: O criador admitiu se inspirar em Battle Royale e Call of Duty.


🔟 Summer Wars (2009)

Diretor: Mamoru Hosoda
Personagens: Kenji, Natsuki, King Kazma
Sinopse: Um estudante é envolvido em uma crise digital global quando um vírus ameaça destruir o mundo virtual OZ, que sustenta toda a vida moderna.
Dica Bellacosa: Assista como um espelho da nossa dependência tecnológica.
Curiosidade: O filme antecipa temas de metaverso, IA e colapso de rede com precisão assustadora.


Reflexão Final Bellacosa

Cada um desses animes mostra que o escapismo não é fuga covarde — é um espelho da alma moderna.
A fronteira entre “online” e “real” está cada vez mais borrada, e o que esses mundos digitais revelam é simples: buscamos significado, mesmo quando o encontramos em pixels.


Entre o sonho e a realidade, o escapismo é apenas o caminho que usamos para nos reencontrar.

terça-feira, 2 de julho de 2024

☕💣 PADAWAN, O TERMINAL ACABOU DE GANHAR UMA CONSCIÊNCIA!

 

Bellacosa Mainframe o terminal acabou de ganhar consciencia

☕💣 PADAWAN, O TERMINAL ACABOU DE GANHAR UMA CONSCIÊNCIA!

A Evolução da IA Generativa Explicada para um Desenvolvedor COBOL

Se você é um desenvolvedor COBOL, provavelmente já viveu várias revoluções tecnológicas.

Você viu:

  • Cartões perfurados virarem JCL.

  • Terminais 3270 substituírem processos manuais.

  • CICS revolucionar o processamento online.

  • DB2 transformar o armazenamento corporativo.

  • Internet chegar ao mundo mainframe.

  • APIs REST invadirem ambientes z/OS.

  • Cloud tentar substituir tudo (e descobrir que o mainframe continua vivo).

Agora estamos diante de mais uma transformação:

A Inteligência Artificial Generativa.

E talvez você esteja se perguntando:

"Mas afinal, o que isso tem a ver comigo?"

A resposta é:

Muito mais do que parece.


A História Começou Muito Antes do ChatGPT

Quando as pessoas ouvem falar de IA Generativa, imaginam algo surgido em 2022.

Mas a história começou décadas atrás.


Década de 1950

Alan Turing propõe uma pergunta:

"As máquinas podem pensar?"

Nascia a computação moderna.

Enquanto isso, os ancestrais do mainframe já estavam surgindo.


Década de 1960

Pesquisadores começam a criar sistemas especialistas.

A ideia era simples:

SE condição
ENTÃO ação

Parece familiar?

Praticamente um IF COBOL.


Década de 1980

Surgem as primeiras redes neurais modernas.

O problema?

Faltava poder computacional.

Imagine executar um treinamento de IA num IBM 3090.

Não era impossível.

Era economicamente inviável.


O Mundo Mudou em Três Etapas

A IA moderna nasceu da combinação de três fatores.


1. Dados

Internet.

Redes sociais.

Documentos digitais.

Logs.

Vídeos.

Fotos.

PDFs.

Código-fonte.

O mundo passou a gerar dados em escala absurda.


2. Hardware

GPUs.

Inicialmente criadas para jogos.

Depois descobriram:

"Essas placas são excelentes para matemática paralela."

Foi um divisor de águas.


3. Algoritmos

A terceira peça surgiu em 2017.

Um artigo mudou tudo.

Chamava-se:

Attention Is All You Need

Ali nasceu o Transformer.

A arquitetura usada até hoje.


O Que é um LLM?

LLM significa:

Large Language Model

Modelo de Linguagem de Grande Escala.

Pense nele como um gigantesco programa que aprendeu padrões de linguagem.


Uma Analogia Mainframe

Imagine um programador COBOL com:

  • 50 anos de experiência

  • acesso a bilhões de livros

  • milhões de programas

  • milhões de manuais

Ele leu tudo.

Memorizou padrões.

Mas não decorou respostas.

Aprendeu relacionamentos.

É isso que um LLM faz.


Como um LLM Aprende?

Durante o treinamento ele recebe frases como:

O céu é azul.

Depois:

O céu é _____

Ele tenta prever.

azul

Acerta?

Ganha pontos.

Erra?

Ajusta os pesos internos.

Repete isso trilhões de vezes.


O Conceito de Tokens

Para um COBOLista, pense assim:

O computador não vê palavras.

Ele vê tokens.

Exemplo:

MAINFRAME

Pode virar:

MAIN
FRAME

ou

MAINFRAME

dependendo do modelo.

Tudo é quebrado em pedaços.


O Que é um Prompt?

Prompt é simplesmente a entrada.

Como um SYSIN.

Exemplo:

GERAR RELATORIO

é o equivalente moderno de:

//SYSIN DD *
GERAR RELATORIO
/*

A IA executa baseada no que você fornece.


A Evolução dos Prompts

No início as pessoas escreviam:

Faça uma newsletter.

Resultado ruim.

Depois descobriram:

Você é um especialista em comunicação interna.

Objetivo:
Criar uma newsletter.

Formato:
Resumo executivo
Benefícios
CTA

Resultado muito melhor.


O Nascimento da Engenharia de Prompt

Surge então uma nova disciplina:

Prompt Engineering.

Basicamente:

Como conversar corretamente com uma IA.


O Que é um Agente?

Aqui a coisa fica interessante.

Um LLM sozinho apenas responde.

Um Agente faz mais.


Exemplo

Você pede:

Faça um relatório de vendas.

O agente:

  1. Consulta banco.

  2. Busca arquivos.

  3. Faz cálculos.

  4. Gera gráficos.

  5. Cria PDF.

Tudo sozinho.


Analogia Mainframe

Pense num JOB.

STEP01 EXTRAI
STEP02 ORDENA
STEP03 CALCULA
STEP04 IMPRIME

Um agente é parecido.

Só que decide sozinho qual STEP executar.


O Que é RAG?

Outra sigla importante.

RAG:

Retrieval Augmented Generation

Sem RAG:

A IA responde usando o treinamento.


Com RAG:

A IA consulta documentos antes de responder.


Imagine:

Manual CICS
Manual DB2
Normas RACF

O sistema consulta esses documentos.

Depois responde.


Como Instalar Seu Ambiente

Hoje existem três caminhos.


Caminho 1 - Usar Serviços Prontos

Mais fácil.

Exemplos:

  • ChatGPT

  • Claude

  • Gemini

Nenhuma instalação.


Caminho 2 - Rodar Localmente

Você baixa um modelo.

Exemplos:

  • Llama

  • Mistral

  • Gemma

  • Qwen

Ferramentas:

  • Ollama

  • LM Studio


Instalação do Ollama

Windows:

winget install Ollama.Ollama

Linux:

curl -fsSL https://ollama.com/install.sh | sh

Executar:

ollama run llama3

Pronto.

Você já possui uma IA local.


Caminho 3 - APIs

Modelo mais usado por empresas.

Você envia:

{
 "prompt":"Explique COBOL"
}

Recebe:

{
 "resposta":"..."
}

Como Funciona Internamente?

Imagine um programa COBOL.


Entrada:

Explique VSAM.

O modelo transforma isso em números.

Milhares deles.


Esses números passam por centenas de camadas matemáticas.


Cada camada calcula probabilidades.


No final:

VSAM é...

surge token por token.


Por Que Parece Inteligente?

Porque o modelo aprendeu padrões absurdamente complexos.

Mas atenção.

Ele não pensa.

Ele prevê.


Da mesma forma que um SORT organiza registros.

O modelo organiza probabilidades.


Como Evoluir Como Desenvolvedor?

Primeiro erro:

Quero criar uma IA.

Não.

Comece usando IA.


Fase 1

Aprenda prompts.

Exercícios:

  • Resumos

  • Documentação

  • SQL

  • COBOL


Fase 2

Aprenda APIs.

Exemplo:

from openai import OpenAI

Fase 3

Aprenda RAG.

Conecte:

  • PDFs

  • Manuais

  • Wikis


Fase 4

Aprenda Agentes.

Ferramentas:

  • N8N

  • LangChain

  • CrewAI

  • OpenAI Agents


Fase 5

Crie Soluções Reais

Exemplos:

  • Assistente JCL

  • Assistente RACF

  • Assistente DB2

  • Gerador de documentação COBOL

  • Conversor COBOL → API


Oportunidades para Mainframe

Pouca gente percebe.

Mas o mercado precisa desesperadamente de IA para ambientes legados.


Exemplo 1

Análise automática de programas COBOL.


Exemplo 2

Documentação automática.


Exemplo 3

Mapeamento de dependências.


Exemplo 4

Explicação de JCL.


Exemplo 5

Geração de testes.


Como Criar Sua Própria Solução

Método simples.


Passo 1

Escolha um problema.

Exemplo:

Explicar programas COBOL antigos.

Passo 2

Colete conhecimento.

Exemplo:

Manuais
Normas
Fontes COBOL

Passo 3

Construa um RAG.


Passo 4

Crie prompts.


Passo 5

Automatize.

Use:

  • N8N

  • Python

  • APIs


O Futuro

Estamos apenas no começo.

A evolução foi:

Dados
↓
Informação
↓
Sistemas
↓
Internet
↓
Cloud
↓
IA Generativa
↓
Agentes
↓
Sistemas Autônomos

Da mesma forma que o COBOL não morreu porque resolve problemas reais, a IA também não substituirá tudo.

O que está acontecendo é a criação de uma nova camada de produtividade.


Conclusão

Para um desenvolvedor COBOL, a IA Generativa não é um inimigo.

Ela é semelhante ao que CICS foi para o processamento online, ao que DB2 foi para os bancos relacionais ou ao que o z/OS Connect é para APIs modernas.

A diferença é que agora a matéria-prima não são registros, arquivos VSAM ou tabelas DB2.

A matéria-prima é conhecimento.

Quem já entende processos corporativos, regras de negócio, integração de sistemas e décadas de experiência acumulada possui uma enorme vantagem. A IA sabe gerar texto, código e documentação. O profissional de mainframe sabe como as empresas realmente funcionam.

E essa combinação pode criar algo extremamente poderoso: agentes inteligentes capazes de conversar com sistemas legados, documentar aplicações, acelerar modernizações e preservar conhecimentos que hoje estão presos em milhões de linhas de COBOL espalhadas pelo mundo.

☕💣 O operador do futuro não será apenas quem executa jobs. Será quem ensinará agentes de IA a entender os jobs que mantêm o mundo funcionando.


segunda-feira, 1 de julho de 2024

☕💣🤖 DO VINIL AO ALGORITMO — COMO A HUMANIDADE PASSOU 50 ANOS TENTANDO FAZER DEPLOY DO DESEJO EM HARDWARE

Bellacosa Mainframe e as sexdolls entre o moral e imoral


☕💣🤖 DO VINIL AO ALGORITMO — COMO A HUMANIDADE PASSOU 50 ANOS TENTANDO FAZER DEPLOY DO DESEJO EM HARDWARE

Existem histórias da tecnologia que falam sobre computadores.

Outras falam sobre foguetes.

Algumas falam sobre inteligência artificial.

Mas existe uma história paralela, quase sempre escondida nos bastidores da cultura, da política, da religião e da engenharia.

A história de como a humanidade tentou transformar companhia, desejo e intimidade em tecnologia.

O que começou como uma simples boneca inflável tornou-se, meio século depois, uma indústria que combina:

  • robótica;

  • inteligência artificial;

  • sensores biométricos;

  • modelos de linguagem;

  • computação emocional.

E talvez nenhuma outra evolução tecnológica revele tanto sobre os seres humanos quanto essa.


OS ANOS 1970 — O TERMINAL BURRO DA INTIMIDADE

As primeiras bonecas infláveis modernas eram, essencialmente, terminais sem processamento.

Não havia interação.

Não havia memória.

Não havia resposta.

Era apenas um objeto físico.

Mas mesmo naquele estágio rudimentar, já existia uma pergunta escondida.

Por que alguém desejaria companhia artificial?

A resposta quase nunca foi tecnológica.

Era emocional.


OS ANOS 1980 — A ERA DOS MATERIAIS

A indústria começou a investir em:

  • vinil;

  • látex;

  • silicone.

O objetivo era simples.

Fazer o hardware parecer mais humano.

Curiosamente, durante décadas a evolução ficou quase toda concentrada na aparência.

Era como aumentar a capacidade de armazenamento de um computador sem melhorar seu software.


OS ANOS 1990 — A INTERNET ENTRA NO CIRCUITO

Com a popularização da internet, comunidades inteiras começaram a discutir relacionamentos artificiais.

Foi também quando a ficção científica explodiu no imaginário popular.

Filmes como:

  • Blade Runner;

  • A.I. Inteligência Artificial;

  • Ghost in the Shell;

levantavam perguntas desconfortáveis.

O que acontece quando uma máquina parece humana?

E mais importante:

o que acontece quando começamos a tratá-la como humana?


OS ANOS 2000 — O NASCIMENTO DOS PRIMEIROS "PROTÓTIPOS SOCIAIS"

A virada do milênio trouxe algo novo.

A ideia de que a companhia artificial poderia ir além da aparência.

Pesquisadores começaram a estudar:

  • robótica social;

  • computação afetiva;

  • reconhecimento emocional;

  • interação humano-máquina.

O foco começou a migrar.

Menos silicone.

Mais software.


2010 — O IPL DOS SEXBOTS

Em 2010 surge Roxxxy.

Hoje ela parece tecnologicamente limitada.

Mas historicamente foi revolucionária.

Pela primeira vez um fabricante dizia claramente:

Não estamos vendendo apenas um objeto.

Estamos vendendo companhia.

Foi um marco.

O nascimento do chatbot com corpo.


2015 — O FIREWALL DOS CONSERVADORES

Quando os primeiros robôs sociais começaram a aparecer, vieram também os críticos.

Acadêmicos.

Religiosos.

Conservadores.

Feministas.

Psicólogos.

Especialistas em ética.

Os argumentos eram variados.

Alguns temiam:

  • objetificação humana;

  • isolamento social;

  • dependência emocional;

  • erosão da empatia.

Outros enxergavam uma ameaça moral.

Muitos líderes religiosos argumentavam que relacionamentos artificiais poderiam enfraquecer estruturas tradicionais de família, casamento e convivência social.

Pela primeira vez a discussão deixou os laboratórios.

Entrou na arena cultural.


A GUERRA DAS NARRATIVAS

Curiosamente, ninguém discutia apenas tecnologia.

Havia duas visões opostas.

Narrativa otimista

Os defensores argumentavam:

  • ajuda para pessoas solitárias;

  • suporte emocional;

  • companhia para idosos;

  • acessibilidade para pessoas com deficiência;

  • novas formas de interação.

Narrativa pessimista

Os críticos alertavam:

  • substituição de relacionamentos reais;

  • dependência psicológica;

  • isolamento;

  • reforço de comportamentos problemáticos.

A mesma tecnologia.

Dois futuros completamente diferentes.


O SURGIMENTO DOS NOVOS MODELOS

Ao longo dos anos surgiram diversas categorias.

Bonecas estáticas

Sem eletrônica.

Sem software.

Apenas representação física.

Bonecas premium

Silicone avançado.

Personalização extrema.

Maior realismo.

Robôs animatrônicos

Movimentos simples.

Expressões limitadas.

Resposta programada.

Sexbots sociais

Conversação.

Memória.

Reconhecimento de voz.

Personalidade configurável.

Companheiros digitais

Sem corpo físico.

Apenas software.

Aplicativos.

Avatares.

IA conversacional.

Companheiros híbridos

Integração entre corpo robótico e inteligência artificial avançada.

O estágio para o qual a indústria parece caminhar.


O ESTADO OBSERVA O DEPLOY

Governos do mundo inteiro reagiram de maneiras diferentes.

Alguns países focaram em:

  • regulamentação de importação;

  • classificação etária;

  • proteção do consumidor;

  • proteção de dados.

Outros discutiram limitações para determinados tipos de representação considerados problemáticos.

O desafio jurídico é enorme.

Porque muitas leis foram criadas para regular relações entre seres humanos.

Não entre humanos e sistemas artificiais.


A ERA DA IA GENERATIVA

Então chegou a verdadeira revolução.

Não foi um novo robô.

Foi o software.

Modelos de linguagem.

IA generativa.

Memória contextual.

Personalização em escala.

A partir desse momento, o cérebro artificial começou a evoluir mais rápido que o corpo artificial.


O QUE O IMAGINÁRIO POPULAR SEMPRE SOUBE

A parte mais curiosa é que a ficção científica previu tudo isso.

Décadas antes da tecnologia existir.

Blade Runner.

Her.

Ex Machina.

Westworld.

A.I.

Todas faziam a mesma pergunta.

Não:

"As máquinas poderão amar?"

Mas:

"Os humanos aceitarão amar máquinas?"


O MAINFRAME DA CONDIÇÃO HUMANA

Depois de cinquenta anos de evolução, a pergunta continua praticamente a mesma.

As máquinas ficaram mais inteligentes.

Mais bonitas.

Mais sofisticadas.

Mais responsivas.

Mais personalizáveis.

Mas a discussão nunca foi realmente sobre elas.

Sempre foi sobre nós.

Sobre solidão.

Sobre desejo.

Sobre companhia.

Sobre pertencimento.

Sobre a busca humana por conexão.

Talvez a maior descoberta desses cinquenta anos não seja que conseguimos construir máquinas capazes de simular afeto.

Talvez seja que descobrimos o quanto os seres humanos desejam acreditar que estão sendo compreendidos.

Mesmo quando do outro lado existe apenas software.

☕💣🤖 E talvez esse seja o deploy mais complexo da história da civilização: não o da inteligência artificial, mas o da própria condição humana executando em um novo hardware.




☕💣🤖 TABOO — A Cronologia do Afeto Artificial

Do robô Roxxxy aos companheiros digitais alimentados por inteligência artificial, esta experiência interativa reúne análises sobre robótica social, ética da IA, solidão digital, relacionamentos sintéticos e o futuro da intimidade humana.

☕💣🤖 PROJETO TABOO
Afeto Artificial, IA, Robôs Sexuais e o Futuro dos Relacionamentos Humanos
Uma investigação Bellacosa Mainframe sobre inteligência artificial, companhia digital, robótica social, solidão tecnológica, relacionamentos sintéticos e os limites entre software e humanidade.
🚀 ABRIR PROJETO
STATUS: ONLINE

domingo, 30 de junho de 2024

☕🍖💣 DUNGEON MESHI — O DIA EM QUE A EQUIPE DE PRODUÇÃO FICOU SEM ORÇAMENTO E COMEÇOU A PROCESSAR OS PRÓPRIOS ERROS DO SISTEMA

Bellacosa Mainframe e as delicias de Dungeon Meshi

 

☕🍖💣 DUNGEON MESHI — O DIA EM QUE A EQUIPE DE PRODUÇÃO FICOU SEM ORÇAMENTO E COMEÇOU A PROCESSAR OS PRÓPRIOS ERROS DO SISTEMA

Se existe um anime que um profissional de Mainframe entende intuitivamente, esse anime é Dungeon Meshi.

Porque, no fundo, não é uma história sobre monstros.

É uma história sobre eficiência operacional, reaproveitamento de recursos, sobrevivência em ambiente hostil e administração de crises.

Ou seja:

é praticamente um curso de Produção Mainframe disfarçado de fantasia medieval.


Ficha Técnica

Título Original

Dungeon Meshi (ダンジョン飯)

Literalmente:

"Refeição da Masmorra"

Título internacional:

Delicious in Dungeon


Autor

Ryoko Kui

Mangá publicado entre:

2014 e 2023


Anime

  • Estúdio: Trigger

  • Direção: Yoshihiro Miyajima

  • Estreia: 4 de janeiro de 2024

  • Distribuição mundial: Netflix


Episódios

24 episódios (1ª temporada)

Adaptando aproximadamente metade da história do mangá.


Classificação

14 anos


Gêneros

  • Fantasia

  • Aventura

  • Comédia

  • Culinária

  • RPG

  • Drama

  • Mistério


A Sinopse Sem Spoilers

Um grupo de aventureiros invade uma gigantesca masmorra.

Durante uma batalha contra um dragão vermelho, tudo dá errado.

A irmã do protagonista fica presa.

Sem dinheiro.

Sem suprimentos.

Sem recursos.

Sem tempo.

A equipe decide retornar imediatamente.

Mas existe um problema:

não há comida.

A solução?

Comer os monstros encontrados pelo caminho.

E assim nasce uma das premissas mais absurdas e geniais dos animes modernos.


A História Vista por um Operador Mainframe

Imagine que seu banco perdeu o orçamento.

O storage está lotado.

O processamento cresceu.

A verba acabou.

E o gerente diz:

— Vagner, precisamos continuar.

Você responde:

— Com quais recursos?

Ele responde:

— Os que já existem.

Pronto.

Isso é Dungeon Meshi.


O Grande Diferencial

Todo anime de fantasia mostra:

  • Heróis

  • Magos

  • Dragões

  • Tesouros

Dungeon Meshi pergunta algo que ninguém havia perguntado:

"Mas o que eles comem?"

Parece simples.

Mas essa pergunta muda completamente o universo.


O Mundo Mais Coerente dos Últimos Anos

Ryoko Kui construiu uma fantasia baseada em lógica.

Cada criatura possui:

  • ecologia

  • cadeia alimentar

  • comportamento

  • habitat

  • anatomia

Os monstros não existem apenas para serem derrotados.

Eles fazem parte de um ecossistema funcional.

Isso faz o mundo parecer real.


Os Personagens

Laios

O protagonista.


No papel:

  • guerreiro

  • líder

Na prática:

  • pesquisador de monstros

  • nerd da biologia fantástica

É o cara que encontra um bug crítico e fica feliz porque poderá estudá-lo.


Marcille

A maga.

Responsável pela voz da razão.

Ou pelo menos tenta.

Passa boa parte da série horrorizada com os pratos preparados por Senshi.

Representa o analista que ainda acredita em documentação formal.


Chilchuck

Especialista em armadilhas.

Pragmático.

Cínico.

Experiente.

É o operador que já viu todos os erros possíveis.


Senshi

O verdadeiro MVP.

O cozinheiro.

O mestre da sobrevivência.

O veterano que conhece cada detalhe da infraestrutura.

Se fosse um ambiente z/OS seria o sujeito que está há 35 anos na empresa e conhece todos os JCLs críticos.


Falin

Embora apareça menos inicialmente, é o coração emocional da narrativa.

Toda a aventura gira ao seu redor.


As Aventuras

Cada episódio parece uma missão simples.

Mas existe uma estrutura inteligente.

O grupo enfrenta:

  • cogumelos vivos

  • armaduras ambulantes

  • basiliscos

  • golems

  • espíritos

  • dragões

  • criaturas mágicas

Porém o foco não é derrotá-los.

É compreendê-los.

Depois cozinhá-los.


O Humor

Dungeon Meshi é engraçado porque trata absurdos com total seriedade.

Imagine uma reunião corporativa sobre:

  • riscos

  • compliance

  • governança

Mas o assunto é:

como preparar um basilisco grelhado.

Esse contraste gera a comédia.


A Mensagem Oculta

A maioria das pessoas vê apenas culinária.

Mas a série fala sobre algo muito maior.

Adaptação

Quem sobrevive não é o mais forte.

É quem se adapta.


Sustentabilidade

Nada é desperdiçado.

Tudo possui utilidade.


Conhecimento

O medo vem da ignorância.

Quando compreendemos algo, ele deixa de parecer monstruoso.


Cooperação

Nenhum personagem consegue avançar sozinho.

O grupo funciona porque cada membro cobre uma deficiência dos demais.

Exatamente como uma equipe de TI.


O Que Quase Ninguém Percebe

Dungeon Meshi é uma crítica ao consumismo de RPG.

Nos jogos:

  • monstros são recursos infinitos

  • comida aparece magicamente

  • logística não existe

Ryoko Kui pergunta:

"E se tudo isso tivesse consequências?"

O resultado é um universo muito mais profundo.


Quando a Série Fica Sombria

Muitos entram esperando uma comédia culinária.

E então descobrem algo inesperado.

A partir da metade da história:

  • temas existenciais

  • identidade

  • desejo

  • obsessão

  • natureza humana

passam a dominar a narrativa.

A série fica surpreendentemente madura.


O Trabalho do Studio Trigger

O Trigger é famoso por:

  • Kill la Kill

  • Little Witch Academia

  • Cyberpunk Edgerunners

Muitos esperavam ação exagerada.

Mas o estúdio fez algo diferente.

Criou uma adaptação extremamente respeitosa ao mangá.

A animação enfatiza:

  • expressões faciais

  • detalhes culinários

  • ecossistemas

  • monstros

O resultado é impecável.


Houve Censura?

Praticamente não.

O anime preserva a maior parte do conteúdo do mangá.

Algumas cenas tiveram pequenas adaptações de enquadramento e ritmo.

Mas não ocorreu censura significativa.

O tom original foi mantido.


Impacto Cultural

Dungeon Meshi produziu algo raro.

Criou um novo subgênero popular:

Fantasy Gourmet.

Após seu sucesso, houve crescimento de obras misturando:

  • fantasia

  • culinária

  • sobrevivência

  • worldbuilding

Além disso, tornou-se referência de construção de mundo.

Hoje muitos fãs consideram Dungeon Meshi um dos universos mais bem planejados dos animes modernos.


A Grande Lição Para Quem Trabalha com Mainframe

No fim, Dungeon Meshi ensina algo que todo veterano de TI aprende cedo:

Quando o orçamento acaba...

Quando os recursos desaparecem...

Quando a documentação sumiu...

Quando o sistema parece impossível...

Você não para.

Você entende o ambiente.

Reaproveita o que existe.

Aprende como ele funciona.

E continua avançando.

Senshi chamaria isso de culinária.

Um profissional Mainframe chamaria de:

sobrevivência em produção.

E talvez seja exatamente a mesma coisa. ☕🍖💣


terça-feira, 25 de junho de 2024

🕵️ The Mentalist no Mainframe — O Caso dos R$ 100 que Atravessaram um Sistema de Cartões

 

Bellacosa Mainframe e o sistema de cartões

☕ Um Café no Bellacosa Mainframe

🕵️ The Mentalist no Mainframe — O Caso dos R$ 100 que Atravessaram um Sistema de Cartões

Compra → captura → autorização → resposta → clearing → settlement → reconciliação

Imagine Patrick Jane entrando em um grande banco.

Nada de CBI. Nada de assassinato. Nenhuma fita amarela isolando a cena do crime.

Desta vez há uma War Room.

Nas paredes, enormes monitores exibem gráficos de CICS, filas de mensagens, utilização de CPU, tempos de resposta, quantidade de transações aprovadas e recusadas.

Analistas observam SDSF.

Programadores procuram mensagens nos logs.

DBAs verificam Db2.

Especialistas de infraestrutura garantem:

— O mainframe está normal.

O pessoal de redes responde:

— A comunicação está normal.

O suporte de cartões diz:

— Temos clientes reclamando.

No centro da confusão existe apenas uma transação de R$ 100.

Patrick Jane olha para o quadro durante alguns segundos.

Pega uma xícara de café.

E pergunta:

— Vocês estão procurando R$ 100. Eu quero saber a história desses R$ 100.

Silêncio.

Bem-vindo ao mundo de processamento de cartões.



🕵️ 1. O crime aparentemente perfeito

João entra no Café Bellacosa.

Pede alguma coisa.

Valor:

R$ 100.

Encosta o cartão na maquininha.

A tela apresenta:

PROCESSANDO...

Poucos segundos depois:

APROVADO.

Para João, terminou.

Para o comerciante, aparentemente terminou.

Para quem está começando em mainframe, talvez também pareça que terminou.

Mas para Patrick Jane a investigação acabou de começar.

Porque aquela pequena palavra — APROVADO — esconde uma infraestrutura gigantesca.

Por trás dela encontramos:

  • cardholder;

  • merchant;

  • POS;

  • acquirer;

  • scheme/network;

  • issuer;

  • cadastro;

  • conta de cartão;

  • produto;

  • plafond;

  • autorização;

  • risco;

  • tarifas;

  • clearing;

  • settlement;

  • billing;

  • cobrança;

  • contabilidade;

  • chargeback;

  • reconciliação.

E ainda temos CICS, COBOL, Db2, VSAM, MQ, batch, JCL, logs, auditoria e diversos sistemas distribuídos conversando com o ambiente bancário.

O primeiro ensinamento de Jane seria:

Nunca confunda aquilo que o cliente vê com aquilo que realmente aconteceu nos sistemas.



💳 2. Conhecendo os suspeitos

Antes de investigar qualquer transação precisamos saber quem estava na sala.

Cardholder

É o portador do cartão.

No nosso caso:

João.

Merchant

É o estabelecimento comercial.

Café Bellacosa.

Acquirer

É a instituição adquirente que mantém o relacionamento de aceitação com o estabelecimento e encaminha a transação para o ecossistema apropriado.

Scheme / Network

É a rede/bandeira que estabelece regras e permite a interoperabilidade entre participantes.

Issuer

É o emissor do cartão.

É no lado do issuer que encontramos boa parte da inteligência necessária para decidir:

“Posso autorizar esta compra?”

O fluxo simplificado fica:

JOÃO
 │
 ▼
CAFÉ BELLACOSA
 │
 ▼
MAQUININHA / POS
 │
 ▼
ACQUIRER
 │
 ▼
SCHEME / NETWORK
 │
 ▼
ISSUER

Só que isso ainda é o desenho visto de helicóptero.

Patrick Jane quer entrar no prédio.



🧩 3. Antes do cartão existe o cliente

O banco conhece João antes de conhecer aquela compra.

Existe um universo de cadastro:

CUSTOMER
 │
 ├── identificação
 ├── documentos
 ├── endereço
 ├── contatos
 ├── status
 ├── relacionamento
 └── informações cadastrais

Depois temos a conta de cartão.

E depois os cartões associados.

Uma das primeiras pegadinhas para o iniciante é imaginar:

CLIENTE = CARTÃO

Não.

Podemos ter:

CUSTOMER
   │
   ├── CARD ACCOUNT A
   │       ├── CARD 1
   │       └── ADDITIONAL CARD
   │
   └── CARD ACCOUNT B
           └── CARD 2

O plástico pode vencer.

O cartão pode ser substituído.

O cliente continua existindo.

A conta pode continuar existindo.

Portanto:

CUSTOMER ≠ CARD ACCOUNT ≠ CARD

Esse relacionamento é fundamental.





🏷️ 4. O sistema de produtos entra na investigação

Jane encontra algo interessante no cadastro:

PRODUCT-ID = 003

Ele pergunta:

— O que significa 003?

Alguém responde:

— Bellacard Platinum.

A partir daqui descobrimos outra camada.

Um cartão não é simplesmente “um cartão de crédito”.

Ele pertence a determinado produto.

Imagine:

001 BELLACARD CLASSIC
002 BELLACARD GOLD
003 BELLACARD PLATINUM
004 BELLACARD CORPORATE
005 BELLACARD VIRTUAL

Cada produto pode possuir parâmetros e características diferentes.

PRODUCT
 │
 ├── Network
 ├── Currency
 ├── Billing Rules
 ├── Credit Rules
 ├── Transaction Rules
 ├── Fee Plan
 ├── Interest Rules
 ├── Rewards
 ├── Risk Parameters
 └── Channel Rules

E aqui aparece uma importante filosofia de sistemas financeiros.

Não queremos escrever um COBOL diferente para cada cartão.

Queremos separar:

código

de

política de negócio.

O programa sabe calcular.

O produto e seus parâmetros dizem o que calcular e quais regras aplicar.



💰 5. Plafond — quanto João realmente pode gastar?

Agora chegamos ao limite de crédito, também chamado em diversos contextos de plafond.

Imagine:

PLAFOND TOTAL       R$ 10.000
UTILIZADO           R$  3.000
PENDENTE            R$    500
DISPONÍVEL          R$  6.500

João deseja gastar:

R$ 100

Parece simples.

Mas Jane desconfia de coisas simples.

Porque limite disponível pode depender de muito mais que:

LIMITE - COMPRAS

Podem existir:

  • autorizações pendentes;

  • parcelamentos;

  • reservas;

  • bloqueios;

  • limites temporários;

  • limites específicos por operação;

  • regras internacionais;

  • saques;

  • operações ainda não apresentadas no clearing;

  • ajustes e pagamentos.

Portanto, antes de responder APROVADO, o issuer precisa consultar o contexto financeiro correto.



🧠 6. A sala de interrogatório: Authorization

A mensagem finalmente chega ao autorizador.

No universo mainframe poderíamos imaginar conceitualmente:

NETWORK
   │
   ▼
GATEWAY
   │
   ▼
CICS
   │
   ▼
AUTHORIZATION
   │
   ├── CARD STATUS
   ├── ACCOUNT STATUS
   ├── PRODUCT RULES
   ├── AVAILABLE CREDIT
   ├── RISK/FRAUD
   ├── MERCHANT INFORMATION
   └── SECURITY CONTROLS

Começa o interrogatório.

O cartão existe?

Sim.

Está ativo?

Sim.

Está vencido?

Não.

Está bloqueado?

Não.

A conta está habilitada?

Sim.

O produto permite essa operação?

Sim.

Existe plafond?

Sim.

Os controles de risco permitem continuar?

Sim.

Então:

APPROVED

Pode surgir também um:

AUTHORIZATION CODE

que ajuda a identificar aquela autorização.

Mas aqui está uma das maiores lições deste artigo:

AUTORIZAÇÃO NÃO É LIQUIDAÇÃO.

A aprovação não significa simplesmente:

“R$ 100 já chegaram à conta bancária do Café Bellacosa.”

Significa que aquela solicitação percorreu o processo de autorização e recebeu uma resposta positiva.


🚫 7. Decline — quando Jane diz não

Se alguma regra impedir a autorização, teremos um decline.

Por exemplo:

AVAILABLE CREDIT = R$ 80
PURCHASE         = R$100

Resultado:

DECLINED

Mas insuficiência de limite é apenas uma possibilidade.

Podem existir recusas relacionadas a:

  • status do cartão;

  • vencimento;

  • bloqueio;

  • restrições;

  • produto;

  • risco;

  • tipo de operação;

  • condições da conta.

A grande descoberta aqui é que uma transação não possui apenas dois estados:

EXISTE
NÃO EXISTE

Ela possui um ciclo de vida.

RECEIVED
   ↓
VALIDATING
   ↓
AUTHORIZED
   ↓
CLEARED
   ↓
SETTLED
   ↓
RECONCILED

E pode desviar:

DECLINED
REVERSED
PENDING
DISPUTED
CHARGEBACK

O cartão é praticamente uma gigantesca máquina de estados financeiros.


⏱️ 8. O mistério do timeout

João faz a compra.

O issuer recebe a solicitação.

Processa.

Autoriza.

Envia a resposta.

Mas a resposta se perde pelo caminho.

POS
 │
 ▼
ACQUIRER
 │
 ▼
NETWORK
 │
 ▼
ISSUER
 │
 ├── APPROVED
 │
 X
 X comunicação interrompida
 X

A maquininha pode concluir:

TIMEOUT.

Agora temos um problema fascinante.

Para um sistema:

AUTHORIZED

Para outro:

TIMEOUT

Os sistemas possuem percepções diferentes do mesmo acontecimento.

E isso nos leva a uma das regras de ouro da investigação:

Estado técnico e estado de negócio não são necessariamente a mesma coisa.


🔄 9. Reversal — desfazendo uma autorização

Se uma autorização precisa ser desfeita, podemos encontrar um reversal.

Conceitualmente:

AUTHORIZATION
     │
     ▼
RESERVE / AFFECT AVAILABLE CREDIT

Depois:

REVERSAL
     │
     ▼
RELEASE / ADJUST

Por isso o investigador não pode parar quando encontra:

APPROVED

Precisa continuar:

APPROVED
   │
   ├── REVERSAL?
   │
   ├── CLEARING?
   │
   └── WHAT HAPPENED NEXT?

Jane nunca encerra a investigação na primeira evidência.


👯 10. O caso dos gêmeos: Duplicate Transaction

Agora encontramos:

10:32:01 R$100
10:32:03 R$100

Temos duas compras?

Ou uma transação retransmitida?

Essa é a essência do problema de duplicate transaction.

Para descobrir precisamos correlacionar informações como:

merchant
terminal
amount
timestamps
transaction identifiers
trace/reference numbers
authorization information

dependendo do protocolo e arquitetura envolvidos.

O iniciante procura:

“R$100.”

O especialista pergunta:

“Qual é a identidade dessa transação?”

Essa pergunta vai nos acompanhar até o fim.


📡 11. A maquininha também é um computador administrado

Jane pega a POS do Café Bellacosa.

Ela parece pequena.

Mas possui identidade e configuração.

Conceitualmente podemos encontrar:

TERMINAL-ID
MERCHANT-ID
STORE-ID
SERIAL
MODEL
APPLICATION VERSION
CONFIGURATION
CAPABILITIES
NETWORK PARAMETERS
SECURITY CONTEXT

Ela é um endpoint transacional.

E alguém precisa administrar potencialmente milhares ou milhões desses endpoints.

Entra em cena o:

TMS — Terminal Management System

                   MATRIZ
                     │
                     ▼
                    TMS
                     │
       ┌─────────────┼─────────────┐
       │             │             │
 CONFIGURATION    SOFTWARE     PARAMETERS
       │             │             │
       └─────────────┼─────────────┘
                     │
                  NETWORK
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
       POS          POS          POS

🏢 12. A conversa entre matriz e maquininhas

Precisamos separar duas conversas.

A primeira é a transação financeira:

CARD
 ↓
POS
 ↓
ACQUIRER
 ↓
NETWORK
 ↓
ISSUER

É online.

O cliente está esperando.

Latência importa muito.

A segunda é administrativa:

TMS
 ↓
POS

Pode envolver, conforme a solução:

  • parâmetros;

  • perfis;

  • configurações;

  • versões de aplicação;

  • atualizações;

  • informações operacionais.

Não devemos confundir:

TRANSACTION PROCESSING

com:

TERMINAL MANAGEMENT.


🏪 13. Merchant, loja e terminal

Também precisamos conhecer a hierarquia:

MERCHANT
   │
   ├── STORE 001
   │      ├── POS 001
   │      ├── POS 002
   │      └── POS 003
   │
   └── STORE 002
          ├── POS 004
          └── POS 005

Agora podemos localizar uma transação com muito mais precisão.

Não aconteceu simplesmente no:

Café Bellacosa.

Pode ter ocorrido no:

MERCHANT 8472
STORE    0004
TERMINAL 0009

Para troubleshooting isso é ouro.


🧬 14. A árvore de configuração

Administrar cada terminal individualmente seria impraticável.

Uma arquitetura pode trabalhar com hierarquias conceituais como:

GLOBAL
  ↓
COUNTRY
  ↓
ACQUIRER
  ↓
MERCHANT SEGMENT
  ↓
MERCHANT
  ↓
STORE
  ↓
TERMINAL

Uma configuração global pode valer para enorme quantidade de equipamentos.

Mas podem existir exceções.

GLOBAL
CONTACTLESS = YES

MERCHANT 8472
CONTACTLESS = NO

Então a pergunta de Jane muda.

Ele não pergunta:

“Qual é a configuração global?”

Pergunta:

“Qual era a configuração efetiva desse terminal?”


🔐 15. Segurança — não confie simplesmente em quem bate à porta

A POS também precisa participar de uma arquitetura segura.

O ecossistema de pagamentos utiliza diversos mecanismos e padrões envolvendo conceitos como:

EMV
HSM
KEY MANAGEMENT
CRYPTOGRAPHIC KEYS
CERTIFICATES
PIN SECURITY
MESSAGE INTEGRITY
PCI CONTROLS

A implementação exata depende do ambiente.

Mas o princípio é simples:

Uma maquininha não deveria simplesmente anunciar uma identidade e receber confiança automaticamente.

Identidade, autenticidade, integridade e proteção do material criptográfico são fundamentais.


🏷️ 16. O outro produto que esquecemos

Existe o produto do cardholder.

Mas também existe o lado comercial do merchant.

O adquirente possui relacionamento contratual com o estabelecimento.

MERCHANT
   │
   ├── CONTRACT
   ├── MCC
   ├── SETTLEMENT RULE
   ├── PRICING PLAN
   ├── BANK ACCOUNT
   └── TERMINALS

Portanto temos dois universos:

ISSUER                       ACQUIRER
   │                            │
CARD PRODUCT              MERCHANT PRODUCT
   │                            │
CARDHOLDER                    MERCHANT

Isso explica por que estudar cartões olhando apenas para o issuer deixa metade do mapa em branco.


🏪 17. MCC — que tipo de estabelecimento é esse?

O merchant possui classificação de atividade no ecossistema, incluindo o Merchant Category Code — MCC.

Essa informação pode participar de diferentes regras de:

  • autorização;

  • risco;

  • rewards;

  • relatórios;

  • políticas comerciais;

  • regras da rede.

Imagine um programa de pontos:

RESTAURANT → 2X
GENERAL    → 1X

Aquela pequena classificação passa a produzir consequências em outros sistemas.

Mais uma pista para Jane.


💰 18. O misterioso mundo das tarifas

Agora aparece na fatura:

R$12

Cliente pergunta:

— O que é isso?

Resposta ruim:

— Tarifa.

Patrick Jane imediatamente:

— Qual tarifa? Gerada por qual evento? Segundo qual produto? Sob qual regra? Em qual vigência?

Essa é a investigação correta.

Um sistema de tarifas pode possuir algo como:

FEE-ID
DESCRIPTION
PRODUCT
EVENT
CALCULATION METHOD
VALUE
VALID-FROM
VALID-TO
STATUS

Podemos ter eventos como:

ANNUAL_FEE
CASH_ADVANCE
LATE_PAYMENT
CARD_REPLACEMENT
SERVICE

conforme contrato, produto e regras aplicáveis.


🧮 19. O Fee Engine

Podemos imaginar:

BUSINESS EVENT
      │
      ▼
   FEE ENGINE
      │
 ┌────┼─────┐
 │    │     │
PRODUCT CUSTOMER CONTRACT
 │    │     │
 └────┼─────┘
      │
    RULE
      │
      ▼
 CALCULATED FEE

Uma tarifa pode ser fixa:

R$12

percentual:

2%

por faixa:

0–1000
1001–5000
>5000

ou condicionada:

IF CUSTOMER-SEGMENT = X
    FEE = 0

Aqui fica clara outra diferença:

regra comercial não deveria ser confundida com lógica fixa enterrada no programa.


💵 20. E quanto o merchant paga?

O estabelecimento também possui seu universo econômico.

No acquiring podemos encontrar conceitos como:

  • MDR;

  • serviços contratados;

  • aluguel/serviços de terminal;

  • condições de recebimento;

  • antecipação de recebíveis;

  • outros componentes comerciais.

No ecossistema existe também interchange, conforme as regras do arranjo.

É importante não confundir:

MDR ≠ INTERCHANGE

E também não concluir que tudo aquilo que o merchant paga pertence ao issuer.

A compra de R$100 possui uma economia inteira escondida por trás dela.


📦 21. Clearing — “a compra voltou”

Algum tempo depois da autorização aparecem informações de clearing.

O iniciante pergunta:

— Mas ela já não tinha sido aprovada?

Sim.

Só que:

AUTHORIZATION

e:

CLEARING

não são a mesma coisa.

Uma maneira didática de pensar é:

Authorization:

“Posso permitir esta operação?”

Clearing:

“Aqui está a transação apresentada para o processamento financeiro correspondente.”

E podem existir situações nas quais valores apresentados e autorizados não sejam simplesmente idênticos.

Hotel é um bom exemplo conceitual:

AUTHORIZATION
R$1.000

FINAL / PRESENTED AMOUNT
R$870

Logo:

AUTHORIZATION ≠ CLEARING

embora os dois façam parte da história da mesma operação.


💰 22. Settlement — agora estamos falando de posições financeiras

Depois chegamos ao settlement.

É aqui que tratamos da liquidação das posições financeiras entre participantes conforme os processos e regras da rede.

Isso destrói outra imagem simplista:

“A mensagem de autorização carregou R$100 de um banco para outro.”

Não.

A autorização é uma decisão online.

Clearing e settlement fazem parte de processos posteriores relacionados ao processamento e liquidação financeira.

A mesma transação possui várias representações durante sua vida.


🧾 23. Billing — agora João precisa pagar

A transação apresentada/postada passa a compor o universo financeiro da conta de cartão conforme o produto.

CARD ACCOUNT
    │
    ├── PURCHASES
    ├── INSTALLMENTS
    ├── INTEREST
    ├── FEES
    ├── CREDITS
    └── ADJUSTMENTS

Chega o fechamento.

Conceitualmente:

SALDO ANTERIOR
+ COMPRAS
+ JUROS
+ TARIFAS
- PAGAMENTOS
- CRÉDITOS
----------------
= FATURA

Agora o sistema de cartão precisa conversar fortemente com o restante do ambiente bancário.


🏦 24. A ponte com o banco

João paga sua fatura.

Esse pagamento pode entrar através de diferentes canais e sistemas.

BANKING CHANNEL
      │
      ▼
PAYMENT PROCESSING
      │
      ▼
CARD ACCOUNT
      │
      ├── REDUCE BALANCE
      └── RESTORE / ADJUST AVAILABLE CREDIT

Perceba como a arquitetura cresceu.

Começamos com:

POS → AUTORIZADOR

Agora temos:

CUSTOMER
CARD
ACCOUNT
PRODUCT
LIMIT
AUTHORIZATION
CLEARING
BILLING
PAYMENT
BANKING
ACCOUNTING

O sistema de cartões é uma ponte entre o mundo do pagamento e o mundo bancário.


💸 25. Cobrança

E se João não pagar?

Outra porta se abre.

BILL
  │
  ▼
DUE DATE
  │
  ├── PAID
  │
  └── UNPAID
         │
         ▼
     DELINQUENCY
         │
         ▼
     COLLECTION

Agora entram regras de atraso, cobrança, encargos, negociação e tratamento do relacionamento conforme produto, contrato e regulamentação.

A compra de R$100 feita em segundos pode permanecer meses dentro dos sistemas.


📚 26. Contabilidade — toda história precisa fechar

Em algum momento, os eventos financeiros relevantes precisam produzir os registros contábeis apropriados.

Conceitualmente:

CARD EVENT
    │
    ▼
BUSINESS EVENT
    │
    ▼
ACCOUNTING INTERFACE
    │
    ▼
ACCOUNTING ENTRIES
    │
    ▼
GENERAL LEDGER

Aqui existe uma fronteira extremamente importante.

O sistema operacional de cartões sabe:

“O que aconteceu com a transação.”

A contabilidade precisa representar:

“Qual é o efeito econômico desse acontecimento.”

É outra visão da mesma realidade.


⚖️ 27. Chargeback — o morto voltou

Semanas depois João olha a fatura.

Encontra:

CAFÉ BELLACOSA    R$100

E diz:

— Não reconheço.

A transação que parecia encerrada retorna.

TRANSACTION
    │
    ▼
DISPUTE
    │
    ▼
INVESTIGATION
    │
    ▼
POSSIBLE CHARGEBACK

Dependendo do caso e das regras aplicáveis, existem processos adicionais de contestação, evidências, representação e resolução.

Isso demonstra uma propriedade importantíssima:

O ciclo de vida da transação pode durar muito mais que os segundos da autorização.


🧮 28. Reconciliação — finalmente encontramos Patrick Jane

Agora chegamos ao sistema que mais se parece com nosso detetive.

A reconciliação pergunta:

“Todos estão contando a mesma história?”

Imagine:

AUTHORIZATION     1.000
CLEARING            998
SETTLEMENT          998
ACCOUNTING          998

Jane imediatamente pergunta:

— Onde estão as duas?

Ou:

CARD SYSTEM       R$10.000.000
ACCOUNTING        R$ 9.999.900

Diferença:

R$100.

Nosso velho amigo voltou.


🕵️ 29. Reconciliação é forense financeira

Ela procura situações como:

AUTH SEM CLEARING
CLEARING SEM AUTH
DUPLICATE CLEARING
VALUE MISMATCH
CURRENCY MISMATCH
SETTLEMENT DIFFERENCE
REVERSAL PENDING
ACCOUNTING MISSING

Por isso gosto de pensar nela como:

forense financeira automatizada.

Não basta saber que existem registros.

Precisamos provar que universos independentes estão coerentes entre si.


⏳ 30. A quarta dimensão: tempo

Patrick Jane encontra uma tarifa:

GOLD ANNUAL FEE = R$300

Cliente reclama:

— Meu contrato dizia R$240.

O analista olha a tabela.

R$300.

Caso encerrado?

Jane pergunta:

— Quanto era a tarifa quando o evento aconteceu?

Silêncio.

Consultamos o histórico:

01/01/2024 – 31/12/2025    R$240

01/01/2026 – ...           R$300

A investigação muda completamente.

Em sistemas financeiros não basta perguntar:

Qual é a regra?

Muitas vezes precisamos perguntar:

Qual era a regra naquele instante?

Isso introduz:

VALID-FROM
VALID-TO
VERSION
STATUS
CREATED-AT
CHANGED-AT
APPROVED-BY

📡 31. O mesmo vale para a maquininha

Hoje:

POS VERSION = 120

Mas a transação problemática aconteceu ontem.

Ontem:

POS VERSION = 118

Portanto a pergunta:

“Qual é a versão atual?”

pode ser inútil.

Jane pergunta:

“Qual versão estava efetivamente ativa quando ocorreu o problema?”

Isso é troubleshooting de verdade.


📜 32. Logs são testemunhas

No mainframe podemos encontrar evidências espalhadas por diferentes tecnologias e componentes:

APPLICATION LOGS
CICS
MQ
Db2
VSAM
SMF
JES/SDSF
NETWORK RECORDS
BATCH REPORTS
AUDIT RECORDS
RECONCILIATION FILES

Um bom sistema deve permitir reconstruir uma narrativa.

Algo como:

10:32:01.003 RECEIVED
10:32:01.017 CARD VALID
10:32:01.025 LIMIT CHECK
10:32:01.041 RISK CHECK
10:32:01.055 APPROVED
10:32:01.061 AUTH CODE GENERATED
10:32:01.074 RESPONSE SENT

Depois:

02:17:43 CLEARING RECEIVED
02:17:44 AUTH MATCHED
02:17:44 ACCOUNT POSTED
02:17:45 ACCOUNTING GENERATED

Não são apenas linhas.

São depoimentos.


🧾 33. Auditoria pergunta quem mexeu na cena do crime

Imagine que alguém alterou uma tarifa.

Precisamos saber:

WHO?
WHEN?
OLD VALUE?
NEW VALUE?
WHO APPROVED?
WHEN EFFECTIVE?

Então podemos encontrar estruturas conceituais como:

FEE_CHANGE_AUDIT
────────────────────────
PRODUCT
FEE
OLD_VALUE
NEW_VALUE
REQUESTED_BY
APPROVED_BY
CHANGE_TIMESTAMP
EFFECTIVE_DATE
REFERENCE

A mesma filosofia pode ser aplicada a mudanças críticas em:

PRODUCT
LIMIT RULE
MERCHANT CONTRACT
TERMINAL PROFILE
SETTLEMENT RULE

Sistema financeiro precisa possuir memória.


🖥️ 34. E onde entra o mainframe?

Agora finalmente podemos olhar para tecnologias.

Uma arquitetura híbrida conceitual poderia ser:

POS
 │
 ▼
ACQUIRER EDGE
 │
 ▼
NETWORK
 │
══════════════════════════════════
           IBM Z / z/OS
══════════════════════════════════
 │
 ▼
CICS
 │
 ├── AUTHORIZATION
 ├── CARD ACCOUNT
 ├── PRODUCT
 ├── LIMIT
 └── BUSINESS RULES
 │
 ├── Db2
 ├── VSAM
 └── MQ
 │
 ▼
BATCH
 │
 ├── CLEARING
 ├── BILLING
 ├── SETTLEMENT
 ├── ACCOUNTING
 └── RECONCILIATION

Em ambientes reais essas funções podem estar distribuídas entre mainframe, sistemas distribuídos, cloud, gateways, appliances especializados e fornecedores.

A pergunta arquitetural fundamental não é:

“Está tudo no mainframe?”

A pergunta é:

“Quem é o System of Record de cada verdade?”


🧠 35. COBOL não é a primeira coisa que eu ensinaria

Se eu tivesse diante de mim vinte programadores COBOL iniciantes destinados a trabalhar em Cards & Payments, eu não começaria ensinando:

IDENTIFICATION DIVISION.

Começaria colocando R$100 sobre a mesa.

E perguntaria:

“O que acontece com este dinheiro quando alguém encosta um cartão numa maquininha?”

Primeiro ensinaríamos o negócio.

Depois:

CUSTOMER
 ↓
CARD
 ↓
PRODUCT
 ↓
PLAFOND
 ↓
MERCHANT
 ↓
POS
 ↓
ACQUIRER
 ↓
NETWORK
 ↓
ISSUER
 ↓
AUTHORIZATION
 ↓
CLEARING
 ↓
SETTLEMENT
 ↓
BILLING
 ↓
ACCOUNTING
 ↓
RECONCILIATION

Só então COBOL começa a fazer sentido.


🧰 36. Cada tecnologia finalmente ganha um motivo para existir

O aluno começa a perceber por que encontrará CICS em processamento transacional online.

Entende por que existem milhões de linhas de COBOL implementando regras de negócio.

Percebe o papel de Db2 e VSAM na persistência de diferentes tipos de informação conforme a arquitetura.

Entende como MQ pode participar da integração entre domínios.

Descobre por que JCL e processamento batch continuam extremamente importantes para volumes massivos, interfaces, fechamentos, billing, clearing, settlement, contabilização e reconciliação em determinadas implementações.

E entende finalmente por que logs, traces, auditoria e monitoramento não são burocracia.

São evidências.


🚨 37. WAR ROOM — 03:17

E aqui está nosso pequeno easter egg.

Telefone toca.

03:17.

Produção:

— Temos uma divergência de R$100.

O iniciante entra no SDSF.

Procura:

100.00

Encontra 8.743 ocorrências.

Excelente.

Agora temos 8.743 suspeitos.

😂

Patrick Jane toma café.

Pergunta:

— Qual é a identidade da transação?

Encontramos a primeira referência.

Então construímos:

03:16:57 AUTH REQUEST
03:16:58 APPROVED
03:17:01 TIMEOUT
03:17:04 RETRY
03:17:05 SECOND MESSAGE
03:17:07 REVERSAL

Horas depois:

CLEARING      1
SETTLEMENT    1
ACCOUNTING    0

Aha!

O problema nunca foi:

“sumiram R$100.”

O problema era:

o ciclo de vida da transação foi interrompido entre dois domínios que deveriam concordar.

Agora temos uma investigação.


🕵️ 38. Outro incidente: 50 mil maquininhas enlouqueceram

Alguns meses depois:

— Determinadas maquininhas deixaram de aceitar um tipo de operação.

War Room.

CICS:

GREEN.

Db2:

GREEN.

CPU:

GREEN.

MQ:

GREEN.

Network:

GREEN.

Issuer:

GREEN.

Todo mundo declara inocência.

Jane pergunta:

— Quando começou?

— Meia-noite.

— O que mudou à meia-noite?

Silêncio.

Descobrimos:

TERMINAL PROFILE
VERSION 118
VALID UNTIL 23:59:59

Uma parte da frota não recebeu ou não ativou adequadamente determinado perfil/configuração.

Resultado:

1.950.000 POS → OK
   50.000 POS → OLD PROFILE

Nenhum COBOL estava errado.

Nenhum CICS estava quebrado.

A máquina estava simplesmente executando a configuração que possuía.

Essa é uma lição magnífica:

Nem todo incidente de negócio é defeito de código.


🧩 39. O grande mapa do BELLACARD

Depois de toda nossa investigação, podemos finalmente desenhar o sistema:

                        CUSTOMER
                           │
                       CADASTRO
                           │
                     CARD ACCOUNT
                           │
             ┌─────────────┼──────────────┐
             │             │              │
          PRODUCT       PLAFOND        FEE PLAN
             │             │              │
             └─────────────┼──────────────┘
                           │
                          CARD
                           │
                           ▼
══════════════════════════════════════════════════
                        MERCHANT
                           │
                        CONTRACT
                           │
                      PRICING PLAN
                           │
                          MCC
                           │
                         STORE
                           │
                          POS
                           │
                    TERMINAL PROFILE
                           │
                          TMS
══════════════════════════════════════════════════
                           │
                        PURCHASE
                           │
                           ▼
                       ACQUIRER
                           │
                        NETWORK
                           │
                         ISSUER
                           │
                    AUTHORIZATION
                           │
                  ┌────────┴────────┐
                  │                 │
               DECLINE          APPROVED
                                    │
                               AUTH CODE
                                    │
                               REVERSAL?
                                    │
                                CLEARING
                                    │
                               SETTLEMENT
                                    │
              ┌─────────────────────┼──────────────────┐
              │                     │                  │
           BILLING              ACCOUNTING       RECONCILIATION
              │                     │
           PAYMENT              GENERAL LEDGER
              │
           BANKING
              │
          COLLECTION

             TRANSACTION
                  │
               DISPUTE
                  │
              CHARGEBACK

Agora podemos finalmente dizer:

isso é um ecossistema de cartões.


☕ 40. A verdadeira lição de The Mentalist

Patrick Jane não seria um excelente analista de produção porque sabe COBOL.

Provavelmente nem saberia escrever:

PERFORM UNTIL

Ele seria excelente porque sabe formular perguntas.

Quando aparece uma transação problemática, o iniciante pergunta:

“O programa deu erro?”

Jane perguntaria:

“Qual foi a última evidência confiável?”

O iniciante pergunta:

“A compra foi aprovada?”

Jane:

“Foi posteriormente revertida?”

O iniciante:

“Está no clearing?”

Jane:

“Com qual identidade?”

O iniciante:

“A tarifa é R$300.”

Jane:

“Era R$300 na data do evento?”

O iniciante:

“A POS está na versão 120.”

Jane:

“Estava na versão 120 quando aconteceu?”

O iniciante:

“O mainframe está verde.”

Jane:

“E quem disse que o problema está no mainframe?”

Essa mudança de mentalidade é talvez mais importante que decorar qualquer comando.


🔎 41. A regra Bellacosa para investigar cartões

Quando receber um incidente, não procure primeiro pelo erro.

Reconstrua a história.

Comece identificando:

WHO
 │
WHAT
 │
WHEN
 │
WHERE
 │
WHICH PRODUCT
 │
WHICH MERCHANT
 │
WHICH TERMINAL
 │
WHICH TRANSACTION
 │
WHICH AUTHORIZATION
 │
WHICH CLEARING RECORD
 │
WHICH SETTLEMENT
 │
WHICH ACCOUNTING EVENT
 │
WHICH VERSION
 │
WHICH RULE

Depois monte a timeline.

Só então mergulhe no código.

Isso evita horas investigando o componente errado.


🧠 42. Curiosidade — a mesma compra possui várias identidades

Esse talvez seja um dos conceitos mais importantes para um futuro especialista.

A compra que João conhece como:

“R$100 no Café Bellacosa”

pode aparecer tecnicamente de maneiras diferentes em:

POS
ACQUIRER
NETWORK
ISSUER
AUTHORIZATION
CLEARING
CARD ACCOUNT
SETTLEMENT
ACCOUNTING
RECONCILIATION

O grande trabalho investigativo é construir uma linha ligando essas representações.

Imagine o mural de The Mentalist:

POS REF
   │
   ▼
ACQUIRER REF
   │
   ▼
NETWORK REF
   │
   ▼
AUTHORIZATION
   │
   ▼
CLEARING REF
   │
   ▼
SETTLEMENT
   │
   ▼
ACCOUNTING REF

A linha vermelha entre elas é aquilo que chamamos de correlação.

Sem ela temos logs.

Com ela temos uma história.


🏛️ 43. E essa é a beleza escondida do mainframe

Quando alguém diz:

“COBOL é uma tecnologia velha.”

Talvez esteja olhando para o tijolo e ignorando a catedral.

O programa COBOL que verifica um status pode fazer parte de uma cadeia que permite que alguém compre um café às 10h32 numa cidade qualquer.

O CICS que executa uma transação pode estar no caminho entre uma maquininha e uma decisão financeira que precisa acontecer em segundos.

Um batch executado durante a madrugada pode estar processando milhões de registros de clearing.

Um job pode gerar contabilizações.

Outro pode reconciliar universos inteiros.

Uma fila MQ aparentemente insignificante pode representar a ponte entre duas partes críticas dessa história.

Uma tabela Db2 com uma data de vigência errada pode afetar milhares de clientes.

Um profile incorreto pode transformar milhares de maquininhas perfeitamente saudáveis em protagonistas de uma War Room.

E uma única transação de R$100 pode atravessar tudo isso.


☕ Epílogo — A última xícara de café

São 05:42.

A War Room finalmente está silenciosa.

O problema das 03:17 foi identificado.

A transação foi reconstruída.

Encontramos autorização.

Encontramos timeout.

Encontramos retry.

Encontramos reversal.

Encontramos clearing.

Encontramos settlement.

Encontramos a ausência da contabilização esperada.

A reconciliação fez exatamente aquilo para que foi criada:

percebeu que duas histórias não terminavam da mesma maneira.

Alguém pergunta a Patrick Jane:

— Como você descobriu?

Ele olha para os enormes monitores.

Depois para as milhares de linhas do log.

E responde:

“Vocês estavam procurando onde o sistema errou. Eu procurei onde os sistemas deixaram de concordar.”

Talvez essa seja uma das melhores definições para troubleshooting em sistemas de cartões.

Não somos apenas programadores COBOL.

Não somos operadores de CICS.

Não somos leitores de dumps.

Somos investigadores de sistemas.

Cada mensagem é uma pista.

Cada timestamp é uma testemunha.

Cada authorization code é uma evidência.

Cada reversal muda a história.

Cada versão possui seu momento.

Cada parâmetro possui sua vigência.

Cada clearing precisa encontrar sua origem.

Cada lançamento contábil precisa possuir uma explicação.

E toda reconciliação possui uma pergunta extremamente simples:

“As histórias fecham?”

Porque em um sistema financeiro podemos até aceitar que uma mensagem demore alguns milissegundos.

Podemos aceitar que um processo atravesse dezenas de sistemas.

Podemos conviver com COBOL escrito antes de alguns de seus atuais mantenedores nascerem.

O que não podemos aceitar é que R$100 desapareçam sem deixar uma história explicável.

E se um dia, às 03:17, alguém telefonar dizendo:

— Bellacosa, sumiram R$100.

Não procure 100.00 no log.

Pegue um café.

Abra o mural.

Descubra quem era o cliente, qual era o cartão, produto, plafond, merchant, loja e terminal.

Descubra a configuração vigente.

Encontre a autorização.

Procure o reversal.

Siga até o clearing.

Atravesse o settlement.

Cheque billing e cobrança quando aplicáveis.

Chegue à contabilidade.

E finalmente pergunte à reconciliação:

“Onde exatamente nossas histórias deixaram de ser iguais?”

Nesse momento você deixou de ser apenas um programador COBOL iniciante.

Você começou a pensar como um verdadeiro analista de sistemas de missão crítica.

Ou, como Patrick Jane provavelmente diria diante do nosso velho IBM Z:

o mainframe quase sempre deixa pistas. O segredo é saber quais perguntas fazer.

☕🕵️‍♂️💳

Bellacosa Mainframe
Onde até uma compra de R$100 pode virar uma investigação de madrugada.



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