✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
 |
| Bellacosa Mainframe e o Cobol no Apple II |
"And now for something completely different..."
Imagine a cena.
Ano de 1982.
Você é um jovem programador COBOL.
Usa gravata.
A manga da camisa está dobrada.
Existe um cinzeiro ao lado do terminal.
O café parece petróleo refinado.
O computador custa o equivalente ao PIB de um pequeno reino medieval.
Para compilar um programa...
...você praticamente precisa pedir autorização ao sacerdote do CPD.
Então aparece uma propaganda dizendo:
("Chega de esperar.")
Nesse momento um engenheiro da IBM provavelmente derrubou o café.
Outro da Burroughs fingiu que não viu.
Um gerente da Honeywell começou a suar.
E um executivo da Micro Focus abriu uma garrafa de champanhe.
Porque aquela propaganda anunciava algo que mudaria completamente a forma de desenvolver sistemas comerciais.
Não.
Não era a chegada da Inteligência Artificial.
Nem do Cloud.
Nem do Kubernetes.
Era algo muito mais revolucionário.
Você podia compilar COBOL sentado na própria mesa.
Hoje isso parece ridiculamente normal.
Naquela época parecia magia negra.
Ou pior...
parecia concorrência.
 |
| Bellacosa Mainframe e o anuncio do Cobol para o Apple II |
Existia EsperOps
O jovem programador de hoje reclama quando uma pipeline demora cinco minutos.
Cinco.
Minutos.
Em 1982...
cinco minutos era o tempo necessário apenas para encontrar o operador responsável pela fila de compilação.
Depois vinha:
esperar liberar a CPU
esperar o compilador
esperar o Link Edit
esperar gerar o Load Module
esperar alguém descobrir que você esqueceu um ponto final.
Imagine atravessar um oceano inteiro para descobrir que escreveu:
MOVE TOTAL TO VALOR
em vez de
MOVE TOTAL TO VALOR.
Volte amanhã.
Obrigado.
Próximo.
Hoje reclamamos porque o Jenkins ficou amarelo.
Naquela época...
o próprio programador ficava amarelo.
O título da propaganda é brilhante.
Não vende COBOL.
Não vende Apple.
Não vende Micro Focus.
Vende...
tempo.
Toda tecnologia que realmente muda o mundo faz exatamente isso.
Ela devolve tempo ao ser humano.
A locomotiva devolveu tempo.
O avião devolveu tempo.
A Internet devolveu tempo.
O compilador local devolveu tempo.
Parece pouca coisa.
Mas não era.
Vamos falar desse pequeno herói improvável.
Hoje olhamos para ele e pensamos:
"Que gracinha."
Mas em 1982...
era praticamente uma estação espacial.
Possuía incríveis...
48 KB.
Ou 64 KB.
Repita comigo.
Kilo.
Não Mega.
Muito menos Giga.
Nem Tera.
Kilo.
Hoje um emoji animado ocupa mais memória.
Mesmo assim...
ele conseguia desenvolver software bancário.
Pense nisso.
O anúncio diz:
"Agora você pode criar aplicações comerciais sérias."
Traduzindo para o português corporativo:
"Não, seu diretor... isso não é um videogame."
Naquela época existia uma ideia quase religiosa.
Mainframe era sério.
Microcomputador era brinquedo.
Era como dizer hoje:
"Vamos colocar o PIX para rodar num Raspberry Pi."
A primeira reação seria:
"...você está brincando?"
O Esperanto do COBOL
Uma das frases mais inteligentes da propaganda é:
COBOL é uma linguagem padrão.
Isso parece simples.
Não era.
Imagine o caos da época.
Cada fabricante tinha seu hardware.
Seu sistema operacional.
Seu compilador.
Seu dialeto.
Seu ego.
COBOL veio com uma proposta ousada.
"Vamos todos falar praticamente a mesma língua."
Foi uma espécie de latim da informática corporativa.
Por isso tantos sistemas sobreviveram décadas.
A IBM vendia hardware.
A Burroughs vendia hardware.
A NCR vendia hardware.
Todo mundo brigava pelo computador.
A Micro Focus fez outra pergunta.
"E se o importante não for a máquina... mas o software?"
Essa pergunta vale bilhões de dólares.
Até hoje.
O Low-Code que nasceu antes do termo existir
O anúncio fala bastante do FORMS-2.
Muita gente pensa:
"Ah...
um desenhador de telas."
Não.
Muito mais.
Era praticamente um ancestral dos ambientes RAD.
Você desenhava.
Ele gerava código.
Hoje chamamos isso de:
Low-Code
No-Code
Model Driven Development
Screen Builder
UI Designer
Na época chamava-se apenas...
FORMS-2.
Às vezes basta mudar o marketing.
Agora vem a parte divertida.
Sem perceber...
essa propaganda descreve praticamente um pipeline DevOps.
Observe.
Antes:
Escreve.
Entrega.
Espera.
Compila.
Espera.
Executa.
Espera.
Corrige.
Espera.
Hoje:
Git.
Commit.
Pipeline.
Teste.
Deploy.
Pronto.
Mudou a tecnologia.
A ideia continua exatamente igual.
Eliminar espera.
Imagine.
08h00.
Você chega.
Liga o Apple II.
Ele faz "BEEP".
Você sorri.
Seu colega olha com desprezo.
— "Isso nunca vai substituir um mainframe."
09h15.
Seu programa compila.
Primeira tentativa.
Sem fila.
Sem operador.
Sem JES2.
Sem pedir autorização.
Você sorri novamente.
Seu colega começa a ficar nervoso.
11h00.
Você já corrigiu quinze bugs.
Seu amigo do CPD ainda espera a compilação.
À tarde ele finalmente recebe:
IGYPS2123-S
Descobre que esqueceu um ponto.
Volta para a fila.
Muitos programadores jovens acreditam que sempre existiram IDEs.
Não.
Durante muito tempo...
o editor era praticamente um bloco de notas glorificado.
Coloração de sintaxe?
Não.
Autocomplete?
Não.
Refactoring?
Nem em sonho.
Git?
Quem?
O avô do VSAM
Outro detalhe maravilhoso da propaganda.
Ela fala de ISAM.
Hoje pouca gente comenta isso.
Mas praticamente todo banco de dados moderno herdou alguma ideia daqueles arquivos indexados.
O conceito era simples.
Guardar informação.
Criar índices.
Buscar rapidamente.
Hoje chamamos isso de índice B-Tree.
Na época...
era simplesmente ISAM.
Observe o tamanho da embalagem.
Ela parece conter um pequeno motor V8.
Na verdade continha:
manuais
referência ANSI
exemplos
formulários
disquetes
licença
Hoje baixamos tudo em dois minutos.
Naquela época...
comprava-se software quase como quem compra uma enciclopédia.
Aliás...
era praticamente uma.
A frase
poderia perfeitamente aparecer hoje em propaganda de:
GitHub Actions
GitLab CI
Jenkins
Azure DevOps
OpenShift Pipelines
Apenas trocariam o Apple II por Kubernetes.
O marketing continua igual.
FORMS-2 provavelmente faria enorme sucesso hoje se fosse relançado com outro nome.
Algo como:
HyperAI Quantum Cloud Enterprise Low-Code Experience Platform™
Acrescentando IA em três lugares.
Naturalmente.
O Apple II possuía menos memória que uma fotografia comum enviada pelo WhatsApp.
Mesmo assim...
desenvolvia sistemas comerciais.
Isso nos obriga a fazer uma pergunta desconfortável.
Será que realmente precisamos de 32 GB de RAM para abrir um editor de texto moderno?
Ou apenas aprendemos a desperdiçar memória com mais eficiência?
Muita gente olha para esse anúncio e vê nostalgia.
Eu vejo outra coisa.
Vejo o nascimento de uma filosofia.
Desenvolver perto do programador.
Não perto do computador.
Hoje usamos:
VS Code.
Git.
Docker.
OpenShift.
GitHub.
Jenkins.
Zowe.
IDz.
Tudo isso segue exatamente a mesma ideia.
O computador central continua existindo.
Mas o desenvolvimento acontece localmente.
Isso começou muito antes do DevOps ganhar nome.
Existe algo deliciosamente britânico nisso tudo.
Imagine um sketch dos Monty Python.
Um cavaleiro entra correndo no castelo gritando:
— "Tenho uma novidade extraordinária!"
Todos param.
O rei pergunta:
— "Descobriram vida em Marte?"
— "Não."
— "Construíram um computador quântico?"
— "Também não."
— "Então o que houve?"
— "Agora conseguimos compilar COBOL sem esperar três horas!"
Silêncio absoluto.
O arauto desmaia de emoção.
Um camponês começa a aplaudir.
Um monge toca sinos.
E alguém ao fundo pergunta:
— "Mas continua precisando colocar ponto final nas frases?"
Resposta:
— "Infelizmente... sim."
Fade out.
Se você está começando agora no universo COBOL, talvez olhe para essa propaganda apenas como uma peça de museu. Não caia nessa armadilha. Ela ensina algo profundamente atual: as melhores ferramentas não são, necessariamente, as que possuem mais recursos, mas as que removem atritos do trabalho diário.
A Micro Focus não prometia inteligência artificial, computação em nuvem ou interfaces holográficas. Ela prometia algo muito mais valioso: permitir que o programador escrevesse, compilasse, testasse, corrigisse e aprendesse rapidamente. Esse ciclo curto de feedback continua sendo um dos pilares da engenharia de software moderna.
Quando você abrir hoje um editor como IBM Developer for z/OS, Visual Studio Code com IBM Z Open Editor ou qualquer ambiente moderno conectado a um mainframe IBM Z, lembre-se de que essa filosofia nasceu décadas atrás, quando um pequeno Apple II ousou desafiar a ideia de que apenas computadores gigantes podiam desenvolver sistemas gigantes.
No fim das contas, o verdadeiro protagonista dessa propaganda nunca foi o Apple II, nem o COBOL, nem o FORMS-2. Foi o tempo. A maior inovação sempre foi devolver horas preciosas ao programador para que ele pudesse pensar, criar e resolver problemas, em vez de simplesmente esperar uma compilação terminar.
E talvez essa seja a maior piada de todas: quarenta anos depois, ainda perseguimos exatamente o mesmo sonho. Apenas trocamos a fila do compilador pela fila da pipeline de CI/CD. Os nomes mudaram, os computadores ficaram milhões de vezes mais rápidos, mas a eterna luta contra o tempo continua sendo o bug mais persistente da história da computação.
 |
