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



segunda-feira, 24 de junho de 2024

🚨 Os 12 Macacos, COBOL e o Tribunal da Timeline ARCO I — CAPÍTULO VI

 

Bellacosa Mainframe e os 12 macacos

☕ Um Café no Bellacosa Mainframe

🚨 Os 12 Macacos, COBOL e o Tribunal da Timeline

ARCO I — CAPÍTULO VI

Quando a denúncia viralizou antes de os fatos terminarem de carregar

Na Internet, às vezes o VERDICT termina de executar enquanto o READ EVIDENCE ainda está esperando I/O.



🕰️ 05:01 — THE DIGITAL TRIBUNAL IS NOW IN SESSION

No capítulo anterior, nosso COBOLzeiro descobriu uma verdade desagradável.

Não existe filtro perfeito.

Não existe IA perfeita.

Não existe moderador perfeito.

E, principalmente:

PERFECT HUMAN........ DEFINITELY NOT FOUND

Palavras viraram códigos.

Códigos viraram emojis.

Emojis viraram memes.

Memes viraram referências internas.

A plataforma aprendeu.

A comunidade adaptou.

O algoritmo observou os usuários.

Os usuários aprenderam a observar o algoritmo.

Tudo perfeitamente caótico.

Nosso herói já estava começando a aceitar que talvez o universo digital fosse simplesmente um gigantesco programa COBOL escrito por alguém que abusou de GO TO.

Até que apareceu:

TRENDING NOW

Milhares de mensagens começaram a subir.

Facebook.

Instagram.

WhatsApp.

Discord.

Reddit.

X.

Twitch.

Telegram.

Vídeos.

Screenshots.

Influenciadores.

Jornalistas.

Comentaristas.

Especialistas.

Supostos especialistas.

Pessoas que descobriram o caso sete minutos atrás.

E pessoas que, aparentemente, já sabiam exatamente quem era culpado.

O terminal perguntou:

LOAD DIGITAL TRIBUNAL? Y/N

Nosso COBOLzeiro cometeu o erro.

Y

ENTER.

A tela ficou preta.

Então surgiu:

WARNING:

EVERYONE HAS A VERDICT.

WE ARE STILL LOOKING
FOR THE EVIDENCE.

Bruce Willis colocou outra garrafa de café sobre a mesa.

— Vamos precisar.



⚡ 1. A Internet possui uma característica que o Direito não consegue acompanhar facilmente

Velocidade.

Uma denúncia pode nascer às 08:00.

Às 08:03 alguém captura um screenshot.

08:07:

POST

08:11:

REPOST

08:16:

THREAD

08:24:

HASHTAG

08:41:

INFLUENCER REACTION

09:05:

TRENDING

10:30:

NEWS PORTAL

12:00:

TELEVISION

14:00:

"ENTENDA O CASO"

Nosso programador interrompe.

— Espere.

— O quê?

— Quando aconteceu a investigação?

Bruce Willis aponta para a tela.

INVESTIGATION STATUS:
UNKNOWN

— E as provas?

PARTIAL

— Então como existe "entenda o caso"?

Bruce toma café.

— Bem-vindo à timeline.



🧠 2. O cérebro humano odeia STATUS = UNKNOWN

Existe uma coisa que seres humanos parecem detestar:

UNKNOWN

Queremos histórias.

Causa.

Culpado.

Motivo.

Começo.

Meio.

Fim.

Uma investigação real frequentemente começa assim:

WHAT HAPPENED?........ UNKNOWN
WHO DID IT?........... UNKNOWN
WHY?.................. UNKNOWN
HOW MANY PEOPLE?...... UNKNOWN
WHEN?................. PARTIAL
EVIDENCE?............. COLLECTING

Terrível para televisão.

Péssimo para uma thumbnail.

Horrível para engajamento.

Então surge uma tentação:

preencher os espaços vazios.


🧩 3. E quando faltam fatos, entram inferências

Imagine:

FACT A
FACT B
??????
FACT D

A Internet não gosta do ??????.

Então alguém publica:

"OBVIAMENTE C."

Outro responde:

"Faz sentido."

Outro:

"Eu já desconfiava."

Outro:

"Todo mundo sabe."

Pouco depois:

C = FACT

Mas C nunca foi fato.

Era hipótese.

Acabamos de testemunhar um dos processos mais perigosos da informação viral:

a solidificação da inferência.


🗃️ 4. O boato ganha tipo de dado errado

Nosso COBOLzeiro reconhece imediatamente.

Imagine:

01 INFORMATION.
   05 FACT       PIC X.
   05 RUMOR      PIC X.
   05 HYPOTHESIS PIC X.

Perfeito.

Só que a Internet faz:

MOVE HYPOTHESIS TO FACT.

Sem validação.

Sem IF.

Sem 88-LEVEL.

Sem vergonha.

Depois grava:

WRITE PUBLIC-OPINION.

Agora temos problema.


📸 5. O screenshot chega à War Room

Alguém publica uma captura de tela.

Nosso programador pergunta:

— Autêntica?

UNKNOWN

— Completa?

UNKNOWN

— Qual data?

PARTIAL

— O que veio antes?

NOT AVAILABLE

— O que veio depois?

NOT AVAILABLE

— Quem capturou?

UNKNOWN

— Então o que sabemos?

SCREENSHOT EXISTS.

Isso pode ser importante.

Mas é muito diferente de:

SCREENSHOT PROVES EVERYTHING.

🖼️ 6. A imagem tem uma autoridade psicológica impressionante

Texto:

"Fulano disse X."

Nosso cérebro talvez responda:

Será?

Agora aparece um screenshot aparentemente mostrando:

Fulano: X.

A sensação muda.

Aha!

Vimos!

Só existe um problema.

Em 2026, produzir uma imagem convincente de uma interface digital não exige acesso ao mainframe da NSA.

Editar imagens nunca foi novidade.

Mas IA generativa tornou produção e alteração de artefatos sintéticos ainda mais acessível.

Então o velho princípio fica mais importante:

SEEING
!=
VERIFYING

🤖 7. Agora existe evidência sintética

O Bellacosa Mainframe recebe:

IMAGE
AUDIO
VIDEO
SCREENSHOT
TEXT LOG

Nosso programador pergunta:

— Qual é verdadeiro?

O sistema responde:

ANALYSIS REQUIRED.

Áudio pode ser manipulado.

Imagem pode ser fabricada.

Vídeo pode ser editado.

Texto pode ser reconstruído.

Até algo verdadeiro pode ser apresentado fora de contexto.

Isso significa que precisamos pensar em:

proveniência.

De onde veio?

Quando?

Quem produziu?

Foi alterado?

Existe original?

Existem registros independentes?

A evidência digital agora precisa carregar passaporte.


📰 8. E então o jornalista recebe o material

Aqui voltamos ao paradoxo da revista do Capítulo II.

Um jornalista recebe uma denúncia.

Talvez seja gravíssima.

Ele possui duas responsabilidades que podem entrar em tensão:

PUBLIC INTEREST

e:

VERIFICATION

Publicar rápido pode alertar pessoas.

Publicar cedo demais pode espalhar informação incorreta.

Esperar pode permitir continuidade de um risco.

Não verificar pode destruir inocentes.

Não existe:

PERFORM JOURNALISM
UNTIL TRUTH

Jornalismo trabalha com tempo, fontes, evidências e incerteza.

E agora compete com milhões de pessoas que não precisam esperar editor algum.


📱 9. O cidadão com smartphone virou emissora

Em outra época, atingir milhões de pessoas exigia infraestrutura.

Gráfica.

Rádio.

Televisão.

Distribuição.

Hoje:

USER
  +
PHONE
  +
NETWORK
  =
POTENTIAL BROADCASTER

Isso democratizou comunicação de maneira extraordinária.

Denúncias que poderiam ser enterradas ganharam voz.

Abusos puderam ser documentados.

Testemunhas puderam publicar.

Mas a mesma infraestrutura permite:

  • boatos;

  • montagens;

  • acusações falsas;

  • recortes;

  • manipulações;

  • perseguições.

A ferramenta amplifica o humano.

Infelizmente ela não verifica caráter antes de instalar.


🚨 10. Denúncia pública pode ser necessária

É importante não cair no extremo oposto.

Existem situações em que denúncias públicas tiveram enorme importância social.

Jornalismo investigativo.

Movimentos de vítimas.

Whistleblowers.

Testemunhas.

Documentação de abusos.

A possibilidade de falar publicamente é parte fundamental de uma sociedade democrática.

O problema não é:

DENUNCIATION = BAD

O problema é confundir:

ALLEGATION

com:

PROVEN FACT

São registros diferentes.

Preserve o RECORD TYPE.


⚖️ 11. Presunção de inocência entra no CPD

No Brasil, a Constituição estabelece uma garantia fundamental relacionada à presunção de inocência.

Isso pertence ao sistema jurídico.

Mas existe um problema interessante:

a timeline não possui Constituição própria.

Ela possui:

LIKE
SHARE
REPOST
COMMENT
TRENDING

Não existe botão:

WAIT FOR DUE PROCESS

Nosso programador procura.

Nada.

— Está escondido nas configurações?

Bruce Willis responde:

— Não.

— Feature request?

— Talvez para a humanidade.


🔨 12. O martelo do juiz e o botão de repost não são equivalentes

Uma decisão judicial emerge de um processo institucional.

Uma conclusão viral emerge de outra arquitetura.

Compare:

EVIDENCE
   |
INVESTIGATION
   |
PROCEDURE
   |
ARGUMENT
   |
DECISION

com:

SCREENSHOT
   |
OUTRAGE
   |
REPOST
   |
TRENDING
   |
"EVERYONE KNOWS"

Ambos podem produzir crenças.

Mas apenas um deles foi construído institucionalmente para decidir responsabilidades jurídicas.

Isso não torna tribunais infalíveis.

Torna evidente que timeline não é tribunal.


🏛️ 13. O devido processo é lento por design

Nosso COBOLzeiro reclama:

— Mas isso demora.

Sim.

Investigar demora.

Verificar demora.

Ouvir partes demora.

Analisar provas demora.

Recursos demoram.

É frustrante.

Mas existe uma razão para não termos:

IF ACCUSATION > 10000 LIKES
   MOVE GUILTY TO VERDICT
END-IF

Popularidade não é padrão probatório.

Viralidade não é cadeia de custódia.

Hashtag não é sentença.


🧒 14. Então aparecem crianças e adolescentes

O terminal muda novamente:

MINORS INVOLVED: POSSIBLE

Silêncio.

Aqui o cuidado precisa aumentar.

Quando existem menores, a exposição pública pode produzir danos adicionais.

Identificação.

Constrangimento.

Revitimização.

Assédio.

Perseguição.

Curiosidade pública.

Reprodução irresponsável de material.

No Brasil, o ECA estabelece proteção especial a crianças e adolescentes.

Então "estou denunciando" não é licença para transformar vítima em conteúdo.


🛡️ 15. Proteger a vítima não exige publicar tudo

