COBOL: de 1959 até hoje — quando o código atravessa décadas sem pedir aposentadoria.

 

💾 EL JEFE MIDNIGHT LUNCH — Bellacosa Mainframe Chronicles

“COBOL: de 1959 até hoje — quando o código atravessa décadas sem pedir aposentadoria.”

---

Há linguagens que nascem modinha.
Há linguagens que viram tese acadêmica.
E há o COBOL, que nasceu em 1959 e simplesmente se recusou a morrer — porque alguém precisava rodar o mundo real: folha, banco, seguro, governo, avião no ar e salário no fim do mês.

Hoje vamos fazer uma linha do tempo completa do COBOL no Mainframe, do nariz de foguete dos anos 50 até o Enterprise COBOL moderno, com comentários, curiosidades, easter eggs e aquele café forte do Bellacosa Mainframe.

Senta que lá vem história. ☕

---

🕰️ 1959 — COBOL nasce

COBOL (Common Business-Oriented Language)
Criado por um comitê liderado por Charles A. Phillips e Joseph Wegstein. 

🔹 O que havia de novo:

• Linguagem quase em inglês

• Pensada em humanos e não técnicos de informatica.

• Foco em negócios, não em matemática

• Independência de hardware (uma heresia para a época)

🔹 Equipe criadora do COBOL, listagem não exaustiva:

Alfred Asch (U.S. Air Force)

Benjamin Cheydleur (RCA)

Charles Gaudette (Minneapolis-Honeywell)

Daniel Goldstein (Univac)

Frances “Betty” Holberton (David Taylor Model Basin)

Gertrude Tierney (IBM)

Howard Bromberg (RCA)

Jean Sammet (Sylvania)

Joseph Wegstein (National Bureau of Standards)

Mary Hawes (Burroughs)

Norman Discount (RCA)

Vernon Reeves (Sylvania)

William Logan (Burroughs)

William Selden (IBM)

🧠 Curiosidade:
Grace Hopper odiava linguagens “ilegíveis”. O COBOL nasceu para ser lido por gerentes — ironicamente, só programadores entendem até hoje.

🥚 Easter egg:
O verbo ADD A TO B GIVING C é praticamente poesia corporativa.

---

🕰️ 1968 — COBOL ANSI 68

Primeira padronização oficial.

🔹 Novidades:

• Estrutura formal

• Maior portabilidade

• Divisão clara em IDENTIFICATION, ENVIRONMENT, DATA e PROCEDURE

🧠 Comentário Bellacosa:
Aqui o COBOL virou “linguagem séria”. Antes era festa; depois, contrato.

---

🕰️ 1974 — COBOL ANSI 74

A versão que dominou os mainframes por décadas.

🔹 Novidades:

• IF/ELSE estruturado

• PERFORM mais poderoso

• Adeus aos GO TO anárquicos (ou quase)

🧠 Curiosidade:
Boa parte do código que rodou no Y2K ainda era ANSI 74.

---

🕰️ 1985 — COBOL ANSI 85

O COBOL aprende boas maneiras.

🔹 Novidades:

• Scope terminators (END-IF, END-PERFORM)

• Código mais legível

• Base do COBOL “estruturado”

🥚 Easter egg:
Muita gente ainda hoje esquece o END-IF e culpa o compilador.

---

🕰️ Anos 80 — COBOL VS / VS II (IBM)

O COBOL entra no reino do MVS.

🔹 Novidades:

• Integração forte com JCL

• Batch pesado

• Performance absurda para a época

🧠 Comentário Bellacosa:
Aqui o COBOL virou músculo. Forte, bruto e confiável.

---

🕰️ 1991 — COBOL/370

Primeiro grande passo rumo ao “Enterprise”.

🔹 Novidades:

• Melhor otimização

• Suporte avançado a CICS e DB2

• Integração com arquitetura System/370

---

🕰️ 1994 — Enterprise COBOL 3.2

🔥 Marco histórico.

🔹 O que há de novo:

• Language Environment (LE)

• Runtime comum com PL/I e C

• Otimização real de código

🧠 Curiosidade:
Muitos chamam o LE de “chatice”. Até o primeiro dump bem explicado salvar seu emprego.

🥚 Easter egg:
CEE3ABD virou melhor amigo de quem debuga madrugada.