| Bellacosa Mainframe e o outro computador z parte vi |
"É possível construir um computador extraordinário. Mais extraordinário ainda é imaginar como conversar com ele quando ninguém jamais havia escrito um programa."
Nas cinco primeiras partes desta série, acompanhamos Konrad Zuse transformar um apartamento em laboratório, construir o Z1, evoluir para o Z2, aperfeiçoar o conceito com o Z3 e, finalmente, levar o Z4 para a ETH Zürich, demonstrando que computadores programáveis tinham utilidade prática.
Mas existe um aspecto de sua obra que, durante décadas, permaneceu praticamente esquecido.
Talvez porque fosse avançado demais.
Talvez porque a guerra interrompeu sua divulgação.
Ou talvez porque o restante do mundo ainda estivesse preocupado em construir computadores, enquanto Zuse já pensava em algo completamente diferente.
Ele queria facilitar a vida do programador.
Pode parecer uma frase comum em 2026.
Mas estamos falando do início da década de 1940.
Nem mesmo a profissão de programador existia oficialmente.
Mesmo assim, Konrad Zuse já fazia uma pergunta extraordinária:
"Por que um ser humano deveria pensar como uma máquina para conseguir utilizá-la?"
Essa pergunta continua extremamente atual.
Hoje um desenvolvedor COBOL escreve algo como:
ADD VALOR-A TO VALOR-B GIVING TOTAL.
O compilador transforma essa instrução em milhares de operações internas.
No IBM Z, isso resulta em instruções de máquina extremamente eficientes.
Mas nada disso existia em 1940.
Programar significava movimentar chaves.
Alterar conexões.
Trocar cabos.
Reposicionar painéis.
Perfurar fitas.
Modificar sequências físicas de operação.
Na prática, cada novo programa alterava o próprio computador.
Era como reescrever a instalação elétrica de uma casa toda vez que alguém quisesse acender uma lâmpada diferente.
Zuse percebeu que esse caminho não escalaria.
Entre aproximadamente 1942 e 1945, Konrad Zuse começou a desenvolver uma notação completamente nova.
Seu nome era Plankalkül.
Traduzido livremente, algo como "Cálculo de Planos" ou "Plano de Cálculo".
Não era apenas uma linguagem.
Era praticamente uma teoria sobre programação.
Décadas antes de FORTRAN.
Décadas antes de ALGOL.
Mais de quinze anos antes de COBOL.
Enquanto boa parte do mundo ainda discutia como construir computadores, Zuse já refletia sobre como escrever algoritmos de maneira compreensível para seres humanos.
É curioso imaginar um Sysprog levando um listing COBOL para mostrar a Konrad Zuse.
Provavelmente ele não entenderia a sintaxe.
Mas reconheceria imediatamente os conceitos.
Variáveis.
Atribuições.
Sequência lógica.
Modularização.
Abstração.
Era exatamente isso que ele havia sonhado décadas antes.
Naquela época, muitos acreditavam que computadores serviriam apenas para resolver equações numéricas.
Zuse discordava.
Seu Plankalkül permitia trabalhar com estruturas de dados.
Matrizes.
Registros.
Conjuntos de informações.
Operações lógicas.
Tomadas de decisão.
Em outras palavras, ele enxergava computadores manipulando informação, não apenas números.
Essa diferença parece sutil.
Na verdade, ela separa uma calculadora de um computador moderno.
Hoje parece natural declarar variáveis.
Em COBOL temos:
01 CLIENTE.
05 NOME.
05 SALDO.
Em PL/I:
DCL SALDO FIXED DECIMAL(15,2);
Em Java:
double saldo;
Mas alguém precisou imaginar esse conceito pela primeira vez.
O Plankalkül introduzia símbolos representando dados que poderiam ser reutilizados durante o algoritmo.
Hoje isso parece óbvio.
Na época era revolucionário.
Outro aspecto surpreendente.
Zuse compreendia que problemas complexos exigiam organização.
Não bastava armazenar valores isolados.
Era necessário agrupá-los.
Essa ideia aparece claramente em seu trabalho.
Quem programa COBOL imediatamente faz uma associação com:
níveis 01;
grupos;
OCCURS;
tabelas;
estruturas hierárquicas.
É evidente que COBOL não nasceu do Plankalkül.
Mas ambos compartilham uma mesma filosofia.
Representar o mundo real utilizando estruturas organizadas.
Uma linguagem de programação possui dois grandes objetivos:
Expressar claramente um algoritmo para outro ser humano.
Permitir que esse algoritmo seja executado por uma máquina.
Quanto melhor ela cumprir esses dois papéis, maior sua longevidade.
Talvez por isso COBOL continue absolutamente relevante mais de seis décadas depois.
Outro conceito presente no Plankalkül era a divisão de problemas em partes menores.
Hoje chamamos isso de:
procedimentos;
funções;
métodos;
módulos;
serviços.
Todo arquiteto de software conhece essa estratégia.
Resolver um problema gigantesco dividindo-o em pequenos problemas independentes.
Konrad Zuse já fazia exatamente isso.
Muito antes da Engenharia de Software receber esse nome.
Uma máquina precisa escolher caminhos.
Executar determinada ação.
Ou outra.
Hoje escrevemos:
IF SALDO > LIMITE
...
END-IF
Esse conceito também aparece nas ideias de Zuse.
Sem estruturas condicionais, computadores seriam incapazes de resolver problemas realmente interessantes.
É impressionante perceber quantos conceitos modernos já estavam presentes em seus manuscritos.
Então surge uma pergunta inevitável.
Se o Plankalkül era tão avançado...
Por que ele não mudou imediatamente a história da computação?
A resposta possui várias causas.
Primeiro.
A guerra.
Grande parte dos documentos permaneceu praticamente desconhecida durante anos.
Segundo.
Havia pouquíssimos computadores capazes de executar qualquer linguagem semelhante.
Terceiro.
Os pesquisadores da época estavam preocupados com problemas muito mais imediatos.
Era necessário construir hardware confiável.
As linguagens ficariam para depois.
Quando FORTRAN surgiu na década de 1950, poucos conheciam o trabalho anterior de Zuse.
O Plankalkül só seria plenamente reconhecido décadas mais tarde.
Nem sempre a melhor ideia vence imediatamente.
Na história da computação existem inúmeras tecnologias que chegaram cedo demais.
O Plankalkül talvez seja o exemplo mais famoso.
Era uma solução excelente para um problema que o restante do mundo ainda não havia percebido.
Chegamos ao momento que todo leitor do Bellacosa Mainframe esperava.
Existe alguma ligação entre Plankalkül e COBOL?
Diretamente, não.
O COBOL nasceu em um contexto completamente diferente, no final da década de 1950, impulsionado por Grace Hopper, pelo CODASYL e pela necessidade de criar uma linguagem voltada para aplicações comerciais.
Entretanto, ambos compartilham objetivos surpreendentemente semelhantes.
Os dois procuram afastar o programador dos detalhes internos da máquina.
Os dois valorizam clareza.
Os dois permitem representar estruturas complexas.
Os dois tratam programas como descrições de processos, e não como sequências de impulsos elétricos.
Em outras palavras.
Eles pertencem à mesma família filosófica.
A família da abstração.
Muito.
Talvez mais do que imagine.
Quando um desenvolvedor declara uma WORKING-STORAGE organizada.
Quando utiliza tabelas OCCURS.
Quando cria procedimentos bem definidos.
Quando separa regras de negócio da infraestrutura.
Está praticando princípios que começaram a surgir justamente nessa época.
Mudaram as linguagens.
Mudaram os compiladores.
Mudaram os processadores.
A boa engenharia permaneceu.
Um Sysprog costuma enxergar compiladores apenas como ferramentas.
Mas compiladores são verdadeiras obras de engenharia.
Eles transformam ideias humanas em instruções que a CPU consegue executar.
Quanto melhor entendemos essa transformação, melhor compreendemos o funcionamento do IBM Z.
Por trás de um simples programa COBOL existe uma longa cadeia.
Código-fonte.
Análise léxica.
Análise sintática.
Código intermediário.
Otimizações.
Instruções de máquina.
Execução.
Tudo isso só existe porque alguém, décadas atrás, decidiu que programar não deveria significar movimentar fios e relés.
Talvez o maior legado de Konrad Zuse não esteja em nenhuma máquina específica.
Nem no Z1.
Nem no Z3.
Nem no Z4.
Seu maior legado talvez seja a ideia de que computadores deveriam adaptar-se às pessoas.
E não o contrário.
Essa filosofia continua presente.
Quando utilizamos COBOL.
Quando escrevemos JCL declarativo.
Quando criamos APIs REST.
Quando descrevemos infraestrutura utilizando Ansible.
Quando perguntamos algo para uma Inteligência Artificial utilizando linguagem natural.
Cada nova camada de abstração afasta um pouco mais o ser humano da complexidade do hardware.
Konrad Zuse sonhava exatamente com isso.
Um IBM z17 executa bilhões de instruções por segundo.
Possui dezenas de núcleos.
Terabytes de memória.
Criptografia embarcada.
Inferência de Inteligência Artificial.
Virtualização sofisticada.
Entretanto, um programador continua escrevendo código utilizando conceitos como:
Variáveis.
Estruturas.
Procedimentos.
Condições.
Algoritmos.
Abstrações.
Essa talvez seja a maior vitória da computação.
Quanto mais poderoso o hardware se torna, menos precisamos pensar nele.
E essa jornada começou muito antes de FORTRAN.
Muito antes de COBOL.
Muito antes de ALGOL.
Começou quando um engenheiro alemão decidiu que computadores deveriam entender melhor as pessoas.
Até agora caminhamos ao lado de Konrad Zuse.
Mas havia outro gigante moldando silenciosamente o futuro da computação.
Enquanto Zuse criava computadores programáveis para cálculos científicos, uma empresa americana dominava governos, bancos e seguradoras com enormes máquinas eletromecânicas alimentadas por cartões perfurados.
Seu nome era IBM.
Na próxima parte responderemos uma pergunta que ainda desperta debates entre historiadores:
A IBM ignorou Konrad Zuse?
Ou será que ambos estavam resolvendo problemas completamente diferentes?
Prepare seu café.
No próximo capítulo, dois mundos finalmente se encontrarão.
O "Z" de Zuse.
E a empresa que, décadas depois, criaria o IBM Z.
Muito Antes do IBM Z Existia Outro “Z”
Viaje pelas origens da computação, conhecendo Konrad Zuse, Herman Hollerith, Tommy Flowers, John von Neumann, o Colossus, o EDVAC, o IBM System/360 e os pioneiros que construíram o caminho até o IBM Z.
Caso o navegador impeça a exibição incorporada, utilize o botão Abrir em nova guia.
 |
