☕ 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

segunda-feira, 27 de janeiro de 2020

DotCom : Capítulo I — Antes da Tempestade: O Mundo Antes da Internet Comercial

 

 

Bellacosa Mainframe a tempestade dot.com capitulo I


DotCOM: Capítulo I — Antes da Tempestade: O Mundo Antes da Internet Comercial

Como um Padawan COBOL pode entender por que a maior revolução digital da história começou muito antes do Google

"Toda revolução parece nascer de um único momento. Na realidade, ela é construída silenciosamente durante décadas."

Imagine que você acabou de entrar em um CPD (Centro de Processamento de Dados) em 1994.

Você veste um jaleco, atravessa uma sala climatizada onde o ar-condicionado nunca desliga, escuta o ruído constante das unidades de disco, observa operadores carregando fitas magnéticas e impressoras de linha imprimindo milhares de páginas por hora. Em um canto, um IBM 9672 executa milhares de transações por segundo sem que a maioria da população sequer imagine sua existência.

Para um jovem Padawan COBOL, aquele era o verdadeiro coração da economia.

Enquanto isso, do lado de fora do prédio, poucas pessoas sequer sabiam o que era Internet.

É difícil acreditar nisso hoje.

Vivemos numa época em que praticamente tudo depende da rede mundial. Pagamos contas pelo celular, fazemos compras em segundos, conversamos com pessoas do outro lado do planeta por vídeo, assistimos filmes sob demanda e utilizamos Inteligência Artificial para escrever textos, criar imagens e desenvolver programas.

Mas, até meados da década de 1990, esse mundo simplesmente não existia.

A Internet não era uma praça pública digital.

Era um enorme laboratório.

E compreender essa diferença é essencial para entender por que a bolha das empresas ".com" aconteceu poucos anos depois.


Muito Antes do Google Existia Outro Mundo

Quando ouvimos falar da Internet, normalmente pensamos em empresas como Google, Amazon, Netflix ou YouTube.

Entretanto, nenhuma delas existia da forma que conhecemos atualmente.

Na verdade, durante boa parte dos anos 1980 e início dos anos 1990, a Internet era utilizada quase exclusivamente por:

  • universidades;

  • centros de pesquisa;

  • órgãos governamentais;

  • instituições militares;

  • alguns grandes laboratórios científicos.

Seu objetivo original nunca foi vender produtos.

Ela foi concebida para compartilhar informações e manter comunicações resilientes entre computadores distribuídos.

As conexões eram lentas.

Muito lentas.

Hoje reclamamos quando uma página demora três segundos para abrir.

Naquela época, uma fotografia podia levar vários minutos para aparecer completamente na tela, linha após linha, como se estivesse sendo desenhada lentamente.

Vídeos?

Praticamente impensáveis.

Streaming?

Nem sequer fazia parte do vocabulário.


O Mundo Corporativo Funcionava Muito Bem Sem a Web

Existe uma ideia bastante difundida entre quem começou a estudar tecnologia recentemente:

"Antes da Internet, as empresas eram atrasadas."

Nada poderia estar mais distante da realidade.

Bancos já processavam milhões de transações diariamente.

Companhias aéreas possuíam sofisticados sistemas de reservas.

Seguradoras administravam enormes bases de dados.

Governos realizavam arrecadação de impostos em escala nacional.

Tudo isso funcionava antes da Web.

Quem fazia esse trabalho?

Mainframes.

COBOL.

CICS.

IMS.

Db2.

VSAM.

JCL.

Essas tecnologias sustentavam operações críticas décadas antes de alguém imaginar fazer compras pela Internet.

É justamente por isso que muitos profissionais veteranos sorriem quando alguém afirma que "a transformação digital começou com a Internet".

Na verdade, a Internet foi construída sobre uma infraestrutura empresarial que já existia e que funcionava com extraordinária confiabilidade.

Enquanto a Web ainda aprendia a andar, o mainframe já corria maratonas.


A Era dos Jardins Fechados

Antes da Internet comercial, existiam diversas redes privadas.

Empresas utilizavam:

  • terminais 3270;

  • redes SNA;

  • sistemas proprietários;

  • comunicação X.25;

  • acesso remoto via modem;

  • BBS (Bulletin Board Systems).

Cada ambiente funcionava quase como um pequeno planeta independente.

Era comum uma empresa possuir centenas de terminais conectados exclusivamente ao seu computador central.

Não havia páginas web.

Não existiam hyperlinks.

A navegação era totalmente baseada em menus e comandos.

Curiosamente, muitos desses sistemas ainda permanecem ativos atualmente, executando aplicações críticas em bancos, governos e grandes empresas.

Isso mostra uma característica importante da tecnologia empresarial:

estabilidade costuma valer mais do que novidade.


O Barulho que Mudou Tudo

No início dos anos 1990, milhões de pessoas começaram a ouvir um som que marcaria uma geração inteira.

O modem discado.

Quem viveu aquela época dificilmente esquece a sequência metálica de chiados, estalos e apitos produzidos enquanto o computador tentava estabelecer uma conexão telefônica.

Aquele pequeno concerto eletrônico significava apenas uma coisa:

Você estava entrando na Internet.

A conexão ocupava a linha telefônica.

Se alguém levantasse o telefone da casa...

A conexão caía.

As velocidades pareciam ridículas para os padrões atuais.

14.400 bps.

28.800 bps.

33.600 bps.

56 Kbps.

Hoje uma fotografia comum pode ser maior que toda a quantidade de dados transferida em vários minutos de navegação daquela época.

Mesmo assim...

Parecia mágico.

Pela primeira vez qualquer pessoa poderia acessar informações publicadas em outro país sem precisar comprar livros, revistas ou jornais.

Era uma mudança de paradigma.


O Nascimento da World Wide Web

Um dos maiores equívocos históricos é acreditar que Internet e Web são a mesma coisa.

Não são.

A Internet é a infraestrutura.

A Web é um dos serviços que funciona sobre ela.

Foi o cientista britânico Tim Berners-Lee quem propôs, em 1989, um sistema baseado em hipertexto capaz de conectar documentos espalhados pelo mundo.

Nascia a World Wide Web.

Sua ideia era simples e genial.

Criar documentos interligados por links.

Hoje isso parece absolutamente comum.

Na época era revolucionário.

Antes disso, acessar informações em computadores remotos exigia comandos específicos e conhecimento técnico.

Com a Web bastava clicar.

Essa simplicidade mudaria tudo.


Mosaic: O Navegador que Encantou o Mundo

Em 1993 surgiu um software que poucos conhecem hoje, mas que alterou definitivamente a história da computação.

O navegador Mosaic.

Pela primeira vez era possível visualizar textos e imagens juntos na mesma página de maneira amigável.

Pode parecer um detalhe pequeno.

Não era.

Até então, boa parte da Internet era baseada em interfaces textuais.

O Mosaic transformou a navegação em algo visual.

Milhões perceberam que aquele ambiente tinha potencial para se tornar muito maior do que um simples projeto acadêmico.

Entre seus desenvolvedores estava Marc Andreessen, que pouco tempo depois ajudaria a fundar a Netscape Communications.

Esse seria o próximo grande capítulo da revolução digital.


Netscape: A Primeira Estrela da Nova Economia

Se hoje o Google domina o mercado de navegadores por meio do Chrome, nos anos 1990 quem despertava admiração era o Netscape Navigator.

Ele era rápido.

Bonito.

Fácil de usar.

Empresas passaram a criar seus primeiros sites.

Jornais começaram a publicar notícias online.

Universidades disponibilizaram conteúdos digitais.

Pequenos negócios descobriram que poderiam alcançar clientes muito além de sua cidade.

A Internet deixava de ser um ambiente técnico.

Ela começava a se tornar comercial.

Era o início de uma nova economia.

E quase ninguém imaginava a velocidade com que essa transformação aconteceria.


O Primeiro Contato da Sociedade com o "Ciberespaço"

Na metade da década de 1990, navegar pela Internet era uma experiência quase exploratória.

Não havia mecanismos de busca eficientes.

Era preciso conhecer o endereço exato de um site ou encontrá-lo em diretórios como Yahoo!, que organizavam páginas por categorias.

Surgiam também serviços que marcaram uma geração:

  • ICQ;

  • IRC;

  • Geocities;

  • AltaVista;

  • Lycos;

  • Excite.

Cada novo site parecia descobrir um território desconhecido.

A sensação era semelhante às grandes navegações dos séculos XV e XVI.

Só que, desta vez, o oceano era digital.


Enquanto Isso... Nos Bastidores da Economia

Enquanto revistas estampavam capas anunciando "A Revolução da Internet", outra realidade permanecia praticamente invisível.

As bolsas de valores continuavam sendo liquidadas por sistemas robustos.

Cartões de crédito eram autorizados em mainframes.

Folhas de pagamento eram processadas em COBOL.

Compensações bancárias aconteciam diariamente sem falhas perceptíveis.

Esse contraste é fascinante.

O mundo olhava para as vitrines da Internet.

Mas a infraestrutura que sustentava a economia continuava funcionando silenciosamente nos grandes centros de processamento de dados.

Como na engenharia de uma nave da Frota Estelar, todos admiravam a ponte de comando. Poucos percebiam que era a sala de máquinas que mantinha a nave em velocidade de dobra.


A Primeira Grande Ilusão

Foi exatamente nesse cenário que surgiu uma ideia extremamente sedutora.

Se a Internet estava crescendo tão rapidamente...

Então qualquer empresa ligada à Internet inevitavelmente ficaria rica.

Essa conclusão parecia lógica.

Mas escondia um erro clássico.

Confundir o crescimento de uma tecnologia com o sucesso automático de todas as empresas que a utilizam.

É como imaginar que, porque a eletricidade revolucionou o mundo, toda empresa fabricante de lâmpadas se tornaria bilionária.

Ou que, porque a Inteligência Artificial está transformando a computação, toda startup que coloca "AI" em seu nome será um sucesso.

A história mostra que inovação e rentabilidade não caminham necessariamente juntas.

E essa foi justamente a semente da maior bolha tecnológica do século XX.


Lições para o Padawan COBOL

Se existe uma primeira lição que um programador COBOL deve guardar deste capítulo, é que as maiores revoluções tecnológicas raramente começam da forma como imaginamos.

A Internet não nasceu para vender produtos.

A Web não foi criada para gerar bilhões em publicidade.

Os mainframes não foram desenvolvidos para competir com computadores pessoais.