Esse conceito é fundamental.

Imagine que determinada denúncia envolva material sensível.

Uma pessoa decide:

"Vou mostrar para provar."

Pare.

Existe diferença entre:

REPORT EXISTENCE OF EVIDENCE

e:

REPUBLISH HARMFUL MATERIAL

Denunciar não exige necessariamente reproduzir.

Jornalismo responsável conhece esse princípio há décadas.

Em ambientes digitais, porém, a tentação de mostrar "a prova" pode gerar uma segunda circulação do próprio dano.

O vírus informacional sorri novamente.


🦠 16. A denúncia pode carregar o objeto denunciado

Este é um dos paradoxos mais perturbadores de toda a série.

Alguém encontra conteúdo problemático.

Fica indignado.

Captura.

Publica:

"OLHEM O ABSURDO!"

Agora o conteúdo possui uma nova cópia.

Outra pessoa reposta denunciando.

Outra salva como evidência informal.

Outra compartilha num grupo:

"Vocês viram isso?"

Temos:

ORIGINAL
   |
   v
DENUNCIATION COPY
   |
   +--> REPOST
   +--> SCREENSHOT
   +--> VIDEO REACTION
   +--> NEWS COVERAGE

Todos talvez condenando.

Mas tecnicamente:

a circulação aumentou.


📢 17. Condenação e amplificação podem coexistir

Essa frase precisa ficar gravada no terminal:

CONDEMNATION
CAN PRODUCE
AMPLIFICATION.

Isso não significa que devemos ficar em silêncio diante de problemas.

Significa que precisamos pensar como comunicar.

Podemos alertar sem transformar alerta em catálogo.

Podemos denunciar sem fornecer caminhos desnecessários.

Podemos explicar sem reproduzir material prejudicial.

Podemos informar sem transformar curiosidade em tutorial.

O Capítulo II acaba de voltar pela porta dos fundos.


💥 18. Efeito Streisand entra na sala

Existe ainda o famoso efeito Streisand.

Tentativas de esconder, remover ou suprimir determinada informação podem, em algumas circunstâncias, aumentar enormemente a atenção sobre ela.

Antes:

PEOPLE WHO KNOW = 500

Depois da tentativa pública de remoção:

"WHAT ARE THEY TRYING TO HIDE?"

Agora:

PEOPLE SEARCHING = 500000

Não é uma lei física.

Nem toda remoção gera Streisand.

Mas é um risco comunicacional real.

Principalmente quando a própria tentativa de supressão vira notícia.


🔍 19. A curiosidade é o motor de busca mais antigo

Antes do Google havia curiosidade.

Antes da Internet havia curiosidade.

Antes da escrita provavelmente alguém dizia:

"Não entre naquela caverna."

E outro humano imediatamente perguntava:

"Por quê?"

O aviso:

DO NOT SEARCH X

contém:

SEARCH TERM = X

Nosso COBOLzeiro olha para Bruce Willis.

— Isso é um bug humano?

— Feature.

— Podemos corrigir?

— Tentamos há alguns milhares de anos.


📰 20. "Não procure isso" pode ser uma query pronta

A imprensa diz:

"Autoridades alertam para o perigoso fenômeno chamado XYZ."

Milhões de pessoas:

SEARCH "XYZ"

Algumas querem entender.

Algumas são jornalistas.

Algumas são pesquisadores.

Algumas são pais.

Algumas são simplesmente curiosas.

E algumas podem estar procurando exatamente o fenômeno denunciado.

O comunicador não controla a intenção de quem recebe a informação.

Essa é uma das razões pelas quais granularidade importa tanto.


📺 21. O telejornal abre a porta da curiosidade

Imagine uma reportagem:

"Existe uma comunidade secreta chamada..."

Pausa.

Nosso COBOLzeiro levanta da cadeira.

— NÃO DIGA!

O apresentador diz.

O nome aparece em letras gigantes.

A reportagem mostra a interface.

Mostra termos.

Mostra símbolos.

Mostra onde usuários se reúnem.

Talvez tudo isso seja jornalisticamente justificável em determinado contexto.

Mas existe um efeito colateral:

DISCOVERABILITY++

A denúncia também funcionou como indexador.


🔎 22. SEO não possui consciência moral

Mecanismos de busca não perguntam necessariamente:

"Por que essa pessoa quer saber?"

Uma notícia gera buscas.

Buscas geram conteúdo.

Conteúdo gera páginas.

Páginas geram links.

Links geram indexação.

NEWS
  |
SEARCH
  |
CONTENT
  |
LINKS
  |
INDEX
  |
MORE SEARCH

A denúncia pode acabar construindo a infraestrutura semântica pela qual futuras pessoas encontrarão o assunto.

Nosso programador olha horrorizado.

— Então o índice também participa da epidemia?

Bruce responde:

— Agora você está entendendo.


🤖 23. E os recomendadores chegam

Pior.

O usuário procura uma coisa.

A plataforma aprende:

USER INTEREST = X

Então recomenda:

RELATED X1
RELATED X2
RELATED X3

O usuário não precisava saber que X2 existia.

Agora sabe.

Aqui surge uma distinção fundamental:

SEARCH

é alguém procurando algo.

RECOMMENDATION

é o sistema trazendo algo até alguém.

Essa diferença é gigantesca.


🎯 24. Da busca para a descoberta algorítmica

Na velha Internet:

I WANT X
   |
   v
I SEARCH X

Na Internet algorítmica:

I WATCH A
   |
   v
SYSTEM INFERS B
   |
   v
SYSTEM SHOWS C
   |
   v
