☕ 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

sexta-feira, 21 de dezembro de 2001

Fushigi Yūgi: Eikoden - Quando um Programador COBOL Descobre que Restaurar um Backup Antigo Também Pode Restaurar Bugs que Nunca Deveriam Voltar

 

Bellacosa Mainframe apresenta fushigi yugi eikoden

☕ Um Café no Bellacosa Mainframe

Fushigi Yūgi: Eikoden (ふしぎ遊戯 永光伝) sem Mistérios

Quando um Programador COBOL Descobre que Restaurar um Backup Antigo Também Pode Restaurar Bugs que Nunca Deveriam Voltar

Depois do anime original, do primeiro OVA e de Dai Ni Bu, parecia que finalmente todos os JOBs haviam terminado com RC=0000.

Miaka e Taka (a reencarnação de Tamahome) finalmente construíram uma vida juntos.

Os Guerreiros de Suzaku seguiram seus caminhos.

O livro dos Quatro Deuses parecia definitivamente fechado.

Mas...

Todo profissional de mainframe conhece aquela cena.

Você termina um projeto gigantesco.

Arquiva toda a documentação.

Fecha os chamados.

Então alguém pergunta:

"Será que conseguimos restaurar aquele backup de três anos atrás?"

Cinco minutos depois...

O ambiente inteiro voltou a executar rotinas antigas.

É exatamente essa a proposta de Fushigi Yūgi: Eikoden.

Não é apenas uma continuação.

É uma reflexão sobre pessoas que vivem presas ao passado enquanto tentam reescrever uma história que já encontrou seu final.


Ficha Técnica

Título Original: ふしぎ遊戯 永光伝 (Fushigi Yūgi: Eikoden)

Título Internacional: Fushigi Yūgi: Eikoden

Baseado em: Light novels de Megumi Nishizaki, ilustradas por Yuu Watase

Universo Original: Fushigi Yūgi

Estúdio: Studio Pierrot

Direção: Nanako Shimazaki

Roteiro: Hiroaki Satō

Lançamento:

  • 21 de dezembro de 2001

  • 25 de junho de 2002 (último episódio)

Formato

OVA (Original Video Animation)

Quantidade de episódios

4 episódios (Wikipedia)


Gênero

  • Isekai

  • Fantasia

  • Romance

  • Drama

  • Shōjo

  • Sobrenatural


Classificação

14 anos.

Possui violência moderada, temas psicológicos, conflitos emocionais e elementos sobrenaturais.


Sinopse

Três anos após os acontecimentos da história principal, Miaka e Taka vivem felizes e esperam seu primeiro filho.

Enquanto isso, uma estudante chamada Mayo Sakaki, solitária e profundamente infeliz, encontra o lendário Livro dos Quatro Deuses.

Consumida pelo desejo de escapar da própria realidade, Mayo entra no livro e passa a acreditar que pode substituir Miaka como sacerdotisa de Suzaku.

Sua obsessão ameaça alterar o equilíbrio entre os dois mundos.


Resumo da História

Diferentemente das animações anteriores, Eikoden muda completamente o ponto de vista.

Agora acompanhamos uma protagonista diferente.

Mayo representa uma garota comum que deseja fugir da realidade.

Ao entrar no livro, ela encontra exatamente aquilo que sempre sonhou:

Um mundo onde acredita poder ser especial.

Mas logo percebe que viver dentro de uma fantasia não significa apagar suas dores.

Enquanto tenta tomar o lugar de Miaka, acaba colocando em risco toda a estabilidade conquistada pelos Guerreiros de Suzaku.


Os Personagens

Mayo Sakaki

A nova protagonista.

Insegura.

Solitária.

Carente.

Sua maior batalha acontece dentro de si mesma.

É provavelmente a personagem mais controversa de toda a franquia.


Miaka Yūki

Agora adulta.

Casada.

Grávida.

Representa maturidade.

Sua evolução desde o anime original fica evidente.


Taka (Tamahome)

A reencarnação de Tamahome.

Mais experiente e protetor.

Sua prioridade deixa de ser a aventura.

Agora é proteger sua família.


Os Guerreiros de Suzaku

Retornam para ajudar a enfrentar a nova crise.

Mais do que guerreiros, tornam-se guardiões da história que ajudaram a construir.


O que há de diferente?

Praticamente tudo.

Até então, a franquia acompanhava Miaka.

Agora seguimos Mayo.

A aventura deixa de ser uma missão para salvar um reino.

Passa a ser uma jornada sobre aceitar a própria realidade.

A fantasia funciona quase como uma terapia emocional.


As Aventuras

Mayo atravessa novamente o universo dos Quatro Deuses.

No caminho enfrenta:

  • ilusões

  • demônios

  • falsas esperanças

  • manipulações

  • entidades espirituais

  • conflitos internos

Cada obstáculo simboliza uma parte de sua própria personalidade.


Temáticas

Escapismo

Até que ponto fugir da realidade resolve nossos problemas?


Identidade

É possível ser feliz tentando viver a vida de outra pessoa?


Aceitação

O verdadeiro crescimento começa quando aceitamos quem somos.


Maturidade

Miaka representa alguém que deixou de sonhar apenas consigo.

Agora pensa na família.


Responsabilidade

Toda escolha possui consequências.

Mesmo dentro de um mundo mágico.


O Grande Diferencial

Enquanto a série original era sobre descobrir um novo mundo...

Eikoden fala sobre descobrir a si mesmo.

É um drama psicológico muito mais intimista.

Os conflitos externos existem.

Mas são apenas reflexos dos conflitos internos.


As Mensagens Ocultas

O Livro

Não representa apenas um portal.

Representa a tentação de viver em uma realidade idealizada.


Mayo

Simboliza qualquer pessoa que acredita que a felicidade sempre está na vida dos outros.


Miaka

Representa exatamente o oposto.

Ela aprendeu que felicidade exige responsabilidade.

Não apenas desejos.


Suzaku

Agora deixa de ser apenas um deus.

Passa a simbolizar esperança e renascimento.


O Paralelo Mainframe

Imagine um banco que decide restaurar um backup de produção de cinco anos atrás.

O ambiente antigo parece maravilhoso.

Não havia APIs.

Não havia cloud.

Não havia auditorias modernas.

Tudo parecia mais simples.

Até perceberem que:

  • existem milhares de vulnerabilidades;

  • as regras de negócio mudaram;

  • os usuários evoluíram;

  • o mundo não é mais o mesmo.

Eikoden mostra exatamente isso.

Não podemos viver presos à nostalgia.

Sistemas precisam evoluir.

Pessoas também.


Impacto Cultural

Entre as animações de Fushigi Yūgi, Eikoden costuma ser a mais divisiva. Muitos elogiam sua proposta de explorar um novo ponto de vista e o amadurecimento de Miaka, enquanto outros consideram Mayo uma protagonista difícil de simpatizar. Ainda assim, a OVA teve importância por adaptar uma das light novels derivadas da franquia e por encerrar a cronologia animada clássica. (Wikipedia)


Curiosidades

  • Foi baseada em duas light novels escritas por Megumi Nishizaki, com ilustrações de Yuu Watase, e não diretamente no mangá. (Wikipedia)

  • Foi a primeira animação da franquia a utilizar amplamente coloração e pintura digital, marcando uma mudança tecnológica em relação às OVAs anteriores. (Wikipedia)

  • A direção ficou a cargo de Nanako Shimazaki, diferente das animações anteriores dirigidas por Hajime Kamegaki. (Wikipedia)

  • A protagonista Mayo divide opiniões até hoje entre os fãs, sendo um dos aspectos mais debatidos da obra. (Reddit)


Nota Bellacosa Mainframe

CritérioNota
Desenvolvimento Psicológico⭐⭐⭐⭐⭐
Romance⭐⭐⭐⭐☆
Continuação do Universo⭐⭐⭐⭐☆
Originalidade⭐⭐⭐⭐⭐
Fantasia⭐⭐⭐⭐☆
Aventura⭐⭐⭐☆☆
Qualidade Visual⭐⭐⭐⭐⭐
Impacto Emocional⭐⭐⭐⭐☆

Vale a pena assistir?

Sim, mas com expectativas corretas.

Quem espera uma nova grande aventura como a série original provavelmente encontrará um ritmo mais lento e introspectivo. Já quem aprecia histórias sobre amadurecimento, identidade e as consequências das escolhas verá em Eikoden um epílogo interessante para o universo de Fushigi Yūgi.


Veredicto Final

Fushigi Yūgi: Eikoden encerra a cronologia clássica da franquia propondo uma pergunta diferente das obras anteriores: o que acontece quando alguém deseja viver a história de outra pessoa? Em vez de focar apenas na fantasia, a OVA explora temas como escapismo, amadurecimento e aceitação, mostrando que a verdadeira jornada nem sempre é atravessar um portal, mas aprender a valorizar a própria realidade.

No universo do Bellacosa Mainframe, a conclusão é inevitável:

"Todo programador já sonhou em restaurar aquela versão antiga do sistema, quando tudo parecia mais simples. Mas a experiência ensina que nem todo backup merece voltar à produção. Eikoden nos lembra que evoluir significa seguir em frente. Porque os melhores sistemas não vivem presos às versões antigas — eles carregam sua história, aprendem com ela e continuam evoluindo sem perder a essência."

sábado, 15 de dezembro de 2001

Inuyasha the Movie: Affections Touching Across Time : Quando um Programador COBOL Descobre que Alguns Bugs Foram Introduzidos Antes Mesmo do Primeiro IPL

 

Bellacosa Mainframe apresenta inuyasha the movie affections touching across time

☕ Um Café no Bellacosa Mainframe

Inuyasha the Movie: Affections Touching Across Time (犬夜叉 時代を越える想い) sem Mistérios

