Bellacosa Mainframe e a ia encontrou o mainframe cobol

☕ Um Café no Bellacosa Mainframe

Uncharted Entra no CPD — A IA Encontrou o COBOL, Mas o Tesouro Estava Escondido no JCL

Ou: por que Nathan Drake consegue ler o mapa, mas ainda precisa descobrir a passagem secreta, o CALL dinâmico, a PROC esquecida e o scheduler que alguém alterou em 2009

Existe uma cena clássica em qualquer aventura de Uncharted.

Nathan Drake encontra um mapa.

O papel está amarelado.

Há símbolos misteriosos.

Uma anotação feita há duzentos anos aponta para algum lugar impossível.

Sully olha para aquilo e provavelmente pensa:

— Garoto, isso vai dar problema.

Nathan responde alguma coisa otimista, pega a mochila, recarrega a arma e vai atrás do tesouro.

O erro seria imaginar que, porque ele encontrou o mapa, a aventura acabou.

Na realidade, foi exatamente naquele momento que ela começou.

Bem-vindo à modernização de aplicações mainframe com Inteligência Artificial.

Hoje temos ferramentas fantásticas capazes de pegar milhões de linhas COBOL, PL/I, Assembler, JCL e copybooks e fazer coisas que vinte anos atrás exigiriam equipes inteiras.

Elas podem:

• explicar programas;

• encontrar referências;

• montar árvores de chamadas;

• gerar documentação;

• sugerir regras de negócio;

• criar testes;

• traduzir código;

• localizar dependências;

• produzir diagramas;

• auxiliar numa migração.

Um programador COBOL iniciante olha para isso e pensa:

“Pronto. Coloca o repositório na IA e ela descobre o sistema.”

Calma, jovem explorador.

Você encontrou o mapa do tesouro.

Não encontrou necessariamente o tesouro.

E talvez nem saiba ainda onde estão as cobras.

---

Prólogo — Nathan Drake encontrou o COBOL

Imagine que chegamos a uma empresa fictícia chamada Bellacosa International Treasure Bank.

O banco possui:

18.000 programas COBOL
9.400 copybooks
26.000 JCLs
4.000 PROCs
centenas de tabelas Db2
milhares de datasets
CICS
IMS
MQ
VSAM
Assembler
REXX
sort cards
scheduler

Além disso, algumas pessoas que criaram partes importantes do sistema já se aposentaram.

Outras trabalham ali há trinta anos e sabem coisas que nunca foram documentadas.

A diretoria anuncia:

“Vamos modernizar.”

A palavra ecoa pelo CPD.

Modernizar.

Maravilhosa palavra.

Pode significar desde:

compilar COBOL com versão mais nova

até:

migrar metade da empresa para cloud
e descobrir seis meses depois
que alguém esqueceu um arquivo EBCDIC.

Para ajudar, chega a Inteligência Artificial.

Jogamos nela:

PAY001.CBL

A IA analisa o programa.

Encontra:

CALL 'PAY002'
CALL 'PAY003'

EXEC SQL
   SELECT ...
END-EXEC

Ela produz:

PAY001
 ├── PAY002
 ├── PAY003
 └── DB2

Excelente.

Nathan Drake encontrou o primeiro pedaço do mapa.

Só que existe isto:

CALL WS-PROGRAM USING WS-AREA

Sully imediatamente pergunta:

“E quem diabos é WS-PROGRAM?”

Ótima pergunta.

---

1. O primeiro templo — programa não é aplicação

Essa é provavelmente uma das lições mais importantes para quem começa em mainframe.

Quando estudamos programação, pensamos:

programa = aplicação

Isso pode funcionar num pequeno exercício.

Você tem:

CALCULA.CBL

O programa lê valores, calcula alguma coisa e termina.

Mas aplicações corporativas que nasceram há décadas são outra criatura.

Um sistema real pode ser:

COBOL
+
COPYBOOK
+
JCL
+
PROC
+
DB2
+
VSAM
+
CICS
+
IMS
+
MQ
+
Scheduler
+
Control Tables
+
Assembler
+
REXX
+
Configuração
+
Dados
+
Operação
+
Conhecimento humano

O COBOL é importante.

Mas ele é apenas uma sala do templo.

E algumas das passagens secretas ficam fora dela.

---

2. O mapa encontrado pela IA

Vamos usar um programa simples.

IDENTIFICATION DIVISION.
PROGRAM-ID. PAY001.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-PROGRAM PIC X(8).

PROCEDURE DIVISION.

    MOVE 'PAY002' TO WS-PROGRAM

    CALL WS-PROGRAM

    GOBACK.

Um analisador consegue identificar:

CALL variável

Mas o destino pode depender de lógica anterior.

Agora imagine:

EXEC SQL
   SELECT PROGRAM_NAME
     INTO :WS-PROGRAM
     FROM CONTROL_TABLE
    WHERE OPERATION = :WS-OPERATION
END-EXEC

CALL WS-PROGRAM.

O programa chamado não está literalmente escrito no comando CALL.

Pode ser:

PAY002
PAY003
PAY099
PAY777

dependendo do conteúdo da tabela.

A IA pode perceber que existe uma chamada dinâmica.

Mas sem conhecer os valores possíveis daquela tabela, ela não consegue afirmar com certeza qual programa será chamado.

Portanto:

SOURCE CODE

diz:

“Existe uma chamada dinâmica.”

Enquanto:

RUNTIME

pode dizer:

“Nas últimas 48 horas, PAY002 foi chamado 800 mil vezes e PAY777 foi chamado três vezes.”

Essas três execuções podem ser exatamente as três que movem cinquenta milhões de reais.

Agora você entende por que quantidade de execução e importância de negócio não são a mesma coisa.

---

3. Curiosidade Bellacosa — o código que quase nunca executa pode ser o mais importante

Um iniciante normalmente pensa:

“Se roda pouco, deve ser pouco importante.”

Não necessariamente.

Imagine:

ROTINA-A

executa 4 milhões de vezes por dia.

Ela formata um nome.

Agora:

ROTINA-B

executa uma vez por ano.

Ela fecha o exercício fiscal.

Qual você prefere quebrar?

Pois é.

Modernização exige algo que Uncharted ensina muito bem:

Nem toda porta escondida guarda o mesmo perigo.

---

4. O segundo templo — COPYBOOK não é só Ctrl+C corporativo

No começo, copybook parece simples.

COPY CLIENTE.

E dentro:

01 CLIENTE.
   05 CODIGO PIC 9(08).
   05 TIPO   PIC X.
   05 SALDO  PIC S9(11)V99 COMP-3.

Você pensa:

“É apenas uma estrutura compartilhada.”

Sim.

E não.

Esse layout pode ser usado por:

programa COBOL online
batch noturno
Easytrieve
SORT
MQ
arquivo VSAM
interface externa
warehouse
Java
Python
ETL

Agora alguém altera:

01 CLIENTE.
   05 CODIGO PIC 9(08).
   05 PAIS   PIC X(02).
   05 TIPO   PIC X.
   05 SALDO  PIC S9(11)V99 COMP-3.

Do ponto de vista da aplicação que recompilou:

Tudo certo.

Mas talvez exista um programa distante que não tenha copybook algum.

Ele simplesmente sabe:

byte 9 = tipo do cliente

Você inseriu dois bytes antes desse campo.

Agora:

byte 9

não significa mais a mesma coisa.

Parabéns.

Você acabou de descobrir uma armadilha do templo.

---

5. Nathan Drake encontra REDEFINES e quase cai num abismo

Agora chegamos numa das maravilhas do COBOL:

01 WS-REGISTRO.
   05 WS-TIPO PIC X.
   05 WS-DADOS PIC X(100).

