☕ 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, 14 de abril de 2000

Guarulhos : Treinamento da Brigada de Incendio

A equipe de Brigadistas do Banco Real


Os bombeiros voluntários e equipes de brigadistas um importante trabalho social que visa ajudar a salvar colegas em caso de desastres, este treinamento foi em Guarulhos no ano 2000, devido a grandes incêndios como Joelma e Andraus o governo de São Paulo obriga que instalações com mais de 50 pessoas ou que tenha acesso livre para a circulação de pessoas, possua uma equipe treinada de Brigadistas.



O nosso treinamento é pesado visando simular diversas situações de risco... uso de extintores diversos, mangueiras, prevenção e detectar de focos de incêndios. inclusive um labirinto de fogo e fumaça para sabermos como seria num caso extremo.

Neste treinamento temos noções de comando de pessoas e evacuação de lugares de risco, combate e apoio em princípios de incêndio, sinalização e comunicação as autoridades e cursos de primeiros socorros.

Este grupo de brigadistas fazia parte dos funcionários do Banco Real, Realplan, RPD, SBPS e Abn Amro que organizaram uma grande equipe de brigadas coordenados por ex-oficiais do Corpo de Bombeiros do Estado de São Paulo.

sábado, 8 de abril de 2000

SP 360 - De Itatiba a caminho de Amparo

Viajando no Rapido Serrano

Durante muitos anos esta foi minha estrada, partia cedo e atravessava a SP 360 em Direcção a Amparo, era incrível ver a paisagem, tinha o Jorge motorista super bacana que animava a viagem sempre com uma boa conversa. A antiga companhia Rápido Serrano fazia a ligação entre todas as cidades da região.



Esta viagem era uma viagem em tanto, pois o ónibus parava em tudo quanto é lugar, subindo e descendo passageiros, sem contar com o transito difícil na SP 360 que nesta altura era de mão única, se pegássemos um caminhão em Morungaba somente em Amparo é que conseguíamos ultrapassa-lo.

Estas fotografias foram feitas em 2002, meses antes de partir para a Vagneida, pois queria guardar a imagem de um caminho que fizera tantas vezes em minha vida.

segunda-feira, 20 de março de 2000

Amparo visitando a cidade.

Prédios históricos em Amparo


Uma jóia na montanha: Amparo cidade histórica com casario conservado e tombado para as gerações futuras... um passeio por suas ruas eh um viagem no tempo. Ver como eram as casa no século passado. Seus parques são outros tesouros, árvores centenárias, animais soltos e jardins com flores belissima.


Esta cidade possui duas grandes ligações, uma vindo por Bragança/Itatiba/São Paulo e outra vindo por Campinas/Jaguariúna e Pedreira e várias subligações com cidades pequenas da região, permitindo um fluxo constante de bens e recursos. Sendo muito visitada por turistas que vêm em busca do seu patrimônio cultural composto por diversas casas coloniais e do início do século XX bem conservadas.

Ao lado da estação de Trem (hoje cinema da cidade). Atualmente, um museu e é claro existe uma pastelaria a Copa de Ouro com suas mais de 4 décadas fazendo o melhor pastel de Amparo, ou se tiver sorte encontrar o velhinho que vende algodão doce em uma máquina construída há mais de 100 que foi passada de mãos em mãos.

Amparo

Amparo, no interior do estado de São Paulo, é daquelas cidades que parecem pequenas no mapa, mas enormes em história, charme e fofoca boa de boteco. Fundada oficialmente em 8 de abril de 1829, Amparo nasceu como ponto de apoio de tropeiros e agricultores que cortavam o interior paulista levando café, gado e histórias. O nome, dizem, vem da devoção à Nossa Senhora do Amparo, que acabou virando padroeira e presença constante nas festas e no imaginário local.

A cidade floresceu de verdade no século XIX com o ciclo do café. Barões do café, casarões imponentes, fazendas gigantescas e uma elite rural que queria parecer europeia no meio do mato. Resultado? Um centro histórico riquíssimo, com prédios preservados, igrejas centenárias e aquela sensação deliciosa de andar por ruas que “já viram de tudo”. Amparo faz parte do famoso Circuito das Águas Paulista, o que por si só já rende histórias curiosas: fontes minerais, hotéis antigos e aquele turismo de “cura”, onde o povo ia tomar água acreditando que resolvia do estômago à alma.

Curiosidade número um: Amparo foi uma das primeiras cidades do Brasil a ter iluminação elétrica pública, ainda no final do século XIX. Enquanto muita capital engatinhava, Amparo já brilhava — literalmente. Isso sempre rende aquela vaidade interiorana clássica: “Aqui a gente chegou primeiro”. Outro detalhe saboroso é que a cidade tem forte influência italiana, herdada da imigração que veio substituir a mão de obra escravizada após a abolição. Resultado? Cantinas, massas, vinhos caseiros e sobrenomes que terminam em vogal espalhados por toda parte.

Agora, vamos aos easter eggs históricos. Pouca gente sabe, mas Amparo já foi palco de intensas disputas políticas e econômicas entre famílias poderosas. Brigas que começavam na Câmara e terminavam em rompimentos familiares que duraram gerações. Tem casarão no centro que, segundo a fofoca local, nunca foi vendido “por birra”, só para não cair na mão da família rival. Verdade? Lenda? Em Amparo, como em toda cidade antiga, as duas coisas se misturam.

Falando em lenda, há quem diga que algumas fazendas antigas são assombradas por ex-escravizados e antigos proprietários. Barulho de corrente, piano tocando sozinho, passos no assoalho… Histórias que ganham força depois de um café forte ou de uma boa cachaça artesanal da região. E cachaça boa, diga-se de passagem, não falta por lá.

Na parte mais fofoqueira: Amparo tem aquela dinâmica clássica de cidade média do interior. Todo mundo se conhece, ou pelo menos acha que conhece. Qualquer novidade vira assunto: quem abriu comércio novo, quem fechou, quem separou, quem voltou, quem foi visto com quem na praça. A Praça Pádua Salles, coração da cidade, é praticamente um “painel de controle social”: sentou ali, virou notícia.

Hoje, Amparo mistura passado e presente com elegância. Mantém o ar tranquilo, mas sem ser parada no tempo. É cidade para quem gosta de história viva, café forte, conversa longa e aquela deliciosa sensação de que cada esquina tem uma história — ou uma fofoca — esperando para ser contada.





quinta-feira, 9 de março de 2000

🌏✨ Spectreman — O Herói Dourado Que Despertou a Consciência da Terra

 

Spectreman



🌏✨ Spectreman — O Herói Dourado Que Despertou a Consciência da Terra

Se você cresceu vibrando com Ultraman, Jaspion ou Kamen Rider, então precisa conhecer (ou relembrar!) um dos maiores clássicos do tokusatsu japonês: Spectreman.
Um herói dourado, vindo do espaço, que lutava não apenas contra monstros, mas também contra a poluição, a ganância humana e a própria ideia de destruição do planeta. 🌿🦸‍♂️



🌀 Sinopse

A série Spectreman (スペクトルマン) estreou no Japão em 1971, produzida pela P Productions, e chegou ao Brasil nos anos 1980 — conquistando corações com sua mistura de ficção científica, drama ecológico e boas doses de ação vintage.

Em um futuro que já era o presente (para os anos 70), a Terra sofre com poluição, desmatamento e desequilíbrio ambiental. É nesse cenário que surge o vilão Dr. Gori, um cientista símio do planeta E, expulso de seu mundo por tentar dominar tudo com sua inteligência e arrogância. Ele vem à Terra para “corrigir” a humanidade — dominando-a.

Mas o Império Nebuloso, guardiões da ordem cósmica, envia seu agente de elite: Spectreman, um guerreiro cibernético capaz de se disfarçar como humano (Kenji) e lutar contra os monstros criados por Gori.

Cada episódio traz um monstro simbólico — nascido da poluição, da ambição ou do erro humano — e um recado sutil sobre o que estamos fazendo com nosso planeta. 🌍💭


💫 Personagens Principais

🦸‍♂️ Spectreman / Kenji
O protagonista. Um androide com alma de guerreiro e coração humano. Trabalha disfarçado na Patrulha Anti-Poluição. Quando a situação aperta, ele ergue o punho e grita:

“Spectreman!”
Transformando-se no herói dourado do cosmos.

🧠 Dr. Gori
O vilão mais carismático da série — um cientista de rosto simiesco, cheio de vaidade e discursos filosóficos sobre o destino da Terra. Apesar de suas intenções malignas, suas críticas à humanidade soam assustadoramente atuais.

🐒 Karas
O assistente fiel (e muitas vezes cômico) de Dr. Gori. É leal até o fim, mesmo diante dos planos mais absurdos do mestre.

👨‍🔬 Equipe Anti-Poluição
Colegas humanos de Kenji, que representam a luta científica e civil pela salvação ambiental — ainda que sem saber que trabalham ao lado de um herói interplanetário.


