✨ 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

Mostrar mensagens com a etiqueta Logística Militar. Mostrar todas as mensagens

sexta-feira, 6 de junho de 2025

Engenharia Militar : Especial — A Guerra da Ucrânia

Bellacosa Mainframe e a engenharia militar especial guerra da ucrania

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Especial — A Guerra da Ucrânia

Quando um Programador COBOL Descobre que uma Guerra do Século XXI é Travada ao Mesmo Tempo por Drones, Satélites, Software, Logística, Informação e Vontade Humana

Introdução

Quando a Rússia iniciou sua invasão em grande escala da Ucrânia em 24 de fevereiro de 2022, boa parte dos analistas acreditava que o conflito terminaria em poucos dias ou semanas.

A lógica parecia simples.

Uma das maiores potências militares do planeta enfrentaria um país muito menor.

A superioridade numérica parecia esmagadora.

Entretanto...

A História mostrou algo completamente diferente.

A Guerra da Ucrânia rapidamente tornou-se um dos maiores laboratórios militares desde a Segunda Guerra Mundial.

Ela mudou conceitos que existiam havia décadas.

Mudou a forma de utilizar drones.

Mudou a guerra eletrônica.

Mudou o papel da inteligência.

Mudou a logística.

Mudou o emprego da artilharia.

Mudou a importância dos satélites comerciais.

Mudou a guerra de informação.

E talvez tenha mudado para sempre a forma como engenheiros militares projetarão conflitos futuros.

Curiosamente, diversas dessas lições lembram exatamente o trabalho diário de arquitetos IBM Z.

Nem sempre vence quem possui mais hardware.

Frequentemente vence quem entende melhor o sistema.

Antes da Guerra

O conflito não começou em 2022.

Suas raízes remontam a décadas de transformações políticas e estratégicas.

Entre os marcos frequentemente destacados por historiadores estão:

dissolução da União Soviética (1991);
independência da Ucrânia;
disputas sobre orientação política entre aproximação com a Europa e com a Rússia;
Revolução da Dignidade (Euromaidan, 2013–2014);
anexação da Crimeia pela Rússia (2014);
conflito armado no Donbass a partir de 2014;
anos de preparação militar, reformas e treinamento das forças ucranianas.

Sob muitos aspectos, 2022 representou uma escalada de um conflito já existente.

O Erro das Previsões

Nos primeiros dias da invasão, inúmeras análises previam uma rápida queda de Kiev.

Isso não ocorreu.

Entre os fatores apontados por especialistas para explicar essa diferença estão:

forte resistência das forças ucranianas;
problemas logísticos enfrentados pelas forças invasoras;
elevada motivação para a defesa nacional;
uso eficiente de inteligência;
capacidade de adaptação;
apoio internacional em equipamentos, treinamento e informações.

A guerra mostrou que números, isoladamente, raramente contam toda a história.

A Resistência Ucraniana

Talvez a maior surpresa do conflito tenha sido a velocidade de adaptação.

Ao invés de enfrentar diretamente todas as capacidades russas em confrontos convencionais, as forças ucranianas frequentemente buscaram explorar vulnerabilidades, proteger áreas críticas e preservar recursos.

Entre os elementos mais discutidos por analistas estão:

defesa em profundidade;
elevada descentralização de decisões em muitos níveis;
integração entre diferentes capacidades militares;
emprego intensivo de reconhecimento;
uso crescente de drones;
grande importância das comunicações.

O resultado foi uma resistência muito superior ao que boa parte dos observadores esperava.

As Grandes Lições da Guerra

1. Logística continua decidindo campanhas

Blindados sem combustível não avançam.

Artilharia sem munição não dispara.

Tropas sem manutenção perdem capacidade.

A máxima atribuída a Omar Bradley continua atual:

"Amadores falam de estratégia. Profissionais falam de logística."

2. Informação vale tanto quanto fogo

Satélites comerciais.

Sensores.

Imagens.

Interceptações.

Drones.

Tudo isso reduziu drasticamente o tempo entre observar um alvo e reagir.

3. Pequenos drones mudaram a guerra

Veículos aéreos não tripulados passaram a desempenhar papéis de observação, reconhecimento, correção de artilharia e outras funções de apoio, transformando a consciência situacional no campo de batalha.

4. Guerra eletrônica voltou ao centro

Interferência em comunicações.

Navegação.

Sensores.

Sinais.

Todo comandante moderno precisa considerar o espectro eletromagnético como parte do campo de batalha.

5. Software tornou-se arma estratégica

Atualizações rápidas.

Integração de sensores.

Compartilhamento de informações.

Planejamento digital.

A velocidade do software passou a influenciar diretamente a velocidade da tomada de decisão.

6. Adaptação supera planejamento rígido

Diversas soluções utilizadas durante o conflito surgiram meses após seu início.

Isso reforçou um princípio clássico:

Quem aprende mais rápido tende a manter vantagem.

O Que um Estrategista Deve Observar

Independentemente do lado analisado, este conflito oferece temas importantes para estudo:

integração entre tecnologia e liderança;
importância da cadeia logística;
inteligência e reconhecimento;
adaptação organizacional;
resiliência de infraestrutura crítica;
guerra de informação;
proteção de comunicações;
continuidade operacional;
cooperação internacional;
inovação acelerada sob pressão.

Esses aspectos interessam não apenas a militares, mas também a profissionais de engenharia, gestão de riscos e continuidade de negócios.

Paralelos com IBM Z

Imagine um banco.

Milhares de aplicações.

Centenas de integrações.

MQ.

Db2.

CICS.

VSAM.

APIs.

Cloud.

Agora imagine que parte dessa infraestrutura fique indisponível.

Os arquitetos precisam:

identificar rapidamente o problema;
manter os serviços essenciais;
redirecionar cargas;
recuperar componentes;
preservar a integridade dos dados;
comunicar equipes;
continuar operando.

É exatamente isso que arquiteturas IBM Z fazem há décadas.