Quando um Programador COBOL Descobre que Alguns Bugs Foram Introduzidos Antes Mesmo do Primeiro IPL... e Agora Precisa Debugar Cinco Séculos de Dependências

"Existem sistemas cujo problema não nasceu na última atualização. Ele foi criado na primeira versão e permaneceu escondido durante séculos. O primeiro filme de Inuyasha conta exatamente esse tipo de incidente."


Introdução

Em 2001, apenas um ano após a estreia do anime de Inuyasha, o estúdio Sunrise lançou o primeiro longa-metragem da franquia.

O objetivo não era continuar diretamente o mangá de Rumiko Takahashi, mas oferecer uma aventura inédita que ampliasse o universo da série, explorando um inimigo antigo ligado aos acontecimentos do passado.

O resultado foi Inuyasha the Movie: Affections Touching Across Time, um filme que mistura ação, romance e fantasia, aprofundando a relação entre Inuyasha e Kagome enquanto apresenta um vilão original.

Para muitos fãs, este longa consolidou a franquia como uma das mais importantes do início dos anos 2000.


Dados Técnicos

Título Original

犬夜叉 時代を越える想い

Inuyasha: Toki wo Koeru Omoi

Tradução aproximada:

"Sentimentos que Atravessam o Tempo"

Título internacional:

Inuyasha the Movie: Affections Touching Across Time


Autora Original

Rumiko Takahashi (高橋留美子)

Criadora de:

  • Inuyasha

  • Ranma ½

  • Urusei Yatsura

  • Maison Ikkoku

  • Mermaid Saga

  • Mao


Estúdio

Sunrise

(atualmente Bandai Namco Film Works)


Diretor

Toshiya Shinohara


Roteiro

Katsuyuki Sumisawa


Lançamento

15 de dezembro de 2001

Japão


Duração

99 minutos


Gênero

  • Fantasia

  • Aventura

  • Romance

  • Ação

  • Sobrenatural

  • Drama


Classificação

Aproximadamente

12–14 anos

Contém:

  • batalhas

  • violência moderada

  • monstros

  • sangue leve

  • temas sobrenaturais


Sinopse

Depois de séculos aprisionado...

o poderoso yokai chinês

Menōmaru

retorna.

Seu objetivo é completar o plano iniciado por seu pai:

destruir o legado deixado por Inu no Taishō, pai de Inuyasha e Sesshomaru.

Enquanto isso...

Kagome começa a perceber que seus sentimentos por Inuyasha estão se tornando cada vez mais profundos.

A aventura rapidamente se transforma numa batalha entre passado e presente.


Resumo

O filme apresenta um inimigo completamente novo.

Menōmaru deseja vingar a derrota do pai.

Para isso tenta controlar:

  • Inuyasha

  • Kagome

  • o poder demoníaco

  • a Pérola de Shikon

A luta torna-se tanto física quanto psicológica.


A História

Muitos anos antes da série...

o Grande Cão Demônio derrotou o poderoso:

Hyōga

um antigo guerreiro demoníaco vindo do continente asiático.

Antes de morrer...

Hyōga deixa um filho.

Menōmaru

Séculos depois...

Menōmaru desperta.

Ele descobre que Inu no Taishō morreu.

Então decide concluir a vingança iniciada pelo pai.

Sua estratégia consiste em despertar completamente o sangue demoníaco de Inuyasha e usá-lo contra seus próprios aliados.


Os Personagens

Inuyasha

Precisa enfrentar seu lado demoníaco.

Mostra um enorme crescimento emocional.


Kagome

Tem papel muito mais importante do que apenas arqueira.

Seu vínculo espiritual torna-se fundamental para salvar Inuyasha.


Menōmaru

Primeiro grande vilão cinematográfico da franquia.

Representa vingança herdada.

Seu objetivo não é conquistar.

É destruir um legado.


Sesshomaru

Participação menor.

Mas extremamente marcante.

Sempre elegante.

Sempre poderoso.


Miroku

Continua oferecendo equilíbrio entre humor e inteligência.


Sango

Mantém seu papel de guerreira estratégica.


Shippo

Responsável por momentos leves em meio ao drama.


O Que Tem de Diferente?

Ao contrário da série de TV, o filme concentra toda a narrativa em um único conflito, com ritmo mais acelerado e foco na relação entre Inuyasha e Kagome.

Além disso, apresenta um antagonista ligado diretamente ao passado da família de Inuyasha, explorando aspectos pouco desenvolvidos naquele momento do anime.


Temáticas

Amor

Kagome finalmente compreende seus sentimentos.


Herança

Filhos carregam conflitos iniciados pelos pais.


Passado

Nem toda guerra termina quando alguém morre.


Escolhas

O sangue demoníaco não define quem Inuyasha é.


Vingança

O ódio pode atravessar gerações.


As Aventuras

A jornada leva o grupo a enfrentar Menōmaru e seus servos, explorando castelos antigos, florestas amaldiçoadas e batalhas que colocam Inuyasha à beira de perder o controle sobre sua natureza demoníaca.

Kagome assume um papel decisivo ao impedir que ele seja consumido pelo ódio, reforçando que a maior força do protagonista não está apenas em sua espada, mas também nos laços que construiu.


Mensagens Ocultas

O Passado Continua Executando

Mesmo quando ninguém percebe.


Poder Sem Controle

Sempre cobra um preço.


Amor Também Salva

Não apenas espadas.


O Ódio é Herdado

Mas não precisa continuar.


O Tempo Não Cura Tudo

Alguém precisa enfrentar os problemas.


Impacto Cultural

O primeiro filme foi um enorme sucesso entre os fãs da franquia e abriu caminho para outros três longas-metragens.

Também demonstrou que Inuyasha possuía um universo forte o suficiente para histórias inéditas, sem depender exclusivamente do mangá.

A animação recebeu elogios pela qualidade superior à da televisão, pela trilha sonora cinematográfica de Kaoru Wada e pelas cenas de ação.


Censura

O filme sofreu poucas alterações fora do Japão.

As principais mudanças envolveram:

  • redução de sangue em algumas transmissões televisivas;

  • adaptações de classificação indicativa;

  • pequenos ajustes em diálogos nas dublagens internacionais.

A versão em DVD e Blu-ray preserva praticamente todo o conteúdo original.


Mangás

O filme não adapta um arco do mangá.

Sua história é original, criada especialmente para o cinema com supervisão da equipe responsável pelo anime.

Posteriormente recebeu adaptações em formato de anime comic e materiais promocionais.


Light Novels

Não existe uma light novel canônica baseada neste filme.


Games

Embora o filme não tenha gerado um jogo exclusivo, elementos de Menōmaru e de sua história apareceram em materiais promocionais e influenciaram personagens e eventos de alguns jogos da franquia.

Os principais títulos relacionados continuam sendo:

  • Inuyasha: A Feudal Fairy Tale (PlayStation)

  • Inuyasha: The Secret of the Cursed Mask (PlayStation 2)

  • Inuyasha: Feudal Combat (PlayStation 2)

  • Inuyasha: Secret of the Divine Jewel (Nintendo DS)


Curiosidades

  • Foi o primeiro longa da franquia a estrear nos cinemas japoneses.

  • A trilha sonora de Kaoru Wada recebeu novos arranjos orquestrais exclusivos para o filme.

  • Menōmaru é um personagem original criado especificamente para o cinema.

  • A qualidade da animação é visivelmente superior à da série de TV, com cenários mais detalhados e batalhas mais elaboradas.


Easter Eggs

  • A história amplia a mitologia em torno de Inu no Taishō, mostrando que sua influência alcançava além do Japão.

  • O despertar da forma demoníaca de Inuyasha antecipa conflitos internos que seriam aprofundados na série principal.

  • O título "Affections Touching Across Time" simboliza tanto o romance entre Inuyasha e Kagome quanto a permanência dos laços familiares e das consequências das ações passadas.


Avaliação Bellacosa Mainframe

AspectoNota
História⭐⭐⭐⭐☆ (4,5/5)
Ação⭐⭐⭐⭐⭐ (5/5)
Romance⭐⭐⭐⭐☆ (4,5/5)
Animação⭐⭐⭐⭐⭐ (5/5)
Trilha Sonora⭐⭐⭐⭐⭐ (5/5)
Vilão⭐⭐⭐⭐☆ (4,5/5)
Fidelidade ao universo⭐⭐⭐⭐⭐ (5/5)

Nota Final: 9,3/10

É um excelente ponto de entrada para os filmes de Inuyasha e uma aventura que amplia o universo da série sem contradizer sua essência.


☕ Bellacosa Mainframe

Imagine um sistema COBOL implantado em 1520.

Durante cinco séculos ninguém mexeu em determinados módulos.

Todo mundo acredita que funcionam perfeitamente.

Até que um dia aparece um incidente crítico.

Depois da investigação, a equipe descobre que o defeito não foi criado pela última alteração.

Nem pela anterior.

Nem pela equipe atual.

O bug foi introduzido pelo arquiteto original do sistema, centenas de anos atrás.

Menōmaru representa esse incidente histórico que ressurge quando todos acreditavam que estava resolvido.

Inuyasha é o módulo crítico que precisa decidir se continuará executando rotinas antigas ou adotará uma nova lógica de funcionamento.

Kagome atua como a analista que compreende tanto a arquitetura moderna quanto o legado histórico, tornando-se a ponte entre duas gerações de tecnologia.

No fim, Affections Touching Across Time ensina uma lição que qualquer profissional de mainframe reconhece: os problemas mais difíceis raramente nascem na última atualização. Eles costumam estar escondidos em decisões tomadas há muito tempo, esperando apenas o momento certo para reaparecer em produção.

quinta-feira, 13 de setembro de 2001

Andaças por Montevideu

Viagem a Montevideu 