🪐 Curiosidades de Bastidores

  • 🎭 Spectreman foi um dos primeiros heróis japoneses com tema ecológico — algo bem ousado para 1971.

  • 💥 Os efeitos especiais foram feitos com orçamentos baixos, mas compensados com roteiros filosóficos e emocionais.

  • 📺 No Brasil, o herói foi dublado com aquele jeitinho clássico das séries tokusatsu dos anos 80 — e muitos fãs ainda lembram da música de abertura icônica:

    “Spectreman! Um ser estranho, poderoso e audaz...” 🎶

     


  • 🦍 O design de Dr. Gori foi inspirado em “O Planeta dos Macacos” (1968), que estava em alta na época.

  • 🌈 O visual dourado do herói foi escolhido para transmitir pureza e energia solar — o oposto da sujeira e decadência das cidades poluídas da trama.


💡 Dicas para Quem Quer Assistir Hoje

  1. 🔎 Onde ver: Algumas plataformas retrô e canais de tokusatsu no YouTube têm episódios legendados e remasterizados.

  2. 🕰️ Modo nostalgia: Assista com a cabeça aberta e o coração leve — Spectreman é uma cápsula do tempo.

  3. 🌱 Olhar ecológico: Repare como cada monstro representa uma crítica ambiental ou social. É tokusatsu com mensagem.

  4. 🧃 Maratona vintage: Combine com séries como Ultraman 80, Zone Fighter ou Robot Keiji para uma imersão total na Era Dourada dos heróis japoneses.


🧭 Por que Spectreman Ainda Importa

Muito antes dos discursos modernos sobre sustentabilidade, Spectreman já falava sobre cuidar da Terra.
Ele mostrou que ser herói não é apenas vencer monstros — é encarar o reflexo de nossos próprios erros.
E, convenhamos: é impossível não torcer quando aquele brilho dourado corta o céu e o som metálico anuncia a transformação. ⚡💛

“Enquanto houver poluição... haverá Spectreman!”


🌟 Resumo Rápido

ItemDetalhes
🎬 Título originalスペクトルマン (Spectreman)
🗓️ Ano1971–1972
🧑‍🚀 Episódios63
🧠 TemaFicção científica, meio ambiente, ética humana
🦸‍♂️ ProdutoraP Productions
🇯🇵 OrigemJapão
🌍 Mensagem centralA verdadeira ameaça à Terra é a própria humanidade

Spectreman é mais do que um herói — é um lembrete dourado de que o planeta também precisa de defensores sem capa, sem elmo, mas com consciência. 🌿💫

terça-feira, 1 de fevereiro de 2000

SHŌGUN 1980 : Quando um navegador europeu sofre um ABEND no Japão feudal e descobre que sobreviver depende menos da espada do que de compreender as regras ocultas do sistema

 

☕ Um Café no Bellacosa Mainframe

SHŌGUN 1980 sem Mistérios para Programadores COBOL

Quando um navegador europeu sofre um ABEND no Japão feudal e descobre que sobreviver depende menos da espada do que de compreender as regras ocultas do sistema

Imagine que você é um programador COBOL iniciante trabalhando tranquilamente em seu primeiro programa batch.

O código compila. O JCL parece correto. O arquivo de entrada está catalogado. O café ainda está quente. De repente, o job termina com ABEND.

Você abre o spool esperando encontrar uma mensagem amigável, mas descobre que:

  • o manual está escrito em japonês;

  • ninguém explica as regras do ambiente;

  • qualquer erro pode ser interpretado como desrespeito;

  • o gerente do sistema pode mandar cortar sua cabeça;

  • e o especialista funcional que poderia ajudá-lo talvez esteja secretamente trabalhando para outra empresa.

Parabéns.

Você acabou de entrar no universo de Shōgun, a monumental minissérie televisiva de 1980 baseada no romance de James Clavell.

Exibida originalmente pela NBC durante cinco noites, entre 15 e 19 de setembro de 1980, a produção transformou o Japão do início do século XVII em um enorme sistema legado político, militar e cultural. Richard Chamberlain interpretou o navegador inglês John Blackthorne; Toshirō Mifune viveu o poderoso senhor Yoshi Toranaga; e Yoko Shimada deu vida à inesquecível Lady Mariko. A minissérie foi escrita por Eric Bercovici, dirigida por Jerry London e produzida pela Paramount Television, com o próprio James Clavell como produtor executivo.

Para quem chegou depois de Game of Thrones, Vikings, The Last Kingdom, Shigurui ou Goblin Slayer, talvez seja difícil compreender o impacto de Shōgun em 1980.

Naquele tempo não havia streaming, replay instantâneo, redes sociais ou vídeo sob demanda. Quando um grande programa era transmitido, o país praticamente parava. E Shōgun foi um desses raros eventos televisivos.

Mas vamos por partes, como faria um veterano diante de um dump de 300 páginas.


Bellacosa Mainframe e o impacto da serie Shogun

1. Antes de executar o programa: o que significa “shōgun”?

A palavra shōgun é uma abreviação de um antigo título militar japonês, normalmente traduzido como “grande general pacificador dos bárbaros”.

Embora o imperador continuasse sendo a autoridade simbólica e religiosa, durante longos períodos da história japonesa o poder efetivo esteve nas mãos de governos militares comandados por shōguns. Em diferentes fases, esses líderes ou suas estruturas políticas exerceram o controle real do país. 

Podemos imaginar o Japão feudal como uma enorme instalação mainframe.

O imperador seria semelhante ao nome institucional da corporação: respeitado, histórico, carregado de legitimidade.

O shōgun seria o executivo que realmente controla:

  • o orçamento;

  • as tropas;

  • os territórios;

  • os acessos;

  • os recursos;

  • a continuidade operacional.

A série começa num momento em que esse cargo ainda não está consolidado nas mãos de um único senhor.

O Japão encontra-se num delicado processo de sucessão política. Diversos grandes senhores feudais, os daimyōs, disputam influência, territórios e sobrevivência. Todos sorriem durante as reuniões, mas cada um mantém suas próprias tropas prontas para entrar em produção.

É como uma reunião de mudança crítica na qual todos dizem:

“Da minha parte está aprovado.”

Mas cada departamento trouxe um plano secreto de rollback.


Bellacosa Mainframe e os atores e os personagens de Shogun

2. O grande ABEND de John Blackthorne

John Blackthorne é um navegador inglês que chega ao Japão depois de uma viagem desastrosa.

Ele não chega como turista.

Não possui passaporte diplomático, intérprete corporativo ou treinamento intercultural. Chega doente, exausto e cercado por sobreviventes de uma expedição quase destruída.

Blackthorne é baseado livremente em William Adams, navegador inglês que chegou ao Japão em 1600 e passou a ser conhecido como Miura Anjin. Adams tornou-se uma figura importante no início do século XVII, ganhou a confiança de Tokugawa Ieyasu e recebeu posição incomum para um estrangeiro dentro da sociedade japonesa.

Na série, Blackthorne recebe o nome de Anjin-san.

“Anjin” significa aproximadamente piloto ou navegador. “San” é um tratamento respeitoso.

Ele desembarca acreditando que conhece o mundo.

Rapidamente descobre que seu conhecimento funciona como um programa compilado para a plataforma errada.

Na Europa, ele compreende:

  • navegação;

  • canhões;

  • comércio;

  • guerras religiosas;

  • rivalidade entre ingleses e portugueses;

  • política marítima.

No Japão, quase tudo é diferente:

  • a linguagem;

  • os códigos de honra;

  • os gestos;

  • a hierarquia;

  • a alimentação;

  • a higiene;

  • a relação com a morte;

  • o sentido da obediência;

  • o papel do indivíduo diante do grupo.

Blackthorne não é burro. Seu problema é mais perigoso: ele tenta interpretar um sistema estrangeiro usando regras do próprio ambiente.

Esse é um erro clássico de programador iniciante.

Você aprende um comando no Windows e imagina que funcionará no z/OS. Aprende SQL num banco pequeno e acha que poderá aplicar as mesmas escolhas numa tabela com bilhões de registros. Conhece programação estruturada, mas ainda não entende o negócio.

O código não está necessariamente errado.

O contexto é que mudou.


3. O Japão feudal como um sistema legado vivo

A série se passa por volta de 1600, durante a transição entre o turbulento período de guerras internas e a ascensão da ordem que seria associada ao xogunato Tokugawa.

É um Japão dividido entre grandes senhores, famílias guerreiras, alianças temporárias e rivalidades antigas.

Cada daimyō possui:

  • terras;

  • castelos;

  • samurais;

  • arrecadação;

  • agricultores;

  • informantes;

  • rotas comerciais;

  • casamentos políticos;

  • compromissos de lealdade.

Isso lembra uma instalação corporativa gigantesca em que cada domínio possui suas próprias aplicações, bases de dados, equipes e regras locais.

O problema é que todos precisam coexistir dentro do mesmo sistema nacional.

A qualquer momento, uma aliança pode ser encerrada. Um casamento pode servir como contrato político. Um refém pode ser chamado de hóspede. Uma visita ao castelo pode se transformar numa prisão elegante.

Nada é simples.

Em Shōgun, as pessoas raramente dizem diretamente o que pretendem fazer.