Não existe apenas potência.

Existe principalmente resiliência.

A Guerra da Informação

A Guerra da Ucrânia também mostrou que a narrativa pública tornou-se um componente importante dos conflitos modernos.

Redes sociais, vídeos, imagens de satélite, jornalistas, comunicados oficiais e plataformas digitais passaram a influenciar a percepção internacional quase em tempo real.

Isso não elimina a necessidade de verificar informações com fontes confiáveis, já que propaganda, desinformação e erros também fazem parte do ambiente informacional em guerras.

Para um profissional de tecnologia, a lição é clara:

Dados são valiosos, mas sua qualidade e verificação continuam sendo essenciais.

Como o Mundo dos Animes Reagiu

Embora poucos animes tratem diretamente da Guerra da Ucrânia, muitos fãs e críticos passaram a revisitar obras sob uma nova perspectiva.

Entre elas:

Legend of the Galactic Heroes

Discussões sobre liderança, diplomacia, desgaste prolongado e escolhas estratégicas ganharam nova relevância.

86 Eighty-Six

A série passou a ser frequentemente citada em debates sobre tecnologia militar, drones, desumanização da guerra e o custo humano dos conflitos.

Mobile Suit Gundam

A franquia voltou a ser lembrada por suas reflexões sobre política, indústria de defesa, rivalidades entre Estados e consequências da guerra para civis.

Saga of Tanya the Evil

Foi reinterpretada por muitos espectadores como uma reflexão sobre burocracia militar, mobilização industrial e escaladas estratégicas.

Attack on Titan

Temas como cercos, sobrevivência, propaganda, ciclos de violência e decisões políticas passaram a ser discutidos de forma ainda mais intensa pela comunidade.

Em geral, a reação do fandom não foi de glorificação do conflito, mas de comparação entre ficção e realidade, destacando como diversas obras já exploravam dilemas éticos e estratégicos presentes em guerras modernas.

Curiosidade

Talvez a maior surpresa tecnológica do conflito tenha sido mostrar que equipamentos sofisticados continuam importantes, mas que integração entre sensores, software, comunicações, logística e treinamento pode ser tão decisiva quanto plataformas individuais.

Em outras palavras, sistemas funcionam melhor quando seus componentes trabalham em conjunto.

Easter Egg Bellacosa

Um jovem programador perguntou ao velho arquiteto:

— Qual foi a maior arma desta guerra?

O arquiteto respondeu:

— O sistema.

O rapaz insistiu:

— O senhor quer dizer um míssil?

O veterano balançou a cabeça.

— Não.

Satélites.

Comunicações.

Software.

Logística.

Treinamento.

Engenharia.

Inteligência.

Liderança.

Continuidade.

Tudo conectado.

Assim como um Mainframe.

Quando você olha apenas para um programa COBOL, vê uma aplicação.

Quando olha para todo o ecossistema IBM Z, entende que o verdadeiro poder nunca esteve em uma única máquina.

Sempre esteve na integração entre pessoas, processos e tecnologia.

Conclusão

A Guerra da Ucrânia já ocupa um lugar importante na história militar contemporânea porque demonstrou que muitos conceitos clássicos permanecem válidos, enquanto outros precisaram ser profundamente revisados.

Ela reforçou a importância da logística, da liderança, da inteligência e da adaptação, ao mesmo tempo em que evidenciou o papel crescente do software, das comunicações, da guerra eletrônica e dos sistemas integrados.

Para um programador COBOL, essas lições soam familiares.

Os maiores ambientes IBM Z do mundo continuam operando não apenas porque possuem hardware robusto, mas porque foram concebidos para resistir, adaptar-se e manter serviços críticos funcionando mesmo diante de condições adversas.

Talvez essa seja a principal mensagem deste capítulo.

No século XXI, vencer não significa apenas possuir mais recursos.

Significa compreender melhor o sistema, integrar pessoas e tecnologia com inteligência e construir estruturas capazes de continuar funcionando quando a pressão aumenta.

E essa é uma lição que vale tanto para o campo de batalha quanto para um Data Center que não pode parar.

☕ Um Café no Bellacosa Mainframe

Engenharia Militar

Prólogo — O Chamado do Guardião
Quando um Programador COBOL descobre que a maior fortaleza da História nunca foi construída apenas com pedra.

Entrar na fortaleza

quinta-feira, 7 de julho de 2016

Engenharia Militar : Os 10 Animes Mais Emblemáticos Sobre Logística Militar

Bellacosa Mainframe e a engenharia militar em 10 animes sobre logistica militar

☕ Um Café no Bellacosa Mainframe

Engenharia Militar : Os 10 Animes Mais Emblemáticos Sobre Logística Militar

Quando um Programador COBOL Descobre que Guerras Não São Vencidas por Espadas... São Vencidas por Comboios, Armazéns e Linhas de Suprimento

Introdução

Existe uma frase atribuída ao general norte-americano Omar Bradley que resume perfeitamente este capítulo:

"Amadores falam de estratégia. Profissionais estudam logística."

Ao longo da História, impérios não caíram porque lhes faltavam soldados.

Caíram porque lhes faltou comida.

Água.

Municação.

Combustível.

Estradas.

Comunicação.

Organização.

A logística sempre foi a verdadeira espinha dorsal das campanhas militares.

Curiosamente, inúmeros animes japoneses compreenderam isso muito antes que muitos livros de administração modernos. Em vez de retratarem apenas batalhas espetaculares, mostram cozinheiros, intendentes, construtores de pontes, engenheiros, comboios, rotas comerciais, depósitos de suprimentos, manutenção de equipamentos e planejamento de longo prazo.

Para um profissional COBOL ou IBM Z, essas obras parecem familiares.

Um Job Batch não termina porque o programa é bonito.

Ele termina porque datasets chegaram na ordem correta, discos estavam disponíveis, filas MQ foram processadas, o Db2 respondeu, o Storage suportou a carga e toda a cadeia funcionou perfeitamente.

