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

Translate

quinta-feira, 17 de fevereiro de 2022

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.


quarta-feira, 16 de fevereiro de 2022

👑 KAZUYA SOUMA E O REINO DOS 25 LIMITES DE SEO

 

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

terça-feira, 8 de fevereiro de 2022

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

 

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.

segunda-feira, 7 de fevereiro de 2022

O Homem que Resolveu a Pensão com Capacity Planning

 

Bellacosa Mainframe e o capacity planning aplicado a pensão alimenticia

☕ Um Café no Bellacosa Mainframe

O Homem que Resolveu a Pensão com Capacity Planning

Ou: quando o Red Team encontrou uma vulnerabilidade no ambiente familiar, o Blue Team chamou o advogado, o WLM redistribuiu os recursos — e o CAB aprovou uma mudança que exigia urologista


Existem histórias que começam num tribunal.

Outras começam num casamento.

Algumas começam com uma decisão ruim tomada às três da manhã.

Esta começa como quase todas as grandes histórias da civilização ocidental deveriam começar:

num boteco, em Itatiba, com uma Original sobre a mesa.

Não vou dar nomes porque nomes estragam excelentes histórias e enriquecem advogados.

Diremos apenas que nosso protagonista era um sujeito normal.

Trabalhava.

Tinha esposa.

Tinha filhos.

Pagava contas.

Provavelmente reclamava do preço da gasolina.

Talvez discutisse futebol.

Nada que justificasse abertura de incidente no ServiceNow.

Até que um dia o ambiente de produção recebeu uma atualização não prevista no roadmap.

Havia um filho fora do casamento.

E, com ele, chegou uma palavra capaz de transformar qualquer mesa de bar brasileira numa banca examinadora da Faculdade de Direito:

pensão.

Imediatamente aparece o especialista.

Ele sempre aparece.

Pode ser o dono do bar.

Pode ser o sujeito da mesa ao lado.

Pode ser o cunhado do primo do padeiro.

Mas aparecerá.

— Pensão é trinta por cento.

Não.

Respire.

Pegue sua cerveja.

Não existe uma lei brasileira dizendo que pensão alimentícia é obrigatoriamente 30% ou 1/3 da renda.

O Código Civil determina que os alimentos sejam fixados considerando as necessidades de quem os recebe e os recursos de quem deve prestá-los. O valor pode ser percentual, quantia fixa ou adotar outros critérios conforme o caso.

O próprio STJ tem inúmeros casos com percentuais diferentes, e recentemente reiterou que alterações familiares, inclusive nascimento de outros filhos, não provocam automaticamente redução: é necessário demonstrar concretamente mudança na capacidade financeira.

Portanto:

não existe SYS1.PARMLIB(PENSAO30).

Mas experimente explicar isso depois da segunda Original.

Boa sorte.


🍺 1. O workload que ninguém colocou no capacity planning

Nosso protagonista já tinha filhos dentro do casamento.

Essas crianças obviamente consumiam recursos.

Comida.

Escola.

Roupa.

Médico.

Transporte.

Casa.

Conta de luz.

Tênis que inexplicavelmente deixa de servir três semanas depois de comprado.

Material escolar cujo preço sugere que o caderno foi produzido artesanalmente por monges suíços.

Era um workload perfeitamente real.

Só havia uma diferença.

Esses custos estavam dentro da vida doméstica.

Não chegavam todo mês acompanhados de uma ordem judicial dizendo:

EXEC PGM=PENSAO

Então aparece outro filho, de outro relacionamento, e aquela obrigação passa a ter representação jurídica explícita.

Percentual.

Data.

Processo.

Valor.

Prazo.

Comprovante.

Subitamente nosso amigo descobriu uma das grandes verdades dos sistemas complexos:

Aquilo que existe e aquilo que o sistema consegue enxergar não são necessariamente a mesma coisa.

Os filhos do casamento já consumiam CPU.

Mas boa parte dessa CPU estava escondida dentro do enorme address space chamado:

FAMÍLIA.

O novo workload chegou etiquetado.

Mensurado.

Monitorado.

Com SLA.

E execução judicial disponível caso o SLA não fosse cumprido.

O WLM doméstico começou a chiar.


🔴 2. Entra o Red Team

É aqui que nossos chimpanzés sóbrios entram na sala.

🐒 O chimpanzé jurídico abre o Código Civil.

🐒 O chimpanzé financeiro abre uma planilha.

🐒 O chimpanzé COBOL pergunta por que ninguém documentou aquilo antes.

🐒 O chimpanzé do bar tenta abrir outra Original e é imediatamente removido do War Room.

O Red Team recebe uma única missão:

encontre todas as maneiras pelas quais esse ambiente pode cair.

Primeira pergunta:

— O novo pagamento cabe no orçamento?

Talvez.

Segunda:

— E os filhos que já existiam?

Continuam existindo.

Terceira:

— O sistema está enxergando corretamente todas as obrigações?

Aí começa a ficar interessante.

A Constituição brasileira não admite filhos de primeira e segunda classe. Filhos havidos ou não dentro do casamento possuem os mesmos direitos e qualificações.

Portanto, juridicamente, não existe:

FILHO_PROD

e

FILHO_DEV

Todos entraram em produção.

Todos têm SLA.

E ninguém pode simplesmente executar:

CANCEL CHILD

porque a conta ficou inconveniente.

O problema então não era eliminar uma obrigação.

Era fazer o sistema enxergar todas as obrigações adequadamente.


🔵 3. Blue Team chamado às pressas

O Blue Team entrou.

E, como frequentemente ocorre quando o Red Team encontra algo realmente sério, ninguém estava sorrindo.

A solução não seria:

— Não pago.

Isso é equivalente a resolver falta de espaço em DASD desligando o catálogo.

Funciona maravilhosamente até o telefone tocar.

Também não seria:

— Tenho outros filhos, então automaticamente pago menos.

Não funciona assim.

O STJ já deixou claro que constituir outra família ou ter outros filhos não basta, sozinho, para reduzir alimentos anteriormente fixados. É necessária demonstração concreta de alteração financeira.

Além disso, valores diferentes para filhos de relacionamentos diferentes podem existir quando as circunstâncias forem diferentes — por exemplo, necessidades distintas ou capacidades econômicas diferentes dos responsáveis. Igualdade entre filhos não significa obrigatoriamente copiar o mesmo número em todas as linhas da planilha.

Portanto o Blue Team precisava fazer aquilo que todo bom Blue Team faz:

telemetria.

Quanto entra?

Quanto sai?

Quantos dependentes existem?

Quanto custa cada núcleo?

Quais obrigações já estão formalizadas?

Quais despesas estão escondidas dentro da operação cotidiana?

Não era glamour.

Era SMF familiar.


⚖️ 4. Quando o divórcio virou observabilidade

E então chegamos à parte que, contada rapidamente num boteco, parece uma piada jurídica.

Nosso protagonista se divorciou.

Calma.

Não estamos dizendo:

“Divórcio reduz pensão.”

Não reduz automaticamente.

Também não estamos oferecendo:

“Faça um divórcio fictício e economize.”

Isso seria outro tipo de história, provavelmente terminando numa sala com iluminação fluorescente ruim.

O que aconteceu naquele caso concreto, segundo a história que chegou à nossa mesa, foi mais interessante.

Com o divórcio, obrigações que anteriormente estavam diluídas dentro da vida matrimonial passaram a ficar muito mais formalmente identificadas.

Os demais filhos continuavam sendo filhos.

Continuavam precisando de recursos.

Mas agora a arquitetura financeira familiar aparecia de maneira diferente perante o sistema.

Aquilo que antes era:

DESPESAS_GERAIS_DA_CASA

passou a poder ser apresentado de maneira muito mais explícita como:

OBRIGAÇÕES_COM_FILHO_A

