[Noticia] PowerCOBOL v11 - ¡¡¡Sí que existe!!!

[Kuk]

Yo creo que PowerCOBOL es un producto único en su clase. Es decir, un IDE que es RAD con GUI para COBOL. Está también el Dialog System de MicroFocus, aunque no sé si sigue incluido en el nuevo Visual Cobol (el NetExpress ya está descatalogado).

Yo creo que, si querían dejar de utilizar Activex y pasar al Framework .NET, deberían hacerlo dejando la esquemática actual de PowerCOBOL sustituyendo la tecnología. Sería un producto nuevo, pero al menos bastante familiar en cuanto al modus operandi.

❞ Yo modestamente lo he intentado por todos los medios, pero es imposible.

Has intentado convencer a tu empresa para que se quede con PowerCOBOL?

❞ si de hecho el cobol .net lo van a tener que traducir al universal de .net

Puedes explicar esto bien? Yo nunca he trabajado con .NET y no lo conozco.

❞ ya decidimos pasarnos a .NET pero con C#

¿Por qué esta decisión, por qué .NET y no otra cosa?

[Nitzer]

Hola Kuk, te respondo

❞ Empezado por Nitzer Ver Mensaje Yo modestamente lo he intentado por todos los medios, pero es imposible. Has intentado convencer a tu empresa para que se quede con PowerCOBOL?

Hace años que hablaba con Fujitsu en Estados Unidos, de hecho me regalaron una caja con el producto que guardo (version 5), e intentaba convencerles de que tenían un producto maravilloso. Nombraron a un responsable para España y me invitaron a Madrid a sus instalaciones. Pero curiosamente al poco tiempo, después de bastantes avances, lo despidieron y nunca mas se supo de esa área.
Intente ser distribuidor con otra persona (no sabía que existía ADAMED) pero sus condiciones eran penosas y se notaba que les daba igual el producto, de hecho me reconocieron que ellos con las ventas de EEUU tenían suficiente, les daba igual el resto del mundo.

❞ Empezado por Nitzer Ver Mensaje si de hecho el cobol .net lo van a tener que traducir al universal de .net Puedes explicar esto bien? Yo nunca he trabajado con .NET y no lo conozco.

No soy experto en .NET, pero según entiendo lo que ha hecho Microsoft es crear un entorno común en el que se pueda programar en cualquier lenguaje y al compilar todos generan un .exe exactamente igual. Pasando por un lenguaje que llaman intermedio y sobre el cual se compila realmente.
Por eso digo que podían haber dejado perfectamente igual el PowerCobol en .net y entonces todo habría sido diferente.

❞ Empezado por Nitzer Ver Mensaje ya decidimos pasarnos a .NET pero con C# ¿Por qué esta decisión, por qué .NET y no otra cosa?

Ahora estamos 3 personas en el departamente y ellos conocen bien .net y como todo lo que tenemos es Microsoft, pues hemos elegido esa opción.
Habiamos intentado con Velneo y con Windev, pero al final nos hemos decantado por .NET

[Kuk]

❞ Hace años que hablaba con Fujitsu en Estados Unidos, de hecho me regalaron una caja con el producto que guardo (version 5), e intentaba convencerles de que tenían un producto maravilloso. Nombraron a un responsable para España y me invitaron a Madrid a sus instalaciones. Pero curiosamente al poco tiempo, después de bastantes avances, lo despidieron y nunca mas se supo de esa área. Intente ser distribuidor con otra persona (no sabía que existía ADAMED) pero sus condiciones eran penosas y se notaba que les daba igual el producto, de hecho me reconocieron que ellos con las ventas de EEUU tenían suficiente, les daba igual el resto del mundo.

¡Ostras! Sí que has llegado lejos en el asunto, me quito el sombrero
Lo que no sabía es que el producto se desarrollaba en EEUU. Porque Fujitsu es japonés, y como las primeras versiones que salen son en japonés, pensé que el desarrollo se hacía en Japón.

Estoy totalmente de acuerdo contigo, en que es un producto muy bueno. Lo que pasa es que como en el mundo lo que manda es el dinero, y COBOL como nunca ha sido orientado a aplicaciones pequeñas ni multipropósito, la orientación de las compañías que producen este tipo de productos es más que nada hacía las grandes empresas y grandes máquinas. Con lo cual, el hincapié se hace sobre la productividad de tratamiento de datos. Fujitsu tiene un compilador para Linux, pero no tiene IDE para Linux, se trabaja sea en línea de comandos, sea por vía NetCOBOL Studio basado en Eclipse que tiene para Windows en remoto. MicroFocus tiene Eclipse para Linux, pero claramente sin desarrollo de GUI. Hay una tendencia actualmente de migrar grandes plataformas z/OS con Mainframe a Linux. El caso es que como COBOL se utiliza más que nada en estas grandes plataformas, el GUI (además uno que no es Cross Platform sino sólo para Windows) interesa poco...

