🏺 Diógenes e o século XXI: o cínico que habita o caos

 

Bellacosa Mainframe apresenta diogines o cinico

🏺 Diógenes e o século XXI: o cínico que habita o caos

1. A vida minimalista e a rejeição de aparências

Diógenes rejeitava convenções, riqueza, fama e normas sociais vazias.
Ele vivia com o mínimo, questionava o poder e confrontava hipocrisia diretamente.
Hoje, você percebe paralelos:

• Redes sociais forçam ostentação, performance e aprovação constante.

• Trabalho e consumo saturam a vida de estímulos desnecessários.

• Propagandas e algoritmos tentam manipular desejos.

O Cínico diria: “Desligue, minimize, questione — viva com o essencial.”
O problema moderno é que vivemos em uma aldeia de espelhos digitais que amplifica o supérfluo.

---

2. A crítica social radical

Diógenes não media palavras: criticava ricos, poderosos e moralistas com ironia direta.
Hoje, o equivalente seria alguém que expõe hipocrisia de mídia, política, religião e cultura pop, sem medo de ser cancelado ou silenciado.
A diferença é que o século XXI adicionou algoritmos de reforço, que podem amplificar crítica ou, ao contrário, aprisioná-lo em bolhas de confirmação.

---

3. Autossuficiência e liberdade interior

O Cínico acreditava que a felicidade não vinha de coisas externas — poder, dinheiro, fama — mas de autonomia e desapego.
Se refletirmos:

• Muitos se irritam com comida, política, cinema ou trabalho (como você comentou).

• Essa irritação é sinal de conflito entre valores internos e o ruído externo.

• A escola cínica, nesse sentido, oferece uma ferramenta de sobrevivência mental: desprender-se do que não importa.

---

4. A vida moderna como “simulação de excesso”

O século XXI é como uma versão digital daquilo que Diógenes rejeitava:

• Consumo desenfreado, aparências constantes, distrações infinitas.

• Redes sociais criam palco para vaidade, competição e comparação.

• Algoritmos alimentam polarização, medo e frustração.

Então, o “cínico moderno” precisa filtrar ruído, escolher autonomia, preservar atenção e discernimento — exatamente como Diógenes fazia, só que com desafios digitais e sociais diferentes.

---

5. Manipulação x realidade

A questão que você coloca — “quanto disso é real e quanto é manipulação do século XXI?” — é crucial.

• O mundo moderno é projetado para explorar emoções e expectativas humanas.

• Mas isso não invalida a percepção de injustiça, absurdo ou hipocrisia.

• Diógenes nos ensina: a consciência do absurdo não depende da manipulação, mas de olhar com clareza e coragem.

---

☕ Epílogo Bellacosa

Se Diógenes vivesse hoje, provavelmente:

• Moraria fora do consumo desenfreado, talvez numa “aldeia offline”.

• Ignoraria polarização digital, focando em liberdade interior.

• Questionaria a cultura, os algoritmos, a política e os rituais modernos, com ironia e lucidez.

E você, Vagner, ao se identificar com ele, está resgatando essa postura de autonomia, crítica e atenção ao essencial — algo que o século XXI insiste em ofuscar.

Parma: fui procurar Verdi e acabei num aniversário italiano

  

Bellacosa Mainframe memorias de Parma

☕ Um Café no Bellacosa Mainframe

🍷 PARMA — O DIA EM QUE FUI PROCURAR VERDI E ACABEI CANTANDO PARABÉNS PARA UM DESCONHECIDO

Ou: como uma pizza no café da manhã, alguns italianos lutando contra uma massa de macarrão, uma lombriga chamada Brigitte e uma jarra de vinho transformaram um almoço qualquer numa das minhas melhores lembranças da Europa

Há viagens que planejamos.

Compramos passagem, estudamos mapas, escolhemos museus, anotamos endereços, calculamos horários de trem e fazemos uma lista quase militar daquilo que precisamos conhecer.

E existem as outras.

As viagens que acontecem enquanto estamos ocupados executando o roteiro.

Minha história em Parma pertence à segunda categoria.

Eu fui até lá por causa de Giuseppe Verdi.

Voltei carregando a lembrança de um velhinho cujo nome provavelmente nem guardei.

E, décadas depois, ainda consigo descer aquelas escadas.

---

🎼 O MOTIVO ERA VERDI

Minha ida a Parma não começou pela gastronomia.

Não fui caçar restaurante famoso.

Não havia uma lista de estabelecimentos recomendados.

Não estava procurando estrelas Michelin.

Meu interesse era outro.

Eu queria conhecer um pouco mais do universo de Giuseppe Verdi.

E havia ainda uma conexão brasileira que tornava aquilo especialmente interessante para mim: Antônio Carlos Gomes, nosso grande compositor, viveu e trabalhou na Itália e pertenceu àquele extraordinário universo musical italiano do século XIX.

Portanto, naquele dia meu programa era essencialmente cultural.

Verdi.

Carlos Gomes.

Igrejas.

Ruelas.

Arquitetura.

História.

E andar.

Principalmente andar.

Eu sempre conheci cidades dessa maneira.

Coloco os pés na rua e começo a zanzar.

---

🍕 NOVE DA MANHÃ E O CAFÉ DA MANHÃ DOS CAMPEÕES

Cheguei de trem.

Era cedo, aproximadamente nove horas da manhã.

E eu já havia tomado aquilo que considero um café da manhã perfeitamente defensável:

pizza de trancio.

Nada de cereal integral.

Nada de iogurte cuidadosamente fotografado ao lado de três morangos.

Pizza.

Afinal, estávamos na Itália.

Alimentado e feliz, comecei a andar pelas ruas.

Foi então que passei diante de um restaurante.

Nada particularmente espetacular do lado de fora.

Não me lembro de estrelas.

Não parecia pertencer àquela categoria de estabelecimentos diante dos quais turistas fazem peregrinação.

Estava meio fora de mão.

E estava fechado.

Mas havia uma vitrine.

E atrás daquela vitrine acontecia uma guerra.

---

🍝 OS BRAVOS ITALIANOS LUTANDO CONTRA O MACARRÃO

Parei.

Lá dentro havia pessoas trabalhando com massa.

Não estavam montando pratos bonitos para Instagram.

O restaurante nem tinha aberto.

Era preparação.

Farinha.

Massa.

Bancada.

Braços trabalhando.

Italianos travando uma batalha corpo a corpo contra aquilo que algumas horas depois seria servido aos clientes.

Fiquei olhando.

Tirei fotografia.

Passei alguns minutos diante daquela vitrine simplesmente acompanhando o trabalho.

Talvez para eles fosse apenas mais uma manhã.

Para mim havia alguma coisa fascinante naquilo.

Era possível ver o back-end da cozinha funcionando antes da abertura do front-end.

O batch gastronômico estava em plena execução.

09:00

RESTAURANT = CLOSED
CUSTOMERS = 0
PASTA_BATCH = RUNNING
BRAZILIAN_OBSERVER = DETECTED

Guardei mentalmente o lugar.

E continuei andando.

---

⛪ VERDI, IGREJAS E QUILÔMETROS DEPOIS

Fui cumprir minha missão.

Visitei lugares ligados a Verdi.

Entrei em igrejas.

Observei prédios.

Atravessei ruas.

Fotografei.

Andei sem pressa.

Esse sempre foi um dos meus maiores prazeres viajando pela Europa: permitir que a cidade aparecesse entre um destino e outro.

Não apenas chegar.

Percorrer.

O problema é que existe um componente biológico que invariavelmente interfere nos grandes projetos culturais da humanidade.

A fome.

Por volta das treze horas, minha barriga começou a apresentar os primeiros alertas operacionais.

E então acordou uma velha companheira de viagem.

Brigitte.

Minha lombriga de estimação.

Brigitte é responsável por importantes decisões gastronômicas da minha vida.

Naquele momento ela assumiu o controle da navegação.

WARNING: FUEL LEVEL CRITICAL

BRIGITTE:
"Vagner..."

VAGNER:
"Que foi?"

BRIGITTE:
"Lembra daqueles italianos fazendo macarrão?"

VAGNER:
"..."

BRIGITTE:
"VOLTA."

Obedeci.

---

🪜 DESCENDO PARA OUTRA PARMA

Retornei ao restaurante.

Agora estava aberto.

Entrei.

E imediatamente veio aquele aroma.

Desci as escadas porque a sala onde se comia ficava no porão.

Lá embaixo encontrei exatamente o tipo de lugar que adoro descobrir viajando.

Poucas pessoas.

Nenhuma multidão.

Nenhum grupo turístico.

Nenhuma juventude fazendo fila para fotografar o prato da moda.

Havia principalmente gente de idade.

Rostos de quem parecia morar ali.

Pessoas que não haviam viajado milhares de quilômetros para conhecer Parma.

Elas eram Parma.

Conversei com o garçom.

Expliquei que era brasileiro.

Um andarilho.

E fiz talvez o melhor pedido possível naquele lugar:

— Me surpreenda.

O homem abriu um baita sorriso.

Anotou alguma coisa.

Foi embora.

Naquele instante percebi que havia cometido algo maravilhoso:

eu tinha entregado meu almoço aos italianos.

---

🍷 O SUMO DOS DEUSES

Pedi vinho da casa.

Veio numa jarra.

Nada de cerimônia.

Nada de uma garrafa acompanhada de uma palestra de quinze minutos sobre notas de carvalho, frutas vermelhas colhidas durante determinada fase da Lua ou o estado emocional das uvas.

Era vinho.

Na jarra.

Sumo dos deuses.

Chegou uma entrada.

Comecei a comer.

E observar.

Os clientes conversavam.

Os garçons circulavam.

O porão tinha vida.

Eu estava sozinho, mas não me sentia isolado.

E então chegou a comida.

Aquela mesma cozinha que eu havia espionado através do vidro às nove da manhã finalmente havia terminado seu processamento batch.

Era hora de consumir a produção.

---

🏛️ O LEGIONÁRIO VOLTOU DA GÁLIA