01 WS-CLIENTE REDEFINES WS-REGISTRO.
   05 ...

01 WS-CONTA REDEFINES WS-REGISTRO.
   05 ...

O mesmo conjunto de bytes pode ser interpretado de formas diferentes.

Para um analisador estático:

layout CLIENTE existe
layout CONTA existe

Perfeito.

Mas qual deles é usado em produção?

Talvez:

CLIENTE = 99,98%
CONTA   = 0,02%

O problema é que aqueles 0,02% podem aparecer somente no encerramento anual.

Você migra o sistema em maio.

Testa maio.

Testa junho.

Testa julho.

Tudo verde.

Chega dezembro.

O velho sistema olha para você e diz:

SOC7

Feliz Natal.

---

6. Terceiro templo — JCL é parte da aplicação

Aqui muitos programadores iniciantes cometem um erro.

Eles estudam COBOL e enxergam JCL como:

“A coisa estranha que executa meu programa.”

Só que JCL pode mudar drasticamente o comportamento real.

Considere:

//STEP10 EXEC PGM=PAY001
//INPUT  DD DSN=PROD.PAY.INPUT

Você conclui:

PAY001 recebe PROD.PAY.INPUT

Agora descubra que o job verdadeiro chama uma PROC:

//STEP10 EXEC PROC=PAYPROC

e depois faz override:

//STEP10.RUN.INPUT DD DSN=PROD.SPECIAL.PAY.INPUT

Pronto.

A informação originalmente lida na PROC não corresponde necessariamente ao dataset utilizado naquela execução.

É exatamente como encontrar um mapa do templo mostrando uma porta.

Só que alguém construiu uma passagem lateral em 2004.

E nunca atualizou o mapa.

---

7. PROC — a passagem secreta atrás da estante

Cataloged procedures existem para reutilizar JCL.

Ótimo conceito.

Mas imagine décadas de alterações.

Temos:

JOB
 ↓
PROC
 ↓
PROC
 ↓
override
 ↓
symbolic parameter
 ↓
dataset

A IA precisa resolver isso tudo.

Porque:

JCL que você vê

não é necessariamente:

JCL efetivamente executado

Antes de modernizar um fluxo batch, tente produzir a versão resolvida do JCL.

Ou seja:

qual PGM?
qual PARM?
qual dataset?
qual DISP?
qual STEPLIB?
qual PROC?
qual override?

Essa é uma excelente prática de discovery.

---

8. Quarto templo — scheduler contém lógica de negócio

A primeira vez que alguém percebe isso geralmente fica olhando para a tela alguns segundos.

Imagine:

JOBB

executa somente se:

JOBA terminou OK
AND hoje é último dia útil
AND FILE-X chegou
AND país != feriado
AND JOBZ não está rodando

Onde está essa lógica?

Talvez não esteja no COBOL.

Talvez nem no JCL.

Está no:

Control-M
IBM Workload Scheduler
CA-7
ESP
ou outro scheduler

Portanto:

scheduler configuration

é parte da aplicação.

Se durante uma migração você copiar:

COBOL
JCL
DB2

mas não reproduzir corretamente a orquestração, você poderá ter um sistema funcional que executa na hora errada.

E em processamento financeiro, “certo na hora errada” costuma significar simplesmente:

ERRADO

---

9. Quinto templo — control table é código disfarçado de dado

Aqui Nathan Drake acende a tocha.

Imagine esta tabela:

OPERATION   PROGRAM
---------------------
PAYMENT     PAY001
REFUND      REF010
REVERSAL    REV777

E o COBOL:

SELECT PROGRAM
INTO WS-PROGRAM
FROM CONTROL_TABLE
WHERE OPERATION = WS-OPERATION.

CALL WS-PROGRAM.

Agora alguém executa:

UPDATE CONTROL_TABLE
SET PROGRAM = 'PAY900'
WHERE OPERATION = 'PAYMENT';