É exatamente isso que a logística faz.

Ela transforma milhares de pequenas tarefas invisíveis em uma única grande operação bem-sucedida.

Pegue seu café.

Hoje descobriremos que muitos dos maiores estrategistas dos animes pensavam exatamente como um excelente operador de Mainframe.

1. Legend of the Galactic Heroes (銀河英雄伝説)

Lançamento: 1988–1997

Resumo

Nenhum anime explica logística militar em escala tão gigantesca. Movimentação de centenas de milhares de naves depende de abastecimento, manutenção, rotas, comunicação e planejamento de longo prazo.

Personagens

Reinhard von Lohengramm
Yang Wen-li
Kircheis
Oberstein

8. Goblin Slayer

Lançamento: 2018

Resumo

Apesar de parecer um anime de fantasia, praticamente todas as missões dependem de planejamento logístico.

Equipamentos.

Cordas.

Lanternas.

Água.

Mapas.

Suprimentos.

Rotas de fuga.

Personagens

Goblin Slayer
Priestess
High Elf Archer
Dwarf Shaman
Lizard Priest

Lição Logística

Improvisar custa caro.

Pumpkin Scissors
Valkyria Chronicles
Mobile Suit Gundam (Universal Century)
Crest of the Stars
Record of Grancrest War
Drifters
Code Geass
Mobile Suit Gundam: The 08th MS Team
The Twelve Kingdoms
Mobile Suit Gundam: Iron-Blooded Orphans

As Dez Grandes Lições da Logística Militar

Esses animes ensinam princípios que também aparecem diariamente em ambientes IBM Z:

1. Nenhuma operação acontece sem planejamento.

2. Infraestrutura é tão importante quanto a linha de frente.

3. O recurso certo precisa chegar na hora certa.

4. Estoques mal administrados provocam derrotas.

5. Comunicação mantém toda a cadeia funcionando.

6. Pequenos atrasos acumulam grandes impactos.

7. Redundância salva operações críticas.

8. A manutenção contínua custa menos que a reconstrução.

9. A disciplina logística reduz desperdícios.

10. O sucesso da logística é justamente passar despercebido.

O Paralelo com COBOL e IBM Z

Quem trabalha em Mainframe rapidamente percebe que um processamento Batch se parece muito mais com uma campanha militar do que com um simples programa de computador.

Cada etapa depende da anterior.

Cada dataset precisa chegar ao destino correto.

Cada Job aguarda outro terminar.

Cada recurso possui capacidade limitada.

Cada minuto de janela operacional importa.

No fundo, um operador de produção administra um enorme sistema logístico digital.

Quando tudo funciona, ninguém percebe.

Quando uma única peça da cadeia falha, toda a operação sofre as consequências.

Curiosidade Histórica

Os exércitos romanos mantinham uma regra simples: uma legião marchava conforme a velocidade de seu comboio de suprimentos, não conforme a velocidade de seus melhores soldados.

Nos Data Centers ocorre exatamente o mesmo. O desempenho global de um ambiente IBM Z raramente é definido pelo componente mais rápido. O fator limitante costuma ser o elo mais lento da cadeia: uma consulta ineficiente ao Db2, um gargalo de I/O, uma fila MQ congestionada, um volume de armazenamento próximo do limite ou uma dependência Batch atrasada. Assim como na logística militar, a eficiência do conjunto vale mais do que a força isolada de qualquer componente.

Easter Egg

Conta uma antiga história que um general perguntou ao intendente:

— Quantas espadas ainda temos?

O intendente respondeu:

— Espadas suficientes.

Mas apenas comida para cinco dias.

O general cancelou imediatamente a ofensiva.

Séculos depois...

um gerente perguntou ao operador:

— O programa COBOL já está compilado?

— Sim.

— O Db2 está disponível?

— Sim.

— O MQ?

— Sim.

— O Storage?

— Está em 99,8% de utilização.

O gerente respondeu:

— Então ainda não estamos prontos.

Porque grandes profissionais sabem que a batalha nunca depende de um único recurso.

Depende de toda a cadeia.

Conclusão

Ao terminar esta lista, talvez você nunca mais assista a esses animes apenas como histórias de guerra.

Você perceberá cozinheiros calculando estoques.

Engenheiros construindo pontes.

Mensageiros atravessando fronteiras.

Caravanas protegendo alimentos.

Oficiais organizando depósitos.

Comandantes adiando batalhas por falta de suprimentos.

Tudo isso parece distante do universo da computação.

Mas não está.

Todos os dias, em algum lugar do mundo, um ambiente IBM Z processa milhões de transações porque milhares de pequenos elementos logísticos funcionaram exatamente como planejado.

Os usuários enxergam apenas o resultado final.

Assim como um reino enxergava apenas a vitória.

Mas os verdadeiros heróis sempre estiveram um pouco mais atrás da linha de frente.

Nos armazéns.

Nas oficinas.

Nas estradas.

Nos centros de comando.

Ou, em nossos dias, silenciosamente trabalhando em um Data Center, garantindo que cada Job encontre seu caminho, que cada dataset chegue ao destino e que a fortaleza digital continue abastecida para mais um dia de operação.

Porque guerras podem ser vencidas por generais.

Mas civilizações são sustentadas pela logística.

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

Consultar arquivo

25 documentos

2014–2016 linha histórica

IBM Z fortaleza digital

COBOL linguagem da missão

Arquivo estratégico

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

25 documentos localizados

Pesquisar no arquivo Categoria Ordenação

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

Engenharia Militar — Índice da campanha

O JavaScript está desativado. Utilize o índice permanente de links exibido nesta página para acessar os artigos.

terça-feira, 6 de janeiro de 2015

Engenharia Militar : Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar

Bellacosa Mainframe e a engenharia militar parte I

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Capítulo I — O Castelo, a Ponte e o Job que Não Podia Falhar