Aqui preciso confessar que provavelmente abandonei parte da elegância.

Estava com fome.

Tinha caminhado.

A comida estava maravilhosa.

O vinho estava ajudando.

Em algum momento comecei a comer com as mãos aquilo que permitia ser comido com as mãos.

Eu devia estar com uma expressão parecida com a de um legionário romano depois de marchar 25 quilômetros e finalmente receber comida.

Não estava degustando.

Estava mandando ver.

HUNGER_LEVEL = LEGIONARY
WINE_BUFFER = LOADED
CUTLERY = OPTIONAL
CUSTOMER_HAPPINESS = 100%

E foi aí que percebi uma mesa ao lado.

Havia dois velhinhos.

Pela minha observação rápida, concluí:

casados.

Um casal de idosos almoçando tranquilamente.

Eles começaram a me observar.

E aparentemente estavam se divertindo bastante vendo aquele brasileiro travar sua própria batalha contra a comida.

Vieram os primeiros olhares.

Sorrisos.

Até que puxaram conversa.

---

🇧🇷🤝🇮🇹 COMEÇA A DIPLOMACIA BRASIL–PARMA

Conversa vai.

Conversa vem.

Descobrem que sou brasileiro.

Explico minha peregrinação.

Falamos sobre coisas que hoje já não consigo reconstruir completamente.

Mas a barreira entre as duas mesas começa a desaparecer.

Até que eles oferecem:

— Quer experimentar isto?

Era o prato deles.

Agora havia um problema diplomático gravíssimo.

Recusar poderia provocar um incidente internacional entre Brasil e Itália.

Como patriota responsável, aceitei.

E descobri mais um sabor de Parma.

Aquilo não havia sido escolhido pelo garçom para o brasileiro.

Era aquilo que eles próprios estavam comendo.

De repente eu já não tinha apenas meu almoço.

Tinha acesso ao almoço da mesa vizinha.

Continuamos conversando.

Então veio outra oferta.

Vinho.

O vinho deles.

Aceitei novamente, desta vez já um pouco sem graça.

Mas integrado.

Comida atravessava a fronteira das mesas.

Vinho atravessava.

Histórias atravessavam.

Eu havia entrado naquele porão como um desconhecido.

Pouco tempo depois estava compartilhando comida com duas pessoas que jamais tinha visto na vida.

---

🎭 O PRIMEIRO PLOT TWIST

Foi durante a conversa que descobri que minha capacidade de investigação antropológica precisava de manutenção urgente.

Eles não eram casados.

A mulher era filha daquele senhor.

E havia mais.

Ela estava ali porque aquele dia era...

aniversário do pai.

Parei mentalmente por alguns segundos.

Então aquela não era simplesmente uma refeição cotidiana.

Eu havia entrado acidentalmente numa pequena celebração familiar.

A filha tinha levado o pai para almoçar.

E, no meio daquela comemoração, apareceu na mesa vizinha um brasileiro faminto comendo como se tivesse acabado de atravessar os Alpes com Aníbal.

Por alguma razão, eles resolveram conversar comigo.

Depois dividir a comida.

Depois dividir o vinho.

Eu estava sendo progressivamente absorvido por uma festa para a qual jamais havia sido convidado.

E ainda não tinha acontecido a melhor parte.

---

🎂 ENTÃO O GARÇOM APARECEU COM UMA TORTA

A refeição estava chegando ao fim.

Eu já havia comido maravilhosamente.

Bebido.

Conversado.

Rido.

Conhecido sabores que nem estavam no meu pedido.

Foi então que o garçom apareceu.

Carregava uma torta de aniversário.

Era para o velhinho.

E aconteceu uma dessas pequenas coisas que parecem insignificantes quando descritas rapidamente, mas que ficam armazenadas em algum lugar estranho da memória durante décadas.

Nós cantamos parabéns para ele.

A filha.

As pessoas do restaurante.

E aquele brasileiro que algumas horas antes estava do lado de fora fotografando homens fazendo macarrão através de uma vitrine.

Eu também cantei.

Para um homem cujo nome talvez eu nem tenha guardado.

Num porão em Parma.

---

❤️ NÃO ESTAVA NO SCRIPT

É aqui que a história deixa de ser sobre comida.

Eu tinha ido a Parma para procurar Verdi.

Queria história.

Música.

Carlos Gomes.

Igrejas.

Arquitetura.

E encontrei tudo isso.

Mas nenhuma dessas coisas estava naquele momento diante de mim.

Diante de mim havia apenas um senhor comemorando mais um ano de vida ao lado da filha.

E eu, um completo desconhecido, havia sido incorporado por alguns minutos àquela memória familiar.

Não estava no roteiro.

Não estava no bilhete do trem.

Não estava num guia turístico.

Não havia reservado aquela experiência pela internet.

Ninguém me vendeu um pacote chamado:

“Authentic Parma Experience — Lunch With Locals.”

Aconteceu.

Só isso.

Aconteceu.

---

🍝 A MELHOR COMIDA DA EUROPA?

Durante muitos anos, quando penso nas melhores refeições que tive na Europa, Parma aparece imediatamente.

Faço apenas uma exceção.

A comida caseira da Dona Gui, minha sogra.

Essa joga em outra categoria.

Mas, fora dela, Parma permanece em algum lugar muito especial da memória.

E hoje percebo que talvez eu tenha cometido um erro durante anos dizendo:

“Foi uma das melhores comidas que comi na Europa.”

Porque não consigo mais separar o sabor daquilo que aconteceu ao redor.

Quanto daquele macarrão era realmente macarrão?

Quanto daquele vinho era realmente vinho?

Quanto do sabor vinha do porão?

Dos velhinhos?

Da conversa?

Do prato que atravessou de uma mesa para outra?

Da jarra?

Da caminhada?

Da fome?

Da surpresa?

Do aniversário?

Da torta?

Não sei.

Talvez memória gastronômica seja justamente isso.

Comemos também o momento.

---

🧠 O BANCO DE DADOS QUE NÃO GUARDA APENAS SABORES

Décadas depois, algumas coisas desapareceram.

Não lembro cada palavra.

Não lembro necessariamente o nome de todos os pratos.

Talvez não consiga reconstruir perfeitamente o restaurante.

Mas consigo lembrar da sensação.

Curiosamente, enquanto escrevia esta história tantos anos depois, meus olhos ficaram marejados.

E isso talvez seja a melhor avaliação gastronômica que aquele restaurante jamais receberá de mim.

Não cinco estrelas.

Não dez pontos.

Não uma fotografia bonita.

Uma lembrança que ainda consegue provocar lágrimas décadas depois.

---

🚶 VIAJAR NÃO É APENAS CHEGAR

Talvez seja por isso que sempre gostei tanto de zanzar.

Quando seguimos apenas o roteiro, encontramos aquilo que fomos procurar.

Quando caminhamos sem tanta pressa, às vezes encontramos aquilo que não sabíamos que existia.

Se eu tivesse escolhido outro caminho naquela manhã, não teria visto a vitrine.

Se não tivesse parado, talvez não tivesse guardado o restaurante.

Se Brigitte não tivesse começado a reclamar às treze horas, talvez tivesse almoçado em outro lugar.

Se tivesse pedido apenas aquilo que conhecia, talvez o garçom não tivesse aberto aquele sorriso.

Se estivesse olhando para o telefone enquanto comia, talvez os dois nunca tivessem puxado conversa.

Se tivesse recusado o prato por educação, perderia um sabor.

Se tivesse recusado o vinho por vergonha, perderia outro pedaço da conversa.

Uma sequência absurda de pequenos IFs.

IF passeio = curioso
AND fome = verdadeira
AND restaurante = aquele
AND garcom = inspirado
AND mesas_vizinhas = abertas
AND viajante = disposto
THEN
    memoria = inesquecivel
END-IF

Nenhum deles isoladamente significa muita coisa.

Juntos produziram uma tarde que atravessou décadas.

---

🍷 EPÍLOGO — O VELHINHO DE PARMA

Não sei o que aconteceu depois com aquele senhor.

Não sei quantos outros aniversários ele comemorou.

Não sei se a filha alguma vez se lembrou daquele brasileiro estranho que apareceu no almoço do pai.

Provavelmente fui apenas uma pequena curiosidade daquele dia.

Talvez tenham voltado para casa e comentado:

— Aquele brasileiro estava com fome, hein?

E dado risada.

Mas existe algo bonito nisso.

Porque eles provavelmente nunca souberam que, muitos anos depois, do outro lado do Atlântico, aquele brasileiro ainda contaria a história.

Ainda lembraria do vinho.

Ainda lembraria da comida passando de uma mesa para outra.

Ainda lembraria da torta chegando.

Ainda lembraria de cantar parabéns.

Eu fui até Parma procurar a memória de homens famosos.

Giuseppe Verdi.

Antônio Carlos Gomes.

E acabei trazendo comigo a memória de um homem anônimo.

Talvez essa seja a maior ironia daquela viagem.

Verdi entrou para a História.

Carlos Gomes entrou para a História.

Mas aquele velhinho...

entrou na minha.

E talvez seja exatamente por isso que Parma continua tendo um sabor que nenhum restaurante conseguiu reproduzir.

Porque certas receitas precisam de ingredientes que não existem numa cozinha:

fome, acaso, curiosidade, generosidade, duas mesas, uma filha, um pai, uma torta e um brasileiro que simplesmente estava passando por ali.

🍷

Buon compleanno, signore.

Onde quer que o tempo tenha levado você.

Eu ainda me lembro daquele almoço.

---

☕ Um Café no Bellacosa Mainframe

Porque algumas das melhores histórias da vida nunca passaram pelo ambiente de homologação.

 

Bellacosa Mainframe e o SEO

☕ Um Café no Bellacosa Mainframe

👑 KAZUYA SOUMA E O REINO DOS 25 LIMITES DE SEO

Sitemaps, robots.txt, title tags, meta descriptions, Googlebot, conteúdo gerado por IA, AI Overviews, llms.txt, structured data, canonical URLs — e o dia em que um programador COBOL descobriu que metade das “leis do SEO” eram apenas costumes da corte.

