☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta memeframefriday. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta memeframefriday. Mostrar todas as mensagens

terça-feira, 24 de setembro de 2024

COBOL razões por dominar o CPD.

Bellacosa Mainframe em uma viagem ao centro do cpd


☕ Um Café no Bellacosa Mainframe

Viagem ao Centro do CPD — Por que COBOL Ainda Domina as Profundezas da Terra Corporativa

🌋🦖 Júlio Verne, COBOL, bilhões de linhas, bancos, CICS, Db2, VSAM, batch e uma expedição às camadas subterrâneas da informática para descobrir por que o dinossauro simplesmente se recusa a morrer

Existe uma teoria muito difundida sobre COBOL.

Segundo ela, em algum momento dos anos 1980 alguém deveria ter desligado todos os mainframes, colocado os programas COBOL dentro de um museu e substituído tudo por alguma coisa moderna.

Primeiro:

C

Depois:

C++

Depois:

Java

Depois:

.NET

Depois:

SOA

Depois:

Cloud

Depois:

Microservices

Depois:

Serverless

Depois:

Kubernetes

Agora:

IA

COBOL ouviu todas essas previsões.

Sentado tranquilamente nas profundezas do CPD.

Processando folha de pagamento.

Compensando transações.

Atualizando contas.

Emitindo apólices.

Calculando juros.

Executando batch.

E respondendo:

DISPLAY 'AINDA ESTOU AQUI'.

Talvez estejamos procurando COBOL no lugar errado.

Para entender sua sobrevivência precisamos seguir Júlio Verne.

Não olhar para o céu.

Precisamos descer.

Muito.

Porque hoje faremos uma:

VIAGEM AO CENTRO DO CPD.


📖 Hamburgo, 1863

Em Viagem ao Centro da Terra, Júlio Verne apresenta o professor Otto Lidenbrock, mineralogista alemão que encontra um misterioso manuscrito contendo uma mensagem cifrada.

O documento indica que o explorador islandês Arne Saknussemm teria encontrado uma passagem para o interior da Terra através do vulcão Snæfellsjökull, na Islândia.

Lidenbrock decide imediatamente:

Vamos entrar.

Seu sobrinho Axel provavelmente pensa:

Talvez não.

Lidenbrock:

Vamos.

E lá vão eles.

É basicamente a mesma sensação de um jovem programador quando alguém diz:

“Precisamos fazer manutenção neste sistema COBOL de 1987.”

Ele pergunta:

— Existe documentação?

O gerente entrega um PDF de 14 páginas atualizado pela última vez em 1996.

No rodapé:

AUTOR: APARECIDO
RAMAL: 4372

Aparecido aposentou-se em 2008.

Meu jovem...

pegue sua lanterna.

Nós vamos descer.



🗺️ O mapa para o centro do CPD

Nossa expedição atravessará várias camadas:

SUPERFÍCIE
   ↓
APIs
   ↓
CICS
   ↓
COBOL
   ↓
Db2 / VSAM / IMS
   ↓
JCL
   ↓
JES2
   ↓
z/OS
   ↓
IBM Z
   ↓
DADOS + REGRAS DE NEGÓCIO

E talvez descubramos uma coisa perturbadora.

Aquilo que parece antigo na superfície pode estar sustentando praticamente tudo que existe acima.



🌋 CAMADA 1 — A superfície moderna

Começamos no mundo que todo mundo enxerga.

Aplicativos.

Sites.

Smartphones.

APIs.

Cloud.

Containers.

Interfaces maravilhosas.

Cliente toca:

TRANSFERIR R$ 500

Tela gira.

Bonita animação.

Confirmação biométrica.

Push notification.

Tudo parece muito moderno.

Mas agora vamos seguir aquela transação.

APP
 ↓
API
 ↓
GATEWAY
 ↓
SERVIÇO
 ↓
?

Existe uma porta.

Axel pergunta:

— Professor, o que existe ali?

Lidenbrock acende a lanterna.

Na parede está escrito:

CICS

Ah.

Agora começou a aventura.



🏦 RAZÃO 1 — COBOL mora onde o dinheiro mora

Essa talvez seja a primeira grande explicação.

COBOL não sobreviveu porque alguém sente nostalgia.

Ele sobreviveu porque foi utilizado durante décadas justamente nos sistemas que organizações não podem simplesmente desligar.

Bancos.

Seguradoras.

Governos.

Varejo.

Transportes.

Processamento financeiro.

Folhas de pagamento.

Grandes sistemas administrativos.

Quando uma aplicação controla algo secundário, substituí-la pode ser relativamente simples.

Quando ela controla:

DINHEIRO

a conversa muda.

Você não migra simplesmente:

“Vamos ver se funciona.”

Você precisa garantir:

EXATIDÃO
INTEGRIDADE
AUDITORIA
RECUPERAÇÃO
CONSISTÊNCIA
SEGURANÇA
PERFORMANCE
DISPONIBILIDADE

E existe outra coisa importantíssima:

o sistema atual já funciona.


🪨 CAMADA 2 — CICS

Descemos mais.

Uma gigantesca cidade subterrânea aparece.

Milhares de transações atravessam túneis simultaneamente.

Bem-vindo ao:

CICS

Aqui programas COBOL podem atender processamento transacional online.

TRANSACTION
   ↓
CICS
   ↓
PROGRAM
   ↓
DB2 / VSAM / MQ
   ↓
RESPONSE

Lidenbrock observa.

— Quantos anos tem isso?

Mainframeiro:

— Depende.

— Devemos substituir?

— Por quê?

Silêncio.

Essa pergunta muda tudo.


⚙️ RAZÃO 2 — Maturidade

Tecnologia madura possui uma característica pouco sexy:

sabemos como ela quebra.

Isso é extraordinariamente valioso.

Depois de décadas usando uma plataforma, conhecemos:

LIMITES
PADRÕES
ERROS
COMPORTAMENTO
FERRAMENTAS
PROCEDIMENTOS
RECUPERAÇÃO
MONITORAMENTO

Tecnologia nova frequentemente chega acompanhada de:

“Segundo a documentação...”

Tecnologia madura chega acompanhada de:

“Em 2003 aconteceu isso. Faça desta maneira.”

Experiência acumulada é infraestrutura invisível.


🦖 CAMADA 3 — Encontramos COBOL

Finalmente chegamos.

Uma enorme caverna.

Nas paredes:

IDENTIFICATION DIVISION.

Mais adiante:

DATA DIVISION.

Axel fica assustado.

— Professor...

— Sim?

— Aquilo é um dinossauro?

O animal vira lentamente a cabeça.

Na lateral está escrito:

ENTERPRISE COBOL

Lidenbrock aproxima-se.

— Achei que estivesse extinto.

O dinossauro responde:

PERFORM PROCESS-TRANSACTION
   UNTIL END-OF-FILE.

Não está extinto.

Está trabalhando.


📚 RAZÃO 3 — COBOL descreve negócios muito bem

Olhe:

IF CUSTOMER-BALANCE > CREDIT-LIMIT
    MOVE 'BLOCKED' TO CUSTOMER-STATUS
END-IF.

Não é poesia.

Não é compacto.

Não ganhará concurso de elegância.

Mas existe uma qualidade extraordinária:

conseguimos entender aproximadamente o que está acontecendo.

COBOL nasceu orientado ao processamento empresarial.

Registros.

Campos.

Valores decimais.

Arquivos.

Relatórios.

Regras.

Volumes.

E empresas são cheias exatamente disso.


💰 RAZÃO 4 — Decimal importa

Agora encontramos uma caverna cheia de moedas.

Lidenbrock pega uma.

Mainframeiro grita:

— NÃO TOQUE NO COMP-3!

COBOL possui excelente tradição no tratamento de dados decimais empresariais.

Imagine:

01 WS-BALANCE PIC S9(11)V99 COMP-3.

Bancos gostam de uma coisa chamada:

dinheiro exato.

Dinheiro não aprecia:

0.1 + 0.2 = 0.30000000000000004

Quando você processa milhões ou bilhões de operações financeiras, representação e aritmética decimal importam enormemente.

COBOL cresceu nesse universo.


🗄️ CAMADA 4 — Db2, VSAM e IMS

Descemos mais.

Encontramos três criaturas ancestrais guardando enormes cofres.

Db2
VSAM
IMS

Axel:

— Quanto dado existe aqui?

Lidenbrock:

— Não pergunte.

Mainframeiro:

— Principalmente não execute SELECT sem WHERE.

Agora percebemos outra razão da longevidade.


🧠 RAZÃO 5 — O código contém conhecimento empresarial

Imagine um programa criado em 1989.

Durante 37 anos recebeu alterações.

1991 — nova regra tributária
1994 — novo produto
1998 — alteração monetária
2002 — novo cliente
2007 — nova regulamentação
2012 — fusão
2018 — nova regra
2021 — exceção
2026 — API

Agora aquele programa não contém apenas código.

Ele contém:

HISTÓRIA DA EMPRESA.

E frequentemente parte dessa história não existe em outro lugar.

A documentação diz:

“Calcular tarifa conforme regra comercial.”

O COBOL possui 3.800 linhas explicando o que “conforme regra comercial” realmente significa.


🏺 Código como arqueologia

Isso transforma manutenção COBOL em arqueologia empresarial.

Você encontra:

IF CUSTOMER-TYPE = '7'
   AND REGION = '03'
   AND CONTRACT-DATE < 19980701
   MOVE ZERO TO WS-FEE
END-IF.

Pergunta:

— Por quê?

Silêncio.

Git não existia.

O autor aposentou-se.

Documento desapareceu.

Mas existe uma certeza:

alguém colocou aquilo ali por algum motivo.

Talvez uma lei.

Talvez contrato.

Talvez decisão judicial.

Talvez promoção.

Talvez gambiarra.

Apague e descubra.

Em produção.


💀 A maldição de Saknussemm

Na parede encontramos uma inscrição:

* DO NOT REMOVE

Sem explicação.

Axel:

— Podemos remover?

Lidenbrock:

— Não.

— Por quê?

— Porque alguém escreveu DO NOT REMOVE.

— Mas quem?

— Saknussemm.

Nunca desafie Saknussemm.


💵 RAZÃO 6 — Reescrever custa dinheiro

Agora chegamos a uma gigantesca montanha.

No topo:

LEGACY MODERNIZATION PROJECT

Consultor:

— Vamos reescrever tudo.

Diretor:

— Quanto custa?

Consultor:

— Sim.

Existe uma fantasia recorrente:

COBOL
 ↓
REWRITE
 ↓
MODERNO

Parece simples.

Mas programas representam décadas de requisitos.

Então você precisa reproduzir:

REGRAS
INTERFACES
ARQUIVOS
TRANSAÇÕES
EXCEÇÕES
PERFORMANCE
SEGURANÇA
AUDITORIA
RECOVERY
BATCH WINDOWS
DEPENDÊNCIAS

E provar que o novo sistema produz resultados equivalentes.


⚠️ RAZÃO 7 — Risco de migração

Imagine um sistema processando:

10.000.000 transações/dia

Novo sistema funciona corretamente em:

99,99%

Parece excelente.

Até perceber que:

0,01%

de dez milhões são:

1.000 transações.

Por dia.

Agora coloque dinheiro envolvido.

Subitamente quatro noves não parecem tão românticos.


🚂 CAMADA 5 — Batch

Escutamos um ruído.

CLACK
CLACK
CLACK

Não é trem.

É batch.

JES2 recebe milhares de JOBs.

INPUT
 ↓
EXECUTION
 ↓
OUTPUT

Durante décadas empresas construíram gigantescas cadeias:

JOB001
 ↓
JOB002
 ↓
JOB003
 ↓
SORT
 ↓
JOB004
 ↓
DB2 LOAD
 ↓
JOB005
 ↓
REPORT

Essa engrenagem pode parecer antiga.

Mas processa volumes enormes de maneira previsível.


⏱️ RAZÃO 8 — Throughput

Existe uma diferença entre:

atender uma requisição.

