Bellacosa Mainframe e o desenvolvimento automatizado de software

☕ Um Café no Bellacosa Mainframe

💀 AINZ OOAL GOWN E A GRANDE TUMBA DO DESENVOLVIMENTO AUTOMATIZADO

CASE, AD/Cycle, Repository, DB2, CUA, CSP, geração de COBOL, testes, engenharia reversa, inteligência artificial — e o dia em que Momonga descobriu que a IBM tentou construir a Grande Tumba de Nazarick do desenvolvimento de software em 1989.

🎬 PRÓLOGO — MOMONGA ENCONTROU UM PROGRAMA COBOL

Momonga estava sentado no trono da Grande Tumba de Nazarick quando Albedo entrou apressadamente.

— Ainz-sama! Temos um problema.

Momonga permaneceu imóvel.

Naturalmente.

Um Overlord não demonstra preocupação diante dos subordinados.

— Explique.

— Encontramos um programa COBOL.

Silêncio.

Demiurge ajustou os óculos.

— Quantas linhas?

— Quarenta e sete mil.

Momonga pensou:

Isso não parece tão ruim.

Albedo continuou:

— Criado em 1978. Alterado por 36 programadores. Possui 19 COPYBOOKs, acessa sete arquivos VSAM, cinco tabelas DB2 e é chamado por três transações CICS.

Momonga começou a ficar preocupado.

— Documentação?

— Existe.

Momonga relaxou.

— De 1986.

Momonga congelou novamente.

— E quem conhece o sistema?

Albedo olhou para Demiurge.

Demiurge olhou para Cocytus.

Cocytus olhou para Shalltear.

Finalmente Sebas respondeu:

— Havia um senhor chamado Carlos.

— Excelente. Chamem Carlos.

— Ele se aposentou em 2004.

Momonga finalmente compreendeu.

Eles não tinham um problema de COBOL.

Tinham um problema de conhecimento.

E foi exatamente esse tipo de problema que, no final dos anos 1980, levou a IBM a embarcar em uma das aventuras mais ambiciosas da história da engenharia de software:

AD/Cycle.

Para entender o tamanho dessa ambição, precisamos voltar para uma época em que COBOL reinava absoluto, os terminais 3270 dominavam grandes empresas e a expressão "Inteligência Artificial Generativa" ainda parecia algo que Demiurge inventaria depois de beber três cafés.

🏰 CAPÍTULO 1 — O REINO NÃO ERA FEITO APENAS DE COBOL

Quando começamos a estudar mainframe, é fácil imaginar o desenvolvimento de sistemas antigos assim:

REQUISITO
   ↓
COBOL
   ↓
COMPILA
   ↓
EXECUTA

Naturalmente, nunca foi tão simples.

Uma aplicação empresarial podia envolver:

COBOL
  +
JCL
  +
VSAM
  +
DB2
  +
CICS
  +
BMS
  +
COPYBOOKS
  +
PROCEDURES
  +
DOCUMENTAÇÃO
  +
REGRAS DE NEGÓCIO

Imagine um sistema bancário.

Uma transação CICS recebe o número de uma conta.

O programa COBOL valida os dados.

Consulta DB2.

Talvez acesse VSAM.

Chama outro programa.

Atualiza informações.

Produz mensagens.

E eventualmente dispara processamento batch.

O programa COBOL é apenas uma peça.

A verdadeira aplicação é uma rede de dependências.

Ainz desenhou no quadro:

TELA BMS
   ↓
CICS
   ↓
PROGRAMA COBOL
   ├── COPYBOOK
   ├── DB2
   ├── VSAM
   └── OUTRO PROGRAMA
             ↓
             MQ

— Interessante — comentou Demiurge.

Ainz fingiu que já sabia tudo.

🧠 CAPÍTULO 2 — QUANDO O CÓDIGO VIRA A MEMÓRIA DA EMPRESA

Existe um fenômeno particularmente importante em sistemas antigos.

No começo temos:

NEGÓCIO
   ↓
REQUISITO
   ↓
DOCUMENTAÇÃO
   ↓
PROGRAMA

Depois de vinte anos:

DOCUMENTAÇÃO
    ≠
REALIDADE

E eventualmente:

PROGRAMA
    =
REALIDADE

A regra oficial pode dizer:

Clientes da categoria especial recebem determinado tratamento.

Mas onde está a definição verdadeira de "categoria especial"?