---

🎬 PRÓLOGO — O REINO ESTAVA QUEBRADO, MAS TODOS DISCUTIAM O TAMANHO DO TITLE

Imagine a situação.

Você acaba de ser transportado para outro mundo.

Não recebeu uma espada lendária.

Não ganhou magia infinita.

Não possui um dragão.

Não consegue lançar uma bola de fogo.

Pior ainda: entregaram para você um reino quase falido, uma pilha de relatórios contraditórios e dezenas de ministros repetindo regras que ninguém sabe exatamente de onde vieram.

“Majestade! O title precisa ter exatamente 60 caracteres!”

Outro conselheiro aparece correndo:

“Não! A meta description precisa ter 160!”

Um terceiro entra desesperado:

“O artigo precisa ter 2.000 palavras ou o Google não gosta!”

Do fundo da sala surge outro:

“Precisamos instalar llms.txt imediatamente! É o novo segredo do SEO para inteligência artificial!”

Kazuya Souma olha para todos.

Silêncio.

Ele provavelmente faria aquilo que o tornou interessante em Genjitsu Shugi Yuusha no Oukoku Saikenki (How a Realist Hero Rebuilt the Kingdom): em vez de procurar uma solução espetacular, começaria separando fatos, recursos, limitações e processos.

É exatamente isso que faremos.

Porque administrar SEO em 2026 tem muito menos a ver com decorar números mágicos e muito mais com saber distinguir quatro coisas:

LIMITES TÉCNICOS
REQUISITOS
RECOMENDAÇÕES
BOAS PRÁTICAS

E essa diferença é gigantesca.

Para nosso jovem programador COBOL, podemos traduzir assim:

01 SEO-RULE.
   05 RULE-TYPE        PIC X(20).
   05 RULE-VALUE       PIC X(50).
   05 RULE-SOURCE      PIC X(100).

O problema começa quando alguém coloca tudo em:

IF REGRA = "GOOGLE MANDA"
    PERFORM OBEDECER
END-IF.

Sem verificar se o Google realmente mandou.

Bem-vindo ao Reino de Elfrieden do SEO.

Kazuya está esperando na sala do trono.

E trouxe uma planilha.

---

👑 CAPÍTULO 1 — A PRIMEIRA REFORMA: SEPARE LEI DE CONSELHO

Esta talvez seja a ideia mais importante de todo este artigo.

Considere:

Sitemap = máximo 50.000 URLs

Isso é um limite técnico.

Agora considere:

Meta description = 150 ou 160 caracteres

Isso não é um limite técnico do Google.

Há uma enorme diferença.

É semelhante a comparar:

05 WS-NOME PIC X(30).

com a recomendação:

“Procure não usar nomes excessivamente longos na interface.”

No primeiro caso existe uma restrição estrutural.

No segundo existe uma decisão de projeto.

Kazuya provavelmente começaria criando quatro ministérios.

Ministério dos Limites Técnicos

Coisas que possuem fronteiras documentadas.

Exemplo:

Sitemap:
até 50.000 URLs
ou
50 MB descompactado

Ministério dos Requisitos

Coisas necessárias para determinada funcionalidade ou formato.

Por exemplo:

Sitemap XML → UTF-8

Ministério das Recomendações

Coisas aconselhadas para melhorar funcionamento, experiência ou apresentação.

Exemplo:

Web Stories → aproximadamente 280 caracteres por página

Não significa que o Google tenha um guarda real executando:

IF STORY-LENGTH > 280
    MOVE "BANIDO DO REINO" TO SEO-STATUS
END-IF.

Ministério das Boas Práticas

Aqui entram decisões editoriais.

Por exemplo, no Bellacosa Mainframe podemos deliberadamente manter descrições SEO compactas, mesmo que não exista uma fronteira rígida de 150 ou 160 caracteres.

Essa disciplina continua útil.

Só não devemos confundir:

“É uma regra editorial que funciona bem para mim.”

com:

“Google tecnicamente proíbe passar desse número.”

Essa distinção é a primeira grande reforma administrativa de Souma.

---

🗺️ CAPÍTULO 2 — SITEMAP: O MAPA DO REINO

Imagine que Elfrieden possui 40.000 vilas.

Kazuya precisa mandar um funcionário visitar algumas delas.

Seria absurdo dizer:

“Boa sorte. Saia andando.”

Ele entrega um mapa.

O sitemap cumpre uma função semelhante para mecanismos de busca.

Simplificando bastante, ele informa:

Estas são URLs que considero importantes no meu site.

Um sitemap XML poderia conter algo parecido com:

<url>
    <loc>https://exemplo.com/cobol</loc>
</url>

<url>
    <loc>https://exemplo.com/cics</loc>
</url>

<url>
    <loc>https://exemplo.com/db2</loc>
</url>

O sitemap padrão possui dois limites importantes:

50.000 URLs por sitemap e 50 MB quando descompactado.

Perceba o detalhe da descompressão.

Você pode ter:

sitemap.xml.gz

pequeno no disco.

Mas o que interessa para o limite é o conteúdo descompactado.

Nosso COBOLeiro imediatamente reconhece a pegadinha:

tamanho armazenado e tamanho lógico não são necessariamente a mesma coisa.

Se o reino crescer demais, não precisamos jogar o mapa fora.

Criamos vários:

sitemap01.xml
sitemap02.xml
sitemap03.xml
sitemap04.xml

E então usamos um sitemap index.

Pense nele como um catálogo dos mapas:

SITEMAP INDEX
 |
 +-- sitemap-cobol.xml
 +-- sitemap-db2.xml
 +-- sitemap-cics.xml
 +-- sitemap-ims.xml
 +-- sitemap-racf.xml

Um sitemap index pode referenciar até 50.000 sitemaps.

Para um blog pessoal isso é monstruosamente grande.

Para sites de comércio eletrônico, grandes portais e marketplaces, porém, a arquitetura de sitemap passa a ser assunto sério.

---

🖼️ CAPÍTULO 3 — AS PROVÍNCIAS ESPECIAIS: IMAGENS, NOTÍCIAS E VÍDEOS

Nem todo sitemap trata apenas de páginas comuns.

Existem extensões especializadas.

Em sitemap de imagens, uma única entrada <url> pode conter até 1.000 elementos de imagem.

Algo conceitualmente parecido com:

<url>
   <loc>https://exemplo.com/mainframe</loc>

   <image:image>...</image:image>
   <image:image>...</image:image>
   <image:image>...</image:image>
</url>

Não significa simplesmente:

“Seu site só pode ter 1.000 imagens.”

Esse detalhe é importantíssimo.

A regra refere-se à estrutura daquele sitemap.

É o equivalente a alguém ler:

OCCURS 1000 TIMES

e concluir:

“O mainframe inteiro só suporta mil registros.”

Não!

Você precisa saber a que estrutura o limite pertence.

---

📰 News Sitemap

Para notícias existe outra administração provincial.

Um sitemap de notícias pode conter até 1.000 elementos de notícias, e o Google estabelece regras específicas para esse tipo de sitemap, inclusive relacionadas à atualidade das publicações.

Isso mostra uma coisa interessante:

SEO técnico é cheio de escopos.

Perguntar:

“Qual é o limite?”

sem perguntar:

“Limite de quê, dentro de qual especificação?”

é uma excelente maneira de produzir informação errada.

---

🎥 CAPÍTULO 4 — O MINISTÉRIO DO VÍDEO

O sitemap de vídeo possui suas próprias regras.

Uma descrição de vídeo nesse contexto pode chegar a 2.048 caracteres.

Temos também requisitos relacionados à thumbnail.

Um mínimo técnico documentado pode ser muito pequeno, como 60 × 30 pixels, mas seria um erro grotesco interpretar:

“mínimo aceito”

como:

“tamanho recomendado para produzir.”

É aqui que Souma interromperia a reunião.

— Ministros, existe diferença entre conseguir sobreviver com uma tigela de arroz e decidir que uma tigela de arroz é a dieta ideal do reino.

Perfeito.

SEO possui inúmeros números assim.

O fato de algo ser tecnicamente aceito não significa que seja a melhor escolha editorial.

---

⭐ CAPÍTULO 5 — O PEQUENO FAVICON E A GRANDE CONFUSÃO

O favicon parece insignificante.

Aquele pequeno símbolo exibido associado ao site pode ter enorme importância visual para reconhecimento de marca.

Existem requisitos mínimos e de proporção, incluindo formato quadrado 1:1, e o Google aceita dimensões muito pequenas, embora recomende trabalhar com resoluções maiores para melhor apresentação.

Aqui surge novamente nossa tabela administrativa:

MÍNIMO ACEITO ≠ TAMANHO IDEAL

Essa equação deveria ficar colada na parede de qualquer profissional de SEO.

Programadores já conhecem isso.

Uma aplicação pode tecnicamente funcionar com recursos mínimos.

Isso não significa que você queira colocar produção nessa configuração.

---

🤖 CAPÍTULO 6 — ROBOTS.TXT: OS GUARDAS DA FRONTEIRA

Agora chegamos a uma parte fascinante.

O arquivo:

robots.txt

fica normalmente na raiz do site.

Exemplo conceitual:

https://exemplo.com/robots.txt

Ele pode fornecer instruções de crawling para robôs compatíveis com o protocolo.

Por exemplo:

User-agent: *
Disallow: /area-interna/

Existe aqui um limite técnico importante: o Google estabelece 500 KiB para o robots.txt; conteúdo além da capacidade processada é ignorado.

Isso é bem diferente do conselho:

“Tente manter o robots.txt pequeno.”

Aqui existe efetivamente uma fronteira de processamento.

E cuidado com outro erro clássico:

robots.txt não deve ser imaginado como RACF.

Isso merece letras gigantes.

ROBOTS.TXT ≠ CONTROLE DE ACESSO

RACF pode efetivamente impedir um usuário não autorizado de acessar determinado recurso.