I DISCOVER X

Você não procurou X.

X encontrou você.

Nosso COBOLzeiro olha para Bruce Willis.

— Quem autorizou isso?

— Você aceitou os termos.

— Aqueles que ninguém lê?

— Aqueles mesmos.


📈 25. O algoritmo não precisa concordar para amplificar

Este ponto é importante.

Um sistema de recomendação não precisa possuir ideologia, intenção ou opinião humana para ampliar determinado conteúdo.

Pode simplesmente otimizar alguma métrica:

  • retenção;

  • cliques;

  • visualização;

  • interação;

  • relevância prevista.

Conteúdo indignante pode gerar interação.

Conteúdo controverso pode gerar comentários.

Conteúdo chocante pode prender atenção.

Então:

OUTRAGE
   |
   v
ENGAGEMENT
   |
   v
VISIBILITY

pode surgir como efeito sistêmico.

Não porque alguém apertou:

PROMOTE EVIL

Mas porque métricas possuem consequências.


🧠 26. O algoritmo aprende que estamos indignados — e conclui que gostamos

Imagine que você odeie determinado assunto.

Toda vez que aparece:

  • abre;

  • lê;

  • comenta;

  • responde;

  • compartilha criticando.

Para o sistema:

USER INTERACTED = TRUE

A máquina pode não compreender sua indignação da mesma forma que outro humano compreenderia.

Então mostra mais.

Você fica mais indignado.

Interage mais.

OUTRAGE
   |
ENGAGEMENT
   |
RECOMMENDATION
   |
MORE OUTRAGE
   |
MORE ENGAGEMENT

Encontramos outro loop.

Os 12 Macacos abriram champanhe.


🔥 27. DO NOT FEED THE ALGORITHM

Talvez uma das frases mais úteis da Internet moderna seja:

DO NOT FEED
WHAT YOU DON'T WANT
TO AMPLIFY.

Mas isso não significa ignorar crimes, abusos ou riscos.

Significa distinguir entre:

REPORT

e:

AMPLIFY

Denunciar à plataforma ou às autoridades apropriadas pode ser necessário.

Transformar tudo em espetáculo público pode produzir consequências completamente diferentes.


🎭 28. O influenciador entra no incidente

Agora surge alguém com dois milhões de seguidores.

Ele recebe um screenshot.

Publica:

"ISSO É ABSURDO!"

Dois milhões de pessoas recebem.

Algumas denunciam.

Algumas atacam.

Algumas procuram o acusado.

Algumas procuram a comunidade.

Algumas tentam encontrar o conteúdo original.

A intenção do influenciador pode ter sido:

CONDEMN

O efeito inclui:

AMPLIFY

Intenção e efeito não são campos idênticos.

Essa é uma lição brutal.


⚠️ 29. A multidão encontra o suspeito

Alguém publica nome.

Outro encontra perfil.

Outro acha endereço antigo.

Outro encontra familiares.

Outro encontra empregador.

Outro encontra telefone.

Agora saímos de:

DISCUSSION

e entramos em território muito mais perigoso.

Assédio.

Ameaças.

Exposição indevida de dados.

Possíveis erros de identidade.

Linchamento digital.

Nosso COBOLzeiro grita:

— Parem!

Ninguém ouve.

A timeline não possui PAUSE.


👤 30. O problema do homônimo

Imagine:

SUSPECT NAME = JOÃO SILVA

Boa sorte.

Alguém encontra um João Silva.

Foto parece vagamente compatível.

Publica:

"É ESTE."

Milhares compartilham.

Só existe um pequeno detalhe.

Não é.

Agora temos uma vítima nova.

Criada pela investigação coletiva.

O sistema começou com uma denúncia sobre possível dano.

E produziu outro dano.


🧯 31. Incident Response sem Change Control

Nosso COBOLzeiro finalmente entende o que o incomoda.

A timeline é uma War Room onde:

  • todo mundo possui teclado;

  • ninguém possui coordenador;

  • hipóteses são públicas;

  • evidências são copiadas;

  • alterações são irreversíveis;

  • logs são incompletos;

  • milhões observam;

  • ninguém possui botão de rollback.

Ele escreve:

SOCIAL MEDIA INCIDENT RESPONSE

CHANGE CONTROL........ NONE
ROOT CAUSE............ UNKNOWN
COMMUNICATION......... CHAOTIC
AUDIENCE.............. MILLIONS
ROLLBACK.............. IMPOSSIBLE

Depois:

SEVERITY = OH-MY-GOD

🕵️ 32. Investigação coletiva pode ajudar — e também contaminar

Comunidades online já ajudaram a identificar lugares, objetos, datas e informações públicas.

Inteligência coletiva pode ser extraordinária.

Mas existe risco.

Pessoas podem:

  • interpretar errado;

  • pressionar testemunhas;

  • espalhar pistas falsas;

  • identificar inocentes;

  • contaminar narrativas;

  • destruir contexto.

Então:

CROWDSOURCING

não equivale automaticamente a:

INVESTIGATION

É ferramenta.

Não instituição.


🧾 33. Preservar é diferente de publicar

Uma pessoa encontra algo potencialmente relevante.

Existem dois verbos:

PRESERVE

e:

PUBLISH

Eles não são sinônimos.

Dependendo do caso, preservar informações e encaminhá-las pelos canais adequados pode ser muito mais responsável que publicar para milhares de pessoas.

Principalmente quando existem:

  • menores;

  • vítimas;

  • material sensível;

  • acusações graves;

  • investigações.

Nem toda evidência precisa virar conteúdo.