Talvez aqui:

IF WS-TIPO-CLIENTE = 'E'
   AND WS-SALDO > 50000
   AND WS-BLOQUEIO NOT = 'S'
       PERFORM 5000-TRATA-ESPECIAL
END-IF.

Agora Ainz faz uma pergunta terrível:

— Por que 50.000?

Silêncio em Nazarick.

O programa sabe o que fazer.

Mas talvez ninguém mais saiba por que faz.

Esse é um dos grandes problemas de sistemas legados.

O conhecimento empresarial acaba fossilizado no código.

🧙 CAPÍTULO 3 — SURGEM OS MAGOS DO CASE

Durante os anos 1980 ganhou força uma ideia:

CASE — Computer-Aided Software Engineering.

Em tradução aproximada:

Engenharia de Software Auxiliada por Computador.

Hoje isso parece óbvio.

Naturalmente usamos computadores para desenvolver programas.

Mas CASE significava algo muito mais ambicioso.

A ideia era usar ferramentas para ajudar a construir:

modelos;
diagramas;
especificações;
estruturas de dados;
documentação;
programas;
testes;
relacionamentos entre componentes.

Em vez de escrever tudo artesanalmente, tentaríamos transformar desenvolvimento de software em um processo mais industrial.

Ainz resumiu:

ANTES

IDEIA
 ↓
PROGRAMADOR
 ↓
COBOL

Com CASE:

NEGÓCIO
 ↓
MODELO
 ↓
ESPECIFICAÇÃO
 ↓
GERAÇÃO
 ↓
COBOL

Essa diferença é fundamental.

O COBOL deixa de ser necessariamente a única representação do conhecimento.

O modelo começa a ganhar importância.

🖥️ CAPÍTULO 4 — POR QUE OS PCS INVADIRAM A DUNGEON?

As primeiras ferramentas CASE encontraram terreno extremamente fértil nos computadores pessoais e workstations.

Por quê?

Principalmente porque diagramas gostam de ambientes gráficos.

Imagine desenhar:

CLIENTE ───────< PEDIDO >────── PRODUTO

usando apenas uma interface alfanumérica.

Agora imagine fazer isso usando:

mouse;
janelas;
ícones;
gráficos;
cores;
menus.

Muito melhor.

Os PCs também estavam ficando relativamente baratos e possuíam excelente interatividade local.

Enquanto um terminal dependia da comunicação com o host, uma workstation podia responder imediatamente às ações do usuário.

Para modelagem visual isso era fantástico.

Mas Nazarick rapidamente encontrou outro problema.

💾 CAPÍTULO 5 — O MODELO_FINAL_AGORA_VAI_3

Albedo tinha seu modelo.

Demiurge tinha outro.

Shalltear possuía uma terceira cópia.

Cocytus havia alterado a estrutura.

Sebas ainda utilizava a versão da semana passada.

Parabéns.

Nazarick acabava de inventar:

CLIENTE_FINAL.DAT

CLIENTE_FINAL2.DAT

CLIENTE_CORRETO.DAT

CLIENTE_CORRETO_NOVO.DAT

CLIENTE_CORRETO_NOVO_FINAL.DAT

CLIENTE_CORRETO_NOVO_FINAL_AGORA_VAI.DAT

Esse é o problema de manter conhecimento corporativo distribuído em arquivos locais.

Conforme as ferramentas CASE cresciam, seus modelos ficavam maiores.

E havia algo ainda pior:

compartilhamento.

Cada ferramenta podia possuir seu próprio formato.

Uma conhecia o modelo de dados.

Outra conhecia processos.

Outra gerava programas.

Outra fazia documentação.

Mas elas não necessariamente compartilhavam uma representação comum.

A IBM percebeu que o problema não seria resolvido apenas criando mais uma ferramenta CASE.

Era necessário criar um ecossistema.

💀 CAPÍTULO 6 — NASCE O AD/CYCLE

Em 1989 a IBM anunciou sua grande estratégia:

AD/Cycle.

Não pense no AD/Cycle simplesmente como:

"um CASE da IBM".

Essa interpretação é pequena demais.

Imagine algo parecido com uma enorme arquitetura destinada a cobrir o ciclo de vida do desenvolvimento.

Algo como:

PLANEJAMENTO
     ↓
ANÁLISE
     ↓
MODELAGEM
     ↓
DESIGN
     ↓
