Barrapunto

solo una cosa... ODIO COBOL nunca trabajaré haciendo software en cobol!!!

...de madrid aprendia yo mis primeros pasos en esto de la informática; y lo hacia con Ms-Dos y con un compilador en modo linea de comando llamado IBM Cobol 1.0 que se componia creo recordar de 7 ficheros nada más.

No era fácil no señor...Empieza en la columna 8...ahora en la 12...no te pases de la 72...DATA DIVISION...PERFORM VARIYING...Ayyyy !!! que recuerdos (suspiros...). Volviendo a la actualidad, han pasado como 12 años (o mas macho o más vete tu a saber) y el panorama programatorio ha evolucionado lo suficiente como para decir que COBOL, por mucha evolucion que haya sufrido, que la ha sufrido sin duda (por mi mano paso un dia una demo de una herramienta Visual-RAD-noseque de COBOL) es un lenguaje obsoleto desde casi todos los puntos de vista por donde se le mire: desde el paradigma de programacion (¿ Procedural con procedimientos a medias sin parametros ni na de na?, ¿Declarativo, porque te declaras en huelga a las tres horas de haber empezado a picar?...¿Orientado a columnas ;-) pasando por la estructuracion inexistente y llegando a la ausencia completa de mecanismos que le doten de la capacidad de afrontar un programa normal y corriente, sin tener que escribir 20 bobinas de lineas de código...

Tampoco pasa nada si se deja a COBOL en su baul, al fin y al cabo no hay que empeñarse en recuperarlo, porque este cumplio su función y muy bien en sus tiempos, y claro, no esta pensado ni mucho menos para éstos.
Tampoco es que sea yo un gran experto en COBOL la verdad, pero no deja de ser un, porque no decirlo queridos barrapunteros enemigos de .NET, magnifico ejercicio de integracion y demostración del paradigma .NET

Todo esto salvando las alambradas de Vaporware.

Ya, pero quedan aún tantos millones de líneas de código COBOL rulando por ahí ... tantos y tantos programas ...

    Hace un par de años (no es mucho tiempo) migré una pequeña parte del software de gestión de una muy importante empresa española de COBOL a C (por cierto, pagaron muy bien :); me consta que aún tienen el 80 ó 90 % en aquel lenguaje.

 

Una empresa moderna ... pasó de un lenguaje de los 60, a uno de los 70 ;)

En todo caso, ya hablamos de NetCobol en COBOL y Linux, cuando pensaron en ampliar su uso a Linux. ¿Alguien sigue el proyecto?

Mal que pese a los que hayamos trabajado alguna vez con Cobol, este lenguaje seguirá dando guerra durante mucho tiempo e incluso hay diez razones por las cuales Cobol es estupendo. Quizás este prometedor futuro es el que haya motivado que Microsoft apoyara el soporte de cobol en la plataforma .NET.

Bromas aparte, en la actualidad existen muchas entidades que realizan sus gestiones con programas de millones de líneas de código, escritas en Cobol, y que han sido probados, mantenidos y corregidos durante más de 30 años. Reescribir estos millones de líneas de código supone no sólo un enorme inversión, sino que implica el riesgo inherente a empezar con nuevas aplicaciones, realizadas con tecnologías más modernas, que no tienen un periodo de pruebas tan amplio. Para determinadas entidades, un mínimo error de programación puede suponer pérdidas de miles de millones (sí, de euros también). Y, que yo sepa, aún no es posible demostrar de forma suficiente y necesaria, la corrección de un programa (aunque algo se está avanzando a este respecto, al menos desde el punto de vista matemático, con la demostración automática de teoremas (pdf) y la verificación de programas (software)).

¿Cómo está el tema del COBOL en para equipos como los S/390, los herederos del AS/400, etc?.

Supongo que podrá trabajarse en muchos lenguajes, especialmente porque estas máquinas pueden funcionar con Linux, además de su SO propietario, pero ¿se sigue desarrollando/manteniendo todo esto en Cobol, RPG y demás?.