Elas comunicam-se por:

  • silêncio;

  • posição na sala;

  • escolha das palavras;

  • presentes;

  • cerimônias;

  • intermediários;

  • mudanças aparentemente pequenas no protocolo.

Para um programador COBOL, é como depurar um sistema no qual a maior parte das regras de negócio não está no fonte.

Elas estão:

  • nos procedimentos operacionais;

  • nos parâmetros;

  • nos arquivos;

  • na experiência dos usuários;

  • nos comentários escritos em 1987;

  • na memória do analista que se aposentou.

Blackthorne vê espadas e armaduras.

Toranaga vê dependências, restrições e possibilidades.


4. Toranaga: o arquiteto que nunca mostra o diagrama completo

Yoshi Toranaga é inspirado em Tokugawa Ieyasu, o líder histórico que emergiria como força dominante após as grandes disputas políticas do período.

Interpretado por Toshirō Mifune, Toranaga é o personagem que mais se aproxima de um grande arquiteto de sistemas.

Ele raramente age por impulso.

Antes de realizar uma mudança, ele analisa:

  • quem será beneficiado;

  • quem será ameaçado;

  • quem acredita estar no controle;

  • quem pode ser usado como distração;

  • qual consequência surgirá meses depois;

  • como transformar a força do inimigo em dependência.

Toranaga não precisa explicar o plano para demonstrar que possui um.

Aliás, explicar tudo seria perigoso.

Num ambiente repleto de espiões, qualquer informação excessiva pode ser explorada.

O personagem trabalha com uma espécie de princípio do menor privilégio: cada aliado recebe apenas a informação necessária para cumprir sua parte.

É quase RACF feudal.

Blackthorne inicialmente acredita que Toranaga pretende simplesmente derrotar seus inimigos numa batalha.

Mas Toranaga compreende que vencer uma guerra não significa apenas possuir mais soldados. Significa controlar:

  • a narrativa;

  • o tempo;

  • as alianças;

  • os acessos;

  • a percepção dos adversários;

  • a disposição dos aliados para morrer.

Um comandante comum pergunta:

“Quantos homens temos?”

Toranaga pergunta:

“O que o inimigo acredita que faremos?”

Easter egg mainframe: Toranaga provavelmente seria o único homem capaz de olhar para um S0C7, não abrir o dump e ainda descobrir quem alterou o arquivo na madrugada anterior.


5. Lady Mariko: compiladora entre dois mundos

Lady Mariko é muito mais do que o interesse amoroso de Blackthorne.

Ela é intérprete, cristã, nobre, esposa de um samurai e membro de uma família marcada por acontecimentos políticos traumáticos.

Historicamente, a personagem foi inspirada de maneira livre em Hosokawa Gracia, mulher cristã de origem nobre cuja vida esteve ligada aos conflitos políticos do período. A Mariko de Clavell, porém, é uma criação ficcional e não uma reprodução exata dessa figura histórica.

Na arquitetura narrativa da série, Mariko funciona como uma compiladora.

Blackthorne fornece instruções em sua linguagem cultural.

Mariko interpreta, traduz e adapta essas instruções para que possam ser executadas no ambiente japonês.

Mas toda tradução envolve perda.

Quando Blackthorne diz algo agressivo, ela pode suavizar.

Quando um senhor japonês oferece uma resposta ambígua, ela precisa decidir quanto explicar.

Quando duas culturas utilizam conceitos diferentes, não existe tradução perfeitamente equivalente.

A palavra pode ser convertida.

O significado completo, nem sempre.

Essa é uma das maiores lições da minissérie: aprender algumas palavras em japonês não significa compreender o Japão.

Da mesma maneira, aprender a sintaxe do COBOL não significa dominar um sistema bancário.

Você pode conhecer:

IF SALDO-DISPONIVEL >= VALOR-SAQUE
    PERFORM AUTORIZAR-OPERACAO
END-IF.

Mas ainda precisa compreender:

  • bloqueios;

  • limites;

  • estornos;

  • dias úteis;

  • prevenção contra fraude;

  • regras regulatórias;

  • sistemas externos;

  • concorrência de transações.

Mariko ensina Blackthorne a linguagem visível e também a invisível.

Ela mostra quando falar, quando calar, quando curvar-se e quando uma aparente gentileza esconde uma ordem absoluta.


6. A violência: não era decoração, era regra de negócio

Um dos elementos mais chocantes de Shōgun em 1980 foi a violência.

Não porque a televisão nunca tivesse mostrado mortes, mas porque a minissérie apresentava uma sociedade na qual a morte podia surgir como consequência imediata de um erro de protocolo, uma desobediência ou uma derrota política.

A produção mostra ou sugere:

  • decapitações;

  • tortura;

  • crucificação;

  • punições coletivas;

  • seppuku;

  • violência conjugal;

  • ameaças contra famílias;

  • exposição de corpos;

  • mortes determinadas por hierarquia.

Algumas versões destinadas ao cinema chegaram a conter material de violência e nudez diferente daquele exibido originalmente pela NBC.  

A violência da série não possui exatamente a estética acelerada das produções atuais.

Não há cortes a cada dois segundos nem trilha sonora dizendo ao público quando ficar assustado.

Muitas vezes a tensão nasce do silêncio.

Um personagem se ajoelha.

Uma espada é retirada.

Todos entendem o que acontecerá.

O espectador ocidental demora alguns segundos para perceber que não haverá recurso, advogado ou reunião de revisão.

O job foi cancelado permanentemente.

Entretanto, é necessário evitar uma leitura simplista.

A série pode induzir o público a imaginar que todos os japoneses viviam diariamente sob uma cultura uniforme de morte e suicídio. A realidade histórica era muito mais complexa. Os códigos associados aos samurais variaram conforme época, região, senhor e circunstância.

O chamado bushidō, frequentemente apresentado no Ocidente como um manual eterno e perfeitamente definido, foi construído, reinterpretado e romantizado ao longo dos séculos.

Nem todo samurai era um guerreiro filosófico.

Havia:

  • oportunistas;

  • burocratas;

  • administradores;

  • covardes;

  • traidores;

  • homens honestos;

  • homens brutais.

Assim como nem todo programador COBOL trabalha numa sala escura usando gravata e conversando diretamente com uma fita magnética.


7. Seppuku: o ABEND voluntário da honra

O seppuku, frequentemente chamado de hara-kiri no Ocidente, aparece como uma das práticas mais difíceis de compreender.

Para a mentalidade contemporânea, a ideia parece absurda: por que uma pessoa aceitaria a própria morte para preservar honra, obedecer a um senhor ou assumir responsabilidade?

Dentro daquela estrutura social, porém, o indivíduo não era compreendido de maneira tão isolada quanto no pensamento moderno.

Sua identidade estava ligada a:

  • família;

  • linhagem;

  • senhor;

  • posição;

  • reputação;

  • obrigações.

A desonra de uma pessoa poderia atingir gerações.

O seppuku podia funcionar como punição, protesto, demonstração de lealdade ou maneira de preservar algum controle diante de uma morte inevitável.

Não era simplesmente “gostar de morrer”.

Era uma linguagem política.

Em termos mainframe, seria como se a integridade do sistema fosse considerada mais importante do que a continuidade de um único processo.

O programa termina para impedir que a corrupção alcance todo o ambiente.

É uma comparação imperfeita — e precisa ser imperfeita, porque seres humanos não são jobs —, mas ajuda a compreender como a série apresenta o conflito entre valores individuais e coletivos.

Blackthorne inicialmente vê apenas brutalidade.

Aos poucos percebe que aquela sociedade possui uma lógica interna.

Compreender a lógica não significa necessariamente concordar com ela.

Essa distinção é fundamental.


8. Portugueses, jesuítas e a guerra escondida nos bastidores

Blackthorne não chega a um Japão isolado do mundo.

Portugueses e jesuítas já possuem presença, influência e interesses comerciais no país.

Para o navegador inglês e protestante, eles não são apenas missionários.

São adversários geopolíticos.

A Europa do período estava dividida por rivalidades religiosas, comerciais e imperiais. Portugueses e espanhóis possuíam extensas redes marítimas. Ingleses e holandeses procuravam romper monopólios, abrir mercados e atacar rotas controladas pelos rivais.

Por isso, quando Blackthorne revela informações sobre o mundo exterior, ele se transforma num ativo estratégico.

Ele conhece:

  • rotas;

  • mapas;

  • armas;

  • disputas europeias;

  • técnicas navais;

  • fragilidades portuguesas;

  • interesses comerciais.

Toranaga percebe que aquele homem desgrenhado pode ser mais útil do que parece.

É como encontrar um arquivo estranho num diretório temporário e descobrir que ele contém a documentação completa do sistema concorrente.

Os jesuítas também cumprem uma função narrativa decisiva.

Eles traduzem, aconselham e negociam, mas não são observadores neutros. Possuem fé, alianças e interesses.

Em Shōgun, informação é poder.

Quem controla a tradução controla parcialmente a realidade.

Quem informa Toranaga pode conduzi-lo a uma conclusão.