CONSTRUÇÃO
     ↓
TESTE
     ↓
IMPLANTAÇÃO
     ↓
MANUTENÇÃO

Tudo isso compartilhando informações.

Era quase a tentativa de construir a Grande Tumba de Nazarick do desenvolvimento empresarial.

Cada andar tinha ferramentas diferentes.

Mas todos deveriam pertencer ao mesmo reino.

🗄️ CAPÍTULO 7 — NO CENTRO DA TUMBA ESTAVA O REPOSITORY

A peça conceitualmente mais importante era o:

Repository.

Imagine um gigantesco catálogo corporativo.

Ele poderia conhecer:

PROGRAMAS
COPYBOOKS
TABELAS
ARQUIVOS
TELAS
ENTIDADES
PROCESSOS
REGRAS
MODELOS
RELACIONAMENTOS

Não basta armazenar objetos.

Precisamos armazenar os relacionamentos entre eles.

Por exemplo:

PROGRAMA PGMA001
       │
       ├── USA COPYBOOK CLIENTE
       │
       ├── ACESSA DB2 TBCLIENTE
       │
       ├── LÊ VSAM CADCLI
       │
       └── CHAMA PGMA002

Agora imagine alterarmos:

COPYBOOK CLIENTE

O Repository poderia ajudar a responder:

Quais programas serão afetados?

Isso é análise de impacto.

Para um programador COBOL iniciante, esse conceito é importantíssimo.

Antes de alterar um campo, você não deveria perguntar apenas:

"Onde ele está?"

Pergunte:

"Quem depende dele?"

🔍 CAPÍTULO 8 — O COPYBOOK MALDITO DE NAZARICK

Suponha:

       01 CLIENTE-REG.
          05 CLIENTE-ID       PIC 9(08).
          05 CLIENTE-NOME     PIC X(40).
          05 CLIENTE-STATUS   PIC X(01).

Alguém decide:

CLIENTE-STATUS

precisa passar de:

PIC X(01)

para:

PIC X(02)

Parece simples.

Mas esse COPYBOOK pode estar sendo utilizado por 80 programas.

Talvez existam arquivos contendo registros com layout antigo.

Talvez mensagens MQ usem a mesma estrutura.

Talvez outro sistema espere exatamente aquele comprimento.

Então:

ALTERAR 1 BYTE

pode produzir:

80 PROGRAMAS
+
12 JOBS
+
5 ARQUIVOS
+
3 INTERFACES
+
1 INCIDENTE ÀS 03:17

Sim.

03:17.

O horário oficial em que aquele programa que "ninguém usa mais" resolve provar que continua vivo.

Easter egg desbloqueado. ☕

🐘 CAPÍTULO 9 — POR QUE DB2?

A IBM utilizou DB2 como base importante para o Repository.

Isso fazia sentido.

O problema envolvia armazenar grandes quantidades de metadados e relacionamentos.

Pense:

PROGRAM
COPYBOOK
TABLE
TRANSACTION
SCREEN
ENTITY
RELATIONSHIP
PROCESS

Agora acrescente:

PROGRAM USES COPYBOOK
PROGRAM ACCESSES TABLE
TRANSACTION EXECUTES PROGRAM
SCREEN BELONGS TO TRANSACTION
ENTITY MAPS TO TABLE

O Repository não seria simplesmente:

PASTA COM DOCUMENTOS

Ele deveria representar conhecimento estruturado.

Hoje poderíamos olhar para essa ideia e enxergar parentesco conceitual com:

METADATA CATALOG
DEPENDENCY GRAPH
KNOWLEDGE GRAPH

E isso se torna especialmente interessante quando chegamos à inteligência artificial.

Mas ainda não chegamos lá.

Ainz pediu paciência.

Temos mais andares na dungeon.

🤝 CAPÍTULO 10 — IBM PERCEBE QUE NÃO SABE TUDO

Uma das decisões mais interessantes da IBM foi reconhecer que outros fabricantes possuíam ferramentas CASE muito avançadas.

Em vez de começar absolutamente tudo do zero, criou alianças.

Entre os nomes associados ao ecossistema estavam:

Index Technology;
KnowledgeWare;
Bachman;
SYNON.

Ferramentas diferentes atacavam partes diferentes do desenvolvimento.

A filosofia era aproximadamente:

FERRAMENTA A ──┐
FERRAMENTA B ──┤
FERRAMENTA C ──┼── REPOSITORY
FERRAMENTA D ──┘