Pergunta:

O source COBOL mudou?

Não.

Houve novo compile?

Não.

Houve link-edit?

Não.

O comportamento da aplicação mudou?

SIM.

Logo:

Alguns dados são, na prática, configuração executável.

Essa é uma das razões pelas quais repositório de source não representa obrigatoriamente todo o sistema.

---

10. Sexto templo — compiler options também importam

Agora entramos numa área que muitos iniciantes ignoram.

Você possui:

PAY001.CBL

e imagina que o source define tudo.

Mas programas COBOL são compilados.

E opções do compilador podem alterar comportamento.

Entre elas encontramos temas relacionados a:

aritmética
truncamento
debug
otimização
chamadas
compatibilidade
representação
runtime checking

Ou seja:

mesmo source
+
configuração diferente
=
possível comportamento diferente

É por isso que discovery sério deve coletar:

source
compiler listing
compiler options
binder information
load module information

A IA não deveria simplesmente olhar um .CBL solitário e proclamar:

“Eu compreendi tudo.”

Nathan Drake olhando uma inscrição na parede não sabe automaticamente qual mecanismo ela aciona.

Ele precisa olhar o chão também.

---

11. Sétimo templo — Db2 Package: o mapa que lembra como chegar ao dado

Com SQL estático em COBOL, existe outra peça importante.

Você escreve:

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CONTA
    WHERE CONTA_ID = :WS-CONTA
END-EXEC

Mas o ecossistema de execução envolve também elementos de Db2 como:

DBRM
BIND
PACKAGE
PLAN
access path

Dependendo do ambiente e da arquitetura.

Para modernization discovery, você quer saber:

qual programa usa qual package?
qual package referencia quais objetos?
qual versão?
qual bind?

Porque a arquitetura real não termina no EXEC SQL.

---

12. Oitavo templo — runtime é o chão onde as pegadas aparecem

Chegamos ao conceito mais poderoso do artigo original.

Static analysis diz:

“Isso pode acontecer.”

Runtime diz:

“Isso aconteceu.”

É uma diferença brutal.

Considere:

PGMA pode chamar:
PGMB
PGMC
PGMD

Static analysis apresenta três caminhos.

Mas produção mostra:

PGMB = 9.000.000 execuções
PGMC = 37 execuções
PGMD = 0 execuções

Agora temos evidência operacional.

Podemos olhar:

SMF
logs
CICS
Db2 traces
IMS
MQ
scheduler history
dataset activity
job history
APM

Cada plataforma terá fontes diferentes.

O objetivo é confrontar:

POSSIBLE

contra:

OBSERVED

Isso é ouro para discovery.

---

13. Mas cuidado: “não observado” não significa “não existe”

Essa é outra armadilha.

Suponha:

PGMD = 0 execuções em 90 dias

Podemos aposentá-lo?

Talvez.

Mas pergunte:

ele roda mensalmente?
trimestralmente?
anualmente?
só em desastre?
somente em fechamento?
somente em contingência?

Um programa DR pode não executar durante cinco anos e continuar essencial.

Portanto:

NOT OBSERVED

não significa automaticamente:

DEAD CODE

Isso precisa virar hipótese.

---

14. A grande tabela do explorador: D, R, H e U

Uma técnica extremamente útil seria classificar cada descoberta.

Use:

[D] Deterministic
[R] Runtime observed
[H] Hypothesis
[U] Unknown

Por exemplo:

[D] PAY001 contém CALL PAY002.

[D] JOBPAY executa PAY001.

[R] PAY001 executou 8.231 vezes em 30 dias.

[R] PAY002 foi carregado 7.994 vezes.

[H] Parte das demais execuções seleciona PAY010 dinamicamente.

[U] 237 targets ainda não resolvidos.

Isso muda completamente a conversa.

Em vez de dizer:

“Mapeamos a aplicação.”

Você diz:

“Temos 91% das relações críticas confirmadas, 7% observadas apenas em runtime e quatro dependências de alto impacto ainda não resolvidas.”

Muito mais profissional.

---

15. Curiosidade — 100% de linhas analisadas pode significar quase nada

Imagine o relatório:

18 milhões de linhas analisadas
100% repository coverage

Executivo feliz.

PowerPoint verde.

Mas escondido numa nota:

11 dynamic CALLs unresolved
3 vendor modules sem source
2 interfaces externas desconhecidas
1 scheduler condition não documentada

Então temos:

100% CODE SCANNED

mas não:

100% SYSTEM UNDERSTOOD

Por isso o objetivo de discovery não deveria ser obsessão por “completude”.

Deveria ser redução controlada de incerteza.

---

16. O conceito Bellacosa de UNKNOWN WITH CONSEQUENCE

Nem todo desconhecido merece a mesma energia.

Imagine:

Unknown	Contexto	Risco
CALL desconhecido	relatório interno	baixo
arquivo desconhecido	processo mensal	médio
consumidor desconhecido	pagamento	crítico
módulo sem source	settlement	crítico

Agora discovery passa a priorizar risco.

Podemos usar uma heurística:

RISCO =
PROBABILIDADE
× IMPACTO
× INCERTEZA

Não precisa ser ciência matemática perfeita.

É uma ferramenta de decisão.

Exemplo:

Dynamic CALL X

Probabilidade: 5
Impacto:       5
Incerteza:     4

Risco = 100

Compare com:

Relatório antigo

Probabilidade: 1
Impacto:       1
Incerteza:     4

Risco = 4

Você sabe onde colocar Nathan Drake primeiro.

---

17. Nono templo — conhecimento tribal

Agora chegamos ao inimigo final.

Pergunte:

“Por que JOBABC não pode rodar antes do JOBXYZ?”

Resposta:

“Porque dá problema.”

Pergunte:

“Onde está documentado?”

Resposta:

“Não está.”

“Scheduler?”

“Também não.”

“JCL?”

“Não.”

“Então como vocês sabem?”

Resposta:

“O Cláudio sabe.”

Cláudio está na empresa desde 1987.

Cláudio sabe que:

quando último dia útil cai numa sexta-feira
e segunda é feriado
JOBABC precisa esperar arquivo X

Onde está essa regra?

Na cabeça do Cláudio.

Isso se chama:

institutional knowledge

ou, informalmente:

conhecimento tribal.

É patrimônio operacional.

E é também um risco enorme.

---

18. Aqui IA pode virar Indiana Jones... quer dizer, Nathan Drake corporativo

Entrevistas com SMEs podem ser transcritas.

A IA pode extrair afirmações.

Exemplo:

Cláudio diz:

“PAY099 só roda quando há reversão manual.”

Transformamos isso em:

[H] PAY099 executa apenas em reversões manuais.

Depois verificamos:

runtime history
scheduler
transactions
JCL
Db2

Se confirmar:

[D/R] CONFIRMED

Se não:

CONTRADICTION

Isso é muito mais poderoso do que simplesmente produzir atas de reunião.

Estamos transformando memória humana em hipóteses verificáveis.

---

19. O grande perigo — IA verificando IA

Agora chegamos à armadilha mais moderna de todas.

Imagine:

IF STATUS = 'A'

A IA interpreta:

A = ACTIVE

Só que no sistema:

A = AWAITING SETTLEMENT

A IA gera documentação:

STATUS A means ACTIVE

Depois cria teste:

Given an active account
STATUS = A

Depois gera Java.

Depois executa seus próprios testes.

Resultado:

PASS
PASS
PASS
PASS

A diretoria comemora.

Só existe um pequeno problema.

Tudo está errado.

Mas está coerentemente errado.

Esse é um dos maiores perigos da geração automática.

---

20. Regra Bellacosa: quem escreve a prova não pode sozinho corrigir a própria prova