Cada tecnologia surgiu para resolver problemas concretos e, somente depois, encontrou aplicações muito maiores do que seus criadores poderiam prever.

Essa é uma das características mais fascinantes da computação: tecnologias sólidas sobrevivem porque entregam valor real, mesmo quando as modas mudam.

No próximo capítulo veremos como essa combinação de entusiasmo, inovação e expectativas ilimitadas deu origem à febre das empresas ".com", uma corrida onde investidores passaram a acreditar que bastava adicionar um endereço na Internet para transformar qualquer ideia em bilhões de dólares. É aí que a verdadeira aventura — e o verdadeiro caos — começa.


domingo, 26 de janeiro de 2020

CI/CD sem Mistérios : O Guia do Programador COBOL Padawan para Entender por que o Mainframe Faz DevOps Há Décadas (Mesmo Antes de Chamarem Assim)

 

Bellacosa Mainframe e ci/cd sem misterios

☕ Um Café no Bellacosa Mainframe

CI/CD sem Mistérios

O Guia do Programador COBOL Padawan para Entender por que o Mainframe Faz DevOps Há Décadas (Mesmo Antes de Chamarem Assim)

Existe uma frase muito comum quando alguém começa a estudar DevOps:

"CI/CD revolucionou a forma de desenvolver software."

Ela não está errada.

Mas para quem trabalha com IBM Z, CICS, Db2, COBOL, IMS e JCL, existe uma observação divertida:

"Revolucionou para quem nunca trabalhou com mainframe."

E aqui está um dos maiores easter eggs da computação.

Durante décadas, enquanto boa parte do mundo compilava programas diretamente no servidor de produção usando FTP e um editor de texto, o universo mainframe já possuía ambientes separados, aprovação, promoção de código, controle de versões internos, rollback, auditoria e pipelines extremamente rígidos.

Não recebiam o nome de DevOps.

Mas faziam praticamente a mesma coisa.


O que significa CI/CD?

CI significa

Continuous Integration
(Integração Contínua)

CD possui dois significados.

Primeiro:

Continuous Delivery
(Entrega Contínua)

Depois:

Continuous Deployment
(Implantação Contínua)

Por isso muita gente escreve

CI/CD

para representar todo o fluxo.


Bellacosa Mainframe e o ciclo Ci/Cd

A ideia parece moderna...

...mas é muito antiga.

A origem vem da necessidade de resolver um enorme problema dos anos 70, 80 e 90.

Imagine uma empresa com:

  • 300 desenvolvedores

  • milhares de programas

  • centenas de alterações diárias

Cada programador alterava arquivos diferentes.

No final da semana alguém tentava juntar tudo.

Resultado?

Era praticamente inevitável aparecerem conflitos, regressões e erros de integração.

Nascia então a necessidade de integrar continuamente.


O problema que existia

Imagine cinco programadores.

João altera cálculo de juros.

Maria altera cadastro.

Carlos altera emissão.

Pedro altera impostos.

Ana altera relatórios.

Todos trabalham separados durante um mês.

Na hora de juntar tudo...

Começa o caos.

Isso era chamado de:

Integration Hell

Ou

Inferno da Integração.

CI nasceu justamente para evitar isso.


O objetivo do CI

Ao invés de integrar tudo no final...

Integra-se o tempo inteiro.

Cada alteração dispara automaticamente:

  • compilação

  • testes

  • validações

  • análise estática

  • geração de artefatos

Se algo quebra...

Descobre-se em minutos.

Não em semanas.


Delivery

Continuous Delivery responde outra pergunta.

Depois que compilou...

Como levar até produção?

Sem copiar arquivos manualmente.

Sem esquecer datasets.

Sem esquecer um BIND.

Sem esquecer um módulo.

Tudo passa a ser automatizado.


Deployment

Continuous Deployment vai além.

Se tudo passou...

O sistema entra automaticamente em produção.

Sem intervenção humana.

Este modelo é muito comum em empresas digitais.

No mundo bancário, normalmente utiliza-se Continuous Delivery com aprovação humana antes da promoção para produção, por exigências regulatórias e de governança.


Onde surgiu?

As raízes aparecem ainda nas práticas de integração de software dos anos 1980 e foram consolidadas com métodos como Extreme Programming (XP) na década de 1990. Em 2006, Martin Fowler popularizou o conceito de Continuous Integration, e a partir da década de 2010, com a ascensão do DevOps, CI/CD tornou-se um padrão amplamente adotado.

Curiosamente...

O mainframe já fazia muitas dessas práticas décadas antes.


O Easter Egg do IBM Z

Imagine um desenvolvedor COBOL em 1988.

Ele faz:

Editar

↓

Compilar

↓

Link

↓

Teste

↓

Homologação

↓

Produção

Agora veja um pipeline GitHub.

Commit

↓

Compile

↓

Test

↓

Package

↓

Deploy QA

↓

Deploy PROD

São praticamente a mesma filosofia.

A diferença está na automação e nas ferramentas.


O ciclo clássico do Mainframe

Durante muitos anos, um fluxo típico era:

Desenvolvimento

↓

Teste Unitário

↓

Integração

↓

Homologação

↓

Produção

Cada ambiente possuía:

  • bibliotecas próprias

  • datasets próprios

  • Db2 próprio

  • CICS próprio

  • IMS próprio

Nada era compartilhado.


O programador Padawan pensa...

"Mas isso já não é CI/CD?"

Na essência...

Sim.

A maior diferença é:

antes boa parte das promoções dependia de pessoas.

Hoje dependem de pipelines.


Como funcionava antigamente?

Um fluxo clássico podia ser:

Programador

↓

Compila

↓

Entrega ao líder

↓

Líder aprova

↓

Equipe de mudança

↓

Equipe de produção

↓

Operadores

↓

Implantação

Cada etapa envolvia documentos.

Telefonemas.

Assinaturas.

Mudanças em papel.

Mudanças aprovadas em CAB (Change Advisory Board).

Tudo extremamente controlado.


As equipes antigamente

Era comum existir:

Programadores

Analistas

QA

DBA

Operadores

Produção

Sysprog

Storage

Segurança

Change Management

Cada equipe era responsável apenas por sua parte.

Esse modelo ficou conhecido como "silos".


Hoje

O objetivo do DevOps não é eliminar especialistas.

É fazê-los trabalhar juntos.

Em vez de jogar o problema para o próximo grupo.

Todos compartilham responsabilidade.


O pipeline moderno

Hoje um commit pode executar automaticamente:

Git

↓

Build

↓

Compile COBOL

↓

IBM COBOL Check

↓

Testes ZUnit

↓

Code Review

↓

Quality Gate

↓

DBB/zBuilder

↓

Empacotamento

↓

Deploy DEV

↓

Deploy QA

↓

Deploy UAT

↓

Deploy Produção

Tudo registrado.

Tudo auditável.

Tudo reproduzível.


O grande objetivo

Reduzir risco.

Não aumentar velocidade.

Velocidade é consequência.

O verdadeiro objetivo é:

Confiabilidade.


Comparando com Waterfall

Waterfall

Grande planejamento.

Grande desenvolvimento.

Grande teste.

Grande implantação.

Tudo ocorre em blocos.

Mudanças são caras.

Feedback demora.


Agile

Entrega pequena.

Feedback rápido.

Correções rápidas.

Novos ciclos.

O cliente participa continuamente.


Onde entra o CI/CD?

O Agile responde:

Como organizar o trabalho?

CI/CD responde:

Como entregar software com segurança e repetibilidade?

São complementares.


Waterfall sem CI/CD

Planejar

↓

Desenvolver

↓

Meses depois integrar

↓

Torcer

Agile sem CI/CD

Sprint

↓

Entrega

↓

Implantação manual

↓

Muito retrabalho

Agile + CI/CD

Sprint

↓

Commit

↓

Pipeline

↓

Testes

↓

Deploy

↓

Feedback

É essa combinação que caracteriza a maior parte das organizações modernas.


O Mainframe já fazia isso?

Muito mais do que muita gente imagina.

Ferramentas como:

  • Endevor

  • Changeman ZMF

  • ISPW

  • Librarian

  • Panvalet

já implementavam conceitos de:

  • versionamento

  • promoção

  • rollback

  • aprovação

  • auditoria

  • segregação de ambientes

Décadas antes do GitHub existir.


O pipeline "invisível"

Um pipeline moderno apenas automatiza etapas que o mainframe tradicional já conhecia:

Editar COBOL

↓

Compile

↓

DBRM

↓

BIND PACKAGE

↓

BIND PLAN

↓

Link Edit

↓

Load Library

↓

Deploy

↓

Smoke Test

↓

Produção

Hoje isso pode ser disparado por um único commit.


Os requisitos para um verdadeiro CI/CD

Não basta instalar Jenkins.

É necessário:

  • Controle de versão (Git ou equivalente).

  • Build automatizado (DBB/zBuilder, Maven, Gradle etc.).

  • Testes automatizados (ZUnit, JUnit...).

  • Análise estática (IBM COBOL Check, SonarQube...).

  • Pipeline (Jenkins, GitHub Actions, GitLab CI...).

  • Promoção automatizada entre ambientes.

  • Rollback.

  • Auditoria.

  • Observabilidade.

  • Aprovação quando exigida por compliance.

Sem esses elementos, há automação parcial, mas não um pipeline maduro.


É hype?

Hoje, não.

Há alguns anos, "DevOps" virou uma buzzword usada para vender ferramentas e consultorias. Porém, CI/CD deixou de ser moda para se tornar uma prática consolidada de engenharia de software.

O hype passou.

A necessidade permaneceu.


É uma buzzword?

Depende do contexto.

Quando alguém diz:

"Nossa empresa faz DevOps."

Mas:

  • não existe automação;

  • não há testes automáticos;

  • tudo é manual;

  • produção depende de copiar arquivos;

  • rollback não existe;

Então virou apenas uma buzzword.

Quando existe pipeline, testes, rastreabilidade, observabilidade e governança, CI/CD deixa de ser discurso e vira prática.


O maior mito

Muitos acreditam:

"CI/CD serve para entregar software mais rápido."

Na verdade...

Serve para entregar software com menos risco.

A velocidade aparece porque há menos retrabalho, menos erros humanos e mais confiança no processo.


