 |
| Bellacosa Mainframe e a documentação de software |
☕ Um Café no Bellacosa Mainframe
📚 MYNE E A BIBLIOTECA PERDIDA DO MAINFRAME — QUANDO O COBOL DESCOBRIU QUE CÓDIGO SEM DOCUMENTAÇÃO TAMBÉM PODE VIRAR UM LIVRO ESQUECIDO
Documentação, COBOL, auditoria, Configuration Management, Git, runbooks, dívida documental, conhecimento institucional, IA generativa — e o dia em que Myne descobriu que o maior risco do sistema não estava no programa, mas na cabeça do único programador que sabia como ele funcionava.
🎬 PRÓLOGO — MYNE ENCONTROU UM PROGRAMA COBOL
Myne abriu os olhos.
Não estava em Ehrenfest.
Não havia templo.
Não havia Ferdinand.
Não havia sequer uma biblioteca.
Diante dela existia uma tela preta com letras verdes.
READY
DSN SYSTEM(DB2P)
IKJ56700A ENTER USERID -
— Onde estão os livros?
Um velho programador apontou para milhares de datasets.
HLQ.PROD.COBOL
HLQ.PROD.COPYLIB
HLQ.PROD.JCL
HLQ.PROD.PROCLIB
HLQ.PROD.PARMLIB
Myne arregalou os olhos.
— Então... isso tudo é conhecimento?
— Mais ou menos.
— Onde está a documentação?
Silêncio.
O programador olhou para o teto.
Outro fingiu que estava analisando um dump.
Um terceiro tomou café.
Finalmente alguém respondeu:
— Pergunta para o Carlos.
Myne imediatamente percebeu que havia encontrado um problema muito mais grave do que a falta de livros.
A empresa possuía milhares de programas.
Mas parte importante do conhecimento necessário para compreendê-los estava armazenada em um dispositivo extremamente sofisticado, porém perigosamente volátil:
a memória dos funcionários.
Bem-vindo, jovem programador COBOL, à dungeon da documentação.
📜 CAPÍTULO 1 — CÓDIGO NÃO É DOCUMENTAÇÃO
Existe uma frase muito repetida no desenvolvimento:
“O código é a documentação.”
Ela contém alguma verdade, mas também pode esconder uma armadilha.
Veja:
IF WS-TIPO-CLIENTE = 'E'
PERFORM 8200-CALCULO-ESPECIAL
END-IF.
Mesmo um iniciante consegue perceber o comportamento básico.
Se WS-TIPO-CLIENTE for igual a E, o programa executa 8200-CALCULO-ESPECIAL.
Ótimo.
Mas agora Myne começa a fazer perguntas.
— O que significa E?
— Especial.
— O que é um cliente especial?
— Não sei.
— Quem decidiu isso?
— Não sei.
— Por que ele recebe cálculo diferente?
— Também não sei.
— Desde quando?
— Talvez 2004.
— Posso remover?
— NÃO!
E encontramos a diferença entre código e conhecimento.
O código descreve muito bem aquilo que o computador precisa executar.
Mas nem sempre preserva:
por que determinada decisão foi tomada;
qual requisito originou a regra;
quem solicitou a alteração;
quais impactos foram considerados;
quais sistemas dependem dela;
quais procedimentos operacionais existem;
como recuperar o sistema quando algo dá errado.
Imagine encontrar:
* ALTERADO JOAO 14/06/2004
Excelente.
Descobrimos que João esteve ali.
Infelizmente, João não deixou pistas sobre aquilo que estava pensando.
Myne suspira.
Um livro que diz apenas:
“Capítulo alterado por João.”
não preserva conhecimento suficiente para reconstruir sua história.
🧠 CAPÍTULO 2 — A EMPRESA POSSUI UMA MEMÓRIA
Uma organização também possui memória.
Só que ela não fica em um único lugar.
Pode estar espalhada por:
Código-fonte
│
├── COBOL
├── JCL
├── COPYBOOKS
├── procedimentos
├── tickets
├── diagramas
├── e-mails
├── Wikis
├── runbooks
├── atas
├── manuais
└── pessoas
O último elemento merece atenção especial.
Imagine:
CONHECIMENTO DO SISTEMA XPTO
20% documentação
30% código
50% Carlos
Temos um problema.
Carlos pode:
Isso transforma Carlos em algo parecido com um Single Point of Failure humano.
Existe inclusive uma expressão informal usada em engenharia de software: bus factor.
Ela procura representar quantas pessoas poderiam ficar indisponíveis antes que um projeto perdesse conhecimento crítico.
Se a resposta for:
uma,
temos enorme concentração de conhecimento.
Myne ficaria horrorizada.
Para alguém que passou a vida tentando preservar livros, colocar conhecimento crítico exclusivamente na memória humana seria equivalente a possuir apenas um exemplar de um livro importantíssimo e guardá-lo ao lado de uma lareira.
⚔️ CAPÍTULO 3 — POR QUE PROGRAMADORES NÃO GOSTAM DE DOCUMENTAR?
Durante décadas, gestores perguntaram:
Como fazer os programadores documentarem?
É uma pergunta compreensível.
Mas pode ser a pergunta errada.
É fácil responder:
— Programador não gosta de escrever.
Alguns realmente não gostam.
Outros têm dificuldade para transformar raciocínio técnico em texto compreensível.
Mas existe um problema organizacional muito mais interessante.
Imagine dois programadores.
Programador A
Codificação ............ 8 horas
Testes ................. 3 horas
Documentação ........... 2 horas
-------------------------------
Total .................. 13 horas
Programador B
Codificação ............ 8 horas
Testes ................. 2 horas
Documentação ........... 0 horas
-------------------------------
Total .................. 10 horas
Se a empresa medir produtividade apenas pela velocidade da entrega, quem parece melhor?
B.
Portanto, não documentar pode ser perfeitamente racional dentro de um sistema de incentivos mal construído.
A empresa publica:
“Documentação é fundamental.”
Mas o projeto comunica:
PRAZO > DOCUMENTAÇÃO
E o funcionário aprende rapidamente qual regra realmente vale.
Myne percebe algo importante:
cultura organizacional não é aquilo que está escrito no manual. É aquilo que a organização recompensa, tolera e pune.
🏰 CAPÍTULO 4 — DOCUMENTAÇÃO NÃO DEVERIA SER UMA TAREFA POSTERIOR
Um projeto tradicional frequentemente funciona assim:
REQUISITO
↓
ANÁLISE
↓
DESENVOLVIMENTO
↓
TESTE
↓
PRODUÇÃO
↓
"Esquecemos da documentação."
Nesse modelo, documentação virou a última obrigação antes da libertação do programador.
Resultado?
Ele está cansado.
O prazo terminou.
Outro projeto já começou.
O gerente quer implantação.
E alguém pergunta:
— Você pode escrever o manual?
Nasce então o clássico:
MANUAL_SISTEMA_FINAL.DOC
Seguido, meses depois, por:
MANUAL_SISTEMA_FINAL2.DOC
MANUAL_SISTEMA_NOVO.DOC
MANUAL_SISTEMA_NOVO_FINAL.DOC
MANUAL_SISTEMA_NOVO_FINAL_OK.DOC
Isso não é versionamento.
É arqueologia digital.
A solução conceitual é colocar documentação dentro do ciclo de desenvolvimento:
REQUISITO
↓
DESIGN
↓
CÓDIGO
+
DOCUMENTAÇÃO
↓
TESTE
+
TESTE DA DOCUMENTAÇÃO
↓
REVIEW
↓
DEPLOY
Agora surge uma regra poderosa:
mudança no sistema pode significar mudança na documentação.
Não necessariamente toda alteração muda todo documento.
Mas toda alteração deveria provocar a pergunta:
Quais informações precisam ser atualizadas por causa desta mudança?
🔗 CAPÍTULO 5 — UMA ALTERAÇÃO COBOL NUNCA ESTÁ SOZINHA
O iniciante frequentemente imagina:
PROGRAMA COBOL
Mas sistemas corporativos são ecossistemas.
Uma alteração pode atingir:
REQUISITO
│
├── COBOL
├── COPYBOOK
├── JCL
├── PROC
├── VSAM
├── Db2
├── CICS
├── MQ
├── API
├── batch
├── procedimento operacional
├── troubleshooting
└── manual do usuário
Imagine aumentar um campo:
05 CLIENTE-ID PIC 9(06).
para:
05 CLIENTE-ID PIC 9(08).
Parece simples.
Mas Myne pergunta:
— O copybook compartilhado mudou?
— Sim.
— Arquivos VSAM?
— Talvez.
— Layout de interface?
— Sim.
— Programa consumidor?
— Também.
— Documentação?
Silêncio novamente.
Essa é a essência da análise de impacto.
Documentação não está fora do sistema.
Ela faz parte do conjunto de artefatos que descrevem o sistema.
🧙 CAPÍTULO 6 — MYNE DESCOBRE CONFIGURATION MANAGEMENT
Chegamos a um conceito importante para quem está começando no mainframe:
Configuration Management.
Simplificando bastante, Configuration Management procura responder perguntas como:
O que existe?
Qual versão existe?
Qual versão está em produção?
Quem alterou?
Quando alterou?
Por que alterou?
O que depende disso?
Qual era a configuração anterior?
Você provavelmente já percebeu que isso não interessa somente ao código.
Imagine:
RUNBOOK-PAGAMENTOS
Versão: 4.7
Sistema: PAY001
Owner: Payments Operations
Aprovador: Production Control
Última revisão: 23/09/2026
Próxima revisão: 23/03/2027
Change: CHG-98472
Status: APPROVED
Agora temos algo auditável.
Podemos perguntar:
Qual procedimento estava válido em 14 de março?
E recuperar aquela versão.
Essa capacidade é essencial.
💀 CAPÍTULO 7 — ÀS 03:17, A DOCUMENTAÇÃO VIRA PRODUÇÃO
03:17.
Sim, jovem padawan.
Você encontrou o easter egg.
O telefone toca.
INCIDENTE CRÍTICO
SISTEMA DE PAGAMENTOS
O operador consulta o procedimento.
1. Localizar JOB PAYR001.
2. Cancelar execução.
3. Executar PAYREC01.
4. Verificar mensagem PAY003I.
Ele está prestes a executar o passo 3 quando alguém grita:
— NÃO EXECUTA!
— Por quê?
— PAYREC01 foi aposentado.
— Quando?
— Ano passado.
— O procedimento manda executar.
Silêncio.
A documentação está oficialmente publicada.
Mas descreve um sistema que já não existe.
Temos então duas verdades:
VERDADE EXECUTÁVEL
≠
VERDADE DOCUMENTADA
Esse fenômeno poderia ser chamado de documentation drift ou deriva documental.
E aqui aparece uma conclusão contraintuitiva:
documentação errada pode ser pior que documentação inexistente.
Se não houver documentação, o operador sabe que precisa investigar.
Quando existe um procedimento aparentemente oficial, ele pode confiar nele.
🧪 CAPÍTULO 8 — DOCUMENTAÇÃO TAMBÉM PRECISA SER TESTADA
Essa ideia é extraordinariamente importante.
Considere:
1. Entre no SDSF.
2. Localize o job.
3. Execute comando X.
4. Confirme mensagem Y.
5. Reinicie componente Z.
Um especialista lê e afirma:
— Perfeito.
Mas entregue isso a alguém que nunca executou o procedimento.
Ele pergunta:
— Em qual painel?
— Como localizo o job?
— Qual comando?
— Onde aparece Y?
— E se Y não aparecer?
Descobrimos cinco buracos em trinta segundos.
Portanto, documentação operacional pode possuir algo parecido com teste funcional.
Uma pessoa representativa do público-alvo tenta realizar a tarefa utilizando somente as instruções.
Isso revela:
Myne aprovaria.
Não basta imprimir o livro.
Precisamos verificar se o leitor consegue utilizá-lo.
📚 CAPÍTULO 9 — MAIS DOCUMENTAÇÃO NÃO SIGNIFICA MELHOR DOCUMENTAÇÃO
Existe outra pergunta antiga:
Quanto devemos documentar?
Resposta errada:
Tudo.
Outra resposta errada:
O mínimo possível.
O objetivo é:
DOCUMENTAÇÃO NECESSÁRIA
+
CORRETA
+
ATUAL
+
ENCONTRÁVEL
+
COMPREENSÍVEL
+
ADEQUADA À TAREFA
Um manual de 900 páginas pode ser praticamente inútil durante um incidente.
O operador talvez precise de duas páginas.
Diferentes necessidades exigem diferentes documentos:
| Necessidade | Informação |
|---|
| compreender arquitetura | Architecture Overview |
| desenvolver | Developer Guide |
| operar | Runbook |
| investigar falha | Troubleshooting Guide |
| integrar | Interface/API Specification |
| recuperar desastre | Disaster Recovery Procedure |
| utilizar aplicação | User Guide |
| modificar | Design/Change Documentation |
| aprender sistema | Onboarding Guide |
| auditar | evidências e histórico |
A antiga ideia de colocar tudo no gigantesco Manual do Sistema frequentemente cria documentos impossíveis de consumir.
🗺️ CAPÍTULO 10 — DOCUMENTAÇÃO PRECISA SER ENCONTRÁVEL
Myne finalmente recebe uma boa notícia.
— Temos documentação!
— Onde?
— Share.
— Qual?
— Não lembro.
— Nome?
— Alguma coisa como PAY...
Depois de vinte minutos:
\\server\departamento\projetos\old\sistemas\pagamentos\
documentacao\backup\antigo\
Myne quase desmaia.
Informação que existe mas não pode ser encontrada possui valor operacional próximo de zero.
Portanto, governança documental envolve também:
taxonomia;
pesquisa;
nomes consistentes;
metadados;
owners;
classificação;
links;
relacionamentos;
controle de versão.
Bibliotecas descobriram isso séculos atrás.
Não basta possuir livros.
Precisamos saber onde eles estão e como encontrá-los.
🏛️ CAPÍTULO 11 — CENTRALIZAR OU DESCENTRALIZAR?
O problema já existia décadas atrás.
Deveríamos possuir um departamento central de documentação?
Ou documentadores dentro das equipes?
Centralizado
DOCUMENTAÇÃO
│
┌─────────┼─────────┐
↓ ↓ ↓
SISTEMA A SISTEMA B SISTEMA C
Excelente para:
padrões;
qualidade;
independência;
governança;
consistência.
Mas pode ficar distante da tecnologia.
Descentralizado
TIME A → documentação A
TIME B → documentação B
TIME C → documentação C
Excelente proximidade.
Mas pode produzir três dialetos diferentes.
Uma solução interessante é o modelo federado:
GOVERNANÇA CENTRAL
│
padrões e ferramentas
│
┌─────────┼─────────┐
↓ ↓ ↓
TIME A TIME B TIME C
│ │ │
OWNER OWNER OWNER
O centro define regras.
As equipes preservam conhecimento local.
👑 CAPÍTULO 12 — TODO DOCUMENTO PRECISA DE UM DONO
Uma regra simples evita enorme quantidade de caos:
todo documento relevante deve possuir owner.
Owner não significa necessariamente autor.
O owner responde pela validade.
Pense assim:
DOCUMENTO
↓
OWNER
↓
REVISÃO
↓
APROVAÇÃO
↓
PUBLICAÇÃO
↓
USO
↓
NOVA REVISÃO
↓
ARQUIVAMENTO
Documento sem proprietário tende a virar órfão.
E órfãos digitais envelhecem silenciosamente.
🧹 CAPÍTULO 13 — DOCUMENTO OBSOLETO PRECISA MORRER
Esse ponto é pouco discutido.
Criar documentação é importante.
Mas aposentar documentação também é.
Imagine encontrar:
RUNBOOK-PAY-2019
RUNBOOK-PAY-2021
RUNBOOK-PAY-NOVO
RUNBOOK-PAY-FINAL
RUNBOOK-PAY-ATUAL
Qual é válido?
Se ninguém souber, temos risco operacional.
Um processo maduro deveria permitir estados como:
DRAFT
REVIEW
APPROVED
PUBLISHED
SUPERSEDED
ARCHIVED
Assim sabemos que determinado documento existe historicamente, mas não deve mais orientar operações atuais.
Myne chamaria isso de diferença entre:
arquivo histórico e livro de uso corrente.
💳 CAPÍTULO 14 — DÍVIDA DOCUMENTAL
Programadores conhecem Technical Debt.
Mas existe outra dívida:
Documentation Debt.
Toda mudança não refletida na documentação cria um pequeno débito.
No começo ninguém percebe.
Mudança 1 → documento quase correto
Mudança 2 → pequeno erro
Mudança 3 → faltam dois procedimentos
Mudança 4 → diagrama incorreto
Mudança 5 → ninguém confia mais
Finalmente acontece algo curioso:
“Não consulte a Wiki porque está desatualizada.”
Pronto.
A organização perdeu confiança em seu próprio repositório de conhecimento.
Podemos imaginar:
Documentation Debt ↑
MTTR ↑
Onboarding ↑
Dependência de especialistas ↑
Retrabalho ↑
Risco operacional ↑
Risco de auditoria ↑
O custo economizado ontem reaparece com juros.
🔍 CAPÍTULO 15 — ENTRA O AUDITOR
Agora o auditor chega.
Um auditor fraco pergunta:
— Vocês possuem documentação?
A equipe mostra cinquenta PDFs.
Check.
Auditor satisfeito.
Myne não.
Um auditor melhor pergunta:
“Mostre uma alteração recente em produção.”
Escolhemos:
CHG-98472
Agora reconstruímos:
REQUISITO
↓
ANÁLISE
↓
CHANGE
↓
ALTERAÇÃO COBOL
↓
TESTE
↓
APROVAÇÃO
↓
DEPLOY
↓
DOCUMENTAÇÃO
↓
COMUNICAÇÃO
Depois fazemos o contrário.
Escolhemos um programa em produção:
PAYB0031
E perguntamos:
Qual versão?
Qual change colocou isso aqui?
Quem aprovou?
Quais testes existem?
Qual requisito originou?
Qual documentação foi atualizada?
Isso é rastreabilidade.
Não estamos procurando papel.
Estamos procurando evidência de controle.
⚔️ CAPÍTULO 16 — O AUDITOR PROCURA A EMPRESA REAL
Existe uma diferença fundamental entre:
PROCESSO DOCUMENTADO
e:
PROCESSO REAL
O manual diz:
Em incidentes críticos consultar RUNBOOK-PAY.
O auditor entrevista operadores.
— O que você faz quando PAY cai?
— Chamo o Zé.
— E o runbook?
— Ah... aquilo está velho.
Bingo.
Encontramos uma diferença entre governança formal e comportamento operacional.
A empresa pensa que possui:
INCIDENTE
↓
RUNBOOK
↓
RESOLUÇÃO
Na realidade possui:
INCIDENTE
↓
WhatsApp
↓
"CHAMA O ZÉ"
Zé virou middleware humano.
E não possui redundância.
🤖 CAPÍTULO 17 — MYNE CONHECE A INTELIGÊNCIA ARTIFICIAL
Então chega 2026.
Myne encontra uma máquina extraordinária.
Ela recebe:
COBOL;
JCL;
copybooks;
diagramas;
tickets;
commits;
logs.
E produz explicações.
— Ela escreve livros?!
Quase.
IA generativa pode ajudar enormemente na documentação.
Por exemplo, pode transformar:
EVALUATE WS-STATUS
WHEN 'A'
PERFORM 1000-ATIVO
WHEN 'B'
PERFORM 2000-BLOQUEADO
WHEN OTHER
PERFORM 9000-ERRO
END-EVALUATE.
em uma explicação preliminar.
Pode ainda:
resumir código;
explicar campos;
gerar diagramas preliminares;
converter tickets em release notes;
comparar versões;
identificar documentação possivelmente afetada;
criar perguntas para revisão;
produzir rascunhos de runbooks.
Fantástico.
Mas existe uma armadilha gigantesca.
☠️ CAPÍTULO 18 — IA PODE DOCUMENTAR PERFEITAMENTE UMA COISA ERRADA
Imagine a IA afirmar:
“O campo E representa cliente empresarial.”
Texto bonito.
Gramática impecável.
Completamente errado.
Na verdade:
E = CLIENTE ESPECIAL
Esse é um novo tipo de risco.
Antigamente tínhamos documentação ruim obviamente ruim.
Agora podemos possuir documentação errada extremamente convincente.
Portanto:
IA
↓
RASCUNHO
↓
SME TÉCNICO
↓
USUÁRIO
↓
VALIDAÇÃO
↓
APROVAÇÃO
↓
PUBLICAÇÃO
Nunca:
IA
↓
PRODUÇÃO
A inteligência artificial reduz o custo de produção.
Ela não transfere responsabilidade pela verdade.
🧰 CAPÍTULO 19 — DOCUMENTATION AS CODE
Agora Myne encontra Git.
E quase pede Ferdinand em casamento novamente.
Porque finalmente os livros possuem histórico automático.
Podemos organizar:
docs/
├── architecture/
├── development/
├── operations/
├── troubleshooting/
├── interfaces/
└── security/
Uma alteração começa:
git checkout -b CHG-98472
O programador altera:
src/PAYB0031.cbl
e também:
docs/operations/payment-runbook.md
Então:
CODE
+
DOC
↓
PULL REQUEST
↓
REVIEW
↓
PIPELINE
↓
RELEASE
Isso é poderoso porque aproxima documentação do mesmo fluxo utilizado pelo software.
Temos:
versionamento;
histórico;
autoria;
comparação;
revisão;
aprovação;
automação.
Código e conhecimento começam a viajar juntos.
🧪 CAPÍTULO 20 — UM PASSO A PASSO PARA O PROGRAMADOR COBOL
Você recebeu uma alteração.
Não pense apenas:
“Qual linha COBOL vou mudar?”
Faça algo parecido com isto.
Passo 1 — descubra o motivo
Pergunte:
Qual problema estamos resolvendo?
Passo 2 — descubra o impacto
Liste:
COBOL?
COPYBOOK?
JCL?
Db2?
VSAM?
CICS?
MQ?
API?
batch?
usuário?
operação?
Passo 3 — localize documentação relacionada
Procure:
Architecture
Developer Guide
Runbook
Interface Specification
User Guide
Troubleshooting
Passo 4 — altere código e conhecimento juntos
Não espere três meses.
Passo 5 — teste ambos
O programa funciona?
A instrução também?
Passo 6 — peça revisão
Técnico revisa tecnologia.
Usuário revisa significado.
Operação revisa execução.
Passo 7 — preserve rastreabilidade
Relacione:
REQUISITO → CHANGE → CÓDIGO → TESTE → DOCUMENTAÇÃO
Passo 8 — retire informação obsoleta
Não deixe armadilhas históricas disponíveis como instrução atual.
🧙♀️ CAPÍTULO 21 — MYNE CRIA AS DEZ REGRAS DA BIBLIOTECA DO MAINFRAME
Depois de observar aquela organização, Myne escreve:
I. Código não substitui contexto.
II. Toda mudança deve avaliar impacto documental.
III. Todo documento crítico precisa de owner.
IV. Documentação precisa possuir versão.
V. Informação precisa ser encontrável.
VI. Procedimentos críticos precisam ser testados.
VII. Documento obsoleto precisa ser claramente aposentado.
VIII. IA pode escrever rascunhos; humanos continuam responsáveis pela verdade.
IX. Conhecimento crítico não pode existir somente na cabeça de uma pessoa.
X. Documentação faz parte do produto.
Ferdinand lê.
Fica em silêncio.
— Onze regras seriam mais completas.
Myne fecha o livro.
— Dez ficam melhores num slide.
☕ EPÍLOGO — O ÚLTIMO LIVRO DE CARLOS
Alguns meses depois, Carlos anunciou aposentadoria.
Ninguém entrou em pânico.
Durante meses, a equipe havia transformado seu conhecimento em:
Architecture Guides
Runbooks
Troubleshooting Guides
Decision Records
Diagramas
README
Procedimentos
Histórico de mudanças
Mais importante: outras pessoas haviam utilizado e testado aquele conhecimento.
No último dia, Carlos deixou sobre a mesa uma pequena folha.
Myne encontrou.
Nela estava escrito:
03:17
Se PAYB0031 apresentar S0C7 depois do fechamento,
não reinicie imediatamente.
Verifique primeiro o arquivo PAY.IN.TRANS.
E não acredite no procedimento de 2019.
Myne sorriu.
Digitalizou a informação.
Criou um ticket.
Atualizou o troubleshooting.
Relacionou ao sistema.
Mandou revisar.
E destruiu a folha.
Porque finalmente aquela empresa havia compreendido algo que bibliotecários sabem há séculos:
conhecimento que não pode ser encontrado não está verdadeiramente disponível.
Conhecimento que não pode ser verificado não é confiável.
Conhecimento que depende de uma única pessoa não pertence realmente à organização.
E conhecimento que não acompanha a evolução do sistema lentamente se transforma em ficção.
Para um programador COBOL iniciante, talvez essa seja uma das lições mais importantes da carreira.
Você não herdará apenas programas.
Herdará decisões tomadas por pessoas que talvez nunca conheça.
Encontrará campos criados antes de você nascer.
COPYBOOKs compartilhados por dezenas de aplicações.
JCLs cujo comentário mais recente terá quinze anos.
Regras de negócio que sobreviveram a três presidentes da empresa, quatro arquiteturas e seis gerações de programadores.
Um dia alguém também encontrará o seu código.
E encontrará algo como:
*---------------------------------------------------------*
* CHG-98472 - 23/09/2026 *
* ALTERADA REGRA DE CLIENTE ESPECIAL. *
* MOTIVO: NOVA REGRA CONTRATUAL. *
* DOCUMENTACAO: DOC/PAYMENTS/RULES-CLIENTE-ESPECIAL.MD *
*---------------------------------------------------------*
Essa pessoa talvez nunca saiba seu nome.
Mas saberá por que aquilo existe.
E existe algo profundamente bonito nisso.
Porque mainframes são máquinas construídas para sobreviver ao tempo.
COBOL também.
Mas sistemas de cinquenta anos não sobrevivem apenas porque o hardware continua funcionando.
Eles sobrevivem porque sucessivas gerações de profissionais conseguem receber, compreender, modificar e transmitir conhecimento.
Somos temporários.
O sistema pode continuar.
O código fica.
As decisões ficam.
A documentação deveria ficar também.
E talvez Myne, olhando para milhões de linhas COBOL preservadas durante décadas, finalmente percebesse que havia encontrado uma biblioteca muito diferente daquela que sempre sonhou construir.
Uma biblioteca na qual alguns livros são executáveis.
E onde esquecer de atualizar uma página pode, às 03:17 da manhã, derrubar produção.
Bem-vindo à Biblioteca do Mainframe.
Seu próximo commit também é uma página da história.
