20 Anos em Formação, GnuCOBOL Está Pronto para a Indústria

Maturidade e Conformidade com Padrões do GnuCOBOL

• É visto como “pronto” em grande parte por causa da estabilidade e da alta conformidade com COBOL‑85 (~97% dos testes aprovados).
• Comentadores observam que mesmo muitos COBOL proprietários nunca atingem conformidade total com o padrão.
• Usa GNU MP para aritmética para corresponder ao comportamento tradicional de precisão fixa do COBOL, em vez de floats IEEE‑754.
• Não possui recursos mais novos do COBOL, como objetos e mensagens de padrões recentes (por exemplo, COBOL 2022/2023).

O Papel do COBOL nos Sistemas Atuais

• A maior parte do COBOL em produção está em mainframes IBM, fortemente acoplada com JCL, bancos de dados (DB2, IMS, DMS) e monitores de transação (CICS, ACMS).
• Também é comum em plataformas não IBM: OpenVMS, OS2200, vários sabores de Unix e x86/Linux com fornecedores como Micro Focus.
• É amplamente usado em finanças, folha de pagamento, faturamento, ERP e outras cargas de trabalho de back office “chatas, mas críticas”.

Mainframes vs. Nuvem e Confiabilidade

• Mainframes são descritos como projetados para disponibilidade de “cinco noves”, com redundância extrema e tempo de inatividade muito raro.
• As interrupções sofridas por bancos são frequentemente atribuídas à infraestrutura de servidores ao redor, não ao núcleo do mainframe.
• O “cinco noves” da nuvem é criticado como sendo em sua maior parte um SLA de cobrança/crédito, não uma operação realmente contínua.
• Alguns relatam ambientes de mainframe que, na prática, são frágeis, então as alegações de confiabilidade não são universais.

Migração, Ecossistema e JCL

• O GnuCOBOL é visto como apenas metade da história de uma migração: ainda é preciso JCL, monitoramento de transações semelhante ao CICS e bancos de dados no estilo mainframe.
• O JCL é considerado essencial para batch; o REXX é frequentemente usado para gerar JCL em vez de substituí-lo.
• Muitas tentativas de migração (incluindo transliteração de COBOL para C) são descritas como dolorosas ou resultando em sistemas difíceis de manter.
• Reescritas modernas fracassadas ou repetidamente retomadas de sistemas COBOL são citadas como um padrão comum.

Correção Numérica e “Matemática do Dinheiro”

• A aritmética decimal e a precisão fixa do COBOL são fundamentais para sistemas financeiros.
• Portar para linguagens que, por padrão, usam ponto flutuante binário é arriscado; equivalentes corretos (BigDecimal etc.) existem, mas não são idiomáticos e podem ser lentos.
• Esse comportamento matemático é uma das principais razões pelas quais organizações hesitam em sair do COBOL.

Características da Linguagem e Experiência do Desenvolvedor

• COBOL é verboso e orientado à definição de dados, mas muitos o consideram direto para o domínio a que se destina.
• Layouts estáticos fortes de dados (cláusulas PICTURE) evitam estouros de buffer e corrupção de memória; a memória é definida explicitamente, não alocada dinamicamente.
• As partes difíceis têm menos a ver com sintaxe e mais com a complexidade do domínio e com as ferramentas de mainframe.
• Há desenvolvimento novo de COBOL em andamento, embora de nicho, muitas vezes como parte de plataformas maiores de ERP ou legadas.

Por que o COBOL Legado Persiste

• Regras centrais de contabilidade, folha de pagamento e finanças mudam lentamente; os sistemas existentes incorporam décadas de legislação, acordos sindicais e casos extremos.
• Muitas vezes não existe fora do código em execução um conjunto completo de requisitos atuais; o sistema é, na prática, a especificação.
• Mudanças incrementais em COBOL são mais baratas e menos arriscadas do que reescritas completas, especialmente quando ninguém entende totalmente toda a lógica de negócio.
• Muitos sistemas “antigos” são navios de Teseu: fortemente modificados ao longo do tempo, mas nunca substituídos de forma fundamental.

Perspectivas de Adoção e Ceticismo

• Entusiasmo pelo GnuCOBOL como compilador gratuito, orientado a padrões, e potencial ferramenta de migração.
• Ceticismo de que grandes ambientes de mainframe trocarão de plataforma devido a restrições regulatórias, lock-in de ecossistema e aversão a risco.
• Alguns duvidam que muitos projetos greenfield escolheriam COBOL hoje; a maioria espera que ele permaneça uma linguagem de manutenção e mudanças incrementais.