A IBM estabeleceu requisitos para integração.

Entre eles estavam padronização de interface, integração ao Repository e internacionalização.

Isso também revela uma mudança importante na IBM.

Em vez de:

IBM FAZ TUDO

começamos a enxergar:

IBM
 +
PARCEIROS
 +
PLATAFORMA
 +
PADRÕES

Algo extremamente comum no mercado atual.

🪟 CAPÍTULO 11 — CUA: QUANDO AINZ DESCOBRIU O MOUSE

Um requisito era utilizar o padrão:

CUA — Common User Access.

Para entender sua importância, não pense apenas em:

"tela gráfica bonita".

Pense em consistência.

Imagine que todos os programas utilizem conceitos semelhantes para:

abrir
salvar
cancelar
copiar
colar
ajuda
menus
atalhos

Você aprende uma aplicação.

Parte desse conhecimento funciona na próxima.

Hoje isso parece natural porque vivemos cercados de convenções de interface.

Mas alguém precisou criar essas convenções.

CUA fazia parte dessa busca.

O objetivo era diminuir o esforço necessário para aprender cada nova aplicação.

📋 CAPÍTULO 12 — ADPS E A BUROCRACIA DE NAZARICK

Outro componente interessante era o Application Development Project Support.

A lógica começava definindo coisas como:

QUAL É A METODOLOGIA?

QUAIS TAREFAS EXISTEM?

EM QUAL ORDEM?

QUEM APROVA?

Depois o sistema ajudava a controlar o processo.

Imagine:

REQUISITO
   ↓
ANÁLISE
   ↓
DESIGN
   ↓
CODIFICAÇÃO
   ↓
TESTE
   ↓
APROVAÇÃO
   ↓
PRODUÇÃO

Agora imagine Demiurge tentando pular TESTE.

O sistema responde:

ACCESS DENIED

Demiurge:

— Mas Ainz-sama autorizaria.

Sistema:

APPROVAL NOT FOUND

Albedo:

— Podemos regularizar amanhã.

Sistema:

NO.

Aqui existe uma ideia extremamente moderna:

transformar processo em algo executável.

Hoje encontramos isso em:

pipelines;
workflows;
CI/CD;
approval gates;
RBAC;
DevSecOps;
Policy as Code.

⚠️ CAPÍTULO 13 — AUTOMATIZAR UM PROCESSO RUIM CONTINUA PRODUZINDO UM PROCESSO RUIM

Existe uma armadilha.

Suponha que sua empresa possua um processo horrível:

15 FORMULÁRIOS
      ↓
8 APROVAÇÕES
      ↓
4 PLANILHAS
      ↓
3 REUNIÕES

Você automatiza tudo.

Parabéns.

Agora possui:

uma burocracia extremamente rápida.

Automação não substitui pensamento.

Antes de automatizar pergunte:

Essa etapa é necessária?
Quem realmente precisa aprovar?
Que risco estamos controlando?
Existe duplicação?
O processo representa a realidade?

Essa lição vale tanto para AD/Cycle em 1990 quanto para DevOps e agentes de IA em 2026.

🏢 CAPÍTULO 14 — DEVELOPMATE: MODELE O REINO ANTES DE PROGRAMÁ-LO

DevelopMate atacava uma área particularmente interessante:

modelagem do negócio.

Antes de pensar:

PRECISAMOS DE UM PROGRAMA COBOL

pergunte:

QUAL PROCESSO DE NEGÓCIO EXISTE?

Depois:

QUAIS INFORMAÇÕES ELE UTILIZA?

Depois:

QUAIS REGRAS EXISTEM?

Só então:

QUAL SISTEMA PRECISAMOS?

Isso produz uma hierarquia muito mais saudável:

NEGÓCIO
   ↓
PROCESSO
   ↓
REGRA
   ↓
INFORMAÇÃO
   ↓
SISTEMA
   ↓
PROGRAMA

O erro comum é começar pelo último item.

⚙️ CAPÍTULO 15 — CSP E A PRIMEIRA MAGIA DE GERAÇÃO DE COBOL

A IBM também apostava em geração de código.

Um dos caminhos envolvia CSP.

A ideia fundamental:

ESPECIFICAÇÃO
      ↓
GERADOR
      ↓
COBOL

Parece familiar?

Troque algumas palavras:

PROMPT
   ↓