O ano 2001 foi um ano totalmente marcante, tanto que esta viagem a capital do Uruguay foi eclipsado pelos atentados de 11/9. Minha viagem era para o dia 12, porem devido ao caos que foi o day after do ataque as Torres Gémeas de Nova York, fomos remarcados para o dia 13.



Com a segurança alta nos aeroportos, a vigilância constante esta viagem na ida não foi tão interessante quanto eu desejava.

Chegando em Montevideu transcorreu tudo tranquilo, os colegas uruguaios eram muito simpáticos sendo grandes anfitriões, após o expediente fazíamos diversas actividades e aproveitávamos para conhecer a capital platina.

Provamos o churrasco uruguaio, cerveja e conhecemos a vida nocturna neste pequeno pais.

Agora a melhor surpresa estava no retorno na semana seguinte, meu voo era American Airline, justamente uma companhia que perdera avião no atentando, éramos 6 passageiro num voo de quase 300 passageiros. Que mordomia, que simpatia ate o piloto véu agradecer o voto de confiança em voar com AA.

sexta-feira, 1 de junho de 2001

📚 MYNE E A BIBLIOTECA PERDIDA DO MAINFRAME — QUANDO O COBOL DESCOBRIU QUE CÓDIGO SEM DOCUMENTAÇÃO TAMBÉM PODE VIRAR UM LIVRO ESQUECIDO

 

Bellacosa Mainframe e a documentação de software

☕ Um Café no Bellacosa Mainframe

📚 MYNE E A BIBLIOTECA PERDIDA DO MAINFRAME — QUANDO O COBOL DESCOBRIU QUE CÓDIGO SEM DOCUMENTAÇÃO TAMBÉM PODE VIRAR UM LIVRO ESQUECIDO

Documentação, COBOL, auditoria, Configuration Management, Git, runbooks, dívida documental, conhecimento institucional, IA generativa — e o dia em que Myne descobriu que o maior risco do sistema não estava no programa, mas na cabeça do único programador que sabia como ele funcionava.



🎬 PRÓLOGO — MYNE ENCONTROU UM PROGRAMA COBOL

Myne abriu os olhos.

Não estava em Ehrenfest.

Não havia templo.

Não havia Ferdinand.

Não havia sequer uma biblioteca.

Diante dela existia uma tela preta com letras verdes.

READY

DSN SYSTEM(DB2P)

IKJ56700A ENTER USERID -

— Onde estão os livros?

Um velho programador apontou para milhares de datasets.

HLQ.PROD.COBOL
HLQ.PROD.COPYLIB
HLQ.PROD.JCL
HLQ.PROD.PROCLIB
HLQ.PROD.PARMLIB

Myne arregalou os olhos.

— Então... isso tudo é conhecimento?

— Mais ou menos.

— Onde está a documentação?

Silêncio.

O programador olhou para o teto.

Outro fingiu que estava analisando um dump.

Um terceiro tomou café.

Finalmente alguém respondeu:

— Pergunta para o Carlos.

Myne imediatamente percebeu que havia encontrado um problema muito mais grave do que a falta de livros.

A empresa possuía milhares de programas.

Mas parte importante do conhecimento necessário para compreendê-los estava armazenada em um dispositivo extremamente sofisticado, porém perigosamente volátil:

a memória dos funcionários.

Bem-vindo, jovem programador COBOL, à dungeon da documentação.



📜 CAPÍTULO 1 — CÓDIGO NÃO É DOCUMENTAÇÃO

Existe uma frase muito repetida no desenvolvimento:

“O código é a documentação.”

Ela contém alguma verdade, mas também pode esconder uma armadilha.

Veja:

       IF WS-TIPO-CLIENTE = 'E'
           PERFORM 8200-CALCULO-ESPECIAL
       END-IF.

Mesmo um iniciante consegue perceber o comportamento básico.

Se WS-TIPO-CLIENTE for igual a E, o programa executa 8200-CALCULO-ESPECIAL.

Ótimo.

Mas agora Myne começa a fazer perguntas.

— O que significa E?

— Especial.

— O que é um cliente especial?

— Não sei.

— Quem decidiu isso?

— Não sei.

— Por que ele recebe cálculo diferente?

— Também não sei.

— Desde quando?

— Talvez 2004.

— Posso remover?

— NÃO!

E encontramos a diferença entre código e conhecimento.

O código descreve muito bem aquilo que o computador precisa executar.

Mas nem sempre preserva:

  • por que determinada decisão foi tomada;

  • qual requisito originou a regra;

  • quem solicitou a alteração;

  • quais impactos foram considerados;

  • quais sistemas dependem dela;

  • quais procedimentos operacionais existem;

  • como recuperar o sistema quando algo dá errado.

Imagine encontrar:

      * ALTERADO JOAO 14/06/2004

Excelente.

Descobrimos que João esteve ali.

Infelizmente, João não deixou pistas sobre aquilo que estava pensando.

Myne suspira.

Um livro que diz apenas:

“Capítulo alterado por João.”

não preserva conhecimento suficiente para reconstruir sua história.



🧠 CAPÍTULO 2 — A EMPRESA POSSUI UMA MEMÓRIA

Uma organização também possui memória.

Só que ela não fica em um único lugar.

Pode estar espalhada por:

Código-fonte
     │
     ├── COBOL
     ├── JCL
     ├── COPYBOOKS
     ├── procedimentos
     ├── tickets
     ├── diagramas
     ├── e-mails
     ├── Wikis
     ├── runbooks
     ├── atas
     ├── manuais
     └── pessoas

O último elemento merece atenção especial.

Imagine:

CONHECIMENTO DO SISTEMA XPTO

20% documentação
30% código
50% Carlos

Temos um problema.

Carlos pode:

  • sair da empresa;

  • mudar de departamento;

  • entrar de férias;

  • esquecer detalhes;

  • aposentar-se;

  • simplesmente não estar disponível durante um incidente.

Isso transforma Carlos em algo parecido com um Single Point of Failure humano.

Existe inclusive uma expressão informal usada em engenharia de software: bus factor.

Ela procura representar quantas pessoas poderiam ficar indisponíveis antes que um projeto perdesse conhecimento crítico.

Se a resposta for:

uma,

temos enorme concentração de conhecimento.

Myne ficaria horrorizada.

Para alguém que passou a vida tentando preservar livros, colocar conhecimento crítico exclusivamente na memória humana seria equivalente a possuir apenas um exemplar de um livro importantíssimo e guardá-lo ao lado de uma lareira.



⚔️ CAPÍTULO 3 — POR QUE PROGRAMADORES NÃO GOSTAM DE DOCUMENTAR?

Durante décadas, gestores perguntaram:

Como fazer os programadores documentarem?

É uma pergunta compreensível.

Mas pode ser a pergunta errada.

É fácil responder:

— Programador não gosta de escrever.

Alguns realmente não gostam.

Outros têm dificuldade para transformar raciocínio técnico em texto compreensível.

Mas existe um problema organizacional muito mais interessante.

Imagine dois programadores.

Programador A

Codificação ............ 8 horas
Testes ................. 3 horas
Documentação ........... 2 horas
-------------------------------
Total .................. 13 horas

Programador B

Codificação ............ 8 horas
Testes ................. 2 horas
Documentação ........... 0 horas
-------------------------------
Total .................. 10 horas

Se a empresa medir produtividade apenas pela velocidade da entrega, quem parece melhor?

B.

Portanto, não documentar pode ser perfeitamente racional dentro de um sistema de incentivos mal construído.

A empresa publica:

“Documentação é fundamental.”

Mas o projeto comunica:

PRAZO > DOCUMENTAÇÃO

E o funcionário aprende rapidamente qual regra realmente vale.

Myne percebe algo importante:

cultura organizacional não é aquilo que está escrito no manual. É aquilo que a organização recompensa, tolera e pune.



🏰 CAPÍTULO 4 — DOCUMENTAÇÃO NÃO DEVERIA SER UMA TAREFA POSTERIOR

Um projeto tradicional frequentemente funciona assim:

REQUISITO
    ↓
ANÁLISE
    ↓
DESENVOLVIMENTO
    ↓
TESTE
    ↓
PRODUÇÃO
    ↓
"Esquecemos da documentação."

Nesse modelo, documentação virou a última obrigação antes da libertação do programador.

Resultado?

Ele está cansado.

O prazo terminou.

Outro projeto já começou.

O gerente quer implantação.

E alguém pergunta:

— Você pode escrever o manual?

Nasce então o clássico:

MANUAL_SISTEMA_FINAL.DOC

Seguido, meses depois, por:

MANUAL_SISTEMA_FINAL2.DOC
MANUAL_SISTEMA_NOVO.DOC
MANUAL_SISTEMA_NOVO_FINAL.DOC
MANUAL_SISTEMA_NOVO_FINAL_OK.DOC

Isso não é versionamento.

É arqueologia digital.

A solução conceitual é colocar documentação dentro do ciclo de desenvolvimento:

REQUISITO
    ↓
DESIGN
    ↓
CÓDIGO
    +
DOCUMENTAÇÃO
    ↓
TESTE
    +
TESTE DA DOCUMENTAÇÃO
    ↓
REVIEW
    ↓
DEPLOY

Agora surge uma regra poderosa:

mudança no sistema pode significar mudança na documentação.

Não necessariamente toda alteração muda todo documento.

Mas toda alteração deveria provocar a pergunta:

Quais informações precisam ser atualizadas por causa desta mudança?


🔗 CAPÍTULO 5 — UMA ALTERAÇÃO COBOL NUNCA ESTÁ SOZINHA

O iniciante frequentemente imagina:

PROGRAMA COBOL

Mas sistemas corporativos são ecossistemas.

Uma alteração pode atingir:

REQUISITO
   │
   ├── COBOL
   ├── COPYBOOK
   ├── JCL
   ├── PROC
   ├── VSAM
   ├── Db2
   ├── CICS
   ├── MQ
   ├── API
   ├── batch
   ├── procedimento operacional
   ├── troubleshooting
   └── manual do usuário

Imagine aumentar um campo:

05 CLIENTE-ID PIC 9(06).

para:

05 CLIENTE-ID PIC 9(08).

Parece simples.

Mas Myne pergunta:

— O copybook compartilhado mudou?

— Sim.

— Arquivos VSAM?

— Talvez.

— Layout de interface?

— Sim.

— Programa consumidor?

— Também.

— Documentação?

Silêncio novamente.

Essa é a essência da análise de impacto.

Documentação não está fora do sistema.

Ela faz parte do conjunto de artefatos que descrevem o sistema.


🧙 CAPÍTULO 6 — MYNE DESCOBRE CONFIGURATION MANAGEMENT

Chegamos a um conceito importante para quem está começando no mainframe:

Configuration Management.

Simplificando bastante, Configuration Management procura responder perguntas como:

O que existe?
Qual versão existe?
Qual versão está em produção?
Quem alterou?
Quando alterou?
Por que alterou?
O que depende disso?
Qual era a configuração anterior?

Você provavelmente já percebeu que isso não interessa somente ao código.

Imagine:

RUNBOOK-PAGAMENTOS

Versão: 4.7
Sistema: PAY001
Owner: Payments Operations
Aprovador: Production Control
Última revisão: 23/09/2026
Próxima revisão: 23/03/2027
Change: CHG-98472
Status: APPROVED

Agora temos algo auditável.

Podemos perguntar:

Qual procedimento estava válido em 14 de março?

E recuperar aquela versão.

Essa capacidade é essencial.


💀 CAPÍTULO 7 — ÀS 03:17, A DOCUMENTAÇÃO VIRA PRODUÇÃO

03:17.

Sim, jovem padawan.

Você encontrou o easter egg.

O telefone toca.

INCIDENTE CRÍTICO
SISTEMA DE PAGAMENTOS

O operador consulta o procedimento.

1. Localizar JOB PAYR001.
2. Cancelar execução.
3. Executar PAYREC01.
4. Verificar mensagem PAY003I.

Ele está prestes a executar o passo 3 quando alguém grita:

— NÃO EXECUTA!

— Por quê?

— PAYREC01 foi aposentado.

— Quando?

— Ano passado.

— O procedimento manda executar.

Silêncio.

A documentação está oficialmente publicada.

Mas descreve um sistema que já não existe.

Temos então duas verdades:

VERDADE EXECUTÁVEL
        ≠
VERDADE DOCUMENTADA

Esse fenômeno poderia ser chamado de documentation drift ou deriva documental.

E aqui aparece uma conclusão contraintuitiva:

documentação errada pode ser pior que documentação inexistente.

Se não houver documentação, o operador sabe que precisa investigar.

Quando existe um procedimento aparentemente oficial, ele pode confiar nele.


🧪 CAPÍTULO 8 — DOCUMENTAÇÃO TAMBÉM PRECISA SER TESTADA

Essa ideia é extraordinariamente importante.

Considere:

1. Entre no SDSF.
2. Localize o job.
3. Execute comando X.
4. Confirme mensagem Y.
5. Reinicie componente Z.

Um especialista lê e afirma:

— Perfeito.

Mas entregue isso a alguém que nunca executou o procedimento.

Ele pergunta:

— Em qual painel?

— Como localizo o job?

— Qual comando?

— Onde aparece Y?

— E se Y não aparecer?

Descobrimos cinco buracos em trinta segundos.

Portanto, documentação operacional pode possuir algo parecido com teste funcional.

Uma pessoa representativa do público-alvo tenta realizar a tarefa utilizando somente as instruções.

Isso revela:

  • passos ausentes;

  • pressupostos ocultos;

  • terminologia inadequada;

  • ambiguidades;

  • comandos errados;

  • dependências não documentadas.

Myne aprovaria.

Não basta imprimir o livro.

Precisamos verificar se o leitor consegue utilizá-lo.


📚 CAPÍTULO 9 — MAIS DOCUMENTAÇÃO NÃO SIGNIFICA MELHOR DOCUMENTAÇÃO

Existe outra pergunta antiga:

Quanto devemos documentar?

Resposta errada:

Tudo.

Outra resposta errada:

O mínimo possível.

O objetivo é:

DOCUMENTAÇÃO NECESSÁRIA
        +
CORRETA
        +
ATUAL
        +
ENCONTRÁVEL
        +
COMPREENSÍVEL
        +
ADEQUADA À TAREFA

Um manual de 900 páginas pode ser praticamente inútil durante um incidente.

O operador talvez precise de duas páginas.

Diferentes necessidades exigem diferentes documentos:

NecessidadeInformação
compreender arquiteturaArchitecture Overview
desenvolverDeveloper Guide
operarRunbook
investigar falhaTroubleshooting Guide
integrarInterface/API Specification
recuperar desastreDisaster Recovery Procedure
utilizar aplicaçãoUser Guide
modificarDesign/Change Documentation
aprender sistemaOnboarding Guide
auditarevidências e histórico

A antiga ideia de colocar tudo no gigantesco Manual do Sistema frequentemente cria documentos impossíveis de consumir.


🗺️ CAPÍTULO 10 — DOCUMENTAÇÃO PRECISA SER ENCONTRÁVEL

Myne finalmente recebe uma boa notícia.

— Temos documentação!

— Onde?

— Share.

— Qual?

— Não lembro.

— Nome?

— Alguma coisa como PAY...

Depois de vinte minutos:

\\server\departamento\projetos\old\sistemas\pagamentos\
documentacao\backup\antigo\

Myne quase desmaia.

Informação que existe mas não pode ser encontrada possui valor operacional próximo de zero.

Portanto, governança documental envolve também:

  • taxonomia;

  • pesquisa;

  • nomes consistentes;

  • metadados;

  • owners;

  • classificação;

  • links;

  • relacionamentos;

  • controle de versão.

Bibliotecas descobriram isso séculos atrás.

Não basta possuir livros.

Precisamos saber onde eles estão e como encontrá-los.


🏛️ CAPÍTULO 11 — CENTRALIZAR OU DESCENTRALIZAR?

O problema já existia décadas atrás.

Deveríamos possuir um departamento central de documentação?

Ou documentadores dentro das equipes?

Centralizado

          DOCUMENTAÇÃO
               │
     ┌─────────┼─────────┐
     ↓         ↓         ↓
 SISTEMA A  SISTEMA B  SISTEMA C

Excelente para:

  • padrões;

  • qualidade;

  • independência;

  • governança;

  • consistência.

Mas pode ficar distante da tecnologia.

Descentralizado

TIME A → documentação A
TIME B → documentação B
TIME C → documentação C

Excelente proximidade.

Mas pode produzir três dialetos diferentes.

Uma solução interessante é o modelo federado:

          GOVERNANÇA CENTRAL
                 │
       padrões e ferramentas
                 │
       ┌─────────┼─────────┐
       ↓         ↓         ↓
     TIME A    TIME B    TIME C
       │         │         │
     OWNER     OWNER     OWNER

O centro define regras.

As equipes preservam conhecimento local.


👑 CAPÍTULO 12 — TODO DOCUMENTO PRECISA DE UM DONO

Uma regra simples evita enorme quantidade de caos:

todo documento relevante deve possuir owner.

Owner não significa necessariamente autor.

O owner responde pela validade.

Pense assim:

DOCUMENTO
   ↓
OWNER
   ↓
REVISÃO
   ↓
APROVAÇÃO
   ↓
PUBLICAÇÃO
   ↓
USO
   ↓
NOVA REVISÃO
   ↓
ARQUIVAMENTO

Documento sem proprietário tende a virar órfão.

E órfãos digitais envelhecem silenciosamente.


🧹 CAPÍTULO 13 — DOCUMENTO OBSOLETO PRECISA MORRER

Esse ponto é pouco discutido.

Criar documentação é importante.

Mas aposentar documentação também é.

Imagine encontrar:

RUNBOOK-PAY-2019
RUNBOOK-PAY-2021
RUNBOOK-PAY-NOVO
RUNBOOK-PAY-FINAL
RUNBOOK-PAY-ATUAL

Qual é válido?

Se ninguém souber, temos risco operacional.

Um processo maduro deveria permitir estados como:

DRAFT
REVIEW
APPROVED
PUBLISHED
SUPERSEDED
ARCHIVED

Assim sabemos que determinado documento existe historicamente, mas não deve mais orientar operações atuais.

Myne chamaria isso de diferença entre:

arquivo histórico e livro de uso corrente.


💳 CAPÍTULO 14 — DÍVIDA DOCUMENTAL

Programadores conhecem Technical Debt.

Mas existe outra dívida:

Documentation Debt.

Toda mudança não refletida na documentação cria um pequeno débito.

No começo ninguém percebe.

Mudança 1 → documento quase correto
Mudança 2 → pequeno erro
Mudança 3 → faltam dois procedimentos
Mudança 4 → diagrama incorreto
Mudança 5 → ninguém confia mais

Finalmente acontece algo curioso:

“Não consulte a Wiki porque está desatualizada.”

Pronto.

A organização perdeu confiança em seu próprio repositório de conhecimento.

Podemos imaginar:

Documentation Debt ↑

MTTR ↑
Onboarding ↑
Dependência de especialistas ↑
Retrabalho ↑
Risco operacional ↑
Risco de auditoria ↑

O custo economizado ontem reaparece com juros.


🔍 CAPÍTULO 15 — ENTRA O AUDITOR

Agora o auditor chega.

Um auditor fraco pergunta:

— Vocês possuem documentação?