e:

processar 300 milhões de registros durante uma janela operacional.

COBOL e mainframe cresceram profundamente ligados ao segundo problema.

Batch não morreu.

Porque o problema batch não morreu.

Empresas continuam precisando:

FECHAR DIA
CALCULAR JUROS
PROCESSAR FATURAS
CONSOLIDAR CONTAS
GERAR RELATÓRIOS
PROCESSAR PAGAMENTOS

Às 02:00 ninguém precisa de uma interface React maravilhosa.

Precisa:

JOB ENDED - RC 0000

⚡ RAZÃO 9 — Performance não é apenas benchmark

Uma aplicação crítica não vive sozinha.

Ela compartilha máquina.

CPU.

Memória.

I/O.

Storage.

Banco.

Locks.

Filas.

Threads.

Mainframe desenvolveu durante décadas mecanismos sofisticados para administrar cargas enormes e concorrentes.

COBOL tornou-se parte natural desse ecossistema.

O valor está no conjunto:

COBOL
+
z/OS
+
CICS
+
Db2
+
JES2
+
WLM
+
RACF
+
STORAGE

Não apenas na linguagem isoladamente.


🛡️ CAMADA 6 — RACF

Descemos.

Porta gigantesca.

Guardião pergunta:

USERID?

Axel entrega.

ICH408I

Acesso negado.

Lidenbrock:

— Somos exploradores científicos!

RACF:

NOT AUTHORIZED.

Finalmente encontramos alguém no romance que possui bom senso.


🔐 RAZÃO 10 — Segurança e governança

Ambientes mainframe corporativos cresceram cercados por controles rigorosos.

Autenticação.

Autorização.

Auditoria.

Segregação.

Perfis.

Recursos.

Logs.

Isso não significa:

“mainframe é magicamente invulnerável.”

Não existe isso.

Significa que existe um ecossistema maduro de controle e operação.

E trocar um sistema não significa apenas trocar linguagem.

Significa reconstruir todo esse contexto.


🔥 CAMADA 7 — O núcleo: confiabilidade

Estamos próximos do centro.

A temperatura aumenta.

Na parede:

UPTIME

Lidenbrock finalmente entende.

O verdadeiro segredo não é COBOL sozinho.

É aquilo que organizações construíram ao redor dele.

Décadas de:

OPERAÇÃO
MONITORAMENTO
BACKUP
RECOVERY
CHANGE MANAGEMENT
CAPACITY PLANNING
SEGURANÇA
PROCEDIMENTOS
AUTOMAÇÃO

A aplicação COBOL está inserida numa máquina organizacional gigantesca.


🧱 RAZÃO 11 — Se funciona, substituir precisa ter motivo

Essa é talvez a mais desconfortável.

Tecnólogos adoram novidade.

Empresas adoram:

resultado.

Imagine:

Sistema A:

IDADE: 35 anos
ESTÁVEL: SIM
CONHECIDO: SIM
PERFORMANCE: BOA
AUDITADO: SIM

Sistema B:

IDADE: 0
ARQUITETURA: LINDA
POWERPOINT: EXTRAORDINÁRIO
RISCO: ???

Qual você coloca para processar bilhões?

Resposta:

depende do problema.

E justamente esse “depende” explica grande parte da longevidade do COBOL.


👴 RAZÃO 12 — Código antigo não significa código ruim

Essa confusão precisa morrer.

VELHO ≠ RUIM

Um algoritmo correto não expira porque completou 30 anos.

Se:

INPUT

continua válido,

a regra continua válida,

e:

OUTPUT

continua correto,

o programa não acorda no aniversário de 25 anos e pensa:

“Agora sou legado.”

Software não envelhece como leite.

O ambiente ao redor muda.

Requisitos mudam.

Pessoas mudam.

Riscos mudam.

Mas lógica correta pode continuar correta.


🌉 RAZÃO 13 — COBOL aprendeu a conversar com o mundo novo

Aqui nossa expedição encontra algo inesperado.

Uma fibra óptica.

Seguimos.

Ela chega até:

API

COBOL moderno não precisa viver isolado.

Podemos ter:

MOBILE
   ↓
REST
   ↓
z/OS CONNECT
   ↓
CICS
   ↓
COBOL
   ↓
DB2

Ou integração através de:

MQ
APIs
EVENTOS
JAVA
USS

O sistema de 30 anos pode participar de uma arquitetura moderna sem necessariamente ser destruído.


🔧 RAZÃO 14 — Ferramentas também evoluíram

A caricatura:

TELA VERDE
+
PROGRAMADOR DE 97 ANOS
+
CARTÃO PERFURADO

é divertida.

Mas incompleta.

Hoje podemos trabalhar com:

VS Code
Git
CI/CD
Zowe
ZUnit
DBB
Jenkins
GitHub
GitLab
Ansible
APIs

O código pode ser antigo.

O processo não precisa ser.


🤖 RAZÃO 15 — Agora chegou a IA

Nossa expedição encontra a criatura mais nova da caverna.

IA generativa.

Ela olha para milhões de linhas COBOL.

COBOL olha para ela.

Silêncio constrangedor.

Então alguém pergunta:

“Explique este programa.”

E ocorre algo interessante.

IA pode ajudar com:

COMPREENSÃO
DOCUMENTAÇÃO
TESTES
ANÁLISE
REFACTORING
MIGRAÇÃO
IMPACT ANALYSIS

Um dos grandes problemas históricos do legado — compreender código antigo — pode ser justamente uma das áreas onde IA oferece enorme potencial.

Ironia maravilhosa.

A tecnologia mais nova ajudando a preservar e modernizar uma das linguagens comerciais mais antigas.


🧠 RAZÃO 16 — O problema não é COBOL; é conhecimento

Empresas frequentemente dizem:

“Não encontramos COBOLzeiros.”

Existe verdade nisso em vários mercados.

Mas existe outra pergunta:

quantos desenvolvedores realmente conhecem as regras daquele sistema?

Você pode converter:

IF A = B
   PERFORM C
END-IF

para Java em cinco minutos.

O difícil é descobrir:

por que C precisa acontecer quando A = B.

Linguagem pode ser convertida.

Conhecimento de domínio precisa ser compreendido.

Essa é outra espécie de problema.


🌋 Encontramos o centro do CPD

Depois de dias descendo, Lidenbrock finalmente chega ao grande salão subterrâneo.

Esperávamos encontrar:

COBOL

no centro.

Não encontramos.

Encontramos algo muito maior.

Escrito na parede:

REGRAS DE NEGÓCIO

Agora tudo faz sentido.

COBOL não domina determinadas organizações simplesmente porque seja velho.

Nem porque alguém esqueceu de desligá-lo.

Ele permanece porque durante décadas empresas depositaram dentro desses sistemas:

PROCESSOS
CONTRATOS
REGRAS
EXCEÇÕES
HISTÓRIA
DINHEIRO
CONHECIMENTO

COBOL tornou-se uma espécie de rocha sedimentar empresarial.

Cada década colocou uma camada.


🪨 Arqueologia do software

2026 ─ APIs / IA / DevOps
2020 ─ Modernização
2010 ─ Serviços
2000 ─ Internet
1990 ─ Client/server
1980 ─ Expansões
1970 ─ Regras históricas
1960 ─ Fundação

No centro:

NEGÓCIO

É por isso que simplesmente arrancar COBOL pode ser equivalente a entrar numa escavação arqueológica com uma retroescavadeira.

Você certamente terminará rápido.

O problema é descobrir o que destruiu.


💡 Então COBOL é eterno?

Não.

Nenhuma tecnologia é.

COBOL pode ser substituído quando existir:

MOTIVO
+
BUSINESS CASE
+
ARQUITETURA
+
TESTES
+
MIGRAÇÃO
+
CONTROLE DE RISCO

Existem sistemas que deveriam ser aposentados.

Existem programas ruins.

Existem arquiteturas horríveis.

Existe dívida técnica.

Existe código que ninguém deveria defender apenas por nostalgia.

A questão não é:

“COBOL deve permanecer para sempre?”

A pergunta correta é:

“Qual problema estamos tentando resolver substituindo-o?”

Essa pergunta economiza milhões.


🦖 O dinossauro não venceu por ser dinossauro

Ele venceu porque continuou adaptando-se.

Padrões evoluíram.

Compiladores evoluíram.

Hardware evoluiu.

Integrações evoluíram.

Ferramentas evoluíram.

Processos evoluíram.

O COBOL de hoje não está rodando numa máquina de 1959.

Assim como Java moderno não está rodando num PC de 1995.

Confundir idade da linguagem com idade da plataforma é uma comparação intelectualmente preguiçosa.


🚀 A saída do vulcão

No romance de Verne, nossos exploradores eventualmente encontram uma saída espetacular através de atividade vulcânica.

Nossa equipe também sobe.

Passamos novamente por:

z/OS
JES2
JCL
Db2
VSAM
COBOL
CICS
APIs

Até retornar à superfície.

Smartphone na mão.

Aplicativo bancário aberto.

Axel faz uma transferência.

R$ 100,00

Confirma.

Um segundo depois:

TRANSFERÊNCIA REALIZADA.

Ele olha para Lidenbrock.

— Professor...

— Sim?

— Aquilo passou pela caverna?

O professor sorri.

Talvez.


☕ As 16 razões encontradas na expedição

Depois de nossa viagem, o diário registra:

  1. COBOL está profundamente ligado a sistemas críticos.

  2. Possui décadas de maturidade operacional.

  3. Expressa regras empresariais de maneira clara.

  4. Trabalha naturalmente com processamento decimal.

  5. Sistemas COBOL acumulam conhecimento de negócio.

  6. Reescritas completas podem custar fortunas.

  7. Migrações de sistemas críticos carregam riscos enormes.

  8. Batch continua sendo essencial.

  9. O ecossistema mainframe oferece enorme capacidade de processamento.

  10. Segurança e governança são maduras.

  11. Sistemas estáveis precisam de motivo econômico para serem substituídos.

  12. Código antigo não é automaticamente código ruim.

  13. COBOL pode integrar-se com APIs e arquiteturas modernas.

  14. Desenvolvimento COBOL pode utilizar ferramentas modernas.

  15. IA pode acelerar compreensão, teste e modernização.

  16. O ativo principal frequentemente não é o código — é o conhecimento empresarial nele acumulado.

E existe uma décima sétima razão não oficial:

porque ele ainda entrega o JOB.


☕ Epílogo — O manuscrito perdido

De volta ao escritório, Lidenbrock abre novamente o antigo manuscrito de Saknussemm.

Percebe algo estranho.

Não era islandês antigo.

Não era latim.

Era:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CENTER-OF-EARTH.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-COBOL-STATUS PIC X(08)
          VALUE 'ALIVE'.

       PROCEDURE DIVISION.

           PERFORM PROCESS-BUSINESS
              UNTIL END-OF-WORLD.

           STOP RUN.

Axel observa.

— Professor, existe um erro.

— Onde?

END-OF-WORLD ainda não aconteceu.

Lidenbrock pensa.

Ao longe, nas profundezas do CPD, escutamos JES2 trabalhando.

$HASP373 BILLING STARTED

CICS continua recebendo transações.

Db2 continua fazendo COMMIT.

COBOL continua processando.

O professor fecha o livro.

Serve outra xícara de café.

E escreve no diário da expedição:

“Não encontramos COBOL enterrado no passado. Encontramos o presente construído sobre ele.”

Lá embaixo, o dinossauro olha para o próximo registro.

READ INPUT-FILE

Processa.

WRITE OUTPUT-RECORD

E segue adiante.

Sem hype.

Sem keynote.

Sem pedir desculpas pela idade.

Apenas fazendo aquilo que faz há décadas:

movendo o mundo enquanto quase ninguém percebe.

🌋🦖☕💾

JOBNAME: EARTHJOB
PROGRAM: COBOL
STATUS : RUNNING

Próxima parada: o centro do negócio.

https://eljefemidnightlunch.blogspot.com/2007/02/o-que-e-cobol.html