Quem esconde um detalhe pode alterar o futuro do Japão.

Dica de sobrevivência para o padawan COBOL: desconfie sempre da frase “é só um campinho”.

Em sistemas críticos, um pequeno campo pode decidir:

  • tributação;

  • autorização;

  • cálculo de juros;

  • classificação do cliente;

  • bloqueio de pagamento.

Em Shōgun, uma palavra traduzida de maneira conveniente pode iniciar uma guerra.


9. O choque cultural como motor da história

A série utiliza Blackthorne como porta de entrada para o público ocidental.

Ele se espanta com os japoneses.

Os japoneses também se espantam com ele.

Blackthorne considera algumas práticas locais cruéis ou incompreensíveis. Para muitos japoneses, o inglês é:

  • barulhento;

  • descontrolado;

  • malcheiroso;

  • ignorante;

  • incapaz de obedecer ao protocolo;

  • semelhante a um bárbaro.

Esse espelhamento é brilhante.

O espectador começa pensando:

“Como os japoneses são estranhos!”

Pouco depois percebe que, aos olhos japoneses, o europeu é igualmente estranho.

Blackthorne valoriza a espontaneidade.

Os japoneses valorizam o autocontrole.

Blackthorne fala o que pensa.

Os nobres japoneses pensam cuidadosamente antes de falar.

Blackthorne acredita que sua vida lhe pertence.

A sociedade samurai entende que deveres podem estar acima da vontade individual.

Nenhum desses mundos é apresentado como completamente simples.

O verdadeiro aprendizado acontece quando Blackthorne para de perguntar:

“Por que eles não fazem como nós?”

E começa a perguntar:

“Que problema essa regra tenta resolver?”

Essa é também uma das perguntas mais importantes para quem entra num sistema legado.

Um iniciante olha para uma rotina antiga e diz:

“Isso está malfeito. Vou reescrever.”

Um veterano pergunta:

“Por que fizeram assim?”

Talvez a decisão tenha sido tomada por limitações de hardware.

Talvez exista uma integração esquecida.

Talvez o formato seja exigido por um órgão regulador.

Talvez outro programa dependa exatamente daquela aparente anomalia.

Antes de remover uma regra antiga, descubra qual guerra ela encerrou.


10. A visão hollywoodiana: janela ou espelho?

Apesar de seus méritos, Shōgun é uma produção norte-americana baseada num romance escrito por um autor ocidental.

Isso significa que o Japão mostrado pela minissérie não é o Japão falando completamente por si mesmo.

É o Japão reconstruído para ser compreendido pelo público ocidental de 1980.

O principal recurso usado para isso é Blackthorne.

O espectador aprende quando ele aprende. Fica confuso quando ele fica confuso. Recebe muitas informações apenas quando elas são traduzidas para ele.

Em vários momentos, os diálogos japoneses não são traduzidos por legendas. O público depende da interpretação disponível a Blackthorne.

Essa escolha cria imersão.

Também limita a autonomia dos personagens japoneses.

Quando eles conversam e o espectador não entende, sua existência narrativa fica subordinada à experiência do europeu.

A produção de 1980 foi filmada no Japão e utilizou um grande elenco japonês, algo expressivo para a televisão norte-americana da época. Tornou-se uma importante apresentação popular de uma versão do Japão histórico ao horário nobre dos Estados Unidos.

Ainda assim, existe orientalismo.

O Japão aparece como:

  • misterioso;

  • sensual;

  • perigoso;

  • ritualístico;

  • exótico;

  • espiritualmente profundo;

  • incompreensível para o estrangeiro.

Essas características não são totalmente inventadas, mas são selecionadas e amplificadas.

Hollywood frequentemente transforma culturas estrangeiras em cenários para a transformação de um protagonista ocidental.

O estrangeiro chega arrogante, aprende com os nativos, sofre, ama uma mulher local e retorna simbolicamente transformado.

Essa estrutura aparece em muitas produções posteriores.

A diferença é que Shōgun oferece a Toranaga e Mariko uma força dramática tão grande que eles escapam parcialmente dessa prisão narrativa.

Blackthorne acredita estar entrando no centro da história.

Toranaga sabe que ele é apenas mais uma peça.


11. Mariko não é um manual de “mulher japonesa”

Uma leitura superficial pode transformar Mariko no estereótipo da mulher oriental:

  • delicada;

  • obediente;

  • silenciosa;

  • dedicada ao homem ocidental.

Mas a personagem é muito mais complexa.

Seu autocontrole não significa ausência de vontade.

Sua delicadeza não significa fraqueza.

Sua obediência externa pode esconder uma decisão pessoal profunda.

Ela navega por um mundo no qual suas opções são limitadas, mas aprende a exercer poder dentro dessas limitações.

Mariko compreende:

  • religião;

  • política;

  • idioma;

  • etiqueta;

  • psicologia;

  • dever;

  • desejo.

Blackthorne possui força física e conhecimento naval.

Mariko possui capacidade de executar código em diversos ambientes humanos.

É ela quem entende a interface entre os sistemas.

E todos que trabalham com integração sabem:

a interface é onde os monstros vivem.


12. Toshirō Mifune: o processador central da minissérie

Toshirō Mifune já era uma lenda do cinema japonês quando interpretou Toranaga.

Sua longa colaboração com o diretor Akira Kurosawa ajudou a criar algumas das imagens mais influentes do samurai no cinema mundial.

Em Shōgun, Mifune não precisa de discursos intermináveis.

Ele domina cenas com:

  • olhar;

  • postura;

  • silêncio;

  • movimento das mãos;

  • mudança quase imperceptível de expressão.

Toranaga pode parecer calmo enquanto processa dezenas de possibilidades.

É como um mainframe em baixa utilização aparente, mas executando milhares de transações sem mostrar esforço.

Richard Chamberlain recebeu grande atenção promocional, mas Mifune oferece à série sua gravidade política.

Quando Toranaga entra, o ambiente muda.

Quando permanece em silêncio, os outros personagens começam a revelar mais do que deveriam.

Uma excelente técnica de liderança, aliás.

Às vezes, o gerente não precisa interromper.

Basta esperar o fornecedor continuar falando até admitir onde está o problema.


13. O impacto televisivo

Shōgun tornou-se um enorme sucesso de audiência.

A minissérie obteve uma média Nielsen de 26,3 e ajudou a NBC a alcançar uma de suas melhores semanas históricas. O programa também impulsionou as vendas do romance de James Clavell, cuja edição popular chegou a milhões de exemplares em circulação naquele período. 

Além da audiência, a produção recebeu reconhecimento crítico, incluindo Peabody, Globos de Ouro e Emmys, entre eles o prêmio de melhor série limitada.

Para muitos norte-americanos, foi o primeiro contato prolongado com elementos como:

  • daimyō;

  • samurai;

  • seppuku;

  • cerimônia do chá;

  • castelos japoneses;

  • conflitos cristãos no Japão;

  • etiqueta feudal;

  • guerra entre clãs;

  • influência europeia na Ásia.

É exagerado afirmar que a minissérie sozinha popularizou sushi ou criou todo o interesse norte-americano pelo Japão. Restaurantes japoneses e outros contatos culturais já existiam antes. Contudo, a produção participou de um momento crescente de fascínio ocidental pela economia e pela cultura japonesa. 

Ela não inventou a curiosidade pelo Japão.

Mas instalou uma atualização gigantesca no imaginário popular.


14. Como os japoneses receberam a série?

O sucesso ocidental não significou aprovação universal no Japão.

Parte do público japonês considerou a dramatização estrangeira simplificada quando comparada às tradicionais produções históricas japonesas, especialmente os taiga dramas da NHK.

Para espectadores acostumados a narrativas detalhadas sobre figuras históricas, alianças e períodos políticos, Shōgun podia parecer uma versão exótica da própria história, organizada principalmente em torno da experiência de um estrangeiro. 

Imagine um programador brasileiro assistindo a uma produção estrangeira sobre o Brasil colonial na qual:

  • todos falam de maneira estranha;

  • vários costumes são misturados;

  • a política é simplificada;

  • o protagonista estrangeiro parece entender o país em poucas semanas.

Talvez a obra seja excelente para o público internacional.

Mas quem conhece o contexto perceberá as abstrações.

Isso não torna Shōgun inútil.

Apenas confirma que se trata de ficção histórica, não de documentação oficial.


15. O que é verdade e o que é liberdade dramática?

A obra usa personagens ficcionais inspirados em pessoas reais:

PersonagemInspiração histórica aproximada
John BlackthorneWilliam Adams
Yoshi ToranagaTokugawa Ieyasu
Lady MarikoHosokawa Gracia
IshidoIshida Mitsunari
NakamuraToyotomi Hideyoshi

Os acontecimentos foram condensados, dramatizados e reorganizados.

Relações pessoais são intensificadas. Conflitos são simplificados. Personagens representam combinações de figuras históricas. Cronologias são adaptadas para servir à narrativa.

Portanto, a maneira correta de assistir é:

  1. aproveitar a história;

  2. observar os temas culturais;

  3. reconhecer o contexto histórico;

  4. pesquisar separadamente os acontecimentos reais;

  5. não utilizar uma minissérie como única fonte sobre o Japão.