Quando um Programador Descobre que a Guerra Não é Vencida pela Espada, mas por Quem Constrói a Estrada, Protege os Suprimentos e Mantém o Sistema Funcionando

A chuva caía sobre os telhados do castelo como milhões de pequenos registros sendo gravados em um arquivo sequencial.

No alto da torre, sentinelas observavam o vale encoberto pela neblina. Abaixo delas, dezenas de homens reforçavam portões, transportavam madeira, verificavam cordas, enchiam depósitos de água e reparavam uma ponte que atravessava o rio.

Ao longe, nenhuma tropa inimiga podia ser vista.

Nenhuma bandeira tremulava no horizonte.

Nenhum tambor anunciava batalha.

Ainda assim, todos trabalhavam como se a guerra já tivesse começado.

Dentro da fortaleza, o senhor feudal estudava mapas à luz de uma lamparina. Ao seu lado estavam generais, conselheiros, mensageiros e um homem que não carregava espada.

Vestia roupas simples, tinha as mãos marcadas pelo trabalho e examinava cuidadosamente uma pequena maquete de madeira.

Era o engenheiro.

O general mais jovem, impaciente, perguntou:

— Por que perdemos tempo fortalecendo pontes? Precisamos de mais guerreiros.

O engenheiro não respondeu imediatamente.

Pegou uma pequena peça que representava uma carroça de suprimentos e a colocou sobre a ponte da maquete.

— Quantos dias seus homens conseguem lutar sem arroz?

O general permaneceu em silêncio.

— Quantas flechas seus arqueiros podem disparar sem madeira? Quantos feridos sobreviverão sem água? Quantos mensageiros chegarão ao castelo se o rio transbordar?

O senhor feudal ergueu os olhos.

— Uma espada vence um duelo — disse ele. — Mas uma estrada pode decidir uma guerra.

Séculos depois, em uma sala de operações iluminada por monitores, um jovem programador COBOL cometeria exatamente o mesmo erro daquele general.

Ele acreditaria que um sistema era apenas código.

E descobriria, da pior maneira possível, que programas também precisam de estradas, pontes, suprimentos, muralhas, mensageiros e planos de retirada.

Bem-vindo ao primeiro capítulo de nossa campanha.

Prepare o café.

Confira o MAXCC.

E não atravesse a ponte antes de verificar quem a construiu.

1. O que realmente significa engenharia militar?

Quando alguém escuta a expressão “engenharia militar”, normalmente imagina soldados construindo pontes improvisadas, abrindo caminhos em florestas, explodindo obstáculos ou levantando fortificações.

Tudo isso faz parte da engenharia militar.

Mas a ideia é muito maior.

Engenharia militar é o uso organizado de conhecimentos técnicos para criar as condições necessárias para uma operação.

Ela procura responder perguntas fundamentais:

Como uma força chegará ao seu destino?
Como atravessará rios, montanhas e áreas destruídas?
Como se protegerá?
Como receberá alimentos, água, energia e equipamentos?
Como manterá comunicação?
Como poderá avançar?
Como poderá recuar?
Como continuará funcionando quando algo falhar?

Observe uma diferença importante.

O guerreiro executa a missão.

O engenheiro cria as condições para que a missão possa ser executada.

Um exército pode possuir soldados valentes, excelentes armas e um comandante brilhante. Mas, se não houver estrada, alimentação, abrigo, comunicação e reposição, aquela força terá pouca utilidade.

A engenharia militar cuida da realidade que existe atrás da imagem heroica.

Os filmes mostram a carga de cavalaria.

O engenheiro pensa na ração dos cavalos.

Os animes mostram o golpe decisivo.

O engenheiro pergunta como o personagem chegou vivo até aquela batalha.

As empresas mostram uma transação concluída em segundos.

O profissional de mainframe pensa em CPU, memória, banco de dados, segurança, filas, arquivos, redes, jobs e recuperação.

A vitória é visível.

A infraestrutura que permitiu a vitória quase nunca é.

2. O programador que acreditava que tudo era código

Imagine uma instituição financeira que precisa calcular o rendimento de milhões de contas durante a madrugada.

O programa COBOL recebe um arquivo de entrada, consulta tabelas Db2, calcula valores, atualiza registros e gera arquivos para outros sistemas.

O código foi cuidadosamente alterado.

Os testes unitários passaram.

A compilação terminou com sucesso.

O bind foi realizado.

O novo load module foi promovido.

Tudo parecia perfeito.

Às 2h13 da madrugada, o job entrou em execução.

Às 2h14, terminou com erro.

O programador foi chamado.

Ele abriu o programa, revisou os parágrafos e examinou as condições.

Nenhum problema.

Depois olhou o JCL.

O arquivo de entrada estava vazio.

O sistema anterior, responsável por gerar aquele arquivo, havia terminado com erro devido à falta de espaço em disco.

O programa COBOL estava correto.

Mas a operação estava derrotada.

Esse é o primeiro princípio da engenharia militar aplicada à tecnologia:

Um componente correto pode participar de um sistema fracassado.

O jovem programador havia pensado como um duelista.

Precisava aprender a pensar como um engenheiro de campanha.

3. O campo de batalha chamado produção

O ambiente de produção não é literalmente uma guerra.

Entretanto, a comparação ajuda a compreender sua complexidade.

Em produção, existem:

recursos limitados;
riscos;
dependências;
prazos;
cadeias de decisão;
responsabilidades;
contingências;
informações incompletas;
consequências reais.

Uma falha pode interromper pagamentos, bloquear transações, atrasar entregas, prejudicar clientes ou gerar perdas financeiras.

Por isso, ambientes críticos não podem depender apenas da habilidade individual.

Eles precisam de organização.

No mundo COBOL e mainframe, essa organização aparece em várias camadas.

O programa COBOL

Representa a unidade que executa uma tarefa específica.

O JCL

Representa o plano operacional.

Define quais recursos serão utilizados, qual sequência deverá ser seguida e como cada etapa será executada.