OBRIGAÇÕES_COM_FILHO_B

OBRIGAÇÕES_COM_FILHO_C

Eis o momento em que nosso programador imaginário bate na mesa:

— AHÁ!

Não foi criado dinheiro novo.

Não desapareceram necessidades.

Mudou a observabilidade.

A capacidade do alimentante passou a ser analisada diante de um conjunto mais claramente demonstrável de obrigações.

O Código Civil inclusive permite revisão de alimentos quando muda a situação financeira de quem paga ou de quem recebe.

Era quase um caso de performance.

Você olha para o sistema e acredita que determinado address space está consumindo 30%.

Depois ativa a instrumentação correta.

Descobre que existem vários workloads concorrendo pelos mesmos recursos.

O problema não era necessariamente excesso de CPU.

Era capacity planning ruim.


🧮 5. WLM Family Edition

Imagine agora o WLM olhando para aquilo.

Temos recursos finitos.

Temos workloads legítimos.

Temos diferentes necessidades.

Temos prioridades constitucionais.

E temos alguém na mesa gritando:

— MAS É 30%!

O WLM responde:

“Cidadão, saia da sala.”

Não existe matemática mágica capaz de transformar Direito de Família numa divisão de pizza.

Se alguém ganha R$ 10.000, não significa automaticamente:

R$ 3.000 para criança A.

Depois outra aparece:

mais R$ 3.000.

Depois outra:

mais R$ 3.000.

Depois:

— O senhor ainda precisa comer?

Porque necessidades e possibilidades precisam ser examinadas concretamente.

Da mesma maneira, ninguém pode simplesmente dizer:

— Tenho quatro filhos, então cada um recebe exatamente 25% do orçamento infantil.

Um deles pode ter tratamento médico.

Outro pode estudar em circunstâncias diferentes.

Outro pode morar em cidade mais cara.

As condições econômicas dos respectivos pais e mães também importam.

O STJ já aceitou expressamente valores diferentes para filhos de relacionamentos distintos justamente quando as condições concretas justificavam.

O WLM não distribui tudo com ROUND ROBIN.

Ainda bem.


🔴 6. O Red Team não estava satisfeito

Depois de muito trabalho, a arquitetura aparentemente estabilizou.

Orçamento reorganizado.

Obrigações visíveis.

Advogados fazendo aquilo que advogados fazem.

Documentos.

Peticionamentos.

Planilhas.

Audiências.

Prazos.

Nosso protagonista respirou.

Blue Team abriu o dashboard.

Tudo verde.

CPU normal.

Paging controlado.

Sem ABENDs.

O gerente declarou:

INCIDENT RESOLVED.

O Red Team levantou a mão.

Silêncio.

Sempre desconfie quando o Red Team levanta a mão depois de todo mundo dizer que acabou.

— Temos uma vulnerabilidade residual.

Blue Team:

— Qual?

Red Team:

— O sistema ainda aceita novos workloads.

Ninguém disse nada.

O arquiteto conferiu o diagrama.

Era verdade.

Todo aquele esforço havia resolvido o incidente atual.

Mas a classe de incidente permanecia tecnicamente possível.

Novo relacionamento.

Nova gravidez.

Novo filho.

Nova obrigação.

Novo capacity planning.

Novo advogado.

Nova Original.

O Red Team escreveu no quadro:

ROOT CAUSE NOT ELIMINATED

Agora nosso amigo precisava tomar uma decisão.

Plano B?

Plano C?

Plano D?

Até Z?

Ou eliminar a superfície de ataque?


🏥 7. O Blue Team chamou o urologista

É aqui que a história deixa de ser Direito de Família e entra definitivamente para a história da engenharia.

Nosso protagonista analisou o post-mortem.

Leu o RCA.

Verificou o impacto.

Avaliou recorrência.

E decidiu:

vasectomia.

Pausa dramática.

Essa palavra precisa ficar sozinha.

Porque qualquer escritor que enterre uma punchline dessas dentro de um parágrafo merece perder acesso ao editor.

VASECTOMIA.

😂

O homem não aumentou o orçamento jurídico.

Não contratou advogado em regime de plantão.

Não criou um novo fundo de contingência.

Não implementou mais uma camada de observabilidade.

Ele simplesmente decidiu:

“Novos deployments desta categoria não serão mais necessários.”


🛠️ 8. Change Request URO-001

Naturalmente, nenhuma alteração séria entra em produção sem CAB.

Portanto imaginemos a documentação.

CHANGE ID: URO-001
Descrição: alteração da infraestrutura reprodutiva.
Categoria: Preventive Maintenance.
Motivo: redução permanente da superfície de risco.
Impacto esperado: bloqueio de novos provisionamentos biológicos.
Downtime: limitado.
Rollback: não tratar como trivial.
Owner: proprietário da infraestrutura.
Implementador: urologista devidamente habilitado.
Validação: espermograma conforme orientação médica.
Status: CHANGE APPROVED.

Aqui cabe um parêntese sério dentro da palhaçada.

Vasectomia não produz esterilidade imediatamente. Após o procedimento ainda pode haver espermatozoides residuais, razão pela qual deve ser seguido o acompanhamento médico e realizada a confirmação apropriada antes de abandonar outros métodos contraceptivos.

Sim.

Até o nosso CAB de boteco tem ambiente de homologação.


🐒 9. Os chimpanzés fazem o post-mortem

Chimpanzé jurídico:

— Obrigações existentes continuam existindo.

Correto.

Chimpanzé financeiro:

— A mudança não reduz retroativamente nenhuma obrigação.

Correto.

Chimpanzé de segurança:

— Mas reduz determinada classe de risco futuro.

Muito bem.

Chimpanzé COBOL:

— Podemos fechar o ticket?

Ainda não.

Chimpanzé do bar:

— AGORA posso abrir a Original?

Pode.

🍺 PSHHHT.

Começa o post-mortem.

O objetivo do post-mortem não é descobrir culpados.

Essa é uma diferença importante.

Filhos não são incidentes.

Crianças não são despesas indesejadas numa planilha.

E mulheres ou homens não precisam ser transformados em atacantes para que alguém pratique gestão de risco.

O incidente, aqui, é a ausência de planejamento diante das consequências possíveis das próprias decisões.

Essa diferença salva a história de virar chorume de rede social.

Red Team não significa:

“Todas as mulheres tentarão alguma coisa.”

Significa:

“Existe algum cenário possível capaz de causar um impacto que preciso compreender?”

Blue Team não significa:

“Como escapar das responsabilidades?”

Significa:

“Como cumprir responsabilidades sem destruir a estabilidade do restante do ambiente?”

Chaos Engineering não significa desejar o desastre.

Significa perguntar:

“Se acontecer, o sistema continua funcionando?”


🧠 10. O verdadeiro Chaos Engineering

É aqui que nossa história volta àquelas páginas imaginárias guardadas na gaveta.

O sujeito verdadeiramente paranoico pergunta:

— Qual é a probabilidade?

O Chaos Engineer responde:

— Não estou perguntando isso ainda.

Primeiro:

“É possível?”

Depois:

“Qual seria o impacto?”

E então:

“Tenho como absorver?”

Existem acontecimentos raríssimos que não merecem nenhum preparo porque o impacto seria pequeno.

Existem outros raríssimos cujo impacto seria tão gigantesco que algum plano B é absolutamente razoável.

Você não precisa acreditar que o datacenter pegará fogo amanhã para manter extintores.

Você não precisa acreditar que todos os discos falharão para fazer backup.

Você não precisa acreditar que seu relacionamento acabará para manter documentos patrimoniais organizados.

Você não precisa acreditar que terá outro filho para pensar seriamente sobre contracepção.

Planejamento não é previsão.

É humildade diante da possibilidade de que o universo tenha senso de humor.


