Translate

quarta-feira, 10 de novembro de 2010

Battle Beyond the Stars (1980) — Quando um Mainframe Ensina que Nem Todo Tesouro Cabe em um Data Center

 

Bellacosa Mainframe apresenta Battle Beyond the Stars

☕ Um Café no Bellacosa Mainframe

Battle Beyond the Stars (1980) — Quando um Mainframe Ensina que Nem Todo Tesouro Cabe em um Data Center

"Às vezes pensamos que a maior riqueza é aumentar a capacidade do disco. Até descobrir que um velho arquivo esquecido vale mais que todos os terabytes do mundo."


Uma viagem para 1980

Existe uma categoria de filmes que envelhece.

E existe outra que simplesmente ganha novas camadas conforme envelhecemos.

Battle Beyond the Stars, lançado em 26 de setembro de 1980 nos Estados Unidos, pertence à segunda categoria.

Na adolescência você assiste pelas explosões.

Aos vinte anos, pelas naves.

Aos quarenta, pelos personagens.

Aos cinquenta...

...você entende Gelt.

E percebe que talvez ele sempre tenha sido o verdadeiro protagonista.



Ficha Técnica

ItemInformação
Título originalBattle Beyond the Stars
BrasilMercenários das Galáxias
Ano1980
DiretorJimmy T. Murakami
ProduçãoRoger Corman
RoteiroJohn Sayles
MúsicaJames Horner
Duração104 minutos
GêneroSpace Opera
EstúdioNew World Pictures
ClassificaçãoPG (EUA)

Curiosamente...

Este foi um dos primeiros trabalhos importantes de James Horner.

Sim...

O mesmo compositor que mais tarde faria:

  • Star Trek II

  • Aliens

  • Willow

  • Braveheart

  • Titanic

  • Avatar

Muitos temas musicais que ele reutilizaria ao longo da carreira começaram aqui.


Roger Corman

Se Hollywood fosse um mainframe...

Roger Corman seria aquele engenheiro capaz de fazer um IBM 3090 competir com um z17 usando metade da memória.

Era conhecido por produzir filmes com orçamento baixíssimo.

Mas conseguia descobrir talentos como ninguém.

Por seus filmes passaram:

  • James Cameron

  • Francis Ford Coppola

  • Martin Scorsese

  • Joe Dante

  • Jonathan Demme

  • Ron Howard

Battle Beyond the Stars foi um verdadeiro laboratório de futuros gigantes do cinema.



A História

O planeta agrícola Akir vive em paz.

Até surgir o conquistador espacial:

Sador

Interpretado por John Saxon.

Ele possui um gigantesco couraçado espacial.

Seu objetivo?

Conquistar.

Pilhar.

Destruir.

Ou receber tributo.

Akir não possui exército.

Então o jovem:

Shad

recebe uma antiga nave espacial.

E parte em busca de guerreiros.

Exatamente como...

Os Sete Samurais.



A verdadeira inspiração

Battle Beyond the Stars não nasceu do nada.

Sua árvore genealógica é quase perfeita.

Os Sete Samurais (1954)

↓

Sete Homens e um Destino (1960)

↓

Battle Beyond the Stars (1980)

↓

Rebel Moon (2023)

A estrutura narrativa permanece praticamente intacta.

Apenas muda o cenário.

Samurais.

Cowboys.

Mercenários espaciais.



Os Mercenários

Cada personagem representa um arquétipo clássico.

Shad

O herói inocente.

Ainda acredita que bondade resolve problemas.


Nestor

Uma nave senciente.

Metade computador.

Metade consciência.

Algo entre HAL 9000...

e R2-D2.


Cayman

Um cowboy espacial.

Atira antes de pensar.


Saint-Exmin

Uma guerreira valquíria interestelar.

Elegância.

Precisão.

Honra.


Gelt

Aqui...

o filme muda completamente de nível.


Gelt

Gelt é um criminoso.

Assassino.

Contrabandista.

Mercenário.

Extremamente rico.

Talvez o homem mais rico da galáxia.

Mas vive sozinho.

Ninguém o visita.

Não possui amigos.

Não pode aparecer em nenhuma cidade.

Não consegue gastar seu dinheiro.

Imagine um bilionário...

condenado ao isolamento perpétuo.

Shad oferece pagamento.

Gelt ri.

Mostra montanhas de ouro.

Então o jovem diz:

"Só podemos oferecer um lar."

E tudo muda.

Ali percebemos:

A fortuna dele nunca comprou aquilo que realmente desejava.


O Plot Twist Emocional

O maior plot twist não é uma batalha.

Não é uma explosão.

É descobrir que o homem mais rico do filme...

...é também o mais pobre.

Ele aceita lutar.

Não pelo dinheiro.

Mas porque deseja experimentar novamente:

  • amizade;

  • confiança;

  • uma refeição compartilhada.

Essa transformação silenciosa é uma das maiores forças do roteiro.



Estrutura Narrativa

Podemos dividir o filme em cinco atos:

Problema

↓

Viagem

↓

Recrutamento

↓

Preparação

↓

Batalha Final

É uma estrutura usada até hoje.

Star Wars.

Os Vingadores.

Sete Homens e um Destino.

Rebel Moon.

The Magnificent Seven (2016).

Tudo bebe desta fonte.


Easter Eggs

Os fãs encontram diversos detalhes interessantes:

  • várias naves lembram modelos de Star Wars;

  • o design orgânico da nave de Nestor foi pensado para parecer quase "viva";

  • James Cameron trabalhou nos efeitos especiais e na direção de arte de miniaturas, antes de dirigir seus próprios sucessos;

  • James Horner reutilizou ideias musicais que mais tarde apareceriam em filmes como Star Trek II e Aliens.


Curiosidades

James Cameron

Antes de Terminator.

Antes de Aliens.

Antes de Titanic.

Ele trabalhou aqui construindo miniaturas e cenários.


John Sayles

O roteiro foi escrito em poucos dias.

Mesmo assim...

continua surpreendentemente sólido.


Orçamento

Cerca de US$ 2 milhões.

Pouquíssimo.

Mesmo para 1980.


Bilheteria

Arrecadou aproximadamente US$ 11 milhões em todo o mundo.

Foi considerado um bom retorno para uma produção independente e consolidou mais um sucesso de Roger Corman.


A Censura

Recebeu classificação PG nos EUA.

Hoje provavelmente seria equivalente a uma classificação para maiores de 12 anos em muitos países, por conter violência de fantasia e batalhas espaciais, mas sem excesso de sangue ou conteúdo adulto.


Impacto Cultural

Na época...

foi visto como um "Star Wars barato".

Hoje...

é considerado um clássico cult.

Isso acontece porque as pessoas passaram a enxergar o roteiro.

E não apenas os efeitos especiais.


Serviu de inspiração para...

É difícil provar influência direta em todos os casos, mas sua marca aparece em diversas obras:

  • Rebel Moon

  • jogos de RPG espacial

  • quadrinhos de mercenários espaciais

  • séries de recrutamento de equipes improváveis

Mais do que copiar cenas, herdaram a ideia de reunir especialistas muito diferentes para enfrentar um inimigo impossível.


Críticas

Os efeitos especiais não competiam com os de Star Wars.

Alguns diálogos são simples.

Alguns personagens aparecem pouco.

Mas...

o filme possui algo raro.

Personagens memoráveis.

E isso sobrevive ao tempo.


A Filosofia Escondida

Aqui está a verdadeira mensagem.

Imagine Gelt como um enorme banco de dados.

Milhões de registros.

Petabytes de riqueza.

Capacidade infinita.

Mas...

nenhuma aplicação utilizando aquelas informações.

No mundo do mainframe diríamos:

Storage

≠

Valor

Valor nasce quando existe uso.

Quando existe compartilhamento.

