El Jefe Midnight Lunch

✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

quarta-feira, 26 de dezembro de 2007

🟦 IBM Mainframe & COBOL 4.00

O elo entre o COBOL clássico e o mundo moderno

“COBOL 4 não é ruptura.
É a IBM dizendo: ‘vamos modernizar… sem quebrar nada’.”
— Bellacosa, depois de recompilar 3 milhões de linhas

🧬 Contexto histórico: onde o COBOL 4.00 se encaixa

O Enterprise COBOL for z/OS 4.0 faz parte da família COBOL 4.x, que surgiu no início da década de 2010, num momento crítico:

Mainframes mais poderosos (z10, z196)
Arquitetura 64 bits amadurecendo
Pressão por performance, modernização e integração
COBOL 3 ainda dominante… mas envelhecendo

👉 O COBOL 4 não veio para “mudar a linguagem”.
Veio para mudar o compilador.

📅 Data de lançamento (contexto realista)

Enterprise COBOL for z/OS 4.0: final de 2007 e primordios da primeira década de 2010.
Consolidação real aconteceu nas versões 4.1 / 4.2
Foi o degrau obrigatório antes do COBOL 5.x

💡 Tradução Bellacosa:

Se você saiu do COBOL 3 direto para o 5, o 4 foi o “meio do caminho” que você pulou… e pagou depois.

🖥️ Equipamentos mainframe indicados

COBOL 4 foi feito para explorar hardware moderno da IBM:

Mainframes ideais:

IBM z10
IBM z196
IBM zEC12
Totalmente compatível com zEnterprise

Por quê?

Porque o COBOL 4:

Gera código mais otimizado
Explora melhor o pipeline do processador
Se beneficia de novas instruções de CPU

🥚 Easter-egg:

Recompilar COBOL antigo em COBOL 4 sem mudar uma linha já dava ganho de performance.

🔄 O que muda em relação ao COBOL 3.x?

🧠 1️⃣ Compilador totalmente redesenhado

Novo backend
Melhor otimização de código
Melhor uso de registradores

👉 O código fonte parece igual.
👉 O código objeto não é.

⚙️ 2️⃣ Melhor suporte a arquitetura moderna

Preparação para 64 bits
Melhor alinhamento de dados
Base para o futuro COBOL 5 (LE-only)

📊 3️⃣ Performance real

Redução de CPU em batch
Melhor performance em loops
Melhor otimização de PERFORM

🥚 Easter-egg:

Muitos shops recompilaram só para economizar MIPS.

🧨 4️⃣ Mais rigor (menos permissividade)

Alguns “pecados antigos” começaram a ser cobrados:

Dados mal definidos
Uso implícito perigoso
Código que “sempre funcionou” 😅

👉 COBOL 4 começa a expor bugs escondidos há 20 anos.

🧪 Exemplo simples (nada muda… mas muda tudo)


IDENTIFICATION DIVISION.
PROGRAM-ID. EXEMPLO4.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-TOTAL PIC 9(9) VALUE 0.

PROCEDURE DIVISION.
    PERFORM 10 TIMES
        ADD 1 TO WS-TOTAL
    END-PERFORM
    DISPLAY WS-TOTAL
    STOP RUN.

➡ Em COBOL 3: funciona
➡ Em COBOL 4: funciona mais rápido

💡 O ganho está no objeto gerado, não no código.

🛠️ Dicas técnicas Bellacosa Approved™

✔ Recompile, mesmo sem modernizar

COBOL 4 já entrega valor só na recompilação

✔ Use parâmetros certos:

OPTIMIZE
ARCH
SSRANGE (para pegar erro escondido)

✔ Teste batch crítico

Principalmente cálculos
Principalmente datas
Principalmente arredondamentos

✔ Compare CPU antes/depois

Você vai se surpreender

⚠️ Armadilhas clássicas