Curiosidades

  • NASA, bancos, companhias aéreas e bolsas de valores utilizam pipelines altamente controlados, muitas vezes exigindo aprovações humanas mesmo com automação.

  • O IBM Z integra-se hoje com Git, Jenkins, GitHub Actions, Azure DevOps, Ansible, Zowe, DBB/zBuilder, UrbanCode Deploy e outras ferramentas modernas.

  • Em ambientes regulados, é comum usar Continuous Delivery, mas não Continuous Deployment, porque uma etapa de aprovação humana continua sendo obrigatória.


Easter Eggs para o Padawan COBOL

🥚 Endevor fazia "pipeline" antes do pipeline existir.

🥚 Promotion Levels do ISPW lembram muito os estágios (stages) de um pipeline moderno.

🥚 O DBRM pode ser visto como um "artefato de build", equivalente ao que linguagens modernas geram antes da implantação.

🥚 O BIND PACKAGE é, em muitos aspectos, semelhante a uma etapa especializada de empacotamento e configuração dentro de um pipeline.

🥚 O JCL sempre foi uma forma declarativa de orquestração de tarefas em lote, décadas antes de arquivos YAML de pipelines se tornarem populares.


A Grande Lição para um Padawan COBOL

Quando você ouvir alguém dizer:

"DevOps e CI/CD chegaram para substituir o mainframe."

Sorria.

Depois explique que o IBM Z já separava ambientes, promovia código entre níveis, exigia aprovações, mantinha auditoria, fazia rollback e garantia rastreabilidade muito antes dessas práticas receberem os nomes que conhecemos hoje.

O que mudou não foi a filosofia.

Mudaram as ferramentas, o grau de automação e a integração entre equipes.

No fim das contas, CI/CD não é uma tecnologia nem uma moda passageira. É a evolução natural de uma ideia simples: tornar a entrega de software repetível, segura, auditável e previsível. E, para quem vive no universo COBOL e IBM Z, essa história soa surpreendentemente familiar. Afinal, o mainframe sempre ensinou que colocar código em produção é um processo de engenharia — nunca um ato de improviso.


sábado, 25 de janeiro de 2020

☕🔥 ABENDs Clássicos do Mainframe IBM — O Guia de Sobrevivência

 

Bellacosa Mainframe revisando a lista classica de abends no mundo ibm mainframe



☕🔥 ABENDs Clássicos do Mainframe IBM — O Guia de Sobrevivência

🔥 S013 — Dataset/Dataset Member Problem

O que significa

Erro de OPEN em dataset.

Causas comuns

  • BLKSIZE incorreto

  • RECFM incompatível

  • Membro inexistente em PDS

  • DCB incompatível

Clássico cenário COBOL

//ARQENT DD DSN=MEU.PDS(MEMBROX),DISP=SHR

Mas o membro não existe.


🔥 S0C1 — Operation Exception

“O programa tentou executar lixo como instrução”

Causas comuns

  • Programa compilado errado

  • Overlay de memória

  • Chamada para área inválida

  • Executar dados como código

Muito comum em:

  • COBOL

  • Assembler

  • LINK incorreto


🔥 S0C4 — Protection Exception

O terror absoluto do programador COBOL

Significa

Acesso inválido à memória.

Principais causas

  • Subscript fora do limite

  • Ponteiro inválido

  • LINKAGE SECTION errada

  • Buffer não inicializado

Exemplo clássico

MOVE TAB-ITEM(9999) TO WS-CAMPO

Quando a tabela só vai até 100.


🔥 S0C7 — Data Exception

O ABEND mais famoso do COBOL

Significa

Campo numérico contém dado inválido.

Exemplo

MOVE 'ABC' TO WS-VALOR-NUM
ADD 1 TO WS-VALOR-NUM

💥 S0C7.


🔥 S213 — Dataset Não Encontrado

“O dataset simplesmente não existe”

Causas

  • DSNAME errado

  • Dataset não catalogado

  • VOL=SER incorreto

Mensagem clássica

IEC143I 213-04

🔥 S222 — Job Cancelado

Operador matou o job

Geralmente ocorre por:

  • Loop infinito

  • Job travado

  • Consumo excessivo

  • Cancel manual


🔥 S322 — TIMEOUT

“Seu job passou do tempo”

Clássico:

TIME=1

Mas o programa entra em loop.


🔥 S806 — Module Not Found

O loader não encontrou o programa

Causas

  • STEPLIB errada

  • LOADLIB ausente

  • Nome do módulo incorreto

Mensagem típica

CSV003I REQUESTED MODULE NOT FOUND

🔥 S913 — RACF Security Violation

Segurança negou acesso

Causas

  • Dataset protegido

  • Falta de permissão RACF

  • Usuário sem READ/UPDATE

Muito comum em:

  • Produção

  • Db2

  • CICS

  • GDGs corporativos


🔥 B37 / D37 / E37 — Falta de Espaço

B37

Sem espaço secundário suficiente.

D37

Sem secondary allocation.

E37

Acabaram as extents ou a fita.

Clássico JCL

SPACE=(CYL,(1,0))

💥 Dataset cresce → ABEND D37.


☕ Curiosidade Histórica

A palavra:

ABEND

vem de:

ABnormal END

Ou seja:

“Término Anormal”

Esse termo nasceu nos primeiros sistemas IBM OS/360 e virou parte da cultura mainframe mundial.


🔥 Os 5 ABENDs Mais Temidos da História do COBOL

ABENDApelido
S0C7Data Exception
S0C4Protection Exception
S806Module Not Found
S322Timeout
S913RACF Security

☕ Dica Profissional Mainframe

Quando houver ABEND:

SEMPRE analisar:

  1. JESMSGLG

  2. JESJCL

  3. SYSMSG

  4. SYSOUT

  5. Dump

  6. CEEDUMP (LE)

  7. Abend-AID / Fault Analyzer


🔥 Regra de Ouro do Mainframe

O ABEND raramente é o problema.

Ele é apenas:

“O sintoma do problema.”

O verdadeiro erro normalmente aconteceu:

  • antes,

  • em outro módulo,

  • ou em dados corrompidos anteriormente.


sexta-feira, 24 de janeiro de 2020

Viagem rumo a São Tomé das Letras - MG

Dirigindo pelo sul de Minas Gerais,


Seguindo os passos de antigos bandeirantes, estamos circulando pela Rodovia Fernão Dias, rumo a mistica cidade dos gnomos, duendes e ovnis.

Neste primeiro vídeo de nossa jornada, apresento algumas estradas que circulamos passamos por inúmeras localidades, estamos na pequena estrada de 3 Corações, posteriormente iremos subir rumo a São Tomé das Letras.

Passando pelo Portal Magico adentramos na cidade e chegamos ao Camping do CID, onde iremos passar a virada de ano e aproveitar para explorar um pouquinho de São Tome.

#MinasGerais #SaoTomeDasLetras #Estrada #TresCoracoes #Viagem #Rodovia #camping #Cid #Aventura #direcao #passeio #viagem #serramantiqueira


#SaoTomeDasLetras #Piramide #tocaFurada #mirante #cruzeiro #IGrejaAssombrada #Castelo #Trilha #Ecoturismo #ViagemAstral #Ufo #et #duende #fada #weed #hippie #bichogrilo #cachoeira #cascata #corredeira #Caverna #pedradabruxa #panorama #ChicoTaquara #Gruta #saoTome #igrejarosario #sobradinho #eubioese #shangrila #poçoazul #poçodasesmeraldas #paraiso #veudanoiva #valedasborboletas #lua #gruta



quinta-feira, 23 de janeiro de 2020

📖 Honzuki no Gekokujou 2ª Temporada : Quando Myne Sai do Ambiente de Desenvolvimento e Entra em Produção — O Deploy Mais Delicado da História dos Isekais

 

Bellacosa Mainframe e a segunda temporada de honzuki no gekokujou

☕ Um Café no Bellacosa Mainframe

📖 Honzuki no Gekokujou 2ª Temporada (本好きの下剋上 第二部): Quando Myne Sai do Ambiente de Desenvolvimento e Entra em Produção — O Deploy Mais Delicado da História dos Isekais

"Criar papel foi apenas o protótipo. Agora Myne precisa integrar seu projeto ao sistema mais complexo daquele mundo: o Templo, a nobreza e uma burocracia que faz o RACF parecer amigável."


Introdução

A primeira temporada de Honzuki no Gekokujou mostrou como uma garota apaixonada por livros conseguiu reinventar tecnologias esquecidas em um mundo medieval. Era uma história sobre invenção, empreendedorismo e sobrevivência.

A segunda temporada muda completamente o foco.

Agora, o desafio não é mais fabricar papel ou tinta. O verdadeiro obstáculo é inserir conhecimento em uma estrutura de poder consolidada há séculos.

Sob a ótica do Bellacosa Mainframe, é como desenvolver uma solução inovadora em um ambiente de testes e, depois, tentar implantá-la em um gigantesco datacenter bancário cheio de normas, auditorias, segurança e interesses políticos.

É nesse momento que Honzuki no Gekokujou deixa de ser apenas um excelente isekai e se transforma em uma obra sobre governança, gestão de mudanças e transformação organizacional.


Ficha Técnica

Título original

本好きの下剋上 司書になるためには手段を選んでいられません 第二部

(Honzuki no Gekokujou: Shisho ni Naru Tame ni wa Shudan wo Erandeiraremasen – Part 2)

Título internacional

Ascendance of a Bookworm – Season 2


Autor Original

Miya Kazuki


Ilustrações

You Shiina


Estúdio

Ajia-do Animation Works

O estúdio mantém sua principal característica:

Priorizar narrativa.

Não existe espetáculo visual constante.

Existe direção cuidadosa.

Existe desenvolvimento gradual.

Existe respeito pelo material original.

A qualidade está muito mais na escrita do que na quantidade de quadros por segundo.


Direção

Mitsuru Hongo

A direção demonstra enorme maturidade.

Os conflitos deixam de ser físicos.

Agora são:

  • políticos

  • econômicos

  • religiosos

  • sociais

Cada episódio acrescenta uma nova camada ao universo.


Data de lançamento

4 de abril de 2020

Exibição encerrada em:

20 de junho de 2020


Episódios

12 episódios

Cada episódio adapta parte do arco conhecido como Part 2 – Apprentice Shrine Maiden.


Classificação

Fantasia

Isekai

Drama

Slice of Life

Política

Religião

Economia

Construção de Mundo


Faixa indicativa

Aproximadamente 12 anos.

Embora seja um anime tranquilo visualmente, trata temas bastante maduros:

  • exploração infantil

  • corrupção

  • fome

  • abuso de autoridade

  • desigualdade social

  • luta por poder

  • manipulação política