---

🕰️ 1996 — Enterprise COBOL 3.3

O compilador do Bug do Milênio.

🔹 Novidades:

• Melhor I/O

• Mais estabilidade

• Código gerado mais rápido

🧠 Comentário Bellacosa:
Se o mundo não acabou em 01/01/2000, agradeça ao COBOL 3.3.

---

🕰️ 2001 — Enterprise COBOL 3.1 (z/OS)

Transição definitiva para o z/OS.

🔹 Novidades:

• Unicode (primeiros passos)

• Melhor integração com ambientes modernos

• Visão “enterprise de verdade”

🧠 Curiosidade:
Aqui o COBOL começou a flertar com XML… timidamente.

---

🕰️ 2007 — Enterprise COBOL 4.1

O salto tecnológico.

🔹 Novidades:

• Arquitetura 64 bits

• Suporte a XML nativo

• Melhor interoperabilidade

🥚 Easter egg:
Muita gente demorou anos para sair do 3.3 por medo.

---

🕰️ 2010 — Enterprise COBOL 5.1

COBOL moderno sem pedir desculpas.

🔹 Novidades:

• Performance absurda

• Melhor otimização para hardware z

• Preparação para serviços

🧠 Comentário Bellacosa:
Aqui o COBOL começa a humilhar linguagens modernas em benchmark.

---

🕰️ 2016 — Enterprise COBOL 6.1

O COBOL acorda para o século XXI.

🔹 Novidades:

• Melhor uso de CPU

• Integração com DevOps

• Compilador mais inteligente

🥚 Easter egg:
Compila mais rápido, roda mais rápido… e ainda reclamam.

---

🕰️ 2019–2022 — Enterprise COBOL 6.2 / 6.3 / 6.4

O COBOL sem vergonha de ser moderno.

🔹 Novidades:

• Melhor suporte a APIs

• Integração com pipelines

• Foco em cloud híbrida e z/OS Connect

🧠 Curiosidade:
COBOL virou backend de API REST. Sim, isso é real.

---

🕰️ 2023–2025 — Enterprise COBOL 6.5 (atual)

O COBOL que ri do etarismo.

🔹 O que há de novo:

• Performance ainda maior

• Melhor diagnóstico

• Alinhamento com z/OS moderno, containers e automação

• Funções intrínsecas criadas pelo programador

🧠 Comentário Bellacosa:
Enquanto discutem se COBOL morreu, ele roda bilhões de transações por dia.

---

☕ Conclusão Bellacosa Mainframe

COBOL não sobreviveu apesar do tempo.
Ele sobreviveu porque o tempo precisava dele.

De 1959 até hoje:

• Mudou

• Evoluiu

• Aprendeu XML, API, DevOps, Unicode e JSON
  Mas nunca perdeu seu propósito: fazer o negócio rodar.

“COBOL não é velho.
Velho é sistema que cai.”
— El Jefe Midnight Lunch

Fonte: https://www.ibm.com/docs/pt-br/cobol-zos/6.5.0?topic=overview-cobol-compiler-versions-required-runtimes-support-information 

Tabela 1. Nomes de compiladores COBOL, versões e releases, identificadores de produtos, datas GA e EOS e tempos de execução necessários