É o mesmo princípio usado diante de código de exemplo.

Um programa didático ensina o conceito.

Não representa necessariamente toda a complexidade da produção.


16. Passo a passo para assistir como um investigador do mainframe

Passo 1 — Não julgue tudo imediatamente

Quando aparecer uma prática estranha, evite concluir:

“Isso é absurdo.”

Pergunte primeiro:

“Qual era a lógica social dessa prática?”

Passo 2 — Observe quem pode falar

Em cada reunião, note:

  • quem entra primeiro;

  • quem se ajoelha;

  • quem permanece armado;

  • quem traduz;

  • quem responde diretamente;

  • quem precisa esperar autorização.

A hierarquia é parte do diálogo.

Passo 3 — Desconfie das traduções

Nem toda frase é transmitida integralmente.

Observe Mariko e os jesuítas. Às vezes, traduzir significa também escolher o efeito político da mensagem.

Passo 4 — Procure o plano de Toranaga

Pergunte em cada episódio:

  • o que ele sabe?

  • o que está fingindo não saber?

  • quem acredita estar manipulando quem?

  • qual resultado ele deseja que pareça acidental?

Passo 5 — Separe honra de bondade

Um personagem pode agir de acordo com seu código e ainda cometer algo brutal.

Honra não significa automaticamente compaixão.

Passo 6 — Observe a transformação de Blackthorne

Ele começa como estrangeiro revoltado.

Depois aprende palavras.

Em seguida aprende rituais.

Mais tarde percebe que conhecer o ritual não significa controlar o sistema.

Passo 7 — Pesquise os equivalentes históricos

Depois de assistir, procure:

  • William Adams;

  • Tokugawa Ieyasu;

  • Hosokawa Gracia;

  • Ishida Mitsunari;

  • Batalha de Sekigahara;

  • cristianismo no Japão;

  • comércio português na Ásia.

A série ganhará uma segunda camada.


17. Curiosidades e pequenos easter eggs

O nome “Anjin”

Blackthorne é chamado de Anjin-san porque “anjin” está relacionado à função de piloto ou navegador. William Adams ficou historicamente conhecido no Japão como Miura Anjin. 

A ausência de legendas

A falta de tradução de muitos diálogos japoneses foi uma escolha deliberada. O público ocidental experimentava a mesma desorientação de Blackthorne.

Era uma espécie de tela 3270 sem manual.

Você enxerga os campos.

Não sabe ainda o que deve digitar.

A música

A trilha foi composta por Maurice Jarre, também conhecido por trabalhos grandiosos no cinema. Sua música ajuda a criar a sensação de viagem épica e encontro entre civilizações.

Uma produção realmente gigantesca

Filmar extensivamente no Japão com elenco internacional, figurinos, castelos, navios e centenas de participantes representava um desafio enorme para uma produção televisiva daquele período.

Richard Chamberlain, rei das minisséries

O ator tornou-se fortemente associado às grandes produções televisivas, participando posteriormente de outras minisséries de grande sucesso.

Toranaga não precisa sacar a espada

O verdadeiro poder do personagem não está em derrotar pessoalmente dezenas de soldados.

Está em construir uma situação na qual o adversário já perdeu antes de perceber que a batalha começou.


18. As lições de Toranaga para um programador COBOL

Primeira lição: conheça o ambiente antes de alterar o código

Blackthorne quase morre repetidamente porque não conhece as regras locais.

O programador iniciante provoca incidentes pelo mesmo motivo.

Antes de mudar, descubra:

  • quem consome a saída;

  • qual job executa depois;

  • quais arquivos são compartilhados;

  • qual é a janela batch;

  • como funciona o rollback;

  • quem precisa aprovar.

Segunda lição: informação vale mais do que força

Blackthorne sobrevive porque possui informações úteis.

No mainframe, quem conhece o fluxo completo frequentemente resolve mais problemas do que quem memoriza mais comandos.

Terceira lição: silêncio também é ferramenta

Não altere o sistema apenas para demonstrar iniciativa.

Observe.

Leia o fonte.

Analise o spool.

Converse com usuários.

Um bom diagnóstico evita uma mudança desnecessária.

Quarta lição: respeite os rituais

No Japão de Shōgun, o protocolo protege a hierarquia.

No ambiente corporativo, os rituais incluem:

  • change request;

  • evidência de teste;

  • aprovação;

  • segregação de funções;

  • homologação;

  • janela de implantação.

Podem parecer burocracia.

Muitas vezes são cicatrizes de antigos desastres.

Quinta lição: nunca confunda acesso com compreensão

Blackthorne entra em castelos e reuniões.

Isso não significa que conheça o plano.

O programador pode acessar o fonte e ainda não compreender o negócio.

Sexta lição: sistemas críticos não perdoam arrogância

O excesso de confiança é um dos ABENDs invisíveis da carreira.

O iniciante diz:

“É uma alteração simples.”

O veterano responde:

“Então será fácil provar que não quebrará nada.”


19. O legado de Shōgun

A minissérie de 1980 pertence a uma era específica.

Seu ritmo é mais lento.

Sua perspectiva é mais ocidental.

Alguns personagens japoneses recebem menos interioridade do que mereciam.

Certos elementos históricos são romantizados.

Mesmo assim, sua importância é enorme.

Shōgun mostrou que uma produção televisiva poderia:

  • contar uma narrativa histórica extensa;

  • exigir atenção durante várias noites;

  • apresentar grande quantidade de diálogo estrangeiro;

  • explorar política internacional;

  • colocar diferenças culturais no centro da história;

  • tratar a televisão como espetáculo épico.

Ela ajudou a preparar o terreno cultural para muitas produções posteriores sobre samurais, Japão feudal e encontros entre Oriente e Ocidente.

Não existe uma linha direta obrigatória entre Shōgun e cada anime, filme ou jogo posterior. Porém, a minissérie participou da ampliação do vocabulário cultural ocidental sobre o Japão.

Décadas depois, obras como:

  • O Último Samurai;

  • Ghost of Tsushima;

  • Nioh;

  • Sekiro;

  • Basilisk;

  • Shigurui;

  • Rurouni Kenshin;

  • Blade of the Immortal;

encontrariam um público já familiarizado, pelo menos superficialmente, com samurais, clãs e conflitos feudais.


20. Conclusão: o verdadeiro shōgun é quem compreende o sistema

No início, Blackthorne acredita que poder significa possuir:

  • navios;

  • canhões;

  • mapas;

  • conhecimento europeu.

Depois encontra homens que consideram a espada, a terra e a lealdade mais importantes.

Por fim, aproxima-se de Toranaga, um líder para quem o maior poder está em entender pessoas.

Essa é a mensagem secreta de Shōgun.

A espada é visível.

A estratégia não.

O exército é visível.

A aliança que o sustenta não.

O código COBOL é visível.

A regra de negócio escondida atrás dele não.

Para sobreviver no Japão feudal, Blackthorne precisa abandonar a arrogância de quem acredita que seu mundo é o único mundo possível.

Para sobreviver no mainframe, o programador iniciante precisa abandonar a arrogância de quem acredita que o fonte contém todo o sistema.

Não contém.

O verdadeiro sistema inclui:

  • pessoas;

  • história;

  • compromissos;

  • medo;

  • tradição;

  • dependências;

  • decisões tomadas décadas atrás;

  • regras nunca documentadas;

  • conhecimento transmitido entre gerações.

Em Shōgun, uma reverência executada no momento errado pode custar uma vida.

No mainframe, um DISP=(NEW,CATLG,DELETE) colocado no lugar errado talvez não corte sua cabeça — mas pode transformar a reunião da manhã seguinte numa cerimônia igualmente desconfortável.

Portanto, jovem padawan COBOL, quando entrar num sistema antigo, faça como Blackthorne em seus melhores momentos:

observe antes de falar;

aprenda antes de julgar;

pergunte antes de alterar;

respeite os mestres locais;

e nunca suponha que o homem segurando a espada seja aquele que realmente controla o castelo.

Às vezes, o verdadeiro shōgun está sentado em silêncio, olhando pela janela e aguardando que todos os demais executem exatamente o plano que acreditavam ser deles.

Fim do job.

MAXCC = 0000.


sábado, 1 de janeiro de 2000

🧙‍♂️ O EX-PROGRAMADOR E A DUNGEON DO DOWNSIZING — QUANDO TRÊS 386 ENFRENTARAM UM IBM 4341

Bellacosa Mainframe e o downsize dos anos 1990

 

☕ Um Café no Bellacosa Mainframe

🧙‍♂️ O EX-PROGRAMADOR E A DUNGEON DO DOWNSIZING — QUANDO TRÊS 386 ENFRENTARAM UM IBM 4341

IBM 4341, COBOL, CICS, VSAM, 3278, NetWare, Clipper, DOS, cliente-servidor, TCO, migração — e o dia em que um ex-programador entrou em outro mundo com um laptop e descobriu que trocar o mainframe por 98 PCs não fazia os problemas desaparecerem.