IA GENERATIVA
   ↓
COBOL

Naturalmente, as tecnologias são radicalmente diferentes.

Mas existe um parentesco filosófico.

Ambas tentam aumentar o nível de abstração.

Em vez de dizer exatamente:

COMO FAZER

tentamos descrever cada vez mais:

O QUE QUEREMOS

e deixamos ferramentas produzirem parte do "como".

🤖 CAPÍTULO 16 — ESPERE... O DOCUMENTO DE 1990 JÁ FALAVA EM IA?

Sim.

E isso merece atenção.

Naquela época, inteligência artificial normalmente significava coisas como:

EXPERT SYSTEMS
KNOWLEDGE BASES
RULES
INFERENCE ENGINES

Um sistema poderia trabalhar com regras:

IF CLIENTE = GOLD
AND RISCO = LOW
THEN RECOMENDAR CREDITO

Não estamos falando de LLMs.

Não existia ChatGPT escondido num PS/2 esperando alguém descobrir.

Mas o objetivo era fascinantemente semelhante:

utilizar conhecimento armazenado para auxiliar tarefas intelectuais.

Hoje temos:

COBOL
+
JCL
+
COPYBOOK
+
DOCUMENTAÇÃO
+
LOGS
+
TICKETS
        ↓
       LLM
        ↓
EXPLICAÇÃO
DOCUMENTAÇÃO
TESTES
CÓDIGO
ANÁLISE

A tecnologia mudou.

A ambição permaneceu.

🧪 CAPÍTULO 17 — SATT E A BOLINHA MÁGICA

Outra ferramenta fascinante era SATT:

Software Analysis Test Tool.

Ela ajudava a observar quais partes de um programa COBOL ou PL/I eram executadas durante um teste.

Considere:

IF SALDO > 1000
   PERFORM 1000-CLIENTE-ESPECIAL
ELSE
   PERFORM 2000-CLIENTE-NORMAL
END-IF.

Seu teste usa:

SALDO = 5000

Então executamos:

1000-CLIENTE-ESPECIAL

Mas nunca:

2000-CLIENTE-NORMAL

A ferramenta poderia revelar essa ausência.

Hoje chamamos isso de conceitos relacionados a:

Code Coverage.

E podemos perguntar:

QUANTAS LINHAS FORAM EXECUTADAS?

QUANTOS BRANCHES?

QUAIS CAMINHOS NÃO FORAM TESTADOS?

🔴 CAPÍTULO 18 — UMA BOLINHA PERCORRENDO O COBOL

A interface visual era especialmente interessante.

Imagine a tela dividida.

De um lado:

IF CLIENTE-ATIVO
   PERFORM PROCESSA
ELSE
   PERFORM REJEITA
END-IF

Do outro:

        START
          ●
          ↓
    CLIENTE ATIVO?
       /       \
     SIM       NÃO
      ●
      ↓
   PROCESSA

Durante a execução uma indicação visual mostrava o caminho percorrido.

Hoje isso pode parecer banal.

Para alguém acostumado a dumps, listings e ferramentas textuais, era praticamente assistir ao programa ganhar vida.

🧪 CAPÍTULO 19 — WITT E A ARTE DE NÃO DIGITAR TUDO NOVAMENTE

WITT guardava dados utilizados em testes de transações.

Parece uma funcionalidade pequena.

Não é.

Imagine testar uma transação que exige preencher:

CLIENTE
CONTA
AGÊNCIA
TIPO
DATA
VALOR
MOEDA
PRODUTO
CANAL

Você encontra um bug.

Corrige.

Compila.

Volta para testar.

E precisa digitar tudo novamente.

Depois novamente.

Guardar os dados do teste permite reprodutibilidade.

E reprodutibilidade é um dos fundamentos de automação de testes.

⏪ CAPÍTULO 20 — BACHMAN E A MAGIA PROIBIDA DA ENGENHARIA REVERSA

Agora chegamos ao andar que fez Momonga levantar do trono.

Engenharia reversa.

A ambição era fantástica:

COBOL ANTIGO
     ↓
ANÁLISE
     ↓
MODELO
     ↓
REESTRUTURAÇÃO
     ↓
NOVO COBOL

Imagine pegar:

       GO TO 1000-PROCESSA.
...
1000-PROCESSA.
       ...
       GO TO 8000-SAIDA.

e reconstruir uma representação lógica da aplicação.

