☕ Um Café no Bellacosa Mainframe
Guilherme de Baskerville Entra no CPD — O Nome dos Pedreiros na Catedral de 80 Colunas
Ou: como cartões perfurados, datasets de 80 bytes, COBOL, PL/I, Assembler, Natural, XML, JSON, APIs e décadas de retrocompatibilidade transformaram programas legados em catedrais construídas por gerações de artesãos quase anônimos
Prólogo — O nome estava na pedra
Guilherme de Baskerville não começou examinando o código.
Isso surpreendeu o jovem programador.
Havia milhares de linhas COBOL diante deles, algumas tão antigas que ninguém presente no CPD sabia explicar completamente sua origem. O programa havia sobrevivido a reorganizações, mudanças de hardware, novos compiladores, novas moedas, novas legislações e incontáveis projetos de modernização.
— Mestre, não deveríamos procurar primeiro a PROCEDURE DIVISION?
Guilherme aproximou-se do terminal.
No alto do fonte havia algo aparentemente banal:
*****************************************************************
* J. PEREIRA
* 17/08/1983
* ALTERADA ROTINA DE FATURAMENTO
*****************************************************************
* M. SANTOS
* 04/02/1987
* INCLUIDO NOVO TIPO DE MOVIMENTO
*****************************************************************
* R. ALMEIDA
* 22/09/1994
* ADEQUACAO NOVA REGRA MONETARIA
*****************************************************************
Continuava.
Uma tela.
Duas.
Dez.
Dezenas de nomes.
Guilherme permaneceu em silêncio.
— O que procura? — perguntou o aprendiz.
— Não procuro — respondeu ele. — Estou prestando homenagem.
1. O programa legado possui uma memória
Quando encontramos um programa COBOL, PL/I, Natural ou Assembler com décadas de existência, frequentemente encontramos também algo que os manuais tratam simplesmente como change history.
Nome ou USER-ID.
Data.
Descrição da alteração.
Três ou quatro linhas cercadas por asteriscos.
*****************************************************************
* JCARLOS
* 14/06/1988
* CORRECAO CALCULO DE JUROS
*****************************************************************
Tecnicamente, aquilo é documentação.
Mas depois de quarenta anos transforma-se em algo diferente.
É memória institucional.
Talvez ninguém saiba mais quem foi JCARLOS.
Seu USER-ID provavelmente desapareceu há décadas.
O sistema de chamados usado naquela alteração talvez nem exista.
A documentação funcional pode ter sido perdida.
O departamento pode ter mudado de nome cinco vezes.
JCARLOS pode estar aposentado.
Pode morar do outro lado do mundo.
Pode ter falecido.
Mas alguma coisa permaneceu:
* JCARLOS
* 14/06/1988
* CORRECAO CALCULO DE JUROS
O programa lembra.
2. As assinaturas dos pedreiros
Nas antigas construções europeias podemos encontrar marcas deixadas por pedreiros e artesãos.
Isso oferece uma metáfora extraordinária para software legado.
Imagine uma catedral.
Um homem trabalha numa pedra.
Ele não projetou o edifício inteiro.
Não escolheu necessariamente onde ficaria a torre.
Não decidiu a doutrina representada nos vitrais.
Seu nome provavelmente nunca aparecerá num livro de história.
Mas aquela pedra passou pelas mãos dele.
Então deixa uma marca.
Séculos depois alguém a encontra.
No mainframe fazemos algo assustadoramente parecido:
*****************************************************************
* MFERREIRA
* 11/03/1991
* INCLUIDA VALIDACAO DO MOVIMENTO 07
*****************************************************************
Não significa:
Eu construí este sistema.
Significa:
Esta pedra passou pelas minhas mãos.
E isso muda completamente nossa maneira de olhar um fonte antigo.
3. Nenhum programador construiu a catedral
Um dos grandes erros quando falamos de software é imaginar um programa como criação de uma única pessoa.
Em sistemas corporativos longevos isso frequentemente não existe.
O programa pode ter nascido assim:
1981 JOAO
criação
Depois:
1984 MARIA
nova modalidade
Depois:
1987 CARLOS
novo processamento
Depois:
1994 ANA
mudança monetária
Depois:
1999 ROBERTO
adequação Y2K
E continua:
2004
2008
2012
2017
2020
2026
Quando chegamos ao programa em 2026, não estamos diante do trabalho de João.
Estamos diante de:
João + Maria + Carlos + Ana + Roberto + dezenas ou centenas de pessoas.
A criatura nasceu, cresceu e foi modificada.
Algumas partes desapareceram.
Outras sobreviveram.
Outras foram reconstruídas.
O programa tornou-se uma obra coletiva.
Exatamente como uma catedral que atravessou gerações.
4. Guilherme faz a primeira pergunta
O jovem programador apontou para uma rotina.
— Isto está horrível. Podemos remover?
Guilherme respondeu:
— Por que ela existe?
— Não sei.
— Então ainda não sabemos se podemos removê-la.
Essa talvez seja uma das regras mais importantes para quem começa a trabalhar com legado.
Código estranho não significa automaticamente código inútil.
Às vezes é lixo.
Às vezes é dívida técnica.
Às vezes é uma gambiarra histórica.
Mas às vezes é a última manifestação de uma regra de negócio que ninguém mais documentou.
Você encontra:
IF WS-TIPO = 7
PERFORM 8000-TRATA-ESPECIAL
END-IF
E pensa:
Que porcaria é essa?
Procura no cabeçalho:
*****************************************************************
* MROCHA
* 18/09/1989
* CORRECAO PROCESSAMENTO MOVIMENTO TIPO 7
*****************************************************************
Agora existe uma pista.
Não temos a resposta.
Temos uma evidência.
Guilherme de Baskerville certamente aprovaria a diferença.
5. O programa também possui camadas arqueológicas
Programas legados podem carregar algo ainda mais interessante.
Eles registram a própria evolução da informática.
Imagine um sistema criado no começo dos anos 1980.
Sua primeira versão pode ter sido essencialmente:
arquivo
|
COBOL
|
arquivo
Depois apareceu VSAM.
Depois Db2.
Depois CICS.
Depois MQ.
Então alguém precisou conectá-lo ao mundo distribuído.
Chegaram HTML e aplicações Web.
Depois XML.
SOAP.
Java.
JSON.
REST.
APIs.
Cloud.
Containers.
Eventos.
De repente temos:
MOBILE
|
HTTPS
|
API GATEWAY
|
JSON
|
REST
|
z/OS CONNECT
|
CICS
|
COBOL
/ | \
Db2 VSAM MQ
|
SISTEMA CLOUD
E em algum lugar no centro dessa arquitetura ainda existe:
PERFORM 300-CALCULAR-JUROS
escrito originalmente quando ninguém possuía um smartphone.
Frankenstein?
Talvez.
Mas existe uma interpretação mais interessante.
Estratigrafia computacional.
6. Frankenstein entra na catedral
Chamamos esses sistemas de Frankenstein porque encontramos tecnologias de épocas completamente diferentes costuradas umas às outras.
Assembler.
COBOL.
PL/I.
Natural.
JCL.
VSAM.
IMS.
Db2.
CICS.
MQ.
HTML.
XML.
SOAP.
Java.
JSON.
REST.
Cloud.
Mas uma catedral construída durante séculos também pode apresentar estilos diferentes.
Uma parte pertence a determinada época.
Outra foi reconstruída.
Uma capela apareceu posteriormente.
Um órgão foi substituído.
Um vitral é muito mais recente.
Uma restauração contemporânea introduziu outra marca.
O historiador não olha imediatamente para aquilo e diz:
Que arquitetura inconsistente!
Ele pergunta:
O que aconteceu aqui?
Essa é a diferença entre simplesmente programar e fazer arqueologia de software.
7. O astronauta na catedral
Existe um caso delicioso na Catedral Nova de Salamanca.
Durante uma restauração realizada em 1992, foi acrescentada à ornamentação uma figura de astronauta.
A catedral começou a ser construída séculos antes da exploração espacial.
Mas ali está ele.
Um astronauta na pedra.
Não é medieval.
Não tenta fingir que é.
Ele registra a época da intervenção.
E nossos programas fazem exatamente isso.
Imagine:
*****************************************************************
* JPEREIRA
* 1983
* CRIACAO
*****************************************************************
*****************************************************************
* MROCHA
* 1995
* INTEGRACAO DB2
*****************************************************************
*****************************************************************
* CSOUZA
* 2003
* INTERFACE XML
*****************************************************************
*****************************************************************
* AFERREIRA
* 2018
* RETORNO JSON
*****************************************************************
*****************************************************************
* VBELLACOSA
* 2026
* INTEGRACAO API REST
*****************************************************************
REST é o astronauta esculpido na catedral COBOL.
Ele não precisa destruir aquilo que veio antes.
Ele demonstra que a construção chegou viva até outra época.
8. O mistério das 80 colunas
Então Guilherme encontrou outra pista.
RECFM=FB
LRECL=80
O jovem programador riu.
— Outra velharia.
Guilherme olhou para ele.
— Oitenta por quê?
Silêncio.
É exatamente aqui que muita gente conhece apenas um terço da história.
O cartão perfurado IBM que se tornou um símbolo da computação possuía 80 colunas. A própria IBM registra que o cartão de 80 colunas foi introduzido em 1928 e tornou-se extremamente disseminado no processamento de informações.
Depois olhamos para o formato tradicional do fonte COBOL:
1 - 6 Sequence Number Area
7 Indicator Area
8 - 11 Area A
12 - 72 Area B
73 - 80 Comment/Identification Area
A documentação atual da IBM ainda descreve explicitamente uma linha fonte COBOL de 80 caracteres, dividida nessas áreas.
Isso significa que aquele número aparentemente arbitrário possui ancestralidade.
9. O cartão desapareceu; sua sombra permaneceu
Essa é uma das coisas mais fascinantes da computação.
Uma limitação física pode transformar-se em convenção.
A convenção transforma-se em padrão.
O padrão influencia software.
O software cria dependências.
As dependências exigem compatibilidade.
Décadas depois a causa física desapareceu, mas seus descendentes permanecem.
Podemos representar assim:
CARTAO PERFURADO
|
v
80 COLUNAS
|
v
FORMATO DE FONTE
|
v
FERRAMENTAS
|
v
DATASETS
|
v
COMPATIBILIDADE
|
v
2026
Inclusive documentação atual de ferramentas IBM continua reconhecendo áreas de numeração nas colunas 1–6 e 73–80 para fontes COBOL.
O cartão morreu.
A geometria sobreviveu.
10. O dataset de 80 bytes é uma rua romana
Imagine caminhar por uma cidade europeia.
Existe uma rua estranhamente curva.
Para um urbanista moderno, aquela curva parece irracional.
Até alguém explicar:
A estrada romana passava aqui.
A cidade desapareceu.
Impérios desapareceram.
Veículos mudaram.
Mas a rua continuou obedecendo a uma decisão tomada dois mil anos antes.
No mainframe:
LRECL=80
pode desempenhar papel semelhante.
Não significa que todo dataset de 80 bytes exista porque era cartão perfurado — seria uma simplificação histórica perigosa.
Significa que 80 tornou-se um número estruturalmente importante em um ecossistema profundamente influenciado pelo cartão e pelos formatos derivados dele.
Essa nuance importa.
O arqueólogo não inventa explicações.
Ele procura evidências.
11. A retrocompatibilidade é a argamassa
Agora chegamos à característica que permitiu que nossa catedral continuasse crescendo:
retrocompatibilidade.
A IBM fez algo extraordinariamente difícil ao longo da evolução do mainframe: preservar caminhos de continuidade enquanto hardware e software avançavam.
A própria IBM descreve os sistemas IBM Z atuais como descendentes diretos da linhagem System/360 e System/370 e afirma que muitas aplicações antigas puderam continuar funcionando em sistemas posteriores.
Isso não significa:
Qualquer programa de 1964 roda magicamente e sem qualquer consideração num z17 de 2026.
Seria falso.
Existem releases suportados, requisitos, PTFs, produtos, dependências, mudanças arquiteturais e processos de migração.
Por exemplo, a matriz atual do z17 estabelece explicitamente quais versões de z/OS são suportadas e quais exigem manutenção apropriada.
Retrocompatibilidade não é magia.
É engenharia.
12. A decisão caríssima de não demolir a cidade
Imagine se toda evolução tecnológica significasse:
NOVO HARDWARE
|
v
JOGUE FORA O SOFTWARE
|
v
REESCREVA TUDO
Para uma pequena aplicação talvez seja possível.
Agora imagine um banco.
Uma seguradora.
Uma companhia aérea.
Um governo.
Uma indústria.
Décadas de:
regras de negócio;
cálculos;
exceções;
layouts;
integrações;
arquivos;
programas;
transações;
conhecimento operacional.
A retrocompatibilidade protege algo muito maior que o executável.
Ela ajuda a preservar investimento e conhecimento acumulado.
A IBM inclusive descreve historicamente ciclos longos de hardware e caminhos de upgrade entre famílias como mecanismos de proteção do investimento e extensão da vida dos ativos.
Isso explica parte da longevidade dessas catedrais.
13. Manutenção também é construção
Existe uma injustiça profissional curiosa.
Quem cria algo novo é chamado de construtor.
Quem mantém algo antigo frequentemente é tratado como alguém que apenas “faz manutenção”.
Uma catedral demonstra o absurdo dessa distinção.
Sem manutenção:
o telhado infiltra.
A madeira apodrece.
A pedra racha.
O vitral quebra.
A torre fica instável.
Depois de séculos, não existe mais catedral.
Portanto, o restaurador também participa da construção da longevidade.
No software acontece o mesmo.
Quem resolveu o problema em 1991 ajudou o programa a chegar a 1992.
Quem resolveu Y2K ajudou-o a chegar a 2000.
Quem migrou o compilador ajudou-o a continuar.
Quem abriu uma API em 2026 talvez permita que a regra de negócio sobreviva por outra década.
Manter também é construir.
14. Modernização não precisa significar demolição
Aqui mora outra lição importante para o programador COBOL iniciante.
Modernizar não significa necessariamente:
DELETE COBOL.
Pode significar:
APLICACAO MODERNA
|
REST
|
JSON
|
INTEGRACAO
|
CICS
|
COBOL
|
Db2
Uma parte continua.
Outra é substituída.
Uma interface nasce.
Uma rotina é refatorada.
Uma dependência desaparece.
Outra surge.
A catedral continua em funcionamento durante a reforma.
Isso é muito diferente de demolir o edifício e prometer que construiremos outro antes do próximo fechamento contábil.
15. Mas não transforme história em religião
Guilherme levantaria o dedo aqui.
Respeitar o legado não significa venerar todo código antigo.
Existe código ruim.
Existe redundância.
Existe rotina morta.
Existe tecnologia cujo custo de manutenção deixou de fazer sentido.
Existe vulnerabilidade.
Existe dívida técnica.
Existe arquitetura que precisa desaparecer.
A arqueologia serve justamente para evitar dois extremos:
Tudo antigo é lixo.
e:
Tudo antigo deve ser preservado.
O restaurador competente pergunta:
O que isto sustenta?
Por que existe?
Quem depende disso?
Qual risco existe em removê-lo?
Existe alternativa melhor?
Como provar que o comportamento continuará correto?
Só então pega o martelo.
16. O comentário pode ser a última testemunha
Agora imagine isto:
IF WS-CODIGO = 47
MOVE 'S' TO WS-TRATAMENTO
END-IF
Ninguém sabe explicar.
Git?
O programa é décadas anterior à adoção de Git pela organização.
Ticket?
Desapareceu.
Documento?
Não encontrado.
Analista funcional?
Aposentou-se em 2007.
Então você sobe até o cabeçalho:
*****************************************************************
* ACOSTA
* 23/05/1993
* TRATAMENTO ESPECIAL CLIENTES CONVENIO 47
*****************************************************************
Não solucionamos o mistério.
Mas encontramos uma testemunha.
E talvez seja a última.
Por isso apagar comentários históricos indiscriminadamente durante uma “limpeza” pode equivaler a restaurar uma catedral lixando as inscrições das pedras.
17. O Frankenstein contém conhecimento
Voltemos ao nosso monstro:
Assembler
|
COBOL
|
CICS
|
Db2
|
MQ
|
XML
|
SOAP
|
Java
|
JSON
|
REST
|
Cloud
Parece absurdo.
Mas cada camada pode representar uma pergunta que a organização precisou responder:
Como processaremos isto?
Como armazenaremos isto?
Como permitiremos transações online?
Como integraremos sistemas?
Como falaremos com aplicações Web?
Como exporemos serviços?
Como integraremos cloud e mainframe?
O Frankenstein deixa então de ser apenas um acidente.
Transforma-se num mapa das necessidades empresariais através do tempo.
18. Easter egg — o sino toca RC=0000
Guilherme terminou sua investigação.
O JOB foi submetido.
O jovem programador observava SDSF.
Esperaram.
Então surgiu:
COND CODE 0000
— Mestre, terminou.
Guilherme sorriu.
— Não. Apenas tocou o sino.
— Sino?
— Toda catedral possui um.
E desde então o aprendiz nunca mais viu um RC=0000 da mesma maneira.
19. O dia em que a catedral fechar
Existe ainda uma cena que raramente imaginamos.
Algum dia um desses programas executará pela última vez.
Talvez depois de quarenta anos.
Talvez cinquenta.
O scheduler deixará de chamá-lo.
O dataset será arquivado.
O load module desaparecerá da biblioteca de produção.
Outro sistema assumirá sua função.
E finalmente teremos:
LAST EXECUTION
RC=0000
Nesse momento seria justo abrir o fonte uma última vez.
Subir até o início.
E ler.
*****************************************************************
* JOAO
* 1981
*****************************************************************
*****************************************************************
* MARIA
* 1985
*****************************************************************
*****************************************************************
* CARLOS
* 1992
*****************************************************************
...
*****************************************************************
* ULTIMO PROGRAMADOR
* 20XX
*****************************************************************
Talvez existam cem nomes.
Talvez duzentos.
Nenhum deles construiu sozinho aquela catedral.
Mas sem eles ela não teria chegado ao último processamento.
20. O programador iniciante precisa aprender a ler pedras
Quando você começar a trabalhar num programa legado, resista à tentação de ir imediatamente para:
PROCEDURE DIVISION.
Leia o cabeçalho.
Leia os comentários.
Observe datas.
Procure padrões.
Veja quando determinadas rotinas apareceram.
Pergunte por que existe determinado layout.
Investigue aquele LRECL=80.
Observe os copybooks.
Descubra quem produz os arquivos.
Descubra quem os consome.
Veja JCL.
Procure dependências CICS, Db2, MQ, VSAM.
Leia antes de julgar.
O primeiro dever do arqueólogo não é cavar.
É compreender o terreno.
Epílogo — O próximo nome
Antes de sair do CPD, Guilherme voltou ao início do programa.
Havia espaço para uma nova inscrição.
O jovem havia terminado sua primeira manutenção importante.
Digitou:
*****************************************************************
* NOVO PROGRAMADOR
* 07/09/2026
* ADEQUACAO DA INTERFACE PARA NOVO SERVICO
*****************************************************************
Ficou olhando.
Acima dele havia nomes de pessoas que trabalharam naquele programa antes mesmo de ele nascer.
— Estranho — disse. — Parece que meu nome não deveria estar junto dos deles.
Guilherme respondeu:
— Agora compreendeu.
— O quê?
— A catedral nunca foi deles.
O jovem esperou.
— Tampouco é sua.
E então veio a lição final:
Você apenas recebeu a chave por algum tempo.
Talvez seja essa a melhor definição de trabalhar com sistemas legados.
Não somos proprietários absolutos deles.
Somos seus guardiões temporários.
Recebemos programas construídos por pessoas que não conhecemos.
Encontramos suas assinaturas entre asteriscos.
Descobrimos decisões tomadas quando computadores, empresas e o próprio mundo eram diferentes.
Preservamos o que ainda possui valor.
Corrigimos aquilo que envelheceu.
Retiramos aquilo que se tornou perigoso.
E acrescentamos as tecnologias da nossa época.
O pedreiro deixou sua marca.
O escultor deixou sua criatura fantástica.
O restaurador deixou um astronauta.
O programador de 1983 deixou COBOL.
O de 2003 deixou XML.
O de 2026 deixou JSON e uma API.
Algum outro, no futuro, acrescentará algo cujo nome ainda nem conhecemos.
E talvez, antes de modificar o programa, ele suba algumas páginas e encontre:
*****************************************************************
* V. BELLACOSA
* 2026
* ...
*****************************************************************
Não saberá exatamente quem foi aquele homem.
Talvez procure.
Talvez não.
Mas durante alguns segundos saberá uma coisa:
outro artesão trabalhou naquela pedra antes dele.
E é isso que torna o legado tão diferente de simplesmente possuir código antigo.
O legado não é aquilo que ficou velho.
Legado é aquilo que alguém construiu bem o bastante para chegar até nós — e que nós cuidamos bem o bastante para entregar ao próximo.
Os cartões desapareceram.
As perfuradoras silenciaram.
Os terminais mudaram.
As máquinas foram substituídas.
As linguagens ganharam companheiras.
Vieram bancos relacionais, mensagens, Web, XML, JSON, APIs, cloud e IA.
Mas em algum dataset ainda encontramos:
RECFM=FB
LRECL=80
E em algum fonte ainda encontramos:
*****************************************************************
* NOME
* DATA
* O QUE FOI FEITO
*****************************************************************
São duas inscrições da mesma civilização.
Uma conta como construíamos.
A outra conta quem construiu.
E enquanto aquela catedral continuar processando transações, calculando valores, movimentando negócios e terminando suas madrugadas com:
RC=0000
o sino continuará tocando.
Para os usuários, será apenas mais um processamento concluído.
Para quem aprendeu a ler as pedras, porém, haverá ali algo muito maior:
cinquenta anos de engenheiros, analistas, operadores e programadores dizendo silenciosamente através do código:
