Barrapunto

Y si no, si basta con soporte de COBOL 85, se podría intentar con TinyCOBOL, que es libre, gratuito, multiplataforma (BeOS, FreeBSD, Linux, Windows)...

El compilador trata de ser completo, ojo. El "Tiny" viene de cuando era un compilador para DOS :-)

nuestra empresa se dedica a instalar ordenadores con una aplicacion en cobol, bajo redhat. No es que sea mi lenguaje favorito, ni mucho menos, pero reconozco que hay aplicaciones enormes que no hace falta portar a otro lenguaje, si aun estan rulando. A parte que cobol no chupa un puto recurso, y tira en maquinas que la verdad, hay que verlo para creerlo. Y conozco mas aplicaciones y empresas que estan instalando cobol o cosas mas antiguas, sin problemas.

Lo que flipé yo en su momento son los ficheros indexados que tiene, y como se lo monta para mantener cantidades ingentes de información convenientemente indexada, y estamos hablando del 85 ;-)

En mi empresa llevamos años trabajando con COBOL bajo Linux. Las mismas aplicaciones que teníamos antes corriendo en un SCO funcionan sin problemas en Linux gracias a la compatibilidad vía iBCS.

Usamos tanto aplicaciones hechas con MicroFocus como aplicaciones hechas con RM-Cobol85. Los dos funcionan perfectamente y no han dado ni un solo problema durante años.

Como decía el comentario anterior, no consume nada de recursos y, si funciona, ¿para qué quieres pasarlo a un lenguaje más moderno?

El modelo cliente-servidor, la programación orientada a objetos... son cosas que existen en el COBOL desde hace ya muchísimo tiempo. Por otra parte en los grandes ordenadores o 'mainframes' que se utilizan en bancos y cosas de ese estilo (tipo S/390 ó AS/400) el lenguaje principal que se suele usar es el COBOL, así que al venerable COBOL le queda cuerda para rato, mal que le pese a algunos :)

En la empresa para la que estoy trabajando actualmente, tienen varios sistemas (en desarrollo actualmente!!!) realizados en Cobol.

Realmente no creo que sea justificable en pleno siglo XXI el encarar la implementación de un sistema en este lenguaje realmente obsoleto (piensen, por ejemplo, en el modelo cliente/servidor).

Por ejemplo: Los sistemas a los que hago referencia estan programados en ACU-Cobol, una versión de Cobol "multi-plataforma". Ocurre que actualmente se ejecutan en máquinas con Windows, que montan los archivos desde un fileserver. Inicialmente se usaba como fileserver un Windows NT 4.0 (y ya tenían problemas), y al migrarlo a un Samba 2.2.x nos hizo renegar terriblemente (al punto de no haber podido solucionar todos los inconvenientes) con problemas de locking. De más está decir que la performance del sistema es HORRIBLE (20 terminales montando el sistema desde un fileserver y haciendo consultas enormes) y todos estos problemas no se presentarían si se hubiera diseñado un sistema cliente-servidor (aunque viene un engendro para hacer a Acu-Cobol funcionar de forma similar a esto...).

En fin... solo quería comentar la experiencia ;)

Eso les pasa por usar algo que no fue pensado para cliente servidor. Creo que lo mejor es pasar los programas cobol con ficheros a un cobol son acceso a una base de datos, el sistema de ficheros de Cobol ya me parece un poco añejo, por el costo de mantenimiento que tiene y la dificultad que hay cuando se necesita integrar con nuevas funcionalidades.<p><p>
Alguien tuvo la genial idea de asignarme hace un tiempo a un proyecto donde trabajaban con Cobol RM y ficheros indexados, fue una tortura, porque las necesidades eran muchas y el costo de construir sobre esa plataforma es enorme, comparada con otras. Si hubieran migrado los archivos a BD, la cosa hubiera sido diferente...

Porquería total joder, claro que no consume recursos, porque son todo moves, es casi ensamblador

Por otra parte es flipante lo que hacen algunos para mantener su base de aplicaciones COBOL rulando por ahí. Patagon, sin ir más lejos. Cuando haces cualquier operación, el servidor web llama a los programas en COBOL que corren en el mainframe. Yo comprendo que si a ellos les van bien así lo hagan, pero desde el punto de vista del programador es para pegarse un tiro.

Lo que dice el asunto: 'a veces no te queda más remedio'. Yo he trabajado con Cobol muchos años. Y no me gusta. Para el programador es un auténtico suplicio. Pero funciona.

Y no es sólo el hecho de que funcione. Si se sigue usando es porque hay muchas (muchííísimas) aplicaciones corriendo en Cobol y que no se pueden parar.

No conozco tu empresa ni sé qué sistemas se están desarrollando actualmente. Pero seguro que si se están haciendo en Cobol es porque tendrán alguna relación con aplicaciones actualmente en funcionamiento hechas en Cobol, o tienen que leer de los datos de esas aplicaciones. ¿o no?