Quando existe comunidade.

O mesmo vale para conhecimento.

Você pode acumular milhares de PDFs.

Milhares de cursos.

Centenas de badges.

Mas, se esse conhecimento nunca ajudar alguém, ele continuará sendo apenas armazenamento.


Bellacosa Mainframe

Sempre digo aos novos profissionais:

"Não estudem para colecionar certificados. Estudem para um dia alguém lembrar do seu nome quando surgir um problema difícil."

Gelt passou a vida colecionando riqueza.

No fim, descobriu que preferia colecionar amigos.

Nós passamos anos colecionando conhecimento técnico.

No fim da carreira, percebemos que as melhores lembranças não são do compilador COBOL ou do CICS que salvamos em uma madrugada, mas das conversas no café, das risadas na sala de operações, dos colegas que confiaram em nós e das pessoas que ajudamos a formar.


Por que você deve assistir?

Porque Battle Beyond the Stars não é apenas uma aventura espacial.

É um filme sobre envelhecer.

Sobre propósito.

Sobre descobrir que existe uma diferença enorme entre ter valor e ter preço.

Você verá naves de design curioso, batalhas feitas com criatividade e um elenco cheio de figuras marcantes. Mas o que provavelmente permanecerá na memória é a jornada de Gelt: um homem que possuía tudo o que o dinheiro podia comprar e, ainda assim, atravessou a galáxia por algo que nenhum tesouro podia oferecer.

Talvez seja por isso que o filme continua vivo mais de quatro décadas depois. No fundo, ele nos lembra que todos buscamos a mesma coisa: um lugar onde sejamos bem-vindos, pessoas com quem possamos dividir uma boa conversa e, quem sabe, um café.

E essa é uma lição que continua tão atual quanto em 1980.

domingo, 7 de novembro de 2010

Isekai no Seikishi Monogatari : Quando um Programador COBOL Padawan é Transportado para Outro Mundo e Descobre que Experiência Vale Mais do que Poder

Bellacosa Mainframe apresenta isekai no seikishi monogatari


☕ Um Café no Bellacosa Mainframe

Isekai no Seikishi Monogatari (異世界の聖機師物語)

Quando um Programador COBOL Padawan é Transportado para Outro Mundo e Descobre que Experiência Vale Mais do que Poder

"No Mainframe, um bom profissional não nasce sabendo JCL, CICS ou Db2. Ele aprende observando, servindo, errando pouco e evoluindo todos os dias. Kenshi Masaki segue exatamente esse caminho."


Introdução

Quando se fala em isekai, normalmente pensamos em protagonistas superpoderosos, sistemas de RPG, telas de status, habilidades infinitas e reis demônios.

Mas anos antes dessa fórmula dominar a indústria, surgiu uma obra que seguia um caminho completamente diferente.

Isekai no Seikishi Monogatari talvez seja um dos isekais mais subestimados já produzidos.

Ao mesmo tempo em que apresenta batalhas de mechas, política internacional, tecnologia ancestral, fantasia medieval e humor, também constrói um protagonista cuja maior habilidade não é lutar.

É aprender.

Para quem trabalha com tecnologia — principalmente no universo IBM Mainframe — essa mensagem é extremamente poderosa.


Ficha Técnica

ItemInformação
Título Original異世界の聖機師物語
RomanizaçãoIsekai no Seikishi Monogatari
Título internacionalTenchi Muyo! War on Geminar
CriadorMasaki Kajishima
DiretorKoji Yoshikawa
RoteiroHideki Shirane
EstúdiosAIC Spirits e BeSTACK
Lançamento20 de março de 2009 a 19 de março de 2010
FormatoOVA
Episódios13
Duraçãocerca de 45 minutos cada
OrigemObra original (spin-off do universo Tenchi Muyo!) (Wikipedia)

O Studio

A AIC (Anime International Company) foi um dos estúdios mais influentes das décadas de 1990 e 2000.

Foi responsável por obras como:

  • Tenchi Muyo!

  • El Hazard

  • Bubblegum Crisis

  • Ah! My Goddess

  • Dual! Parallel Trouble Adventure

A parceria com a BeSTACK elevou a qualidade visual da série, especialmente nas animações dos Sacred Mechanoids, que continuam impressionantes para um OVA daquela época. (Wikipedia)


O Autor

Masaki Kajishima é conhecido principalmente por criar o universo Tenchi Muyo!

Seu estilo sempre mistura:

  • ficção científica;

  • civilizações antigas;

  • humor;

  • política;

  • romance;

  • tecnologia extremamente avançada escondida sob aparência fantástica.

Geminar é praticamente uma continuação dessa filosofia.


Sinopse

Kenshi Masaki é transportado para um planeta chamado Geminar.

Sem entender por quê, é forçado a participar de uma conspiração para assassinar a jovem imperatriz Lashara Earth XXVIII utilizando um poderoso Sacred Mechanoid.

Depois que a conspiração fracassa, Kenshi passa de assassino a protegido da imperatriz.

A partir daí começa uma longa jornada envolvendo academias, reinos, tecnologia perdida, guerras, amizades e descobertas sobre sua própria origem. (Wikipedia)


A História

Ao contrário da maioria dos isekais modernos, Kenshi não chega como um herói predestinado.

Ele simplesmente...

...trabalha.

Cozinha.

Limpa.

Constrói.

Conserta equipamentos.

Ajuda qualquer pessoa.

Isso faz com que todos passem a confiar nele.

A história mostra algo extremamente raro:

a competência cotidiana.

Kenshi conquista respeito antes de conquistar poder.



Os Personagens

Kenshi Masaki

Talvez um dos protagonistas mais completos dos isekais.

É extremamente forte.

Mas nunca depende apenas da força.

Possui enorme inteligência emocional.

Aprende rapidamente qualquer profissão.

Nunca reclama.

Nunca demonstra arrogância.

Se precisasse trabalhar em um CPD dos anos 80, provavelmente começaria organizando JCLs antes de querer alterar um sistema crítico.


Lashara Earth XXVIII

Imperatriz extremamente inteligente.

Carismática.

Politicamente habilidosa.

Percebe rapidamente que Kenshi é muito mais valioso como aliado do que como inimigo.


Chiaia Flan

Guarda-costas da imperatriz.

Excelente piloto.

Orgulhosa.

Inicialmente desconfia de Kenshi.

Depois torna-se uma de suas maiores aliadas.


Aura Shurifon

Uma das personagens mais criativas do anime.

Sua personalidade muda conforme o período do dia.

Serve tanto para humor quanto para explorar diferentes comportamentos humanos.


Maria Nanadan

Assistente da imperatriz.

Responsável por boa parte do humor.


O Mundo de Geminar

Geminar parece medieval.

Mas isso é apenas aparência.

Na prática existe:

  • tecnologia perdida;

  • engenharia extremamente avançada;

  • biotecnologia;

  • energia cristalina;

  • robôs gigantes;

  • política internacional;

  • academias militares.

É quase como visitar uma instalação IBM de 1980 e descobrir um IBM z17 funcionando atrás de uma parede antiga.


Os Sacred Mechanoids

Os Seikijin não são robôs comuns.

São máquinas antigas.

Pouquíssimos conseguem pilotá-las.

Cada piloto imprime sua personalidade no combate.

As lutas são rápidas, estratégicas e exigem habilidade, não apenas força.


O que torna este anime diferente?

Enquanto quase todos os isekais modernos seguem uma estrutura semelhante, este faz escolhas incomuns:

1. O protagonista trabalha

Não passa os episódios apenas lutando.

Ele aprende profissões.

Ajuda pessoas.

Resolve problemas.


2. O mundo parece vivo

Cada reino possui:

  • economia;

  • cultura;

  • diplomacia;

  • interesses próprios.

Nada existe apenas para servir ao protagonista.


3. O protagonista não domina tudo

Apesar de poderoso, Kenshi continua aprendendo constantemente.


4. O humor é natural

Não depende apenas de fan service.

Grande parte da comédia surge das diferenças culturais entre Kenshi e Geminar.


5. Mechas fazem sentido

Os Sacred Mechanoids não existem apenas para criar cenas de ação.

São parte fundamental da política, da economia e do equilíbrio de poder.


As Aventuras

Durante a série acompanhamos:

  • guerras entre nações;

  • conspirações políticas;

  • missões diplomáticas;

  • treinamentos;

  • torneios;

  • descobertas arqueológicas;

  • exploração tecnológica;

  • desenvolvimento dos relacionamentos.

É uma aventura muito mais ampla do que simplesmente derrotar um vilão.


Temáticas

A obra discute vários temas interessantes:

Trabalho

O esforço diário vale mais do que talento.


Humildade

Quanto mais Kenshi aprende, mais humilde se torna.


Liderança

Ele nunca exige respeito.

Ele conquista respeito.


Cooperação

Nenhum personagem resolve tudo sozinho.


Adaptação

O verdadeiro poder não é destruir.

É conseguir viver em qualquer ambiente.


As Mensagens Ocultas

O verdadeiro herói serve primeiro

Antes de comandar, Kenshi aprende a servir.

No mundo corporativo isso lembra os melhores líderes técnicos.

Primeiro entendem o sistema.

Depois lideram mudanças.


Conhecimento é acumulativo

Toda habilidade aprendida por Kenshi reaparece futuramente.

Nada é desperdiçado.


Poder sem disciplina é perigoso

Diversos antagonistas possuem mais recursos.

Mesmo assim fracassam.

Porque não possuem equilíbrio emocional.


Civilizações desaparecem quando esquecem seu conhecimento

Geminar está repleto de tecnologias antigas.

Esse tema lembra diretamente um problema enfrentado por muitas empresas:

sistemas críticos sobrevivem por décadas, mas poucos entendem como realmente funcionam.


A Filosofia Bellacosa Mainframe

Este anime parece contar a jornada de um Padawan COBOL.

Observe a evolução:

Chegada ao ambiente
→ tudo é estranho.

Aprende observando.

Aceita tarefas simples.

Ganha confiança.

Conhece a arquitetura.

Resolve pequenos problemas.

Recebe responsabilidades maiores.

Torna-se especialista.

É exatamente o caminho de um novo programador IBM Z.

Ninguém começa alterando um sistema bancário de milhões de clientes.

Primeiro aprende o ambiente.

Depois entende os processos.

Só então recebe autonomia.


Impacto Cultural

Embora nunca tenha alcançado o sucesso comercial de Sword Art Online, Re:Zero ou Mushoku Tensei, a obra conquistou status de cult entre fãs de mechas e isekais clássicos. Muitos a consideram uma precursora de vários elementos que se tornariam comuns no gênero, especialmente a combinação de fantasia, tecnologia e protagonista transportado para outro mundo. (Reddit)


Curiosidades

  • Faz parte do universo expandido de Tenchi Muyo!, mas funciona muito bem como obra independente.

  • Os OVAs têm duração próxima à de um longa-metragem dividido em capítulos.

  • A tecnologia de Geminar lembra mais uma civilização altamente avançada em decadência do que uma fantasia medieval tradicional.

  • O design dos mechas, de Naohiro Washio, foge do estilo clássico de Gundam e busca uma aparência mais orgânica. (Wikipedia)


Classificação Bellacosa Mainframe

CritérioNota
História⭐⭐⭐⭐⭐ 9,4/10
Construção do Mundo⭐⭐⭐⭐⭐ 9,8/10
Personagens⭐⭐⭐⭐⭐ 9,5/10
Mechas⭐⭐⭐⭐⭐ 9,6/10
Política⭐⭐⭐⭐⭐ 9,2/10
Desenvolvimento do protagonista⭐⭐⭐⭐⭐ 9,9/10
Trilha sonora⭐⭐⭐⭐☆ 8,8/10
Humor⭐⭐⭐⭐☆ 8,7/10
Originalidade⭐⭐⭐⭐⭐ 9,3/10
Valor para fãs de isekai clássico⭐⭐⭐⭐⭐ 9,8/10

Considerações finais

Isekai no Seikishi Monogatari não é apenas um anime sobre outro mundo. É uma história sobre crescimento profissional, humildade e aprendizado contínuo. Enquanto muitos protagonistas modernos recebem poder instantâneo, Kenshi Masaki conquista seu espaço trabalhando, observando e ajudando quem está ao seu redor.

Sob a ótica do Bellacosa Mainframe, Geminar funciona como um grande datacenter corporativo: há tecnologias antigas, regras rígidas, sistemas críticos e profissionais experientes. Kenshi representa o Padawan que chega sem conhecer aquele universo, mas que evolui por curiosidade, disciplina e disposição para aprender. A verdadeira mensagem da obra é clara: o maior diferencial de um especialista não é a força, e sim a capacidade de aprender continuamente, colaborar com a equipe e transformar conhecimento em confiança. Essa lição permanece tão atual para um piloto de Sacred Mechanoid quanto para um engenheiro de software no IBM Z.


sábado, 6 de novembro de 2010

☕🔥 EBCDIC vs ASCII — A GUERRA SILENCIOSA QUE DIVIDIU A COMPUTAÇÃO

 

Bellacosa Mainframe e a guerra entre EBCDIC versus ASCII

☕🔥 EBCDIC vs ASCII — A GUERRA SILENCIOSA QUE DIVIDIU A COMPUTAÇÃO

Se você trabalha com Mainframe…

mais cedo ou mais tarde vai descobrir uma verdade dolorosa:

“Nem todo texto é texto.”

Porque no mundo Enterprise…

uma letra “A” pode valer:

  • C1 no EBCDIC

  • 41 no ASCII

E é exatamente aí que começam:

  • arquivos corrompidos,

  • integrações quebradas,

  • caracteres estranhos,

  • “ç” virando lixo,

  • jobs falhando,

  • FTPs destruindo datasets,

  • e programadores entrando em crise existencial.

Hoje vamos mergulhar numa das maiores divisões técnicas da história da computação:

ASCII vs EBCDIC

A batalha entre:

  • o padrão do mundo aberto

  • e o padrão do império IBM.


☕ O QUE É ASCII?

ASCII significa:

American Standard Code for Information Interchange

Criado em:

1963

Padronizado pelo:

ANSI (American National Standards Institute)

Objetivo:
Criar um padrão universal de representação de caracteres.

Antes disso:
cada fabricante fazia sua própria codificação.

Resultado?
Caos absoluto.

Um computador não “entendia” o texto do outro.

ASCII veio para resolver isso.


☕ O QUE É EBCDIC?

EBCDIC significa:

Extended Binary Coded Decimal Interchange Code

Criado pela:

IBM

Ano:

1964

Baseado em:

  • BCD (Binary Coded Decimal)

  • punch cards

  • sistemas IBM 1401/360

O EBCDIC nasceu praticamente junto do:

IBM System/360

Ou seja:

o DNA do EBCDIC está ligado diretamente à história do Mainframe moderno.


☕ A DIFERENÇA TÉCNICA MAIS IMPORTANTE

A maior diferença NÃO é o tamanho.

Os dois usam 8 bits (na prática moderna).

O problema real é:

O MAPEAMENTO DOS CARACTERES

Exemplo:

CaractereASCIIEBCDIC
A41C1
B42C2
030F0
espaço2040

Ou seja:

o mesmo byte representa coisas diferentes.


☕ POR QUE ISSO IMPORTA?

Porque computadores não enxergam letras.

Eles enxergam:

bytes

Quando um sistema ASCII lê EBCDIC sem conversão:

vira lixo.

Exemplo clássico:

Você envia um dataset mainframe para Linux sem conversão.

Resultado:

  • caracteres quebrados

  • colunas desalinhadas

  • SQL inválido

  • JSON destruído

  • XML ilegível

O famoso:

“mojibake corporativo”


☕ POR QUE A IBM CRIOU O EBCDIC?

Aqui entra a parte histórica fascinante.

A IBM NÃO queria depender do ASCII.

Na época:

  • fabricantes brigavam por padrões

  • havia guerra comercial

  • ninguém queria perder controle tecnológico

A IBM já possuía:

  • sistemas baseados em cartões perfurados

  • BCD interno

  • hardware orientado ao seu ecossistema

Então ela fez:

o próprio padrão.

E como a IBM dominava o mercado corporativo…

o EBCDIC virou rei nos data centers.


☕ ENTÃO POR QUE O ASCII “VENCEU”?

Porque o mundo mudou.

ASCII tinha vantagens gigantes:

1 — Organização lógica dos caracteres

No ASCII:

Sequência
A B C D
41 42 43 44

Tudo sequencial.

Já no EBCDIC:
os caracteres ficam espalhados.

Isso dificulta:

  • sorting

  • comparações

  • parsing

  • algoritmos simples


☕ 2 — ASCII ERA MAIS SIMPLES

Universidades adotaram ASCII.

Minicomputadores adotaram ASCII.

Unix adotou ASCII.

E quando Unix dominou:

  • redes

  • internet

  • TCP/IP

  • e-mail

  • web

o ASCII virou padrão global.


☕ 3 — INTERNET

A internet praticamente nasceu ASCII.

Protocolos antigos:

  • SMTP

  • HTTP

  • FTP

  • TELNET

foram pensados em ASCII.

Mainframe precisou se adaptar.

Não o contrário.


☕ 4 — UNIX E C

A linguagem C e o Unix foram desenhados pensando em ASCII.

Muita lógica assume:

'A' + 1 == 'B'

No ASCII:
funciona perfeitamente.

No EBCDIC:
isso quebra.


☕ UMA CURIOSIDADE ABSURDA

No EBCDIC:

as letras NÃO são contínuas.

Exemplo:

Intervalo
A-I
J-R
S-Z

ficam em blocos separados.

Isso acontece por herança dos cartões perfurados IBM.

Até hoje isso surpreende desenvolvedores.


☕ OUTRA CURIOSIDADE HISTÓRICA

Muitos bugs antigos de software aconteceram porque programadores assumiam ASCII.

Quando rodavam no Mainframe:
💥 caos.

Especialmente em:

  • compiladores

  • bibliotecas C

  • middleware Unix-to-z/OS


☕ O “TRAUMA” DOS PROGRAMADORES DISTRIBUÍDOS

Um clássico do mundo enterprise:

FTP ASCII vs FTP BINARY

Se você transfere:

  • fonte COBOL

  • JCL

  • datasets texto

usa:

ASCII mode

O FTP converte EBCDIC ↔ ASCII.

Mas se você transfere:

  • load modules

  • arquivos binários

  • DBRM

  • executáveis

e usa ASCII…

você destrói o arquivo.

Literalmente.

Veteranos de mainframe têm PTSD disso até hoje.


☕ POR QUE O EBCDIC SOBREVIVEU?

Porque Mainframe:

nunca foi sobre moda.

Foi sobre:

  • estabilidade

  • compatibilidade

  • legado

  • investimento bilionário

Trocar encoding em sistemas bancários gigantescos seria um pesadelo histórico.

Imagine converter:

  • COBOL

  • CICS

  • DB2

  • VSAM

  • datasets históricos

  • aplicações financeiras

  • décadas de batch

Tudo isso sem quebrar:

  • centavos

  • juros

  • impostos

  • contratos

  • auditoria

Resultado:

EBCDIC ficou.


☕ MAS O z/OS USA SÓ EBCDIC?

Hoje:

não.

O IBM Z moderno fala praticamente tudo:

  • ASCII

  • Unicode

  • UTF-8

  • JSON

  • XML

  • REST

  • APIs

  • Linux

Inclusive:
Linux on Z usa UTF-8 normalmente.

O mundo IBM atual é híbrido.


☕ O VERDADEIRO “SUCESSOR”

Hoje o padrão dominante não é ASCII.

É:

Unicode / UTF-8

Porque ASCII não suporta:

  • japonês

  • árabe

  • emojis

  • acentos complexos

  • símbolos globais

UTF-8 virou o idioma universal.

Inclusive:
UTF-8 preserva compatibilidade ASCII nos primeiros 128 caracteres.

Genialidade pura.


☕ EASTER EGGS E CURIOSIDADES NERDS

🔥 1 — O “HELLO WORLD” QUEBRADO

Muitos programas antigos imprimiam lixo no Mainframe porque assumiam ASCII.