robots.txt é uma instrução de crawling para agentes que a respeitam.

Portanto jamais trate:

Disallow: /segredo/

como mecanismo de segurança.

É quase como colocar uma placa:

“Favor não entrar.”

e imaginar que instalou uma fechadura.

Souma demitiria o ministro da segurança na mesma tarde.

---

🕷️ CAPÍTULO 7 — O GOOGLEBOT E O MITO DOS 15 MB

A tabela original apresentava algo como:

Crawler file size = 15 MB default

Esse é um ótimo exemplo do perigo de transformar um número encontrado na internet em verdade eterna.

Documentação muda.

Infraestrutura muda.

Em 2026, o Google esclareceu limites atuais de sua infraestrutura de crawling: para o Googlebot principal, o valor documentado atualmente é 2 MB por URL individual, excluindo PDFs; PDFs possuem tratamento próprio, com limite documentado de 64 MB. O valor de 15 MB continua aparecendo como padrão para outros crawlers da infraestrutura quando não há limite específico.

E aqui está a lição mais importante:

SEO-2022 ≠ SEO-2026

Um artigo antigo pode ter sido perfeitamente correto quando publicado.

Isso não significa que permaneça correto quatro anos depois.

Nosso programador COBOL conhece esse problema.

Um manual de:

Enterprise COBOL 4

pode conter conceitos úteis.

Mas você não deve assumir que cada opção continua idêntica no COBOL moderno.

Versão importa.

Em SEO também.

---

🏷️ CAPÍTULO 8 — A LENDA DOS 60 CARACTERES

Chegamos a uma das maiores lendas da corte.

Durante anos repetiram:

“Title deve ter no máximo 60 caracteres.”

Só que não existe um limite rígido universal de 60 caracteres para o elemento <title>.

Você pode perfeitamente escrever:

<title>
Um Café no Bellacosa Mainframe — COBOL, CICS, Db2,
VSAM e os Segredos do Reino
</title>

O problema é outro.

O mecanismo de pesquisa precisa apresentar resultados dentro de uma interface.

Dependendo do dispositivo, espaço disponível e outras condições, o título mostrado pode ser truncado ou tratado de maneira diferente.

Portanto a pergunta correta não é:

“Tenho 59 ou 61 caracteres?”

É:

“Meu título comunica rapidamente o assunto e coloca informação importante cedo?”

Isso muda completamente a forma de escrever.

---

📝 CAPÍTULO 9 — META DESCRIPTION: OS 160 MANDAMENTOS QUE NÃO EXISTEM

Outra lenda:

META DESCRIPTION = MÁXIMO 160

Não existe esse limite rígido.

O snippet apresentado nos resultados pode ser truncado e o Google pode inclusive construir snippets a partir do próprio conteúdo da página.

Então por que continuar produzindo descrições Bellacosa perto de 150 caracteres/bytes como disciplina editorial?

Porque é útil!

Veja a diferença:

REGRA A:
"Não posso passar de 150 porque o Google proíbe."

REGRA B:
"Quero aproximadamente 150 porque desejo uma descrição curta,
reutilizável e informativa."

A primeira justificativa está errada.

A segunda é uma estratégia editorial perfeitamente razoável.

Souma adoraria isso.

Uma regra administrativa não precisa ter sido entregue pelos deuses para ser útil ao reino.

---

📚 CAPÍTULO 10 — QUANTAS PALAVRAS UM ARTIGO PRECISA?

E agora chegamos a uma deliciosa ironia.

Este próprio artigo foi solicitado com:

mais de 1.500 palavras.

Excelente.

Mas essas 1.500+ palavras têm uma finalidade editorial: queremos aprofundamento, exemplos, analogias e contexto.

Não estamos escrevendo 1.500 palavras porque existe algo no Google parecido com:

IF WORD-COUNT < 1500
    MOVE ZERO TO GOOGLE-RANKING
END-IF.

Isso simplesmente não existe.

Uma página explicando:

“O que significa RC=0000?”

pode resolver a dúvida rapidamente.

Já uma página explicando:

“Como funciona uma transação COBOL/CICS/Db2?”

pode legitimamente precisar de milhares de palavras.

O tamanho correto é consequência da profundidade necessária.

Não deveria ser objetivo independente.

---

🤖 CAPÍTULO 11 — O EXÉRCITO DE ESCRITORES ARTIFICIAIS CHEGA AO REINO

Então aparecem os escribas mágicos.

IA generativa.

De repente alguém pergunta:

“Qual porcentagem de IA o Google permite?”

10%?

30%?

50%?

Existe detector?

Há limite de palavras?

A pergunta começa pelo lugar errado.

Não existe uma cota universal do tipo:

HUMANO 70%
IA     30%

O problema relevante é qualidade e finalidade.

Imagine usar IA para produzir automaticamente:

10 páginas
100 páginas
10.000 páginas
1.000.000 páginas

apenas alterando palavras-chave e criando conteúdo sem valor real.

A questão deixa de ser:

“Foi IA?”

e passa a ser:

“Isso existe para ajudar pessoas ou para manipular sistemas de busca em escala?”

Esse ponto é fundamental.

IA pode ajudar a:

• organizar conhecimento;

• revisar texto;

• gerar exemplos;

• estruturar tópicos;

• transformar documentação complexa em material didático;

• comparar conceitos;

• criar perguntas;

• encontrar lacunas no raciocínio.

Mas:

IA + VOLUME

não produz automaticamente:

AUTORIDADE + QUALIDADE

---

🧠 CAPÍTULO 12 — AI OVERVIEWS E O NOVO CONSELHO REAL

Com AI Overviews e experiências generativas de pesquisa, muita gente anunciou:

“SEO morreu!”

Depois:

“SEO virou GEO!”

Depois:

“Agora precisamos escrever exclusivamente para LLMs!”

Souma provavelmente perguntaria:

— Temos evidência?

A documentação do próprio Google continua enfatizando fundamentos conhecidos: páginas rastreáveis, conteúdo útil, estrutura compreensível, qualidade, confiabilidade e boas práticas técnicas.

Ou seja, não apareceu uma magia chamada:

PERFORM RANK-IN-AI
   UNTIL POSITION = 1.

A busca está mudando profundamente.

Mas fundamentos continuam fundamentais.

É parecido com modernização de mainframe.

Adicionar:

REST
JSON
OpenAPI
z/OS Connect
Kafka
OpenTelemetry

não significa que:

COBOL
CICS
Db2
RACF

deixaram instantaneamente de importar.

A nova camada normalmente conversa com a antiga.

---

📜 CAPÍTULO 13 — LLMS.TXT: O PERGAMINHO MÁGICO

Poucas coisas representam melhor a ansiedade provocada pela IA que:

llms.txt

A ideia parece sedutora.

Temos:

robots.txt
sitemap.xml

Logo parece natural imaginar:

llms.txt

como:

“o sitemap das inteligências artificiais”.

Só que esse salto lógico é perigoso.

Para Google Search, o próprio Google esclareceu em 2026 que llms.txt não é necessário para melhorar ranking ou visibilidade.

Isso não significa que o formato jamais possa ter utilidade em outros ecossistemas.

Significa apenas:

llms.txt
   ≠
botão secreto para Google AI

E aqui escondemos nosso primeiro easter egg.

Imagine Kazuya recebendo um pergaminho:

“Majestade! Descobrimos o segredo definitivo do reino!”

Ele abre.

Está escrito:

LLMS.TXT

Kazuya consulta Hakuya.

Hakuya responde:

“Não consta no orçamento.”

Fim da reunião.

---

🧩 CAPÍTULO 14 — STRUCTURED DATA: NÃO É ENCHER JSON-LD ATÉ EXPLODIR

Structured data ajuda sistemas a compreender entidades e informações estruturadas.

Você pode encontrar JSON-LD parecido com:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Kazuya Souma e os Limites do SEO"
}

Mas a conclusão errada seria:

“Não existe limite geral de caracteres, então quanto mais structured data eu colocar, melhor.”

Não.

Os tipos possuem propriedades, requisitos e recomendações próprias.

E principalmente:

o dado estruturado deve representar o conteúdo real.

Structured data não deveria contar uma história diferente daquela que a página conta ao visitante.

---

🔗 CAPÍTULO 15 — CANONICAL: QUEM É O REI LEGÍTIMO?

Imagine cinco URLs mostrando praticamente o mesmo conteúdo:

/artigo
/artigo?ref=facebook
/artigo?utm_source=x
/artigo?versao=1
/artigo?origem=newsletter

Quem representa aquele conteúdo?

Entra:

<link rel="canonical"
      href="https://exemplo.com/artigo">

Conceitualmente estamos dizendo:

“Esta é a versão representativa que prefiro.”

Canonicalização é muito mais importante que ficar perguntando:

“Quantos caracteres uma canonical URL pode ter?”

É quase uma crise sucessória.

Temos cinco pretendentes ao trono.

Canonical ajuda a indicar:

👑 “Souma é o rei.”

---

🔤 CAPÍTULO 16 — UTF-8 ENTRA NO DATACENTER E O COBOLERO OLHA DESCONFIADO

Sitemaps XML devem utilizar UTF-8.

Nesse momento nosso veterano olha para a tela:

“EBCDIC mandou lembranças.”

😂

Esse é um ótimo exemplo para iniciantes entenderem modernização.

Seu COBOL pode trabalhar dentro de um ambiente historicamente ligado ao EBCDIC.

Mas quando atravessamos fronteiras:

Mainframe
    |
    +-- API
    +-- XML
    +-- JSON
    +-- Web
    +-- Linux
    +-- Browser

precisamos respeitar os padrões daquele ecossistema.

Modernização não significa necessariamente destruir o legado.

Muitas vezes significa traduzir corretamente nas fronteiras.

---

📱 CAPÍTULO 17 — OS 280 CARACTERES DAS WEB STORIES

Outro excelente exemplo de recomendação transformada em “lei”.

Aproximadamente 280 caracteres por página aparecem como orientação de experiência para Web Stories.