A equipe mostra cinquenta PDFs.

Check.

Auditor satisfeito.

Myne não.

Um auditor melhor pergunta:

“Mostre uma alteração recente em produção.”

Escolhemos:

CHG-98472

Agora reconstruímos:

REQUISITO
    ↓
ANÁLISE
    ↓
CHANGE
    ↓
ALTERAÇÃO COBOL
    ↓
TESTE
    ↓
APROVAÇÃO
    ↓
DEPLOY
    ↓
DOCUMENTAÇÃO
    ↓
COMUNICAÇÃO

Depois fazemos o contrário.

Escolhemos um programa em produção:

PAYB0031

E perguntamos:

Qual versão?
Qual change colocou isso aqui?
Quem aprovou?
Quais testes existem?
Qual requisito originou?
Qual documentação foi atualizada?

Isso é rastreabilidade.

Não estamos procurando papel.

Estamos procurando evidência de controle.


⚔️ CAPÍTULO 16 — O AUDITOR PROCURA A EMPRESA REAL

Existe uma diferença fundamental entre:

PROCESSO DOCUMENTADO

e:

PROCESSO REAL

O manual diz:

Em incidentes críticos consultar RUNBOOK-PAY.

O auditor entrevista operadores.

— O que você faz quando PAY cai?

— Chamo o Zé.

— E o runbook?

— Ah... aquilo está velho.

Bingo.

Encontramos uma diferença entre governança formal e comportamento operacional.

A empresa pensa que possui:

INCIDENTE
   ↓
RUNBOOK
   ↓
RESOLUÇÃO

Na realidade possui:

INCIDENTE
   ↓
WhatsApp
   ↓
"CHAMA O ZÉ"

Zé virou middleware humano.

E não possui redundância.


🤖 CAPÍTULO 17 — MYNE CONHECE A INTELIGÊNCIA ARTIFICIAL

Então chega 2026.

Myne encontra uma máquina extraordinária.

Ela recebe:

  • COBOL;

  • JCL;

  • copybooks;

  • diagramas;

  • tickets;

  • commits;

  • logs.

E produz explicações.

— Ela escreve livros?!

Quase.

IA generativa pode ajudar enormemente na documentação.

Por exemplo, pode transformar:

       EVALUATE WS-STATUS
          WHEN 'A'
             PERFORM 1000-ATIVO
          WHEN 'B'
             PERFORM 2000-BLOQUEADO
          WHEN OTHER
             PERFORM 9000-ERRO
       END-EVALUATE.

em uma explicação preliminar.

Pode ainda:

  • resumir código;

  • explicar campos;

  • gerar diagramas preliminares;

  • converter tickets em release notes;

  • comparar versões;

  • identificar documentação possivelmente afetada;

  • criar perguntas para revisão;

  • produzir rascunhos de runbooks.

Fantástico.

Mas existe uma armadilha gigantesca.


☠️ CAPÍTULO 18 — IA PODE DOCUMENTAR PERFEITAMENTE UMA COISA ERRADA

Imagine a IA afirmar:

“O campo E representa cliente empresarial.”

Texto bonito.

Gramática impecável.

Completamente errado.

Na verdade:

E = CLIENTE ESPECIAL

Esse é um novo tipo de risco.

Antigamente tínhamos documentação ruim obviamente ruim.

Agora podemos possuir documentação errada extremamente convincente.

Portanto:

IA
 ↓
RASCUNHO
 ↓
SME TÉCNICO
 ↓
USUÁRIO
 ↓
VALIDAÇÃO
 ↓
APROVAÇÃO
 ↓
PUBLICAÇÃO

Nunca:

IA
 ↓
PRODUÇÃO

A inteligência artificial reduz o custo de produção.

Ela não transfere responsabilidade pela verdade.


🧰 CAPÍTULO 19 — DOCUMENTATION AS CODE

Agora Myne encontra Git.

E quase pede Ferdinand em casamento novamente.

Porque finalmente os livros possuem histórico automático.

Podemos organizar:

docs/
├── architecture/
├── development/
├── operations/
├── troubleshooting/
├── interfaces/
└── security/

Uma alteração começa:

git checkout -b CHG-98472

O programador altera:

src/PAYB0031.cbl

e também:

docs/operations/payment-runbook.md

Então:

CODE
  +
DOC
  ↓
PULL REQUEST
  ↓
REVIEW
  ↓
PIPELINE
  ↓
RELEASE

Isso é poderoso porque aproxima documentação do mesmo fluxo utilizado pelo software.

Temos:

  • versionamento;

  • histórico;

  • autoria;

  • comparação;

  • revisão;

  • aprovação;

  • automação.

Código e conhecimento começam a viajar juntos.


🧪 CAPÍTULO 20 — UM PASSO A PASSO PARA O PROGRAMADOR COBOL

Você recebeu uma alteração.

Não pense apenas:

“Qual linha COBOL vou mudar?”

Faça algo parecido com isto.

Passo 1 — descubra o motivo

Pergunte:

Qual problema estamos resolvendo?

Passo 2 — descubra o impacto

Liste:

COBOL?
COPYBOOK?
JCL?
Db2?
VSAM?
CICS?
MQ?
API?
batch?
usuário?
operação?

Passo 3 — localize documentação relacionada

Procure:

Architecture
Developer Guide
Runbook
Interface Specification
User Guide
Troubleshooting

Passo 4 — altere código e conhecimento juntos

Não espere três meses.

Passo 5 — teste ambos

O programa funciona?

A instrução também?

Passo 6 — peça revisão

Técnico revisa tecnologia.

Usuário revisa significado.

Operação revisa execução.

Passo 7 — preserve rastreabilidade

Relacione:

REQUISITO → CHANGE → CÓDIGO → TESTE → DOCUMENTAÇÃO

Passo 8 — retire informação obsoleta

Não deixe armadilhas históricas disponíveis como instrução atual.


🧙‍♀️ CAPÍTULO 21 — MYNE CRIA AS DEZ REGRAS DA BIBLIOTECA DO MAINFRAME

Depois de observar aquela organização, Myne escreve:

I. Código não substitui contexto.

II. Toda mudança deve avaliar impacto documental.

III. Todo documento crítico precisa de owner.

IV. Documentação precisa possuir versão.

V. Informação precisa ser encontrável.

VI. Procedimentos críticos precisam ser testados.

VII. Documento obsoleto precisa ser claramente aposentado.

VIII. IA pode escrever rascunhos; humanos continuam responsáveis pela verdade.

IX. Conhecimento crítico não pode existir somente na cabeça de uma pessoa.

X. Documentação faz parte do produto.

Ferdinand lê.

Fica em silêncio.

— Onze regras seriam mais completas.

Myne fecha o livro.

— Dez ficam melhores num slide.


☕ EPÍLOGO — O ÚLTIMO LIVRO DE CARLOS

Alguns meses depois, Carlos anunciou aposentadoria.

Ninguém entrou em pânico.

Durante meses, a equipe havia transformado seu conhecimento em:

Architecture Guides
Runbooks
Troubleshooting Guides
Decision Records
Diagramas
README
Procedimentos
Histórico de mudanças

Mais importante: outras pessoas haviam utilizado e testado aquele conhecimento.

No último dia, Carlos deixou sobre a mesa uma pequena folha.

Myne encontrou.

Nela estava escrito:

03:17

Se PAYB0031 apresentar S0C7 depois do fechamento,
não reinicie imediatamente.

Verifique primeiro o arquivo PAY.IN.TRANS.

E não acredite no procedimento de 2019.

Myne sorriu.

Digitalizou a informação.

Criou um ticket.

Atualizou o troubleshooting.

Relacionou ao sistema.

Mandou revisar.

E destruiu a folha.

Porque finalmente aquela empresa havia compreendido algo que bibliotecários sabem há séculos:

conhecimento que não pode ser encontrado não está verdadeiramente disponível.

Conhecimento que não pode ser verificado não é confiável.

Conhecimento que depende de uma única pessoa não pertence realmente à organização.

E conhecimento que não acompanha a evolução do sistema lentamente se transforma em ficção.

Para um programador COBOL iniciante, talvez essa seja uma das lições mais importantes da carreira.

Você não herdará apenas programas.

Herdará decisões tomadas por pessoas que talvez nunca conheça.

Encontrará campos criados antes de você nascer.

COPYBOOKs compartilhados por dezenas de aplicações.

JCLs cujo comentário mais recente terá quinze anos.

Regras de negócio que sobreviveram a três presidentes da empresa, quatro arquiteturas e seis gerações de programadores.

Um dia alguém também encontrará o seu código.

E encontrará algo como:

      *---------------------------------------------------------*
      * CHG-98472 - 23/09/2026                                 *
      * ALTERADA REGRA DE CLIENTE ESPECIAL.                    *
      * MOTIVO: NOVA REGRA CONTRATUAL.                          *
      * DOCUMENTACAO: DOC/PAYMENTS/RULES-CLIENTE-ESPECIAL.MD    *
      *---------------------------------------------------------*

Essa pessoa talvez nunca saiba seu nome.

Mas saberá por que aquilo existe.

E existe algo profundamente bonito nisso.

Porque mainframes são máquinas construídas para sobreviver ao tempo.

COBOL também.

Mas sistemas de cinquenta anos não sobrevivem apenas porque o hardware continua funcionando.

Eles sobrevivem porque sucessivas gerações de profissionais conseguem receber, compreender, modificar e transmitir conhecimento.

Somos temporários.

O sistema pode continuar.

O código fica.

As decisões ficam.

A documentação deveria ficar também.

E talvez Myne, olhando para milhões de linhas COBOL preservadas durante décadas, finalmente percebesse que havia encontrado uma biblioteca muito diferente daquela que sempre sonhou construir.

Uma biblioteca na qual alguns livros são executáveis.