Sob a tutela de A Former Programmer Enters Another World and Uses a Laptop to Hack S-Rank Mage Skills



🎬 PRÓLOGO — O EX-PROGRAMADOR ACORDOU EM 1990

O ex-programador abriu os olhos.

Não havia Wi-Fi.

Não havia GitHub.

Não havia Stack Overflow.

Não havia Docker.

Não havia Kubernetes.

Não havia Cloud.

Não havia sequer uma tomada USB onde carregar seu misterioso laptop vindo de outro mundo.

Na parede havia um terminal.

Ele olhou para o teclado.

IBM 3278.

— Onde estou?

Um analista aproximou-se carregando uma listagem COBOL de aproximadamente quatro centímetros de espessura.

— No Banco Inter-Atlântico.

— Em que ano?

— 1990.

O programador olhou novamente para o terminal.

— E onde está o computador?

O analista apontou para outra sala.

— Lá.

Era um IBM 4341.

Nosso aventureiro sorriu.

Finalmente reconhecia alguma coisa naquele mundo.

Mas então apareceu o diretor da guilda.

— Temos uma missão S-Rank.

— Qual?

— Vamos aposentar o mainframe.

Silêncio.

O programador fechou lentamente seu laptop.

A dungeon acabara de começar.



🏰 CAPÍTULO 1 — QUANDO O COMPUTADOR ERA O CASTELO

Para um programador COBOL iniciante entender o downsizing, primeiro precisa compreender como funcionava grande parte da computação empresarial antes da popularização dos PCs.

Imagine um castelo.

Dentro dele estão os recursos mais importantes do reino:

  • CPU;

  • memória;

  • discos;

  • aplicações;

  • arquivos;

  • processamento transacional;

  • segurança;

  • operação.

Esse castelo é o mainframe.

Os usuários não carregavam pequenos castelos consigo.

Eles possuíam terminais.

Podemos simplificar a arquitetura assim:

             +-------------------+
             |     IBM 4341      |
             |                   |
             | COBOL CICS VSAM   |
             +---------+---------+
                       |
                 Controladores
                       |
          +------------+------------+
          |            |            |
       3278         3278         3278

O terminal IBM 3278 não era equivalente ao PC moderno.

Ele servia principalmente como interface entre o usuário e o sistema central.

O processamento importante acontecia no ambiente central.

Isso nos leva ao primeiro conceito.

Centralização

Na arquitetura centralizada, grande parte da capacidade computacional encontra-se concentrada.

O usuário diz:

“Quero consultar a conta 12345.”

O terminal transmite a solicitação.

CICS recebe a transação.

Um programa COBOL é acionado.

O programa acessa VSAM.

O resultado retorna.

Conceitualmente:

3278
 |
 v
CICS
 |
 v
COBOL
 |
 v
VSAM
 |
 v
COBOL
 |
 v
CICS
 |
 v
3278

Para quem está começando em COBOL, guarde esse desenho.

Ele explica uma quantidade enorme da arquitetura clássica de aplicações comerciais.



⚔️ CAPÍTULO 2 — COBOL, CICS E VSAM: OS TRÊS MAGOS DO CASTELO

O relato do Banco Inter-Atlântico menciona três tecnologias importantíssimas:

COBOL, CICS e VSAM.

Elas não são a mesma coisa.

COBOL

COBOL é a linguagem na qual podemos escrever a lógica de negócio.

Por exemplo:

IF SALDO-CONTA >= VALOR-SAQUE
    SUBTRACT VALOR-SAQUE
        FROM SALDO-CONTA
ELSE
    MOVE 'SALDO INSUFICIENTE'
        TO MENSAGEM
END-IF.

A regra é:

somente autorize o saque quando houver saldo suficiente.

COBOL representa a lógica.


CICS

CICS é um monitor de processamento transacional.

Imagine centenas ou milhares de usuários realizando:

consulta
depósito
saque
transferência
alteração cadastral
pagamento

simultaneamente.

Precisamos administrar essas transações.

É aí que entra o CICS.

Em uma analogia de RPG:

COBOL é o guerreiro.

VSAM é o inventário.

CICS é o mestre da dungeon coordenando quem pode fazer o quê e quando.


VSAM

VSAM fornece estruturas de armazenamento de dados muito utilizadas em sistemas mainframe.

Um programador iniciante provavelmente encontrará siglas como:

KSDS
ESDS
RRDS
LDS

Um KSDS, por exemplo, permite acessar registros através de chave.

Imagine:

000001 | MARIA | 1500.00
000002 | JOAO  | 3270.00
000003 | ANA   | 4341.00

Você fornece a chave:

000002

e procura o registro correspondente.

Portanto, quando o texto diz:

COBOL/CICS e VSAM

não está simplesmente despejando três siglas.

Está descrevendo boa parte de uma arquitetura transacional.



🧟 CAPÍTULO 3 — O MONSTRO NÃO ERA NECESSARIAMENTE O MAINFRAME

O Banco Inter-Atlântico enfrentava problemas.

Entre eles:

  • sistemas obsoletos;

  • analistas consumidos por manutenção;

  • usuários insatisfeitos;

  • upgrades caros.

É extremamente tentador concluir:

“O IBM 4341 era o problema.”

Nosso ex-programador levantaria a mão imediatamente.

— Prova?

Silêncio na War Room.

Essa pergunta é fundamental.

Porque:

HARDWARE ANTIGO
       ≠
SOFTWARE RUIM
       ≠
PROCESSO RUIM
       ≠
ARQUITETURA RUIM
       ≠
DÍVIDA TÉCNICA

Eles podem coexistir.

Mas não são sinônimos.

Imagine este código:

IF WS-TIPO = 'A'
    PERFORM 7000-ROTINA-ANTIGA
ELSE
    IF WS-TIPO = 'B'
        PERFORM 7100-ROTINA-NOVA
    ELSE
        PERFORM 7999-TRATAMENTO
    END-IF
END-IF.

Perguntamos:

Por que clientes A utilizam a rotina antiga?

Resposta:

— Ninguém sabe.

Quem escreveu?

— Almeida.

Onde está Almeida?

— Saiu da empresa em 1987.

Existe documentação?

— Talvez no armário do terceiro andar.

Trocar o IBM 4341 por PCs não explica a regra.

Apenas transporta o mistério para outra plataforma.

Easter egg #1

Se encontrar no fonte:

0317-ROTINA-ESPECIAL.

não mexa antes de descobrir por quê.

Às 03:17, produção sempre cobra juros.



🖥️ CAPÍTULO 4 — SURGE UMA NOVA MAGIA: DOWNSIZING

No final dos anos 1980 e começo dos anos 1990, microcomputadores tornavam-se cada vez mais poderosos.

O raciocínio parecia irresistível.

Se um computador enorme custa muito e vários computadores pequenos custam pouco, por que não substituir o grande pelos pequenos?

Nascia a febre do:

DOWNSIZING

Não significa simplesmente:

“comprar computadores menores.”

Significa transferir workloads que antes dependiam de plataformas maiores e centralizadas para plataformas menores, frequentemente distribuídas.

A transformação conceitual era:

ANTES

Terminal
   |
Mainframe
   |
Aplicação
   |
Dados

para algo parecido com:

DEPOIS

PC ----\
PC -----+---- Rede ---- Servidor
PC ----/                 |
                         Dados

Isso é uma mudança arquitetural profunda.

O PC não é mais apenas uma janela.

Ele possui:

  • CPU;

  • RAM;

  • armazenamento;

  • sistema operacional;

  • programas;

  • capacidade de processamento local.

A inteligência começa a se espalhar.


💰 CAPÍTULO 5 — "CEM VEZES MAIS BARATO!"

O vendedor entrou na dungeon.

— Tenho uma magia capaz de reduzir o custo de processamento em até cem vezes!

Nosso ex-programador cruzou os braços.

— Qual custo?

O vendedor hesitou.

E aí encontramos uma das maiores lições do caso.

Preço de hardware não é necessariamente o mesmo que:

TCO — TOTAL COST OF OWNERSHIP

Ou Custo Total de Propriedade.

Você pode comparar:

IBM 4341
versus
386 SX

e descobrir enorme vantagem de preço para o pequeno computador.

Mas a empresa não estava adquirindo simplesmente um 386.

O ambiente terminou com:

3 servidores 386 SX

98 micros entre XT e 386 SX

2 GB de armazenamento

rede

software

suporte

Agora existem dezenas de equipamentos para administrar.

Cada PC pode precisar de:

instalação
configuração
backup
suporte
manutenção
placa de rede
sistema operacional
aplicativos
atualizações

Surge então uma verdade clássica da computação distribuída:

O custo não desaparece necessariamente. Parte dele muda de lugar.


🧙 CAPÍTULO 6 — NASCE O MAGO DO SUPORTE DE DESKTOP

No mundo 3270, o usuário possuía uma interface relativamente controlada.

Com dezenas de PCs aparecem novas aventuras:

— Meu AUTOEXEC.BAT não funciona!

— Minha placa de rede sumiu!

— Não consigo mapear o drive!