Por quê?

Porque uma Story não deveria parecer:

IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

espremida dentro da tela de um telefone.

😂

Web Story é formato visual.

Muito texto destrói a experiência.

Logo:

~280 caracteres

é uma orientação de design e legibilidade.

Não significa:

281 = ABEND S0C7

Easter egg número dois detectado.

---

🛠️ CAPÍTULO 18 — O PASSO A PASSO DE KAZUYA PARA UMA AUDITORIA

Agora vamos administrar o reino.

Quando encontrar uma lista de “novos limites SEO”, não saia imediatamente alterando seu site.

Faça o seguinte.

PASSO 1 — Identifique a afirmação

Exemplo:

Title máximo = 60 caracteres

PASSO 2 — Pergunte qual é a natureza dela

É:

limite técnico?
requisito?
recomendação?
boa prática?
opinião?

PASSO 3 — Procure a fonte primária

Prefira documentação oficial.

Não faça:

POST LINKEDIN
   ↓
BLOG QUE CITOU OUTRO BLOG
   ↓
THREAD
   ↓
VÍDEO
   ↓
"GOOGLE DISSE"

Procure chegar ao documento original.

PASSO 4 — Verifique a data

Uma informação de 2022 pode ter sido correta em 2022 e não representar 2026.

PASSO 5 — Descubra o escopo

“1.000 imagens” significa:

1.000 no site?
1.000 no sitemap?
1.000 por URL?
1.000 por domínio?

Uma palavra muda tudo.

PASSO 6 — Não confunda mínimo com recomendado

MINIMUM != OPTIMUM

PASSO 7 — Teste

Search Console, analytics, logs, indexação e comportamento real devem complementar documentação.

Souma não administraria o reino apenas lendo manuais.

Ele mediria os celeiros.

---

🔍 CAPÍTULO 19 — A AUDITORIA BELLACOSA MAINFRAME

Para um blog técnico, eu priorizaria uma auditoria aproximadamente nesta sequência lógica:

RASTREAMENTO
      ↓
INDEXAÇÃO
      ↓
CANONICALIZAÇÃO
      ↓
SITEMAP
      ↓
ARQUITETURA
      ↓
LINKS INTERNOS
      ↓
TÍTULOS
      ↓
DESCRIÇÕES
      ↓
CONTEÚDO
      ↓
IMAGENS
      ↓
DADOS ESTRUTURADOS
      ↓
PERFORMANCE
      ↓
ANALYTICS

Observe o que não aparece:

CONTAR PALAVRAS ATÉ 2.000

Também não aparece:

CORTAR TITLE NO CARACTERE 60

Muito menos:

INSTALAR LLMS.TXT E REZAR

A preocupação deveria ser:

O Google consegue descobrir a página?

Depois:

Consegue rastreá-la?

Depois:

Entende qual URL representa aquele conteúdo?

Depois:

A página responde realmente a alguma necessidade?

Depois:

Existe alguma razão para alguém preferir esse conteúdo a centenas de páginas semelhantes?

Essa última pergunta é cruel.

Mas é excelente.

---

💡 CAPÍTULO 20 — CURIOSIDADES QUE O APRENDIZ COBOL DEVE GUARDAR

SEO possui uma característica curiosamente parecida com mainframe.

Existe uma camada enorme de folclore criada em torno da tecnologia.

No mainframe ouvimos:

“COBOL está morto.”

“Mainframe não tem API.”

“Mainframe não usa TCP/IP.”

“Tudo é batch.”

“Não existe DevOps.”

Em SEO:

“60 caracteres.”

“160 caracteres.”

“2.000 palavras.”

“Keyword density.”

“IA será penalizada automaticamente.”

“llms.txt fará você aparecer nas respostas de IA.”

Quando repetidas milhares de vezes, afirmações ganham aparência de especificação.

Mas engenharia exige outra coisa:

AFIRMAÇÃO
   ↓
FONTE
   ↓
CONTEXTO
   ↓
VERSÃO/DATA
   ↓
TESTE
   ↓
EVIDÊNCIA

Esse fluxo serve tanto para SEO quanto para investigar um incidente no z/OS.

---

🥚 EASTER EGG — INCIDENTE ÀS 03:17

São 03:17 da madrugada.

O telefone toca.

O blog perdeu tráfego.

O jovem SEO entra desesperado na War Room:

“Majestade! Deve ser porque nosso title tem 63 caracteres!”

Kazuya pergunta:

— A página está indexada?

Silêncio.

— Verificaram canonical?

Silêncio.

— Sitemap?

Mais silêncio.

— robots.txt?

Ninguém responde.

— Houve alteração no template?

O programador COBOL levanta lentamente a mão.

“Majestade... ontem alguém alterou o template do Blogspot e colocou noindex.”

Kazuya fecha os olhos.

Hakuya abandona a sala.

Liscia pergunta por que contrataram 14 consultores para contar caracteres.

E o velho COBOLeiro toma outro café.

Easter egg desbloqueado: RC=0317.

---

🏰 EPÍLOGO — COMO O HERÓI REALISTA RECONSTRUIRIA O REINO DO SEO

A grande lição desses “25 novos limites” não está nos 25 números.

Está justamente em aprender quando não procurar um número.

Existem fronteiras técnicas reais:

50.000 URLs por sitemap
50 MB descompactado
50.000 sitemaps por sitemap index
1.000 imagens por URL no image sitemap
1.000 entradas em news sitemap
2.048 caracteres na descrição específica de video sitemap
500 KiB de robots.txt

Existem requisitos:

UTF-8 em sitemap
estruturas XML corretas
URLs apropriadas ao contexto

Existem recomendações:

favicon em tamanho adequado
Web Stories sem muralhas de texto
titles claros
descriptions concisas

E existem mitos:

TITLE TEM OBRIGATORIAMENTE 60
META DESCRIPTION TEM OBRIGATORIAMENTE 160
ARTIGO PRECISA TER 2.000 PALAVRAS
GOOGLE ACEITA X% DE IA
LLMS.TXT É O NOVO ROBOTS.TXT DO GOOGLE

É aí que Kazuya Souma deixa de ser apenas nossa referência de anime e se torna uma ótima metáfora para engenharia.

O protagonista realista não resolve todos os problemas usando uma espada.

Ele pergunta:

Quais recursos temos?

Qual é o problema verdadeiro?

Quais regras realmente existem?

Quem disse isso?

Os dados confirmam?

Como podemos melhorar o sistema sem desperdiçar recursos?

Esse pensamento serve perfeitamente para um programador COBOL iniciante.

Quando alguém disser:

“Mainframe funciona assim.”

Pergunte:

Em qual sistema?

Quando disser:

“COBOL não consegue fazer isso.”

Pergunte:

Qual versão?

Quando disser:

“Google exige isso.”

Pergunte:

Onde está documentado?

Quando disser:

“O limite é X.”

Pergunte:

Limite técnico ou recomendação?

Quando disser:

“Sempre fizemos assim.”

Aí, meu jovem padawan COBOL, você acaba de encontrar o equivalente tecnológico daquele ministro do reino que não sabe por que existe determinado imposto, mas continua cobrando porque seu antecessor também cobrava.

☕ E essa talvez seja a verdadeira lição de Kazuya Souma aplicada ao SEO:

não administre tecnologia por superstição. Administre por especificação, contexto, evidência e resultado.

Porque no fim das contas, seja reconstruindo Elfrieden, mantendo um programa COBOL de quarenta anos ou tentando fazer o Google entender um Blogspot em 2026, a regra continua a mesma:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. SEO-REALISTA.

       PROCEDURE DIVISION.

       INVESTIGAR.
           PERFORM LER-DOCUMENTACAO.
           PERFORM IDENTIFICAR-CONTEXTO.
           PERFORM VALIDAR-LIMITES.
           PERFORM TESTAR-RESULTADO.

           IF BOATO = TRUE
               MOVE "NAO ACREDITE AINDA"
                 TO DECISAO
           END-IF.

           IF EVIDENCIA = TRUE
               PERFORM TOMAR-DECISAO
           END-IF.

           STOP RUN.

E se alguém aparecer na próxima reunião dizendo que mudar uma meta description de 161 para 159 caracteres vai sozinho salvar o reino...

mande-o primeiro conferir se o castelo inteiro não está com noindex.

MAXCC=0000. Reino reconstruído. Café servido. ☕👑

 

Bellacosa Mainframe apresenta o ACID

☕ Um Café no Bellacosa Mainframe

🧪 PROFESSOR FARNSWORTH E AS QUATRO LEIS QUE IMPEDIAM O Db2 DE DESTRUIR O UNIVERSO

ACID, COBOL, Db2 for z/OS, COMMIT, ROLLBACK, Unit of Work, locks, IRLM, isolation levels, buffer pools, logging, recovery, CICS, deadlocks, restart — e o dia em que o Professor Farnsworth descobriu que “Good news, everyone!” não era uma estratégia válida de recuperação de banco de dados.

Sob a tutela do Professor Hubert J. Farnsworth, da Planet Express.

---

🎬 PRÓLOGO — BOAS NOTÍCIAS, PESSOAL!

Eram exatamente 03:17 da manhã quando o telefone tocou.

Nenhum programador COBOL experiente gosta de um telefone tocando às 03:17.

Às 08:00, telefone significa reunião.

Às 14:00, provavelmente alguém esqueceu uma vírgula no JCL.

Às 17:30, significa mudança emergencial que alguém garante ter sido "exaustivamente testada".

Mas às 03:17?

Às 03:17 significa produção.

O jovem programador levantou da cama, abriu o notebook e encontrou uma mensagem assustadora:

URGENTE

TRANSFERÊNCIA FINANCEIRA INCONSISTENTE

CONTA A = DEBITADA
CONTA B = NÃO CREDITADA

— Professor! Temos um problema!

Do fundo do laboratório surgiu uma figura de jaleco, chinelos e óculos grossos.

Professor Hubert J. Farnsworth levantou um dedo.

— Good news, everyone!