🧒 34. Quando há menores, SHARE pode ser exatamente o botão errado

Esse ponto merece letras gigantes.

PROTECT
!=
REPUBLISH

Se o objetivo é proteger criança ou adolescente, aumentar a circulação de material sensível pode contrariar o próprio objetivo.

O impulso:

"Vou compartilhar para denunciar"

precisa ser substituído por:

"Qual é a forma mais segura e eficaz de encaminhar isso sem ampliar o dano?"

Isso é maturidade digital.

E talvez seja uma das maiores diferenças entre denúncia responsável e espetáculo.


📡 35. Discord fecha o servidor

Agora imagine que a plataforma tome uma medida.

SERVER DISABLED

A timeline explode.

Grupo A:

"Prova de culpa!"

Grupo B:

"Censura!"

Grupo C:

"Tentativa de esconder!"

Nosso COBOLzeiro interrompe:

— Qual foi o motivo oficial?

Silêncio.

— A plataforma publicou?

Talvez não completamente.

Então temos novamente:

PLATFORM ACTION
!=
CRIMINAL CONVICTION

Um servidor pode ser removido por violação de políticas privadas.

Isso pode coincidir com conduta ilegal.

Ou não.

Precisamos conhecer os fatos.


🏃 36. E a comunidade migra

Lembra do Capítulo III?

Servidor fecha.

Usuários:

DISCORD
   X
   |
   +--> TELEGRAM
   |
   +--> WHATSAPP
   |
   +--> REDDIT
   |
   +--> NEW SERVER

A imprensa anuncia:

"Comunidade banida do Discord."

Milhares que nunca ouviram falar dela perguntam:

"Qual comunidade?"

Buscam.

Alguns encontram os novos endereços.

Novamente:

SUPPRESSION
+
PUBLICITY
=
POSSIBLE REDISCOVERY

Os 12 Macacos continuam migrando.


📰 37. A reportagem precisa decidir quanto mostrar

Chegamos ao dilema editorial.

Uma matéria pode dizer:

"Uma comunidade foi investigada por determinado comportamento."

Ou pode:

  • publicar nome;

  • mostrar logotipo;

  • exibir termos de busca;

  • mostrar interface;

  • reproduzir mensagens;

  • explicar códigos;

  • indicar plataformas;

  • mostrar convites.

Cada informação adicional pode possuir valor jornalístico.

Mas também pode aumentar:

DISCOVERABILITY

Não existe fórmula universal.

Existe responsabilidade editorial.


🧭 38. Informação suficiente para compreender, não necessariamente para reproduzir

Talvez possamos criar uma regra operacional útil:

INFORM
WITHOUT
UNNECESSARILY ENABLING

Explique o fenômeno.

Contextualize.

Apresente riscos.

Mostre consequências.

Indique formas seguras de denúncia.

Evite detalhes operacionais desnecessários quando eles apenas facilitariam acesso ao problema.

Isso vale para jornalismo.

Educação.

Blogs.

Vídeos.

E, sim, para Um Café no Bellacosa Mainframe.


☕ 39. O blog também faz parte do sistema

Nosso COBOLzeiro para.

Olha para a câmera.

Depois olha para nós.

— Espere.

Bruce Willis percebe.

— O quê?

— Estamos escrevendo sobre tudo isso.

Silêncio.

— Então também estamos amplificando?

Bruce responde:

— Potencialmente.

Nosso programador quase derruba o café.

É aqui que a série precisa olhar para si mesma.

Quando escrevemos sobre um fenômeno, entramos no fenômeno.

Podemos aumentar:

KNOWLEDGE

Mas também:

CURIOSITY

A responsabilidade está em como fazemos isso.


🧠 40. Educação não precisa ser tutorial de transgressão

Podemos explicar:

  • efeito Streisand;

  • migração de comunidades;

  • códigos;

  • moderação;

  • ECA;

  • liberdade;

  • algoritmos;

  • amplificação;

  • responsabilidade.

Sem fornecer:

STEP 1: GO HERE
STEP 2: SEARCH THIS
STEP 3: ENTER THIS GROUP

Existe uma diferença enorme entre:

alfabetização digital

e:

manual operacional.

Nosso veterano COBOL finalmente encontra uma especificação que gosta.


🧪 41. O teste das três perguntas

Antes de publicar informação sensível, nosso Bellacosa Mainframe cria um pequeno checklist.

01 - ESTA INFORMAÇÃO É NECESSÁRIA
     PARA COMPREENDER O FENÔMENO?

02 - ELA PODE CAUSAR DANO
     OU FACILITAR ACESSO INDEVIDO?

03 - EXISTE FORMA DE EXPLICAR
     SEM FORNECER O DETALHE OPERACIONAL?

Não é regra jurídica universal.

É uma heurística editorial.

Mas é útil.

Nosso COBOLzeiro batiza:

BELLACOSA THREE-QUESTION CHECK

Bruce Willis suspira.

— Você realmente precisa colocar seu nome em tudo?

— Branding.


🔔 42. O alerta vira propaganda involuntária

Agora voltamos à frase que iniciou tudo:

"NÃO PROCURE ISTO NA INTERNET."

Nosso sistema interpreta:

NEGATIVE COMMAND
+
SPECIFIC OBJECT
=
OBJECT DISCOVERY

É quase o clássico:

"Não pense num elefante rosa."

Pronto.

Elefante rosa.

A mente humana é irritante.

Dizer que algo existe já modifica o universo cognitivo do receptor.

Antes:

KNOWLEDGE = 0

Depois:

KNOWLEDGE = 1

Mesmo que a mensagem seja:

DO NOT ACCESS

📼 43. A velha revista retorna

Nosso COBOLzeiro abre uma gaveta.

Lá está uma revista antiga.

A matéria condenava determinado aspecto da Internet.

Alertava.

Explicava.

Mostrava.

Apresentava vocabulário.

Para o jornalista, aquilo era:

WARNING

Para um leitor curioso poderia funcionar como:

DISCOVERY GUIDE

Talvez ninguém tenha planejado isso.

Esse é justamente o ponto.

Efeitos não precisam ser intencionais para serem efeitos.

Aquela revista acaba de conectar 1990-e-alguma-coisa a Discord, IA e algoritmos de recomendação.

Os 12 Macacos fecham o círculo.


📺 44. O telejornal de ontem virou treinamento do buscador de amanhã

Antes, uma reportagem desaparecia parcialmente depois de transmitida.

Hoje ela pode:

  • ficar online;

  • ser indexada;

  • ser recortada;

  • aparecer em buscas;

  • ser transcrita;

  • ser recomendada;

  • virar vídeo de reação;

  • alimentar modelos;

  • aparecer anos depois.

O alerta não dura mais vinte minutos.

Pode durar décadas.

BROADCAST
   |
ARCHIVE
   |
INDEX
   |
SEARCH
   |
RECOMMEND
   |
AI RETRIEVAL

A mídia produz memória digital.

E memória digital é infraestrutura.


🤖 45. Agora a IA lê a velha reportagem

Aqui a coisa fica quase ficção científica.

Uma reportagem de décadas atrás é digitalizada.

Indexada.

Recuperada.

Uma IA consulta.

Resume.

Relaciona com outra fonte.

Um usuário pergunta:

"O que era aquilo?"

O sistema responde.

Informação enterrada volta à superfície.

Nosso COBOLzeiro olha para Bruce Willis.

— Então nada morre?

Bruce responde:

— Não exatamente.

— Mas pode voltar?

— Sim.

Ele olha para o terminal.

ARCHIVE != GRAVEYARD

Excelente frase para colocar numa camiseta.


🧬 46. A Internet possui memória seletiva e amnésia simultaneamente

Paradoxo delicioso.

Coisas importantes desaparecem.

Links quebram.

Sites fecham.

Serviços morrem.

Ao mesmo tempo, uma frase idiota escrita em 2009 reaparece quinze anos depois.

A Internet consegue ser simultaneamente:

FORGETFUL

e:

UNFORGIVING

É um sistema de memória projetado por um roteirista bêbado.

Perfeitamente adequado para Os 12 Macacos.


⚖️ 47. A reputação não possui ROLLBACK

Imagine acusação viral.

Depois:

CORRECTION PUBLISHED

Ótimo.

Quantas pessoas viram a acusação?

5,000,000

Quantas viram a correção?

83,000

Temos:

ORIGINAL REACH >> CORRECTION REACH

Mesmo que a informação seja corrigida, o dano reputacional pode continuar.

Nosso programador pergunta:

— Restauramos backup?

Bruce Willis responde:

— De uma reputação?

— Sim.

— Não temos.

Ele fica em silêncio.

Mainframe nunca pareceu tão confortável.


🧯 48. Comunicação de crise precisa considerar assimetria

Quando uma informação falsa viraliza, simplesmente publicar:

"Correção: não era bem assim."

pode ser insuficiente.

Organizações precisam pensar em:

  • alcance;

  • velocidade;

  • clareza;

  • evidência;

  • canais;

  • atualização;

  • transparência.

É incident response aplicado à informação.

DETECT
CONTAIN
VERIFY
COMMUNICATE
CORRECT
MONITOR
LEARN

Agora estamos falando a língua do COBOLzeiro.


🚨 49. Mas cuidado com MONITOR

Monitorar não significa vigiar toda a sociedade.

A palavra pode parecer inocente em TI.

MONITOR TRANSACTIONS

Normal.

Mas aplicada a pessoas:

MONITOR EVERYONE

entramos em outra discussão.

Privacidade.

Proporcionalidade.

Direitos.

Governança.

A solução para riscos digitais não pode simplesmente ser transformar a Internet num gigantesco panóptico.

Os valores do Capítulo IV continuam rodando em background.


🔐 50. Segurança e liberdade precisam coexistir

É tentador pensar em dois botões:

[ LIBERDADE ]
[ SEGURANÇA ]

Escolha um.

Mas sociedades democráticas precisam tentar executar ambos.

PERFORM FREEDOM
PERFORM SAFETY

com conflitos, limites e controles.

É difícil.

É imperfeito.

É frustrante.

Mas soluções simples para sistemas humanos complexos geralmente escondem custos que aparecem depois em produção.

Todo programador veterano sabe disso.


🐒 51. Finalmente encontramos os 12 Macacos?

05:42.

O terminal exibe:

SEARCH COMPLETE.

12 MONKEYS IDENTIFIED.

Nosso COBOLzeiro levanta.

— Finalmente!

Bruce Willis se aproxima.

A tela mostra:

MONKEY 01: CURIOSITY
MONKEY 02: VIRALITY
MONKEY 03: OUTRAGE
MONKEY 04: RUMOR
MONKEY 05: CONTEXT COLLAPSE
MONKEY 06: ALGORITHMIC AMPLIFICATION
MONKEY 07: SOCIAL MIGRATION
MONKEY 08: CODED LANGUAGE
MONKEY 09: AUTOMATION BIAS
MONKEY 10: FALSE CERTAINTY
MONKEY 11: PUBLIC SHAMING
MONKEY 12: UNINTENDED AMPLIFICATION