https://eljefemidnightlunch.blogspot.com/2025/07/homenagem-incrivel-grace.html

https://eljefemidnightlunch.blogspot.com/2026/06/padawan-testar-cobol-nao-e-desconfiar.html

Por que o COBOL continua a dominar o Processamento de Dados no Mundo dos Negócios? Uma linguagem orientada a negócios precisa declarar, gerenciar e manipular dados heterogêneos. Programas de negócios misturam strings de comprimento fixo e variável, dados de ponto flutuante, inteiros e decimais com abandono selvagem em estruturas de registro complicadas, geralmente com partes variáveis. Os programadores de banco de dados estão familiarizados com alguns desses problemas, e ferramentas de mapeamento objeto-relacional tropeçam nessas complexidades regularmente.
 

Cobol o Rei dos CPDs



☕ Um Café no Bellacosa Mainframe

COBOL à Lua: Júlio Verne, JCL e o Primeiro Batch Interplanetário

🌕🚀 E se Da Terra à Lua, de Júlio Verne, fosse na verdade a documentação perdida de um gigantesco JOB COBOL escrito um século antes do primeiro mainframe?

Existe uma suspeita que me acompanha há algum tempo.

Talvez tenhamos interpretado Júlio Verne errado.

Durante mais de um século disseram que aquele francês escrevia ficção científica.

Submarinos.

Balões.

Viagens extraordinárias.

Máquinas impossíveis.

Explorações.

Lua.

Mas depois de décadas trabalhando com mainframe comecei a desconfiar.

Talvez Verne estivesse fazendo outra coisa.

Talvez fossem:

documentações funcionais.

Documentações extremamente antecipadas.

Porque quando releio Da Terra à Lua, publicado em 1865, encontro elementos estranhamente familiares.

Existe um requisito absurdo.

Um grupo de especialistas.

Um orçamento gigantesco.

Uma solução tecnicamente questionável.

Cálculos intermináveis.

Hardware construído especificamente para uma única missão.

Pressão por prazo.

Testes limitados.

Usuários colocados dentro da solução.

E uma data de implantação que aparentemente não pode ser alterada.

Meu amigo...

Isso não é ficção científica.

É projeto de TI.



📚 Monsieur Verne abre o chamado

Vamos primeiro ao original.

Júlio Verne publicou De la Terre à la Lune — Da Terra à Lua em 1865.

A história apresenta o Gun Club, uma associação americana formada por especialistas em artilharia que, depois da Guerra Civil dos Estados Unidos, encontra-se diante de um problema existencial.

Eles sabem construir canhões.

Sabem calcular trajetórias.

Sabem explodir coisas.

Mas acabou a guerra.

O backlog desapareceu.

Então o presidente do clube, Impey Barbicane, apresenta uma ideia perfeitamente razoável:

Vamos disparar um projétil até a Lua.

Silêncio.

Em qualquer empresa moderna alguém imediatamente levantaria a mão:

“Tem budget?”

Barbicane:

“Vamos descobrir.”

Projeto aprovado.



🦖 Enquanto isso, em 1959...

Quase cem anos depois surge outra ideia aparentemente absurda:

Criar uma linguagem de programação orientada a negócios, próxima do inglês, capaz de sobreviver entre fabricantes diferentes.

Nasce o:

COBOL

Common Business-Oriented Language.

Agora precisamos cometer um pequeno crime contra a cronologia.

Vamos colocar COBOL em 1865.

Porque Barbicane precisa calcular aquela viagem.

E eu definitivamente não entregaria uma missão lunar inteira para uma planilha.


🖥️ BARBICANE MAINFRAME CENTER

Em algum lugar da Flórida alternativa de Júlio Verne existe uma sala refrigerada.

No centro:

BELLACOSA Z1865
INTERPLANETARY COMPUTING SYSTEM

Operador coloca o JOB na fila.

//MOONJOB  JOB (VERNE),'LUNAR MISSION',
//             CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=MOONCOB
//SYSOUT   DD SYSOUT=*
//ORBITIN  DD DSN=GUNCLUB.LUNAR.DATA,DISP=SHR

JES recebe.

$HASP100 MOONJOB ON READER

Barbicane olha para o console.

Michel Ardan pergunta:

— Estamos indo para a Lua?

Operador:

— Calma.

— Por quê?

— Seu JOB ainda está aguardando initiator.


🌕 O requisito funcional

Toda grande aplicação começa com um requisito.

Nosso requisito é particularmente simples:

RF-001

ENVIAR SERES HUMANOS À LUA.

Critérios de aceite:

1. DISPARAR PROJÉTIL
2. NÃO MATAR TRIPULAÇÃO
3. ALCANÇAR LUA
4. PREFERENCIALMENTE VOLTAR

O analista funcional lê.

Pergunta:

— O item quatro é obrigatório?

Gerente:

— Vamos colocar como melhoria futura.

Perfeito.

Estamos oficialmente em produção.


🧮 COBOL começa a calcular

Nosso programa:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. MOONCOB.

       DATA DIVISION.

       WORKING-STORAGE SECTION.

       01 WS-MISSION.
          05 WS-DISTANCE-KM     PIC 9(06)V99.
          05 WS-VELOCITY        PIC 9(08)V99.
          05 WS-ANGLE           PIC 9(03)V99.
          05 WS-PROJECTILE-MASS PIC 9(08)V99.
          05 WS-GUN-LENGTH      PIC 9(06)V99.

Barbicane observa.

— Isso calcula trajetória lunar?

COBOLzeiro:

— Calcula.

— Em 1865?

— Não complique a arquitetura.


🔭 Júlio Verne tinha uma obsessão maravilhosa: números

Essa é uma das características mais interessantes de Da Terra à Lua.

Verne não simplesmente diz:

“Construíram um canhão enorme.”

Ele tenta dar dimensões.

Distâncias.

Pesos.

Custos.

Velocidades.

Materiais.

Localização.

Trajetórias.

O romance brinca constantemente com a fronteira entre:

FICÇÃO
   ↕
ENGENHARIA