— Professor, desapareceram mil reais.

— Então talvez as notícias não sejam tão boas.

Na tela havia algo parecido com isto:

EXEC SQL
   UPDATE CONTA
      SET SALDO = SALDO - 1000
    WHERE CONTA_ID = 100
END-EXEC.

EXEC SQL
   UPDATE CONTA
      SET SALDO = SALDO + 1000
    WHERE CONTA_ID = 200
END-EXEC.

EXEC SQL
   COMMIT
END-EXEC.

O jovem programador olhou para o código.

— Parece simples.

Farnsworth sorriu.

Esse era precisamente o problema.

Porque atrás daquele pequeno COMMIT existia um universo inteiro chamado:

ACID.

---

🧪 CAPÍTULO 1 — AS QUATRO LEIS DO UNIVERSO TRANSACIONAL

Quem começa a estudar banco de dados encontra rapidamente a famosa sigla:

A — Atomicity
C — Consistency
I — Isolation
D — Durability

Em português:

Atomicidade
Consistência
Isolamento
Durabilidade

O resumo de bolso é:

Atomicidade  → tudo ou nada
Consistência → dados continuam válidos
Isolamento   → controlar concorrência
Durabilidade → confirmou, deve permanecer

Está correto.

Mas para quem trabalha com Db2 for z/OS, isso é apenas a porta do laboratório.

Atrás dela encontramos:

COBOL
   │
   ▼
CICS / Batch
   │
   ▼
Db2
   │
   ├── Unit of Work
   ├── COMMIT / ROLLBACK
   ├── Locks
   ├── IRLM
   ├── Isolation Levels
   ├── Buffer Pools
   ├── Logging
   ├── Checkpoints
   ├── Recovery
   └── Restart

ACID não é simplesmente uma propriedade acadêmica do banco.

É uma resposta para uma pergunta muito mais séria:

Como manter os dados confiáveis quando programas falham, máquinas param, transações concorrem e seres humanos fazem coisas que o Professor Farnsworth jamais colocaria em uma especificação?

Vamos entrar no laboratório.

---

⚛️ CAPÍTULO 2 — A DE ATOMICITY: NÃO EXISTE MEIA TRANSFERÊNCIA

Imagine duas contas:

CONTA A = R$ 5.000
CONTA B = R$ 3.000

Precisamos transferir:

R$ 1.000

O resultado correto é:

CONTA A = R$ 4.000
CONTA B = R$ 4.000

O programa executa:

1. debita A
2. credita B
3. registra movimento
4. COMMIT

Mas o universo não é obrigado a colaborar.

Pode acontecer:

1. debita A ............ OK
2. credita B ........... OK
3. registra movimento .. ABEND

Sem atomicidade, poderíamos terminar com um estado parcialmente processado.

E isso é exatamente o que não queremos.

Farnsworth desenharia no quadro:

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

Essa caixa representa uma Unit of Work, ou UOW.

Ela é muito mais importante do que pensar individualmente em cada SQL.

O iniciante olha para:

UPDATE CONTA ...

O engenheiro começa a perguntar:

A qual unidade lógica de negócio esse UPDATE pertence?

Essa mudança mental é enorme.

---

💥 CAPÍTULO 3 — O ABEND NO MEIO DA EXPERIÊNCIA

Agora Farnsworth puxa uma enorme alavanca vermelha.

O jovem programador grita:

— Professor, o que essa alavanca faz?

CLICK.

As luzes apagam.

— Descobriremos!

Imagine que o Db2 estivesse processando:

BEGIN UOW

UPDATE A
     │
     ▼
A = 4000

UPDATE B
     │
     ▼

💥 FALHA

A transação ainda não chegou ao seu ponto de confirmação.

O banco precisa conseguir impedir que o trabalho incompleto se transforme permanentemente no novo estado lógico.

É aí que entram mecanismos como:

ROLLBACK
BACKOUT
LOGGING
RECOVERY

A ideia de atomicidade pode ser resumida assim:

             TRANSAÇÃO

                  │
          ┌───────┴───────┐
          ▼               ▼
       SUCESSO           FALHA
          │               │
          ▼               ▼
       COMMIT        ROLLBACK/BACKOUT
          │               │
          ▼               ▼
     CONFIRMADA       DESFEITA

O importante é que o banco não termine no meio do caminho lógico.

---

🛑 CAPÍTULO 4 — COMMIT NÃO SIGNIFICA APENAS "SALVAR"

Essa é uma das primeiras armadilhas para o programador COBOL iniciante.

Muitos aprendem:

COMMIT   = salvar
ROLLBACK = desfazer

Não está totalmente errado.

Mas é uma simplificação perigosa.

Pense no COMMIT como:

a declaração de que uma Unit of Work alcançou seu ponto de confirmação.

Portanto:

EXEC SQL
   COMMIT
END-EXEC.

não deveria ser colocado aleatoriamente no programa.

O lugar do COMMIT define fronteiras transacionais.

Imagine um batch processando dez milhões de registros.

Você poderia fazer:

registro 1
registro 2
registro 3
...
registro 10.000.000

COMMIT

Farnsworth olharia para isso e provavelmente diria:

— Excelente! Agora só precisamos esperar alguma coisa falhar no registro 9.999.999.

Uma UOW gigantesca pode trazer consequências para logging, recursos, locking, rollback, concorrência e restart.

Por isso aplicações batch frequentemente utilizam commits periódicos:

processa 1.000
COMMIT

processa 1.000
COMMIT

processa 1.000
COMMIT

Mas atenção.

Não existe um número mágico:

COMMIT A CADA 1000

que seja correto para todas as aplicações.

O intervalo depende de coisas como volume, duração, concorrência, requisitos do negócio, custo de restart e características do workload.

---

🔄 CAPÍTULO 5 — DEPOIS DO COMMIT NÃO EXISTE BORRACHA MÁGICA

Suponha:

Registros 1–1000
COMMIT

1001–2000
COMMIT

2001–3000
COMMIT

3001–3782
💥 ABEND

Um ROLLBACK não vai magicamente voltar ao registro 1.

As UOWs anteriores já foram confirmadas.

O programa precisa saber:

último COMMIT válido = registro 3000

E isso nos leva a um conceito importantíssimo em batch:

Restartability.

Uma aplicação bem projetada pode guardar um checkpoint lógico próprio, chave de último registro processado ou outra informação de controle adequada ao desenho.

No restart:

JOB reiniciado
      │
      ▼
consulta controle
      │
      ▼
último ponto = 3000
      │
      ▼
continua de forma segura

E surge uma nova pergunta:

Se eu executar novamente uma operação, ela produzirá o mesmo resultado ou duplicará dinheiro?

Bem-vindo ao mundo da idempotência.

ACID não resolve sozinho todos os problemas de restart da aplicação.

---

🧱 CAPÍTULO 6 — C DE CONSISTENCY: O Db2 NÃO CONHECE O REGULAMENTO DO PLANETA EXPRESS

Consistência significa que uma transação deve levar o banco de um estado válido para outro estado válido, respeitando as regras relevantes.

O Db2 conhece muitas regras estruturais porque nós as declaramos.

Por exemplo:

CREATE TABLE CONTA
(
    CONTA_ID INTEGER NOT NULL,
    CLIENTE_ID INTEGER NOT NULL,
    SALDO DECIMAL(15,2) NOT NULL,

    PRIMARY KEY (CONTA_ID)
);

Podemos utilizar mecanismos como:

PRIMARY KEY
FOREIGN KEY
UNIQUE
CHECK
NOT NULL

Eles ajudam a preservar integridade.

Por exemplo, uma FOREIGN KEY pode estabelecer uma relação entre conta e cliente.

Mas Farnsworth faz uma pergunta:

— O Db2 sabe que clientes marcianos recebem 15% de desconto às terças-feiras?

Não.

A menos que essa regra esteja adequadamente representada na solução, o banco não a inventará.

Temos então três mundos:

       CONSISTÊNCIA

      /      |       \
     /       |        \
    ▼        ▼         ▼

DATABASE   APLICAÇÃO   NEGÓCIO

Um valor pode ser perfeitamente válido para um DECIMAL(15,2) e completamente absurdo para a empresa.

Por exemplo:

SALDO = -999999999.99

O datatype pode aceitar.

A regra empresarial talvez não.

Portanto:

Consistência ACID não significa que o Db2 entende automaticamente todas as regras da empresa.

Essa é uma diferença pequena na frase e gigantesca na arquitetura.

---

👥 CAPÍTULO 7 — I DE ISOLATION: FRY E BENDER SACAM O MESMO DINHEIRO

Agora temos:

SALDO = R$ 1.000

Fry tenta sacar:

R$ 800

Bender, exatamente ao mesmo tempo, tenta sacar:

R$ 800

Imagine ingenuamente:

FRY                       BENDER

SELECT SALDO              SELECT SALDO
     │                         │
     ▼                         ▼
   1000                      1000

"Tem dinheiro!"            "Tem dinheiro!"

Agora os dois tentam continuar.

Concorrência é um dos grandes problemas que bancos de dados transacionais precisam controlar.

É aqui que Isolation começa a conversar com:

locks
IRLM
UR
CS
RS
RR
deadlocks
timeouts

---

🔐 CAPÍTULO 8 — IRLM: O PORTEIRO DO LABORATÓRIO

No ecossistema Db2 for z/OS aparece um personagem importantíssimo:

IRLM — Internal Resource Lock Manager.

Uma representação conceitual:

PROGRAMA A
    │
    ▼
   Db2
    │
    ▼
   IRLM
    ▲
    │
PROGRAMA B

Suponha que A esteja alterando determinado recurso e possua um lock incompatível com aquilo que B deseja fazer.

B pode precisar esperar.

A:

UPDATE CONTA 100
      │
      ▼
    LOCK
      │
      │
      │     B:
      │
      │     UPDATE CONTA 100
      │            │
      │            ▼
      │           WAIT
      │
   COMMIT
      │
      ▼
 liberação conforme
 regras aplicáveis

O usuário pode reclamar:

"O sistema está esperando!"

Mas aquela espera pode ser justamente parte do mecanismo que evita resultados transacionais incorretos.

Performance e consistência frequentemente precisam conversar.

---

👻 CAPÍTULO 9 — O FANTASMA DO DIRTY READ

Farnsworth altera um saldo:

T1:

1000 → 100

Mas ainda não fez COMMIT.

Outra transação lê aquele valor.

Depois T1 executa:

ROLLBACK

O saldo retorna a 1000.

A segunda transação acabou de enxergar um valor que nunca se tornou um estado confirmado.

Esse fenômeno é associado a:

Dirty Read.

Conceitualmente:

T1                T2

UPDATE 100
   │
   │
   ├──────────► lê 100
   │
ROLLBACK
   │
   ▼
volta 1000

T2 tomou conhecimento de um estado intermediário que foi posteriormente abandonado.

E agora precisamos falar dos níveis de isolamento.

---

🧬 CAPÍTULO 10 — UR, CS, RS E RR

No Db2 for z/OS, quatro nomes aparecem frequentemente:

UR — Uncommitted Read
CS — Cursor Stability
RS — Read Stability
RR — Repeatable Read

O erro do iniciante é imaginar:

UR = ruim
RR = excelente

Não.

São escolhas com comportamentos e custos diferentes.

Uma maneira didática de pensar é:

            maior proteção
                  ▲
                  │
                 RR
                  │
                 RS
                  │
                 CS
                  │
                 UR
                  │
                  ▼
       maior liberdade de leitura

Mas não transforme isso numa simples régua de qualidade.

A pergunta correta é:

Qual garantia de isolamento esta transação realmente precisa?

Um relatório estatístico pode aceitar comportamento que seria inadmissível em uma autorização financeira.

Mais isolamento também pode significar impactos na concorrência e no locking.

Engenharia é escolher conscientemente.

---

👻 CAPÍTULO 11 — NON-REPEATABLE READ

Fry executa:

SELECT SALDO
FROM CONTA
WHERE CONTA_ID = 10;

Obtém:

1000

Outra transação altera a mesma linha e confirma:

1000 → 1500

COMMIT

Fry lê novamente e, dependendo das garantias aplicáveis, pode encontrar:

1500

Temos conceitualmente:

primeira leitura = 1000

segunda leitura  = 1500

A mesma linha não repetiu o valor observado anteriormente.

Daí o nome:

non-repeatable read.

---

👻 CAPÍTULO 12 — PHANTOM READ: AGORA APARECEU OUTRO BENDER

Considere:

SELECT COUNT(*)
FROM PEDIDO
WHERE STATUS = 'PENDENTE';

Resultado:

100

Outra transação executa:

INSERT INTO PEDIDO ...

criando outro pedido PENDENTE, e confirma.

Uma nova execução da consulta pode encontrar:

101

A diferença para o exemplo anterior é fascinante.

Não necessariamente alteraram uma das linhas que você já tinha visto.

O conjunto de linhas que satisfaz o predicado mudou.

Temos então três fenômenos fáceis de diferenciar:

DIRTY READ
→ observei dado não confirmado.

NON-REPEATABLE READ
→ uma linha observada mudou.

PHANTOM
→ o conjunto correspondente ao predicado mudou.

Farnsworth chamaria o último de:

— Fantasmas quânticos relacionais!

Não use esse termo numa prova de certificação.

---

💀 CAPÍTULO 13 — DEADLOCK: FRY ESPERA BENDER, BENDER ESPERA FRY

Imagine:

TRANSAÇÃO A                TRANSAÇÃO B

LOCK RECURSO X             LOCK RECURSO Y
      │                          │
      ▼                          ▼

quer Y                      quer X
      │                          │
      ▼                          ▼

WAIT                         WAIT

Temos um ciclo:

A espera B
▲         │
│         ▼
└──────── B

Isso é deadlock.

O sistema precisa romper a situação e uma das unidades de trabalho envolvidas acaba sendo tratada como vítima.

Para o programador COBOL surge uma lição essencial:

IF SQLCODE NOT = ZERO
    DISPLAY 'ERRO'
END-IF

não representa tratamento transacional adequado.

É necessário compreender o SQLCODE/SQLSTATE e decidir o comportamento correto da aplicação.

---

⏱️ CAPÍTULO 14 — TIMEOUT NÃO É DEADLOCK

Farnsworth deixa Bender segurando a chave do laboratório.

Fry espera.

E espera.

E espera.

Não existe necessariamente um ciclo.

Existe um recurso indisponível durante tempo suficiente para que o limite aplicável seja atingido.

Conceitualmente:

DEADLOCK:

A → B
↑   │
└───┘


TIMEOUT:

A possui recurso

B → WAIT → WAIT → WAIT → limite

Para o usuário:

"Travou."

Para quem investiga produção:

Precisamos saber exatamente por quê.

Essa é a diferença entre observar sintoma e diagnosticar sistema.

---

💾 CAPÍTULO 15 — D DE DURABILITY: O SEGREDO DO COMMIT

Agora Farnsworth aperta novamente o botão vermelho.

— Professor, não!

Tarde demais.

💥

O Db2 caiu logo depois de uma transação ter sido confirmada.

A pergunta é:

Os dados confirmados desapareceram?

A durabilidade existe justamente para estabelecer a expectativa de que uma transação efetivamente comprometida sobreviva a falhas dentro das garantias do sistema.

Mas aqui encontramos uma curiosidade fantástica.

Muitos iniciantes imaginam:

UPDATE
   │
   ▼
grava imediatamente a página no DASD
   │
   ▼
COMMIT

Essa visão é simples demais.

Db2 utiliza buffer pools.

---

🏊 CAPÍTULO 16 — BUFFER POOL: A PISCINA DO PROFESSOR

Imagine uma página trazida para memória:

       DASD
         │
         ▼
    BUFFER POOL
   ┌────────────┐
   │ DATA PAGE  │
   └────────────┘

Ela é alterada:

    BUFFER POOL
   ┌────────────┐
   │ MODIFIED   │
   │   PAGE     │
   └────────────┘

Essa página modificada precisa, em algum momento apropriado, chegar ao armazenamento persistente.

Mas seria terrivelmente caro exigir ingenuamente uma escrita física completa da página de dados a cada simples UPDATE.

Então surge outro personagem fundamental:

O Db2 Log.

---

📜 CAPÍTULO 17 — O DIÁRIO SECRETO DO Db2

O Db2 mantém informações de log essenciais para recovery.

Mentalmente:

             SQL UPDATE
                 │
        ┌────────┴────────┐
        ▼                 ▼
   BUFFER POOL          LOG
        │                 │
        ▼                 ▼
   DATA PAGES         RECOVERY

É por isso que uma ideia crucial é:

COMMIT não deve ser entendido como "todas as páginas modificadas foram necessariamente gravadas fisicamente no tablespace naquele mesmo instante".

O sistema possui mecanismos de logging e recuperação justamente para separar adequadamente esses eventos sem abandonar durabilidade.

Esse ponto muda completamente a compreensão do COMMIT.

---

✍️ CAPÍTULO 18 — WRITE-AHEAD LOGGING

Entra em cena o princípio de Write-Ahead Logging, WAL.

De forma didática, as informações de log necessárias à recuperação precisam obedecer à ordenação apropriada em relação às páginas de dados modificadas.

Farnsworth explicaria:

Antes de mandar Bender alterar o universo, anote no diário o suficiente para descobrir depois o que ele fez.

Suponha o log conceitual:

T001 UPDATE A
T001 UPDATE B
T001 COMMIT

T002 UPDATE C
T002 UPDATE D

💥 CRASH

Temos duas situações.

T001 foi confirmada.

T002 não chegou ao commit.

Durante recovery, o sistema possui informações para preservar/reaplicar o que deve sobreviver e desfazer/backout do que não deveria permanecer, conforme necessário.

Didaticamente:

T001 → REDO se necessário

T002 → UNDO/BACKOUT conforme necessário

E aqui acontece algo maravilhoso.

---

♻️ CAPÍTULO 19 — ATOMICITY E DURABILITY SE ENCONTRAM NO LOG

Veja:

                    LOG
                  /     \
                 /       \
                ▼         ▼
              UNDO       REDO
                │         │
                ▼         ▼
          ATOMICITY   DURABILITY

Atomicidade diz:

Trabalho incompleto não pode permanecer como se estivesse confirmado.

Durabilidade diz:

Trabalho confirmado não deve desaparecer simplesmente porque houve uma falha.

O log ajuda o Db2 a navegar entre esses dois mundos.

ACID deixa de parecer quatro palavras independentes.

É uma engrenagem.

---

🗄️ CAPÍTULO 20 — ACTIVE LOG, ARCHIVE LOG E A MÁQUINA DO TEMPO

No Db2 for z/OS encontramos active logs e archive logs dentro da arquitetura de logging.

Uma representação simplificada:

TRANSAÇÕES
     │
     ▼
 ACTIVE LOG
     │
     │ offload
     ▼
ARCHIVE LOG

Ao avançarmos em Db2 recovery aparecem ainda termos importantíssimos:

BSDS
RBA / LRSN
checkpoints
image copies
RECOVER
restart
active logs
archive logs

Perceba como uma simples aula sobre ACID acaba levando diretamente para Backup & Recovery de Db2 for z/OS.

É por isso que conhecimento mainframe funciona como uma catedral.

Você abre uma porta e encontra outras vinte.

---

🚦 CAPÍTULO 21 — COMMIT, CHECKPOINT E IMAGE COPY NÃO SÃO A MESMA COISA

Guarde isto:

COMMIT ≠ CHECKPOINT ≠ IMAGE COPY

O COMMIT está relacionado à confirmação da Unit of Work.

O checkpoint do Db2 participa de mecanismos internos importantes para restart/recovery e gerenciamento do sistema.

Uma image copy é utilizada dentro da estratégia de backup/recovery dos objetos Db2.

Três ferramentas do universo da confiabilidade.