🚨 Código que dependia de comportamento indefinido
🚨 Campos mal alinhados
🚨 MOVE CORRESPONDING em estruturas duvidosas
🚨 Arredondamento implícito não documentado

🥚 Easter-egg cruel:

COBOL 4 não cria bug.
Ele revela.

🧠 Curiosidades de bastidor

COBOL 4 foi o primeiro passo sério rumo ao LE-only
Muitas empresas ficaram “presas” no 4 por anos
Ele é visto como a versão mais estável da transição
Serviu de base para o radical COBOL 5

🧘 Primeiros passos para o Padawan

Se você está começando agora:

1️⃣ Entenda COBOL clássico primeiro
2️⃣ Saiba compilar e linkar
3️⃣ Entenda parâmetros de compilação
4️⃣ Recompile código antigo e observe
5️⃣ Leia o listing — ele ensina mais que o código

“Quem lê o listing, domina o mainframe.”

🧠 Visão Bellacosa Final™

O COBOL 4.00 não é famoso.
Não é revolucionário.
Não é hype.

Mas ele é:

Estável
Inteligente
O verdadeiro ponto de virada técnico do COBOL moderno

Se o COBOL fosse uma saga:

COBOL 3 = trilogia clássica
COBOL 4 = o episódio de transição
COBOL 5 = o reboot corajoso

E lembre-se, Padawan:

“Modernizar não é reescrever.
É entender o que funciona… e deixar melhor.”

segunda-feira, 17 de setembro de 2007

☕ Um Café no Bellacosa Mainframe — z/OS 1.9: o gigante mais inteligente e autônomo da era System z

☕ Um Café no Bellacosa Mainframe — z/OS 1.9: o gigante mais inteligente e autônomo da era System z

🕰️ Ano de lançamento

O IBM z/OS 1.9 foi lançado em setembro de 2007, acompanhando o IBM System z10 em seu ciclo de desenvolvimento — embora também suportasse o System z9.
Essa versão simboliza o amadurecimento da plataforma z/Architecture, consolidando avanços em autonomia, automação, segurança e processamento paralelo inteligente.

⚙️ Introdução técnica

Enquanto o z/OS 1.7 havia trazido a plena transição para 64 bits, o z/OS 1.9 foi a versão que deu “consciência situacional” ao sistema operacional.
Ele começou a analisar sua própria performance, otimizar cargas automaticamente e dialogar melhor com o hardware via novas interfaces do PR/SM e do z/Architecture.

Seu lema interno na IBM era:

“Think, adapt, optimize — autonomic computing starts here.”

E fazia jus ao nome. O 1.9 é considerado o primeiro z/OS verdadeiramente autonomic, aquele que gerencia, ajusta e distribui recursos de forma dinâmica, sem intervenção manual constante.

🧠 Avanços de arquitetura e uso de memória

Com suporte pleno a 64 bits, o z/OS 1.9 trouxe avanços notáveis:

Melhor gerenciamento de memória virtual, com page fixing otimizado e melhor cache awareness;
Expansão do suporte a Large Memory Objects (LMO), beneficiando cargas Java, DB2 e WebSphere;
Hipervisores e LPARs podiam agora consumir memória dinamicamente sem reboot, via Dynamic Storage Reconfiguration (DSR);
O sistema passou a entender afinidade de CPU/memória — recurso crucial para evitar latências em ambientes SMP (Symmetric Multi Processing).

Na prática, isso resultou em redução de page faults, melhor throughput em batch workloads e resposta mais rápida para transações CICS e IMS.

🧩 Aplicativos internos e softwares embarcados

O z/OS 1.9 trouxe grandes renovações no ecossistema IBM interno:

RACF (Security Server): novos controles de senha, expiração adaptativa, integração com LDAPv3 e criptografia AES-256 para chaves simétricas.
JES2 e JES3: otimizações no gerenciamento de spool e segurança, com controle refinado de job classes.
DFSORT e ICETOOL: passaram a explorar SIMD (Single Instruction, Multiple Data) da z/Architecture para aceleração de sorting.
RMF (Resource Measurement Facility): agora suportava métricas em tempo real integradas ao WLM — base para os primeiros dashboards de auto-tuning.
UNIX System Services (USS): maior compatibilidade com padrões POSIX, suporte a NFSv4 e novas APIs de rede para integração WebSphere/DB2.
Communications Server (TCP/IP stack): suporte robusto a IPv6, IPSec nativo, e QoS (Quality of Service) ajustável via WLM.

🔬 Instruções de máquina e firmware

O System z9 e o z/OS 1.9 trabalharam juntos para explorar novas instruções da z/Architecture:

Criptografia assistida por hardware (CPACF v2) — aceleração de AES, SHA e RSA diretamente no processador;
Instruções de controle de cache e pipeline, otimizando acessos concorrentes a memória;
Suporte a “Restartable Instructions”, garantindo integridade mesmo em falhas intermediárias;
Sincronização estendida (Compare-and-Swap, Fetch-and-Add) — base para virtualização eficiente e paralelismo seguro.

No firmware, o PR/SM (Processor Resource/System Manager) ganhou um salto em inteligência:

Capacidade de redistribuição automática de processadores lógicos entre LPARs com base no WLM;
Suporte aprimorado a zAAPs (Application Assist Processors) e zIIPs (Integrated Information Processors);
Introdução do Group Capacity Limit e Soft Capping Dinâmico — controle refinado de consumo de CPU por partição.

Essa combinação tornou o z/OS 1.9 um sistema operacional mais previsível, justo e elástico, precursor direto das políticas de cloud elástica do z/OS moderno.

🧮 Créditos de CPU e desempenho

No z/OS 1.9, os créditos de CPU (entitlement) ganharam vida nova:

Introdução do WLM Goal Mode aprimorado, que realoca créditos em tempo real;
Possibilidade de mover créditos entre LPARs sem intervenção;
Integração total com IRD (Intelligent Resource Director) — permitindo que o sistema negocie recursos entre workloads.

A consequência?
Mais performance em workloads DB2, WebSphere e CICS com menor custo por MIPS — e maior eficiência energética (conceito que começava a ser prioridade).

🧭 Curiosidades e bastidores

O z/OS 1.9 foi a primeira versão totalmente construída sobre z/Architecture, sem dependências de compatibilidade com 31 bits.
A IBM apelidou o projeto internamente de “Nova”, pois a meta era “iluminar” a inteligência dentro do mainframe.
Foi a última versão a rodar confortavelmente em System z9 BC, antes que o z/OS 1.10 se tornasse exclusivo de z10 e superiores.
Alguns engenheiros da época chamavam o WLM + IRD de “mini-cérebro”, por sua capacidade de autoajuste.

☕ Dica Bellacosa Mainframe

Se você é curioso sobre autotuning, WLM e virtualização, o z/OS 1.9 é uma joia de estudo.
Ele é leve o suficiente para rodar em ambientes zPDT/Hercules e rico o bastante para mostrar o início real da era autonomic — onde o mainframe aprendeu a pensar sozinho.
Além disso, suas métricas de RMF são excelentes para treinar operadores e analistas de performance.

📜 Resumo técnico rápido

Item	Descrição
Versão	z/OS 1.9
Ano de lançamento	2007
Hardware principal	IBM System z9 / início do z10
Arquitetura	z/Architecture (64-bit)
PR/SM	Redistribuição automática de CPU e memória
Processadores	Suporte total a zAAP e zIIP
WLM	Goal Mode dinâmico e autoajuste
Segurança	RACF com AES-256 e LDAPv3
Rede	IPv6, IPSec, QoS dinâmico
Curiosidade	Primeira versão “autonomic”, cognitiva e autoajustável da IBM