O JES

Organiza a movimentação dos jobs.

É como uma autoridade responsável por receber, ordenar e despachar as operações.

O WLM

Distribui recursos conforme prioridades e objetivos definidos.

É o comandante que precisa decidir quais unidades receberão atenção primeiro.

O RACF

Controla acessos e protege os portões.

Determina quem pode entrar, o que pode acessar e quais ações pode executar.

O Db2

Armazena informações vitais.

É simultaneamente arquivo imperial, tesouro, registro histórico e centro administrativo.

O CICS

Atende solicitações em tempo quase imediato.

É a cidade comercial dentro da fortaleza, onde milhares de transações acontecem continuamente.

O MQ

Transporta mensagens entre sistemas.

Funciona como uma rede de mensageiros que precisa garantir que a informação chegue ao destino correto.

O storage

Armazena dados, versões, históricos e cópias.

É o conjunto de depósitos, arsenais, arquivos e reservas da fortaleza.

O programador iniciante costuma enxergar apenas seu programa.

O engenheiro enxerga a campanha inteira.

4. Mobilidade: como chegar até o objetivo?

Uma das principais funções da engenharia militar é permitir movimento.

Isso inclui:

construir pontes;
abrir estradas;
remover obstáculos;
preparar travessias;
criar rotas alternativas;
reparar caminhos destruídos.

No mainframe, mobilidade significa permitir que os dados se movam.

Os dados precisam atravessar:

arquivos;
filas;
tabelas;
redes;
APIs;
programas;
subsistemas;
plataformas.

Uma empresa pode possuir informações excelentes, mas elas não possuem valor se não conseguem chegar ao lugar certo no momento certo.

Imagine um arquivo COBOL produzido com o seguinte layout:

       01  REGISTRO-CLIENTE.
           05  CODIGO-CLIENTE      PIC 9(10).
           05  NOME-CLIENTE        PIC X(40).
           05  SALDO-CLIENTE       PIC S9(11)V99 COMP-3.

Outro sistema precisa consumir esse arquivo.

À primeira vista, parece simples.

Mas surgem várias perguntas:

Qual é o tamanho total do registro?
O arquivo é FB ou VB?
Qual é o LRECL?
A codificação é EBCDIC ou ASCII?
O campo compactado será compreendido pelo consumidor?
Existe cabeçalho?
Existe trailer?
Como o consumidor detecta duplicidade?
Como confirma que o arquivo está completo?
Como ocorre o reprocessamento?
O nome do dataset muda diariamente?
Há uma geração GDG?
O arquivo é criptografado?
Quem possui autorização de leitura?

Essas perguntas pertencem à engenharia da ponte.

O código apenas produz registros.

A integração garante que eles atravessem o rio.

5. Contramobilidade: impedir que o adversário avance

A engenharia militar não serve apenas para facilitar o movimento das próprias forças.

Também pode dificultar o movimento adversário.

Isso é feito por meio de:

fossos;
barreiras;
destruição controlada de pontes;
obstáculos;
campos defensivos;
rotas bloqueadas;
fortificações.

Na tecnologia, essa função corresponde à segurança.

Não basta permitir que usuários autorizados utilizem o sistema.

Também é necessário impedir ações indevidas.

O RACF, por exemplo, não é apenas um cadastro de usuários.

Ele representa uma política de acesso.

Pode determinar:

quem pode ler um dataset;
quem pode alterá-lo;
quem pode executar determinado recurso;
quais grupos possuem acesso;
quando uma tentativa deve ser registrada;
quais privilégios precisam ser separados.

Um ambiente sem controles é como uma fortaleza cujos portões permanecem abertos porque os moradores consideram inconveniente usar chaves.

A segurança cria obstáculos.

Mas esses obstáculos precisam ser inteligentes.

Uma proteção mal planejada pode impedir o próprio trabalho.

Uma proteção fraca pode facilitar uma invasão.

O verdadeiro desafio está no equilíbrio.

6. Fortificação: sobreviver ao impacto

Fortificações existem porque nenhum território pode presumir que jamais será atacado.

Castelos, muralhas e bunkers são construídos com uma ideia fundamental:

O impacto acontecerá. Precisamos continuar funcionando depois dele.

Esse princípio também deve orientar sistemas críticos.

Não é realista imaginar que nunca ocorrerão:

erros humanos;
falhas de hardware;
arquivos corrompidos;
indisponibilidade de rede;
problemas de software;
credenciais expiradas;
ataques;
interrupções;
volumes inesperados;
dados inválidos.

Por isso, sistemas precisam de mecanismos de resistência.

No COBOL, alguns exemplos são:

       READ ARQUIVO-CLIENTES
           AT END
               MOVE 'S' TO FIM-DO-ARQUIVO
           NOT AT END
               PERFORM PROCESSAR-CLIENTE
       END-READ

O tratamento de fim de arquivo é uma proteção simples.

Mas também existem situações mais críticas:

       IF WS-FILE-STATUS NOT = '00'
           DISPLAY 'ERRO NO ARQUIVO CLIENTES: '
                   WS-FILE-STATUS
           MOVE 12 TO RETURN-CODE
           PERFORM ENCERRAR-PROCESSAMENTO
       END-IF

O FILE STATUS é uma sentinela.

Ele informa se o portão abriu corretamente.

No Db2, o SQLCODE exerce função semelhante.

       EXEC SQL
           UPDATE CONTA
              SET SALDO = :WS-NOVO-SALDO
            WHERE NUMERO_CONTA = :WS-CONTA
       END-EXEC

       EVALUATE SQLCODE
           WHEN 0
               CONTINUE
           WHEN 100
               PERFORM TRATAR-CONTA-NAO-ENCONTRADA
           WHEN OTHER
               PERFORM TRATAR-ERRO-SQL
       END-EVALUATE

Ignorar o SQLCODE equivale a enviar tropas para uma ponte sem confirmar se ela ainda existe.

