PowerCOBOL 3.0, lições esquecidas pela Fujitsu
Olá,
há muito tempo queria escrever um artigo sobre o PowerCOBOL, em especial a versão 3.0.
Eu comecei a usar o PowerCOBOL ainda na versão 2, de 16 bits. Para falar a verdade ainda tenho saudades dele. Algumas coisas que a versão 2 fazia fazem falta na 3 como, por exemplo, detectar eventos de labels sobre images.
Mas ainda que a versão 3.0 tenha lá seus defeitos, algumas coisas são memoráveis. Primeiro, o conceito do PowerCOBOL sempre foi único. Todo o compilador foi montado em cima do Cobol-85. Isto permanece verdadeiro até hoje, na versão 11. Apenas o compilador passou a suportar (mais ou menos) Orientação ao Objeto, ao que realmente faz falta na versão 3.0, mas apenas em alguns casos.
O Padrão ANS-85 trouxe alguns conceitos pouco usados, como por exemplo a idéia de transformar todos os programas numa única entidade, com o código fonte de vários programas aninhados num único arquivo, permitindo compartilhar variáveis via cláusula GLOBAL ou EXTERNAL para o caso de módulos executáveis distintos.
Este conceito, pouco usado por desenvolvedores, na verdade é a base do PowerCOBOL e aqui reside a genialidade do produto: Uma janela (pantalla) é o programa principal, tendo como propriedades as seções mais importantes de um programa, incluindo SPECIAL-NAMES, FILE CONTROL, FILE SECTION, WORKING-STORAGE e PROCEDURE.
Cada elemento na pantalla (buttons, labels, tables, images, multimedia etc) se torna uma variável no programa e cada evento de cada elemento se torna um programa. Cada programa é compilado com a palavra-chave "COMMON" ao lado do seu nome. Aliás este é o motivo de não definirmos o nome do programa associado a um evento. O PowerCOBOL define ele pois precisa ter certeza de que sabe quem deve chamar quando o usuário clica num botão.
O modelo tem algumas limitações, sendo a mais óbvia a dificuldade de compartilhar elementos entre .EXE. Não chega a ser incontornável, especialmente nas versòes acima da 4.x, mas é um pouco frustrante.
Outro problema é o fraco suporte a CGI, mesmo nas versão 11.
A versão 3.0 não suporta o modelo de componente do Windows (COM). Isto é uma desvantagem na hora de usar ActiveX, mas uma benção na hora de instalar em um cliente. Simplesmente copie os arquivos juntamente com o runtime e voilá ! Funciona como mágica. Na versão 4 em diante, ao se adota o modelo de componentes da Microsoft, passamos a ser reféns do Registry. Quem nunca teve problemas com versões de DLL ou de instalação de OCXs que atire a primeira pedra.
A versão .Net perdeu a chance de aumentar a popularidade do PowerCOBOL. Bastava a Fujitsu ter dado suporte ao PowerCOBOL como uma alternativa ao WinForms que o produto teria tido uma vida muito mais longa. Talvez estivesse hoje firme como uma alternativa ao VB.Net. Infelizmente a Fujitsu não entendeu o que tinha em mãos e preferiu apostar no WinForms. O PowerCOBOL era sensacional para desenvolver aplicações. Com algumas poucas melhorias (tipo suporte o .Net Framework e o suporte a funções do ISO-2002) teria se tornado imbatível. Não foi o que aconteceu e agora o produto chegou ao fim da carreira, considerado como legado.
Tudo o que a Fujitsu precisava era OUVIR seus clientes (nós). Delegou o suporte para a Alchemy, que apesar da boa vontade estava claramente preocupada com sua sobrevivência e não em se tornar um canal entre o mundo e a Fujitsu.
Muita gente abandonou o Cobol depois que chegou à conclusão (correta) de que não valia a pena migrar do PowerCOBOL para o NetCobol.net. Muitos, atraídos pela facilidade, adotaram o WinDev. Desejo sorte. Eu teria ido para Java ou mesmo Swift. O tempo dirá se tenho razão.
Saludos, Emerson
|