PauloMotta.pro

Essa semana um aluno me perguntou por email se eu conhecia algum editor para trabalhar com COBOL, não lembrei de imediato, mas depois de um tempo me veio a mente um evento que participei da empresa Micro Focus (de quem não estou ganhando nada para falar aqui…) apresentando um produto que permitia integrar programas COBOL com aplicações Java e .Net, inclusive rodar o programa em baixa plataforma.

Eu nunca usei o produto, até porque nem tenho programas em COBOL, mas é uma alternativa interessante para quem precisa manter aqueles programas do legado e quer mais facilidades. Lembro que nos meus tempos de EDS havia um grande buzz em torno do conceito de Application Modernization (modernização de aplicações) foram inclusive considerados produtos que permitiam avalizar o fluxo de chamadas entre módulos de programas COBOL para poder identificar o que eram regras de negócio e o que precisava realmente ser abandonado.

O fato que ninguém quer assumir é que não dá para jogar fora programas com 30 anos de execução, que você SABE que funcionam pelo simples fato de estarem rodando há tanto tempo. Tentar reescrever muitas vezes é a receita para o desastre porque você terá que revalidar as novas aplicações e garantir que está tudo certo, mas não temos hoje nenhum método ou ferramenta de teste que garanta 100% de cobertura de testes, mesmo que tal ferramenta existisse, seria impossível garantir que todos os casos de teste foram pensados. Ao longo dos 30 anos de existência aqueles programas COBOL foram testados, corrigidos, modificados e isso é uma coisa que só com o tempo para garantir a estabilidade.

A própria IBM investiu em um caminho contraditório, disponibilizou para mainframe (plataforma Z/OS) o Websphere e o Java de forma que você pode dentro do seu programa COBOL (que funciona há 30 anos) fazer uma chamada para um novo componente EJB feito em Java, pode também encapsular seu módulo COBOL em um EJB e expor para o mundo via WebService. Aí você pensa “duvido! isso não funciona!” mas nesse caso eu posso dizer que funciona porque trabalhei em um projeto assim na EDS, aliás meu último projeto por lá. O único inconveniente (não sei como está agora) é que a própria IBM não tinha muita experiência nesse tipo de integração então algumas dúvidas ficavam muito perdidas. Uma das coisas que foi legal de descobrir futucando manuais,  experimentando e lendo código fonte de outras plataformas é que essa integração (do Enterprise COBOL 4.3 ou superior) com o Java é feita via JNI (Java Native Inteface) então quando você quer referenciar no COBOL uma classe Java precisa fazer isso usando “/” como separador de pacotes ao invés de “.” para ficar mais claro:

java/lang/String ao invés de java.lang.String

Mas fora isso funcionava bem direitinho.