Compilador	Versão, liberação e nível de modificação	Identificador de produto (PID)	Data de disponibilidade geral (GA) (Ano-Mês-Dia)	Data do fim do suporte (EOS)1 (Ano-Mês-Dia)	Tempos de execução necessários2
OS/VS COBOL	1.2.1	-	-	-	-
OS/VS COBOL	1.2.2	-	-	-	-
OS/VS COBOL	1.2.3	5740-CB1	1974-09-23	1999-12-31	Biblioteca de tempo de execução COBOL OS/VS; ou Biblioteca de tempo de execução do VS COBOL II; ou z/OS Language Environment
OS/VS COBOL	1.2.4	5740-CB1	1976-09-23	1999-12-31	Biblioteca de tempo de execução COBOL OS/VS; ou Biblioteca de tempo de execução do VS COBOL II; ou z/OS Language Environment
VS COBOL II	1.1	5668-958	1985-10-01	1997-06-30	Biblioteca de tempo de execução do VS COBOL II; ou z/OS Language Environment
VS COBOL II	1.2	5668-958	1986-12-19	1997-06-30	Biblioteca de tempo de execução do VS COBOL II; ou z/OS Language Environment
VS COBOL II	1.33	5668-958	1988-12-16	1996-06-30	Biblioteca de tempo de execução do VS COBOL II; ou z/OS Language Environment
VS COBOL II	1.43	5668-958	1993-03-12	2001-03-31	Biblioteca de tempo de execução do VS COBOL II; ou z/OS Language Environment
COBOL/370	1.1	5688-197	1991-12-20	1997-09-30	z/OS Language Environment
COBOL para MVS & VM	1.2	5688-197	1995-10-27	2001-12-31	z/OS Language Environment
COBOL for OS/390® & VM	2.13	5648-A25	1997-05-23	2004-12-31	z/OS Language Environment
COBOL for OS/390 & VM	2.23	5648-A25	2000-09-29	2004-12-31	z/OS Language Environment
Enterprise COBOL for z/OS®	3.1	5655-G53	2001-11-30	2004-04	z/OS Language Environment
Enterprise COBOL for z/OS	3.2	5655-G53	2002-09-27	2005-10-03	z/OS Language Environment
Enterprise COBOL para z/OS	3.3	5655-G53	2004-02-27	2007-04-30	z/OS Language Environment
Enterprise COBOL para z/OS	3.4	5655-G53	2005-07-01	2015-04-30	z/OS Language Environment
Enterprise COBOL para z/OS	4.1	5655-S71	2007-12-14	2014-04-30	z/OS Language Environment
Enterprise COBOL para z/OS	4.2	5655-S71	2009-08-28	2022-04-30	z/OS Language Environment
Enterprise COBOL para z/OS	5.1	5655-W32	2013-06-21	2020-04-30	z/OS Language Environment
Enterprise COBOL para z/OS	5.2	5655-W32	2015 -02-27	2020-04-30	z/OS Language Environment
Enterprise COBOL para z/OS	6.1	5655-EC6	2016-03-18	2022-09-30	z/OS Language Environment
Enterprise COBOL para z/OS	6.2	5655-EC6	2017-09-08	2024-09-30	z/OS Language Environment
Enterprise COBOL para z/OS	6.3	5655-EC6	2019-09-06	2025-09-30	z/OS Language Environment
Enterprise COBOL
Enterprise COBOL para z/OS	6.4	5655-EC6	2022-05-27	A ser determinado	z/OS Language Environment
Enterprise COBOL para z/OS	6.5	5655-EC6	2025-06-13	A ser determinado	z/OS Language Environment

 

Laboratório Prático de Java para IBM Mainframe 20 Labs para Transformar um Programador COBOL em um Desenvolvedor Java para IBM Z

 

Bellacosa Mainframe e um laboratorio java para mainframers

☕ Um Café no Bellacosa Mainframe

Laboratório Prático de Java para IBM Mainframe

Metodologia do Laboratório

Este laboratório foi desenvolvido para programadores COBOL iniciantes no ecossistema IBM Z, utilizando uma metodologia prática baseada no conceito learning by doing (aprender fazendo). Em vez de ensinar Java de forma isolada, cada conceito é apresentado em paralelo com tecnologias já conhecidas pelo desenvolvedor Mainframe, como COBOL, JCL, CICS, DB2, VSAM e z/OS. Dessa forma, o aluno estabelece uma associação natural entre os dois ambientes, reduzindo a curva de aprendizado e compreendendo como ambas as linguagens coexistem na arquitetura corporativa moderna.

Os vinte laboratórios evoluem gradualmente, começando pelos fundamentos da linguagem Java, passando por orientação a objetos, tratamento de exceções, coleções, acesso ao DB2 via JDBC, processamento Batch, APIs REST, WebSphere Liberty, IBM MQ, z/OS Connect, automação com Ansible, DevOps, LinuxONE e containers. Cada exercício apresenta objetivos claros, arquitetura, código comentado, desafios práticos e solução completa.