Ou, tecnicamente:

Verification must exist outside the generation loop.

Se IA:

interpreta
gera
testa
valida

tudo usando a mesma hipótese inicial, ela pode perpetuar o erro.

Precisamos de fontes externas de verdade.

Exemplos:

compiler output
runtime traces
immutable specs
regression suites
parallel run
production reconciliation
known datasets
SME validation

Ou seja:

AI OUTPUT
     ↓
INDEPENDENT EVIDENCE

e não:

AI OUTPUT
     ↓
AI CHECKS AI
     ↓
PARABÉNS

---

21. O décimo templo — parallel run

Uma técnica poderosíssima em modernização é executar:

sistema antigo

e:

sistema novo

em paralelo.

Mesmas entradas.

Depois comparar:

saídas
saldos
transações
contagens
erros
tempos
efeitos

Exemplo:

LEGACY:
10.000.000 transações
resultado financeiro X

NEW:
10.000.000 transações
resultado financeiro X

Excelente.

Agora imagine:

NEW divergiu em 17 transações

Essas 17 são lixo?

Ou são justamente:

clientes judiciais
contas especiais
operações antigas
casos de fechamento

A reconciliação encontra justamente as pequenas exceções que documentação gerada pode esconder.

---

22. O verdadeiro mapa: Evidence Graph

Se eu estivesse montando uma arquitetura de discovery moderna, criaria um grafo.

Nós:

PROGRAM
COPYBOOK
JOB
PROC
STEP
DATASET
TABLE
PACKAGE
TRANSACTION
QUEUE
API
SCHEDULER
CONTROL TABLE
LOAD MODULE

Relacionamentos:

CALLS
READS
WRITES
EXECUTES
USES
BINDS
TRIGGERS
CONSUMES
PRODUCES
DEPENDS ON

Mas não basta guardar a relação.

Precisamos guardar a evidência.

Exemplo:

PAY001
   |
   | CALLS
   |
PAY002

Metadata:

source: compiler listing
type: deterministic
confidence: 100%

Outro:

PAY001
   |
   | CALLS
   |
PAY099

Metadata:

source: runtime trace
observed: 37 times
type: runtime

Outro:

PAY001
   |
   | POSSIBLY CALLS
   |
PAY777

Metadata:

source: LLM inference
type: hypothesis
confidence: 63%

Agora sim temos algo valioso.

Não apenas:

knowledge graph.

Mas:

evidence-backed knowledge graph.

---

23. Passo a passo para um iniciante fazer discovery

Vamos transformar tudo isso numa sequência prática.

Passo 1 — escolha uma capacidade pequena

Não comece:

“Vamos entender o banco inteiro.”

Comece:

“Vamos entender consulta de saldo.”

Ou:

“Vamos entender pagamento.”

---

Passo 2 — encontre os pontos de entrada

Pode ser:

CICS transaction
JCL
API
MQ
IMS transaction
batch

Pergunte:

como essa capacidade começa?

---

Passo 3 — descubra os programas

Mapeie:

programas chamados
CALLs estáticos
CALLs dinâmicos
subprogramas
assembler
utilities

---

Passo 4 — expanda COPYBOOKs

Não analise apenas:

COPY ACCOUNT.

Resolva o conteúdo real.

Observe:

offset
length
REDEFINES
OCCURS
COMP
COMP-3

---

Passo 5 — resolva JCL e PROC

Descubra o job efetivo.

Inclua:

symbolics
overrides
datasets
STEPLIB
PARM
COND

---

Passo 6 — analise acesso a dados

Procure:

Db2
VSAM
QSAM
IMS
MQ
files

---

Passo 7 — busque configuração externa

Inclua:

scheduler
control tables
CICS definitions
IMS definitions
Db2 package info
MQ configuration

---

Passo 8 — olhe produção

Pergunte:

o que realmente executou?