Yo hace tiempo que estoy pensando en crear un IDE moderno basado en el compilador de PowerCOBOL 3 que es Freeware. He intentado modificar el propio PowerCOBOL 3 y he tenido avances, pero por desgracia no lo he conseguido porque con código decompilado, con nombres de variables y funciones aleatorios, es más que complicado seguir el hilo del programa. Si quieres puedes mirar mis avances aquí: [Compilador] Añadir más controles a PowerCOBOL v3 - COBOL Foro. He escrito un mail a FUjitsu Japón pidiéndoles que me pasen algunos fuentes del PowerCOBOL 3 pero han pasado olímpicamente de mi (cosa bastante normal )

Entonces, he empezado a hacer pruebas con el compilador (cobol.exe y cobol32.exe) para ver qué tal andaba. Tiene bastante buena pinta. Lo malo es que Fujitsu no acepta variables BY VALUE en la LINKAGE. Así que si llego a hacerlo un día, habrá que crear una capa en C para este tipo de tratamientos. Pero la idea me parece interesante. Si se llega a hacer algo estable y bastante rico en controles visuales, podría llegar a ser un proyecto. Además manteniéndose por mi y otras personas que estuvieran interesadas, se podría dar vida al asunto durante años proporcionando modernizaciones y adaptaciones a los Windows SO nuevos.

[Dasije]

De estoy de acuerdo, PowerCOBOL ha sido un buen producto, pero por lo visto no va a ser eterno, no es algo que yo diga, sino que el mercado se está adaptando a las nuevas tecnologías, y COBOL se quedará para el desarrollo de aplicaciones de servidor.

Aunque que, los fabricantes intenten "vendernos la moto", siempre hay una herramienta mejor para la presentación de pantallas, tecnología más actual, etc, siempre han tirado hacía abajo, pero por su "nicho de mercado" en el que se mueven: aplicaciones de negocios.

[Eslopes]

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

[Joseg]

O Fujitsu Cobol .Net é um autentico tiro no pé. Powercobol era um excelente compilador para Windows, mas sem suporte para Windows forms é para esquecer. O nosso caminho foi pelo uso do Windev/Webdev, não estamos nada arrependidos pela rapidez/possibilidades no desenvolvimento de soluções, que não conseguimos com Java ou mesmo Visual Studio (nossa opinião).

[JuanJuan77]

Hola,

Como puedo obtener la clave del rar. Alguien la tiene?

gracias

[Dasije]

JuanJuan77, Dudo que puedas conseguir la contraseña del rar con fuerza bruta, solo le envían la contraseña a aquellos clientes que hayan comprado el paquete.

Hola a todos,
Represento a los responsables de NetCOBOL para España y otros paises de la U.E. y de habla hispana.
Podeis contactar conmigo para vuestras preocupaciones sobre NetCOBOL PowerCOBOL etc.
No son los mismos productos y cada cual ofrece sus inconvenientes pero lo mejor es aprender Orientación a Objetos y no a Eventos como PowerCOBOL y para ello se ha creado NetCOBOL para .NET que tiene otras muchas ventajas como acercar todas las nuevas tecnologías a COBOL.

Saludos a todos,
Luis

[Dasije]

Hola Luimarat

Estuve apunto de comprar PowerCOBOL, pero me echó mucho para atrás, viendo la innovación tecnologica de la herramienta, se quedaba muy atrasada a las necesidades del mercado, y probando otras herramientas de desarrollo mejores me desconté por completo.

Compré Windev, necesitaba integración total, y esta herramienta si lo cumple, aprendes un lenguaje y te sirve para todo, aunque en el fondo lo compila a lenguajes de otro nivel como Android, Apple, Java, .NET y desarrollo web (AJAX y HTML), excepto WLenguaje es más puro para la plataforma Windows y Linux.

Estoy contento con el resultado, lo tienes todo lo que necesitas en el desarrollo diario, de momento no he tenido que conseguir nada fuera, siempre habrá que extenderse al exterior, pero sería mínimo.

Conozco muchas empresas que desarrollaban en PowerCOBOL y se han pasado a Windev, pero por desconocimiento sobre su futuro, no daba garantías de que hubiera una plataforma en 64 bits para el futuro, implicaba un riesgo dejarles tirado y tener que volver a programar en una solución que quizás no les gustaran, en Windew este problema está resuelto, puedes crear varias configuraciones para compilar por separado, sin tocar el código tanto para 32 como para 64 bits.

El COBOL se está muriendo, y lo sabes, solo por el hecho de que solo se quedará para aplicaciones de servidor o de terminal, por un lado por no innovar y por el otro llegar muy tarde.

Nitzer