Sinopse

Após conseguir produzir papel e iniciar uma pequena revolução comercial, Myne descobre que sua enorme quantidade de mana ameaça sua própria vida.

A única maneira de sobreviver é ingressar no Templo como aprendiz de sacerdotisa (Blue Shrine Maiden), onde poderá utilizar sua mana de forma controlada.

Mas o Templo está longe de ser um local sagrado e pacífico.

Por trás dos rituais existem interesses políticos, corrupção, disputa por influência e uma rígida divisão entre plebeus e nobres.

Enquanto tenta manter seu sonho de criar livros, Myne precisará aprender a navegar por uma estrutura de poder muito mais perigosa do que qualquer monstro.


Resumo da História

Na primeira temporada, Myne enfrentava limitações tecnológicas.

Na segunda, enfrenta limitações institucionais.

Ela deixa de lutar contra a falta de papel e passa a enfrentar:

  • burocracia

  • preconceito

  • interesses econômicos

  • aristocracia

  • religião

  • poder político

É uma mudança radical de escala.


O Grande Tema da Segunda Temporada

Se a primeira temporada fala sobre inovação tecnológica, a segunda fala sobre governança.

Toda inovação, cedo ou tarde, encontra um sistema estabelecido.

É aí que começam os verdadeiros conflitos.


Bellacosa Mainframe

O Templo é o Datacenter Central

Imagine um enorme ambiente IBM Z.

Tudo passa por ele.

Segurança.

Autorização.

Processamento.

Controle.

Documentação.

Auditoria.

O Templo funciona exatamente assim.

Quem controla o Templo controla informação, recursos e influência.


Ferdinand: o Sysprog Supremo

Nesta temporada Ferdinand ganha enorme profundidade.

Ele lembra um Sysprog veterano.

Conhece todas as regras.

Conhece todas as exceções.

Conhece todos os riscos.

Seu papel é impedir que Myne destrua o ambiente sem perceber.

Ao mesmo tempo, reconhece que apenas ela pode modernizar aquele sistema.


Myne torna-se uma Arquiteta Corporativa

Ela deixa de ser apenas inventora.

Agora precisa:

negociar

liderar

ensinar

administrar

planejar

controlar riscos

formar equipes

gerenciar recursos

Ela amadurece enormemente.


Os novos personagens

Delia

Inicialmente parece antagonista.

Na verdade representa pessoas que cresceram dentro de sistemas injustos.

Ela age conforme foi ensinada.

Não por maldade.


Fran

Extremamente disciplinado.

Competente.

É praticamente um operador experiente de produção.

Sempre segue procedimentos.

Sempre executa corretamente.


Gil

Começa rebelde.

Pouco a pouco descobre propósito.

Talvez represente o maior crescimento pessoal da temporada.


Rosina

Sua sensibilidade artística lembra que cultura também faz parte da construção de uma sociedade.


Ferdinand e Myne

A relação entre ambos evolui bastante.

Não existe romance.

Existe confiança.

Mentoria.

Aprendizado.

Respeito intelectual.

É uma parceria semelhante à de um arquiteto experiente treinando uma futura líder técnica.


As aventuras

Embora pareça um anime "parado", praticamente todo episódio apresenta desafios.

Criar biblioteca.

Organizar funcionários.

Ensinar leitura.

Negociar recursos.

Produzir novos materiais.

Lidar com nobres.

Resolver conflitos internos.

Descobrir conspirações.

Sobreviver politicamente.

Cada episódio adiciona uma peça ao quebra-cabeça.


O verdadeiro antagonista

Não existe um vilão clássico.

O inimigo é:

o sistema.

Estruturas antigas.

Preconceitos.

Interesses.

Corrupção.

Isso torna a obra extremamente realista.


As mensagens ocultas

Conhecimento ameaça quem controla informação

Toda vez que Myne democratiza conhecimento, alguém perde poder.

A série demonstra que informação nunca é neutra.


Mudança exige aliados

Nenhuma revolução acontece sozinha.

Myne depende de:

Lutz.

Benno.

Fran.

Ferdinand.

Gil.

Rosina.

Cada pessoa representa uma competência diferente.


Liderança é servir

Ao contrário de muitos protagonistas.

Myne não manda.

Ela inspira.

As pessoas começam a trabalhar melhor porque acreditam em seu propósito.


Educação modifica gerações

Os livros que Myne cria talvez não mudem sua própria vida.

Mudam a vida das próximas gerações.


Instituições podem proteger ou aprisionar

O Templo é simultaneamente:

abrigo

prisão

escola

centro político

centro econômico

centro religioso

Essa dualidade é brilhantemente construída.


O que diferencia esta temporada?

Enquanto quase todos os isekais aceleram para batalhas cada vez maiores, Honzuki desacelera.

Troca ação por construção de personagens.

Troca magia por administração.

Troca guerras por diplomacia.

Troca espadas por livros.

E surpreendentemente funciona.


Qualidade da adaptação

A adaptação continua bastante fiel às light novels, mas a limitação de episódios exigiu condensar muitos acontecimentos.

Diversos detalhes sobre o funcionamento interno do Templo, as motivações dos sacerdotes, a política da nobreza e o desenvolvimento psicológico de personagens secundários aparecem de forma mais rica nos livros. Ainda assim, o anime preserva os principais eventos e o tom da obra.


Houve censura?

Não houve registros de censura significativa na segunda temporada. A adaptação manteve temas como desigualdade social, exploração de crianças, manipulação política e corrupção religiosa sem grandes alterações. O que ocorreu foi uma simplificação de alguns conflitos e diálogos para adequação ao tempo disponível em cada episódio, evitando excesso de exposição e mantendo um ritmo acessível para a televisão.


Impacto Cultural

A segunda temporada consolidou Ascendance of a Bookworm como um dos isekais mais diferentes da década. Muitos espectadores que inicialmente buscavam fantasia tradicional descobriram uma narrativa voltada para administração, economia e construção de instituições.

A obra passou a ser frequentemente utilizada como exemplo de worldbuilding consistente, mostrando que um universo bem planejado pode ser mais envolvente do que batalhas espetaculares. Também reforçou o interesse internacional pelas light novels de Miya Kazuki, impulsionando traduções e ampliando a comunidade de fãs.


Bellacosa Mainframe Score

ItemNota
Construção de Mundo⭐⭐⭐⭐⭐ (10/10)
Desenvolvimento dos Personagens⭐⭐⭐⭐⭐ (10/10)
Política e Intriga⭐⭐⭐⭐⭐ (9,8/10)
Emoção⭐⭐⭐⭐⭐ (9,7/10)
Trilha Sonora⭐⭐⭐⭐☆ (9,0/10)
Animação⭐⭐⭐⭐☆ (8,8/10)
Fidelidade às Novels⭐⭐⭐⭐⭐ (9,5/10)
Originalidade⭐⭐⭐⭐⭐ (10/10)
Valor Educacional⭐⭐⭐⭐⭐ (10/10)

Conclusão

A segunda temporada de Honzuki no Gekokujou demonstra que inovar é apenas a primeira etapa; o verdadeiro desafio é integrar essa inovação a organizações complexas, onde tradição, burocracia e interesses estabelecidos resistem à mudança. Myne deixa de ser apenas uma inventora brilhante para se tornar uma líder capaz de negociar, formar equipes e transformar instituições sem destruir suas bases.

Na linguagem do Bellacosa Mainframe, essa temporada é o equivalente a implantar uma nova arquitetura em um ambiente IBM Z crítico: não basta escrever um excelente programa COBOL. É preciso entender governança, segurança, processos, gestão de mudanças e, acima de tudo, conquistar a confiança das pessoas que mantêm o sistema funcionando.

É essa combinação de inteligência, sensibilidade e realismo institucional que faz da segunda temporada uma das mais ricas do gênero isekai. Ela prova que a maior aventura não é derrotar um rei demônio, mas convencer uma sociedade inteira de que o conhecimento deve deixar de ser um privilégio para se tornar um patrimônio coletivo.

DT NÃO É Data Type! O Dia em que um Programador COBOL Descobriu que os Otakus Estavam Falando de Outra Coisa o Tempo Todo!

 

Bellacosa Mainframe e o significado oculto de DT

☕ Um Café no Bellacosa Mainframe

DT NÃO É Data Type! O Dia em que um Programador COBOL Descobriu que os Otakus Estavam Falando de Outra Coisa o Tempo Todo!

Imagine a cena.

Você, veterano de COBOL, quarenta anos de mainframe nas costas.

Alguém no grupo do WhatsApp escreve:

"Esse anime tem muito DT."

Imediatamente você pensa:

"Ah... deve ser um novo tipo de dado...

DISPLAY TYPE?

DECIMAL TYPE?

DATA TRANSFER?

DOUBLE TEST?

DATABASE TRIGGER?"

Não.

Nada disso.

Você abre o anime.

Cinco minutos depois...

Uma garota tropeça.

A câmera faz um mergulho cinematográfico.

A gravidade tira férias.

E você finalmente entende.


O que significa DT?

No universo dos mangás e animes, DT normalmente significa:

Doutei (童貞)

Que em japonês significa literalmente:

Virgem (homem).

Mas...

Como tudo no Japão...

...não é tão simples.


Não é apenas "virgem"

Nos animes, chamar alguém de DT virou praticamente um meme.

É quase uma classe de personagem.

Algo como:

  • nunca namorou

  • não sabe conversar com garotas

  • entra em pânico ao ouvir "bom dia"

  • morre por combustão espontânea quando uma menina segura sua mão.

É praticamente um ABEND social.


Traduzindo para COBOL

Imagine um programa assim:

01 EXPERIENCIA-AMOROSA.
   05 STATUS PIC X VALUE "N".

Durante vinte temporadas...

Nunca muda.

Continua:

STATUS = N

Nem um UPDATE.

Nem um COMMIT.

Nem um INSERT.

Só SELECT.


O COBOL Padawan DT

É aquele programador que:

  • conhece CICS

  • conhece Db2

  • conhece VSAM

  • conhece IMS

  • conhece RACF

Mas...

Quando uma garota pergunta:

"Você programa?"

Ele responde:

S0C7

O verdadeiro significado nos animes

DT quase sempre representa o protagonista clássico.

Ele é:

✔ gentil

✔ trabalhador

✔ tímido

✔ azarado

✔ absurdamente poderoso

✔ completamente incapaz de perceber que CINCO garotas gostam dele.


O algoritmo emocional dele