Use evidência disponível.

---

Passo 9 — registre unknowns

Exemplo:

U-001 Dynamic CALL unresolved
U-002 Consumer of dataset unknown
U-003 Vendor module source unavailable

---

Passo 10 — classifique risco

Algo como:

LOW
MEDIUM
HIGH
CRITICAL

---

Passo 11 — use IA para correlação

Agora sim.

Entregue os fatos.

Peça:

explique
correlacione
documente
sugira testes
aponte inconsistências

A IA passa a trabalhar sobre evidência.

---

Passo 12 — valide fora da IA

Use:

compiler
runtime
SME
tests
parallel run

---

24. Easter egg — “Sic Parvis Magna”

Fãs de Uncharted reconhecerão imediatamente:

Sic Parvis Magna

“Grandeza a partir de pequenos começos.”

É praticamente uma metodologia perfeita para modernização.

Não tente modernizar:

30 milhões de linhas

de uma vez.

Comece:

1 capability
1 fluxo
1 domínio
1 slice

Descubra.

Valide.

Execute.

Aprenda.

Atualize o mapa.

Depois avance.

small slice
↓
evidence
↓
deployment
↓
observation
↓
new evidence
↓
next slice

Sic Parvis Magna, versão z/OS.

---

25. Discovery não deve terminar numa enciclopédia

Outro erro comum:

Passamos nove meses criando:

4.000 páginas de documentação

Todos ficam felizes.

Seis meses depois:

20% já está desatualizado.

Discovery não existe para produzir a Wikipédia definitiva do mainframe.

Existe para permitir decisão.

Exemplo:

RETAIN
EXPOSE
REPLACE
RETIRE
REIMAGINE

---

26. RETAIN — não mexa no templo que está funcionando

Às vezes você descobre:

COBOL
estável
rápido
barato
confiável
bem testado

Então por que reescrever?

Modernização pode significar:

novo compiler
CI/CD
APIs
testes
observabilidade
Git
DevOps

mantendo o core.

---

27. EXPOSE — abra uma porta moderna

Imagine:

CICS → COBOL

que funciona há vinte anos.

Talvez a necessidade moderna seja:

Mobile
   ↓
REST API
   ↓
CICS
   ↓
COBOL

Você não precisa necessariamente destruir o castelo.

Talvez baste construir uma ponte.

---

28. REPLACE — troque o que realmente perdeu sentido

Existem partes que podem ser substituídas.

Exemplo:

relatório antigo
utility obsoleto
interface redundante

Mas a decisão deve nascer da descoberta.

Não do preconceito:

“É COBOL, portanto precisa morrer.”

---

29. RETIRE — finalmente aposente o fantasma

Discovery pode encontrar programas que:

não executam
não são chamados
não têm consumidores
não possuem valor

Ótimo candidato a aposentadoria.

Mas lembre:

not observed
≠
not needed

Cheque ciclos anuais, contingência e requisitos regulatórios.

---

30. REIMAGINE — não traduza o passado linha por linha

Aqui mora uma das maiores confusões de modernization.

Você pega:

COBOL

e traduz para:

Java

Parabéns.

Agora você pode ter:

um sistema COBOL escrito em Java.

As mesmas:

dependências
batch windows
control tables
arquivos
acoplamentos
processos

continuam lá.

Modernizar não é necessariamente trocar linguagem.

Reimaginar significa perguntar:

“Como essa capacidade deveria existir hoje?”

Isso pode gerar uma arquitetura completamente diferente.

---

31. Migration e modernization são parentes, não gêmeos

Migrar:

A → B

Modernizar:

A → algo melhor

Às vezes coincidem.

Às vezes não.

Você pode migrar sem modernizar.

Pode modernizar sem migrar.

E pode realizar uma migração tão ruim que termina com um sistema mais complexo do que antes.

Nathan Drake também sabe disso.

Nem todo caminho novo leva ao tesouro.