Ao final do treinamento, espera-se que o desenvolvedor compreenda o papel estratégico do Java no IBM Z e no LinuxONE, saiba como a JVM é executada nessas plataformas, desenvolva aplicações Batch e Online, integre serviços Java com programas COBOL e DB2, automatize processos utilizando ferramentas modernas e participe de projetos de modernização sem abandonar os sólidos fundamentos do Mainframe. O objetivo não é substituir o COBOL, mas formar profissionais capazes de transitar com segurança por todo o ecossistema IBM Z.

20 Labs para Transformar um Programador COBOL em um Desenvolvedor Java para IBM Z

Objetivo: Capacitar um programador COBOL Junior a compreender como o Java funciona dentro do ecossistema IBM Z, sempre relacionando os novos conceitos com aquilo que ele já conhece em COBOL, JCL, CICS e DB2.

---

Filosofia do Laboratório

Este não é um curso tradicional de Java.

É um curso pensado para quem já conhece Mainframe.

Durante todos os exercícios faremos comparações entre:

• COBOL × Java

• JCL × JVM

• CICS × Liberty

• SQL Embutido × JDBC

• VSAM × Collections

• Batch × Java Batch

• Online CICS × REST APIs

O objetivo é diminuir o choque entre os dois mundos.

---

Ambiente sugerido

Desenvolvimento

• VS Code

• IBM Z Open Editor

• Java 21 LTS

• Maven

• Git

• Zowe CLI

Mainframe

• IBM z/OS

• USS (Unix System Services)

• Enterprise COBOL

• DB2

• CICS TS

• z/OS Connect

• IBM MQ

• WebSphere Liberty

Opcional

• LinuxONE

• Docker

• OpenShift

• Ansible

---

LAB 01 — Primeiro Programa Java

Objetivo

Criar o famoso Hello World.

O que aprender

• Classe

• Método main()

• JVM

• Compilação

Exercício

Criar

HelloMainframe.java

Executar

javac HelloMainframe.java

java HelloMainframe

Solução

Exibir

Olá IBM Z

---

LAB 02 — Comparando COBOL e Java

Objetivo

Criar um programa que recebe nome e idade.

Comparar com

WORKING-STORAGE
DISPLAY
ACCEPT

Aprender

• Scanner

• Variáveis

• String

• int

Solução

Programa imprime

Olá João

Você possui 30 anos

---

LAB 03 — Estruturas de Decisão

Comparar

COBOL

IF
ELSE
END-IF

com

Java

if

else

Exercício

Calcular maioridade.

---

LAB 04 — Estruturas de Repetição

Comparar

PERFORM UNTIL

com

for

while

Exercício

Exibir números de 1 a 100.

---

LAB 05 — Métodos

Comparar

SECTION

PARAGRAPH

com

Métodos Java

Criar método

calcularIR()

---

LAB 06 — Orientação a Objetos

Primeiro contato.

Criar

Cliente
Conta

Banco

Aprender

• classe

• objeto

• atributos

• métodos

---

LAB 07 — Collections

Comparar

Tabela OCCURS

com

ArrayList

Exercício

Cadastrar clientes.

---

LAB 08 — Tratamento de Exceções

Comparar

IF SQLCODE

IF FILE STATUS

com

try

catch

Gerar erro proposital.

Capturar erro.

---

LAB 09 — Leitura de Arquivos

Comparar

Sequential File

com

BufferedReader

Ler arquivo

CLIENTES.TXT

---

LAB 10 — Escrevendo Arquivos

Criar

RELATORIO.TXT

Comparar

WRITE

com

FileWriter.

---

LAB 11 — JDBC + DB2

Objetivo

Primeira conexão com DB2.

Aprender

• Driver JDBC

• Connection

• Statement

• ResultSet

Consulta

SELECT *

CLIENTE

Solução

Exibir registros na tela.

---

LAB 12 — PreparedStatement

Comparar

EXEC SQL

com

PreparedStatement

Inserir cliente.

Depois atualizar.

Depois excluir.

---

LAB 13 — Java Batch

Criar um processamento Batch.

Fluxo

Ler Arquivo

↓

Validar

↓

Atualizar DB2

↓

Gerar Relatório

Executar usando JCL.

---

LAB 14 — Java no USS

Entrar no Unix System Services.

Executar

java

javac

jar

Aprender

• PATH

• JAVA_HOME

• CLASSPATH

---

LAB 15 — WebSphere Liberty