Depois trabalhar sobre o modelo.

Depois gerar código melhor estruturado.

Esse é praticamente o sonho eterno da modernização de legado.

🧟 CAPÍTULO 21 — MAS O CÓDIGO NÃO CONTA TODA A HISTÓRIA

Aqui aparece o problema fundamental.

Podemos descobrir:

PROGRAMA A
CHAMA
PROGRAMA B

Podemos descobrir:

PROGRAMA B
ACESSA
TABELA C

Mas descobrir:

"Por que essa regra existe?"

é muito mais difícil.

Imagine:

IF WS-DIA = 15
   ADD 1 TO WS-PRAZO
END-IF.

Por quê?

Regra fiscal?

Acordo antigo?

Bug transformado em feature?

Convenção bancária?

Exigência regulatória?

Carlos pediu em 1987?

O código descreve comportamento.

Nem sempre preserva intenção.

Por isso engenharia reversa completa continua sendo difícil até hoje.

🧬 CAPÍTULO 22 — AD/CYCLE ERA DEVOPS?

Não.

Seria historicamente incorreto dizer isso.

Mas existem parentescos conceituais fascinantes.

Podemos fazer uma ponte didática:

AD/CYCLE              MUNDO MODERNO

Repository      →     Metadata / Git / Catalog
ADPS            →     Workflow / CI/CD
Methodology     →     SDLC
Authorization   →     RBAC
Approval        →     Quality Gates
SATT            →     Code Coverage
WITT            →     Test Automation
CASE            →     IDE / Modeling
CSP             →     Code Generation
Reverse Eng.    →     Application Discovery
AI              →     Generative AI

Não são equivalências perfeitas.

São parentes conceituais.

Todos tentam responder:

Como controlar e automatizar o ciclo de construção de software?

💥 CAPÍTULO 23 — POR QUE A GRANDE TUMBA NÃO DOMINOU O MUNDO?

A ambição também era o problema.

Para obter todo o potencial, uma organização precisava lidar com diversas tecnologias, ferramentas, integrações, metodologia, infraestrutura e treinamento.

Não era simplesmente:

INSTALL AD-CYCLE

e clicar:

NEXT
NEXT
NEXT
FINISH

Era transformação organizacional.

E transformação organizacional custa:

DINHEIRO
+
TEMPO
+
TREINAMENTO
+
MUDANÇA CULTURAL
+
INTEGRAÇÃO

Uma ferramenta pode ser instalada em algumas horas.

Uma metodologia pode levar anos para ser absorvida.

🎯 CAPÍTULO 24 — FEZ UMA LEITURA MUITO INTELIGENTE

O documento histórico que iniciou nossa aventura possui uma conclusão especialmente interessante.

Ele não dizia simplesmente:

"Vamos comprar tudo."

A análise era aproximadamente:

AD/CYCLE COMPLETO?

Talvez não.

Mas também:

AUTOMAÇÃO DO DESENVOLVIMENTO?

PRECISAMOS OBSERVAR.

E principalmente:

REPOSITORY?

ISSO PODE VIRAR IMPORTANTE.

Essa é uma excelente lição para qualquer profissional de tecnologia.

Nunca confunda:

PRODUTO

com:

CONCEITO.

Produtos desaparecem.

Conceitos sobrevivem.

🧠 CAPÍTULO 25 — O REPOSITORY RETORNA COMO KNOWLEDGE GRAPH

Agora saltamos para 2026.

Imagine armazenarmos relações como:

PROGRAM
  ↓ USES
COPYBOOK

PROGRAM
  ↓ ACCESSES
DB2 TABLE

CICS TRANSACTION
  ↓ EXECUTES
PROGRAM

PROGRAM
  ↓ SENDS
MQ MESSAGE

Temos praticamente um:

grafo de conhecimento da aplicação.

Agora coloque IA sobre esse grafo.

Pergunte:

"O que acontece se eu alterar CLIENTE-STATUS?"

Em vez de simplesmente ler um programa, a IA poderia navegar:

CLIENTE-STATUS
      ↓
COPYBOOK
      ↓
83 PROGRAMAS
      ↓
17 TRANSAÇÕES
      ↓
6 TABELAS
      ↓
4 INTERFACES
      ↓
2 APIs

Agora começamos a perceber o tamanho da ideia.

🤖 CAPÍTULO 26 — LLM SABE COBOL, MAS NÃO SABE O SEU COBOL