Alguns levam ao precipício.

---

32. Métricas que não impressionariam Sully

Evite celebrar apenas:

20 milhões de linhas escaneadas
50 milhões de tokens
900 diagramas gerados
10 mil páginas documentadas

Essas são métricas de atividade.

Pergunte:

Quantos riscos críticos fechamos?

Quantas decisões foram tomadas?

Quantas dependências foram confirmadas?

Quantos unknowns de alto impacto restam?

Quantas mudanças chegaram com segurança à produção?

Qual KPI melhorou?

Isso é resultado.

---

33. A aventura completa

No final, nosso mapa fica assim:

SOURCE
   ↓
STATIC ANALYSIS
   ↓
CONFIGURATION
   ↓
RUNTIME
   ↓
EVIDENCE
   ↓
AI
   ↓
INTERPRETATION
   ↓
HYPOTHESES
   ↓
VALIDATION
   ↓
RISK
   ↓
DECISION

E finalmente:

RETAIN
EXPOSE
REPLACE
RETIRE
REIMAGINE

Essa é uma metodologia muito mais saudável do que:

COBOL
 ↓
LLM
 ↓
Java
 ↓
PRODUCTION

Se alguém propuser exatamente esse último diagrama numa reunião, recomendo verificar se Sully já está preparando o avião para fugir.

---

Epílogo — o tesouro nunca esteve apenas no COBOL

O programador iniciante chega ao mainframe e pensa:

“Preciso aprender COBOL.”

Correto.

Depois descobre:

JCL

Depois:

Db2

Depois:

VSAM

Depois:

CICS

Depois:

IMS

Depois:

MQ

Depois:

scheduler

Depois:

RACF

Depois vê control tables, compiler options, PROCs, SMF, load libraries, binder, copybooks e pessoas que conhecem regras de 1993.

Nesse momento ele entende:

Mainframe não é uma linguagem. É um ecossistema.

E aplicações antigas são frequentemente organismos históricos.

Foram construídas em camadas.

Uma mudança em 1988.

Outra em 1994.

Um workaround em 1999.

Euro em 2002.

Regulatório em 2008.

Novo canal em 2013.

API em 2018.

Cloud em 2024.

IA em 2026.

Cada geração deixou alguma coisa no templo.

O trabalho da Inteligência Artificial não é fingir que conhece todas as câmaras escondidas.

É ajudar você a encontrá-las.

Ela pode ler inscrições numa velocidade impossível para uma equipe humana.

Pode conectar copybooks.

Pode explicar COBOL.

Pode comparar milhares de programas.

Pode gerar hipóteses.

Pode localizar padrões.

Pode transformar documentação ruim em algo utilizável.

Pode auxiliar na geração de testes.

Pode tornar discovery dramaticamente mais rápido.

Mas ainda precisamos perguntar:

De onde veio essa afirmação?

É fato?

É runtime?

É hipótese?

É unknown?

Qual o risco se estiver errada?

Essa é a diferença entre demonstração bonita e engenharia de modernização.

Portanto, quando alguém disser:

“Nossa IA analisou 100% do COBOL.”

Sorria.

Tome um gole de café.

Olhe para o horizonte como Nathan Drake olhando para mais uma cidade perdida.

E pergunte:

“Ótimo. Agora me mostre os CALLs dinâmicos, os overrides de JCL, as tabelas de controle, o histórico do scheduler, os consumidores dos arquivos, os packages Db2, o runtime e aquilo que ainda não sabemos.”

Se a sala ficar silenciosa...

parabéns.

Você acabou de encontrar a entrada da próxima ruína.

☕

E, lá no fundo do CPD, provavelmente existe uma placa antiga dizendo:

SIC PARVIS MAGNA

Grandeza a partir de pequenos começos.

Ou, em português de mainframe:

Não tente mapear o planeta inteiro antes de descobrir quem está alterando o DDNAME do STEP030.