Me dirás que es mejor hacerlas nuevas. Pues sí: Es mejor hacerlas nuevas. ¿Vas a pagar tú al equipo de programadores que hace falta para eso? Porque tu empresa sólo puede pagar a UN equipo de programadores. Y ya están ocupados manteniendo una aplicación y haciendo que siga funcionando día tras día. ¿Les decimos a los usuarios que no trabajen durante un par de añitos para que hagamos una aplicación nueva? ¿se lo decimos al jefe, que cierre la empresa unos meses?

En mi empresa teníamos una aplicación de Gestión Comercial y Contabilidad corriendo en Cobol. Me propuse hacer una nueva, cliente/servidor hecha en Delphi o similar, pero me tiraba más tiempo arreglando/ampliando la aplicación antigua que trabajando en la nueva. Al final, llegó el 2000 y el Euro y no quedó más remedio que comprar una aplicación estándar. ¿el resultado? pues que todos los usuarios se quejan de lo lentísimo que es el sistema ahora, comparado con lo rápido que iban ellos antes con sus pantallas negras en modo texto (un telnet al servidor para ejecutar la aplicación Cobol).

Actualmente estoy desarrollando la aplicación esa en Delphi para desechar la que compramos hace tan solo dos años.

En cuanto a los problemas que tienes con esa aplicación en ACU-Cobol, no se los debes achacar al ACU-Cobol, sino al hecho de que son 20 programas (en cualquier lenguaje) abriendo archivos de un 'fileserver'. Los bloqueos con ese sistema son inevitables. No quieras pensar lo que pasaría si fueran programas en VisualBasic abriendo archivos Access..... (por experiencia)

En fin. Que no me gusta el Cobol (como a tí). Pero que comprendo que hay veces que no hay más remedio que usarlo.

Casi ensamblador?? xDDD qué axagerao macho. Hablando en serio: sí, es cierto, que tiene algunas estructuras bastante arcaicas (los MOVES esos son una putada), pero como lenguaje es de los de más alto nivel que he visto (y eso teniendo en cuenta que es de los años 50), sobre todo en cuestión de manejo de ficheros, indexados, etc... De hecho el COBOL se hizo para que pudieran utilizarlo "no-programadores" (en toería claro).

Yo no tengo mucha experiancia en cuanto a lenguajes pero no he visto ningún lenguaje que maneje con tanta facilidad los ficheros, lo mismo es que estoy obsoleto yo también...

Solo comentarte dos cositas:

1) que los sistemas "funcionen" no significan que lo hagan de forma razonablemente eficiente (y robusta).

2) La principal razon por la que esta empresa tiene sistemas en Cobol fue por la excelente fuerza de venta de un programador que "SOLO" conoce Cobol... nada mas.

3) Lo de la "porqueria" de Cobol fue en tono de chiste. No hay por que achacarle a un Ford T que no pueda competir con una Ferrari. Hay que reconocerle a Cobol los meritos que tuvo al aparecer alla por los 60. Pero.. usarlo hoy en dia?

Puedo comprender que a alguien acostumbrado a programar en cualquier otra cosa, le cueste un ... programar en COBOL. También a mí me costó el otro abandonarlo.

Pero desde que salí de COBOL, he pasado por C, PL/SQL, algo de Java, algo de PHP, y alguno más que por ahí se ha colado.

Y tengo que decir que para gestión comercial (por cierto, la C de cobol significa comercial), es el mejor lenguaje que se ha inventado.

De entrada, es cierto que para alguien acostumbrado a las bases relacionales, los ficheros indexados son un martirio. Pero para eso existe el sql embebido en cobol (pro*cobol, como el pro*c). A cambio, los rendimientos y las necesidades de máquina con los ficheros cambian co mo del día a la noche.

En segundo lugar, es cierto que todos son moves y similares. Con lo cual es mucho más facil seguir la secuencia exacta de un programa para saber donde se ha metido la gamba. No se presupone nada de ninguna función (si no se quiere): se lee lo que pasa.

En tercer lugar, os recuerdo que los programas no son PARA el programador, sino para el usuario, y cuando te empiezas a juntar con unos cientos de usuarios, lo del rendimiento, consumos de recursos y todas esas pequeñas tonterías el que las "paga" no es precisamente el programador.

Y a partir de ciertos tamaños empieza a no ser cierto que es más barato incrementar la máquina que corregir el programa.

¿O me vais a decir que es más fácil hacer un ERP o una aplicación de gestión de un almacén de 5000 m3, o una aplicación de gestión de recursos humanos, como ejemplos, para una gran empresa en C++ que en COBOL? Si me decis eso, o habéis hecho pocas, o os habéis complicado demasiado la vida en COBOL. Vosotros mismos.

¡Ah!, lo del casi ensamblador, lo siento, pero entre la altura de lenguaje del COBOL y la del C++ ...

Particularmente lamento que en mi empresa (entre otras cosas por decisión mía) estamos abandonando el COBOL por otros lenguajes más modernos... que la verdad, aún tienen que demostrar que son más rentables para la empresa. Y lo que tampoco puedo es ir contracorriente, me guste o no.

Bueno, pues eso.