IF GAROTA-SORRI
   MOVE "ELA ESTÁ SENDO EDUCADA"
      TO INTERPRETACAO.

IF GAROTA-ABRACA
   MOVE "DEVE ESTAR COM FRIO"
      TO INTERPRETACAO.

IF GAROTA-BEIJA
   MOVE "FOI UM ACIDENTE"
      TO INTERPRETACAO.

Resultado?

END-IF.

Nada acontece.


O poder oculto do DT

Curiosamente...

Quanto mais DT...

Mais poderoso costuma ser o protagonista.

É uma regra não escrita.

Veja alguns exemplos.

O herói derrota:

✔ dragões

✔ demônios

✔ reis

✔ deuses

✔ entidades cósmicas

✔ conceitos abstratos da existência

Mas...

Não consegue dizer:

"Você gostaria de tomar um café?"


O compilador emocional

Imagine o compilador.

COMPILANDO...

LOVE.DAT

Erro:

Linha 45

Unexpected Female Interaction.

Expected:

Sword

Shield

Magic

Dragon

Guild

Adventure

Found:

Girl

Compilation failed.


O famoso Buff da Pureza™

Em muitos mangás antigos existia até a piada:

Quanto mais DT...

Maior o poder mágico.

Era quase uma estatística RPG.

MAGIA = DT x 100

Perdeu o status?

MAGIA = 0

Não faz sentido.

Mas anime nunca prometeu fazer sentido.


O Agente Smith entra no anime

Imagine Matrix.

Neo enfrenta centenas de Agentes Smith.

Tudo tranquilo.

Mas...

A Trinity segura sua mão.

Neo:

ABEND U9999

Reason:

Emotional Overflow.

O Padawan COBOL encontra uma elfa

A elfa diz:

— Você é incrível.

O programador responde:

— Obrigado.

Silêncio.

Ela continua olhando.

Ele abre o ISPF.


O Debug

DISPLAY "ELA GOSTA DE MIM?"

Resultado:

FALSE.

DISPLAY "TEM CERTEZA?"

TRUE.

DISPLAY "ABSOLUTA?"

TRUE.

DISPLAY "VOCÊ É BURRO?"

TRUE.

O Scheduler do Romance

JES2:

JOB LOVE001 SUBMITTED

Cinco anos depois...

JOB STILL WAITING...

Motivo?

CLASS=A

Priority=LOW

User forgot to talk.

O Banco de Dados Amoroso

SELECT *

FROM GAROTAS

WHERE INTERESSE='SIM';

Resultado:

5 linhas encontradas.

Programa:

DISPLAY

"NÃO EXISTEM RESULTADOS."

O Plot Twist

O curioso é que muitos autores usam o DT justamente para representar o crescimento do personagem.

No início ele é inseguro.

Tem medo.

Não acredita em si mesmo.

Não entende as pessoas.

Com o tempo...

Aprende amizade.

Responsabilidade.

Empatia.

Confiança.

Ou seja...

O DT nunca foi realmente sobre romance.

Era apenas um símbolo da falta de maturidade.


O Bellacosa Mainframe explica

No mundo do mainframe existe algo parecido.

Todo Padawan começa assim.

Tem medo de:

  • SDSF

  • JCL

  • CICS

  • Db2

  • VSAM

  • RACF

  • produção

  • IPL

Até que um belo dia...

Depois do centésimo ABEND...

Depois da milésima compilação...

Depois de sobreviver ao primeiro incidente em produção...

Ele percebe:

"Talvez eu saiba alguma coisa."

É exatamente a evolução de muitos protagonistas de anime.


Moral da História

Ser DT em um anime não significa apenas "ser virgem".

Virou um arquétipo cômico que representa a timidez extrema, a inexperiência social e a clássica incapacidade de perceber o óbvio, rendendo incontáveis cenas engraçadas. Muitos protagonistas começam assim justamente para terem espaço para amadurecer ao longo da história.

E lembre-se, Padawan COBOL...

Você pode não entender as indiretas da elfa da guilda...

Pode demorar três temporadas para perceber que a sacerdotisa gosta de você...

Pode até levar um S0C7 emocional ao receber um elogio...

Mas, se conseguir decifrar um JCL de 4 mil linhas, um dump de CICS às três da manhã e uma query Db2 escrita em 1989, talvez exista esperança. Afinal, entre um ABEND e outro, até o protagonista mais distraído acaba aprendendo que alguns bugs não estão no código... estão na interpretação dos sinais da vida. 😄

quarta-feira, 22 de janeiro de 2020

Murphy's Law Rules : Quando um Programador COBOL Descobriu que a Matrix Não Era Derrotada Pelos Grandes Bugs… Mas Pelos Pequenos Erros que Ninguém Testou

 

Bellacosa Mainframe e a lei de murphy rules

☕ Um Café no Bellacosa Mainframe

Murphy's Law Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Não Era Derrotada Pelos Grandes Bugs… Mas Pelos Pequenos Erros que Ninguém Testou

"Tudo o que pode dar errado, dará errado... principalmente às 2h17 da madrugada, durante o fechamento mensal, quando o especialista está de férias e o gerente pergunta: 'Mas vocês não testaram isso?'"


Prólogo — O Bug Impossível da Matrix

Era o último minuto antes da implantação da nova versão da Matrix.

Toda a equipe estava reunida.

Neo revisava cuidadosamente o último programa COBOL.

Trinity conferia as APIs.

Tank monitorava o CICS.

Link acompanhava as filas MQ.

O Arquiteto perguntou:

— Todos os testes passaram?

Neo respondeu confiante.

— Sim.

O Arquiteto sorriu.

— Todos?

Neo hesitou.

— Bem...

todos os que imaginamos.

O sistema entrou em produção.

Cinco segundos depois.

O telefone tocou.

Era Zion.

O saldo de todos os habitantes havia desaparecido.

Neo olhou para Morpheus.

— Como isso aconteceu?

O Oráculo apareceu.

Pegou um pequeno parafuso metálico.

Colocou sobre a mesa.

E disse:

"Vocês testaram tudo... menos aquilo que realmente iria acontecer."

Neo respirou fundo.

Naquele instante compreendeu a Lei de Murphy.


O que é a Lei de Murphy?

A Lei de Murphy é um princípio informal que afirma:

"Anything that can go wrong, will go wrong."

Ou, em português:

"Tudo o que pode dar errado, dará errado."

Na Engenharia de Software, essa frase não significa pessimismo.

Ela significa preparação.

Projetamos sistemas assumindo que falhas acontecerão.

Porque elas realmente acontecem.


A verdadeira origem da Lei de Murphy

Ao contrário do que muita gente imagina, a Lei de Murphy não nasceu da computação.

Ela surgiu em 1949, durante experimentos da Força Aérea dos Estados Unidos.

O engenheiro Edward A. Murphy Jr. trabalhava em testes de aceleração com foguetes.

Em um dos experimentos, sensores foram instalados de maneira incorreta.

Todos.

O teste inteiro falhou.

Murphy comentou algo equivalente a:

"Se existir uma maneira de alguém montar isso errado, alguém vai montar."

Com o tempo a frase evoluiu para a forma conhecida mundialmente.


Matrix explica perfeitamente

Imagine Neo.

Existe apenas uma porta errada.

Qual porta o Agente Smith escolhe?

Exatamente aquela.

Existe um cabo conectado invertido.

Qual cabo será usado na produção?

Esse mesmo.

Existe um único usuário que digita um caractere inesperado.

Quem aparece primeiro?

Ele.

Murphy nunca dorme.


O COBOL conhece Murphy há décadas

Imagine um programa.

Você testou:

  • CPF válido.

  • Saldo positivo.

  • Cliente ativo.

Tudo funciona.

Primeiro dia em produção.

Chega um cliente com:

  • CPF estrangeiro.

  • Conta conjunta.

  • Limite especial.

  • Saldo negativo.

  • Produto encerrado.

  • Agência incorporada.

  • Dados vindos via Open Finance.

ABEND.

Murphy sorri.


Murphy não cria problemas

Essa é uma confusão comum.

Murphy não "faz" algo dar errado.

Ele apenas lembra que:

seres humanos erram.

Hardware falha.

Redes caem.

Discos quebram.

Usuários digitam errado.

APIs ficam indisponíveis.

Sistemas distribuídos apresentam atrasos.

Falhas fazem parte da realidade.


Matrix Reloaded

Neo finalmente aprende a enxergar o código verde.

Mesmo assim.

Ele nunca assume que a Matrix será perfeita.

Sempre existe:

um agente escondido.

um programa exilado.

uma porta secreta.

uma variável inesperada.

Essa postura é exatamente o espírito da Engenharia de Software.


O efeito psicológico

Existe um viés chamado:

Excesso de confiança.

Pensamos:

"Comigo não acontece."

Até acontecer.

Murphy combate exatamente esse comportamento.


O Programador COBOL Padawan

Imagine seu primeiro programa.

Você testa:

10

20

30

Tudo funciona.

Produção recebe:

-999999999999

Ou:

ZERO

SPACES

NULL

UTF-8

EBCDIC inesperado

Você nunca imaginou.

Murphy imaginou.


O Agente Smith adora pressupostos

Smith sabe que basta uma hipótese falsa.

"Esse campo nunca vem vazio."

"Esse arquivo sempre chega."

"Essa API nunca cai."

"Esse usuário nunca faz isso."

É exatamente aí que ele ataca.


Um exemplo COBOL

Programa.

DIVIDE WS-VALOR
   BY WS-QUANTIDADE

Pergunta.

Quem garantiu que:

WS-QUANTIDADE

nunca será zero?

Se ninguém garantiu.

Murphy garantirá o contrário.


Outro exemplo clássico

READ CLIENTE

E se o registro não existir?

Foi testado?


Como Murphy aparece?

Pequenos detalhes.

  • Arquivo cheio.

  • Disco indisponível.

  • Dataset bloqueado.

  • Job cancelado.

  • Db2 indisponível.

  • MQ congestionado.

  • Timeout REST.

  • Token expirado.

  • Data inválida.

  • Leap Year.

  • Horário de verão.

Nenhum parece impossível.

Todos acontecem.


O custo invisível

A maior parte do desenvolvimento testa:

caminhos felizes.

Pouca gente testa:

fracassos.

Mas é justamente neles que sistemas críticos demonstram qualidade.


O impacto no Mainframe

Mainframes executam bilhões de transações.

Logo.

Mesmo eventos raríssimos acabam acontecendo.

Se uma falha possui probabilidade de:

1 em 100 milhões.

Um banco processando bilhões de operações provavelmente a encontrará.


Curiosidade

Existe uma frase muito conhecida entre engenheiros:

"Hope is not a strategy."

Esperança não substitui testes.


Matrix e os Sentinelas

Imagine construir Zion assumindo que:

"Os Sentinelas nunca encontrarão este túnel."

Essa não é uma estratégia.

É um desejo.


Ferramentas ajudam

Hoje possuímos recursos incríveis.

No universo IBM.

  • ZUnit.

  • IBM Test Accelerator.

  • Galasa.

  • Debug Tool.

  • Fault Analyzer.

  • File Manager.

  • Application Performance Analyzer.

  • OMEGAMON.

  • Instana.

Eles ajudam a descobrir falhas antes da produção.


O papel dos testes

Murphy explica exatamente por que existem:

Testes Unitários

Cada módulo.


Testes Integrados

Comunicação.


Testes de Performance

Carga.


Testes de Segurança

Ataques.


Chaos Engineering

Falhas controladas.


Disaster Recovery

Pior cenário.


Matrix e Chaos Engineering

Imagine Morpheus desligando propositalmente parte da Matrix.

Por quê?

Para descobrir.

Antes de Smith.

Essa é exatamente a ideia do Chaos Engineering.


O papel da IA

A IA pode:

  • gerar casos de teste;

  • encontrar caminhos pouco explorados;

  • sugerir cenários extremos;

  • revisar código;

  • detectar riscos.

Mas continua dependendo da criatividade humana para imaginar situações improváveis.


Atenção!

Murphy não significa paranoia.

Significa preparação.

Existe enorme diferença.


A diferença

Pessimismo

"Nada funciona."


Engenharia

"Se falhar, estaremos preparados."


Os riscos

Quando Murphy é ignorado.

Surgem.

  • ABENDs.

  • Incidentes.

  • Perda financeira.

  • Vazamento de dados.

  • Retrabalho.

  • Imagem comprometida.


Erros clássicos

  • Testar apenas cenário feliz.

  • Ignorar exceções.

  • Não validar entrada.

  • Assumir infraestrutura perfeita.

  • Não testar recuperação.


Boas práticas

  • Teste entradas inválidas.

  • Faça testes negativos.

  • Automatize regressão.

  • Valide limites.

  • Simule falhas.

  • Faça rollback.

  • Monitore produção.


Aplicabilidade

Murphy aparece em:

  • COBOL.

  • CICS.

  • Db2.

  • MQ.

  • Cloud.

  • Java.

  • Python.

  • Kubernetes.

  • APIs.

  • IA.

Nenhuma tecnologia escapa.


O ensinamento do Oráculo

O Oráculo entrega duas xícaras para Neo.

Uma perfeita.

Outra com uma pequena rachadura.

Pergunta.

— Qual você levaria para atravessar o deserto?

Neo escolhe a perfeita.

Ela sorri.

Depois derruba as duas.

A perfeita quebra.

A rachada continua inteira porque era mais espessa.

Ela olha para Neo.

"Você testou apenas a aparência. Nunca testou a queda."


Murphy e o Mainframe Moderno

No universo IBM Z existe um princípio silencioso que acompanha décadas de engenharia: construa sistemas assumindo que componentes falharão.

Por isso existem:

  • Parallel Sysplex para alta disponibilidade.

  • GDPS para recuperação de desastres.

  • RACF para minimizar erros de acesso.

  • CICS Transaction Server com recuperação automática.

  • Db2 com logs e rollback.

  • MQ garantindo entrega confiável de mensagens.

Nada disso existe porque os engenheiros acreditavam que tudo funcionaria para sempre.

Existe porque eles sabiam que Murphy apareceria.


Lições para um Programador COBOL Padawan

Durante sua carreira você escreverá programas que movimentarão dinheiro, impostos, aposentadorias, seguros e milhões de transações críticas.

Nunca pergunte apenas:

"O programa funciona?"

Pergunte também:

  • O que acontece se o arquivo não existir?

  • E se o banco estiver indisponível?

  • E se o usuário informar dados inválidos?

  • E se houver timeout?

  • E se a conexão cair durante o COMMIT?

  • E se o disco ficar cheio?

  • E se o horário mudar por causa do fuso?

Essas perguntas transformam um programador em um engenheiro.


Curiosidades

A Lei de Murphy inspirou diversos conceitos modernos:

  • Defensive Programming

  • Fail Fast

  • Circuit Breaker

  • Retry Pattern

  • Bulkhead Pattern

  • Chaos Engineering

  • Site Reliability Engineering (SRE)

Todos partem da mesma premissa:

falhas acontecerão.

A diferença está em como o sistema reage a elas.


Conclusão — A Matrix Não Era Forte Porque Nunca Falhava

No final da trilogia percebemos algo importante.

A Matrix nunca foi perfeita.

Ela possuía mecanismos para detectar falhas, adaptar-se e continuar funcionando.

Essa é exatamente a essência da Engenharia de Software.

A Lei de Murphy não é um convite ao pessimismo.

É um convite à humildade.

Ela nos lembra que usuários surpreendem, infraestrutura falha, requisitos mudam e eventos improváveis acabam acontecendo — especialmente em sistemas que executam milhões ou bilhões de operações.

Para um Programador COBOL, especialmente no ambiente IBM Z, isso significa projetar aplicações resilientes, validar entradas, tratar exceções, automatizar testes e preparar planos de recuperação antes que a produção cobre essa preparação.

No universo Bellacosa Mainframe existe uma máxima que Morpheus certamente diria aos novos Padawans antes do primeiro deploy:

"Não escreva código esperando que nada falhe. Escreva código sabendo que um dia tudo poderá falhar — e que, mesmo assim, o sistema continuará de pé."

Porque o verdadeiro Escolhido não é aquele que nunca encontra um bug.

É aquele que já havia imaginado esse bug muito antes de ele aparecer na tela verde do terminal.

quinta-feira, 9 de janeiro de 2020

A Deep Web que Não Era Deep — o dia em que o Google esqueceu a velha Internet

 

Bellacosa Mainframe e a web que o google expulsou do radar

☕ Um Café no Bellacosa Mainframe

A Deep Web que Não Era Deep — o dia em que o Google esqueceu a velha Internet

🕸️ Quando páginas públicas, blogs esquecidos, fóruns mortos, fanpages obscuras e bizarrices culturais continuaram existindo — mas desapareceram do mapa

Existe um tipo muito específico de solidão digital.

Você lembra que uma coisa existia.

Tem quase certeza de que viu aquilo em algum lugar.

Talvez fosse um blog sobre anime de 2007.

Talvez um fórum sobre computadores japoneses.

Talvez uma página de fã dedicada a uma atriz secundária de uma série esquecida.

Talvez uma propaganda brasileira de 1989.

Talvez um texto obscuro sobre COBOL escrito por alguém que trabalhou num banco em 1996.

Você abre o Google.

Pesquisa.

Nada.

Tenta de novo.

Troca as palavras.

Coloca aspas.

Remove as aspas.

Adiciona o ano.

Adiciona “blogspot”.

Adiciona “forum”.

Adiciona “archive”.

E então acontece aquela sensação estranha:

a Internet está enorme, mas parece menor.

Bem-vindo à Deep Web que não era Deep.



🎹 Play it again, Sam

Existe uma frase que todo mundo conhece:

“Play it again, Sam.”

Só há um detalhe divertido.

Rick não fala exatamente isso em Casablanca.

A frase foi sendo reconstruída pela memória popular até se tornar mais famosa que a versão original.

Isso é cultura.

Não funciona como checksum.

Não funciona como hash.

Não funciona como um banco de dados perfeitamente normalizado.

Funciona como uma gigantesca memória distribuída cheia de erros, repetições, interpretações, referências cruzadas e pequenas corrupções.

E durante muito tempo a Web foi provavelmente a melhor máquina já criada para preservar essa bagunça maravilhosa.

Você pesquisava:

Play it again, Sam

e não encontrava apenas Casablanca.

Encontrava um blog de cinema.

Depois um fórum.

Depois Woody Allen.

Depois alguém discutindo citações erradas de filmes.

Depois uma página pessoal de 1998 sobre Humphrey Bogart.

Depois um sujeito explicando por que determinada tradução brasileira estava errada.

Três horas depois você estava lendo sobre algum projetor soviético usado numa universidade da antiga Tchecoslováquia.

E pensava:

como diabos eu vim parar aqui?

Essa era a magia.

A velha Internet não era particularmente eficiente.

Mas era extraordinariamente boa em permitir que você se perdesse com qualidade.



🏺 A Internet como sítio arqueológico

Quem começou a navegar nos anos 1990 ou 2000 provavelmente se lembra de uma Web muito diferente.

Sites pessoais.

GeoCities.

Tripod.

Angelfire.

Fóruns.

Guestbooks.

FTP.

Usenet.

BBS sobreviventes.

Páginas de universidades.

Blogs independentes.

Blogspot.

LiveJournal.

Fotolog.

Orkut.

Sites de fãs.

Páginas feitas em FrontPage.

HTML escrito à mão.

GIFs piscando.

Contadores de visitas.

Cursores personalizados.

MIDI tocando automaticamente.

Era bonito?

Frequentemente não.

Era organizado?

De jeito nenhum.

Mas havia uma coisa preciosa ali:

densidade humana.

Cada página parecia ter sido feita por alguém.

Não necessariamente por uma empresa.

Não necessariamente por um especialista.

Não necessariamente por alguém tentando vender alguma coisa.

Às vezes era apenas um sujeito de Campinas apaixonado por locomotivas japonesas.

Ou uma estudante portuguesa catalogando filmes de terror italianos.

Ou um programador alemão documentando uma biblioteca obscura.

Ou alguém no Japão fotografando máquinas de vending.

E essas pessoas criavam páginas.

E essas páginas apontavam para outras páginas.

Era um gigantesco organismo descentralizado.



🔗 A Web era uma rede de verdade

Talvez esse seja o ponto mais importante.

A palavra Web não foi escolhida por acaso.

Teia.

Uma página apontava para outra.

Um blog possuía um blogroll.

O blogroll apontava para quinze outros blogs.

Os comentários tinham URLs.

Os autores respondiam citando outro texto.

Um fórum apontava para uma página pessoal.

A página pessoal apontava para um FTP.

O FTP possuía uma documentação.

A documentação mencionava um software.

Você pesquisava o software.

Encontrava outro fórum.

