 |
| Bellacosa Mainframe e uma odisseia do Cobol |
☕ Um Café no Bellacosa Mainframe
COBOL: Uma Odisseia de 1959 ao IBM Z
Quando um Programador Descobre que o Código Mais Antigo da Nave Ainda Controla os Sistemas Vitais da Civilização
“Abra as portas do processamento, HAL.”
“Sinto muito, programador. O fechamento contábil ainda não terminou.”
Em algum ponto silencioso de um datacenter, protegido por portas reforçadas, sensores, câmeras, autenticação multifator e camadas de segurança que fariam a nave Discovery One parecer uma kombi espacial, existe um programa COBOL trabalhando.
Ele não aparece nos comerciais.
Não possui uma mascote colorida.
Não muda de framework a cada seis meses.
Não publica frases motivacionais sobre inovação disruptiva.
Ele apenas trabalha.
Lê registros.
Valida contas.
Calcula juros.
Atualiza saldos.
Autoriza pagamentos.
Rejeita inconsistências.
Grava resultados.
E, ao terminar, provavelmente deixa uma mensagem curta no relatório:
PROCESSAMENTO CONCLUÍDO COM SUCESSO
Enquanto desenvolvedores discutem qual linguagem dominará o futuro, esse programa continua executando uma missão iniciada décadas atrás.
Talvez tenha sido escrito quando terminais ainda não eram comuns.
Talvez tenha atravessado cartões perfurados, fitas magnéticas, discos removíveis, terminais 3270, redes privadas, interfaces gráficas, internet, APIs, microsserviços, nuvem híbrida e inteligência artificial.
O hardware mudou.
O sistema operacional evoluiu.
As interfaces se transformaram.
Mas a regra de negócio permaneceu.
Essa é a verdadeira razão pela qual o COBOL se recusa a desaparecer.
Não porque esteja preso ao passado.
Mas porque continua sustentando o presente.
E esta é a história de uma das mais impressionantes odisseias da engenharia de software.
Prólogo: o monólito verde de 1976
A capa verde do manual apresentado nesta conversa parece um monólito tecnológico.
Na parte superior, o logotipo da IBM.
No centro, em letras brancas:
IBM DOS Full American National Standard COBOL
Na lateral, uma indicação simples:
DOS/VS COBOL
Na parte inferior:
Seventh Edition — April 1976
Para um observador moderno, pode parecer apenas um manual antigo.
Para um programador mainframe, entretanto, aquilo representa uma passagem para outra era.
Em 1976, os computadores pessoais ainda não faziam parte da vida cotidiana. Não existiam navegadores, smartphones, GitHub, Docker, Kubernetes ou vídeos ensinando programação em dez minutos.
A documentação era física.
O conhecimento vinha em volumes.
O programador precisava consultar tabelas, sintaxes, restrições do compilador, formatos de registros, instruções de entrada e saída e características específicas do sistema operacional.
O manual não era um acessório.
Era parte da estação de trabalho.
Imagine um jovem programador entrando numa sala de processamento de dados em 1976. Ele encontra armários metálicos, impressoras de linha, operadores, formulários contínuos, fitas identificadas, pilhas de relatórios e um computador central que custa uma fortuna.
Em suas mãos está aquele manual verde.
Ele não sabe, mas alguns dos programas que ajudará a escrever poderão sobreviver à sua carreira inteira.
Talvez sobrevivam à empresa que os criou.
Talvez sejam migrados para plataformas sucessivas.
Talvez executem, décadas depois, num IBM Z moderno.
É como se o astronauta David Bowman encontrasse um monólito não na Lua, mas numa biblioteca técnica, e percebesse que aquele objeto contém instruções capazes de atravessar gerações inteiras de computadores.
Capítulo 1 — A missão original do COBOL
COBOL significa:
COmmon Business-Oriented Language
Ou, em português:
Linguagem Comum Orientada aos Negócios.
O nome revela sua missão.
COBOL não nasceu para ser uma linguagem experimental.
Não nasceu para impressionar matemáticos.
Não nasceu para criar efeitos visuais.
Não nasceu para construir jogos ou controlar sondas planetárias.
Ele nasceu para processar os registros do mundo empresarial.
Folhas de pagamento.
Contas bancárias.
Seguros.
Impostos.
Estoques.
Faturas.
Financiamentos.
Contratos.
Pensões.
Transações comerciais.
Registros governamentais.
Sua arquitetura foi moldada por uma pergunta muito concreta:
Como representar e processar dados empresariais de maneira clara, previsível e confiável?
Essa pergunta continua válida.
Empresas modernas ainda possuem clientes, contas, pagamentos, contratos e regras.
Os nomes das tecnologias mudaram, mas a essência do negócio continua incrivelmente parecida.
Um banco de 1976 precisava saber:
quem era o cliente;
quanto havia na conta;
qual valor seria debitado;
qual valor seria creditado;
qual regra deveria ser aplicada;
qual evidência seria produzida.
Um banco moderno precisa saber exatamente as mesmas coisas.
A diferença é que hoje as transações chegam por aplicativos, APIs, cartões, terminais, redes instantâneas e plataformas digitais.
Mas, em algum ponto do processamento, ainda existe uma regra dizendo:
IF SALDO-DISPONIVEL >= VALOR-TRANSACAO
SUBTRACT VALOR-TRANSACAO
FROM SALDO-DISPONIVEL
MOVE "APROVADA" TO STATUS-TRANSACAO
ELSE
MOVE "RECUSADA" TO STATUS-TRANSACAO
END-IF
A sintaxe pode parecer simples.
O impacto não é.
Esse pequeno bloco representa uma decisão financeira.
Ele pode autorizar a compra de alimentos, pagar uma conta médica, liberar um empréstimo ou impedir uma operação indevida.
COBOL trabalha no ponto onde código e realidade se encontram.
Capítulo 2 — A linguagem que podia ser lida
Uma das ideias centrais do COBOL era a legibilidade.
Observe este exemplo:
IF IDADE-CLIENTE GREATER THAN OR EQUAL TO 18
MOVE "CLIENTE MAIOR DE IDADE"
TO MENSAGEM
ELSE
MOVE "CLIENTE MENOR DE IDADE"
TO MENSAGEM
END-IF
Mesmo uma pessoa que nunca estudou COBOL consegue imaginar o que está acontecendo.
Essa característica não é uma fraqueza.
É uma decisão de engenharia.
Sistemas empresariais precisam ser examinados por muitas pessoas:
programadores;
analistas;
auditores;
especialistas de negócio;
equipes de suporte;
profissionais de segurança;
responsáveis por conformidade;
novos integrantes da equipe.
Num sistema de missão crítica, o código precisa sobreviver ao seu criador.
Uma rotina obscura pode parecer elegante para quem a escreveu, mas se torna perigosa quando ninguém consegue compreendê-la cinco anos depois.
COBOL foi pensado para resistir a esse problema.
Sua verbosidade frequentemente criticada é também uma forma de documentação.
COMPUTE VALOR-JUROS =
SALDO-DEVEDOR
* TAXA-JUROS
/ 100
Não há muito mistério.
O código declara a intenção.
Isso é especialmente importante em programas que precisam permanecer compreensíveis durante décadas.
A nave espacial pode trocar seus tripulantes.
O programa precisa continuar operando.
Capítulo 3 — O verdadeiro patrimônio não está no código
Quando alguém olha para um sistema COBOL com milhões de linhas, pode pensar:
“É apenas código antigo.”
Esse é um dos maiores erros de interpretação da história da tecnologia.
O código é apenas a superfície.
O verdadeiro patrimônio está nas regras de negócio acumuladas.
Imagine uma instituição financeira que existe desde 1965.
Ao longo das décadas, seus sistemas precisaram incorporar:
mudanças nas leis;
novas moedas;
alterações tributárias;
regras de crédito;
métodos de cálculo;
produtos bancários;
exceções contratuais;
fusões entre instituições;
novas políticas de segurança;
decisões judiciais;
exigências regulatórias;
prevenção contra fraudes;
mudanças contábeis;
integrações com outras empresas.
Cada alteração acrescentou conhecimento ao sistema.
Um programa COBOL com quarenta anos não contém apenas quarenta anos de instruções.
Ele contém quarenta anos de decisões empresariais.
Veja uma regra aparentemente estranha:
IF TIPO-CONTRATO = "P7"
AND DATA-ADESAO < 19940701
AND CODIGO-REGIAO NOT = 18
PERFORM CALCULO-ESPECIAL
ELSE
PERFORM CALCULO-PADRAO
END-IF
Um programador iniciante pode perguntar:
“Por que existe essa exceção?”
Talvez ela tenha sido criada devido a uma mudança legal ocorrida em 1994.
Talvez represente contratos antigos que mantiveram uma condição específica.
Talvez proteja clientes adquiridos numa fusão.
Talvez esteja ligada a uma decisão judicial.
Talvez ninguém da equipe atual conheça todos os detalhes.
Mas o sistema conhece.
Ele carrega aquela regra como a Discovery One carregava instruções secretas sobre sua missão.
O perigo de uma reescrita apressada é remover a condição sem compreender sua origem.
O programa moderno compilará.
Os testes superficiais passarão.
A interface ficará bonita.
E, meses depois, alguém descobrirá que milhares de contratos foram calculados incorretamente.
O erro não estava na nova linguagem.
Estava na perda de conhecimento.
Capítulo 4 — Por que “traduzir para Java” não resolve tudo
Frequentemente aparece a proposta:
“Vamos converter o COBOL para Java.”
Essa frase parece simples porque reduz o problema a uma troca de sintaxe.
Mas modernizar um sistema empresarial é muito mais complexo.
Considere este trecho:
EVALUATE TIPO-OPERACAO
WHEN "01"
PERFORM VALIDAR-DEPOSITO
WHEN "02"
PERFORM VALIDAR-SAQUE
WHEN "03"
PERFORM VALIDAR-TRANSFERENCIA
WHEN OTHER
MOVE 12 TO CODIGO-ERRO
END-EVALUATE
Em Java, poderia existir uma estrutura equivalente.
Porém, a questão central não é como converter EVALUATE para switch.
As perguntas importantes são:
Por que o código de erro é 12?
Quem interpreta esse código?
Ele aparece num relatório?
Ele é enviado a outro sistema?
Existe um programa esperando exatamente dois dígitos?
A operação "03" possui regras diferentes em finais de semana?
Há integração com CICS, Db2, VSAM ou IBM MQ?
O programa participa de uma unidade de trabalho?
O que acontece se a gravação ocorrer parcialmente?
Como o sistema realiza recuperação?
Quais controles de auditoria precisam ser preservados?
Qual volume deve ser processado?
Quanto tempo a janela batch permite?
Uma tradução automática pode converter instruções.
Ela não compreende necessariamente a missão completa.
É como reconstruir a inteligência de HAL 9000 apenas traduzindo seus comandos para outra linguagem, sem entender os objetivos contraditórios que governam seu comportamento.
Capítulo 5 — Milhões de horas de produção
Um sistema COBOL antigo possui uma característica difícil de reproduzir: tempo real de uso.
Imagine um programa executado todos os dias durante trinta anos.
Ele passou por:
Cada execução revelou problemas.
Cada correção fortaleceu o sistema.
Isso não significa que programas antigos sejam perfeitos.
Sistemas COBOL também possuem defeitos, dívidas técnicas, trechos obscuros e decisões ultrapassadas.
Mas muitos deles foram refinados por décadas de operação real.
Essa maturidade possui enorme valor.
Testes automatizados são fundamentais.
Ambientes de homologação são indispensáveis.
Simulações são úteis.
Porém, nada substitui completamente décadas de comportamento observado em produção.
Um programa que processou bilhões de registros acumulou uma espécie de experiência operacional.
Ele pode não possuir inteligência artificial.
Mas carrega cicatrizes.
Capítulo 6 — O hardware envelheceu, a plataforma evoluiu
Outro erro comum é imaginar que programas COBOL antigos continuam executando exatamente nas mesmas máquinas de quarenta anos atrás.
Em muitos casos, isso não é verdade.
As aplicações foram movidas por diferentes gerações de hardware e software.
A plataforma mainframe evoluiu continuamente.
O IBM Z moderno não é um computador congelado nos anos 1970.
É uma plataforma empresarial contemporânea, projetada para altos volumes, segurança, disponibilidade e integração.
O mesmo ambiente pode reunir:
O programa COBOL permanece porque o ecossistema se modernizou ao redor dele.
Imagine uma nave cuja estrutura central é continuamente aperfeiçoada.
Novos motores são instalados.
Os sensores são substituídos.
A navegação é atualizada.
Os canais de comunicação evoluem.
Mas o módulo que controla o oxigênio continua sendo usado porque funciona, foi testado e todos dependem dele.
Substituí-lo apenas para dizer que a nave está “mais moderna” seria irresponsável.
Capítulo 7 — A compatibilidade como filosofia
Uma das maiores forças da cultura mainframe é a continuidade.
Em muitas áreas da tecnologia, uma nova versão pode abandonar rapidamente os sistemas anteriores.
No universo empresarial, isso pode ser desastroso.
Uma empresa investe durante anos em programas, dados, processos, treinamento e integração.
Ela não pode simplesmente descartar tudo a cada mudança tecnológica.
A compatibilidade permite que investimentos antigos continuem produzindo valor.
Isso não significa nunca mudar.
Significa mudar sem destruir.
Essa é uma diferença essencial.
Modernização responsável procura combinar:
preservação do que funciona;
eliminação de riscos;
documentação das regras;
criação de testes;
exposição por APIs;
renovação de interfaces;
automação de entrega;
melhoria da observabilidade;
substituição gradual de componentes.
O objetivo não é conservar cada linha para sempre.
O objetivo é evitar que a modernização se transforme num ABEND corporativo.
Capítulo 8 — O aplicativo moderno e o motor invisível
Imagine uma cliente usando o celular para pagar uma conta.
Ela toca no aplicativo.
A tela mostra uma animação elegante.
Em poucos segundos, aparece:
Pagamento realizado com sucesso.
Por trás dessa experiência podem existir várias camadas:
Aplicativo móvel
↓
API Gateway
↓
Serviço Java
↓
IBM MQ
↓
Transação CICS
↓
Programa COBOL
↓
Db2 ou VSAM
A cliente não precisa conhecer essa arquitetura.
Para ela, tudo é um aplicativo moderno.
Mas o núcleo da transação pode ser um programa COBOL.
Isso demonstra uma verdade importante:
Modernização não exige necessariamente substituição total.
Um programa confiável pode ser encapsulado.
Pode receber chamadas por API.
Pode participar de fluxos modernos.
Pode interagir com aplicações web, dispositivos móveis, mensageria e nuvem híbrida.
O COBOL não precisa aparecer na tela para continuar sendo essencial.
Ele é como o computador central da nave: invisível para os passageiros, decisivo para a missão.
Capítulo 9 — Batch: o turno da madrugada
Durante o dia, sistemas online recebem transações individuais.
Durante a noite, entra em cena outro universo: o processamento batch.
É quando grandes volumes são consolidados.
Extratos são gerados.
Contas são fechadas.
Juros são calculados.
Relatórios são produzidos.
Arquivos são enviados.
Dados são reconciliados.
Um job pode executar vários passos:
//FECHAMEN JOB ...
//STEP01 EXEC PGM=VALIDA01
//ARQENT DD DSN=BANCO.MOVIMENTO.DIA,DISP=SHR
//ARQSAI DD DSN=BANCO.MOVIMENTO.OK,
// DISP=(NEW,CATLG,DELETE)
//STEP02 EXEC PGM=CALCJURO
//STEP03 EXEC PGM=GERAEXTR
Para um iniciante, isso pode parecer apenas uma sequência técnica.
Para a empresa, é uma linha de produção digital.
Se o primeiro passo falha, os seguintes podem não executar.
Se um arquivo está incorreto, o fechamento pode atrasar.
Se o job perde sua janela, o sistema online do dia seguinte pode ser afetado.
Por isso o ambiente mainframe desenvolveu uma cultura intensa de disciplina operacional.
Horários.
Dependências.
Retornos.
Códigos de condição.
Recuperação.
Reprocessamento.
Auditoria.
COBOL sobreviveu também porque se encaixa extraordinariamente bem nesse universo de processamento previsível e volumoso.
Capítulo 10 — Precisão decimal: onde um centavo importa
Muitas linguagens foram criadas com forte orientação científica ou de sistemas.
COBOL foi criado para negócios.
Negócios trabalham com números decimais.
Dinheiro exige precisão.
Considere:
01 VALOR-COMPRA PIC 9(7)V99.
01 TAXA-DESCONTO PIC 9(3)V99.
01 VALOR-DESCONTO PIC 9(7)V99.
01 VALOR-FINAL PIC 9(7)V99.
COMPUTE VALOR-DESCONTO ROUNDED =
VALOR-COMPRA * TAXA-DESCONTO / 100
COMPUTE VALOR-FINAL =
VALOR-COMPRA - VALOR-DESCONTO
Um sistema financeiro precisa definir:
Um erro de R$ 0,01 pode parecer pequeno.
Multiplicado por milhões de transações, deixa de ser pequeno.
Além disso, o problema não é apenas o valor total.
É a confiança.
Um cliente que identifica cálculo incorreto começa a questionar todo o sistema.
COBOL foi projetado para tornar estruturas numéricas e formatos empresariais explícitos.
A PICTURE, representada por PIC, funciona como um contrato de dados.
01 VALOR-SALDO PIC S9(11)V99 COMP-3.
Essa declaração informa que existe sinal, onze posições inteiras, duas decimais e representação decimal compactada.
Para um iniciante, parece apenas sintaxe.
Para o sistema, é a forma física do dinheiro.
Capítulo 11 — O perigoso mito do software velho
“Antigo” e “ruim” não são sinônimos.
“Novo” e “bom” também não são.
Um sistema deve ser avaliado por critérios concretos:
atende ao negócio?
é confiável?
possui suporte?
é seguro?
consegue evoluir?
integra-se com outros sistemas?
seu custo é justificável?
seus riscos são conhecidos?
existe mão de obra?
há documentação e testes?
a arquitetura permite manutenção?
Um programa antigo pode estar bem estruturado, documentado e estável.
Um programa novo pode ser frágil, confuso e inseguro.
A data de criação não determina a qualidade.
O problema real aparece quando o sistema se torna impossível de compreender, manter ou adaptar.
Por isso a pergunta correta não é:
“O COBOL é antigo?”
A pergunta correta é:
“Este sistema ainda entrega valor com risco aceitável?”
Em muitos casos, a resposta continua sendo sim.
Capítulo 12 — Passo a passo para o Padawan COBOL
Ao encontrar um programa antigo, não tente compreender tudo de uma vez.
Aproxime-se como um astronauta examinando um artefato desconhecido.
Primeiro passo: identifique a missão
Leia o cabeçalho.
Procure comentários.
Observe o nome do programa.
Descubra quais dados entram e quais resultados saem.
Pergunte:
Qual problema empresarial este programa resolve?
Segundo passo: examine a Data Division
Comece pelos dados.
WORKING-STORAGE SECTION.
01 WS-CLIENTE.
05 WS-CODIGO PIC 9(8).
05 WS-NOME PIC X(40).
05 WS-SALDO PIC S9(9)V99 COMP-3.
05 WS-STATUS PIC X(01).
A estrutura dos dados costuma revelar grande parte da história.
Terceiro passo: localize o fluxo principal
Procure a sequência central:
PROCEDURE DIVISION.
PERFORM INICIALIZAR
PERFORM PROCESSAR UNTIL FIM-ARQUIVO
PERFORM FINALIZAR
STOP RUN.
Esse é o mapa da missão.
Quarto passo: siga cada PERFORM
Analise uma rotina por vez.
PROCESSAR.
READ ARQUIVO-CLIENTES
AT END
MOVE "S" TO FIM-ARQUIVO
NOT AT END
PERFORM VALIDAR-CLIENTE
PERFORM ATUALIZAR-CLIENTE
END-READ.
Não pule diretamente para trechos complexos.
Siga o fluxo.
Quinto passo: observe arquivos e bancos
Descubra onde os dados residem.
Pode ser:
arquivo sequencial;
VSAM;
Db2;
IMS;
fila MQ;
área temporária CICS.
Sexto passo: procure códigos de retorno
IF SQLCODE NOT = ZERO
MOVE 08 TO RETURN-CODE
PERFORM TRATAR-ERRO
END-IF
Esses pontos revelam como o programa reage a falhas.
Sétimo passo: descubra quem chama o programa
Ele é executado por JCL?
Recebe comando CICS?
É chamado por outro COBOL?
Consome uma mensagem?
É exposto por uma API?
Nenhum programa existe isoladamente.
Oitavo passo: não altere uma regra sem contexto
Antes de remover um IF estranho, descubra:
quando foi criado;
qual problema resolveu;
quais dados o acionam;
quem depende dele;
quais testes existem.
A linha mais feia do programa pode ser justamente a linha que impede um desastre.
Capítulo 13 — Curiosidades da odisseia COBOL
COBOL nasceu no final da década de 1950, quando a indústria buscava uma linguagem comercial mais portável e compreensível.
Uma figura central nessa história foi Grace Hopper, pioneira na ideia de linguagens mais próximas da comunicação humana e no desenvolvimento de compiladores.
Muitos programas foram escritos numa época em que cada coluna do código possuía significado específico.
O formato tradicional incluía áreas reservadas para numeração, indicadores, conteúdo e identificação.
Daí surgiram marcas culturais conhecidas por programadores experientes, como a famosa coluna 7.
Em ambientes antigos, um asterisco nessa posição podia indicar comentário:
* ESTE É UM COMENTÁRIO
Outro símbolo conhecido era o hífen na coluna de continuação, usado quando uma instrução precisava prosseguir na linha seguinte.
Essas características faziam sentido em cartões perfurados e formatos rígidos.
O COBOL moderno evoluiu muito e oferece formato livre, recursos estruturados, integração e capacidades que os pioneiros dificilmente imaginariam.
Ainda assim, conhecer as origens ajuda a compreender por que certos programas possuem determinada aparência.
É como encontrar uma seção antiga da Discovery One e perceber que alguns painéis foram projetados segundo tecnologias anteriores à missão atual.
Capítulo 14 — Easter eggs encontrados no setor 3270
Há uma semelhança curiosa entre 2001: Uma Odisseia no Espaço e o universo mainframe.
Na obra, o computador HAL 9000 fala com voz calma.
Ele observa tudo.
Ele controla funções críticas.
Todos dependem dele.
No mainframe, o operador também conversa com uma entidade central.
Não por voz, mas por comandos, mensagens e painéis.
HAL poderia dizer:
“Esta missão é importante demais para permitir que você execute esse job sem validar o parâmetro de data.”
Outro paralelo está no monólito.
Na história, o monólito aparece em momentos de transformação da humanidade.
No mainframe, o manual verde aparece no início da jornada do programador.
Ele também representa uma transformação: o momento em que o estudante deixa de ver COBOL como um fóssil e começa a enxergá-lo como engenharia.
E existe ainda o monólito definitivo:
IEF142I JOB12345 STEP01 - STEP WAS EXECUTED - COND CODE 0000
Para o operador, poucas mensagens possuem tanta beleza.
É o equivalente mainframe da imagem da Terra vista do espaço.
Capítulo 15 — Modernizar não é destruir a nave
Uma estratégia madura de modernização pode seguir etapas.
1. Inventariar
Quais programas existem?
Quais arquivos usam?
Quais tabelas acessam?
Quais jobs os executam?
Quais sistemas dependem deles?
2. Medir
Quais programas são mais utilizados?
Quais consomem mais recursos?
Quais causam mais incidentes?
Quais mudam com maior frequência?
3. Documentar
Mapeie regras de negócio.
Registre dependências.
Explique exceções.
Crie diagramas.
4. Testar
Construa testes de regressão.
Capture entradas e resultados conhecidos.
Compare comportamento antes e depois das mudanças.
5. Modularizar
Separe regras.
Reduza acoplamento.
Crie interfaces claras.
6. Expor serviços
Permita que aplicações modernas utilizem funções COBOL por APIs ou mensageria.
7. Automatizar
Integre compilação, testes, análise e implantação em pipelines.
8. Substituir seletivamente
Componentes problemáticos podem ser reescritos.
Mas isso deve acontecer com evidência, não por moda.
Modernização é uma cirurgia na nave em movimento.
Desligar todos os sistemas e reconstruir do zero raramente é uma opção realista.
Capítulo 16 — A geração que precisa assumir o painel
Existe um argumento frequente:
“Os programadores COBOL estão envelhecendo.”
Essa preocupação é real, mas não significa que a linguagem esteja condenada.
Significa que conhecimento precisa ser transferido.
Empresas devem formar novos profissionais.
Programadores iniciantes precisam aprender mais do que sintaxe.
Precisam compreender:
processos empresariais;
arquivos;
processamento batch;
transações online;
integridade;
recuperação;
auditoria;
desempenho;
segurança;
disciplina operacional.
O profissional COBOL não é apenas alguém que escreve MOVE.
Ele é alguém que compreende a relação entre código, dados e negócio.
Um grande programa COBOL pode ser tecnicamente simples e empresarialmente complexo.
Por isso o conhecimento do domínio vale tanto quanto o conhecimento da linguagem.
Capítulo 17 — O que realmente mantém COBOL vivo
COBOL não sobrevive apenas por causa de compatibilidade.
Ele sobrevive por uma combinação de fatores:
Os sistemas continuam cumprindo funções essenciais.
As regras acumuladas possuem enorme valor.
A reescrita completa custa caro e envolve alto risco.
A plataforma moderna continua oferecendo desempenho e suporte.
O processamento empresarial combina naturalmente com os pontos fortes da linguagem.
Sistemas antigos podem ser integrados a arquiteturas modernas.
A continuidade operacional é mais importante do que seguir tendências.
O mercado não preserva tecnologias por caridade.
Ele preserva aquilo que continua entregando valor.
Se COBOL fosse completamente inútil, teria desaparecido há muito tempo.
Sua permanência é resultado de sua utilidade.
Epílogo — Além de Júpiter
Ao final de 2001: Uma Odisseia no Espaço, a jornada não termina numa resposta simples.
Ela termina numa transformação.
O astronauta atravessa o desconhecido e se torna algo diferente.
O programador iniciante também passa por uma transformação quando compreende o COBOL.
No começo, vê uma linguagem antiga.
Depois, vê programas extensos.
Em seguida, percebe arquivos, jobs, transações e bancos.
Mais tarde, enxerga regras de negócio.
Finalmente, entende que o mainframe não é apenas uma máquina.
É uma memória operacional da civilização.
Nele estão registrados salários, seguros, impostos, contratos, contas, benefícios, movimentos logísticos e incontáveis decisões empresariais.
O COBOL permaneceu porque foi construído para esse mundo.
Um mundo no qual os dados precisam fechar.
No qual centavos importam.
No qual auditorias exigem evidências.
No qual sistemas não podem simplesmente “tentar novamente amanhã”.
A pergunta, portanto, não deveria ser:
“Por que COBOL ainda não morreu?”
A pergunta correta é:
“Como uma linguagem criada há mais de seis décadas conseguiu continuar relevante enquanto tantas tecnologias desapareceram?”
A resposta está em sua missão.
COBOL não prometeu mudar o universo.
Prometeu processar negócios com precisão, clareza e confiabilidade.
Cumpriu essa promessa em computadores que já não existem.
Cumpre hoje em sistemas IBM Z modernos.
E poderá continuar cumprindo enquanto organizações precisarem de continuidade, controle e confiança.
Em algum datacenter, o próximo job já entrou na fila.
O JES recebeu a missão.
O programa foi carregado.
Os arquivos foram abertos.
Os registros começaram a atravessar a nave.
No console, uma mensagem aparece:
JOB COBOL001 STARTED
O monólito verde continua de pé.
A odisseia continua.
E o velho programa, silencioso como o espaço, executa mais uma vez exatamente aquilo para o qual foi criado.
BELLACOSA MAINFRAME TEMPORAL SYSTEM
>
INICIANDO CONTAGEM HISTÓRICA...
COBOL
00
ANOS
Uma odisseia temporal desde
1º de abril de 1959
DATA DE ORIGEM
01/04/1959
DATA DO SISTEMA
CARREGANDO...
TEMPO DECORRIDO
CALCULANDO...
SISTEMAS VITAIS OPERACIONAIS
“O código muda. A regra permanece. A missão continua.”