Três finalidades diferentes.

Misturá-las é como confundir:

SAVE
BACKUP
TRANSACTION

só porque todas parecem envolver a ideia de "não perder alguma coisa".

---

🚀 CAPÍTULO 22 — PROFESSOR, TEM CICS NESSA EXPERIÊNCIA?

Tem.

E agora Farnsworth realmente fica animado.

Imagine:

ATM / MOBILE / API
        │
        ▼
       CICS
        │
        ▼
      COBOL
        │
   ┌────┼────┐
   ▼    ▼    ▼
  Db2   MQ   VSAM

Uma única operação de negócio pode envolver vários recursos.

Suponha:

1. atualizar Db2
2. atualizar outro recurso transacional
3. produzir uma mensagem

A pergunta já não é apenas:

O Db2 confirmou?

Passa a ser:

A unidade lógica completa foi coordenada corretamente entre os resource managers participantes?

Aqui aparecem conceitos como:

SYNCPOINT
resource managers
transaction coordination
two-phase commit

E percebemos por que o mundo transacional mainframe é muito maior que EXEC SQL.

---

🤝 CAPÍTULO 23 — TWO-PHASE COMMIT, OU "TODO MUNDO PRONTO?"

Didaticamente, pense num coordenador perguntando:

              COORDENADOR
                   │
          ┌────────┴────────┐
          ▼                 ▼
         Db2                MQ

       pronto?            pronto?
          │                 │
         YES               YES
          │                 │
          └────────┬────────┘
                   ▼
                 COMMIT

Se a operação não puder prosseguir adequadamente, entra o caminho de rollback/recovery previsto pelo protocolo e pelos participantes.

A realidade é mais sofisticada que esse desenho, mas ele mostra uma coisa essencial:

Atomicidade dentro de um banco já é interessante. Atomicidade envolvendo múltiplos resource managers é outro nível de engenharia.

---

📦 CAPÍTULO 24 — ACID NÃO IMPEDE PAGAMENTO DUPLICADO POR MÁGICA

Farnsworth envia a mensagem:

PAGAMENTO 98472

A rede apresenta problema.

A aplicação tenta novamente:

PAGAMENTO 98472

Temos duas mensagens.

Cada processamento individual pode ser perfeitamente ACID.

Ainda assim, se a aplicação não identificar a duplicidade, poderemos processar o mesmo evento duas vezes.

Talvez o desenho utilize algo equivalente a:

TRANSACTION_ID UNIQUE

ou outra estratégia de idempotência.

Portanto:

ACID
   ≠
IDEMPOTÊNCIA

ACID também não substitui:

tratamento de retries
deduplicação
regras de negócio
recovery da aplicação
restartability

Essa distinção tornou-se ainda mais importante quando o mainframe começou a conversar intensamente com:

APIs
MQ
eventos
cloud
microservices
Kafka

---

💳 CAPÍTULO 25 — O TESTE FINAL: DUAS COMPRAS, UM LIMITE

Chegamos à experiência final do laboratório.

Limite disponível:

R$ 1.000

Compra de Fry:

R$ 700

Compra de Bender:

R$ 600

As duas chegam praticamente juntas:

                 R$1000
                    │
             ┌──────┴──────┐
             ▼             ▼
          R$700           R$600

Agora ACID inteiro entra em ação.

Atomicity

Se a autorização depende de registrar movimento e atualizar o limite, precisamos da unidade transacional correta.

Não queremos:

limite reduzido
+
autorização inexistente

Consistency

Constraints, relacionamentos e regras implementadas precisam permanecer válidos.

Isolation

As duas compras não podem simplesmente tomar decisões independentes baseadas numa visão concorrente inadequada dos mesmos R$ 1.000.

Aqui entram isolamento, locking e concorrência.

Durability

Depois que a autorização foi efetivamente confirmada, uma falha posterior não deve simplesmente apagá-la da história.

Agora ACID não é mais uma pergunta de entrevista.

É dinheiro.

---

🧰 CAPÍTULO 26 — CHECKLIST DO PADAWAN COBOL

Sempre que encontrar:

EXEC SQL
   COMMIT
END-EXEC.

não passe correndo.

Pare e investigue:

1. Qual Unit of Work termina aqui?

2. Quais alterações pertencem à mesma operação de negócio?

3. O que acontece se houver ABEND antes deste ponto?

4. E imediatamente depois?

5. Como funciona o restart?

6. Existe risco de reprocessamento?

7. A operação é idempotente?

8. Quais outras transações concorrem pelos mesmos dados?

9. Qual isolamento é necessário?

10. Há CICS, MQ ou outros resource managers envolvidos?

11. O programa trata deadlock e timeout adequadamente?

12. As constraints representam todas as regras importantes ou parte delas vive no COBOL?

Essas doze perguntas valem mais do que decorar ACID para uma prova.

---

🗺️ CAPÍTULO 27 — O MAPA DO LABORATÓRIO FARNSWORTH

No final da aula, o Professor desenhou tudo no quadro:

                       A C I D
                          │
       ┌──────────────────┼──────────────────┐
       │                  │                  │
       ▼                  ▼                  ▼
  ATOMICITY          CONSISTENCY         ISOLATION
       │                  │                  │
       ▼                  ▼                  ▼
     UOW              Constraints          IRLM
   COMMIT              PK / FK             Locks
  ROLLBACK             UNIQUE            UR/CS/RS/RR
  BACKOUT              CHECK                │
       │               Business        ┌────┴────┐
       │                Rules          ▼         ▼
       │                           Deadlock   Timeout
       │
       └──────────────┐
                      ▼
                    LOG
                 ┌────┴────┐
                 ▼         ▼
               UNDO       REDO
                 │         │
                 ▼         ▼
            Atomicity  Durability
                           │
                ┌──────────┼───────────┐
                ▼          ▼           ▼
           Active Log  Archive Log  Recovery
                                       │
                                       ▼
                                     Restart

E acima disso:

                   USUÁRIO
                      │
                      ▼
                 CICS / BATCH
                      │
                      ▼
                    COBOL
                      │
                      ▼
                     Db2
          ┌───────────┼───────────┐
          ▼           ▼           ▼
     BUFFER POOL     IRLM         LOG
          │           │           │
          ▼           ▼           ▼
        DATA        LOCKING    RECOVERY
          │           │           │
          └───────────┼───────────┘
                      ▼
                     ACID

---

🧪 EPÍLOGO — GOOD NEWS, EVERYONE!

O jovem programador olhou novamente para o programa.

Naquela manhã, o código parecia simples:

EXEC SQL
   COMMIT
END-EXEC.

Agora ele enxergava outra coisa.

Via uma Unit of Work.

Via alterações ainda não confirmadas.

Via locks sendo administrados.

Via transações concorrentes.

Via IRLM.

Via páginas no buffer pool.

Via logging.

Via trabalho confirmado e não confirmado.

Via possibilidades de REDO e UNDO.

Via restart.

Via CICS coordenando recursos.

Via o batch que precisava saber de onde continuar.

Via o pagamento duplicado que ACID sozinho não impediria.

Via o deadlock escondido entre duas transações perfeitamente corretas quando observadas isoladamente.

Finalmente percebeu uma coisa que todo programador COBOL que trabalha seriamente com Db2 acaba descobrindo:

O SQL que você escreve é apenas a parte visível da transação.

Farnsworth colocou a mão sobre a enorme alavanca vermelha.

— Professor...

— Sim?

— Não toque nisso.

O velho cientista sorriu.

— Good news, everyone! Eu instalei um COMMIT!

— Professor, COMMIT não é backup.

Silêncio.

— Muito bem, jovem.

Farnsworth afastou lentamente a mão da alavanca.

E essa talvez seja a melhor definição do salto entre aprender SQL e começar a compreender Db2 for z/OS.

No começo aprendemos:

SELECT
INSERT
UPDATE
DELETE

Depois aprendemos:

COMMIT
ROLLBACK

Mas o verdadeiro salto acontece quando olhamos para um UPDATE e imediatamente pensamos:

Quem mais está acessando isto?

Qual é minha UOW?

Que lock posso provocar?

Qual isolamento preciso?

O que acontece se eu falhar agora?

O que já está confirmado?

Como faço restart?

Posso executar novamente?

Existe outro resource manager?

Como o Db2 recuperará isso?

Nesse momento você deixa de enxergar Db2 apenas como um lugar onde o COBOL guarda registros.

Você começa a enxergá-lo como uma máquina transacional construída para administrar simultaneamente mudança, concorrência e falha.

E essa é a grande sacada escondida nas quatro letras:

A C I D

ATOMICITY
   │
   └── Não deixe metade da história acontecer.

CONSISTENCY
   │
   └── Não transforme um estado válido em absurdo.

ISOLATION
   │
   └── Não deixe milhares de histórias simultâneas
       destruírem umas às outras.

DURABILITY
   │
   └── Depois de confirmar a história,
       não deixe uma falha apagá-la.

É por isso que bancos, cartões, seguradoras, companhias aéreas, varejistas e tantas outras empresas podem executar volumes enormes de transações sem depender da esperança de que "nada dê errado".

Porque coisas dão errado.

Programas sofrem ABEND.

Jobs são reiniciados.

Transações entram em deadlock.

Recursos ficam indisponíveis.

Sistemas precisam de recovery.

Mensagens podem ser reenviadas.

Aplicações concorrem.

Máquinas podem parar.

E às vezes alguém liga às 03:17 da manhã.

A genialidade não está em construir um universo onde falhas sejam impossíveis.

Está em construir um sistema que saiba o que fazer quando elas inevitavelmente acontecerem.

Farnsworth apagou as luzes do laboratório.

Na tela permaneceu apenas uma mensagem:

DSNE610I NUMBER OF ROWS DISPLAYED IS 1

E, ao lado dela, uma pequena anotação:

*> GOOD NEWS, EVERYONE.
*> SQLCODE = 0.

☕ Bem-vindo ao Db2 no mainframe, Padawan. Aqui até o caos precisa respeitar a Unit of Work.