E isso ajuda a produzir aquela maravilhosa sensação verniana:

“Espere... será que isso poderia funcionar?”

Hoje sabemos que disparar seres humanos de um canhão gigantesco produziria alguns pequenos inconvenientes técnicos.

Entre eles:

transformar passageiros em geleia.

Mas o espírito é extraordinário.

Verne tenta transformar fantasia em problema calculável.

E COBOL gosta exatamente disso.


🧮 COMPUTE TO THE MOON

Nosso programa recebe parâmetros.

       COMPUTE WS-TRAJECTORY =
           WS-VELOCITY * WS-ANGLE
       END-COMPUTE.

Naturalmente essa equação é ridiculamente insuficiente para mecânica orbital.

Mas estamos escrevendo um artigo Bellacosa Mainframe.

Não lançando Artemis.

Espero.

O importante é perceber a filosofia.

Barbicane pega um sonho:

IR À LUA

e começa a quebrá-lo em:

DISTÂNCIA
MASSA
VELOCIDADE
ÂNGULO
TEMPO
MATERIAL
ENERGIA
CUSTO

Isso é praticamente análise de sistemas.


🔧 Gun Club = departamento de infraestrutura

Pense nos integrantes do Gun Club.

São especialistas em hardware pesado.

Extremamente pesado.

Eles olham para um problema e imediatamente pensam:

CANHÃO MAIOR.

Isso me lembra algumas reuniões de infraestrutura.

Problema:

Aplicação está lenta.

Resposta:

MAIS CPU.

Problema continua.

MAIS MEMÓRIA.

Continua.

MAIS STORAGE.

Continua.

Até alguém chamado Penny, Grace Hopper ou estagiário pergunta:

“Vocês verificaram o programa?”

Silêncio.


💣 Columbiad: o hardware definitivo

No romance, o gigantesco canhão recebe o nome de Columbiad.

É essencialmente o dispositivo responsável pelo lançamento.

No nosso universo:

DEVICE TYPE:
LUNAR ACCELERATOR

MODEL:
COLUMBIAD 1865

STATUS:
PRODUCTION

Não existe redundância.

Não existe segundo Columbiad.

Não existe disaster recovery.

Não existe rollback.

Existe:

FIRE.

É provavelmente o deployment mais agressivo da história.


🚨 CHANGE REQUEST

Imagine o CAB — Change Advisory Board.

CHANGE:
CHG-1865-001

DESCRIPTION:
DISPARAR CÁPSULA TRIPULADA CONTRA A LUA

RISK:
HIGH

ROLLBACK:
N/A

IMPLEMENTATION WINDOW:
QUANDO A LUA ESTIVER NA POSIÇÃO CORRETA

CAB pergunta:

— Foi testado?

Barbicane:

— Fizemos cálculos.

— Existe ambiente de homologação?

— Não.

— Plano de rollback?

— Gravidade.

Change:

APPROVED.


🧔 Michel Ardan entra no requisito

Então aparece Michel Ardan.

O francês aventureiro.

Carismático.

Excêntrico.

E decide:

Se vão mandar o projétil para a Lua, eu vou dentro.

Aqui todo projeto tecnológico conhece o fenômeno.

Até aquele momento tínhamos:

PROJÉTIL NÃO TRIPULADO

Agora:

PROJÉTIL TRIPULADO

Analista:

— Isso muda completamente o requisito.

Gerente:

— É só uma pequena alteração.

A frase:

“É só uma pequena alteração”

já matou mais cronogramas que qualquer S0C7.


📋 COPYBOOK atualizado

Antes:

       01 PROJECTILE.
          05 PROJECTILE-MASS PIC 9(08).

Depois:

       01 PROJECTILE.
          05 PROJECTILE-MASS PIC 9(08).
          05 PASSENGERS.
             10 PASSENGER OCCURS 3 TIMES.
                15 PASSENGER-NAME PIC X(30).
                15 PASSENGER-WEIGHT PIC 9(03).
                15 PASSENGER-ALIVE PIC X.

Observe cuidadosamente:

PASSENGER-ALIVE

Esse campo será importante.


🧪 QA pergunta sobre testes

QA:

— Testaram aceleração?

— Sim.

— Com humanos?

— Não.

— Vibração?

— Mais ou menos.

— Pressurização?

— Estamos vendo.

— Temperatura?

— Próxima sprint.

— Navegação?

— Cálculos parecem bons.

— Recuperação?

— Depois pensamos nisso.

QA olha para o documento.

STATUS:
READY FOR PRODUCTION

QA pede férias.


🌎 Por que lançar da Flórida?

Aqui existe uma coincidência histórica deliciosa.

No romance, após cálculos sobre o local apropriado para o disparo, a região escolhida fica na Flórida.

Décadas depois, a Flórida se tornaria central para o programa espacial americano, com Cape Canaveral/Kennedy Space Center.

Não significa que Verne “previu a NASA”.

Geografia e mecânica orbital fornecem boas razões para lançamentos em latitudes mais baixas e em determinadas direções.

Mas para um leitor moderno é impossível não sorrir.

Júlio Verne escreve sobre americanos lançando uma missão lunar da Flórida em 1865.

NASA:

“Anotado.”


🖥️ COBOL valida a janela lunar

Nosso programa recebe:

       IF WS-LAUNCH-WINDOW = 'OPEN'
           DISPLAY 'GO FOR LAUNCH'
       ELSE
           DISPLAY 'HOLD'
       END-IF.

Barbicane:

— GO?

Operações:

— GO.

Hardware:

— GO.

Tripulação:

— GO.

COBOL:

GO FOR LAUNCH

JES2:

MOONJOB STEP01 MAXCC=0000

Todos comemoram.

Exceto o velho programador.

Ele sabe:

MAXCC=0 não significa que a Lua está onde deveria estar.

Significa apenas que o programa terminou sem reclamar.

Existe uma diferença filosófica importante.


🚀 3... 2... 1...

Chega o momento.

Columbiad carregado.

Projétil preparado.

Barbicane.

Nicholl.

Michel Ardan.

Dentro da cápsula.

Operador:

SUBMIT MOONJOB

JES:

$HASP373 MOONJOB STARTED

COBOL:

CALCULATING TRAJECTORY...

CICS não participa.

Graças a Deus.

Db2 registra a missão.

INSERT INTO LUNAR_MISSION
VALUES ('MOON-001','LAUNCHED');

COMMIT.

Agora não tem volta.


💥 FIRE

Columbiad dispara.

BOOOOOOOOOOOOOOM

Toda a Flórida alternativa treme.

Operador olha SDSF.

JOB STATUS: ACTIVE

Michel Ardan:

— Estamos vivos?

Barbicane:

— Aparentemente.

Nicholl:

— Qual nossa trajetória?

Ardan:

— Pergunte ao computador.

Terminal:

MOONCOB:
TRAJECTORY STATUS = UNKNOWN

Ardan:

— Excelente.


🌌 O primeiro batch interplanetário

Agora nosso JOB está literalmente viajando.

Isso apresenta um problema arquitetural.

O mainframe está na Terra.

A cápsula está no espaço.

Rede:

LATENCY:
CONSIDERÁVEL

Programador moderno:

— Podemos colocar Kubernetes na cápsula.

Não.

Sente-se.


🛰️ Arquitetura distribuída de 1865

Precisamos de processamento local.

Imagine um pequeno subsistema COBOL embarcado.

MOONCOB-EDGE

Agora finalmente encontramos o verdadeiro significado de:

Edge Computing.

Edge mesmo.

A borda está a centenas de milhares de quilômetros.


🐛 E naturalmente aparece um bug

Nenhuma viagem Bellacosa Mainframe estaria completa sem isso.

No meio da trajetória:

ABEND S0C7

Barbicane:

— O que significa?

COBOLzeiro:

— Data Exception.

— Estamos entre a Terra e a Lua!

— Continua sendo Data Exception.

Investigação.

Campo:

05 WS-LUNAR-DISTANCE PIC 9(06).

Entrada:

384400KM

Ah.

Alguém colocou:

KM

num campo numérico.

Dois caracteres.

Missão lunar inteira ameaçada por:

K
M

COBOL permanece absolutamente indiferente à importância histórica da missão.

Dado inválido é dado inválido.


🔧 DISPLAY salva a humanidade

Sem debugger sofisticado:

DISPLAY 'DISTANCE=' WS-LUNAR-DISTANCE.

SYSOUT:

DISTANCE=384400KM

Barbicane:

— Encontramos!

Nicholl:

— Quem colocou KM?

Michel Ardan lentamente olha para o lado.

Silêncio.


🌕 O mistério da trajetória

A continuação da história, Autour de la Lune — Ao Redor da Lua, publicada primeiro em série e depois em volume em 1870, acompanha a viagem dos personagens.

E aqui Verne faz algo ainda mais interessante.

A aventura deixa de ser apenas:

CONSTRUIR CANHÃO

e passa a ser:

O QUE ACONTECE DEPOIS DO DEPLOY?

Essa é a pergunta que todo desenvolvedor conhece.

Antes:

“Precisamos colocar em produção.”

Depois:

“Colocamos.”

Silêncio.

“E agora?”

Agora começa a verdadeira aventura.


🔄 Produção é diferente de projeto

No laboratório tudo parece controlável.

Em produção aparecem:

GRAVIDADE
TEMPERATURA
TRAJETÓRIA
ERROS DE CÁLCULO
EVENTOS IMPREVISTOS
COMPORTAMENTO HUMANO

Software é igual.

Homologação:

10 REGISTROS

Produção:

480.000.000 REGISTROS

Homologação:

CLIENTE = JOAO

Produção:

CLIENTE = O'BRIEN DA SILVA & FILHOS 日本支店

E então descobrimos se nossa arquitetura realmente funciona.


🧭 Observabilidade lunar

Precisamos saber:

POSIÇÃO
VELOCIDADE
DIREÇÃO
OXIGÊNIO
TEMPERATURA
STATUS TRIPULAÇÃO

Nosso SMF espacial registra tudo.

SMF TYPE 999
LUNAR FLIGHT RECORD

RMF pergunta:

CPU UTILIZATION?

COBOLzeiro:

— Estamos indo para a Lua.

RMF:

— Não perguntei isso.


🧠 Júlio Verne e a engenharia da imaginação

Aqui está o ponto realmente bonito.

Júlio Verne não precisava acertar todos os detalhes técnicos.

E não acertou.

Seu canhão lunar possui problemas físicos gigantescos.

Mas isso é quase secundário.

A genialidade está em tratar uma ideia fantástica como se pudesse ser desmontada em problemas menores.

COMO CHEGAR À LUA?

vira:

QUAL DISTÂNCIA?

QUAL TRAJETÓRIA?

QUAL VELOCIDADE?

QUAL MATERIAL?

QUAL LOCAL?

QUAL CUSTO?

QUAL CÁPSULA?

QUEM VAI?

Essa maneira de pensar está no coração da engenharia.

E também da programação.


🦖 COBOL faz exatamente isso

Imagine um requisito:

“Calcule a folha de pagamento de 100.000 funcionários.”

Para uma pessoa, parece gigantesco.

COBOL transforma em:

READ EMPLOYEE
   ↓
VALIDATE
   ↓
CALCULATE
   ↓
WRITE RESULT
   ↓
REPEAT

Agora imagine:

“Vamos à Lua.”

Bellacosa COBOL responde:

READ LUNAR-PARAMETERS
   ↓
VALIDATE
   ↓
CALCULATE TRAJECTORY
   ↓
VALIDATE CREW
   ↓
LAUNCH
   ↓
MONITOR

Problemas extraordinários tornam-se sequências de problemas menores.


🤖 E se Júlio Verne tivesse IA?

Agora entramos em território perigoso.

Verne sentado diante de uma máquina.

Pergunta:

“Qual seria uma maneira plausível de enviar três homens à Lua?”

IA:

“Certamente não através de um canhão.”

Verne:

“Obrigado.”

Fecha a IA.

Escreve o livro mesmo assim.