7. A engenharia da logística

Esta talvez seja a parte menos glamorosa e mais decisiva de qualquer campanha.

Logística é o processo de disponibilizar recursos no lugar certo e na hora certa.

Em uma operação militar, envolve:

comida;
água;
munição;
roupas;
combustível;
transporte;
ferramentas;
medicamentos;
peças de reposição.

Em um ambiente mainframe, envolve:

CPU;
memória;
storage;
espaço temporário;
arquivos;
conexões;
filas;
tempo de janela;
disponibilidade de subsistemas;
equipes de suporte.

Considere um programa de ordenação.

O programador pode escrever:

       SORT ARQUIVO-SORT
           ON ASCENDING KEY CHAVE-CLIENTE
           USING ARQUIVO-ENTRADA
           GIVING ARQUIVO-SAIDA

A instrução parece pequena.

Mas, nos bastidores, talvez precise processar milhões de registros.

Então a operação exige:

espaço temporário;
memória;
tempo;
dispositivos;
estimativas de volume;
parâmetros adequados;
capacidade de reinício.

O comando é simples.

A logística é complexa.

É por isso que sistemas críticos não podem ser avaliados apenas pela elegância do código.

Um algoritmo maravilhoso que ultrapassa a janela batch pode ser operacionalmente inútil.

Um programa rápido que consome recursos excessivos pode prejudicar outros serviços.

Um job que funciona com dez mil registros pode falhar com cem milhões.

Engenharia significa avaliar escala.

8. JCL: o mapa de campanha

O JCL costuma assustar iniciantes.

Ele parece antigo, cheio de parâmetros, símbolos e regras peculiares.

Mas, quando compreendido como um plano operacional, começa a fazer sentido.

Observe:

//CALC001  JOB (ACCT),'CALCULO',CLASS=A,MSGCLASS=X
//STEP010  EXEC PGM=CALCREND
//STEPLIB  DD  DSN=EMPRESA.LOADLIB,DISP=SHR
//ENTRADA  DD  DSN=EMPRESA.CLIENTES.DIARIO,DISP=SHR
//SAIDA    DD  DSN=EMPRESA.RESULTADO(+1),
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(CYL,(100,20)),
//             DCB=(RECFM=FB,LRECL=120,BLKSIZE=0)
//SYSOUT   DD  SYSOUT=*

Esse JCL responde várias perguntas.

Qual programa será executado?

//STEP010 EXEC PGM=CALCREND

Onde está o módulo?

//STEPLIB DD DSN=EMPRESA.LOADLIB,DISP=SHR

Qual é o arquivo de entrada?

//ENTRADA DD DSN=EMPRESA.CLIENTES.DIARIO,DISP=SHR

Onde será produzido o resultado?

//SAIDA DD DSN=EMPRESA.RESULTADO(+1)

Quanto espaço será reservado?

// SPACE=(CYL,(100,20))

O que acontecerá se o step falhar?

// DISP=(NEW,CATLG,DELETE)

O JCL é o mapa de campanha.

O COBOL descreve o que a unidade fará.

O JCL define como ela será enviada ao campo.

9. Comunicação: ordens que precisam ser compreendidas

Em guerras antigas, uma mensagem mal transmitida podia destruir um exército.

Uma ordem atrasada, ambígua ou entregue ao comandante errado poderia alterar completamente uma batalha.

Nos sistemas, mensagens e logs também precisam ser claros.

Considere:

ERRO 102

Essa mensagem possui pouco valor operacional.

Agora compare:

ERRO 102 - ARQUIVO DE MOVIMENTOS NÃO DISPONÍVEL
DATA ESPERADA: 20260725
JOB PRODUTOR: MOVGER01
AÇÃO RECOMENDADA: VALIDAR STEP020 E REINICIAR A PARTIR DO STEP030

A segunda mensagem funciona como uma ordem útil.

Ela informa:

o problema;
o contexto;
a dependência;
a ação sugerida.

Em produção, clareza reduz tempo de recuperação.

Mensagens precisam ser escritas para seres humanos sob pressão.

Esse é um detalhe frequentemente ignorado.

O programador escreve o erro pensando no momento do desenvolvimento.

Mas quem verá aquela mensagem poderá ser um operador às três da madrugada, durante um incidente, sem conhecer o programa.

Uma boa mensagem deve funcionar como um mensageiro treinado.

10. Reconhecimento: estudar antes de atacar

Nenhum comandante responsável avança sem conhecer o terreno.

Antes de uma operação, procura informações sobre:

distância;
rios;
estradas;
elevações;
obstáculos;
forças adversárias;
clima;
população;
rotas de retirada.

No desenvolvimento, reconhecimento significa análise de impacto.

Antes de alterar um programa COBOL, o iniciante deve investigar.

Passo 1 — Descubra como o programa é chamado

É executado por JCL?

É chamado por outro programa?

É uma transação CICS?

É acionado por uma mensagem?

Passo 2 — Mapeie entradas e saídas

Quais arquivos são lidos?

Quais arquivos são gerados?

Quais tabelas são consultadas ou atualizadas?

Passo 3 — Localize dependências

Existem copybooks?

Subprogramas?

Stored procedures?

Filas MQ?

Passo 4 — Verifique consumidores

Quem utiliza o resultado?

Outro job?

Uma API?

Um relatório?

Uma equipe externa?

Passo 5 — Analise volumes

Quantos registros?

Qual crescimento esperado?

Qual tempo atual?

Passo 6 — Procure regras escondidas

Comentários antigos.

Condições especiais.

Datas críticas.

Exceções históricas.

Passo 7 — Consulte veteranos

Documentação ajuda.

Mas, em ambientes antigos, parte do mapa pode existir apenas na memória de quem já percorreu o terreno.

Modificar antes de investigar é entrar na floresta acreditando que todas as sombras são árvores.

11. Animes como manuais invisíveis de organização