Era uma espécie de random walk cultural.

Em termos de teoria de grafos, aquilo era maravilhoso.

Imagine:

BLOG A
   |
   +------ BLOG B
   |          |
   |          +------ FÓRUM C
   |                     |
   |                     +------ SITE D
   |
   +------ PÁGINA PESSOAL E
              |
              +------ FTP F

O usuário não precisava conhecer previamente o destino.

Bastava entrar no grafo.

A própria arquitetura levava você adiante.


🧱 Então construímos jardins murados

Aos poucos, grande parte da produção humana migrou.

Facebook.

Instagram.

TikTok.

Discord.

Telegram.

WhatsApp.

Aplicativos.

Plataformas privadas.

Comunidades fechadas.

O conteúdo continuou sendo produzido.

Provavelmente mais conteúdo do que em qualquer momento anterior da história.

Só que algo mudou.

O hyperlink começou a desaparecer.

Você não publica necessariamente uma página.

Você publica dentro de uma plataforma.

O conteúdo passa a possuir contexto interno.

O relacionamento entre pessoas passa a existir dentro do sistema.

O grafo deixa de ser:

SITE A → SITE B → SITE C

e passa a ser:

PLATAFORMA
   |
   +-- usuário
   +-- usuário
   +-- usuário
   +-- post
   +-- vídeo
   +-- grupo

Do lado de fora existe apenas um muro.

Muito conteúdo.

Poucas portas.


🕳️ A verdadeira Deep Web cotidiana

Tecnicamente, Deep Web significa conteúdo não indexado por mecanismos de busca.

Sistemas internos.

Bases de dados.

Conteúdo protegido por autenticação.

Painéis privados.

Aplicações.

Nada de particularmente misterioso.

Mas surgiu uma segunda categoria curiosa.

Conteúdo que:

  • é público;

  • pode ser acessado por URL;

  • não exige login;

  • não está criptograficamente escondido;

  • continua disponível no servidor;

e mesmo assim praticamente desapareceu da descoberta cotidiana.

Não porque esteja secreto.

Mas porque ninguém mais chega até ele.

Eu gosto de chamar isso de:

Dark Long Tail da Web

A cauda longa obscura da Internet.

Milhões de páginas que ainda estão tecnicamente online, mas culturalmente desconectadas.


👻 O site fantasma

Imagine um blog criado em 2006.

Última postagem:

17 de março de 2011.

Existem 438 artigos.

Uma sidebar.

Setenta links.

Comentários.

Fotos.

Relatos pessoais.

Referências.

Reviews.

Tutoriais.

Curiosidades.

O autor abandonou o projeto.

Mas o servidor continua respondendo:

HTTP 200 OK

A página está viva.

Só que ninguém visita.

Ela não aparece nas buscas comuns.

Os blogs que apontavam para ela morreram.

Os fóruns que mencionavam o endereço desapareceram.

As redes sociais que compartilhavam aquele conteúdo foram encerradas.

O domínio talvez ainda exista.

Tecnicamente:

online.

Culturalmente:

morto.

É praticamente uma cidade romana soterrada.

As paredes estão lá.

As ruas estão lá.

As inscrições estão lá.

O problema é descobrir onde cavar.


🏛️ E então temos o Blogspot

Aqui começa a parte divertida.

O Blogspot é uma coisa extraordinária.

Não necessariamente porque seja moderno.

Justamente pelo contrário.

Ele preservou uma arquitetura quase fóssil da Web.

Arquivos mensais.

Posts individuais.

Labels.

Sidebars.

Blogrolls.

Comentários.

Links permanentes.

Imagens.

Páginas estáticas.

E principalmente:

URLs que continuam funcionando depois de quinze ou vinte anos.

Há blogs abandonados que hoje parecem pequenas Pompeias digitais.

O autor foi embora.

A comunidade desapareceu.

Os comentários pararam.

Mas tudo ficou congelado.

Você entra.

E parece ouvir os fantasmas da velha Web conversando.


🔍 Google, encontre isso para mim

Durante muitos anos havia uma sensação quase mística:

Se está na Internet, o Google encontra.

Nunca foi literalmente verdade.

Mas parecia verdade o suficiente.

O índice era gigantesco.

Links eram seguidos.

Páginas obscuras apareciam.

Consultas estranhas retornavam resultados igualmente estranhos.

Então a Web cresceu absurdamente.

E indexar a Web inteira deixou de ser apenas uma questão de encontrar páginas.

Virou uma questão de decidir:

o que vale a pena rastrear?

o que vale a pena indexar?

o que vale a pena apresentar?

E aqui nasce uma distinção importante.

Existem três operações diferentes:

CRAWL
  ↓
INDEX
  ↓
RANK

Primeiro o mecanismo precisa descobrir a página.

Depois decidir armazená-la no índice.

Depois decidir se ela merece aparecer para você.

Uma página pode existir e falhar em qualquer um desses pontos.


🧮 Bem-vindo ao WLM da Internet

Programador de mainframe vai entender imediatamente.

O Google tem recursos finitos.

CPU.

Storage.

Network.

Crawl budget.

Prioridade.

Classificação.

Pense nisso como um Workload Manager planetário.

Temos workloads.

Alguns recebem prioridade alta.

Outros recebem baixa.

Se você administra bilhões de URLs, precisa decidir onde gastar recursos.

Então imagine algo parecido com:

SERVICE CLASS: IMPORTANT_CURRENT_CONTENT
IMPORTANCE: 1

SERVICE CLASS: COMMERCIAL_INFORMATION
IMPORTANCE: 2

SERVICE CLASS: CURRENT_POPULAR_PAGES
IMPORTANCE: 2

SERVICE CLASS: BLOG_ABANDONADO_2009
IMPORTANCE: 5

😂

O Blogspot sobre VHS japoneses pode continuar existindo.

Mas talvez ninguém queira gastar CPU nele.


🦖 O COBOL cultural

Aqui surge uma analogia especialmente deliciosa.

COBOL sofre exatamente do mesmo preconceito.

Algo é antigo.

Então presumimos:

irrelevante.

Só que idade e irrelevância não são a mesma variável.

Um programa COBOL escrito em 1988 pode continuar processando milhões de transações.

Um blog escrito em 2008 pode possuir a única descrição existente de determinado acontecimento.

Um fórum de 2004 pode conter a única solução conhecida para determinado equipamento.

Uma página pessoal de 1999 pode guardar fotos que não existem em nenhum outro lugar.

Velho não significa lixo.

Velho significa:

precisa de contexto para sabermos se é lixo.


🤖 A ironia da Inteligência Artificial

E agora chegamos a uma ironia magnífica.

Vivemos na era dos modelos gigantes.

LLMs.

RAG.

Knowledge graphs.

Vector databases.

Semantic search.

Agentes.

Embeddings.

Todo mundo quer construir máquinas capazes de compreender o conhecimento humano.

Só que paralelamente estamos permitindo que pedaços enormes do conhecimento humano desapareçam da superfície pesquisável.

É quase como construir a Enterprise enquanto queimamos a biblioteca.

A IA pergunta:

Onde estão os dados?

A humanidade responde:

Estavam num fórum.

Qual fórum?

Não lembro.

Existe?

Acho que sim.

URL?

Não tenho.

Parabéns. Temos 300 bilhões de parâmetros e não encontramos a página do Seu Arnaldo sobre rádios valvulados de 1973.


🗺️ Search virou answer engine

Também ocorreu outra transformação.

Antes, o mecanismo de busca dizia:

Aqui estão dez caminhos.

Agora cada vez mais tenta dizer:

Aqui está a resposta.

Isso parece uma melhoria.

E muitas vezes é.

Mas existe um custo filosófico.

Quando você recebe uma resposta sintetizada, não necessariamente percorre os caminhos que levariam às fontes marginais.

A resposta fica melhor.

A aventura piora.


🧭 A serendipidade morreu?

Serendipidade é descobrir algo valioso sem estar procurando exatamente aquilo.

A velha Web era uma máquina extraordinária de serendipidade.

Você pesquisava:

IBM 3270 terminal

Encontrava:

3270
 ↓
mainframe museum
 ↓
computadores dos anos 1970
 ↓
companhias aéreas
 ↓
sistemas de reservas
 ↓
Sabre
 ↓
história da American Airlines
 ↓
algum blog obscuro
 ↓
um sujeito contando como trabalhava num aeroporto em 1994

E então percebia que acabou aprendendo alguma coisa que nem sabia que queria aprender.

Pesquisa moderna frequentemente tenta eliminar esse ruído.

Só que aquele ruído também era cultura.


🪦 Link rot: o cemitério invisível

Existe ainda outro inimigo.

Links morrem.

Domínios expiram.

Sites mudam.

Serviços encerram.

CMS são migrados.

URLs mudam.

Empresas desaparecem.

Isso é chamado de link rot.

Você encontra um artigo de 2005 contendo:

Para saber mais:
http://www.exemplo.com/artigo/123.html

Clica.

Nada.

Domain parking.

Cassino online.

Página vendendo suplemento.

A referência desapareceu.

O texto sobreviveu.

A evidência morreu.

É devastador para história digital.


📚 O hyperlink também é citação

Nós tratamos links como elementos técnicos.

Mas eles são muito mais do que isso.

Um link diz:

“Eu estava lendo aquilo quando escrevi isto.”

É uma relação intelectual.

Um fragmento de contexto.

Uma pequena linha genealógica do conhecimento.

Quando os links desaparecem, perdemos não apenas navegação.

Perdemos proveniência.


🧬 O grafo cultural vai se desfazendo

Imagine:

A → B → C → D

D desaparece.

Depois C sai do índice.

Depois B perde relevância.

A continua vivo.

Mas agora o caminho desapareceu.

Depois o próprio A para de receber links.

O conteúdo continua tecnicamente disponível.

Só que o grafo cultural foi desmontado.


🩺 Dr. House entra na sala

House olha o paciente.

Sintoma:

“Eu não encontro mais coisas estranhas na Internet.”

Equipe:

— Google piorou?

House:

— Sintoma idiota. Próximo.

Foreman:

— Talvez o conteúdo tenha sido removido.

House:

— Algumas páginas continuam online.

Chase:

— Então é problema de ranking.

House:

— Parcial.

Cameron:

— Mudança da arquitetura social?

House olha para o quadro.

Escreve:

CONTENT ≠ DISCOVERABILITY

E sai mancando.

Diagnóstico:

a informação não morreu. A circulação sanguínea morreu.