— Meu CONFIG.SYS está diferente!

— O aplicativo funciona no computador do João!

— O disquete trouxe um vírus!

— Minha impressora não imprime!

— Alguém apagou o arquivo!

Bem-vindo à computação distribuída.

Você reduziu determinado tipo de centralização.

Em compensação, criou dezenas de novos pontos que precisam ser administrados.

Esse princípio permanece válido em 2026.

Troque:

PC

por:

container
microservice
VM
pod
endpoint
cloud account

e perceberá que o problema continua reconhecível.

Distribuir processamento também significa distribuir complexidade.


🌐 CAPÍTULO 7 — NETWARE: A ESTRADA ENTRE AS VILAS

O banco adotou Novell NetWare 386.

Para entender sua importância, imagine dezenas de PCs isolados:

PC     PC     PC     PC

Eles são ilhas.

Uma LAN cria estradas:

 PC \
 PC  \
 PC --- REDE --- SERVIDOR
 PC  /
 PC /

O servidor pode centralizar recursos como:

arquivos
diretórios
aplicações
impressoras
autenticação

NetWare tornou-se extremamente importante nesse período.

Era a infraestrutura que permitia transformar um conjunto de PCs em um ambiente corporativo conectado.


🔌 CAPÍTULO 8 — A REDE TAMBÉM PRECISA DE ARQUITETURA

Uma recomendação do relato parece banal:

“Planejar a rede antes de instalar.”

Não é banal.

Você precisa pensar em:

topologia
cabeamento
servidores
protocolos
capacidade
distância
crescimento
backup
segurança
impressão
falhas

Até a instalação elétrica entra na arquitetura.

Antes:

CPD
 |
infraestrutura especializada
 |
IBM

Agora:

Sala 1 → PCs
Sala 2 → PCs
Sala 3 → PCs
Gerência → PCs
Operações → PCs
Servidores → outra sala

Computação distribuída significa também distribuir:

energia, cabeamento e pontos de falha.

Não basta comprar 98 computadores e gritar:

“Transformação digital!”


💾 CAPÍTULO 9 — 2 GB ERA MUITA COISA

O jovem aventureiro de 2026 abriu seu laptop.

— Dois gigabytes? Meu celular usa isso para...

O mago interrompeu:

— Estamos em 1991.

Esse contexto é essencial.

Suponha registros comerciais com aproximadamente 200 bytes.

Um milhão deles representaria aproximadamente:

200 × 1.000.000
=
200.000.000 bytes

aproximadamente 200 MB em uma conta simplificada.

Dois gigabytes podiam armazenar enorme quantidade de dados estruturados daquela época.

Isso ensina algo importante:

Nunca avalie uma arquitetura histórica usando apenas os padrões de consumo atuais.

Um arquivo VSAM com milhões de registros comerciais pode representar enorme valor empresarial sem possuir terabytes.

Valor do dado não é proporcional ao tamanho do arquivo.


🧰 CAPÍTULO 10 — CLIPPER ENTRA NA GUILDA

Outro nome importante no relato é Clipper.

Clipper tornou-se muito conhecido no desenvolvimento de aplicações comerciais para microcomputadores.

Era comum trabalhar com estruturas como:

CLIENTES.DBF
CONTAS.DBF
MOVIMENTO.DBF

Para alguém vindo de ambientes mais centralizados, desenvolver diretamente no PC podia produzir uma enorme sensação de liberdade.

O ciclo podia parecer:

EDITAR
  ↓
COMPILAR
  ↓
EXECUTAR
  ↓
TESTAR
  ↓
CORRIGIR

Tudo perto do desenvolvedor.

Compare isso mentalmente com processos centralizados de desenvolvimento, compilação e implantação.

Não é difícil compreender por que os micros eram vistos como libertadores.


🪟 CAPÍTULO 11 — POR QUE DOS E NÃO UMA INTERFACE GRÁFICA?

Aqui existe uma decisão arquitetural muito interessante.

O banco tinha pressa.

Tempo era crítico.

Então escolheu DOS em vez de perseguir imediatamente um ambiente gráfico.

Para o arquiteto moderno, isso ensina:

Não escolha uma tecnologia simplesmente porque ela parece mais moderna. Escolha-a porque atende aos requisitos.

GUI poderia significar:

mais memória
hardware melhor
novo treinamento
novas ferramentas
maior complexidade

DOS já era conhecido e leve.

O objetivo era migrar.

Não ganhar um concurso de interface.


📦 CAPÍTULO 12 — O VERDADEIRO FEITIÇO TALVEZ TENHA SIDO O PACOTE

Existe uma frase no caso que merece enorme atenção:

“adotar pacotes prontos no lugar de desenvolvimento interno.”

Isso significa que duas variáveis foram modificadas simultaneamente.

Antes:

MAINFRAME
+
SOFTWARE DESENVOLVIDO INTERNAMENTE

Depois:

MICROS/SERVIDORES
+
PACOTES

Agora alguém anuncia:

“Nossa produtividade aumentou porque abandonamos o mainframe!”

Nosso aventureiro responde:

— Como você provou isso?

Talvez a produtividade tenha aumentado porque:

  • houve menos desenvolvimento interno;

  • processos foram padronizados;

  • interfaces melhoraram;

  • aplicações antigas foram eliminadas;

  • regras foram simplificadas;

  • hardware tornou-se mais barato;

  • usuários ganharam autonomia.

Provavelmente houve contribuição de várias dessas coisas.

Arquitetura séria exige cuidado com causalidade.


👨‍💻 CAPÍTULO 13 — O CHEFÃO FINAL ERA HUMANO

O relato diz algo extraordinariamente moderno:

O maior impasse eram as pessoas.

Eis o verdadeiro S-Rank.

Não IBM.

Não COBOL.

Não CICS.

Não NetWare.

Pessoas.

Imagine um analista que passou dez anos aprendendo:

COBOL
CICS
VSAM
3270
produção
regras bancárias

Agora o diretor anuncia:

“Vamos substituir tudo.”

O analista pode ouvir algo completamente diferente:

“Tudo aquilo que você aprendeu não vale mais.”

Isso cria:

medo
resistência
insegurança
territorialismo
desmotivação

Por isso o relato enfatizava:

  • apoio da alta administração;

  • treinamento;

  • motivação;

  • comunicação da nova cultura;

  • cronogramas realistas.

Cloud, DevOps e IA continuam tropeçando exatamente nessa dungeon.


🗺️ CAPÍTULO 14 — COMO MIGRAR SEM EXPLODIR O REINO

O IBM 4341 não foi simplesmente desligado.

A migração durou 14 meses, segundo o relato.

Essa é uma pista importantíssima.

Provavelmente existiu alguma forma de coexistência entre ambientes.

Didaticamente podemos imaginar:

FASE 1

IBM 4341
COBOL/CICS/VSAM
████████████████████

NOVO
██

Depois:

FASE 2

IBM
████████████

NOVO
████████

Depois:

FASE 3

IBM
████

NOVO
████████████████

Finalmente, em julho de 1991:

IBM
OFF

NOVO AMBIENTE
████████████████████

Essa estratégia reduz o risco do temido:

BIG BANG

O Big Bang seria:

SEXTA 18:00

IBM OFF

e:

SEGUNDA 08:00

NOVO SISTEMA ON

seguido, eventualmente, por:

SEGUNDA 08:07

WAR ROOM

E, por alguma razão inexplicável:

03:17

continua sendo o horário em que tudo resolve quebrar.

Easter egg localizado. ☕


🧪 CAPÍTULO 15 — COMO EU AUDITARIA ESSA MIGRAÇÃO

Nosso ex-programador abre seu laptop.

Não vai começar copiando arquivos.

Primeiro criará um inventário.

Passo 1 — Aplicações

Sistema
Programa
Função
Usuários
Criticidade
Dependências

Passo 2 — COBOL

Catalogar:

programas
subprogramas
copybooks
interfaces
regras especiais

Passo 3 — CICS

Identificar:

transactions
programas associados
arquivos
dependências
fluxos

Passo 4 — VSAM

Catalogar:

KSDS
ESDS
RRDS
chaves
layouts
volumetria
retenção

Passo 5 — Batch

Não esqueça do batch!

Um erro clássico seria migrar apenas aquilo que o usuário vê.

O usuário vê:

TELA

mas atrás dela podem existir:

JCL
SORT
COBOL batch
arquivos
fechamentos
relatórios
conciliações

A interface é apenas a porta da dungeon.


💰 CAPÍTULO 16 — MIGRAR DINHEIRO EXIGE RECONCILIAÇÃO

Agora chegamos ao ponto mais importante para um banco.

Imagine o mainframe dizendo:

TOTAL CONTAS:
R$ 10.000.000

Depois da migração:

NOVO SISTEMA:
R$ 9.997.413

Alguém pergunta:

— Migração concluída?

Não.

Você precisa provar que os dados mantiveram:

quantidade
valor
identidade
relacionamentos
significado

Isso é reconciliação.

Podemos criar controles como:

ANTES
1.000.000 registros

DEPOIS
1.000.000 registros