A relação entre animes e engenharia militar não está apenas em obras sobre guerra.

Ela aparece na forma como os personagens são organizados e treinados.

Em muitas histórias japonesas, existe:

uma instituição;
uma hierarquia;
um mestre;
uma equipe;
um período de treinamento;
regras;
testes;
falhas;
amadurecimento;
responsabilidade coletiva.

Em Attack on Titan, a formação é explicitamente militar.

Os personagens aprendem combate, disciplina, formação, comando e sacrifício.

Em Kingdom, vemos estratégia, logística, terreno, moral e comando.

Em Legend of the Galactic Heroes, a guerra é tratada como política, administração, liderança e economia.

Em Goblin Slayer, o combate é engenharia operacional.

O protagonista avalia:

entradas;
saídas;
quantidade de inimigos;
terreno;
ventilação;
suprimentos;
possibilidades de fuga;
armas disponíveis.

Ele não pergunta apenas:

— Consigo vencer?

Pergunta:

— Como impedir que o problema retorne?

Esse é pensamento sistêmico.

E pensamento sistêmico é essencial para programadores.

12. Um Estado poderia utilizar animes e mangás para educar?

Sim.

Narrativas visuais são instrumentos poderosos de educação.

Elas podem ensinar:

primeiros socorros;
prevenção de incêndios;
defesa civil;
segurança no trânsito;
educação financeira;
preparação para enchentes;
comportamento em terremotos;
segurança digital;
saúde pública;
cidadania.

A grande vantagem está na identificação emocional.

Uma lista de instruções pode ser esquecida.

Uma história pode permanecer durante décadas.

Quando uma personagem admirada toma uma decisão correta e salva outras pessoas, o público não recebe apenas informação.

Recebe um modelo de comportamento.

Esse mecanismo pode ser positivo.

Mas também pode ser perigoso.

A mesma ferramenta que ensina cooperação pode ensinar submissão.

A mesma narrativa que estimula coragem pode glorificar sacrifícios inúteis.

A mesma obra que valoriza disciplina pode tentar eliminar questionamentos.

Por isso, precisamos separar educação de propaganda.

Educação

Apresenta conhecimento, contexto e possibilidades.

Propaganda

Busca produzir adesão emocional a uma causa.

Doutrinação

Procura impedir o pensamento alternativo.

A pergunta essencial é:

A obra ensina o cidadão a pensar ou apenas a obedecer?

Muitos animes interessantes fazem exatamente o contrário da propaganda simplista.

Eles mostram:

autoridades que erram;
líderes que manipulam;
instituições corrompidas;
ordens imorais;
conflitos entre dever e consciência;
consequências do militarismo.

Disciplina e pensamento crítico não precisam ser inimigos.

A melhor formação ensina quando obedecer, por que obedecer e quando uma ordem precisa ser questionada.

13. Shogun e a engenharia do poder invisível

Em uma narrativa no estilo de Shogun, a guerra raramente acontece apenas no campo de batalha.

Ela ocorre:

em conversas;
em casamentos;
em alianças;
em cerimônias;
em decisões comerciais;
no controle de portos;
na circulação de informação;
na interpretação de gestos.

Uma fortaleza pode cair sem ser atacada.

Basta cortar seus suprimentos.

Um senhor pode perder poder sem perder soldados.

Basta perder aliados.

Uma frota pode ser inutilizada sem combate.

Basta impedir o acesso ao porto.

Isso também acontece nos sistemas.

Uma aplicação pode parar mesmo com seu código intacto.

Basta:

revogar uma credencial;
bloquear uma porta de rede;
atrasar um arquivo;
indisponibilizar uma tabela;
encher uma fila;
remover espaço;
alterar uma autorização.

O poder real está nas dependências.

Quem controla as dependências controla a operação.

Esse é um dos maiores ensinamentos da engenharia militar e da arquitetura de sistemas.

14. O passo a passo do engenheiro COBOL

Antes de realizar uma alteração, siga este pequeno ritual de campanha.

1. Defina a missão

O que precisa mudar?

Qual problema empresarial será resolvido?

2. Conheça o terreno

Onde o programa executa?

Batch, CICS, IMS ou outro ambiente?

3. Identifique as unidades envolvidas

Quais programas, arquivos, tabelas e filas participam?

4. Verifique os suprimentos

Existe espaço, tempo, capacidade e disponibilidade?

5. Proteja as fronteiras

Quais acessos e autorizações são necessários?

6. Teste as pontes

As interfaces funcionam corretamente?

7. Prepare comunicação

As mensagens de erro são claras?

Os logs permitem investigação?

8. Defina contingência

Como interromper?

Como reiniciar?

Como reverter?

9. Execute testes realistas

Utilize volumes e cenários próximos da produção.

10. Reúna evidências

Guarde resultados, relatórios, logs e comparações.

Esse processo parece mais lento que simplesmente alterar o código.

Na verdade, ele é muito mais rápido que corrigir um desastre em produção.

15. Easter egg: o programador que removeu a ponte

Em uma instalação antiga, havia um campo aparentemente inútil no final de um copybook.

       05  FILLER                  PIC X(08).

O campo não era utilizado por nenhum programa conhecido.

Um desenvolvedor decidiu removê-lo para “otimizar o layout”.

A compilação passou.

Os testes locais passaram.

O programa produziu registros menores.

Na madrugada seguinte, um sistema externo começou a interpretar os campos usando posições fixas.

Datas foram lidas como valores.

Valores foram lidos como códigos.

Códigos foram lidos como espaços.

O problema não estava no programa alterado.

Estava na ponte que conectava dois sistemas.

O FILLER aparentemente inútil era parte do contrato de integração.

O novo programador havia removido oito bytes.

Na prática, havia desmontado uma ponte enquanto a caravana ainda atravessava.

Desde então, um comentário passou a aparecer em vários copybooks daquela instalação:

      * ANTES DE REMOVER UMA PEDRA,
      * DESCUBRA QUAL MURALHA ELA SUSTENTA.