Esta talvez seja a lição mais importante para quem estuda IA aplicada ao mainframe.

Uma IA pode conhecer sintaxe COBOL.

Pode explicar:

PERFORM UNTIL

Pode compreender:

REDEFINES

Pode explicar:

OCCURS DEPENDING ON

Mas existe uma enorme diferença entre:

conhecer COBOL

conhecer o sistema COBOL da sua empresa.

Para isso precisamos fornecer contexto:

PROGRAMAS
COPYBOOKS
JCL
DDL
BMS
VSAM
DOCUMENTAÇÃO
TICKETS
HISTÓRICO
TESTES
DEPENDÊNCIAS
REGRAS

Então poderíamos perguntar:

"Por que PGMA123 existe?"

"Quem chama esse programa?"

"Qual tabela ele atualiza?"

"Quais jobs dependem desse arquivo?"

"Existe teste para esta condição?"

"Qual regra empresarial implementa este parágrafo?"

Isso é muito mais poderoso do que simplesmente gerar código.

🧙 CAPÍTULO 27 — O VERDADEIRO TESOURO NÃO É GERAR COBOL

Todo mundo fica impressionado quando uma IA escreve:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLO.

Bonito.

Mas isso é a parte fácil.

A parte valiosa é perguntar:

QUAL PROGRAMA PRECISO ALTERAR?

POR QUÊ?

QUEM DEPENDE DELE?

QUAL O RISCO?

QUE TESTES PRECISO EXECUTAR?

QUAL REGRA DE NEGÓCIO ESTÁ ENVOLVIDA?

A verdadeira modernização não começa com:

gerar código.

Começa com:

compreender sistemas.

🧭 CAPÍTULO 28 — PASSO A PASSO PARA O PADAWAN COBOL

Se você está começando agora, faça este exercício.

Escolha um programa COBOL.

Passo 1 — descubra as entradas

Procure:

LINKAGE SECTION
COPY
ACCEPT
READ
EXEC CICS RECEIVE

Pergunte:

De onde chegam os dados?

Passo 2 — descubra as saídas

Procure:

WRITE
REWRITE
EXEC SQL
EXEC CICS SEND
CALL

Pergunte:

Para onde vão?

Passo 3 — encontre dependências

Liste:

COPYBOOKS
PROGRAMAS CHAMADOS
TABELAS
ARQUIVOS
TRANSAÇÕES

Passo 4 — identifique regras

Procure:

IF
EVALUATE
COMPUTE
PERFORM

Não olhe apenas a sintaxe.

Pergunte:

Qual decisão empresarial está sendo tomada aqui?

Passo 5 — desenhe o mapa

Mesmo que seja:

CICS
 ↓
PGMA001
 ↓
COPY CLIENTE
 ↓
DB2 CLIENTE
 ↓
PGMA002

Você começou a construir seu pequeno Repository mental.

🧰 CAPÍTULO 29 — DICAS DE AINZ PARA NÃO MORRER NA PRIMEIRA DUNGEON

Primeira:

Nunca altere um COPYBOOK sem procurar consumidores.

Segunda:

Nunca confunda programa com aplicação.

Terceira:

Documente o motivo da alteração, não apenas aquilo que alterou.

Ruim:

* ALTERADO IF

Melhor:

* 2026-09-23 - USERID - INC12345
* REGRA ALTERADA PARA ATENDER NOVA
* CLASSIFICACAO DE CLIENTES.

Daqui a vinte anos alguém agradecerá.

Talvez esse alguém seja você.

Quarta:

Teste caminhos alternativos.

Não teste apenas aquilo que deveria funcionar.

Teste:

ZERO
VAZIO
LIMITE
INVÁLIDO
DUPLICADO
INEXISTENTE

Quinta:

Antes de modernizar, compreenda.

Reescrever um sistema incompreendido apenas produz:

BUG ANTIGO
      ↓
TECNOLOGIA NOVA

🏺 CAPÍTULO 30 — CURIOSIDADE: SOFTWARE TAMBÉM É ARQUEOLOGIA

Quando encontramos um programa COBOL de 1985 ainda executando, estamos diante de algo extraordinário.

Ele não é apenas código.

É uma cápsula do tempo.

Dentro dele podem existir decisões tomadas durante:

inflação
mudanças monetárias
fusões empresariais
novas legislações
mudanças tributárias
novos produtos
novas tecnologias