Criar primeira aplicação.

Executar

localhost:9080

Primeira API REST.

---

LAB 16 — Java + MQ

Criar

Produtor

Consumidor

Enviar mensagens.

Comparar com Batch desacoplado.

---

LAB 17 — Java + CICS

Criar aplicação Java.

Consumir programa COBOL.

Fluxo

Java

↓

CICS

↓

COBOL

Entender integração.

---

LAB 18 — Java + z/OS Connect

Criar API REST.

Consumir programa COBOL.

Resultado

GET

/clientes

Retorna

JSON.

---

LAB 19 — Deploy Automatizado

Criar Pipeline.

Ferramentas

• Git

• Maven

• Jenkins

• Zowe

• Ansible

Deploy automático.

---

LAB 20 — Projeto Final

Sistema Bancário Completo

Arquitetura

Cliente

↓

REST API

↓

Spring Boot

↓

Liberty

↓

MQ

↓

CICS

↓

COBOL

↓

DB2

---

O Projeto

Cadastrar clientes.

Consultar clientes.

Atualizar clientes.

Excluir clientes.

Gerar relatório Batch.

Consultar API REST.

Executar deploy automático.

---

Estrutura sugerida

MainframeJavaLabs

│

├── Lab01_HelloJava

├── Lab02_Variaveis

├── Lab03_IF

├── Lab04_FOR

├── Lab05_Metodos

├── Lab06_OO

├── Lab07_Collections

├── Lab08_Exceptions

├── Lab09_Arquivos

├── Lab10_FileWriter

├── Lab11_JDBC

├── Lab12_PreparedStatement

├── Lab13_JavaBatch

├── Lab14_USS

├── Lab15_Liberty

├── Lab16_MQ

├── Lab17_CICS

├── Lab18_zOSConnect

├── Lab19_Ansible

└── Lab20_ProjetoFinal

O que cada laboratório deve conter

Para que o aprendizado seja realmente prático, todos os 20 laboratórios devem seguir a mesma estrutura:

• Objetivo: o que será aprendido e por que isso é importante no IBM Z.

• Conceitos COBOL equivalentes: comparação direta entre os conceitos de COBOL e Java.

• Arquitetura: diagrama do fluxo da aplicação.

• Pré-requisitos: softwares, datasets, tabelas DB2 ou configurações necessárias.

• Passo a passo: instruções detalhadas de implementação.

• Código comentado: explicando cada linha e sua função.

• Compilação e execução: tanto no ambiente local quanto no z/OS, quando aplicável.

• Análise dos resultados: como validar se tudo funcionou corretamente.

• Desafios extras: exercícios para expandir o laboratório.

• Solução completa: código-fonte, JCL, scripts Maven/Gradle, SQL e arquivos de configuração.

Competências desenvolvidas

Ao concluir os 20 laboratórios, o programador COBOL Junior terá desenvolvido competências para:

• Escrever aplicações Java orientadas a objetos.

• Compreender a execução da JVM no IBM Z.

• Criar programas Batch em Java executados por JCL.

• Desenvolver APIs REST com Spring Boot e WebSphere Liberty.

• Integrar aplicações Java com programas COBOL via CICS e z/OS Connect.

• Acessar tabelas DB2 utilizando JDBC e PreparedStatement.

• Utilizar IBM MQ para comunicação assíncrona.

• Trabalhar com USS (Unix System Services).

• Automatizar builds e deploys com Maven, Git, Jenkins, Zowe e Ansible.

• Entender o papel do LinuxONE, Docker e OpenShift na modernização do ecossistema IBM Z.

Resultado esperado

Ao final desse laboratório, o aluno deixará de enxergar Java como uma tecnologia "concorrente" do COBOL. Em vez disso, compreenderá como ambas as linguagens coexistem no IBM Z, cada uma exercendo um papel específico na arquitetura corporativa moderna. Esse conhecimento amplia significativamente as oportunidades profissionais e prepara o desenvolvedor para atuar em projetos de modernização, integração por APIs e DevOps, mantendo o COBOL como o coração das regras de negócio e o Java como a ponte entre o Mainframe e o restante do mundo.

Aprenda COBOL

Evolua na Stack Mainframe
Aprenda COBOL

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

守
GUARDIÃO