Talvez seja apenas uma lenda de data center.

Mas toda lenda antiga costuma proteger alguma verdade.

16. Checklist de campo

Antes de considerar seu programa pronto, pergunte:

Entendi a missão empresarial?
Conheço o ambiente de execução?
Identifiquei entradas e saídas?
Mapeei todas as dependências?
Conheço os consumidores dos dados?
Verifiquei volume e capacidade?
Tratei FILE STATUS e SQLCODE?
Preparei mensagens claras?
Existe procedimento de reinício?
Existe rollback?
As autorizações foram verificadas?
Os testes representam situações reais?
Os resultados podem ser comprovados?
Alguém além de mim entende a operação?

Se alguma resposta for “não”, talvez o código esteja pronto.

Mas a campanha ainda não está.

Conclusão — O homem sem espada

De volta ao castelo, o jovem general observava os trabalhadores terminando a ponte.

Durante a noite, a chuva havia aumentado.

O rio estava mais forte.

Ao amanhecer, mensageiros chegaram com notícias: uma força inimiga avançava pela estrada do norte.

O general colocou a mão na espada.

— Finalmente.

O engenheiro, porém, olhou para o rio.

As carroças começaram a atravessar a ponte levando alimentos, flechas, ferramentas e medicamentos para as unidades posicionadas no vale.

Sem aquela estrutura, os soldados ficariam isolados.

Sem os suprimentos, não resistiriam.

Sem mensageiros, não receberiam ordens.

Sem rota de retirada, poderiam ser cercados.

O general compreendeu.

A batalha ainda seria travada por guerreiros.

Mas a possibilidade de vitória havia sido construída por homens que não apareceriam nas canções.

Séculos depois, o jovem programador COBOL observou seu job executar novamente.

O arquivo de entrada fora corrigido.

O espaço de storage havia sido ampliado.

As permissões estavam ajustadas.

A dependência anterior havia terminado.

O processamento avançou.

Milhões de registros foram lidos.

Tabelas foram atualizadas.

Arquivos foram gerados.

O job terminou com:

MAXCC=0000

O veterano levantou sua caneca.

— Agora você entende?

O jovem assentiu.

— O programa não é o sistema.

— Exatamente.

— E o programador não é apenas alguém que escreve código.

O veterano sorriu.

— Quando aprende a enxergar estradas, muralhas, suprimentos e rotas de retirada, ele se torna engenheiro.

Do lado de fora da sala de operações, a empresa continuava funcionando sem saber que, durante a madrugada, uma pequena batalha havia sido vencida.

Não por uma espada.

Não por uma linha de código isolada.

Mas por uma ponte que permaneceu de pé.

E, em algum lugar da fortaleza, o homem sem espada já examinava o próximo mapa.

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

Consultar arquivo

25 documentos

2014–2016 linha histórica

IBM Z fortaleza digital

COBOL linguagem da missão

Arquivo estratégico

Um Data Center analisado como uma fortaleza em guerra

Sala de operações

Índice da campanha

25 documentos localizados

Pesquisar no arquivo Categoria Ordenação

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

Engenharia Militar — Índice da campanha

O JavaScript está desativado. Utilize o índice permanente de links exibido nesta página para acessar os artigos.

Translate

sexta-feira, 6 de junho de 2025

Engenharia Militar : Especial — A Guerra da Ucrânia

☕ Um Café no Bellacosa Mainframe

Engenharia Militar sem Mistérios para Programadores COBOL

Especial — A Guerra da Ucrânia

Quando um Programador COBOL Descobre que uma Guerra do Século XXI é Travada ao Mesmo Tempo por Drones, Satélites, Software, Logística, Informação e Vontade Humana

Introdução

Antes da Guerra

O Erro das Previsões

A Resistência Ucraniana

As Grandes Lições da Guerra

1. Logística continua decidindo campanhas

2. Informação vale tanto quanto fogo

3. Pequenos drones mudaram a guerra

4. Guerra eletrônica voltou ao centro

5. Software tornou-se arma estratégica

6. Adaptação supera planejamento rígido

O Que um Estrategista Deve Observar

Paralelos com IBM Z

A Guerra da Informação

Como o Mundo dos Animes Reagiu

Legend of the Galactic Heroes

86 Eighty-Six

Mobile Suit Gundam

Saga of Tanya the Evil

Attack on Titan

Curiosidade

Easter Egg Bellacosa

Conclusão

Engenharia Militar

quinta-feira, 7 de julho de 2016

Engenharia Militar : Os 10 Animes Mais Emblemáticos Sobre Logística Militar

☕ Um Café no Bellacosa Mainframe

Engenharia Militar : Os 10 Animes Mais Emblemáticos Sobre Logística Militar

Quando um Programador COBOL Descobre que Guerras Não São Vencidas por Espadas... São Vencidas por Comboios, Armazéns e Linhas de Suprimento

Introdução

1. Legend of the Galactic Heroes (銀河英雄伝説)

Resumo

Personagens

Lição Logística

Analogia IBM Z

2. Kingdom

Resumo

Personagens

Lição Logística

Analogia IBM Z

3. Gate: Jieitai Kanochi nite, Kaku Tatakaeri

Resumo

Personagens

Lição Logística

Analogia IBM Z

4. Alderamin on the Sky (Nejimaki Seirei Senki)

Resumo

Personagens

Lição Logística

Analogia IBM Z

5. Shoukoku no Altair

Resumo

Personagens

Lição Logística

Analogia IBM Z

6. Arslan Senki (The Heroic Legend of Arslan)

Resumo

Personagens

Lição Logística

Analogia IBM Z

7. Vinland Saga

Resumo

Personagens

Lição Logística

Analogia IBM Z

8. Goblin Slayer

Resumo

Personagens

Lição Logística

Analogia IBM Z

9. Saga of Tanya the Evil (Youjo Senki)

Resumo

Personagens