💬 “O z/OS 1.9 foi quando o mainframe deixou de apenas trabalhar — e começou a pensar.”

domingo, 1 de julho de 2007

🔥 CICS Transaction Server for z/OS 3.x

CICS TS 3.2 Bellacosa Mainframe

🔥 CICS Transaction Server for z/OS 3.x

☕ Midnight Lunch no túnel do tempo

Imagine estar na sala de operações em meados dos anos 2000.
O CICS já não era mais apenas “aquele trem verde de 3270”.
Ele estava virando servidor transacional corporativo global, lidando com Web, Java e conectividade aberta — e as versões 3.x foram decisivas nessa transição.

Aqui está tudo que você precisa saber sobre essa série — com história, contexto, curiosidades e um exemplo para “sentir” o impacto real.

📅 Versões e Linha do Tempo

CICS Transaction Server for z/OS 3.x engloba versões que marcaram a década de 2000:

Versão	Lançamento (aprox.)	Destaques principais
3.1	2005	Entrada forte em Web, HTTP, segurança e integração C/C++
3.2	2007	Melhor suporte a conectividade, ESDS/VSAM grandes, APIs threadsafe

📌 Note que os releases 3.x não têm tabelas públicas fáceis de EOS (End of Service), mas já estão largamente fora de suporte oficial há muitos anos.

CICS 3.2

🧠 O que há de novo no 3.x

✅ 1. Suporte avançado a Web & HTTP

CICS 3.1 foi um divisor de águas:
pela primeira vez os ambientes CICS puderam servir requisições HTTP nativamente, abrindo caminho para aplicações web centradas em transações já existentes.

💬 Bellacosa diz:
“Antes disso, CICS era green screen ou nada. Depois disso, ele começou a conversar com o mundo inteiro.”

✅ 2. Segurança fortalecida

Antes de microserviços e OAuth, o CICS 3.1 trouxe mecanismos de autenticação e autorização integrados ao HTTP, simplificando a gestão de usuários e integração com LDAP/RACF.

✅ 3. Web Services e SOAP no mainstream

Embora SOAP estivesse surgindo em outros lugares, o CICS 3.1 o integrou de forma sólida, permitindo que as aplicações transacionais fossem expostas como serviços.

📌 Esse passo foi chave para tudo que veio depois em JSON, REST e APIs nativas.

✅ 4. Threadsafe Core APIs

No 3.2, a IBM investiu pesado em APIs threadsafe para:

arquivos VSAM
journals
WebSphere MQ

Esse foi um reflexo da necessidade de alta concorrência e escalabilidade.

✅ 5. Capacidade ampliada de VSAM e dados grandes

O CICS 3.2 elevou limites históricos:
suporte a arquivos ESDS maiores que 4 GB e tabelas de dados compartilhado maiores que 2 GB.

💬 Comentário Bellacosa:
“Isso significa que sistemas antes fragmentados podiam por fim lidar com conjuntos de dados corporativos gigantescos sem gargalo.”

🧪 Melhorias e Mudanças Significativas

🔹 Conectividade TCP/IP madura

Web services + HTTP + TCP/IP tornaram o CICS porta de entrada para arquiteturas distribuídas.

🔹 Usabilidade do CICSPlex SM

Novas vistas de gerenciamento e integração com sistemas de workload distribuído chegaram com 3.2.

🔹 Tradução e interoperabilidade com C/C++ e Java

O CICS começou a ser plataforma de escolha para mixed–language applications num momento em que Java só começava a ganhar tração em corporações.

🧠 Curiosidades e Eastereggs Bellacosa

🍺 O “Web CICS” nasceu aqui:
Antes de 3.x, “CICS e Web” era um hack. Depois, virou padrão.

🍺 Threadsafe foi go-to para MQ:
APIs threadsafe mudaram como MQ e VSAM eram acessados dentro de CICS.