| Bellacosa Mainframe e a engenharia militar em 10 animes |
Ao longo deste livro vimos que engenharia militar nunca foi apenas sobre espadas, muralhas ou canhões.
Sempre foi sobre algo muito maior.
Planejamento.
Logística.
Arquitetura.
Distribuição de recursos.
Inteligência.
Comunicação.
Continuidade.
Os japoneses sempre tiveram enorme fascínio por esses temas, e isso aparece em diversos animes. Alguns retratam guerras históricas, outros apresentam impérios fictícios, batalhas espaciais ou mundos de fantasia, mas todos compartilham uma característica: mostram que nenhuma vitória depende apenas da força. Ela nasce da engenharia, da estratégia e da capacidade de coordenar pessoas e recursos.
Para um profissional IBM Z, é surpreendente perceber como muitos desses comandantes pensam exatamente como um arquiteto de sistemas críticos: observam métricas, administram recursos limitados, criam redundâncias, protegem infraestrutura e evitam decisões impulsivas.
Pegue uma xícara de café.
Vamos conhecer dez obras que ensinam muito mais do que batalhas.
Lançamento: OVA (1988–1997)
Considerado por muitos o maior anime de estratégia militar já produzido, acompanha a guerra secular entre o Império Galáctico e a Aliança dos Planetas Livres. Em vez de focar em heróis individuais, mostra logística, política, economia, inteligência e planejamento em escala interestelar.
Reinhard von Lohengramm
Yang Wen-li
Siegfried Kircheis
Paul von Oberstein
Oskar von Reuenthal
Cadeia de comando
Logística de frotas
Planejamento estratégico
Inteligência militar
Gestão de recursos
Continuidade operacional
Reinhard pensa como um arquiteto corporativo.
Yang Wen-li lembra um excelente sysprog: resolve problemas com eficiência, economiza recursos e vence utilizando conhecimento em vez de força bruta.
Lançamento: 2012
Baseado no período dos Reinos Combatentes da China, acompanha a unificação do país através de campanhas militares extremamente bem planejadas.
Xin (Shin)
Ei Sei
Ou Ki
Ri Boku
Kanki
Fortificações
Engenharia de campanha
Logística
Rotas de suprimento
Reconhecimento
Cerco
Cada campanha lembra um grande processamento Batch envolvendo centenas de dependências.
Lançamento: 1991 (OVA) / 2015 (TV)
Inspirado na antiga Pérsia, acompanha o jovem príncipe Arslan tentando reconstruir seu reino.
Arslan
Daryun
Narsus
Elam
Gieve
Construção de alianças
Inteligência
Diplomacia
Administração
Logística
Mostra que arquitetura não é apenas tecnologia.
É coordenação de pessoas.
Lançamento: 2017
Uma obra extremamente rica em geopolítica, cartografia, diplomacia e movimentação de exércitos.
Mahmut
Khalil
Kyros
Zağanos
Cartografia
Fortificações
Rotas comerciais
Inteligência
Planejamento territorial
Equivale ao desenho de uma arquitetura corporativa distribuída.
Lançamento: 2016
Ikta Solork vence batalhas utilizando matemática, logística e inteligência.
Ikta Solork
Yatorishino
Haroma
Matthew
Economia de recursos
Logística
Gestão de riscos
Engenharia de campanha
Ikta lembra um especialista em WLM.
Não desperdiça CPU.
Não desperdiça soldados.
Lançamento: 2015
O Exército Japonês atravessa um portal para um mundo medieval, demonstrando como logística, engenharia e organização superam tecnologia isolada.
Youji Itami
Rory Mercury
Lelei
Tuka
Pina Co Lada
Cadeia logística
Bases avançadas
Engenharia de campanha
Inteligência
Comunicações
Integração entre sistemas legados e tecnologias modernas.
Lançamento: 2019
Embora conhecido pelas batalhas vikings, apresenta excelente retrato sobre liderança, planejamento e organização militar.
Thorfinn
Askeladd
Canute
Thorkell
Estratégia
Moral
Liderança
Logística marítima
Mostra que liderança supera força bruta.
Lançamento: 2018
Diversos reinos disputam poder enquanto engenheiros militares organizam fortalezas, suprimentos e alianças.
Theo Cornaro
Siluca
Villar
Alexis
Administração de fortalezas
Logística
Planejamento
Diplomacia
Muito semelhante ao gerenciamento de múltiplos ambientes distribuídos.
Lançamento: 2018
Muito além da fantasia, Goblin Slayer mostra operações militares de pequena escala, reconhecimento, armadilhas, logística e engenharia de combate.
Goblin Slayer
Priestess
High Elf Archer
Dwarf Shaman
Lizard Priest
Reconhecimento
Cerco
Guerra subterrânea
Fortificações improvisadas
Controle de terreno
Cada missão lembra uma investigação de produção.
Primeiro entender.
Depois agir.
Lançamento: 2013
Apesar de ser lembrado pelos Titãs, a obra é também um tratado sobre engenharia de muralhas, logística, defesa urbana e administração de recursos limitados.
Eren Yeager
Mikasa Ackerman
Armin Arlert
Erwin Smith
Levi Ackerman
Defesa em profundidade
Muralhas
Inteligência
Reconhecimento
Gestão de crises
As três muralhas lembram perfeitamente o conceito de Defesa em Camadas (Defense in Depth): múltiplas barreiras de proteção, onde cada nível reduz o impacto caso o anterior seja comprometido.
Valkyria Chronicles
Drifters
Code Geass
Record of Grancrest War
The Twelve Kingdoms
Pumpkin Scissors
Arpeggio of Blue Steel
Mobile Suit Gundam (Universal Century)
Saga of Tanya the Evil (Youjo Senki)
Crest of the Stars
Apesar de ambientados em épocas, mundos ou galáxias diferentes, todos compartilham princípios que qualquer profissional de sistemas críticos reconhece imediatamente:
Planejamento supera improviso.
Logística vence batalhas antes do primeiro combate.
Inteligência reduz riscos.
Comunicação evita desastres.
Disciplina mantém operações funcionando.
Conhecimento compartilhado fortalece equipes.
Infraestrutura é tão importante quanto a linha de frente.
Liderança consiste em proteger pessoas, não apenas alcançar objetivos.
Um arquiteto IBM Z, um Sysprog ou um desenvolvedor COBOL provavelmente encontrará nesses animes mais do que entretenimento. Encontrará estudos de caso sobre continuidade operacional, gestão de recursos, capacidade de adaptação e tomada de decisão sob pressão.
Quando olhamos além das espadas, dos uniformes e das batalhas, percebemos que esses animes falam da mesma missão que move a engenharia de sistemas críticos.
Nenhuma fortaleza resiste apenas por possuir muralhas altas.
Nenhum Data Center permanece disponível apenas por possuir computadores rápidos.
O verdadeiro diferencial sempre esteve nas pessoas capazes de planejar, coordenar, documentar, aprender e transmitir conhecimento.
É por isso que obras como Legend of the Galactic Heroes, Kingdom, Goblin Slayer ou Attack on Titan continuam fascinando engenheiros décadas depois de seus lançamentos. Elas mostram que a tecnologia muda, mas os princípios da boa engenharia permanecem.
Talvez seja essa a maior lição para quem trabalha com COBOL e IBM Z: cada Job executado com sucesso, cada transação concluída e cada incidente evitado representam uma pequena vitória silenciosa. Assim como nas grandes campanhas militares desses animes, o verdadeiro triunfo raramente pertence ao guerreiro mais forte.
Pertence ao engenheiro que preparou a fortaleza para resistir.
☕ Um Café no Bellacosa Mainframe
Uma campanha completa sobre estratégia, logística, inteligência, segurança, liderança, continuidade, sistemas críticos, IBM Z e COBOL.
A série Engenharia Militar sem Mistérios para Programadores COBOL compara castelos, exércitos, muralhas, cadeias de comando, logística, inteligência e operações militares com os ambientes IBM Z responsáveis por bancos, governos, seguros, transportes e serviços essenciais.
Cada artigo apresenta uma parte dessa arquitetura: aplicações COBOL, Jobs JCL, transações CICS, bancos Db2, filas MQ, segurança RACF, monitoramento, contingência, liderança, documentação e continuidade operacional.
Esta relação permanece disponível no HTML da página para mecanismos de busca, leitores de tela, navegadores sem JavaScript e ferramentas de arquivamento.