Porque às vezes uma ideia tecnicamente absurda produz uma história extraordinária.


📊 O dashboard da missão

Na sala do Gun Club:

╔════════════════════════════════╗
║     LUNAR MISSION CONTROL      ║
╠════════════════════════════════╣
║ JOB.............. MOONJOB      ║
║ PROGRAM.......... MOONCOB      ║
║ VEHICLE........ COLUMBIAD      ║
║ DESTINATION......... MOON      ║
║ PASSENGERS............. 3      ║
║ STATUS.......... IN FLIGHT     ║
║ ABENDS................. 1      ║
║ COFFEE.............. LOW       ║
╚════════════════════════════════╝

O último indicador preocupa operações.


☕ PRIORITY 1

Ticket aberto:

INCIDENT:
INC-1865-384400

SEVERITY:
P1

DESCRIPTION:
THREE USERS CURRENTLY TRAVELLING
BETWEEN EARTH AND MOON.

BUSINESS IMPACT:
SIGNIFICANT.

Service Desk pergunta:

“Consegue enviar screenshot?”

Barbicane desliga o rádio.


🌍 O retorno

Sem entregar toda a aventura para quem ainda quiser ler Verne, existe uma característica fundamental nessas histórias:

o verdadeiro desafio nunca é simplesmente partir.

É sobreviver às consequências da partida.

Isso também vale para sistemas.

Criar aplicação:

20%

Mantê-la durante décadas:

80%

E talvez seja exatamente por isso que COBOL combina tão maravilhosamente com Júlio Verne.

Ambos pertencem a épocas que o presente frequentemente olha como antigas.

Ambos continuam sendo lidos.

Ambos sobrevivem às previsões de desaparecimento.

E ambos carregam uma estranha elegância de engenharia.


📚 1865 encontra 1959 encontra 2026

Nossa linha temporal fica maravilhosa:

1865
JÚLIO VERNE
DA TERRA À LUA
      ↓
1870
AO REDOR DA LUA
      ↓
1959
COBOL
      ↓
1969
APOLLO 11
      ↓
2026
IA + MAINFRAME + CLOUD

Em pouco mais de um século, aquilo que era literatura virou engenharia.

E aquilo que era tecnologia revolucionária virou infraestrutura invisível.

Talvez essa seja uma das coisas mais fascinantes da história tecnológica.

O impossível possui prazo de validade.


🚀 Ontem ficção, amanhã produção

Em 1865:

homens viajando à Lua.

Fantasia.

Em 1969:

homens caminhando na Lua.

História.

Em outra época:

computador entendendo linguagem próxima do inglês.

Absurdo.

Depois:

COBOL.

Hoje:

conversar em linguagem natural com uma inteligência artificial capaz de gerar programas.

Normal.

Portanto tenha cuidado quando alguém disser:

“Isso nunca vai acontecer.”

Júlio Verne pode estar ouvindo.


🦖 E o velho COBOL?

COBOL observa tudo.

Nasceu quando computadores ainda eram gigantes.

Viu o homem chegar à Lua.

Viu ARPANET.

Viu Unix.

Viu PCs.

Viu Internet.

Viu smartphones.

Viu cloud.

Viu blockchain.

Viu IA generativa.

E continua executando:

       PERFORM PROCESS-TRANSACTION
          UNTIL END-OF-FILE.

Talvez COBOL seja menos uma linguagem e mais uma testemunha histórica.


🌕 O último JOB

Imagino Júlio Verne entrando no Bellacosa Mainframe Center.

Ele observa um IBM Z moderno.

Pergunta:

— Quanto ele consegue calcular?

Respondemos:

— Bastante.

— Poderia calcular uma viagem à Lua?

— Facilmente.

Verne sorri.

— Então podemos usar meu canhão?

— Não.

— Por quê?

— A tripulação morreria instantaneamente.

Ele pensa.

— Podemos aumentar o tamanho?

Silêncio.

Agora entendemos de onde vieram os arquitetos corporativos.


☕ Epílogo — Da Terra ao Mainframe

Sala de operações.

03:14.

A cápsula finalmente retorna.

Sistema registra:

MISSION STATUS:
COMPLETED

Db2:

COMMIT COMPLETE.

JES2:

$HASP395 MOONJOB ENDED

Operador abre o spool.

IEF142I MOONJOB STEP01
STEP WAS EXECUTED

MAXCC=0000

Barbicane comemora.

Michel Ardan pede champanhe.

Nicholl pergunta pelos cálculos.

Júlio Verne fecha seu caderno.

E no fundo da sala o velho COBOLzeiro permanece desconfiado.

Ele olha novamente para o SYSOUT.

Confere os totais.

Confere a quantidade de passageiros.

PASSENGERS SENT...... 3
PASSENGERS RETURNED.. 3

Agora sim.

Ele pega a caneca.

Toma café.

E finalmente declara:

“Pode fechar o incidente.”

Porque viajar até a Lua é impressionante.

Voltar é extraordinário.

Mas fazer tudo isso sem estourar um S0C7...

meu amigo...

isso sim é ficção científica.

🌕🚀☕🦖

IDENTIFICATION DIVISION.
PROGRAM-ID. FROM-EARTH-TO-MOON.

PROCEDURE DIVISION.

    DISPLAY 'BON VOYAGE, MONSIEUR VERNE'.

    STOP RUN.

MAXCC=0000

Destination: Moon.

https://eljefemidnightlunch.blogspot.com/2026/08/o-spread-do-conhecimento-matrix-cobol-e.html

https://eljefemidnightlunch.blogspot.com/2026/08/quanto-custa-um-programador-salario.html

https://eljefemidnightlunch.blogspot.com/2026/08/delete-user-nao-apaga-memoria-o.html


Por que o COBOL continua a dominar o processamento de dados no mundo dos negócios? Os dados comerciais e financeiros precisam ser gerenciados usando tipos de dados decimais verdadeiros. Os sistemas de contabilidade devem estar corretos até o último dígito decimal e precisam reproduzir exatamente os resultados do cálculo manual; números convencionais de ponto flutuante levam a
 complexidades e erros.
Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...