🔴🔵 11. Red Team versus Blue Team

Vamos colocar os dois lados frente a frente.

RED TEAM: E se surgir uma obrigação financeira inesperada?

BLUE TEAM: Reserva e capacidade financeira.

RED TEAM: E se existirem outras obrigações que o sistema não esteja enxergando adequadamente?

BLUE TEAM: Documentação.

RED TEAM: E se a situação mudar?

BLUE TEAM: Revisão pelos meios legais adequados.

RED TEAM: E se o primeiro advogado estiver errado?

BLUE TEAM: Segunda opinião.

RED TEAM: E se outro filho nascer?

BLUE TEAM: Contracepção.

RED TEAM: E se a contracepção falhar?

Blue Team olha lentamente para o urologista.

Red Team fecha o notebook.

— Sem mais perguntas.

😂


☕ 12. A grande lição que ninguém pediu

Existe uma tendência moderna de chamar qualquer preparação para cenário desagradável de paranoia.

Talvez seja.

Mas existe uma diferença entre paranoia improdutiva e arquitetura resiliente.

A primeira faz você viver esperando o ataque.

A segunda permite viver normalmente porque o ataque não precisa mais ocupar sua cabeça todos os dias.

Esse talvez seja o detalhe mais bonito do bom planejamento.

O plano fica na gaveta.

Você não acorda toda manhã lendo o Disaster Recovery Manual.

Você simplesmente sabe que ele existe.

Relacionamentos continuam sendo relacionamentos.

Filhos continuam sendo filhos.

Amor continua sendo amor.

Mas ninguém precisa entregar acesso SPECIAL ao RACF apenas para provar confiança.

O mundo adulto tem contratos, seguros, backups, testamentos, reservas, redundâncias, procedimentos médicos e advogados justamente porque confiar na vida não significa presumir que ela sempre obedecerá ao roteiro.


🍺 Epílogo — Garçom, outra Original

Voltamos ao boteco.

A história terminou.

Na mesa havia copos vazios, guardanapos rabiscados e provavelmente um diagrama de arquitetura que jamais deveria ser apresentado numa conferência da IBM.

Alguém perguntou:

— Então depois do divórcio, advogado, pensão, revisão e toda aquela confusão... o que ele fez?

Nosso narrador bebeu um gole.

Olhou para a mesa.

E respondeu:

— Vasectomia.

Silêncio.

Um segundo.

Dois.

Alguém começou a rir.

Outro quase cuspiu a cerveja.

Um terceiro bateu na mesa.

E eu percebi que aquele homem havia aplicado à própria vida uma das lições mais antigas da engenharia:

Você pode passar a existência inteira criando planos B, C, D, E até Z.

Ou, em determinados casos, pode eliminar definitivamente uma classe inteira de incidente.

O Red Team encerrou o teste.

O Blue Team atualizou o runbook.

O WLM estabilizou os workloads existentes.

O CAB fechou a mudança.

O urologista recebeu seus honorários.

E ninguém mexeu nos direitos de nenhuma criança.

Olhei para o garçom.

— Amigo...

Ele já sabia.

Pegou outra garrafa.

— Original?

— Original.

Porque algumas histórias terminam com uma sentença judicial.

Outras terminam com uma lição de vida.

Esta terminou com uma cerveja e um Change Request aprovado.

E, convenhamos:

para uma retrospectiva de produção, não foi um resultado ruim.


Nota jurídica: esta é uma crônica inspirada em situação hipotética/anedótica e não constitui orientação jurídica individual. No Brasil, não há percentual legal obrigatório de 30% para pensão alimentícia; valores dependem das circunstâncias concretas, especialmente necessidades do alimentando e capacidade de quem presta os alimentos. Filhos havidos dentro ou fora do casamento possuem igualdade jurídica. Alterações relevantes na situação financeira podem fundamentar pedido judicial de revisão, mas divórcio ou nascimento de outros filhos não produzem redução automática.

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