✨ 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
💣🔥 QUANDO O BUSHIDO RODOU EM MODO CRUZ: O SAMURAI QUE NEGOU O SISTEMA — E EXECUTOU A FÉ EM PRODUÇÃO 🔥💣
⚔️ O caso mais improvável da história japonesa: samurais católicos
Se você acha que já viu tudo no Japão feudal… segura essa:
No meio de um sistema altamente fechado, hierárquico e baseado no bushido, surge um “patch externo” vindo do Ocidente: o cristianismo. E não foi só um “teste em ambiente DEV”… ele chegou a rodar em produção real — com samurais, daimyos e até generais convertidos.
Esses caras ficaram conhecidos como Kirishitan (cristãos japoneses).
E entre todos… um nome brilha como um verdadeiro job que nunca abortou:
👉 Justo Takayama Ukon
🧠 Contexto histórico (ou: quando o sistema abriu porta TCP pro Ocidente)
Tudo começa quando missionários portugueses (principalmente jesuítas como Francisco Xavier) chegam ao Japão no século XVI.
O Japão estava em modo:
⚔️ Guerra constante (Período Sengoku)
🧩 Fragmentado politicamente
💰 Aberto a comércio externo
Resultado?
👉 O cristianismo entra como:
Nova ideologia
Nova aliança política
E… sim… até estratégia de poder
Alguns daimyos adotaram a fé não só por crença… mas por vantagem geopolítica (acesso a armas de fogo, comércio com Portugal etc).
⚔️ Justo Takayama Ukon — o samurai que não deu rollback na fé
Agora entra o cara que parece script de filme… mas é real.
🧬 Quem foi ele?
Daimyo (senhor feudal)
Samurai de alto nível
Convertido ao cristianismo ainda jovem
Nome cristão: Justo
💣 O diferencial?
Ele não usou a fé como “feature opcional”.
👉 Ele fez commit total.
☠️ O conflito: sistema japonês vs sistema cristão
Quando Toyotomi Hideyoshi e depois Tokugawa Ieyasu perceberam o crescimento do cristianismo, acionaram o alerta:
🚨 “Isso aqui pode quebrar o controle do sistema.”
Motivos:
Influência estrangeira
Lealdade fora do imperador/shogun
Crescimento rápido demais
👉 Resultado: perseguição pesada
💣 O momento crítico (ou: quando pediram pra ele deletar a própria fé)
Ukon recebeu a ordem:
“Renuncie ao cristianismo… ou perca tudo.”
E aqui vem o ponto que quebra qualquer lógica “corporativa”:
Ele escolhe:
❌ Perder terras
❌ Perder status
❌ Perder poder
❌ Perder tudo
Mas…
👉 NÃO renuncia à fé
Isso é literalmente um:
IF (fé == verdadeira) IGNORAR status, poder, riqueza ENDIF
🚢 Exílio — o deploy final fora do Japão
Ele acaba exilado para Manila, nas Filipinas.
E aqui vem mais um detalhe brutal:
👉 Ele morre pouco tempo depois de chegar
Mas…
Morre respeitado
Morre firme na decisão
Morre como símbolo
✝️ Beatificação — o reconhecimento tardio
Séculos depois, ele é reconhecido oficialmente pela Igreja Católica:
👉 Beatificado em 2017
Ou seja:
💣 O cara que foi “expulso do sistema” virou referência global de fé e integridade
Bellacosa Mainframe um bug ou experimento social? Corrupted Blood no World Warcraft
💣🔥 “CORRUPTED BLOOD” — QUANDO UM MMORPG VIRou UM INCIDENTE DE PRODUÇÃO GLOBAL
🎮 O cenário do “incidente”
Em 2005, dentro do universo de World of Warcraft, um evento aparentemente “local” saiu completamente do controle: a praga “Corrupted Blood”, criada para ser um debuff limitado ao boss Hakkar the Soulflayer na dungeon Zul’Gurub.
👉 Era para ser simples:
Um efeito temporário
Contido dentro da raid
Removido após sair da área
💥 Só que… alguém “quebrou a lógica do sistema”.
🧪 O BUG que virou pandemia
Aqui entra o clássico caso de falha de boundary + persistência indevida de estado:
🔎 O que aconteceu:
Jogadores levaram pets infectados para fora da raid
O debuff continuava ativo nos pets (estado não limpo ❌)
Ao invocar o pet em cidades → BOOM 💣
NPCs também foram infectados (e não morriam → super-spreaders 😱)
Resultado:
🧬 Uma epidemia virtual não controlada 🏙️ Cidades como Stormwind viraram zonas de quarentena ☠️ Jogadores low-level morriam instantaneamente
🧠 Análise estilo Bellacosa Mainframe
Se isso fosse um ambiente z/OS, o diagnóstico seria direto:
📊 Problema raiz
Falta de isolamento transacional
Estado persistente fora do escopo previsto
Ausência de validação de contexto (raid vs mundo aberto)
🧩 Tradução para mainframe:
Isso aqui é praticamente:
Um JOB batch que deveria rodar isolado
Mas vaza dados para produção online (CICS)
E ainda deixa registros contaminados no DB2 😬
💣 Resultado: 👉 “Contaminação sistêmica de ambiente”
🧬 O mais INSANO: comportamento humano real
O evento ficou tão caótico que chamou atenção de cientistas!
Pesquisadores analisaram o caso como modelo de epidemia real. E o que apareceu?
🧠 Tipos de comportamento:
👨⚕️ “Curandeiros” → ajudavam infectados
🏃 “Fugitivos” → corriam para áreas remotas
😈 “Griefers” → espalhavam de propósito
🤷 “Negacionistas” → ignoravam o risco
Isso virou estudo sério em epidemiologia 😳 Sim… um BUG virou laboratório científico.
🧨 O equivalente em produção real
Imagina isso no mundo corporativo:
Um erro em validação de contexto
Um estado persistente indevido
Um “objeto” que propaga erro automaticamente
👉 Você não tem um bug… 👉 Você tem um efeito cascata sistêmico
No mainframe seria algo como:
RACF liberando acesso indevido
CICS replicando erro entre regiões
MQ espalhando mensagem contaminada
💀 Resultado: incidente nível “SEV1 global”
🧠 Lições de arquitetura (OURO PURO)
🔥 1. Nunca confie no escopo lógico — valide tecnicamente 🔥 2. Estado precisa ser limpo (stateless sempre que possível) 🔥 3. NPCs = processos batch sem controle → perigo extremo 🔥 4. Usuário SEMPRE vai explorar edge cases 🔥 5. Sistemas complexos geram comportamento emergente
☕ Conclusão no estilo Bellacosa
“Corrupted Blood” não foi só um bug…
Foi:
💣 Um teste de caos não planejado 🧠 Um experimento social real 🧬 Um estudo de arquitetura distribuída 🚨 Um alerta brutal sobre sistemas complexos
🚀 Frase final
👉 “O sistema não quebrou… ele só executou exatamente o que ninguém previu.”
Bellacosa Mainframe fala sobre o legado Dijkstra : Structured Programming
🧠 Structured Programming (Dijkstra) — A Revolução Silenciosa que Salvou o Software
☕ Um Café no Bellacosa Mainframe
Nos primórdios da programação, escrever código era mais parecido com montar uma gambiarra elétrica do que com engenharia. Fios cruzados, saltos imprevisíveis e um único erro podia derrubar tudo. Foi nesse caos que surgiu uma ideia simples — e revolucionária:
💡 Programas deveriam ser estruturados, previsíveis e compreensíveis.
O nome por trás dessa virada?
👉 Edsger W. Dijkstra — um dos maiores gênios da computação.
🏛️ Antes da Revolução: O Velho Oeste do Código
Nos anos 50 e início dos 60:
Programas eram gigantescos blocos lineares
Cheios de saltos incondicionais
Manutenção era um pesadelo
Bugs eram quase impossíveis de rastrear
O principal culpado? 😈
👉 O famigerado GOTO
Um comando que dizia:
“Pare o que está fazendo e vá executar ali no meio do programa.”
Resultado: o famoso spaghetti code 🍝
💣 A Carta que Mudou Tudo
Em 1968, Dijkstra publicou uma carta histórica:
👉 “Go To Statement Considered Harmful”
Essa publicação virou um terremoto intelectual na área.
Ele não estava apenas criticando um comando — estava propondo uma nova forma de pensar software.
🧱 O Conceito Central: Programas Devem Ter Estrutura
Structured Programming defende que todo programa pode ser construído usando apenas três estruturas de controle:
1️⃣ Sequência
Executar instruções na ordem.
A B C
2️⃣ Seleção (Decisão)
IF condição A ELSE B END-IF
3️⃣ Iteração (Repetição)
WHILE condição A END-WHILE
💡 Só isso. Sem saltos caóticos.
🏗️ O Impacto no Mainframe
Folha de Codificacao COBOL
Terminal 3270
Programa COBOL
Structured Programming influenciou diretamente:
COBOL moderno (COBOL-74 em diante)
Pascal (projetado para ensino estruturado)
C
Ada
praticamente todas as linguagens posteriores
No COBOL, surgiram práticas como:
PERFORM estruturado
END-IF, END-PERFORM
eliminação de GO TO sempre que possível
💬 Nos ambientes corporativos, isso foi decisivo para sistemas críticos sobreviverem décadas.
☕ Comentário Bellacosa Mainframe
Se você já abriu um programa legado cheio de:
GO TO ERRO-999 GO TO SAIDA GO TO VOLTA-LOOP GO TO TRATA-ABEND
Você sabe exatamente por que Dijkstra virou uma lenda 😅
Structured Programming não é frescura acadêmica.
👉 É o que permite um sistema bancário rodar 40 anos sem colapsar.
🕵️ Curiosidades e Bastidores
🧩 1) Dijkstra odiava computadores “bagunçados”
Ele acreditava que programação deveria ser uma disciplina matemática rigorosa.
Chegou a dizer que:
“Testar pode mostrar a presença de bugs, nunca sua ausência.”
✍️ 2) Ele escrevia à mão
Sim — muitos de seus algoritmos eram desenvolvidos no papel antes de qualquer implementação.
🧮 3) Também criou o algoritmo de caminho mínimo
👉 O famoso Algoritmo de Dijkstra, base de roteamento e GPS.
🧨 4) Nem todo mundo gostou da crítica ao GOTO
Programadores da época reagiram com:
indignação
sarcasmo
artigos contra
debates acalorados
Hoje parece óbvio. Na época, foi uma guerra cultural.
🐣 Easter Egg Mainframe
Mesmo em sistemas altamente estruturados…
👉 GO TO nunca morreu completamente.
Em COBOL legado, ele aparece como:
fuga de erro
tratamento de exceções improvisado
controle de fluxo antigo
patches históricos
É o equivalente ao:
“Não encoste nisso que está funcionando.”
🤫 Fofoquice Histórica
Dijkstra não gostava de popularização excessiva da programação.
Ele acreditava que:
👉 nem todos deveriam programar 👉 programação é atividade intelectual profunda 👉 más práticas se espalham rápido demais
Hoje, com milhões de devs no mundo… imagine o que ele diria 😄
🚀 Por que isso ainda importa HOJE?
Structured Programming é a base de:
Clean Code
Arquitetura de Software
Boas práticas corporativas
Programação orientada a objetos
Sistemas críticos
Segurança e confiabilidade
Sem essa revolução, software moderno seria inviável.
✅ Conclusão
Structured Programming não é apenas um capítulo da história.
👉 É o alicerce invisível de praticamente todo software sério já escrito.
No mundo mainframe, especialmente, ela foi a diferença entre:
💀 sistemas incontroláveis e 🏦 infraestruturas que sustentam economias inteiras
Bellacosa Mainframe e os pratos quentes e caseiros dos animes
🔥 PARTE 3 — Pratos Quentes & Caseiros Otaku
(Ou: o “JOB” que nunca dá ABEND, porque comida quente é o SPOOL da alma.)
Se no Japão a rua tem sua magia, é dentro de casa — no bentô, na cozinha pequena, no jantar simples — que acontece o verdadeiro commit de afeto.
São comidas que aparecem em animes não pela estética, mas porque representam lar, aconchego, cura e aquele warm start do coração.
1. Ramen – O “IPL da alma”
🍜 Quando o protagonista toma um golpe moral, sabe qual é o recovery? Ramen.
Origem: China → Japão, era Meiji. Base: Caldo (shoyu, miso, tonkotsu), macarrão, ovo, nori, carne. Por que aparece? Porque é barato, rápido e tem simbolismo:
→ “Você não está sozinho, coma direito.” Animes:Naruto, Bleach, Tokyo Ghoul, Durarara!! Easter Egg: Ichiraku Ramen existe de verdade em Fukuoka (e virou ponto otaku obrigatório).
🍛 É o PF favorito do Japão — curry + arroz = throughput culinário.
Origem: Trazido pela Marinha Britânica no século XIX. Textura: Espesso, doce-picante, com cenoura, batata e carne. Por que é tão popular?
→ Fácil de fazer.
→ Serve muita gente (good for bulk loads). Animes:Shokugeki no Soma, Detective Conan, Steins;Gate. Curiosidade: Há escolas no Japão que têm curry toda sexta-feira — uma espécie de “Sexta do Deploy”.
3. Katsudon – O prato da VITÓRIA
🥩 Katsu = empanado. Don = tigela. Juntos: o buff +100 determinação.
Origem: Período Meiji. Simbolismo:
→ “Katsu” soa como “vencer” → prato dos estudantes antes de prova. Animes:Yuri!!! on Ice, My Hero Academia, Gintama. Easter Egg: É o prato policial mais famoso do Japão — aparece nas cenas de interrogatório (o clichê do “confesse e te dou um katsudon”).
4. Gyūdon – O “JCL da fome”
🥣 Carne fatiada + arroz = a refeição de quem vive correndo.
Origem: Século XIX. Sabor: Doce-salgado, com cebola no dashi. Por que aparece? É literalmente o PF de trabalhador e estudante quebrado. Animes:Food Wars, Death Note, Silver Spoon. Curiosidade: Yoshinoya e Sukiya são rivais tão fortes quanto Quadra B vs Quadra C no CECAP.
5. Udon – O macarrão “kernel mode”
🍜 Grossão, macio, reconfortante — tipo abraço quente de vó.
Origem: China → Japão, século IX. Destaque: Caldo leve, macarrão espesso. Animes:Boruto, Hanasaku Iroha, Ristorante Paradiso. Comentário Bellacosa: Slurp barulhento é cultural. No Brasil parece feio. No Japão significa “tô feliz”.
6. Oyakodon – O prato com o nome mais estranho
🐔 Literalmente “Tigela Pai-e-Filho” (frango + ovo). Japão sendo Japão.
Origem: Século XIX. Ingredientes: Frango, cebola, ovo cremoso sobre arroz. Simbolismo:
→ Conforto, família, cuidado. Animes:Shokugeki no Soma, Lucky Star. Easter Egg: No mundo otaku, é meme desde sempre por causa do nome.
7. Nikujaga – O prato que toda mãe japonesa tem no repertório
🥔 Carne ensopada com batata. O “feijão com arroz” do Japão.
Origem: Inspirado no beef stew britânico. Sabor: Doce-salgado, suave, nostálgico. Animes:Clannad, March Comes in Like a Lion, Anohana. Curiosidade: É considerado teste de “boa esposa” nos dramas antigos — cringe, mas culturalmente real.
8. Tamagoyaki – O omelete OTIMIZADO
🍳 Camadas enroladas de ovo. Tão bonito que parece editado no Photoshop.
Origem: Século XVII. Uso: Bentô, cafés da manhã, sushi. Animes:Bungo Stray Dogs, Demon Slayer, Ghibli em geral. Easter Egg: Em Ghibli, tamagoyaki sempre aparece quando o protagonista está prestes a virar gente grande.
9. Sukiyaki – O prato das festas e encontros importantes
🥘 Carnes finas cozidas à mesa, molho doce, vegetais e tofu.
Origem: Era Edo. Simbolismo: Reunião, amizade, celebração. Animes:Working!!, Ranma ½, Fruits Basket. Comentário: É quase uma feijoada japonesa — não pelo sabor, mas pelo clima social.
10. Oden – O “buffer quente” do inverno japonês
🍢 Rabanete, ovo, tofu, konnyaku, tudo nadando num caldo quente e suave.
Origem: Século XIV. Sabor: Leve, reconfortante, perfeito pro frio. Animes:One Piece, Tokyo Revengers, Mob Psycho 100. Easter Egg: Luffy ama oden — e quem não ama?
11. Bento Caseiro – O pacote .ZIP da comida japonesa
🍱 Tudo organizado, fofo e pensado com carinho — parece JCL bem comentado.
Origem: Século XIII. Por que é especial nos animes?
→ Demonstra amor ou cuidado.
→ Mostra personalidade (bentôs desastrados são clássicos). Animes:Kimi ni Todoke, Tonikawa, Your Name.
12. Miso Soup – O “IPL nutritivo” diário
🥣 Sopa de pasta de soja fermentada. Simples, mas identitária.
Origem: Século VIII. Importância: Presença obrigatória no café da manhã japonês. Animes:Barakamon, Way of the Househusband, Angel Beats.
13. Nabe (Hot Pot) – Quando junta todo mundo no mesmo caldeirão
🍲 O prato social definitivo.
Origem: Antigo Japão rural. Função: Aquece o corpo e a relação entre personagens. Animes:Yuru Camp, Haikyuu!!, Kuroko no Basket. Easter Egg: Episódios de nabe geralmente fazem o fandom shippar casais.
14. Okonomiyaki – A “panqueca que aceita parâmetros”
🥞 “Okonomi” = do jeito que quiser. “Yaki” = grelhar.
Origem: Hiroshima e Osaka (rivalidade eterna). Ingredientes: Repolho, massa, carne, queijo, frutos do mar. Animes:Shokugeki no Soma, Ranma ½, Silver Spoon. Curiosidade: Hiroshima e Osaka se odeiam por causa da receita — tipo briga de SYS1 e SYS2.
15. Tonjiru – A sopa reforçada dos trabalhadores
🥩 Miso soup turbinada com carne de porco e legumes.
📜 A Latrina de Ibitinga — O Vilão Final do Arc Rural
Ao estilo Bellacosa Mainframe, para o glorioso El Jefe Midnight Lunch.
Ah, Ibitinga…
Terra mágica das tanajuras crocantes, do sítio encantado, onde o fusquinha vermelho desafiando estradas sem pavimento, no barro, com buracos, com poeira, onde a comida do forno a lenha tinha gosto de abraço de avó, onde os vaga-lumes piscavam como LEDs de placa-mãe iluminando a noite rural.
Ali, entre galos orgulhosos, galinhas tagarelas, pintainhos confusos e frutas colhidas no pé, o coração da criança pulsava mil aventuras por minuto.
Mas como todo bom enredo — seja anime, HQ, novela mexicana ou crônica mainframe — sempre existe um vilão.
E naquele sítio o vilão tinha nome, cheiro, presença e uma arquitetura digna de Silent Hill Rural Edition:
💀 A Latrina.
🚪 A Cabine do Terror em Madeira Duvidosa
A latrina de Ibitinga era uma estrutura icônica:
uma casinha de madeira simples, meio torta, feita com tábuas que rangiam como portas de dungeon mal lubrificadas.
Ali, no meio do cafezal, parecia um boss final aguardando a vítima entrar:
“Você precisa enfrentar o medo para liberar o buffer interno.”
Podia ter vaga-lume, grilo, galinha, até o galo cantando sinfonias matinais…
Mas pisou na porta da latrina: reset emocional.
🕳️ A Fossa Abissal
A parte inferior da latrina era uma fossa funda, negra, úmida, fedida, viva.
Um verdadeiro poço das trevas, um buraco de RPG com level 99 de toxicidade.
Embaixo, borbulhando, estava o inferno biológico:
O Abismo da Merda.
Se Dante Alighieri tivesse visitado Ibitinga antes de escrever A Divina Comédia,
teria acrescentado esse círculo do inferno, com certeza.
E, sobre esse abismo, sustentando a integridade da missão fisiológica, havia:
🪵 Duas tábuas.
Só isso.
Duas tábuas velhas.
Passadas, empenadas, talvez carcomidas.
Tábuas que pareciam olhar pra você e sussurrar:
“Vai cair, campeão.”
🧎♂️ O Ninja Rural: Operação Cocorô
Para executar o famoso número 2, não era simples sentar e contemplar a vida.
Era uma operação de guerra:
Entrar.
Fechar a porta torta.
Ajustar os pés sobre as tábuas suspeitas.
Abaixar-se cuidadosamente.
Encontrar equilíbrio zen.
Rezar para todas as divindades conhecidas e desconhecidas.
Executar o processo sem tremer as pernas.
Torcer para que nada caia (incluindo você).
Era literalmente ficar de cócoras, como um ninja do esgoto, a centímetros de despencar no buraco existencial.
E o medo era real. Muito real.
Não importava que nunca tivesse acontecido com ninguém.
Na cabeça da criança, havia sempre a possibilidade de:
BREAKPOINT: TÁBUA QUEBRA
FATAL ERROR: MERGULHO EM MERDA
GAME OVER
🎉 O Duplo Prazer da Sobrevivência
O ato era físico, claro.
Mas a vitória era psicológica.
Ao sair da latrina, duas coisas aconteciam ao mesmo tempo:
A alma ficava leve.
O coração celebrava: “Eu sobrevivi!”
Era quase um rito tribal.
Uma iniciação rural.
Um achievement desbloqueado:
“Escapei da Fossa +10 de coragem.”
E, depois disso, tudo voltava à magia:
os grilos, as cigarras, o brilho dos vaga-lumes, as galinhas em fila indiana, a charrete na madrugada com lampião tremulando, o colchão de palha fazendo crec crec, o céu estrelado que mais parecia BIOS gráfico da natureza.
Sim, Ibitinga era quente.
Quente na memória, no coração e no afeto.
Mas nada — absolutamente nada — supera a emoção de ter enfrentado…
Bellacosa Mainframe e a engenharia militar parte ix
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Capítulo IX — Inovação, Evolução e o Futuro: Quando a Engenharia Militar Encontra a Inteligência Artificial
Quando um Programador COBOL Descobre que o Futuro Nunca Substitui a Fortaleza... Apenas Constrói Novas Muralhas Sobre Alicerces Antigos
O castelo permanecia de pé havia mais de quatrocentos anos.
Suas muralhas resistiram a guerras.
Incêndios.
Terremotos.
Tempestades.
Mudanças de governo.
Mudanças de imperadores.
Mudanças de armas.
O jovem comandante observava os canhões recém-instalados.
Depois olhou para as antigas muralhas de pedra.
Perguntou ao velho engenheiro:
— Mestre...
se agora temos canhões...
por que ainda conservamos estas velhas muralhas?
O velho sorriu.
— Porque os canhões mudaram.
A guerra mudou.
Mas a Física continua sendo a mesma.
O silêncio tomou conta do pátio.
— Toda inovação inteligente respeita aquilo que continua verdadeiro.
Séculos depois...
09h42.
Uma reunião discutia Inteligência Artificial.
Cloud.
APIs.
Containers.
Quantum Computing.
Agentes Autônomos.
O recém-contratado comentou entusiasmado:
— O COBOL acabou.
O arquiteto veterano apenas perguntou:
— Quem processará o pagamento do salário da sua empresa amanhã às oito da manhã?
A sala ficou silenciosa.
Pegue seu café.
Hoje falaremos sobre inovação.
Mas não da inovação que destrói.
Da inovação que aprende primeiro por que algo sobreviveu durante sessenta anos.
1. O erro de confundir novidade com evolução
Existe uma armadilha comum.
Imaginar que tudo o que é novo automaticamente substitui o antigo.
A História demonstra exatamente o contrário.
A espada não desapareceu imediatamente com a pólvora.
O cavalo continuou sendo utilizado durante décadas.
Fortalezas continuaram existindo mesmo após o surgimento dos canhões.
Navios à vela coexistiram com navios a vapor.
A engenharia raramente evolui por substituição instantânea.
Ela evolui por integração.
2. O Castelo Aprende
Imagine um castelo construído em 1400.
Ao longo dos séculos ele recebe:
novos portões;
novas torres;
canhões;
depósitos;
observatórios;
sistemas hidráulicos.
Ele muda continuamente.
Mas permanece sendo o mesmo castelo.
O IBM Z evolui exatamente assim.
Cada geração incorpora:
novos processadores.
mais criptografia.
IA embarcada.
virtualização.
aceleradores.
novos compiladores COBOL.
integração com Linux.
OpenShift.
APIs.
Cloud.
Sem abandonar décadas de conhecimento acumulado.
3. O Maior Patrimônio Nunca Foi o Código
Quando observamos um sistema COBOL antigo costumamos enxergar milhões de linhas.
Na realidade...
essas linhas representam décadas de decisões de negócio.
Cada IF.
Cada EVALUATE.
Cada regra tributária.
Cada cálculo atuarial.
Cada validação.
É conhecimento empresarial transformado em software.
Reescrever tudo do zero significa correr o risco de esquecer parte desse conhecimento.
4. O Valor da Evolução Incremental
Na engenharia militar raramente se derruba um castelo inteiro para construir outro.
Reforça-se uma torre.
Amplia-se um depósito.
Melhora-se uma muralha.
Substitui-se um portão.
Na arquitetura de software chamamos isso de evolução incremental.
Pequenas melhorias constantes costumam produzir resultados mais seguros do que grandes revoluções.
5. A Inteligência Artificial Como Conselheira
Existe muito entusiasmo em torno da IA.
E com razão.
Ela pode:
analisar documentação;
explicar código COBOL;
identificar padrões;
sugerir testes;
propor refatorações;
traduzir regras de negócio;
gerar documentação inicial.
Mas existe uma diferença importante.
Ela auxilia.
Quem responde pela decisão continua sendo o engenheiro.
Assim como um excelente mapa não substitui o comandante.
6. O Perigo da Automação Sem Compreensão
Imagine uma enorme catapulta automática.
Ela dispara perfeitamente.
Mas ninguém verifica para onde está apontando.
Automação sem entendimento apenas acelera erros.
Em tecnologia isso ocorre quando:
scripts são executados sem revisão;
deploys são aprovados automaticamente;
agentes recebem permissões excessivas;
decisões críticas deixam de ser auditadas.
Velocidade nunca deve substituir responsabilidade.
7. APIs — As Novas Estradas do Reino
Nos capítulos anteriores falamos sobre estradas romanas e rotas de suprimentos.
Hoje essas estradas também são digitais.
As APIs conectam:
mainframe;
mobile;
cloud;
ERP;
portais;
Inteligência Artificial;
microsserviços.
Elas permitem que sistemas escritos em épocas diferentes trabalhem juntos.
Não substituem o castelo.
Constroem novas estradas até ele.
8. O COBOL Conversa com o Mundo
Durante muitos anos existiu um mito.
"O mainframe é isolado."
Na realidade moderna encontramos:
REST.
JSON.
MQ.
Kafka.
gRPC.
OpenAPI.
z/OS Connect.
OpenShift.
Linux on IBM Z.
Python.
Java.
Node.js.
Todos convivendo com COBOL.
A fortaleza abriu novos portões.
Mas continua protegendo o tesouro.
9. A Engenharia da Confiança
Imagine um banco.
Você deposita dinheiro hoje.
Volta daqui a vinte anos.
Espera encontrá-lo corretamente registrado.
Essa confiança não nasce da moda tecnológica.
Nasce da engenharia.
Por isso sistemas críticos valorizam tanto:
consistência;
auditabilidade;
integridade;
rastreabilidade;
continuidade.
Esses princípios continuarão importantes mesmo daqui a cinquenta anos.
10. Computação Quântica
Muito se fala sobre computadores quânticos.
Eles representam uma enorme oportunidade.
Mas também enormes desafios.
Especialmente para criptografia.
Assim como a pólvora obrigou castelos a evoluírem...
novas tecnologias obrigarão arquiteturas digitais a evoluírem.
A resposta continuará sendo engenharia.
Não pânico.
11. Observabilidade — As Torres do Século XXI
Antigamente existiam vigias observando o horizonte.
Hoje observamos:
logs.
métricas.
traces.
eventos.
telemetria.
painéis.
alertas.
A observabilidade moderna funciona como milhares de sentinelas distribuídos por toda a fortaleza.
Quanto mais cedo percebemos mudanças...
mais cedo reagimos.
12. Zero Trust Continua Atual
Mesmo utilizando IA.
Cloud.
Containers.
Quantum.
O princípio permanece.
Nunca confiar automaticamente.
Verificar sempre.
A tecnologia muda.
Os fundamentos permanecem.
13. O Futuro do Profissional COBOL
Existe uma pergunta recorrente.
"O que devo estudar?"
A resposta mudou.
Não basta conhecer apenas COBOL.
Também é importante compreender:
APIs.
Segurança.
DevOps.
Git.
Cloud.
Automação.
Containers.
Observabilidade.
IA.
Mas sem abandonar os fundamentos.
A árvore cresce.
Porque suas raízes permanecem fortes.
14. Goblin Slayer e a Evolução
Ao longo da obra, Goblin Slayer melhora seus equipamentos.
Aprende novas estratégias.
Utiliza novas ferramentas.
Mas nunca abandona aquilo que funciona.
Ele evolui sem perder sua essência.
Essa talvez seja uma excelente definição para qualquer engenheiro.
Aprender continuamente.
Sem esquecer por que chegou até aqui.
15. Shogun e o Choque Tecnológico
Em Shogun, o contato entre culturas apresenta novas armas, novas embarcações, novos conhecimentos e novas formas de organização.
Os líderes que prosperam não são os que rejeitam toda novidade.
Nem os que abandonam imediatamente suas tradições.
São aqueles que sabem combinar inovação e experiência.
Essa mesma postura explica por que tantas organizações modernizam seus sistemas IBM Z em vez de simplesmente descartá-los.
16. A IA Não Elimina Engenheiros
Existe outro mito.
"A Inteligência Artificial substituirá todos."
Historicamente, grandes inovações modificam profissões, automatizam tarefas repetitivas e criam novas especializações.
Engenharia, arquitetura, pensamento crítico, ética, validação, responsabilidade e compreensão do negócio continuam sendo atividades essencialmente humanas.
A IA amplia capacidades.
Não elimina a necessidade de profissionais preparados.
17. Curiosidade Histórica
Ao longo da História, fortalezas bem-sucedidas foram aquelas que souberam incorporar novas tecnologias sem abandonar seus princípios estruturais. Castelos passaram a utilizar canhões, novas técnicas de construção, sistemas hidráulicos mais eficientes e melhores formas de comunicação, mantendo, porém, a lógica de defesa em profundidade, abastecimento, observação e comando.
Os ambientes IBM Z seguiram trajetória semelhante. Processadores mais rápidos, criptografia por hardware, virtualização, integração com Linux, APIs, contêineres e Inteligência Artificial foram incorporados preservando compatibilidade, disponibilidade e confiabilidade, características que continuam sustentando aplicações críticas em diversos setores.
18. Easter Egg — O Programa Mais Moderno do Banco
Conta-se que uma equipe resolveu identificar o software "mais moderno" da empresa.
Todos imaginavam encontrar um microsserviço recém-criado.
Uma API.
Um agente de IA.
Depois de semanas de investigação descobriram algo curioso.
O componente mais acessado de toda a arquitetura era um programa COBOL escrito décadas antes.
Mas ele havia recebido centenas de pequenas melhorias ao longo dos anos.
No cabeçalho existia uma anotação feita por dezenas de desenvolvedores.
A última dizia:
Não somos antigos.
Somos continuamente atualizados.
O arquiteto sorriu.
A inovação verdadeira não depende da data de nascimento.
Depende da capacidade de continuar evoluindo.
19. Checklist do Engenheiro do Futuro
Antes de afirmar que um sistema está preparado para os próximos anos, pergunte:
✔ Os fundamentos continuam sólidos?
✔ O conhecimento do negócio está documentado?
✔ As integrações utilizam padrões abertos quando apropriado?
✔ Existe observabilidade adequada?
✔ A segurança acompanha a evolução tecnológica?
✔ As equipes estudam continuamente?
✔ A IA é utilizada com supervisão humana?
✔ Há automação responsável?
✔ Os sistemas antigos conversam com os novos?
✔ Existe estratégia de modernização incremental?
✔ As decisões permanecem auditáveis?
✔ O foco continua sendo entregar valor ao negócio?
Conclusão — A Fortaleza do Amanhã
O jovem comandante caminhava pela muralha recém-ampliada.
Agora havia telescópios.
Canhões.
Novos depósitos.
Pontes reforçadas.
Mensageiros mais rápidos.
Nada daquilo existia quando o castelo fora construído.
Mesmo assim...
a fortaleza permanecia reconhecível.
O velho engenheiro aproximou-se.
— O que aprendeu?
O rapaz respondeu olhando para o horizonte.
— Achei que modernizar significasse substituir tudo.
Hoje compreendo que significa preservar aquilo que merece continuar existindo e melhorar aquilo que pode evoluir.
O mestre sorriu.
— Agora você pensa como um engenheiro.
Na sala de arquitetura, o jovem programador observava um ambiente onde COBOL, APIs, Linux, OpenShift, IA e serviços em nuvem trabalhavam juntos.
Nenhuma tecnologia tentava apagar a outra.
Cada uma resolvia o problema para o qual havia sido concebida.
Naquele momento ele compreendeu a maior lição de toda a jornada.
A engenharia nunca foi uma disputa entre passado e futuro.
Sempre foi uma conversa entre experiência e inovação.
Os maiores castelos da História não sobreviveram porque permaneceram imutáveis.
Sobreviveram porque souberam mudar sem destruir seus alicerces.
Da mesma forma, os grandes sistemas IBM Z continuarão relevantes enquanto houver engenheiros capazes de unir tradição, conhecimento de negócio, disciplina operacional e novas tecnologias.
Porque, no fim, a missão continua exatamente a mesma desde o primeiro capítulo desta jornada:
proteger aquilo que é essencial.
Garantir que a operação nunca pare.
E construir, geração após geração, uma fortaleza cada vez mais inteligente, resiliente e preparada para o futuro.
A tecnologia continuará mudando.
Os princípios da boa engenharia... esses permanecerão.
☕ Um Café no Bellacosa Mainframe
Engenharia Militar sem Mistérios para Programadores COBOL
Uma campanha completa sobre estratégia, logística, inteligência,
segurança, liderança, continuidade, sistemas críticos, IBM Z e COBOL.
Um Data Center analisado como uma fortaleza em guerra
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.
Sala de operações
Índice da campanha
25documentos localizados
Nenhum documento foi encontrado.
Remova os filtros ou pesquise outra palavra.
Índice permanente
Links completos da série Engenharia Militar
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.
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