🍺 Arquitetura híbrida antes da nuvem:
CICS 3.x já pensava como um servidor de aplicativos moderno, mesmo quando “nuvem” ainda era buzzword futurista.

📉 Final de Vida (EOS) — Resumo

Estas versões 3.x já estão fora de suporte há muitos anos — de fato, o foco IBM passou para as séries 4.x e depois 5.x/6.x. A tabela oficial indica o fim do serviço das versões 5.* como referência de política, confirmando que nada abaixo disso terá suporte continuado.

📜 História com Exemplo (Bellacosa Way)

Imagine um sistema bancário em 2006:

Você tinha centenas de telas 3270 e milhares de COBOL + BMS.
De repente:

📍 Você habilita HTTP: agora as aplicações web internas da intranet chamam CICS direto.
📍 Você expõe serviços SOAP: aplicativos distribuídos começam a falar com CICS.
📍 Você usa APIs threadsafe com MQ: integração com middleware vira rotina.

💬 Bellacosa comenta:
“Foi aqui que muitos sistemas que deveriam morrer em 5 anos, ainda estão de pé.”

💡 Dicas e Recomendações

✅ Entenda como HTTP foi integrado: é o ancestral das integrações REST/JSON que vieram depois.
✅ Aprenda sobre funções threadsafe: quase tudo de moderno em CICS tem raízes nisso.
✅ Use CICSPlex SM: aprendê-lo aqui facilita todo o resto.

📌 Conclusão Bellacosa

O CICS TS 3.x foi mais do que uma linha de releases. Foi o momento em que o CICS virou servidor de aplicativos transacionais corporativo — antes disso, ele era “transação e tela”; depois disso, virou plataforma integrada para Web, middleware e aplicações modernas.

🔥 Sem 3.x, não haveria 5.x moderno.
Sem 3.x, o CICS continuaria preso ao passado.

domingo, 15 de janeiro de 2006

Bellacosa Index Page : ferramenta de análise para avaliar site

Bellacosa Index Page : Ferramentas para analisar um site

É totalmente possível avaliar um blog hospedado no Blogspot diretamente pela URL, sem precisar instalar programas, extensões ou ter acesso ao painel administrativo do Blogger. Hoje existem diversas ferramentas online confiáveis que analisam um site da mesma forma que os mecanismos de busca fazem, observando fatores técnicos, estruturais e de conteúdo apenas a partir do endereço público da página. Isso torna a avaliação acessível tanto para iniciantes quanto para criadores experientes.

Essas ferramentas funcionam simulando o comportamento de robôs como o Googlebot. Ao receber a URL do blog ou de um post específico, elas fazem o rastreamento do conteúdo HTML, verificam cabeçalhos, meta tags, links, estrutura do texto, carregamento da página e outros sinais importantes. Tudo isso é feito externamente, sem necessidade de login ou permissões especiais. Basta colar o link e iniciar a análise.

No quesito SEO, essas plataformas conseguem identificar se o blog possui títulos adequados, meta descrições bem definidas, uso correto de headings (H1, H2, H3), URLs amigáveis e presença de palavras-chave relevantes. Também apontam problemas comuns, como títulos duplicados, descrições ausentes ou excesso de tags que podem confundir os mecanismos de busca. Isso ajuda a entender se o conteúdo está bem preparado para ranquear no Google.

Quanto à indexação, algumas ferramentas mostram se a página pode ser rastreada, se o robots.txt permite acesso e se existem sinais de bloqueio, como noindex. Complementando isso, o Google Search Console — também baseado em URL pública — informa se as páginas estão indexadas, excluídas ou apresentando erros. Assim, mesmo sem entrar no painel do Blogspot, é possível saber exatamente como o Google enxerga o blog.

A análise de conteúdo é outro ponto forte. Existem serviços online que contam o número de palavras diretamente a partir da URL, avaliam a densidade de texto, a presença de imagens, links internos e externos, além da legibilidade. Isso ajuda a identificar conteúdos muito curtos (“conteúdo fino”) ou mal estruturados, que tendem a ter baixo desempenho nos resultados de busca.