Mas quantidade sozinha não basta.

Precisamos verificar também:

soma de saldos
soma de movimentos
quantidade por categoria
hashes
amostragens
totais de controle
exceções

Em sistemas financeiros:

Mover o dado não basta. É necessário demonstrar que seu significado sobreviveu à viagem.


🏦 CAPÍTULO 17 — MAS ERA UM BANCO!

Isso torna tudo mais sério.

Aplicações bancárias precisam considerar:

integridade
consistência
segurança
concorrência
auditoria
disponibilidade
recuperação
backup
transações

Suponha:

Conta A = 1000
Conta B = 500

Transferência:

A → B = 200

Precisamos terminar com:

A = 800
B = 700

Não podemos aceitar:

A = 800
B = 500

porque o sistema caiu no meio.

Nem:

A = 1000
B = 700

Senão acabamos de criar dinheiro.

É por isso que processamento transacional não pode ser reduzido à pergunta:

“Qual computador é mais rápido?”

Existem propriedades muito mais importantes.


⚖️ CAPÍTULO 18 — MAINFRAME CONTRA PC É A PERGUNTA ERRADA

Um iniciante frequentemente procura respostas absolutas:

Mainframe é melhor?

Cloud é melhor?

Microservices são melhores?

PC é melhor?

A arquitetura responde:

Depende do workload.

Considere:

volume
transações
latência
segurança
disponibilidade
custo
crescimento
equipe
software
integração
regulação

Então:

WORKLOAD
   +
REQUISITOS
   +
RISCOS
   +
CUSTOS
   +
PESSOAS
   =
ARQUITETURA ADEQUADA

O Banco Inter-Atlântico possuía apenas 25 terminais 3278 no ambiente descrito.

Talvez uma infraestrutura menor realmente oferecesse excelente relação custo-benefício.

Isso não demonstra universalmente:

PC > MAINFRAME

Da mesma maneira que uma grande instalação financeira não demonstra:

MAINFRAME > TUDO

Arquitetura não é torcida de futebol.


🔄 CAPÍTULO 19 — E ENTÃO O PÊNDULO VOLTOU

Agora vem a ironia histórica.

Durante décadas fizemos:

MAINFRAME
   |
TERMINAL

Depois:

PC
 |
SERVIDOR

Depois:

BROWSER
 |
WEB SERVER
 |
DATABASE

Depois:

SMARTPHONE
 |
INTERNET
 |
CLOUD

E hoje temos:

NOTEBOOK
   |
HTTPS
   |
API
   |
LOAD BALANCER
   |
CONTAINER
   |
DATABASE

Nosso ex-programador olha para isso.

Depois olha para:

3278
 |
CICS
 |
COBOL
 |
VSAM

E sorri.

Não são arquiteturas tecnicamente equivalentes.

Mas existe uma ironia conceitual deliciosa.

O usuário continua muitas vezes diante de uma interface local que depende de recursos computacionais remotos.


☁️ CAPÍTULO 20 — CLOUD NÃO É UM MAINFRAME GIGANTE, MAS...

Precisamos evitar uma simplificação enganosa.

Cloud não é mainframe.

As arquiteturas, modelos operacionais, virtualização, redes, elasticidade, software e economia são diferentes.

Mas existe uma semelhança econômica interessante:

recursos caros são concentrados e compartilhados.

No passado:

Muitos usuários
      ↓
   MAINFRAME

Hoje:

Milhões de clientes
       ↓
DATACENTERS / CLOUD REGIONS

Portanto, depois de décadas celebrando a descentralização, construímos alguns dos maiores centros de processamento da história humana.

O pêndulo não voltou ao mesmo lugar.

Mas voltou a passar perto.


👻 CAPÍTULO 21 — O MAINFRAME NÃO MORREU

Durante os anos do downsizing, era fácil imaginar:

“Mais alguns anos e ninguém precisará dessas máquinas.”

Isso não aconteceu.

O que realmente perdeu força foi outra ideia:

todo processamento empresarial precisa morar no mainframe.

Essa ideia realmente foi derrotada.

Passamos a construir ambientes híbridos:

MAINFRAME
     |
     +---- API
     |
     +---- MQ
     |
     +---- Kafka
     |
     +---- Cloud
     |
     +---- Mobile
     |
     +---- Analytics
     |
     +---- IA

O mainframe deixa de precisar representar:

“toda a computação da empresa”

e pode representar:

“um motor especializado dentro de um ecossistema maior.”

Essa diferença é fundamental.


🧠 CAPÍTULO 22 — DOWNSIZING, CLOUD E IA ENSINAM A MESMA LIÇÃO

1991:

“Vamos abandonar o mainframe porque micros são mais baratos.”

2015:

“Vamos colocar tudo na cloud porque será mais barato.”

2026:

“Vamos colocar IA em tudo porque aumentará a produtividade.”

Nosso aventureiro pergunta nas três ocasiões:

— Você mediu?

Essa talvez seja a maior skill S-Rank de arquitetura.

Não acreditar cegamente.

Medir.

Para downsizing:

TCO
disponibilidade
produtividade
suporte
incidentes
tempo de resposta

Para cloud:

compute
storage
network
egress
observabilidade
operações
licenciamento

Para IA:

qualidade
tempo economizado
erros
revisão humana
tokens
risco
governança

Tecnologia nova não elimina engenharia.


🧙 CAPÍTULO 23 — AS DEZ REGRAS DO EX-PROGRAMADOR

Antes de abandonar a dungeon, nosso aventureiro deixou dez regras escritas na parede:

  1. Nunca confunda hardware antigo com arquitetura ruim.

  2. Nunca confunda hardware barato com operação barata.

  3. Descubra o workload antes de escolher a plataforma.

  4. Inventarie antes de migrar.

  5. Entenda as regras de negócio escondidas no COBOL.

  6. Não esqueça batch, interfaces e arquivos.

  7. Reconcilie os dados depois da migração.

  8. Planeje coexistência e rollback.

  9. Treine as pessoas antes de culpá-las pela resistência.

  10. Meça o resultado antes de declarar vitória.

Depois acrescentou uma décima primeira:

Se alguém disser que uma nova tecnologia vai resolver todos os problemas, verifique primeiro se ele está vendendo essa tecnologia.


🥚 EASTER EGG — O PROGRAMA COBOL ESQUECIDO

Trinta e cinco anos depois, um jovem desenvolvedor encontra um programa antigo:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. BIA0317.

      *--------------------------------------------*
      * BANCO INTER-ATLANTICO
      * NAO REMOVER SEM CONSULTAR OPERACOES
      * MIGRACAO - 1991
      *--------------------------------------------*

       PROCEDURE DIVISION.

           DISPLAY 'HELLO, OTHER WORLD'.

           STOP RUN.

Ele abre um chamado:

“Alguém sabe por que isso ainda existe?”

Um veterano responde:

“Não mexa.”

— Por quê?

— Ninguém sabe.

O ciclo está completo.


☕ EPÍLOGO — ACREDITE SE QUISER!

Em julho de 1991, segundo o relato histórico, o IBM 4341 foi finalmente desativado depois de aproximadamente 14 meses de migração.

No lugar daquele ambiente centralizado havia redes NetWare, três servidores 386 SX e quase uma centena de micros.

Os usuários estavam mais satisfeitos.

O custo teria diminuído.

A expansão continuava.

E o autor da época encerrou praticamente piscando para o leitor:

“Acredite se quiser!”

Décadas depois, aquela frase ficou ainda melhor.

Porque o mais extraordinário não é que pequenos computadores tenham conseguido substituir aquele IBM em determinado banco.

O extraordinário é perceber que a história não terminou ali.

Depois do downsizing vieram:

cliente-servidor
Internet
Web
Java
Linux
virtualização
SOA
Cloud
containers
microservices
APIs
event streaming
IA

E o velho COBOL?

Continua por aí.

CICS?

Também.

VSAM?

Também.

Mainframe?

Também.

Não porque a computação tenha parado no tempo.

Justamente pelo contrário.

A indústria descobriu que modernização nem sempre significa destruir aquilo que existia anteriormente.

Às vezes significa conectá-lo ao próximo mundo.

Nosso ex-programador finalmente abriu o portal de retorno.

Antes de atravessá-lo, olhou uma última vez para o IBM 4341 de um lado e os servidores 386 do outro.

O jovem aprendiz perguntou:

— Mestre, afinal, quem venceu? O mainframe ou o micro?

Ele respondeu:

— Você ainda está fazendo a pergunta errada.

— Então qual é a pergunta certa?

O portal começou a fechar.

O ex-programador sorriu.

“Qual arquitetura resolve melhor o problema que realmente temos?”

E desapareceu.

Na tela 3278 permaneceu apenas:

READY

Em algum lugar da empresa, entretanto, uma rotina esquecida aguardava pacientemente.

Seu nome?

0317-ROTINA-ESPECIAL

Porque certas coisas sobrevivem ao downsizing, à cloud, à inteligência artificial e, aparentemente, até mesmo ao isekai.

Bem-vindo ao mainframe, Padawan.

1


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