🔥 2 — A LETRA “{” ERA UM INFERNO

Em alguns terminais EBCDIC:
caracteres especiais mudavam dependendo da code page.

Programadores COBOL antigos sofreram MUITO com isso.


🔥 3 — CODE PAGES

Existe:

  • EBCDIC US

  • EBCDIC BRASIL

  • EBCDIC EUROPA

  • CP037

  • CP1047

  • CP500

Ou seja:
nem “o EBCDIC” é único.


🔥 4 — O ASCII TEM CONTROLE DE TELETIPO

Caracteres como:

  • CR

  • LF

  • BEL

  • ESC

vieram de teletipos mecânicos.

O famoso:

BEL

era literalmente:

tocar um sino físico.

Sim.

Um sino REAL.


🔥 5 — O MAINFRAME “TRADUZ” O MUNDO O TEMPO TODO

Hoje grande parte do middleware IBM faz:

  • conversão automática

  • transcoding

  • CCSID mapping

Sem você perceber.

CICS, MQ, DB2, Connect:Direct, FTP…
todos vivem traduzindo bytes.


☕ VANTAGENS E DESVANTAGENS

ASCIIEBCDIC
SimplesForte integração IBM
Dominou internetCompatibilidade histórica
Organização lógicaExcelente legado corporativo
Melhor interoperabilidadeIntegração perfeita com workloads antigos
Fácil para linguagens modernasDécadas de estabilidade

☕ DESVANTAGENS

ASCIIEBCDIC
Originalmente limitadoPouca interoperabilidade
Não nasceu globalMapeamento estranho
Dependia de extensõesConversões constantes
Evoluiu para UTF-8Complexidade de code pages

☕ O GRANDE PONTO FILOSÓFICO

ASCII venceu o mundo aberto.

EBCDIC venceu o mundo corporativo crítico.

ASCII construiu:

  • internet

  • Unix

  • open systems

EBCDIC sustentou:

  • bancos

  • seguradoras

  • governos

  • bolsas de valores

  • cartões de crédito

Enquanto muita gente fazia:
“Hello World”…

o Mainframe estava liquidando bilhões de dólares por segundo.


☕ FRASE FINAL ESTILO BELLACOSA MAINFRAME

“ASCII ajudou a conectar computadores.

EBCDIC ajudou a sustentar o sistema financeiro do planeta.”

sexta-feira, 5 de novembro de 2010

🐱 Maneki-neko – o gato que dá IPL na sorte

 

Bellacosa Mainframe apresenta o famoso gato da sorte maneki neko

Perfeito. Vamos de Maneki-neko no modo Bellacosa Mainframe 🐱⚙️
Origem, história, fofoca, easter egg, curiosidade inútil-útil e aquele paralelo inevitável com sistemas que não podem cair.


🐱 Maneki-neko – o gato que dá IPL na sorte

Se você já entrou num restaurante japonês, numa lojinha de bairro ou até num boteco “meio oriental”, provavelmente viu ele lá:
um gato sentado, uma patinha levantada, olhando para o nada… mas trabalhando pesado.

O Maneki-neko (招き猫) não está acenando.
Ele está chamando.

E isso muda tudo.


Maneki neko

📜 Origem: logs antigos do Japão feudal

O termo Maneki-neko vem de:

  • maneku (招く) → convidar, chamar

  • neko (猫) → gato

Ou seja:

“o gato que chama”

As origens mais aceitas ficam entre os séculos XVII e XVIII, no Período Edo, quando o Japão começa a urbanizar, surgem comércios, rotas internas e… concorrência.

Existem três lendas principais, como qualquer sistema legado respeitável.


🏯 Lenda do Templo Gotoku-ji (a mais famosa)

Um senhor feudal passava por um templo pobre durante uma tempestade.
Viu um gato levantando a pata, como se chamasse.

Curioso, se aproximou.
No instante seguinte, um raio caiu exatamente onde ele estava antes.

Resultado:

  • Sobreviveu

  • Financiou o templo

  • O gato virou símbolo de proteção + prosperidade

Failover espiritual bem-sucedido.


🏮 Lenda da velha comerciante pobre

Uma senhora, sem dinheiro, sonha com um gato dizendo:

“Faça estátuas de mim e você nunca passará fome.”

Ela obedece.
As pessoas começam a comprar.
O dinheiro volta.

Primeiro caso documentado de monetização de mascote.


🧧 Lenda da gueixa e o gato enforcado (a versão dark)

Um gato puxa o quimono da gueixa repetidamente.
Assustado, um cliente decapita o gato.

A cabeça voa, mata uma cobra venenosa que estava prestes a atacar a gueixa.

Culpa, remorso, estátuas do gato…

Backup tardio, mas com aprendizado.


🐾 A pata levantada NÃO é aleatória

Aqui entra a parte que pouca gente sabe:

  • 🐱 Pata esquerda levantada
    → chama clientes, pessoas, movimento
    → comum em lojas e restaurantes

  • 🐱 Pata direita levantada
    → chama dinheiro, prosperidade
    → comum em empresas, caixas, escritórios

  • 🐱 Duas patas levantadas
    → proteção total
    → também conhecido como “overkill visual”

Duas patas = firewall + IDS + backup offsite.


🎨 Cores e seus significados

Nada no Maneki-neko é decorativo. Tudo é configuração.

  • 🤍 Branco → pureza, novos começos (default)

  • 🖤 Preto → proteção contra azar

  • ❤️ Vermelho → saúde

  • 💛 Dourado → dinheiro (o mais vendido)

  • 💚 Verde → estudos, crescimento

  • 💗 Rosa → amor (versão moderna)


🧧 A moeda oval (koban)

Muitos Maneki-nekos seguram uma moeda com inscrição:

千万両 (sen man ryō)

Tradução livre:

“10 milhões de ryō”
(uma fortuna absurda na época)

É o equivalente espiritual a:

MAX-AMOUNT=YES


🥚 Easter eggs culturais

  • O gesto japonês de “chamar alguém” é com a palma para baixo, não para cima
    → o gato NÃO está dando tchau

  • No anime Natsume Yuujinchou, Doraemon, Pokémon, Bleach e até Hello Kitty, referências ao Maneki-neko aparecem o tempo todo

  • O bairro de Gotoku-ji, em Tóquio, tem milhares de estátuas acumuladas
    → um spool espiritual de agradecimento


🧠 Tradução para o mundo mainframe

O Maneki-neko representa:

  • Alta disponibilidade

  • Chamada constante de recursos

  • Proteção contra eventos inesperados

  • Resiliência silenciosa

Ele não faz barulho.
Não promete milagres.
fica lá, funcionando.

Como um CICS estável numa sexta-feira à noite.


☕ Comentário final estilo El Jefe

Talvez o Maneki-neko não traga dinheiro sozinho.
Mas ele lembra algo fundamental:

Sorte também é disciplina, atenção e constância.

O gato não corre atrás da prosperidade.
Ele senta, observa…
e chama.

Como todo bom sistema que dura décadas.


🐾⚙️

quinta-feira, 4 de novembro de 2010

🧠 SMP/E for z/OS – Uma Revisão

 

Bellacosa Mainframe apresenta um review smp/e 

🧠 SMP/E for z/OS – Uma Revisão

Revisão definitiva (com cheiro de fita, CSI alinhado e café frio ☕)

Se você acha que SMP/E é complicado, relaxa: ele só é honesto.
Honesto no sentido de que reflete exatamente a complexidade do z/OS — sem abstrações mágicas, sem “next, next, finish”.

SMP/E não é só uma ferramenta.
É memória histórica, controle cirúrgico e disciplina operacional.

Vamos revisar The Network do SMP/E for z/OS Workshop no melhor estilo Bellacosa Mainframe: com contexto, visão sistêmica e alguns easter eggs que só quem já brigou com um CSI entende 😉


🏛️ Antes do SMP/E: quando tudo era fita, suor e coragem

Nos anos 70, o mundo era simples — e perigoso.

  • O sistema vinha em DLIB tapes

  • O SYSGEN tinha Stage 1 e Stage 2

  • O programador montava tudo na unha

  • E manutenção?
    👉 Manual. Muito manual.

Resultado?

  • Instabilidade

  • Erros humanos

  • Sistemas que “funcionavam… até não funcionarem”

💾 Easter egg #1:

Quem nunca teve medo de rodar um IEP_COPY no volume errado… não viveu essa época.


🧬 A chegada do SMP (e depois SMP/E)

Nos anos 80, a IBM fez algo revolucionário:
automatizou o que não podia mais depender da memória humana.

Nascia o SMP, que depois evoluiu para SMP/E (System Modification Program / Extended).

Agora o sistema tinha:

  • Global Zone → cérebro

  • Target Zone → sistema em execução

  • Distribution Zone (DLIB) → fonte da verdade

Tudo documentado.
Tudo rastreável.
Tudo auditável.


🧠 O conceito-chave: CSI (Consolidated Software Inventory)

O CSI é o coração do SMP/E.

Ele responde perguntas críticas como:

  • O que está instalado?

  • Onde está?

  • Como foi construído?

  • Quem depende de quem?

Zonas:

  • Global Zone
    Índice mestre + opções de controle

  • Target Zone
    Reflete o que está rodando

  • Distribution Zone
    Reflete o que foi entregue

📌 Regra de ouro:

SMP/E não adivinha. Ele só faz exatamente o que o CSI diz.


📦 Tudo em SMP/E é SYSMOD

Não existe exceção.
Se entrou no SMP/E, virou SYSMOD.

Tipos clássicos:

  • FUNCTION → produto novo

  • PTF → serviço preventivo

  • APAR → correção corretiva

  • USERMOD → customização local (o famoso “aqui a gente fez diferente”)

Todos eles têm:

  • MCS (++ statements) → inteligência

  • Modification Text → o código

💾 Easter egg #2:

Viu ++HOLD? Pare. Respire. Leia o PSP antes de qualquer APPLY.


🔁 O fluxo eterno do SMP/E

O ciclo que nunca muda:

  1. RECEIVE

    • Entra no SMPPTS

    • Atualiza Global Zone

    • Nada muda no sistema ainda

  2. APPLY

    • Atualiza Target Libraries

    • Sistema pode ser testado

    • Ainda reversível

  3. RESTORE

    • Volta ao último nível aceito

    • Usa DLIB como fonte

    • Seu botão de “desfazer”

  4. ACCEPT

    • Atualiza DLIB

    • Ponto sem volta

    • Agora é história oficial

💣 Easter egg #3:

ACCEPT em produção sem teste é um pedido formal de incidente grave.


🌐 The Network: quando o SMP/E ganhou internet

Chegamos ao ponto alto do módulo: entrega eletrônica.

Com Shopz / JustShopz, tudo mudou:

  • Menos fita

  • Mais automação

  • Menos transporte físico

  • Mais rastreabilidade

Opções modernas:

  • ServerPac → replace completo

  • CBPDO → produto ou serviço incremental

  • Internet Delivery

    • RECEIVE FROMNETWORK

    • RECEIVE FROMNTS

    • RECEIVE ORDER

📦 Tudo chegando direto no HFS/zFS, validado por hash, protegido por certificado X.509.

🔐 Easter egg #4:

Se o RACDCERT não reconhece seu certificado, o SMP/E também não vai.


🧾 Shopz, pedidos e abas que importam

Depois de submeter o pedido:

  • Ele aparece como Open

  • Depois Submitted ou Order Center

  • E você acompanha em:
    👉 In Progress

Quando muda para Download
🎉 chegou a hora.

📬 E-mail da IBM
🔗 Link direto
⏳ 14 dias de validade


🧠 SMP/E moderno não é só manutenção

Hoje o SMP/E também:

  • Ordena PTF automaticamente

  • Agenda serviço

  • Controla origem dos fixes (SourceID)

  • Centraliza histórico

Tudo isso com:

  • RECEIVE ORDER

  • ORDER Management (Option 7)

  • Java ou ICSF

  • FTPS + Hash SHA-1


🧪 Planejamento: onde bons sysprogs se diferenciam

Antes de qualquer INSTALL:

  • Clone do sistema

  • Program Directory

  • PSP Buckets

  • Espaço em Target, DLIB e SMP/E datasets

  • IVP depois

  • Testes reais

  • Migração controlada

🧠 Easter egg final:

O melhor sysprog não é o que instala rápido.
É o que dorme tranquilo depois do IPL.


🏁 Conclusão

SMP/E não é moda.
Não é hype.
Não é simples.

Ele é engenharia de software em estado puro, aplicada a um dos ambientes mais críticos do planeta.

E se você chegou até aqui entendendo tudo isso…
👉 Parabéns: você fala fluentemente Mainframe.


quarta-feira, 3 de novembro de 2010

☕🔥 REXX Hardcore no z/OS — automação, controle e poder operacional

 

Bellacosa Mainframe apresenta o REXX

☕🔥 REXX Hardcore no z/OS — automação, controle e poder operacional  

Se você já salvou produção com um exec improvisado, já rasgou SDSF via ADDRESS, ou já ouviu

“isso dá pra automatizar em REXX, né?”
então puxa a cadeira.
Aqui é REXX técnico, sem verniz didático e com cheiro de madrugada.


🕰️ Histórico & Origem — por que o REXX virou arma de produção

O REXX (Restructured Extended Executor) nasce na IBM nos anos 80 com uma missão clara:

  • Substituir JCL “verboso”

  • Padronizar scripts

  • Criar uma linguagem legível, extensível e integrada ao sistema

Ele não foi feito para ser “bonito”.
Foi feito para controlar ambiente.

Verdade histórica:

REXX não é linguagem de apoio — é linguagem de governo operacional.


🧠 Conceito de Ambiente de Processamento

REXX não executa no vácuo.
Ele sempre roda dentro de um ambiente:

  • TSO/E

  • Batch

  • SDSF

  • ISPF

  • CICS (indiretamente)

  • Programas externos

Cada ambiente define:

  • Comandos válidos

  • RC interpretado

  • Recursos disponíveis

  • Permissões RACF

🔥 Easter egg:
O mesmo EXEC pode funcionar em TSO e falhar em Batch sem mudar uma linha.


🧩 Fundamentos da Linguagem — simples na superfície, profunda no núcleo

Sintaxe & Elementos

  • Tipagem dinâmica

  • Strings como cidadão de primeira classe

  • Sem declaração obrigatória

  • Case-insensitive (armadilha clássica)

📌 Exemplo:

parse upper arg parm1 parm2 if parm1 = '' then exit 8

Comentário ácido:
REXX perdoa erro demais — e isso cobra seu preço em produção.


🏗️ Estrutura de um Programa REXX

Todo EXEC sério tem:

  1. Identificação

  2. Validação de ambiente

  3. Tratamento de RC

  4. Controle de erro

  5. Cleanup

📌 Exemplo base:

/* REXX */ signal on error signal on failure signal on syntax address tso "ALLOC FI(IN) DA('DATASET') SHR" ... exit 0

🔥 Veterano sabe:
EXEC sem SIGNAL ON é convite ao caos.


🧮 Estrutura de Dados — tabelas na memória

REXX não tem array clássico.
Tem stem variables.

tab.1 = 'A' tab.2 = 'B' tab.0 = 2

Curiosidade:
Stem mal controlado vira memory leak conceitual.


📂 Acesso a Arquivos & Geração de Relatórios

  • ALLOC / FREE

  • EXECIO DISKR / DISKW

  • Geração de relatórios spoolados

  • Integração com SORT

📌 Exemplo:

"EXECIO * DISKR IN (STEM L.)" do i=1 to L.0 say L.i end

🔥 Easter egg:
EXECIO ignora erro… até você checar o RC.


🔃 Classificação & Manipulação de Dados

  • SORT via IDCAMS

  • SORT via ICETOOL

  • Manipulação em memória (lento)

  • Pipeline híbrido REXX + SORT

Regra de produção:

Se precisa ordenar muito, não é REXX — é SORT.


🗂️ Acesso a Diretório de PDS

REXX + ISPF services:

  • LMDINIT

  • LMMLIST

  • LMCLOSE

📌 Exemplo:

address ispexec "LMINIT DATAID(DID) DATASET('MY.PDS')" "LMMLIST DATAID(DID) OPTION(LIST)"

🔥 Veterano:
ISPF services dão poder… e risco.


🧑‍💻 Interatividade com Usuário (TSO)

  • Pseudo-conversational

  • Command-level

  • SAY / PULL

  • Mensagens controladas

Fofoquice:
Interface feia, mas resolve crise em minutos.


🧪 Modos de Execução REXX

🟢 REXX Linha de Comando (Online)

  • Interativo

  • Debug rápido

  • Dependente de perfil

🟡 REXX Batch Script (Interpretado)

  • Executa via IKJEFT01

  • Dependente de ambiente

  • Mais flexível

🔴 REXX Batch Compilado

  • Performance superior

  • RC previsível

  • Menos tolerante a erro

  • Exige processo de build

🔥 Script vs Compilado:

Interpretado é agilidade.
Compilado é confiabilidade.


🔐 REXX + RACF

REXX não ignora segurança:

  • Herda permissões do usuário

  • Pode consultar via RACROUTE (indireto)

  • Controla acesso via classes

Verdade dura:
EXEC com SPECIAL é bomba com pavio curto.


🗄️ REXX + DB2

  • DSNREXX

  • SQL dinâmico

  • RC + SQLCODE + SQLSTATE

  • Automação de consultas e relatórios

📌 Exemplo:

ADDRESS DSNREXX "EXECSQL SELECT COUNT(*) INTO :CNT FROM SYSIBM.SYSTABLES"

🔥 Easter egg:
SQLCODE ignorado vira incidente invisível.


🔀 ADDRESS — o coração da integração

ADDRESS muda o destino dos comandos:

  • TSO

  • ISPEXEC

  • SDSF

  • CONSOLE

  • DSNREXX

☕🔥 Regra sagrada:

Quem domina ADDRESS domina o sistema.


🔢 Return Code (RC) — o idioma da produção

  • RC ≠ erro sempre

  • RC precisa ser interpretado

  • Padronização é vital

if rc > 4 then exit rc

🔥 Veterano:
RC não tratado é mentira operacional.


📘 Programa do Curso — visão hardcore

Estrutura Geral / Labs

  • Ambiente restritivo

  • Casos reais

  • Incidentes simulados

Instruções REXX

  • IF, DO, SELECT

  • SIGNAL, EXIT

  • PARSE

Funções Internas / Sub-rotinas

  • Modularização

  • Reuso

  • Controle de escopo

Comandos REXX

  • SAY, PULL, TRACE

  • QUEUE / PULL

  • EXECIO

Funções TSO / CONSOLE

  • WTO

  • MODIFY

  • DUMP

  • SDSF

INTERPRET (🔥 perigoso)

  • Execução dinâmica

  • Flexibilidade extrema

  • Risco máximo

Comentário ácido:

INTERPRET é poder absoluto — use sóbrio.


🥚 Easter Eggs & Fofoquices REXX

  • Todo ambiente tem um EXEC “salvador”

  • Sempre existe um REXX sem comentários rodando há anos

  • O melhor REXX é o que não precisa ser explicado

  • Debug começa com TRACE ?R


☕🔥 Conclusão — Manifesto El Jefe REXX

REXX não é:

  • Script simples

  • Linguagem de iniciante

  • Alternativa ao COBOL

REXX é:

  • Cola do z/OS

  • Automação estratégica

  • Ferramenta de sobrevivência em produção

☕🔥 Quem domina REXX,
não programa apenas —
orquestra o mainframe.


Robert E. Howard : Quando um Programador Descobre que o Homem que Criou Conan Também Escreveu a Arquitetura da Fantasia Moderna

 

Bellacosa Mainframe apresenta o lendario Robert E. Howard criador do Conan o Barbaro

☕ Um Café no Bellacosa Mainframe

Robert E. Howard sem Mistérios para Programadores COBOL

Quando um Programador Descobre que o Homem que Criou Conan Também Escreveu a Arquitetura da Fantasia Moderna Como Quem Projetava um Sistema Crítico de Mainframe

"Alguns programadores escrevem software que sobrevive décadas. Robert E. Howard escreveu personagens que sobreviveram quase um século."


Introdução – O Programador Invisível da Fantasia

Existe uma pergunta curiosa.

Quem inventou o COBOL?

Grace Hopper participou da sua criação.

Quem inventou C?

Dennis Ritchie.

Quem inventou Java?

James Gosling.

Quem inventou Linux?

Linus Torvalds.

Agora faça outra pergunta.

Quem inventou praticamente toda a fantasia heroica moderna?

Pouquíssima gente conhece a resposta.

Robert Ervin Howard.

Seu nome talvez não seja imediatamente reconhecido.

Mas seus personagens...

Esses você conhece.

Conan.

Kull.

Solomon Kane.

Bran Mak Morn.

Red Sonja (que mais tarde seria expandida por Roy Thomas a partir de uma personagem de Howard).

Centenas de conceitos utilizados hoje em RPGs, videogames, mangás, filmes e séries nasceram de sua imaginação.

Curiosamente...

Ele fez tudo isso antes dos trinta anos de idade.

Para um programador COBOL existe uma analogia perfeita.

Howard foi para a literatura o que um arquiteto de sistemas foi para o mainframe.

Ele não criou apenas programas.

Criou uma plataforma inteira.


O Menino do Texas

Robert Ervin Howard nasceu em 22 de janeiro de 1906, em Peaster, Texas.

Seu pai era médico.

Na infância a família mudou diversas vezes acompanhando cidades ligadas ao petróleo.

Isso parece um detalhe.

Mas mudou completamente sua forma de escrever.

Howard cresceu observando cidades nascerem praticamente da noite para o dia.

Homens enriquecendo.

Empresas desaparecendo.

Violência.

Ganância.

Corridas pelo ouro negro.

Tudo isso moldou sua visão de mundo.

Ele percebeu algo muito cedo.

Civilizações não são eternas.

Empresas também não.

Tecnologias muito menos.

Esse pensamento aparece em praticamente todos os seus contos.


Howard Era um Arquiteto de Mundos

Muita gente acredita que Howard simplesmente escrevia aventuras.

Não.

Ele fazia algo muito mais sofisticado.

Primeiro criava:

  • geografia;

  • história;

  • economia;

  • religião;

  • política;

  • povos;

  • idiomas;

  • cultura;

  • conflitos.

Só depois escrevia as histórias.

Isso lembra muito um arquiteto de software.

Antes do primeiro programa existir, define-se:

  • arquitetura;

  • camadas;

  • banco de dados;

  • comunicação;

  • segurança;

  • desempenho;

  • disponibilidade.

Howard fazia exatamente isso.


A Era Hiboriana: um Grande Projeto de Software

Quando criou Conan, Howard percebeu um problema.

Se utilizasse História real...

ficaria preso aos fatos.

Então criou uma linha do tempo completamente nova.

A famosa Era Hiboriana.

Era praticamente um framework.

Depois disso bastava adicionar novas histórias.

É semelhante ao que fazemos hoje criando uma plataforma corporativa.

Primeiro vem a arquitetura.

Depois surgem centenas de aplicações.


Weird Tales: O GitHub da Década de 1930

Howard publicou grande parte de sua obra na lendária revista Weird Tales.

Imagine uma mistura de:

GitHub.

Medium.

Dev.to.

LinkedIn.

Revista científica.

Tudo ao mesmo tempo.

Era ali que escritores publicavam seus trabalhos.

Ali também estavam:

  • H. P. Lovecraft;

  • Clark Ashton Smith;

  • Seabury Quinn.

Esses autores trocavam cartas constantemente.

Não existia Internet.

Não existia e-mail.

Mesmo assim construíram uma comunidade criativa extremamente ativa.

Era praticamente um Open Source da literatura.


Easter Egg nº 1

Howard e Lovecraft escreveram dezenas de cartas discutindo filosofia, história, religião e literatura.

Essas conversas influenciaram diretamente a criação dos universos de ambos.

É como acompanhar hoje uma longa discussão técnica entre os criadores do Linux e do Kubernetes.


Conan Não Foi Seu Primeiro Personagem

Essa talvez seja uma das maiores surpresas.

Antes de Conan vieram vários personagens.

Entre eles:

  • Solomon Kane;

  • Kull;

  • Bran Mak Morn;

  • Sailor Steve Costigan;

  • El Borak.

Cada personagem explorava um aspecto diferente da natureza humana.

Conan acabou ficando famoso.

Mas Howard jamais escreveu apenas fantasia.


O Método Howard

Existe um depoimento famoso.

Howard dizia que não inventava Conan.

Ele apenas observava.

Segundo ele:

Conan "sentava-se ao seu lado" e contava suas aventuras.

Parece superstição.

Na verdade descreve algo conhecido por escritores.

Quando o personagem está suficientemente desenvolvido...

ele praticamente ganha vida.

Curiosamente acontece o mesmo com sistemas muito grandes.

Depois de décadas de evolução...

eles parecem possuir personalidade própria.

Todo veterano COBOL sabe disso.


O Código Invisível

Imagine um sistema legado.

Você abre um programa.

Não conhece quem escreveu.

Mas consegue perceber:

esse programador gostava de tabelas.

esse preferia PERFORM.

aquele utilizava GO TO.

outro fazia tudo modular.

Autores deixam assinaturas invisíveis.

Howard também.

Depois de alguns contos conseguimos identificar imediatamente seu estilo.


A Filosofia das Civilizações

Existe um tema recorrente.

Howard acreditava que:

civilizações crescem;

ficam ricas;

tornam-se burocráticas;

enfraquecem;

desaparecem.

Enquanto povos considerados "bárbaros" continuam evoluindo.

Essa ideia aparece em:

Conan.

Kull.

Bran Mak Morn.

É praticamente uma teoria sobre inovação.


Easter Egg nº 2

Décadas depois diversos historiadores observaram semelhanças entre a visão de Howard e teorias sobre ascensão e queda de impérios discutidas por autores como Oswald Spengler e Arnold Toynbee.


Howard e o Mainframe

Existe uma curiosidade interessante.

Mainframes também envelhecem.

Não porque fiquem ruins.

Mas porque acumulam conhecimento.

Um sistema bancário com cinquenta anos possui milhares de decisões incorporadas.

Howard descrevia reinos exatamente assim.

Castelos construídos sobre castelos.

Templos sobre templos.

Civilizações sobre civilizações.

É impossível não lembrar de aplicações COBOL que carregam decisões tomadas ainda na década de 1970.


Seus Personagens São Arquétipos

Conan representa sobrevivência.

Kull representa liderança.

Solomon Kane representa justiça.

Bran Mak Morn representa resistência.

El Borak representa adaptação cultural.

Cada personagem resolve um tipo diferente de problema.

Isso lembra orientação a objetos.

Cada classe possui responsabilidades específicas.


Howard Era Historiador?

Não oficialmente.

Mas estudava História compulsivamente.

Colecionava livros.

Pesquisava povos antigos.

Mitologias.

Armas.

Guerras.

Civilizações.

Grande parte do realismo presente em suas obras vem desse hábito.


Easter Egg nº 3

Howard frequentemente escrevia mapas completos dos reinos antes de produzir qualquer conto.

Décadas depois Tolkien faria algo semelhante.

Hoje chamamos isso de worldbuilding.


A Tragédia

Infelizmente sua vida terminou cedo.

Em 1936 sua mãe entrou em coma irreversível.

Howard possuía enorme ligação emocional com ela.

Ao saber que dificilmente despertaria, entrou em profunda crise.

No dia 11 de junho de 1936, aos 30 anos, disparou contra si mesmo. Morreu no dia seguinte, 12 de junho de 1936.

Sua mãe faleceu pouco depois.

Foi um desfecho trágico para um autor que produziu uma obra gigantesca em tão pouco tempo.

É importante tratar esse episódio com respeito. Ele não define sua contribuição literária, mas faz parte de sua história.


Quanto Howard Produziu?

Mesmo vivendo apenas trinta anos...

escreveu centenas de obras.

Entre elas:

  • contos;

  • poemas;

  • cartas;

  • ensaios;

  • histórias de faroeste;

  • boxe;

  • horror;

  • aventura;

  • fantasia;

  • ficção histórica.

Seu ritmo impressiona.

Era praticamente uma fábrica de criatividade.


Curiosidade Técnica

Howard escrevia em máquina de escrever.

Sem:

CTRL+Z.

Git.

Backup automático.

Cloud.

Auto Save.

Versionamento.

Se errasse uma página inteira...

precisava recomeçar.

Hoje reclamamos quando o IDE demora cinco segundos para abrir.


Easter Egg nº 4

Howard escreveu muitos contos por necessidade financeira.

Era um escritor profissional em uma época em que viver exclusivamente da escrita era extremamente difícil.

Cada conto vendido ajudava a sustentar sua vida cotidiana.


Howard Influenciou Quase Tudo

É difícil listar todos.

Mas encontramos sua influência em:

Dungeons & Dragons.

Warhammer.

Magic The Gathering.

Diablo.

The Witcher.

Elden Ring.

Dark Souls.

Berserk.

Record of Lodoss War.

Goblin Slayer.

Dragon's Dogma.

Skyrim.

Conan Exiles.

Pathfinder.

Praticamente toda fantasia de espada e feitiçaria moderna carrega algum traço de Howard.

Até mesmo muitos mangás e animes inspirados em fantasia medieval herdaram elementos que ele ajudou a consolidar: heróis errantes, reinos decadentes, ruínas de civilizações antigas e a mistura de aventura com horror cósmico.


Howard e Lovecraft

Os dois são frequentemente comparados.

Mas escreviam coisas completamente diferentes.

Lovecraft dizia:

O homem é insignificante diante do universo.

Howard dizia:

Mesmo diante de um universo hostil...

o homem ainda pode lutar.

Essa diferença explica Conan.

Explica Kane.

Explica Kull.

Howard acreditava na capacidade humana de reagir.


A Maior Lição para um Programador COBOL

Existe um motivo pelo qual Howard continua relevante quase cem anos depois.

Ele nunca escreveu pensando apenas na moda do momento.

Escreveu sobre:

coragem;

medo;

civilização;

mudança;

liderança;

ambição;

queda;

renascimento.

Esses temas nunca envelhecem.

O mesmo acontece com COBOL.

Linguagens mudam.

Frameworks aparecem e desaparecem.

Ferramentas recebem novos nomes.

Mas sistemas críticos continuam precisando de:

clareza;

confiabilidade;

resiliência;

manutenibilidade.

São princípios permanentes.


Curiosidades que Pouca Gente Conhece

Conan nunca encontrou Kull

Apesar de viverem no mesmo universo fictício, suas épocas são separadas por milhares de anos.


Howard praticava boxe

Seu interesse pelo esporte influenciou profundamente a maneira como descrevia combates: diretos, físicos e convincentes.


A correspondência de Howard é gigantesca

Suas cartas são consideradas uma fonte preciosa para entender seu processo criativo e sua visão sobre história e literatura.


A Era Hiboriana possui cronologia própria

Howard escreveu uma cronologia relativamente detalhada para manter consistência entre suas histórias, algo muito semelhante ao cuidado de manter uma arquitetura coerente em um sistema de grande porte.


O Verdadeiro Legado

Quando pensamos em Robert E. Howard, é fácil imaginar apenas um escritor de aventuras.

Isso seria uma enorme injustiça.

Ele foi um engenheiro de imaginação.

Construiu universos completos.

Projetou arquiteturas narrativas.

Definiu regras.

Criou padrões.

Produziu documentação.

Depois implementou centenas de histórias sobre essa base.

É exatamente o trabalho de um grande arquiteto de software.


Conclusão – O Arquiteto Invisível da Fantasia

Existe uma curiosa semelhança entre Robert E. Howard e os grandes profissionais de mainframe.

Ambos raramente recebem o reconhecimento proporcional ao impacto de seu trabalho.

Milhões de pessoas utilizam diariamente sistemas escritos em COBOL sem jamais saber quem desenvolveu aquelas aplicações. Da mesma forma, milhões assistem a filmes, jogam RPGs, leem mangás ou exploram videogames inspirados na fantasia heroica sem perceber que muitas das ideias fundamentais nasceram na mente de um jovem escritor texano.

Howard não apenas criou personagens inesquecíveis. Ele estabeleceu uma forma de construir mundos. Sua metodologia de planejamento, coerência histórica, geografia, política e cultura lembra a criação de uma arquitetura corporativa robusta, na qual cada componente possui uma função clara e faz sentido dentro do conjunto.

Conan ensinou coragem.

Kull ensinou liderança.

Solomon Kane ensinou investigação.

Mas o próprio Robert E. Howard ensinou algo ainda maior: antes de existir uma grande aplicação, precisa existir uma grande arquitetura.

No desenvolvimento de software, isso significa projetar antes de codificar.

Na literatura, significou construir um universo antes de escrever a primeira aventura.

Talvez seja por isso que, quase noventa anos após sua morte, suas histórias continuem vivas. Porque elas foram erguidas sobre fundamentos sólidos, assim como os melhores sistemas COBOL que ainda sustentam bancos, governos, seguradoras e empresas ao redor do mundo.

No fim das contas, Robert E. Howard nunca foi apenas um escritor.

Foi o arquiteto-chefe de uma plataforma criativa que continua sendo executada em produção pela imaginação da humanidade, release após release, geração após geração — um verdadeiro sistema legado de excelência, sem previsão de descontinuação.

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