Yo sigo aún viendo anuncios de trabajo que piden esto.

Sí, aún se siguen viendo anuncios de Cobol, y no pocos, como ya se habló en Barrapunto.

¿se sigue desarrollando/manteniendo todo esto en Cobol, RPG y demás?

Una respuesta a tu pregunta la puedes encontrar en tecnoempleo, donde hay más de 160 ofertas de empleo que requieren cobol en diversas plataformas.

Que no está tan muerto como a algunos les gustaría.

Y eso a pesar de que las máquinas actúan sobre todo como servidores de teleproceso y pueden funcionar con Linux.

Con todo lo dinosáurico que es, hace ya tiempo que COBOL dejó atrás muchas de estas restricciones. Desde el estándar del 85 el formateo por columnas es opcional. Desde el estándar del 80 se puede prescindir totalmente del GOTO (tienes todas las construcciones de programación estructurada: PERFORM...END-PERFORM, IF...END-IF, EVALUATE...WHEN...END-EVALUATE) y es posible programar procedimientos con paso de parámetros (aunque no sea muy bonito) ;). Además, todo el rollo de la IDENTIFICATION DIVISION (exceptuando el PROGRAM-ID, que define el nombre externo del programa) es considerado como comentario (y es en su mayor parte opcional).

No soy un fanático de COBOL (en el curro uso PL/1 y ensamblador), pero desde luego para tratar FICHEROS es el mejor lenguaje que existe. Claro que en aplicaciones modelnas el uso de ficheros es muy limitado (es más cómodo gastar MIPS en un SBGD y trabajar con SQL), pero en desarrollos antiguos (y no tan antiguos, sobre máquinas de tipo mainframe) siguen estando vigentes.

Desde luego no tiene sentido usar COBOL para escribir un "Hello world!", pero si tienes que combinar dos o más ficheros secuenciales, con diferentes tipos de registro, ordenaciones y tratamientos más o menos complejos, escribirás menos en COBOL que en C, java o cualquier otro lenguaje similar (con la posible excepción del PL/1).

Aunque, desde luego, por muy bueno que sea SIGUE DOLIENDO ;)

Y si alguien se queja del Cobol que me avise y le presento al ensamblador de MVS... eso si que es un infierno.... y hay bancos (muy importantes) que todavía lo están usando... esos si que suspiran por el COBOL!!!!

Jejeje... no es tan fiero el león como lo pintan. El assembler del S/390 tiene sus cosillas chungas (sobre todo el modo de direccionamiento que usa, basado SIEMPRE en un registro, con un desplazamiento máximo de 4K), pero es menos asqueroso que el de x86 (aunque eso no es muy difícil ;)).

Desde luego, no se usa para codificar aplicaciones. Se usa cuando tienes que meterle mano al sistema o al middleware (las famosas EXIT: lo que en otros entornos llamaríamos "callbacks"), o para codificar rutinas de utilidad en las que el rendimiento es crítico (pensad en una rutina de conversión de fechas que se ejecute varios millones de veces al día...).

Eso sí, si comparamos COBOL y PL1 desde luego no hay color. PL1 es un lenguaje de aspecto moderno, con algunas herencias curiosas del FORTRAN (la declaración implícita de variables y los formatos de edición), pero tiene todo lo que tiene que tener un lenguaje estructurado (tipado semifuerte, procedimientos y funciones con variables locales y paso de parámetros, manejo de excepciones, etc...)... todo un mérito si se tiene en cuenta que es un lenguaje de los 60! :) También permite hacer guarradas a nivel de sistema (puede manejar punteros y hacer cositas muy divertidas con memoria dinámica) y, de hecho, se usó para codificar MULTICS (el legendario antecesor de UNIX). Los que tengais curiosidad por la historia de MULTICS, o por la retrocomputación en general, podeis visitar esta página. Es una lectura interesante ;)

 

Si que le veo utilidad en ese sentido. Quizá sea una forma eficaz de traducir los programas 'legacy' en COBOL.