🧟 O conteúdo zumbi

Temos então um novo tipo de objeto digital.

Não está morto.

Não está vivo.

É um conteúdo zumbi.

Servidor responde.

HTML renderiza.

Imagens carregam.

Mas ele não participa mais da circulação cultural.

É uma URL sem comunidade.


🏴‍☠️ A arqueologia de busca

Para encontrar essas coisas, começamos novamente a usar técnicas quase artesanais.

Aspas:

"frase extremamente específica"

Restrição:

site:blogspot.com

Combinação:

site:blogspot.com "IBM 3270"

Datas:

"termo obscuro" 2007

Variações linguísticas.

Nomes antigos.

Nicknames.

Domínios extintos.

Trechos conhecidos.

E então uma página aparece.

Você abre.

E começa a seguir os links.

Nesse momento você não está mais pesquisando.

Está escavando.


⛏️ Indiana Jones da Internet

O arqueólogo digital moderno possui ferramentas peculiares.

Google.

Bing.

Internet Archive.

Caches.

Mirrors.

GitHub.

Reddit.

Usenet archives.

Blogspot.

Sites pessoais sobreviventes.

Às vezes uma única palavra encontrada em um comentário permite reconstruir uma cadeia inteira.

É OSINT cultural.


🗃️ O mainframe conhece esse problema

Existe uma velha máxima implícita em sistemas corporativos:

o dado que ninguém consegue localizar é quase equivalente ao dado inexistente.

Você pode possuir cinquenta anos de registros.

Mas se não houver catálogo, índice, metadata e relacionamentos...

boa sorte.

Em mainframe, inventamos ferramentas exatamente para impedir isso.

Catálogos.

Indexes.

VTOC.

GDG.

DB2 indexes.

Metadata.

RACF profiles.

Naming conventions.

O objetivo é simples:

saber onde as coisas estão.

A Internet está descobrindo a versão cultural desse problema.


📦 Temos os datasets. Perdemos o catálogo.

Talvez essa seja a metáfora mainframe perfeita.

Imagine um data center contendo milhões de datasets.

Todos intactos.

Mas alguém perdeu o catálogo.

Tecnicamente os dados ainda existem nos volumes.

Operacionalmente:

boa sorte.

A velha Web está caminhando para algo parecido.

Os volumes continuam montados.

As páginas continuam nos discos.

Mas o catálogo cultural está desaparecendo.


🕸️ Por isso links internos importam mais do que SEO

Quem possui um blog antigo pode fazer algo muito poderoso.

Criar ligações entre textos.

Não apenas:

“clique aqui para melhorar meu ranking.”

Mas:

“este assunto possui história.”

Um artigo sobre COBOL aponta para outro sobre System/360.

Que aponta para outro sobre Grace Hopper.

Que aponta para um sobre bancos.

Que aponta para um sobre história da computação.

O leitor entra por uma porta.

Depois começa a caminhar.

Isso cria um grafo.


🧠 O blog como knowledge graph humano

Um grande blog pode ser visto como:

POST
 |
 +-- conceito
 |
 +-- pessoa
 |
 +-- tecnologia
 |
 +-- evento histórico
 |
 +-- filme
 |
 +-- piada
 |
 +-- outro post

Milhares de textos interligados formam algo maior.

Não é apenas conteúdo.

É uma representação parcial de como alguém pensa.

Quase um knowledge graph autobiográfico.


🧱 O artigo isolado é uma ilha

Publicar um artigo sem links é fácil.

Ele nasce.

Recebe algumas visitas.

Desaparece.

Já um artigo conectado torna-se uma ponte.

Mesmo anos depois alguém pode chegar até ele por caminhos inesperados.

Isso é especialmente importante para conteúdo estranho.

Porque conteúdo estranho raramente possui volume de pesquisa suficiente para competir por ranking.

Mas pode ser encontrado por associação.


🐇 Follow the white rabbit

A melhor Internet sempre funcionou assim.

Você encontra uma coisa.

Ela aponta para outra.

Depois outra.

Depois outra.

É o buraco do coelho.

A Web sem buracos de coelho é apenas um catálogo.

E catálogos são úteis.

Mas ninguém conta histórias sobre o dia em que passou quatro horas navegando num catálogo eficiente.


📼 Cultura popular precisa dessa bagunça

Especialmente cultura popular.

Porque cultura popular raramente possui documentação formal completa.

Memes.

Dublagens.

Programas de televisão.

Propagandas.

Brinquedos.

Animes obscuros.

Revistas.

Quadrinhos.

Locadoras.

Videocassetes.

Programas de rádio.

Jogos.

Fanzines.

Músicas locais.

Boa parte dessa memória viveu em páginas amadoras.

Se essas páginas desaparecem da descoberta, a memória coletiva começa a ser reescrita pelas fontes que sobreviveram.


⚠️ E quem sobrevive normalmente é grande

Sites institucionais.

Enciclopédias.

Grandes plataformas.

Empresas.

Portais.

Isso cria um risco silencioso.

A história continua existindo.

Mas passa a ser contada apenas pelos sobreviventes mais fortes.

É survivorship bias aplicado à Internet.


🎬 Casablanca novamente

Voltemos a Sam.

A citação errada sobreviveu porque foi repetida.

Milhões de vezes.

Mas imagine uma pequena curiosidade cinematográfica que apareceu apenas em três blogs de 2004.

Dois morreram.

O terceiro continua online.

Só que ninguém o encontra.

Do ponto de vista cultural:

a informação praticamente deixou de existir.

Isso demonstra uma coisa interessante.

A memória coletiva depende menos de verdade absoluta do que de:

redundância.


💾 3-2-1 para cultura

Quem trabalha com backup conhece:

3 cópias.

2 mídias.

1 fora do local.

Talvez a cultura digital precise de uma versão semelhante.

Uma informação importante deveria existir:

em diferentes sites,

em diferentes formatos,

em diferentes comunidades.

Porque uma única URL não é preservação.

É fé.


🤖 IA pode piorar e melhorar isso

A Inteligência Artificial tem dois papéis possíveis.

O primeiro é ruim.

Modelos sintetizam respostas.

Usuários deixam de visitar páginas.

Sites recebem menos tráfego.

Autores deixam de publicar.

Fontes marginais desaparecem.

Mas existe outro cenário.

IA pode ser usada para reconstruir relações.

Extrair entidades.

Detectar referências.

Criar grafos.

Relacionar arquivos.

Descobrir páginas esquecidas.

Semantic search pode finalmente encontrar algo mesmo quando você não lembra exatamente as palavras.

Isso pode ser maravilhoso.

Desde que os documentos ainda estejam disponíveis.


🕯️ Porque IA não ressuscita o que foi apagado

Essa é uma distinção fundamental.

AI retrieval não é necromancia.

Se o documento não existe mais, o modelo não pode magicamente reconstruí-lo com fidelidade.

Pode inferir.

Pode imaginar.

Pode aproximar.

Mas isso não é arquivo.

Preservação vem primeiro.

Inteligência vem depois.


🧙 Sam ainda está no piano

Talvez a velha Web nunca tenha realmente desaparecido.

Talvez esteja apenas ficando silenciosa.

Ela continua lá.

Em servidores antigos.

Blogs abandonados.

Páginas pessoais.

Mirrors.

Arquivos.

Diretórios esquecidos.

Como um bar quase vazio depois da meia-noite.

As cadeiras continuam ali.

As garrafas continuam atrás do balcão.

E num canto existe um piano.

Você chega.

Olha para o músico.

E diz:

Play it again, Sam.

Ele começa a tocar.

E por alguns minutos voltamos à Internet onde você pesquisava uma coisa...

e encontrava o mundo.


☕ Café encerrado

Talvez estejamos vivendo uma inversão histórica curiosa.

1998

“Precisamos colocar isso na Internet para que as pessoas encontrem.”

2008

“Se existe, o Google encontra.”

2018

“Está nas redes sociais.”

2026

“Eu sei que existe. Só não consigo encontrar.”

E talvez o maior problema da Web futura não seja falta de informação.

Será exatamente o contrário.

Teremos informação demais.

Armazenada em lugares demais.

Produzida por gente demais.

Mas com cada vez menos caminhos ligando uma coisa à outra.

A Deep Web do futuro talvez não seja um lugar misterioso cheio de hackers usando capuz.

Pode simplesmente ser:

uma página pública de 2009 que ninguém mais sabe que existe.

HTTP 200.

Sem visitas.

Sem links.

Sem citações.

Sem testemunhas.

E em algum Blogspot esquecido, com sidebar gigantesca, GIF antigo, fonte duvidosa e um comentário de quinze anos atrás dizendo:

“Muito bom o texto, amigo. Abraço.”

estará guardado um pedaço da história humana que nenhum algoritmo julgou importante o suficiente para mostrar.

Talvez seja hora de começarmos a tratá-los não como páginas velhas.

Mas como aquilo que realmente são.

Artefatos arqueológicos de uma civilização digital que ainda está viva — mas já começou a esquecer o próprio passado.

☕🕸️🏺

Um Café no Bellacosa Mainframe

Onde até um HTML de 2007 merece backup antes que alguém dê DELETE PURGE na memória coletiva.

https://eljefemidnightlunch.blogspot.com/2026/08/organizacoes-tabajara-mainframe-seus.html

Time machine web

  • Marginalia Search — provavelmente é o mais próximo do que você está procurando. O próprio projeto diz priorizar conteúdo não comercial e oferecer ferramentas para encontrar “lost old websites”. Tem crawler e índice próprios e foi pensado justamente para revelar sites que você provavelmente não conhecia.
  • Wiby — voltado à Classic Web. É especialmente interessante para páginas simples, pessoais e antigas. O próprio Mwmbl o cataloga como “Search Engine for the Classic Web”.
  • Mwmbl — buscador independente, open source e sem fins lucrativos. O detalhe fantástico é que usuários podem inclusive submeter sites para serem rastreados, ajudando a reconstruir um índice alternativo.
  • Million Short — abordagem diferente e genial para nosso experimento: permite retirar da busca os sites dominantes e procurar aquilo que sobra. O objetivo declarado é justamente escapar de resultados excessivamente dominados por SEO.
  • Wayback Machine — Internet Archive — aqui mudamos de busca para arqueologia propriamente dita. Se você conhece uma URL, domínio ou pelo menos consegue descobrir o antigo endereço, pode voltar no tempo e procurar capturas históricas. A Wayback também oferece APIs para verificar e listar capturas.


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