Já a performance e a experiência do usuário podem ser avaliadas por ferramentas como o Google PageSpeed Insights. Elas medem o tempo de carregamento, a estabilidade visual, a responsividade em dispositivos móveis e outros indicadores conhecidos como Core Web Vitals. Esses fatores influenciam tanto o SEO quanto a satisfação do visitante, e podem ser analisados apenas com a URL do blog.

Por fim, a estrutura geral do site também pode ser examinada: organização dos links, uso de sitemap, presença de erros técnicos e compatibilidade com dispositivos móveis. Em conjunto, essas análises oferecem uma visão clara da saúde do Blogspot. Portanto, mesmo sem acesso ao painel e sem instalar nada, é perfeitamente viável avaliar, diagnosticar problemas e planejar melhorias usando apenas ferramentas online baseadas na URL pública do blog.

🔍 1️⃣ Google Search Console (OFICIAL – indispensável)

📍 https://search.google.com/search-console

O que avalia:

páginas indexadas
páginas excluídas (noindex, duplicadas)
erros de rastreamento
cobertura
desempenho nos resultados de busca

Como usar:

Adicione seu Blogspot
Use Inspeção de URL
Use Indexação → Páginas

📌 Ferramenta nº 1 para saber se o Google vê seu blog.

📊 2️⃣ SEO Site Checkup

📍 https://seositecheckup.com

O que avalia (pela URL):

SEO on-page
meta tags
headings
links
sitemap
robots.txt
velocidade

✔️ Gratuito (limitado)
✔️ Ideal para Blogspot

🧠 3️⃣ Ahrefs Webmaster Tools (gratuito)

📍 https://ahrefs.com/webmaster-tools

O que avalia:

páginas indexáveis
problemas de SEO
links internos
backlinks
conteúdo fraco

📌 Excelente para identificar posts com pouco texto.

⚡ 4️⃣ PageSpeed Insights (Google)

📍 https://pagespeed.web.dev

O que avalia:

velocidade
mobile-friendly
problemas técnicos
Core Web Vitals

📌 Blogspot lento = indexação lenta.

🧾 5️⃣ SEO Review Tools – Website Word Count

📍 https://www.seoreviewtools.com/website-word-count/

O que avalia:

quantidade de palavras por URL
texto visível
estrutura básica

👉 Cole a URL do post (não da home).

🧪 6️⃣ Screaming Frog (versão online alternativa)

📍 https://www.screamingfrog.co.uk/seo-spider/

💻 Versão desktop é melhor, mas online ajuda a entender:

status code
títulos
meta descriptions
duplicações

📈 7️⃣ Small SEO Tools

📍 https://smallseotools.com

Ferramentas úteis:

verificador de plágio
análise de SEO
contador de palavras por URL
meta tag analyzer

🎯 8️⃣ Google Rich Results Test

📍 https://search.google.com/test/rich-results

Avalia:

dados estruturados
erros de schema
compatibilidade com resultados avançados

🧠 COMO USAR NA PRÁTICA (PASSO A PASSO)

Para um post do Blogspot:

1️⃣ Teste no SEO Review Tools (Word Count)
2️⃣ Teste no SEO Site Checkup
3️⃣ Inspecione no Search Console
4️⃣ Veja velocidade no PageSpeed

📌 Se passar nesses 4 → está muito bem.

🚨 DICA IMPORTANTE

Nenhuma ferramenta substitui o Google.
Se o Search Console diz “indexada”, o resto é otimização.

sábado, 24 de dezembro de 2005

FORTE APACHE GULLIVER — O SISTEMA OPERACIONAL DA INFÂNCIA

Bellacosa Mainframe apresenta Forte Apache na infancia