E onde esquecer de atualizar uma página pode, às 03:17 da manhã, derrubar produção.

Bem-vindo à Biblioteca do Mainframe.

Seu próximo commit também é uma página da história.

🏴‍☠️ JACK SPARROW E A ROTA PIRATA DOS BITS — QUANDO O TK85 DESCOBRIU QUE A INTERNET DOS ANOS 80 VIAJAVA DE K7

 

Bellacosa Mainframe e os primórdios da informatica

☕ Um Café no Bellacosa Mainframe

🏴‍☠️ JACK SPARROW E A ROTA PIRATA DOS BITS — QUANDO O TK85 DESCOBRIU QUE A INTERNET DOS ANOS 80 VIAJAVA DE K7

TK85, Z80, Pimania, fitas cassete, BASIC, Assembler, revistas, Galeria Pagé, Xavier de Toledo, Reserva de Mercado, Amazônia e a extraordinária rede humana que transportava software pelo planeta muito antes da Internet.



🎬 PRÓLOGO — JACK SPARROW ENCONTROU UMA FITA K7

Imagine que estamos em São Paulo, em algum momento dos anos 1980.

Não existe Google.

Não existe GitHub.

Não existe Steam.

Não existe fibra óptica chegando à sua casa.

Não existe pip install.

Não existe Stack Overflow.

Aliás, se você disser "download", provavelmente alguém vai perguntar que palavra inglesa estranha é essa.

Nosso jovem programador COBOL entra no centro de São Paulo acompanhado de seu improvável mentor:

Capitão Jack Sparrow.

Jack aponta para uma pequena fita cassete.

— Está vendo isso?

— Uma fita K7.

— Errado. Isto é um navio.

— Capitão, é uma fita.

— Todo objeto capaz de transportar um tesouro é um navio.

E naquele pequeno pedaço de plástico realmente poderiam estar escondidos jogos, programas, utilitários, aventuras e algumas centenas ou milhares de linhas de código.

Talvez até um jogo britânico chamado:

Pimania.

Um programa capaz de transportar um garoto brasileiro, através de um TK85, até um misterioso cavalo branco desenhado numa colina inglesa.

Prepare o café.

Aperte PLAY.

Digite:

LOAD ""

Nossa aventura começou.



🏴‍☠️ CAPÍTULO 1 — ANTES DA INTERNET, OS BITS TAMBÉM VIAJAVAM

Existe uma ideia equivocada de que antes da Internet os países tecnologicamente distantes viviam praticamente isolados.

Não era assim.

O mundo dos anos 1980 já possuía uma extensa rede internacional formada por:

  • aviação;

  • correios;

  • empresas multinacionais;

  • revistas;

  • livros;

  • emigrantes;

  • estudantes;

  • turistas;

  • tripulantes;

  • pilotos;

  • executivos;

  • comerciantes;

  • clubes de usuários.

A diferença estava principalmente na latência e na largura de banda.

Hoje podemos transferir gigabytes entre Londres e São Paulo em minutos.

Naquela época, um programa poderia viajar assim:

LONDRES
   |
   v
FITA K7
   |
   v
MALA DE UM VIAJANTE
   |
   v
AVIÃO
   |
   v
SÃO PAULO
   |
   v
CÓPIA
   |
   +----> amigo
   |
   +----> loja
   |
   +----> clube
   |
   +----> outra cidade

Não havia TCP/IP.

Mas havia pessoas.

Jack Sparrow chamaria isso de:

rede distribuída baseada em rum.

Um engenheiro provavelmente chamaria de supply chain informal de informação.






🧠 CAPÍTULO 2 — LATÊNCIA NÃO É LARGURA DE BANDA

Para nosso iniciante COBOL, aqui existe um conceito importante.

Imagine um sistema bancário.

Uma transação MQ pode chegar ao destino rapidamente, mas isso não significa necessariamente que o canal tenha enorme capacidade.

São conceitos diferentes:

latência mede quanto tempo uma informação leva para chegar.

throughput mede quanto conseguimos transmitir em determinado intervalo.

Uma comissária de bordo poderia comprar uma fita em Londres e estar em São Paulo poucos dias depois.

Latência:

surpreendentemente pequena.

Mas ela talvez trouxesse apenas algumas fitas e revistas.

Throughput:

minúsculo comparado à Internet atual.

Nosso backbone era literalmente um Boeing.

EUROPA
   |
   |  K7
   |
   v
[ BOEING ]
   |
   v
BRASIL

Depois que a primeira cópia chegava, entretanto, começava a replicação.

Era quase um BitTorrent humano.



📼 CAPÍTULO 3 — O K7 ERA O PENDRIVE DOS ANOS 80

Para quem começou a programar décadas depois, pode parecer estranho armazenar programas numa fita cassete.

Mas computadores como o Sinclair ZX81 e seus parentes utilizavam gravadores domésticos como armazenamento.

O programa era convertido em sinais de áudio.

O computador enviava esses sinais para o gravador.

Para salvar:

COMPUTADOR
    |
    v
SINAL ELÉTRICO
    |
    v
ÁUDIO
    |
    v
FITA MAGNÉTICA

Para carregar, acontecia o processo inverso.

O resultado era uma experiência que exigia paciência.

Volume errado?

Erro.

Cabeçote desalinhado?

Erro.

Fita deteriorada?

Erro.

Cópia da cópia da cópia?

Boa sorte.

Era o equivalente oitentista a assistir:

DOWNLOAD: 99%

durante vinte minutos e depois receber:

NETWORK ERROR

Só que o erro vinha acompanhado de chiados.



🖥️ CAPÍTULO 4 — SURGE O TK85

No Brasil tivemos diversos computadores inspirados ou compatíveis com arquiteturas estrangeiras.

Um dos mais famosos foi o:

TK85, da Microdigital.

Ele pertencia ao universo tecnológico derivado do Sinclair ZX81 e utilizava o lendário processador:

Zilog Z80.

O Z80 era uma CPU de 8 bits.

Isso significa, simplificando bastante, que sua arquitetura trabalhava naturalmente com unidades de dados de oito bits.

Um byte:

10110110

Oito bits.

Para nosso COBOL iniciante, pense assim:

COBOL esconde grande parte da máquina.

Você escreve:

ADD 1 TO WS-CONTADOR.

O compilador resolve como isso será transformado em instruções.

No Assembler Z80 você estava muito mais perto do hardware:

INC A

ou:

LD A,10
ADD A,5

O programador precisava compreender registradores, memória, endereços e flags.

Era outro mundo.


🧙 CAPÍTULO 5 — BASIC ERA A PORTA DA DUNGEON

Muitos computadores domésticos iniciavam diretamente em BASIC.

Você ligava a máquina e praticamente recebia:

Programe alguma coisa.

Isso produziu uma geração muito peculiar.

O usuário começava querendo jogar.

Encontrava:

10 PRINT "BELLACOSA"
20 GOTO 10

Executava.

Depois pensava:

E se eu mudar?

Pronto.

Nascia um programador.

Talvez alterasse:

100 LET LIVES=3

para:

100 LET LIVES=99

Primeiro hack.

Depois modificava a velocidade.

Depois queria criar uma fase.

Depois descobria POKE.

Depois perguntava por que BASIC era lento.

Então alguém dizia:

Você precisa aprender Assembler.

Jack Sparrow sorria.

O garoto acabara de entrar em águas profundas.


📰 CAPÍTULO 6 — A REVISTA ERA O GITHUB IMPRESSO

Outro mecanismo extraordinário de distribuição eram as revistas.

Elas publicavam programas completos.

Sim.

Código-fonte em papel.

Imagine encontrar:

10 CLS
20 PRINT "AMAZONIA"
30 INPUT A$
40 IF A$="NORTE" THEN GOTO 200

Você precisava digitar aquilo manualmente.

Portanto:

AUTOR
   |
   v
REVISTA
   |
   v
GRÁFICA
   |
   v
BANCA
   |
   v
LEITOR
   |
   v
TECLADO
   |
   v
RAM

O usuário era o dispositivo de entrada.

E havia um mecanismo sofisticadíssimo de detecção de erros chamado:

o programa não funciona.

Você voltava para a revista procurando:

O ou 0?

1 ou I?

8 ou B?

Era debugging antes mesmo de compreender que aquilo era debugging.


🇧🇷 CAPÍTULO 7 — MICRO SISTEMAS E A FORMAÇÃO DOS PROGRAMADORES

No Brasil, revistas como Micro Sistemas tiveram importância enorme.

Não eram simplesmente publicações sobre computadores.

Funcionavam como:

REVISTA
+
CURSO
+
REPOSITÓRIO
+
DOCUMENTAÇÃO
+
COMUNIDADE
+
CATÁLOGO

Uma única edição podia ensinar BASIC, publicar uma listagem, discutir hardware e apresentar um programa novo.

Isso criava uma relação completamente diferente com software.

Hoje:

DOWNLOAD
INSTALL
PLAY

Naquele universo:

COMPRAR REVISTA
     |
     v
LER
     |
     v
DIGITAR
     |
     v
ERRAR
     |
     v
DEBUGAR
     |
     v
ENTENDER
     |
     v
MODIFICAR

A fricção educava.


🌴 CAPÍTULO 8 — AMAZÔNIA: QUANDO O BRASIL CRIOU SUA PRÓPRIA AVENTURA

É nesse ambiente que aparece um personagem fundamental:

Renato Degiovani.

Em 1983 ele publica Aventuras na Selva, originalmente em BASIC para a família ZX81.

Depois essa experiência evoluiria para:

AMAZÔNIA.

O significado histórico é enorme.

Até então muito do imaginário computacional chegava do exterior.

Mas agora um computador daquela família tecnológica poderia executar uma aventura ambientada no próprio Brasil.

Em vez de castelos ingleses:

selva.

Em vez de cavaleiros:

sobrevivência.

Em vez de importar exclusivamente imaginários estrangeiros, começávamos a produzir os nossos.

O processador continuava sendo Z80.

Mas software possui cultura.


🧠 CAPÍTULO 9 — UMA ADVENTURE É UMA MÁQUINA DE ESTADOS

Aqui nosso programador COBOL pode compreender tecnicamente o que está acontecendo.

Imagine:

01 WS-GAME.
   05 WS-LOCAL          PIC 99.
   05 WS-TEM-CHAVE      PIC X VALUE 'N'.
   05 WS-TEM-CORDA      PIC X VALUE 'N'.
   05 WS-VIDAS          PIC 99 VALUE 03.

O jogador digita:

PEGAR CORDA

O programa altera:

WS-TEM-CORDA = 'S'

Depois:

IR NORTE

O estado muda.

Uma adventure textual é essencialmente:

ESTADO ATUAL
     +
COMANDO
     |
     v
REGRA
     |
     v
NOVO ESTADO

É praticamente uma máquina de estados.

COBOL conseguiria implementar isso perfeitamente.


🥧 CAPÍTULO 10 — PIMANIA E O TESOURO FORA DO COMPUTADOR

Agora aparece nosso jogo mítico.

Pimania, lançado pela Automata UK em 1982.

Era uma aventura para computadores como ZX81 e Spectrum.

Mas possuía uma característica extraordinária:

existia um prêmio real.

As pistas existentes no programa levavam o jogador para fora do computador.

O objetivo final estava relacionado ao:

Litlington White Horse

um enorme cavalo desenhado no giz de uma colina inglesa.

O jogo misturava:

  • matemática;

  • trocadilhos;

  • geografia;

  • cultura britânica;

  • observação;

  • lógica;

  • pistas visuais.

Uma delas explorava:

22 / 7

que é uma conhecida aproximação de:

π

E também podia representar:

22 de julho.

Pi.

Pimania.

Nada estava ali por acidente.


🐴 CAPÍTULO 11 — O COMPUTADOR NÃO PRECISAVA ARMAZENAR A INGLATERRA

Essa talvez seja a maior lição técnica de Pimania.

Um computador de memória minúscula não precisava armazenar um gigantesco mundo tridimensional.

Ele armazenava:

pistas.

O resto estava no cérebro.

16 KB
   |
   v
PISTA
   |
   v
CÉREBRO
   |
   v
ENCICLOPÉDIA
   |
   v
MAPA
   |
   v
INGLATERRA

Portanto o verdadeiro armazenamento do jogo era distribuído.

Parte estava na RAM.

Parte na fita.

Parte na documentação.

Parte na cultura do jogador.

Parte no mundo real.

Quarenta anos depois chamaríamos algo parecido de experiência transmídia ou ARG.

Eles simplesmente fizeram.


🏴‍☠️ CAPÍTULO 12 — MAS COMO PIMANIA CHEGOU AO BRASIL?

Aqui começa outra aventura.

Não sabemos qual foi exatamente a rota da cópia específica lembrada nesta história.

Mas sabemos que existiam múltiplas portas de entrada.

Software podia chegar através de:

  • Correios;

  • viajantes;

  • pilotos;

  • comissários;

  • filhos de funcionários de companhias aéreas;

  • executivos;

  • brasileiros residentes no exterior;

  • turistas;

  • comerciantes.

Mais tarde, a grande comunidade brasileira no Japão adicionaria outra importante rota humana.

Portanto:

INGLATERRA
   |
   +---- CORREIO
   |
   +---- PILOTO
   |
   +---- TRIPULANTE
   |
   +---- VIAJANTE
   |
   +---- AMIGO
          |
          v
       BRASIL

O mundo já era globalizado.

A Internet apenas mudaria radicalmente a escala.


🏙️ CAPÍTULO 13 — XAVIER DE TOLEDO: O FÓRUM PRESENCIAL

No centro de São Paulo existiam pontos nos quais usuários conseguiam adquirir K7 com software, trocar informações e encontrar outras pessoas da comunidade.

A região da Xavier de Toledo aparece nesta memória como um desses hubs.

E a palavra importante é:

hub.

Não era apenas comprar.

Era:

COMPRAR
+
CONVERSAR
+
PERGUNTAR
+
APRENDER
+
CONHECER PESSOAS
+
TROCAR INFORMAÇÕES

Alguém podia perguntar:

Como passo daquela parte?

Outro respondia.

Era Stack Overflow sem Stack Overflow.

Discord sem Discord.

Reddit sem Reddit.

A rede era humana.

E amizades surgiam dessas conexões.

Algumas duravam anos.

Isso raramente aparece numa imagem .TAP preservada atualmente.

O arquivo conserva os bytes.

Não conserva as pessoas que os transportaram.


🏢 CAPÍTULO 14 — JACK SPARROW ENTRA NA GALERIA PAGÉ

Agora nosso capitão precisa de hardware.

Existe Reserva de Mercado.

Existem restrições.

Existem dificuldades de importação.

Jack pergunta:

— Então ninguém consegue comprar equipamento estrangeiro?

O programador brasileiro começa a rir.

Bem-vindo à:

GALERIA PAGÉ.

A Pagé tornou-se lendária no imaginário paulistano como lugar de produtos importados, eletrônicos e novidades.

Você entrava procurando uma coisa.

Saía conhecendo cinco tecnologias que nem sabia que existiam.

Era uma espécie de marketplace físico.

Só que o algoritmo de recomendação era:

subir mais um andar.


🇧🇷 CAPÍTULO 15 — A RESERVA DE MERCADO

A política brasileira de informática buscava estimular e proteger a indústria nacional.

A lógica simplificada era:

LIMITAR IMPORTAÇÕES
        |
        v
PROTEGER EMPRESAS NACIONAIS
        |
        v
DESENVOLVER TECNOLOGIA LOCAL

Isso produziu resultados complexos.

Por um lado, surgiu indústria brasileira, empresas, técnicos e máquinas nacionais.

Por outro, determinados produtos estrangeiros eram difíceis ou caros de obter oficialmente.

E tecnologia possui um problema para qualquer barreira:

as pessoas sabem que existe algo melhor do outro lado.

Revistas mostravam.

Viajantes contavam.

Empresas utilizavam.

Então surgia a pergunta mais brasileira possível:

Conhece alguém que consegue?


🧙 CAPÍTULO 16 — A API “CONHEÇO UM CARA”

Podemos documentar tecnicamente:

CALL 'CONHECO-UM-CARA'
   USING WS-PRODUTO
         WS-PAIS
         WS-URGENCIA.

😂

Era uma API extremamente resiliente.

Precisava de uma placa?

Alguém conhecia alguém.

Precisava de software?

Outro conhecia um tripulante.

Precisava de revista?

Fulano estava viajando.

Precisava de videogame?

Alguém conhecia a Pagé.

Essa rede social invisível reduzia consideravelmente a latência tecnológica brasileira.


⚓ CAPÍTULO 17 — A PRIMEIRA CÓPIA ERA O SEED

Para compreender a distribuição informal, imagine BitTorrent.

A parte difícil era obter o primeiro arquivo.

Depois:

ORIGINAL
   |
   +---- COPY A
   |
   +---- COPY B
   |
   +---- COPY C

Cada cópia poderia gerar outras.

Portanto, uma única fita que chegasse de Londres poderia rapidamente alimentar uma comunidade.

É claro que isso levantava problemas jurídicos de direitos autorais.

Mas historicamente também precisamos reconhecer o efeito tecnológico dessa circulação informal: software chegava a lugares onde a distribuição oficial simplesmente não chegava.

Por isso:

vendas ≠ jogadores.

Um jogo que vendeu uma unidade poderia ser experimentado por dezenas de pessoas.


🏴‍☠️ CAPÍTULO 18 — JACK SPARROW EXPLICA COPYRIGHT

Jack levanta a mão:

— Finalmente chegamos à minha especialidade.

Não, Jack.

Piratas marítimos e pirataria de software são coisas diferentes.

Mas existe uma discussão histórica interessante.

Para muitos usuários dos anos 1980, copiar uma fita parecia culturalmente semelhante a:

  • gravar música do rádio;

  • copiar LP;

  • emprestar livro;

  • trocar cassete.

A indústria de software ainda estava consolidando modelos de licenciamento e distribuição para consumidores domésticos.

Isso não tornava automaticamente a cópia autorizada.

Mas explica parte do comportamento social.

Tecnologia frequentemente surge antes das normas culturais estabilizarem.


🔧 CAPÍTULO 19 — A DIFICULDADE CRIOU TÉCNICOS

Agora imagine importar um equipamento.

Ele quebra.

Você procura:

ASSISTÊNCIA TÉCNICA AUTORIZADA

Não existe.

Então alguém abre.

Mede.

Testa.

Solda.

Substitui.

Adapta.

Documenta.

E aprende.

Essa necessidade ajudou a alimentar uma cultura extremamente prática de eletrônica e engenharia reversa.

O técnico não podia simplesmente trocar a motherboard inteira.

Precisava descobrir:

Onde está o defeito?

Essa mentalidade tem enorme relação com mainframe.

Quem trabalha com sistemas críticos sabe:

entender o sistema é diferente de simplesmente substituir o sistema.


🖥️ CAPÍTULO 20 — SANTA IFIGÊNIA E A PRÓXIMA ERA

Com a abertura econômica e o fim da Reserva de Mercado no começo dos anos 1990, o ecossistema mudou.

A região da Santa Ifigênia tornou-se fortemente associada à informática.

Agora nossa dungeon tinha:

386
486
RAM
HDD
SVGA
MODEM
SOUNDBLASTER
CD-ROM

E apareceu uma criatura tipicamente brasileira:

PC MONTADO.

Fabricante:

ninguém sabe.

Placa-mãe de um lugar.

Memória de outro.

Gabinete de outro.

HD de outro.

Tudo funcionando junto.

Era arquitetura aberta aplicada com entusiasmo.


🧠 CAPÍTULO 21 — O QUE TUDO ISSO TEM A VER COM MAINFRAME?

Muito.

A primeira conexão é:

ABSTRAÇÃO.

O usuário moderno vê:

DOWNLOAD

Mas abaixo existem:

HTTP
TCP
IP
ROTEAMENTO
FIBRA
SWITCHES
SERVIDORES
STORAGE

Nos anos 1980 o usuário via:

K7

Mas abaixo existia:

PESSOA
AVIÃO
CORREIO
LOJA
CÓPIA
COMUNIDADE

Todo sistema possui camadas invisíveis.

No mainframe acontece exatamente isso.

O usuário executa uma transação CICS.

Por trás:

CICS
   |
   +-- COBOL
   |
   +-- Db2
   |
   +-- VSAM
   |
   +-- MQ
   |
   +-- RACF
   |
   +-- z/OS
   |
   +-- WLM

O bom profissional aprende a enxergar as camadas.


⚔️ CAPÍTULO 22 — SEGUNDA LIÇÃO: COMPATIBILIDADE VALE OURO

O ecossistema ZX81/TK85 mostra como compatibilidade cria mercados.

Se máquinas conseguem executar software semelhante, surge um ecossistema.

Mainframe conhece isso melhor do que quase qualquer plataforma.

Programas COBOL escritos décadas atrás continuam existindo porque existe uma obsessão histórica com compatibilidade.

Hardware muda.

Sistema operacional muda.

Compilador muda.

Storage muda.

Mas o investimento em software não pode simplesmente desaparecer.

Isso é engenharia econômica, não nostalgia.


🧩 CAPÍTULO 23 — TERCEIRA LIÇÃO: SOFTWARE É MAIS QUE CÓDIGO

Quando encontramos hoje:

PIMANIA.TAP

temos o software.

Mas perdemos:

  • quem trouxe;

  • quem copiou;

  • onde comprou;

  • quem ensinou;

  • quem explicou;

  • qual revista comentou;

  • qual amigo indicou;

  • quais soluções circularam.

Isso deveria ensinar algo ao programador COBOL.

Um sistema corporativo também é:

CÓDIGO
+
DOCUMENTAÇÃO
+
HISTÓRIA
+
REGRAS
+
PESSOAS
+
PROCESSOS

Apagar as pessoas da história de um sistema é perder metade da arquitetura.


🐴 CAPÍTULO 24 — O EASTER EGG DO CAVALO BRANCO

Voltemos finalmente a Pimania.

Um pequeno programa britânico entra no ecossistema ZX81.

Cruza fronteiras.

Pode ser copiado.

Chega a computadores brasileiros compatíveis.

E deixa na memória de alguém uma imagem:

um cavalo branco numa montanha inglesa.

Décadas passam.

Computadores tornam-se milhões de vezes mais poderosos.

Chega a Internet.

Chega Google.

Chega IA.

E em 2026 aquela lembrança ainda existe.

Isso nos ensina algo importante sobre desenvolvimento.

O objetivo final de software não é consumir CPU.

É produzir efeito humano.

Pimania precisava de alguns kilobytes para criar uma memória que sobreviveria por mais de quarenta anos.

Isso é performance.


🏴‍☠️ CAPÍTULO 25 — JACK SPARROW ENCONTRA O VERDADEIRO TESOURO

Nosso jovem programador finalmente pergunta:

— Capitão, onde estava o tesouro?

Jack olha para o TK85.

Depois olha para a fita.

Depois para uma revista Micro Sistemas.

Depois para o mapa da Inglaterra.

— Você ainda não percebeu?

O tesouro nunca esteve somente no cavalo.

Estava na rede.

Na pessoa que trouxe a fita.

Na loja que fez a cópia.

No garoto que digitou BASIC.

No programador que publicou uma listagem.

No técnico que abriu uma máquina que ninguém sabia consertar.

No amigo que disse:

“Conheço um cara.”

Estava no conhecimento transmitido.


☕ EPÍLOGO — QUANDO OS BITS PRECISAVAM DE PASSAPORTE

Hoje abrimos GitHub e clonamos:

git clone projeto

Em segundos temos código produzido do outro lado do planeta.

É fácil esquecer o quão extraordinário isso é.

Nos anos 1980, aquele mesmo fluxo poderia exigir:

REVISTA
   |
   v
CONTATO
   |
   v
LONDRES
   |
   v
LOJA
   |
   v
K7
   |
   v
MALA
   |
   v
AVIÃO
   |
   v
GUARULHOS
   |
   v
SÃO PAULO
   |
   v
XAVIER DE TOLEDO
   |
   v
CÓPIA
   |
   v
TK85

E paralelamente tínhamos:

MICRO SISTEMAS
   |
   v
BASIC IMPRESSO
   |
   v
TECLADO
   |
   v
Aventuras na Selva
   |
   v
AMAZÔNIA

Enquanto hardware estrangeiro encontrava caminhos por viajantes, comerciantes e lugares lendários como a Galeria Pagé.

Mais tarde, Santa Ifigênia assumiria enorme protagonismo na informática paulistana.

O que parece caos quando observado superficialmente revela uma arquitetura.

Uma arquitetura humana.

Distribuída.

Redundante.

Resiliente.

Com múltiplas rotas.

Se o Correio demorasse, havia o viajante.

Se a importação oficial não existisse, havia outro canal.

Se não houvesse manual, havia revista.

Se não houvesse software, alguém programava.

Se não houvesse documentação, alguém perguntava ao sujeito que sabia.

E se ninguém soubesse...

alguém abria a máquina.

Talvez essa seja uma das grandes lições daquela geração para quem começa hoje em COBOL e mainframe:

tecnologia nunca foi apenas tecnologia.

Sempre existiram pessoas transportando conhecimento entre sistemas, empresas, países e gerações.

Um programa COBOL de 1975 que continua processando transações em 2026 possui algo em comum com uma fita de Pimania sobrevivendo através de emulação.

Ambos atravessaram gerações tecnológicas porque alguém considerou que aquilo ainda tinha valor.

Portanto, quando encontrar um programa COBOL antigo, não diga imediatamente:

“Isso é legado.”

Pergunte:

“Que viagem esse código fez para chegar até mim?”

Talvez tenha atravessado cinco versões de z/OS.

Talvez tenha sobrevivido a quatro migrações.

Talvez vinte programadores tenham mexido nele.

Talvez o autor original já esteja aposentado.

Mas o programa continua executando.

Como aquela velha fita.

Como o TK85.

Como Amazônia.

Como Pimania.

E em algum ponto de uma colina inglesa continua existindo um cavalo branco lembrando que, muito antes de GPS, cloud, smartphones e Internet, alguns poucos kilobytes já eram suficientes para conectar pessoas separadas por oceanos.

Jack Sparrow pega a fita K7.

Observa os dois lados.

E pergunta:

— Então isto tudo cabe aqui?

O programador responde:

— O programa cabe.

Jack sorri.

— A aventura, não.

🥚 Easter egg final

Se encontrar um velho programa COBOL cujo comentário diz:

*> DO NOT REMOVE THIS CODE.

não remova.

Provavelmente é o equivalente mainframe de encontrar um mapa marcado com:

X

E todo pirata competente sabe:

é exatamente aí que começa o problema.


☕ Um Café no Bellacosa Mainframe

Porque antes de existir cloud, nossos bits já viajavam pelo mundo. Só precisavam de K7, avião, revista, café e alguém que conhecesse um cara.

🏴‍☠️ STOP RUN.

03:17 — o TK85 terminou de carregar.

https://worldofspectrum.net/item/0003714

sábado, 19 de maio de 2001

Fazenda A Colonia em Amparo

Almoço no cenário da novela "Os Imigrantes"

A Fazenda A Colónia situada em Amparo, foi nos anos 80 cenário para uma bela novela de época os imigrantes, naquela época foi restaurada, pintada e limpara. Ficando com a aparencia de uma casa de um "Barão do Cafe" do século XIX.



Esta situada as margens da SP 360, logo após o trevo de Bragança, durante 15 anos abrigou um restaurante a beira do lago.

Comida caipira paulista com muitos produtos obtidos ali mesmo. De bónus ganhava-se uma volta pela fazenda onde podia conhecer todas as instalações existentes e ainda em uso.

Ao lado do restaurante tinha um lago com pedalinho, podia-se caminhar e ver plantações de café, gansos, bovinos, equídeos e ovideos. Os gansos por si so faziam a festa com aquela barulhada toda.

domingo, 13 de maio de 2001

A Fazenda Santa Rosa passeio ciclistico do dia das Maes

Ciclo-passeio pela zona rural de Itatiba

A minha cidade por opção é Itatiba , me apaixonei pela princesinha da colina e aqui estou . Nasci na capital andei por diversas cidades, sem nunca fixar raízes. Morei em Sao Paulo, Ibitinga, Novo Horizonete, Pirassununga, Quiririm e Taubate.



Porem devido aquelas escolhas da vida, conheci Itatiba em 1993, mudei-me para cá em 1998 e aqui estamos vendo a cidade crescer.

Este passeio ciclistico foi na zona rural próximo a antiga fazenda Santa Rosa, partindo do Itatiba Futebol Clube foram aparecendo mais e mais ciclistas ate chegarmos nos cafundos de Itatiba.

Curiosamente percebi como esta sem forma visita, eu que andava tantos quilómetros em bike, fui andar alguns poucos quilómetros e quase morri. Conheci um lado da cidade que nunca tinha visto, foi um bom domingo.
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...