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