Cada alteração deixou uma camada.

Por isso analisar legado lembra arqueologia.

Você encontra:

IF ANO < 1994

e pensa:

— Por quê?

Parabéns.

Você encontrou um artefato.

Não remova antes de descobrir a civilização que o construiu.

☕ EPÍLOGO — AINZ DESCOBRE QUE 1989 AINDA NÃO TERMINOU

Albedo finalmente perguntou:

— Ainz-sama, então AD/Cycle fracassou?

Momonga permaneceu alguns segundos em silêncio.

Precisava parecer sábio.

Finalmente respondeu:

— Produtos desaparecem. Problemas permanecem.

Demiurge arregalou os olhos.

— SASUGA AINZ-SAMA!

Momonga continuou.

AD/Cycle não se tornou o sistema universal de desenvolvimento imaginado para os anos 1990.

Mas observe as ideias:

REPOSITORY
AUTOMAÇÃO
WORKFLOW
MODELOS
TESTES
GERAÇÃO DE CÓDIGO
ENGENHARIA REVERSA
ANÁLISE DE IMPACTO
INTELIGÊNCIA ARTIFICIAL
PADRONIZAÇÃO

Agora observe o vocabulário moderno:

DEVSECOPS
CI/CD
PLATFORM ENGINEERING
KNOWLEDGE GRAPH
GENERATIVE AI
AI AGENTS
CODE GENERATION
APPLICATION DISCOVERY
AUTOMATED TESTING
DEPENDENCY ANALYSIS

Não são simplesmente as mesmas tecnologias com nomes novos.

Houve décadas de evolução técnica entre elas.

Mas estamos perseguindo uma ambição surpreendentemente parecida:

capturar o conhecimento necessário para construir e manter sistemas e permitir que máquinas auxiliem cada vez mais esse processo.

Em 1989, o sonho era colocar a inteligência da organização em modelos e em um Repository compartilhado.

Em 2026 queremos oferecer aos modelos de inteligência artificial contexto suficiente para compreender nossas aplicações.

A diferença é enorme.

Mas existe uma ponte histórica fascinante entre os dois mundos.

E talvez o maior erro seja imaginar que o futuro do desenvolvimento COBOL consiste apenas em pedir:

"IA, gere um programa."

Isso é magia de primeiro nível.

A verdadeira magia de Nazarick seria perguntar:

"Ainz, explique todo o sistema."

E receber:

ESTA TRANSAÇÃO CICS
        ↓
CHAMA ESTES PROGRAMAS
        ↓
QUE USAM ESTES COPYBOOKS
        ↓
ACESSAM ESTAS TABELAS
        ↓
PUBLICAM ESTAS MENSAGENS
        ↓
IMPLEMENTAM ESTAS REGRAS
        ↓
POSSUEM ESTES TESTES
        ↓
E SE VOCÊ ALTERAR ESTE CAMPO
        ↓
ESTES 37 COMPONENTES
SERÃO IMPACTADOS

Nesse momento teríamos finalmente conectado algumas das grandes ideias do passado ao poder das ferramentas atuais.

O programador COBOL iniciante então perceberia uma coisa fundamental:

COBOL nunca foi apenas escrever código.

É compreender sistemas.

É compreender dados.

É compreender dependências.

É compreender processos.

E, principalmente, é preservar conhecimento.

Porque um programa pode sobreviver ao programador.

Uma aplicação pode sobreviver ao projeto.

Uma regra pode sobreviver à documentação.

Uma plataforma pode sobreviver ao produto que tentou implementá-la.

E uma ideia concebida em 1989 pode reaparecer décadas depois usando outro nome.

Ainz levantou-se do trono.

Olhou para Albedo.

— Encontraram aquele Carlos?

— Sim, Ainz-sama.

— Excelente!

— Mas ele disse que não lembra mais por que CLIENTE-STATUS possui um byte.

Silêncio.

Momonga sentou-se novamente.

No console, às 03:17, apareceu:

IEC161I

Demiurge sorriu.

— Devemos investigar?

Ainz respondeu imediatamente:

— Primeiro procurem a documentação.

Albedo:

— De que ano?

— 1986.

E assim começou outra madrugada no Bellacosa Mainframe.

☕💀

Porque o verdadeiro Overlord não teme código legado.

Ele teme código legado sem documentação.

Translate

segunda-feira, 1 de julho de 2002