Silêncio.

Nosso programador olha para Bruce Willis.

— Então não eram pessoas?

— Nunca precisaram ser.


🧠 52. O vírus também não era uma informação específica

O terminal continua:

VIRUS IDENTIFICATION:

NOT A FILE.
NOT A POST.
NOT A PLATFORM.
NOT A USER.
NOT A WEBSITE.

— Então o que é?

Nova linha:

A SELF-REINFORCING
INFORMATION SYSTEM.

A metáfora finalmente fecha.

O vírus desta história não é um arquivo proibido.

É o sistema pelo qual:

INFORMATION
   |
CURIOSITY
   |
SEARCH
   |
DISCOVERY
   |
SHARING
   |
ALGORITHM
   |
AMPLIFICATION
   |
MEDIA
   |
MORE CURIOSITY

retroalimenta a si próprio.


🔄 53. O loop completo

Nosso COBOLzeiro escreve no quadro:

0000-INFORMATION-LOOP.

    PERFORM DISCOVERY.

    PERFORM CURIOSITY.

    PERFORM SEARCH.

    PERFORM SOCIAL-SHARING.

    PERFORM MEDIA-COVERAGE.

    PERFORM ALGORITHMIC-AMPLIFICATION.

    PERFORM MODERATION.

    PERFORM COMMUNITY-ADAPTATION.

    PERFORM PUBLIC-REACTION.

    GO TO 0000-INFORMATION-LOOP.

Bruce Willis observa.

— Você acabou de colocar a Internet num GO TO.

— Sim.

— Isso explica muita coisa.


🛑 54. Como quebrar o loop?

Nosso herói pergunta:

— Então desligamos a Internet?

NO.

— Censuramos tudo?

NO.

— Proibimos redes sociais?

NO.

— Removemos anonimato?

NO.

— Monitoramos todo mundo?

ABSOLUTELY NOT.

— Então?

O terminal responde:

REDUCE UNNECESSARY AMPLIFICATION.

VERIFY BEFORE ACCUSING.

PROTECT VICTIMS.

PRESERVE CONTEXT.

USE APPROPRIATE REPORTING CHANNELS.

DISTINGUISH POLICY FROM LAW.

DISTINGUISH ALLEGATION FROM FACT.

DESIGN SAFER SYSTEMS.

EDUCATE USERS.

KEEP HUMAN JUDGMENT.

RESPECT RIGHTS.

Nosso programador sorri.

— Isso parece trabalhoso.

Bruce Willis responde:

— Democracia também.


☕ 55. O café finalmente esfria

Pela primeira vez desde o Capítulo I, nenhuma luz vermelha pisca.

Nenhum servidor explode.

Nenhuma IA pede revisão.

Nenhum emoji aparece.

Nosso COBOLzeiro olha para sua caneca.

O café está frio.

Ele bebe mesmo assim.

Profissional de produção não desperdiça cafeína.

Bruce Willis pergunta:

— O que você aprendeu?

Ele pensa.

— Que a Internet não é um computador.

— Continue.

— É um sistema sociotécnico.

Bruce levanta a sobrancelha.

— Bonito.

— Pessoas, empresas, algoritmos, leis, comunidades, mídia, cultura, curiosidade...

— E?

Nosso programador aponta para a tela.

— E todo mundo altera o estado do sistema.


🏗️ 56. Não existe SYSADM da Internet

Essa talvez seja a maior diferença entre o universo mainframe e a sociedade digital.

No mainframe alguém possui responsabilidades relativamente definidas.

Sysprog.

Security.

DBA.

Operação.

Desenvolvimento.

Auditoria.

Na Internet global:

WHO IS SYSADM?

Resposta:

NO SINGLE SYSADM EXISTS.

Estados possuem jurisdição.

Plataformas possuem infraestrutura.

Comunidades possuem regras.

Usuários possuem escolhas.

Nenhum controla tudo.

O sistema é distribuído não apenas tecnicamente.

É distribuído institucionalmente.


🌐 57. A Internet é o maior sistema legado da humanidade

Nosso COBOLzeiro olha para Bruce Willis.

— Acho que entendi.

— O quê?

— Internet é legado.

Bruce quase engasga.

— Como?

— Protocolos antigos, tecnologias novas, compatibilidade histórica, bilhões de usuários, regras adicionadas depois, componentes que ninguém pode desligar, documentação incompleta e dependências que ninguém conhece completamente.

Silêncio.

Ele continua:

— E todo mundo quer modernizar sem parar produção.

Bruce Willis olha para a câmera.

Talvez aquele homem tenha finalmente enlouquecido.

Ou talvez tenha entendido tudo.


🐒 58. Easter egg: DELETE INTERNET

Nosso herói decide tentar uma última vez.

DELETE INTERNET

Resposta:

IKJ56700A ENTER DATA SET NAME

Ele digita:

INTERNET

Resposta:

DATA SET INTERNET NOT IN CATALOG

Bruce começa a rir.

O programador tenta:

DELETE INTERNET PURGE

Resposta:

INVALID COMMAND.

Ele pensa.

Depois:

CANCEL INTERNET
JOB INTERNET NOT FOUND.

Finalmente:

SHUTDOWN INTERNET

O terminal demora.

Então responde:

INSUFFICIENT AUTHORITY.

ALSO:

BAD IDEA.

Ele desiste.


📼 59. A fita que ninguém deveria assistir

Bruce Willis encontra uma velha fita VHS.

Na etiqueta:

DO NOT WATCH

Os dois olham.

Silêncio.