FORTE APACHE GULLIVER — O SISTEMA OPERACIONAL DA INFÂNCIA

Forte Apache da Gulliver

Existem brinquedos.

Existem brinquedinhos.
E existe o Forte Apache da Gulliver — uma entidade que transcende plástico, tinta, escala 1:35 e infância.

Para muitos foi só um brinquedo.
Para mim foi companheiro, cenário, portal, quase uma LPAR emocional em que eu podia subir quantas instâncias de imaginação quisesse.

Não lembro a idade exata.
Só lembro que era pequeno — daqueles pequenos que ainda caem de bunda no chão — quando ganhei meu primeiro Forte Apache.

Forte Apache

E, meus amigos… aquele era O Forte Apache.
De madeira.
Com o cheiro doce de tinta artesanal.
Tinha casa-sede, as quatro torres, soldados a pé, a cavalo, um menino e um cão pastor preto que parecia sempre pronto para salvar o dia.
Tudo pintado à mão.
Não era um conjunto de brinquedo.
Era uma obra de arte do artesanato brasileiro dos anos 70.

Forte Apache

Aquela fortaleza era meu microcosmo de batalhas épicas:
Cowboys bravos, Sétima Cavalaria, guerreiros apaches, dramatizações infantis de uma América inventada entre a TV Record, a TV Tupi e os western spaghetti de Giuliano Gemma que eu assistia em preto e branco.

E ali, sem manual, sem supervisão, sem “adoçantes didáticos”, meu imaginário treinava estratégias, narrativas, táticas, diplomacias e… guerras.
Sim, era outra época.
Sem a patrulha do politicamente correto.
Sem filtro.
Sem revisões históricas.
Apenas a imaginação crua, selvagem, viva — como devia ser.

Forte Apache
1982 — O SEGUNDO FORTE

O tempo passa, os anos mudam, a Gulliver simplifica materiais, abandona tintas caras…
Mas em 1982, quando ganhei o segundo Forte Apache, a magia estava lá.
Menos pintura à mão, mais padronização.
Mas ainda com alma.

O realismo permanecia.
O espírito também.
E as histórias ganhavam novas luzes, novos personagens, novos “episódios”.

Caixa do Forte Apache

1984 — O TERCEIRO, A EXPANSÃO DO UNIVERSO APACHECINEMÁTICO™

Em 1984, veio o terceiro.
O que já era saga virou trilogia.
E trilogias, como todo nerd sabe, são portais de poder.

Eu construí cidades, inventei batalhas, narrei vitórias e derrotas.
Ali aprendi — sem querer — storytelling, estratégia e até logística de guerra.

A infância é sábia: ensina brincando, sem avisar.

Caixa do Forte Apache

ANOS 1990–2000 — O COLECIONADOR DESPERTA

O tempo seguiu.
O menino cresceu.
Mas o Forte Apache nunca foi embora.

Com dinheiro próprio, comprei mais três.
Era um reencontro com o passado, um handshake entre versões do mesmo “eu”.

E um dia, já adulto, comprei um especialmente para o meu filho.

Porque algumas heranças não podem ser guardadas no banco.
Elas devem ser transmitidas como chama, não como cinza.

Caixa do Forte apache

POR QUE IMPORTA TANTO?

Porque o Forte Apache não era plástico.
Era território.
Era portal.
Era código-fonte da imaginação.

Foi ali que aprendi a criar universos.
Foi ali que o mundo começou a expandir.
Foi ali que comecei a me tornar quem sou.

Quando adulto, a gente olha para trás e descobre que certos objetos não eram objetos: eram arquiteturas emocionais.

E na minha, no meu “mainframe da memória”, há um dataset inteiro, catalogado, indexado e replicado nos backups afetivos, chamado:

FORTAP.APACHE.GULLIVER.LOVE(197X–HOJE)

forte apache desmontado

Maleta do Forte Apache

quinta-feira, 29 de setembro de 2005