Nosso COBOLzeiro pergunta:

— Assistimos?

Bruce responde:

— Depois de seis capítulos sobre curiosidade humana?

— Justamente.

Ele coloca a fita no aparelho.

Bruce fecha os olhos.

— Nós não aprendemos nada.

A televisão acende.

Terry Gilliam provavelmente sorri em algum lugar do multiverso.


🕰️ 60. A mensagem final

Na televisão não aparece vídeo.

Apenas texto verde.

BELLACOSA INFORMATION CONTROL FACILITY
---------------------------------------

FINAL INCIDENT REPORT

SUBJECT:
THE INFORMATION OUTBREAK

ROOT CAUSE:
NOT SINGLE

CONTRIBUTING FACTORS:

HUMAN CURIOSITY
MEDIA EXPOSURE
SEARCH ENGINES
SOCIAL NETWORKS
ALGORITHMIC RECOMMENDATION
COMMUNITY MIGRATION
CODED LANGUAGE
MODERATION FEEDBACK
OUTRAGE
RUMOR
PUBLIC ACCUSATION
UNINTENDED AMPLIFICATION

---------------------------------------

IMPORTANT:

CENSORSHIP
IS NOT THE SAME AS
MODERATION.

MODERATION
IS NOT THE SAME AS
CRIMINAL LAW.

ALLEGATION
IS NOT THE SAME AS
EVIDENCE.

EVIDENCE
IS NOT THE SAME AS
CONVICTION.

PRIVACY
IS NOT THE SAME AS
IMPUNITY.

FREEDOM
IS NOT THE SAME AS
ABSENCE OF RESPONSIBILITY.

DENUNCIATION
IS NOT THE SAME AS
REPUBLICATION.

CONDEMNATION
IS NOT THE SAME AS
NON-AMPLIFICATION.

---------------------------------------

CHILDREN AND ADOLESCENTS:

PROTECT.
DO NOT EXPLOIT.
DO NOT TURN VICTIMS
INTO CONTENT.

---------------------------------------

FINAL LESSON:

BEFORE YOU SHARE,
ASK WHAT YOUR SHARE
WILL DO TO THE SYSTEM.

---------------------------------------

Nosso COBOLzeiro permanece olhando.

Depois surge uma última frase:

THE VIRUS WAS NEVER
JUST THE INFORMATION.

THE VIRUS WAS THE LOOP.

A tela apaga.


☕ 61. Epílogo — RETURN-CODE = 00?

Bruce Willis pergunta:

— Terminou?

Nosso programador verifica.

ARC-I STATUS:
COMPLETE

— Parece que sim.

— Return code?

Ele olha.

RETURN-CODE = 04

Bruce estranha.

— Warning?

— Claro.

— Por quê?

Nosso COBOLzeiro pega a caneca.

— Porque terminamos o processamento.

— E?

Ele aponta para bilhões de usuários conectados.

— Os dados continuam mudando.

Bruce sorri.

Finalmente.

Uma resposta que qualquer profissional de produção compreenderia.


🖥️ FINAL DO ARCO I

BELLACOSA MAINFRAME
INFORMATION CONTROL FACILITY
=======================================

OS 12 MACACOS, COBOL
E O VÍRUS QUE NÃO CABIA NO RACF

ARCO I
=======================================

CHAPTER I
INFORMATION OUTBREAK......... COMPLETE

CHAPTER II
DISCOVERY PARADOX............ COMPLETE

CHAPTER III
DIGITAL TRIBES............... COMPLETE

CHAPTER IV
LAW AND FREEDOM.............. COMPLETE

CHAPTER V
SEMANTIC ARMS RACE........... COMPLETE

CHAPTER VI
DIGITAL TRIBUNAL............. COMPLETE

=======================================

FINAL STATUS:

INTERNET..................... ONLINE
HUMANS....................... ONLINE
CURIOSITY.................... ONLINE
ALGORITHMS................... ONLINE
MEDIA........................ ONLINE
LAW.......................... PROCESSING
MODERATION................... PROCESSING

12 MONKEYS................... EVERYWHERE

=======================================

LESSON:

YOU CANNOT CONTROL
AN INFORMATION ECOSYSTEM
BY TREATING IT
LIKE A SINGLE FILE.

=======================================

AND REMEMBER:

A WARNING CAN INFORM.

A WARNING CAN PROTECT.

A WARNING CAN ALSO
TEACH SOMEONE
WHAT TO SEARCH FOR.

THE DIFFERENCE
MAY BE IN THE DETAILS.

=======================================

RETURN-CODE.................. 04

REASON:

THE STORY IS COMPLETE.

THE SYSTEM IS NOT.

=======================================

Nosso COBOLzeiro aperta ENTER.

Nada acontece.

Ele aperta novamente.

Nada.

Bruce Willis pergunta:

— Travou?

— Não.

— Como sabe?

O programador aponta para a última linha.

NEXT ARC NOT YET LOADED.

Bruce sorri.

— Então existe outro arco?

O COBOLzeiro serve café.

— Sempre existe outro arco.

Na tela surge rapidamente uma interferência.

Por menos de um segundo aparece:

ARCHIVE SEARCH IN PROGRESS...

QUERY:

WHO DECIDES
WHAT THE INTERNET
IS ALLOWED TO REMEMBER?

Depois desaparece.

Nosso programador encara Bruce Willis.

Bruce encara o monitor.

A cafeteira começa a funcionar sozinha.

ARC II............... AVAILABLE

FIM DO ARCO I

🐒 RETURN-CODE = 04

A história terminou. O sistema, não.

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