En la entrada anterior os describí someramente cómo son los grandes mainframes de IBM; en entradas sucesivas os volveré a dar la tabarra sobre el software cuando corresponda…
Pero en ésta de hoy me centraré en otro cuasi-desconocido (y, en este caso, incluso denostado) protagonista del mundo de la informática: El Lenguaje COBOL. Porque en 1980, igual que ahora, el lenguaje por antonomasia en que se programaban los mainframes de IBM es, sobre todo, Cobol.
Bueno, no es en realidad tan desconocido, puesto que da trabajo a muchos profesionales para escribir o mantener Aplicaciones escritas en este lenguaje, pero sí que lo es, y de qué manera, para los estudiantes de informática de todas las Universidades y Escuelas. Por lo que yo sé, en ninguna se estudia, ni siquiera se suele citar al hablar de lenguajes de programación.
Y es que el Cobol, más que un lenguaje, es casi una filosofía de vida. Ehh, bueno, vale, no tanto, me he dejado llevar por la emoción, o más bien por la nostalgia de los años que llevo sin programar…
Cobol (COmmon Business Oriented Language) se definió en 1960 (hace casi cincuenta años), de la mano del todopoderoso DoD (Departament of Defense de los Estados Unidos). Básicamente, porque estaba harto (¡ya entonces!) de que cada sistema que compraba o subcontrataba viniera escrito en un lenguaje diferente, casi siempre ensambladores que dependían de la máquina, como el caso del NEAT/3 en NCR, lo que originaba grandes gastos para mantener dichos sistemas heterogéneos funcionando.
Grace Hopper: inventora de Cobol y, muchos años después, Contraalmirante de la US Navy
Así que, ni corto ni perezoso, el DoD participó activamente en el diseño e implementación del nuevo lenguaje, proceso que duró menos de un año, y obligó (no inmediatamente, pero sí en el curso de unos pocos años) a que todos los sistemas (de gestión, naturalmente) que se instalaran en el DoD estuvieran escritos en Cobol.
Este comité, que se constituyó dentro de CODASYL, tuvo como alma mater a Grace Hopper, a la sazón trabajando en la US Navy de los Estados Unidos, y diseñadora de Flow-Matic, lenguaje del que Cobol aprendió mucho.
Tras toda su vida en la Marina, Grace Hopper se jubiló finalmente como ContraAlmirante de la Armada, siendo seguramente la única mujer en la historia en llegar a ese rango, como contribución a toda una vida dedicada a la informática, que tanto la debe, incluyendo el concepto de bug, que ella acuñó buscando insectos entre las entrañas del UNIVAC. Incluso hay una nave de la Marina estadounidense bautizada con su nombre, compartiendo con ella el sobrenombre de “Amazing Grace”, que también a ella se le daba.
Ada Lovelace, uno de los primeros informáticos
Por cierto, veintitantos años más tarde, el DoD hizo de nuevo la misma operación con Ada, nombre dado en honor a Lady Ada Lovelace, discípula de Babbage y no sólo la primera mujer “informática”, sino, definitivamente, uno de los primeros informáticos. A diferencia del Cobol, Ada nunca fue un lenguaje muy utilizado, al menos en el mundo comercial; parece que el DoD dejó de exigir sistemas programados en Ada en 1997. Claro que, si le hubieran llamado Grace, igual triunfaba… ¡pues no era nadie, la Señora Hopper!
Todos los fabricantes implementaron más o menos rápido el lenguaje Cobol, y su conocimiento se extendió rápidamente por los EEUU (el Departamento de Defensa era con mucho el principal contratista, y lo siguió siendo muchos años), y poco después por todo el mundo occidental.
El hecho de que se pudieran programar en Cobol fue utilizado (con éxito) en aquellos años como argumento de marketing en la venta de ordenadores, y poco a poco se impuso como “lingua franca” de los informáticos (¿Cuál será la lingua franca de los informáticos de hoy en día, me pregunto? ¿SQL, quizás?). Otros lenguajes, sobre todo Fortran, se siguieron utilizando en entornos científicos o ingenieriles, y aún lo hacen, pero en el entorno de Aplicaciones de Negocio (Contabilidad, Facturas, Proveedores, etc), Cobol se impuso con rapidez.
En este punto me hubiera gustado incorporar una foto de un taco de tarjetas perforadas con un programa Cobol, o un listado de una compilación de hace treinta años… pues lo siento: ni tengo, ni he encontrado nada buscando por ahí. En alguna de las muchas mudanzas, acabaron todas en el reciclador de papel. Así que, de momento, os vais a quedar con las ganas.
Ya desde el principio, Cobol define muy claramente la estructura que debe tener un programa, mediante una organización en Divisiones, éstas en Secciones, y éstas, a su vez, en Párrafos, en contraposición al otro gran lenguaje de alto nivel de la época, el Fortran, donde puedes definir cualquier cosa en cualquier punto, cosa que a los ingenieros seguro que les venía bien, pero no cuando se escriben programas de gestión. Hay cuatro divisiones, que son, siempre en este orden:
IDENTIFICATION DIVISION, donde se pone la información de identificación del programa: Su nombre, su autor (o autores), Fecha de escritura, etc. Esta División sirve más bien a título de comentario.
ENVIRONMENT DIVISION, donde se especifica la información de entrada/salida: Qué ficheros usará el programa, cómo son (secuenciales, indexados, etc), cómo se llamarán para el programa y, muy importante, cómo se llaman de verdad en el Sistema, etc.
DATA DIVISION, donde se definen… los datos, sí. Los registros de los ficheros (en la FILE SECTION), las áreas de trabajo (en la nunca bien ponderada WORKING-STORAGE SECTION), y, en caso de tratarse de un módulo (que es llamado por otro programa de mayor rango), las áreas de intercambio de información (en la LINKAGE SECTION). La DATA DIVISION es el reino de la PICTURE, la cláusula de definición de los datos más potente jamás inventada.
Sentencias de la Procedure Division en un pantalla ISPF
Un amigo mío (también de la época de los dinosaurios, como yo) comenta siempre que “XML es un standard muy completo, que sólo tiene un fallo: ¡No tener PICTURE!!”
PROCEDURE DIVISION, donde se define lo que es el programa en sí, las instrucciones que conformarán tu programa, con sus lecturas y escrituras, movimientos de campos, cálculos, ejecuciones de rutinas, etc… hasta alcanzar el STOP RUN, donde el programa termina tranquilamente… si antes no ha dado un cascotazo, claro.
Y es emblemático en Cobol el uso del punto para indicar el fin de la frase, es decir, el fin de sentencia o del párrafo, de la misma forma que el punto se usa en la escritura para terminar una frase o párrafo (salvo que seas Gabriel García Márquez y escribas El Otoño del Patriarca… entonces sólo pondrás un punto cada seis o siete páginas, pero claro, muy pocos somos un genio como D. Gabriel).
La principal ventaja de usar Cobol reside en su capacidad de autodocumentación: escribir un programa en Cobol es prácticamente lo mismo que describir lo que hay que hacer en inglés:
Por ejemplo:
READ INPUT-FILE INTO REGISTRO-ENTRADA AT END MOVE ‘SI’ TO INDICADOR-FIN-FICHERO.
PERFORM PROC-FACTURA UNTIL COD-FACTURA NOT EQUAL TO COD-FACTURA-ANT.
EXAMINE CAMPO-ALFANUMERICO REPLACING ALL ‘A’ BY SPACES.
ADD 1 TO CONTADOR-REGISTROS.
CALL ‘MODULO’ USING ARGUMENTO-1, ARGUMENTO-2.
IF INDICE-TABLA GREATER 1000 DISPLAY ‘***LA TABLA SE HA EXCEDIDO’.
MULTIPLY NUM-UNIDADES BY PVP-UNITARIO GIVING PVP-TOTAL ON SIZE ERROR GO TO PVP-EXCEDIDO.
WRITE OUTPUT-REGISTER FROM REGISTRO-DE-SALIDA.
PERFORM HACER-CALCULO THRU FIN-HACER-CALCULO.
GO TO LEER-FICHERO.
Eso sí… ¡Casi nadie sabía inglés por estos lares en aquella época!, porque el “Idioma Moderno” que se estudiaba en el Bachillerato era Francés, el idioma de la diplomacia. ¡Qué gran visión la de los educadores de entonces!
Parte de un programa Cobol, con Divisiones, Secciones, Párrafos y sentencias. Y sus puntos.
No, tranquilos, no voy a explicar lo que hacen las sentencias anteriores, porque cualquiera que sepa un poco de inglés (ahora, ya somos muchos) se puede hacer una idea muy aproximada del objetivo de cada una de ellas… sin saber una palabra de Cobol. Para los que estéis interesados, aquí teneís el “Cobol Language Reference” de IBM, donde podéis disipar todas vuestras dudas, y aquí, la misma cosa pero de Cobol Microfocus, que tiene versiones para PC, UNIX, y emula al mainframe, o sea, es sintácticamente el más completo de todos, pues a todos ellos los emula.
Por cierto, cuando en España (creo que en Latinoamérica no es así) hablamos “en Coboliano” (o como se diga), la pronunciación de los verbos es diferente de la que usamos cuando nosotros mismos hablamos en inglés (bueno, ejem, en esa cosa parecida al inglés que chapurreamos muchos): Por ejemplo, pronúnciese “READ” en vez de “Riid”; “MOBE TO” en lugar de “Muuv Tchú”, “GOTO” en lugar de “Gou Tchú” y, desde luego, “PIKTURE” en lugar de “Pikchrr”. Curiosamente, otros verbos sí que los pronunciamos los coboleros como los sajones: “Compiutt”, “Rrait”, o “Examinn”, por ejemplo. Manías de la profesión, supongo (…y que me perdonen los lingüistas ingleses por la chapuza fonética: Sorry!).
En cuanto a la gestión de ficheros, la del Cobol es muy potente y sencilla de utilizar, y la capacidad de definición y uso de los datos, mediante la famosa cláusula PICTURE, es excelente (siempre “PIC” para los coboleros, pocos escribían PICTURE en un programa de verdad: es más largo, y como había que perforarlo todo…).
Una curiosidad Cobolera: La siguiente sentencia es una sentencia válida en Cobol:
NOM-PARRAFO. GO TO.
Go To… ¿adónde?, preguntaréis. Porque una sentencia de bifurcación (un GO TO) que no dice adónde se produce la bifurcación… parece un poco raro, ¿no?
Y es que una característica del Cobol, que no se da en casi ningún otro lenguaje de alto nivel, es la capacidad de, utilizando de forma legal las sentencias del lenguaje, modificar el propio código máquina de una instrucción del programa. Para ello está la (odiada) sentencia “ALTER”. Por ejemplo, podríamos codificar:
ALTER NOM-PARAFO TO CALCULAR.
Esta sentencia cambiaría el código del GO TO en NOM-PARRAFO para apuntar a la dirección de “CALCULAR”. Cuando, por su orden de ejecución normal, el programa alcance la dichosa sentencia GO TO, el programa ahora bifurcará a “CALCULAR”.
Naturalmente, puede haber varias sentencias ALTER que vayan modificando la bifurcación para que apunte a diferentes puntos del programa en función de las condiciones que se vayan dando… lo que puede ser una forma muy eficiente de programar… y un auténtico quebradero de cabeza para luego seguir lo que hace el programa.
Como podéis imaginar, el uso de esta sentencia está tácitamente prohibida por el manual implícito de buenas prácticas del Cobolero medio (y por las normas de programación de las empresas que las tienen, que son muchas), lo que no impide que algún inteligente lo use de tanto en cuando… más que nada, para fastidiar.
Y sin embargo, en el momento de la definición del lenguaje, en 1960, era una sentencia lógica, potente y bastante usada en los primeros años, en sustitución de la sentencia PERFORM (la de ejecutar una rutina y, al acabar, proseguir el proceso por la instrucción siguiente a la propia PERFORM, como el DO de Fortran y muchos otros lenguajes). En la siguiente ilustración se pueden observar las dos diferentes maneras de programar esta llamada.
Dos maneras de ejecutar la subrutina -A- en Cobol.
Cuando los ordenadores tenían muuuy poca capacidad, codificar de la forma de la derecha ahorraba espacio, instrucciones y ciclos de máquina, por lo que era bastante usada, incluso recomendada por algunos manuales de buenas prácticas de la época. Había que adaptarse a lo poco que había…
Debugger de Cobol en acción
El lenguaje Cobol se fue adaptando, con el tiempo, a la tecnología de cada momento, incorporando fácil acceso a las Bases de Datos que fueron apareciendo (IMS/DL1, Total, Adabas, DB2, etc), a los diferentes Gestores de Teleproceso (IMS/DC, CICS, etc), y a otros ambientes y sistemas operativos (UNIX, Linux, etc), aunque, definitivamente, no tanto al mundo del PC.
Sí que existen diversos Compiladores de Cobol para PC desde mediados finales de los años 80, y existe también un entorno completo de Simulación para poder programar, compilar y probar en un PC programas Cobol para el entorno mainframe.
Este entorno permite simular no sólo el propio compilador, sino a todos los productos del mainframe, como CICS, IMS ó DB2, con un potente debugger, ¡incluso permite simular la ejecución de rutinas escritas en Assembler! permitiendo una productividad muy alta en el desarrollo y pruebas, y una total (bueno, casi total) compatibilidad.
También existen productos que implementan Cobol en PC, permitiendo desarrollar aplicaciones completas, y no sólo aplicaciones puramente batch.
Se han definido, e implementado, extensiones para soportar Windows (u OS/2, en su día), el paradigma Cliente/Servidor, el de Orientación a Objetos… pero ciertamente nadie en sus cabales escribe una aplicación Cliente-Servidor, ni menos aún Web, en Cobol.
Cobol para PC
Algún iluminado, inasequile al desaliento, llegó a proponer que al Cobol Orientado a Objetos (OO Cobol) se le cambiase el nombre a “ADD 1 TO COBOL GIVING COBOL”, que es la traducción literal a Coboliano del término “C++”, puesto que éste último nombre de lenguaje había tenido tanto éxito en este entorno del OO… Pero parece que pocos entendieron la gracia, y no tuvo éxito la propuesta. ¡Qué cosas!
Cobol es un lenguaje realmente “verbose”: seguramente para hacer las mismas tonterías de las sentencias anteriores, en C (con o sin los signos de la suma) o en Java se requerirían quizá tres líneas cortitas en total… pero esa “verbosidad” redunda en un buen entendimiento de lo que hace un programa Cobol cuando lo mira un programador distinto de aquél que lo escribió… veinte años después. Y eso, en una instalación informática de verdad, con decenas de miles de programas, y millones de líneas de código en Producción, cotiza muy, pero que muy caro.
Ya he comentado que muchas Aplicaciones llevan veinte años o más en Producción, y es lógico pensar que han debido sufrir cambios durante este tiempo: naturalmente que es así. Cambios legales, nuevas necesidades de la compañía, nuevos productos, etc, obligan a cambiar funcionalidades, ficheros, bases de datos… y todo cambio termina obligando a cambiar a su vez uno o varios programas. O muchos. O todos.
En estas condiciones, poder entender rápidamente la funcionalidad de un programa, localizar el lugar donde debe ser modificado, modificarlo, y que funcione correctamente según las nuevas especificaciones, y todo en un tiempo razonable, es realmente el factor clave en la elección de un lenguaje de programación. Y en esto, Cobol se lleva la palma.
Me da a mí la sensación, tras hablar con muchos colegas, de que el paradigma sobre el mantenimiento de las aplicaciones escritas en C, por ejemplo, es que resulta más barato reescribir el código de nuevo, cuando hay que hacer una modificación de cierta entidad, que tocar el código existente… porque casi siempre el programa resulta prácticamente incomprensible para un programador distinto del que lo escribió (y en ocasiones, incluso para el mismo que lo escribió). Esto no se puede tolerar en una gran instalacion. Que me perdonen los fans del C, o del Java, o del Perl, o del propio Ada, pero esta es mi opinión… y la de muchos otros, también. “Bonus Track”
Para terminar este artículo, quizá os acordéis del publicitadísimo “virus del milenio”, cuando hubo que hacer grandes inversiones en informática derivadas de la inevitable llegada del año 2000, exactamente al día siguiente del 31 de diciembre de 1999 (por cierto, esas inversiones no fueron nada comparadas con lo que hubo que hacer en Europa el 2001 con la llegada del Euro… ésa sí que fue de aúpa, pero ésa es otra historia, y será contada en otro momento).
Uno de los muchos libros que se vendieron sobre el Y2K
…Primero los consultores nos amenazaron con el fin del mundo, luego nos echaron la culpa a los informáticos por nuestra descomunal falta de previsión, se vendieron libros, revistas, seminarios, conferencias y charlas por todas partes, se escribió mucho y se habló más… y luego, cuando el 1 de enero del 2000 todo funcionó, nos tildaron de alarmistas, derrochadores, y de que no era para tanto… Y, total, todo porque no se cayó ningún avión, ni explotó ninguna central nuclear, ni siquiera hubo un Banco que dejara de procesar sus transacciones.
Si habéis abierto la página de la Wikipedia que cité antes, podéis comprobar la lista de “grandes” errores que acontecieron en el mundo el 1 de enero del 2000. ¡Imaginaos lo que nos hubieran llamado (no, de dónde nos habrían colgado) si alguna catástrofe de verdad hubiera ocurrido! Las consecuencias, efectivamente, fueron mínimas y rápidamente solventadas, así que mucha gente pensó que los informáticos habíamos engañado a todo el mundo, con el fin de conseguir mucho dinero para corregir un error que, en definitiva, no era para tanto…
Pues… Sí que fue para tanto. Yo os aseguro (lo viví en primera persona, como muchos otros), que fue un trabajo exhaustivo y agotador, revisando, cambiando, probando y poniendo en Producción muchos miles de programas, interrelacionados entre sí… una labor de chinos, y donde el control de cambios era vital para asegurar que una aplicación cambiada siguiera “hablando” con las que aún no lo habían sido, y viceversa. Fue tremendo.
Y todo este trabajo, para que todo siguiera igual.
Bueno, vale, también se aprovechó para cambiar algunas cosas, incluso para tirar las realmente viejas y hacerlas nuevas. Pero en muchísimos casos, no: nos limitamos a cambiar el código para tratar la fecha sin introducir ningún cambio adicional.
En definitiva, dinero “perdido”, según los administradores de las empresas. Y con razón, pensaréis… ¿Con razón? No lo creo. Veamos:
Todo el asunto fue motivado por la “manía” de muchos informáticos (¿muchos…? ¡todos!) de almacenar las fechas en los Sistemas de Información con el año en dos dígitos.
Así, por ejemplo, el 7 de febrero de 1978 se almacenaba como “780207”, en vez de “19780207” (por cierto, no como “070278”, pues de esta forma las fechas no quedan ordenadas según el natural orden cronológico; a la hora de imprimirlas, se dan la vuelta, pero internamente están siempre Año-Mes-Día). Y, claro, el día más alto posible era el “991231”. El día siguiente (el uno de enero del 2000), se vería como “000101”… que es anterior a todas las demás fechas hasta entonces, pues es la más pequeña posible.
La fecha de marras...
En sí, si nos fijamos, no es que pase nada especial… salvo por los programas que necesitan ordenar movimientos por fechas, o calcular diferencias entre fechas (como las liquidaciones de cuenta, o los cálculos de la fecha de caducidad, por ejemplo). Es decir, muchos. Pero muchos. En realidad, todas las aplicaciones contables (las que manejan datos de dineros, o sea, casi todas en las empresas) están afectadas en mayor o menor medida.
No quedaba, pues, más remedio que modificar todos los ficheros y bases de datos para aumentar el tamaño de las fechas, después cargar los nuevos ficheros con los datos antiguos (añadiendo un “19” en las dos primeras posiciones del año), y listo. Fácil, ¿no?
Pues no.
El problema es que esto afectaba a muchos millones de ficheros y bases de datos en todo el mundo… y muchos cientos de millones de programas que los leían y escribían.
En este punto uno no puede dejar de preguntarse: ¿Cómo es que los informáticos del mundo mundial, tan listos ellos, no vieron venir este hecho, y se empeñaron, años y años, en almacenar el año en dos dígitos? Es más, debió tratarse efectivamente de un virus de alcance universal, porque no se escapó nadie, ni en España, ni en Latinoamérica, ni en EEUU, ni en Europa, ni en la India, ni en ningún sitio.
Pues hay varias razones para tan criminal proceder:
En los años 70 y primeros 80, a nadie en su sano juicio se le podía ocurrir que las Aplicaciones que diseñaba, con los años en dos dígitos, pudieran resistir 20 años o más sin que una nueva y más moderna aplicación sustituyera a la que estabas escribiendo. Por ejemplo, en los primeros 80, en el Banco ya estábamos desarrollando completo un nuevo Sistema Bancario, que sustituía a otro con menos de diez años de vida, y lo mismo ocurría en muchas instalaciones. La Informática era joven, y en unos pocos años habíamos ya sustituido muchas Aplicaciones, así que, ¿cómo pensar que la cosa que poníamos en marcha en 1981 pudiera durar hasta 2009… y contando?
Y es que, por estúpido que parezca, almacenar las fechas en ocho dígitos en lugar de seis era caro. Carísimo. Hagamos unas pequeñas cuentas. Un Banco (de entonces) podía tener quizá un millón de clientes, y cada cliente tenía una o varias cuentas, que tienen algunos apuntes cada mes, quizá cinco o seis. En cada uno de estos apuntes (operaciones), hay al menos tres fechas: la de operación, la de contabilización y la de valor. Y muchas más en el resto de la información de la cuenta (fecha de apertura, de liquidación, de cancelación, etc). Utilizar ocho dígitos para almacenar las fechas, en lugar de seis, ocuparía 6 caracteres más por cada apunte. Con varios centenares de millones de apuntes almacenados, la diferencia supondría apenas cinco o seis Gigabytes de almacenamiento en disco… Y no sólo había fechas en los apuntes. ¡Había fechas por todas partes! Montañas de fechas de todo pelaje, esparcidas por ficheros y Bases de Datos.
Por cierto: ni siquiera la “Fecha de finalización de un préstamo hipotecario” estaba en cuatro caracteres… ¡El plazo máximo al que se concedía un préstamo eran doce años!! Y de los tipos de interés, ya ni hablamos, todos eran de dos cifras. Para que os quejéis los jóvenes…
- Tripas de un disco IBM 3340 (años setenta). ES tan grande como parece.
¡Pero es que los discos de la época tenían algún ciento de Megabytes cada uno, y eso que ya no eran removibles! O sea, por el mero hecho de guardar espacio en la fechas para tener los años de cuatro cifras, había que comprar alguna decena más de discos… que eran bastante caros, como podéis imaginar… (El IBM 3380 DASD, la unidad de disco más avanzada de la época, era capaz de almacenar hasta ¡10 Gb!, en sólo cuatro armarios realmente aparatosos, con varios discos cada uno, que ocupaban un espacio enorme, quizá seis o siete de largo metros por uno de ancho, más el área de servicio).
- Disco IBM 3380. Casi 10 GB en seis metros de discos
…Y todo este dispendio de valioso espacio en disco, para nada: ni a corto, ni a medio, ni a largo plazo: hasta quince o veinte años más tarde no se notarían las supuestas ventajas de tener las fechas así almacenadas… si la Aplicación seguía aún funcionando, claro, cosa por entonces inimaginable. No había manera, en los setenta y ochenta, de justificar económicamente usar cuatro dígitos para el año. Las cuentas no salían.
Vale, de acuerdo, también nosotros los de la profesión tuvimos parte de la culpa: ya a principios de los noventa empezó a ser evidente que las aplicaciones que se desarrollaban entonces deberían durar más de diez años, y el coste del almacenamiento había ido bajando muchísimo… y sin embargo muchas se siguieron escribiendo con los años en dos cifras. Sobre todo por inercia (“como toda la vida se han almacenado en dos, ni te paras a pensar si no sería mejor hacerlo de otro modo”), y un poco por compatibilidad (“si hay que comunicarse con otra aplicación que ya funciona, hay que adaptarse a su formato”).
Sólo a partir de 1995 o 1996 se desterró definitivamente la costumbre de almacenar las fechas en seis caracteres… tarde, muy tarde. Pero… se ve que aprendemos rápido de nuestros errores: ya hay gente muy sesuda preocupándose del problema del año 10.000, y ¡exigiendo que los años se almacenen en cinco cifras!, para evitar que los tataranietos de los tataranietos de… nuestros tataratataranietos no tengan que lidiar con el mismo problema dentro de 8.000 años. Está claro que los humanos no estamos nunca contentos con nada…
En el próximo artículo (si aún os sentís capaces de aguantar los desvaríos de este Abuelo Cebolleta), os contaré cómo funcionaba un Banco, y cómo trabajábamos nosotros, los informáticos de postín, en estos Sistemas durante los años ochenta. Las cosas cambiaban deprisa…
Disfrutad de la vida, mientras podáis.
ACTUALIZACIÓN:
Nuestro amigo Jaume ha recuperado del baúl de los recuerdos un auténtico programa Cobol en tarjetas perforadas, lo ha fotografiado, y ahora todos podemos disfrutar de estas irrepetibles imágenes en esta entrada.
¡Gracias, Jaume.!
Seguid disfrutando de la vida, mientras podáis.
The Historia de un Viejo Informático. El Cobol. Bonus Track: el “Virus del Milenio”. by , unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.
{ 69 } Comentarios
Hola, encontré por casualidad el artículo de los mainframes de IBM en menéame, y desde ese momento estoy enganchado a esta serie tan apasionante. Basta con decir que soy un apasionado de la computación, y a mis “escasos” 32 años, aunque no estudié informática, sino que soy contable, me encanta leer del tema, y más que nada, aprender de quien quiera compartir con nosotros sus conocimientos; ahora entiendo mis primeras clases de informatica en bachillerato, allá por los 90′s, cuando el profesor nos hablaba de las tarjetas perforadas, y nos enseñó programación con diagramas de flujo, que así se le dicen acá a las plantillas con dibujos que hacíamos en nuestras servilletas de bar… muchas gracias por compartir, y espero con ansia el siguiente artículo, saludos desde México!!
Antes que el año 10.000 tenemos otro problema por delante: ¡El problema del año 2038!
Suena a cachondeo pero no lo es. Todos los sistemas UNIX almacenan la fecha en una variable de llamada time_t, que es un enterode 32 bits con signo(wikipedia dixit). Esto significa que el primer bit de ella nos dice el signo y el resto el valor. De este modo puede almacenar un total de 4.294.967.294 de valores. SON muchos pero es que la variable de marras lo que cuenta son los segundos que han pasado desde el1 de enero de 1970 (llamadme ignorante pero no tengo ni idea de por qué esa fecha…). Con eso ya no nos sobra tanto. En resumen, cuando ese contador llegue a 01111111111111…..1 en binario (2147483647 en decimal, acordaros que el 1er bit es para el signo),al segundo siguiente pasará a 10000000000…..0. O lo que es lo mismo -2.147.483.648 que correspondería al año 1901.
Este problema se soluciona con el paso a arquitecturas de 64 bits (ahora la mayoría son de 32) pero me da por pensar si cuando lleque el segundo 2147483647 (03:14:07 del 19 de enero de 2038) estarán todos los sistemas UNIX. Ésto son la mayoría de servidores del mundo y cada vez mas ordenadores personales (como el mío…).
No se si cuadra mucho aquí pero me parecía interesante comentarlo.
Saludos a todos!!!
Muy buena, ahora falta que te atrevas a preparar otra entrada sobre el otro lenguaje de IBM, el RPG http://en.wikipedia.org/wiki/IBM_RPG
Salu2
@jesus: Gracias. Me alegro de que os guste.
@Boot Loos: Sí, ya lo sé, pero sinceramente no creo que pasen 18 años sin que se hayan tirado a la basura todas las máquinas de ahora… claro que, con la crisis de los … igual hay que mantener lo que hay hasta el 2.200!
@alex: ¡Ya me gustaría! Pero jamás trabajé con RPG, sólo leí manuales, y en cierta ocasión mi equipo de desarrollo tuvo que hacer un proyecto en AS400… pero entonces no estaba yo para aprender lenguajes nuevos!! Bastante tenía con sacar un rato para ver a mi familia casi todos los días… Qué tiempos infernales!, que espero que no vuelvan nunca.
Saludos a todos y gracias por los ánimos.
Sobre el problema del 2038 me gustaría añadir alguna cosilla…
Según tengo entendido, este sistema de almacenar la fecha (segundos desde el 1 de Enero de 1970, fecha tambien llamada The Epoch o La Época) se diseño e implantó a finales de 1969… como el cambio de año (y de década!) estaba a la vuelta de la esquina, quedaba elegante iniciar el contador con el primer segundo de ese año.
Este sistema está en muchos UNIX, y como seguro que confirmará Manuko, en muchos otros sistemas operativos. Además no está solamente en PCs u ordenadores, sino en multitud de “cacharritos” (routers, firmwares, consolas, móviles…). Creo que es un problema realmente grave.
Como curiosidad, hace unos días pasamos por la fecha UNIX 1234567890. Si alguien quiere juguetear con esta fecha, puede ejecutar los siguientes comandos en su sistema operativo (Microsoft Windows abstenerse):
Ver la fecha actual desde epoch: date +%s Convertir una fecha cualquiera a epoch: date -d’01/10/1983′ +%s Convertir una fecha de epoch a formato ‘normal’: date -d ‘@1234567890′
Nunca me olvidaré de cuando me contaron lo que era el “BRITE”… porque así sonaba cuando lo decía, “BRITE”, y no teníamos ni puñetera idea de lo que era hasta que el pollo lo escribió en la pantalla… WRITE, joder, ¡WRITE! Pero así lo decían, y nosotros (los pardillos) éramos los que teníamos que adaptarnos a cómo decían las cosas los de siempre
Muy buen artículo, y lo dice alguien que trabajó en COBOL durante el “virus del milenio”. Tal cual. Siempre meneo tus artículos (como todos los que escribís), pero éste con una nostalgia especial. (Por cierto, el comentario de PERFORM VARYING MENEOS… es cojonudo).
Buenas Macluskey! Genial como siempre. Despues de currar en Cobol durante un tiempo, y ahora trabajar con C, mis compañeros flipan cuando digo “aseriscar”en vez de comentar! O cuando algo no funciona como debe digo “voy a displayar el campo tal” en vez de hacer printf de la variable tal…Me miran raro!! Cobol para trabajar con registros en ficheros… una maravilla!! El que lo pensó (Creo que fue LA que lo pensó, me suena que es de una señora), lo pensó muy bien.
Una cosa, todas las maravillas que puedo pensar de Cobol pierden su sentido si hablamos de Pacbase! El puto pac generaba código digno de un psicópata! Pero escribía PICTURE, y COMPUTATIONAL-3… y… bueno que me lío jejej y solo quería felicitar al autor!
Salud!!
Casi me hace llorar este articulo. Me recordo cuando programaba en COBOL y FORTRAN y los tenian que guardar en tarjetas perforadas y ya poco despues en cassetes de audio : O Pocos ahora nos creen que asi empezamos pero ya con este articulo se convencen mas. Gracias por escribirlo.
Lo que habris disfrutado en el museo que visite el otro dia… Computer History Museum en Mountain View, CA. Tenian partes de ENIAC, EDVAC, y de muchos Mainframes desde los inicios hasta la actualidad e la informatica. Entre otros, algunos discos duros como el que pones imagen (grandes los platos como una paella para 12) y con una sola cabeza que se desplazaba entre los platos. El primer Apple, que basicamente era una placa taladrada a un pedazo de madera. Y tambien manuales de Cobol y Fortran de la epoca…
Recomendable para cualquiera que este enamorado de esta cacharreria y se acerque a la zona de San Francisco
Impresionante como siempre… salvo un pequeño fallo en las lineas 208 y 209(les falta el punto ) de la ficha del programa cobol … que haría que en la primera compilación salieran unos 25000 errores XD
Saludos
He leido el articulo y la verdad es que he sentido nostalgia de los años que programaba con Cobol. Ya han pasado muchos muchos años desde la ultima linea de cobol que programé. Particularmente ha sido el sistema de programacion que mas he dominado porque era perfectamente capaz de desarrollarlo en multiples sistemas operativos. Ahora me dedico a otras cosas que no tienen nada que ver con la informatica. Creo que mi primer programa Cobol fue con 14 o 15 años. snif
Vuelvo a comentar, admitiendo mi error , que me lo han chivado en meneame.net … no le falta el punto
Saludos
muy buena historia, para refrescarnos la memoria de las bases de la computación, informática, sistemas, y todo ese rollo que dia a dia nos facilitan la vida
@Kent: Caramba, eso no lo sabía. Así que 2038 va a ser fino… Bueno, eso no tiene por qué ser malo: el número de informáticos que se incorporaron a la profesión entre 1997 y 1999 casi duplicó a los que ya estábamos… así que igual solucionamos la dichosa crisis en 2035!! Lo podríamos llamar “La Crisis del Centenario del Nylon” (descubierto en 1938), y tan panchos: A vender libros, organizar conferencias… Claro que yo espero estar, al menos, jubilado.
@Pedro: Lo siento, estás equivocado. No es WRITE; es BRITE, que se escribe con uve doble para fastidiar, pero es BRITE!!
@Jimmy Jazz: Sí. A todo. Aunque el que firmó el Cobol fue el comité creado por el DoD, parece que la autora intelectual fue Grace Hopper. Se nota que está diseñado por una mujer. De haberlo diseñado sólo hombres, en vez de “ADD 1 TO PEPE”, sería PEPE++, y ya estamos en la mata. Y el Pacbase es francés… que son un poco raros para estas cosas. Mira que poner “COMPUTATIONAL-3″, vamos, es un sacrilegio… Por cierto, que sepas que en la profesión, si hablas de una entidad española que usa Pacbase, todos sabemos de qué entidad estás hablando…
@javi: Gracias por la información. no tengo pensado cruzar el charco en los próximos tiempos, pero lo apunto por si acaso.
Y gracias a todos por vuestros comentarios.
Solo un pequeño apunte, los que veniamos de la informatica de verdad, S34 en adelante, teniamos para micro informatica el RM Cobol, creo que Ross McFarland Cobol, un Cobol para PC que trabajabas con los ficheros indexdados tipo Btrieve, con sus ficheros de datos y sus indices. Yo personalmente soy mas programador de RPG que de Cobol aunque he tocado y todavia toco Cobol,recuerdo cuando IBM presento V/SAM como la panacea del acceso a datos. Sigo pensando que si quieres gestion no hay nada como un IBM y sus ‘arcaicos” lenguajes de programacion y tampoco he trabajado para IBM pero si en varios agentes IBM.
Jeje pues lo de Pac se por lo menos de 2 sitios, a parte del que tu conoces, hay cosas en Pacbase por lo menos en otro sitio, aunque está desapareciendo poco a poco y lo están pasando todo a Cobol normal; porque tenían cosas tan chungas como los fuentes generados, pero sin los fuentes en Pac (otros sí que los tenían), por lo que hacer cambios en esos programas era la ostia. Es una instalación la mar de exótica, una máquina Bull, cobol y pacbase, oracle…
Supongo que el Pac si aprendes a usarlo estará bien, y si eres constante con el mantenimiento y eso funcionará de lujo… pero visto así un poco por encima… tiene muy mala uva! jeje
Salud!
Hola Macluskey,
solo escribo para felicitarte por los artículos. Este y el anterior de la serie son especialmente buenos.
Solo una cosa: no hay que ser un pureta para haber lidiado con COBOL. Yo no tengo ni 25 años y ya trabajé con él, en sistemas mainframe con DB2 (eso sí, no he perforado ni una tarjeta en mi vida). Supongo que por eso se me ha dibujado una sonrisilla al leer tus comentarios o al ver ese editor infernal con fondo oscuro. Por suerte o por desgracia ya lo dejé, pero creo que fue muy gratificante y muy constructivo trabajar con una tecnología que se usaba antes de que yo naciese. Creo que más gente que aprende a programar en una tarde con algún editor repleto de asistentes debería pasar por esto para ver de dónde venimos y adónde vamos en el mundo del desarrollo.
No me extiendo más. Recibe un saludo.
Yo que trabajé con RPG y con S/38 y AS400, me acuerdo del año 2000, como si fuera ayer, porque como teniamos que cambiar las longitudes a todos los ficheros fisicos y logicos(otro dia lo explico), no nos daba tiempo y una empresa en Barcelona descubrió, que el año 1972 era igual que el año 2000, que el 71 igual al 99, etc… y cambiamos toda la base de datos restandola 28 años, y en entradas y salidas sumabamos o restabamos 28 años y así lo hicimos y estuvimos aguantando hasta el año 2006, que se cambiaron las aplicaciones
Yo estaba por comentarte del problema del año 2038, porque me pareció raro que no hicieras mención de él. Pero veo que ya varios se me adelantaron
Muy buen artículo, como siempre Mac.
Saludos a todos.
a Jose Suárez de Lezo: el RM/Cobol fue una excelente herramienta de desarrollo de los 80 y 90. RM viene de Ryan McFarland (No Ross). Ademas de versiones para PC (DOS – CP/M) hay versiones para unix/xenix. Y el codigo objeto (el compilado) era transparente a la plataforma. Podias compilar el codigo en DOS y ejecutar el programa desde unix y viceversa. Eso si, necesitabas el intérprete para la plataforma que querías. Saludos
@Todos: Muchas gracias por vuestros comentarios.
@RPGeros: Me hubiera encantado poder escribir un artículo sobre el otro monstruo de las cavernas, el RPG de los S/32, 34, 36, 38, AS400, iSeries… pero ¡no sé!. Sin embargo, os animo a que, los que sepáis, que sois legión, escribáis un artículo sobre RPG. Me ofrezco a ayudaros si hiciera falta… porque de Cobol hay poco, pero de RPG… de RPG hay menos aún.
¡Todo sea por informar a las nuevas generaciones!!
Saludos
Me uno a Mac: si sabéis de RPG y pensáis que puede resultar interesante leer sobre él (a mí me lo resultaría, creo que a Mac también, seguro que a otros igualmente), escribid sobre él, y os leeremos
Oh¡¡ que tiempos aquellos donde el unico libro en español de Cobol era el Ciro de La Fuente, debio hacerse de oro el tal Ciro.
Y puestos a suponer de programación estructurada ¿quien se acuerda ya de las metodologías de estructuración wrnier y Bertini?
@ Ex NCR,
Pues Mac se debe de acordar bastante bien, porque tiene ya escrito un borrador de tropecientas palabras sobre ese tema
PERFORM 10000-INICIO THRU 10000-INICIO-FIN.
PERFORM 20000-PROCESO THRU 20000-PROCESO-FIN.
PERFORM 30000-FIN THRU 30000-FIN-FIN.
Uy, no me ha mantenido el formato ordenadito cobolero jeje
GOBACK
A ver, la diferencia UNIX PC a la que te refieres varias veces en el texto no existe. UNIX puede funcionar en PC sin problemas, sin ir más lejos LINUX se creó para PC y se portó a otras arquitecturas después, creo que la diferencia es UNIX Windows o WIN32 o M$.
Por otro lado no creo que el lenguaje más usado hoy en día sea SQL. Yo me decantaría por XML, sobre todo HTML
Y ya que he empezado a escribir pues …¡ buen artículo!, ¡otra vez!
En la Facultad de Informática de Coruña hasta hace un par de años en una asignatura de 2º llamada Metodología de la Programación (que estaba basada en la informática de 20 años atrás) había una parte dedicada a la Metodología Warnier, y además entraba en el examen…
@Ex NCR: ¿No había el de Tomás Hurtado Melero? D. Tomás fue el gran gurú del Cobol en España en los primeros setenta, y yo creo que suyo era el libro. A ver si lo confirmo. Y luego, el Ciro de la Fuente, sí señor. Y sí, en un par de entradas nos meteremos con Warnier, Bertini y Jackson (el que yo de verdad me sé).
Aviso con antelación: No hay nada de nada de nada en la red sobre Bertini. Marie Thérèse Bertini no tiene una entrada en la Wikipedia, ni siquiera en la francesa. Si pones su nombre en Google, aparece una señora que, por su edad y curriculum no puede ser la misma Sra. Bertini, pues es al menos quince años más joven (salvo que sea su hija o algo así). No lo entiendo, pero así es.
Si alguien tiene alguna referencia, porfa porfa, que me la sople.
@Jimmy Jazz: ¡Siempre he odiado poner numeritos a los párrafos!. Eso sí que era una costumbre de la época de las tarjetas, que afortunadamente fue desapareciendo con el uso de las pantallas. Aunque es verdad que hay generadores (como el que tu y yo sabemos) que ponen numeritos a todo…
@Brigo: No entiendo tu comentario. ¿He hablado yo de diferencias UNIX-PC? He comentado que hay versiones de Cobol para todos los sistemas, incluidos PC y UNIX. Microfocus, por ejemplo, tiene Cobol para casi todos los sistemas; pero hay otros Coboles que sólo funcionan en un tipo de sistemas u otros. Y en cuanto al lenguaje, claro que XML o HTML son los más usados hoy en día… pero yo me refería a la “lingua franca”: eso que todo el mundo entiende, aunque no domine. Mi opinión es que es SQL. Todo informático que se precie debería saber que es SELECT * FROM PEPE GROUP BY JUAN. Mientras que yo, y mucho dinosaurio como yo, por ejemplo, de HTML, ni papa. Es más, conozco mucho diseñador y programador en Java que de HTML anda justito, justito. A eso me refería. En mis tiempos era Cobol, je je. Años ha.
Gracias a todos por comentar
Una de las herramientas líderes en gestión de Nóminas en España está programada íntegramente en COBOL con entorno gráfico para Windows. Yo fui programador durante unos meses y debo confirmar que aunque parezca un lenguaje tosco y engorroso es muy productivo.
Hace ya casi 10 años que dejé esa empresa y en esos momentos estaban dando cursos a los programadores para migrarla a Visual “algo” (mi memoria nunca ha sido lo que fue). El caso es que a día de hoy la aplicación sigue intacta, por lo visto han sido incapaces de migrar ese monstruo a un lenguaje mas moderno (que no mejor!).
Geniales los artículos, la verdad es que enganchas.
Lo que comenta “Brigo” es que te refieras a los “ordenadores con Windows instalado” como PC (Personal Computer). Esto, para los linuxeros, nos resulta algo molesto ya que estas mezclando peras con manzanas.
Por ejemplo: “sistemas operativos (UNIX, Linux, etc), aunque, definitivamente, no tanto al mundo del PC”
Habría quedado mejor: “sistemas operativos (UNIX, Linux, etc), aunque, definitivamente, no tanto al mundo de Windows”
@BootLoos. Esperemos que para ese segundo ya hayan desaparecido las arquitecturas de 32, si Dios y Adobe (propietarios de Flash) quieren
@ubersoldat: Ah! Ya!
Pues no. Entonces lo que digo está bien. Bueno, je, je, no sé si está bien o no. Pero es que a mí me parece.
Porque la situación es exactamente la misma en UNIX o en Windows: hay compiladores de Cobol (¡y muy buenos!) para ambos entornos (para Linux, sinceramente, no lo sé, aunque supongo que algo habrá). Para todo tipo de UNIX (AIX, HP/UX, Solaris, etc). Y todo tipo de SO de Microsoft (MS/DOS, Windows 3.1, 95, 2000, XP, Vista, etc). Pero no han tenido éxito. Se han programado cosas en Cobol en todos los sistemas, existen aplicaciones de PC, sea cual fuere su SO, en Cobol, como meniona Sorrillo. Pero POCAS. En todos estos entornos se lleva programando las cosas en OTRA COSA hace mucho.
Yo digo que “nadie en sus cabales desarrolla una aplicación C/S ni Web en Cobol”, y quizá debería añadir “hoy en día”, pues Cobol ha perdido la batalla en estos entornos (lógico). Su reino sigue siendo el mainframe (VSE, z/OS) o el mundo de los AS400 (ahora, iSeries), donde reina por completo (porque poco debe quedar ya en RPG, y poco se programa en estos entornos en C y cosas así, aunque tienen un compilador de C extraordinario… pero se usa poco.
¡Gracias por vuestras aportaciones!
No lo había pensado antes, pero también me parece que es algo confuso lo de UNIX/PC: uno se refiere al sistema operativo, otro a la arquitectura, aunque entiendo lo que quieres decir al usar los términos. Pero yo estoy utilizando ahora mismo un PC, pero con UNIX
Tal vez Windows/PC se preste menos a confusión.
Bueno, no sé si queda claro, pero… es que estamos hablando de Cobol, no de Sistemas Operativos ni de máquinas.
Por resumir, y a ver si consigo expresarme bien:
El reino del Cobol es el mundo mainframe (cualquiera que sea su SO) y el mundo AS400/iSeries. En estos mundos existen compiladores de otros lenguajes, pero se usan menos. Quizá, dado que ahora funciona Linux en mainframe se comiencen a utilizar más otros lenguajes, pero de momento, poco.
En el resto de los mundos, máquinas de todo tipo y pelaje, con diferentes arquitecturas y procesadores, con Sistemas Operativos de Microsoft (cualquiera), o UNIX (cualquiera), o Linux (cualquiera), o Mac, o lo que sea, existen compiladores de Cobol que funcionan muy bien, pero se usan poquísimo (salvo para emular al propio mainframe y descargarle de la tarea de desarrollo, pero incluso esto, muy poco).
Uff, espero que haya quedado más o menos claro.
Gracias por las aclaraciones
Mac, me asombra que después de tantos años lidiando con tantos y tantos problemas que hemos tenido que afrontar en nuestra vida profesional, sigas ‘enganchado’. En varios de tus espectaculares artículos y comentarios, haces referencia a los duros y angustiosos momentos que has pasado en tu etapa como desarrollador, lo que comparto plenamente por mi experiencia en esa etapa, pero sabemos que nada comparable con los momentos de tensión y presión que se viven en el entorno de Producción, donde se juega con fuego real en lugar de balas de fogeo. Te animo a que cuentes algo sobre la ventana Batch, considero sería de utilidad a las nuevas generaciones de informáticos que no han tenido la suerte de conocer esta trastienda. Desde Galicia, gracias por tu tiempo y conocimientos, y desde luego ¡ánimo viejo colega!
Buff: ¡La ventana batch!
La peña se preguntará si eso es que los mainframes tenían (TIENEN, qué demonios) una ventanita para mirar cómo se ejecutan los batches…
Tienes razón, Rabade. Pero es que la siguiente entrada me ha salido tan larga que si sigo metiendo más texto, va a acabar por aburrir hasta a los incondicionales como tú… Miraré a ver si puedo al menos citarlo, porque desde luego es importante…
Gracias por la anotación!
Reorganizaciones de tablas, cambios al modelo, planificación de cadenas batch (Control-M…), monitores de Cics (Omegamon…)… queremos massss jeje.
En el anterior curro que estuve, donde andaban con los Bull, (NovaScale y máquinas mu majas), tenían también aplicaciones Cobol sobre linux y Unix, con RM-Cobol. Pero editar con Vi, no es como el ISPF… no e lo mimmo jeje.
Respecto al editor de Microfocus para windows, con su debugger y demás (Mainframe express creo recordar que se llamaba); es una puta maravilla. En una instalación donde curré el entorno de desarrollo era ese, luego en los varios entornos de pruebas que había, si que era un zOS.
TSO QUERY, TSO %DITTO, pantalla 3.14 para buscar, SPOOFY… CEMT noseke… que recuerdos… jeje estaba muy bien aquello.
Leeñe, Jimmy Jazz… Pero ¡si sabes más que yo de todas esas cosas… !!
Y sí, Microfocus es una maravilla (y lo es desde hace quince o veinte años). Permite programar y probar con total compatibilidad con CICS, IMS, DB2… incluso Assembler (porque siempre tienes un par de módulos vitales en la organización que están escritos en Assembler…) en un entorno amigable y con un debugger de primera línea. Excelente herramienta. Aunque se usa poco actualmente: como el ISPF tiene tiempos de respuesta subsegundo, paqué montar DOS juegos de prueba, en fin… que somos cada vez más vagos.
¡Si yo hubiera pillado el Microfocus a primeros de los 80!!!! Sniff
Iré hablando de lo que conozco. Pero insisto en mi ofrecimiento una vez más: Si pensáis que podéis aportar a la serie en temas que yo no domino, adelante, incluso os ayudo si queréis (por ejemplo, conozco muy bien CICS -que por cierto, no me gusta mucho-… pero nunca programé ni diseñé para él; cosa que sí que me pasa con el IMS, el DL/1 el DB2…). Además, estuve ahí cuando se fueron poniendo en marcha (sobre todo DB2) desde el principio casi…
Ya le tocará al DB2, ya. En tres o cuatro entradas, que las próximas están ya en el horno.
Saludos
Que va, si no controlo de eso, son cosas que había en instalaciones que curré de picateclas y es por curiosidad! O Como planificabais las cadenas batch para que no chocaran entre ellas dejando tablas o ficheros pillados o lo que sea… yo solo soy un aprendiz de mucho, maestro de nada jeje
sin más, esperando próximas entregas
Buenas! mi enhorabuena por tu artículos, abren la mente de programadores noveles como yo (empecé a programar con 21 y ahora tengo 26). Solo decir que aún siendo un programador novel… programo en Cobol!! Hoy en día el Cobol sigue vivito y coleando, y se sigue usando en muchas empresas de programación de software de gestión (aqui en Tenerife, Islas Canarias, hay un buen par de empresas que lo usan, incluida la mia
). Poco a poco va adaptando cosas de tiempos modernos (api’s, objetos, etc etc), pero cual es mi sorpresa viendo los trozos de código que ponías arriba, que lo entendía todo perfectamente!, lo que es el código en si no ha variado casi nada. Un saludo!
Fantástico artículo Macluskey.
Yo empecé en informática modificando programas en COBOL para adaptarlos al año 2000 y al euro. Por aquellas fechas lo raro era empezar desarrollando otras cosas.
Eso sí, la tarea era pesada como ella sola. Después de 6 meses buscando fechas por todas partes para cambiarles el formato uno se sentía como si estuviese en una cadena de montaje poniendo tapones a las botellas que iban pasando delante suyo.
Tan harto estaba que empecé a buscar trabajo en otras empresas en las que dedicarme a otra cosa… ¡Y no te imaginas lo que me costó! En cuanto veían en mi currículum mis humildes 6 meses de experiencia en COBOL, intentaban por todos los medios convencerme para cambiarme a su empresa trabajando… ¡también en COBOL! En fin, supongo que no tengo que explicarte nada sobre la brutal demanda de “coboleros” de entonces.
Mi pertinaz negativa me llevó hasta una empresa en la que empecé a trabajar con sistemas de información geográfica y de supervisión de red. Pintar garabatos de colores en la pantalla, eso sí que me gustaba.
En fin, ahora recuerdo mi etapa “cobolera” con cariño. Participar en todo ese enorme fregado tuvo su gracia…
@Mazinger: ¡Qué me vas a contar del 2000!!! Yo lo sufrí más que modificando programas, controlando qué programas se modificaban, cuándo, cómo… Divertidoooooo, divertidoooo, pero que divertido!. Menos mal que tenía fecha de caducidad… el uno de enero del 2000, para bien o para mal, se acababa el proyecto…
Sí, fueron épocas, digamos, curiosas ¡y muy bien pagadas, por cierto!
@Papamillo: Sí, ya lo creo que está vivito y coleando. Pero mucho. Si la gente más OO-adicta supiera cómo pagan los talones los bancos, cómo envía Hacienda las Declaraciones de IRPF, o cómo vende El Corte Inglés, por poner algunos ejemplos obvios… pues eso. MOVE va, MOVE viene. Y algún que otro GOTO..
Este año COBOL cumple 50 años. Desde mi agencia de comunicación llevamos la cuenta de una empresa inglesa que se llama Microfocus y sólo provee aplicaciones en COBOL. Por otro lado estoy llevando una campaña del Ministerio de Industria que se llama Software Legal y que tiene un portal sobre software tanto desde el punto de vista de la programación como de la distribución. Me encantaría que el “Abuelo Cebolleta” escribiese un artículo para él o que me diese la oportunidad de entrevistarle. Creo que estaría muy bien que las nuevas generaciones escucharan tus batallas.
HOLA, SOY UN JOVEN PROGRAMADOR AS400 Y NECESITO CONOCER MICROFOCUS COBOL PARA UNIX, SI ALGUIEN ME PUEDE DAR ALGUNA AYUDA ESTARÍA MUY AGRADECIDO. ATTE. ANGEL ARAYA M. (STGO DE CHILE)
ANGEL ARAYA: Bienvenido a la profesión.
No sé si te has dado cuenta, pero en el propio artículo hay un link a una página donde tienes online el manual de Microfocus (en concreto, de la web de HP, o sea, que es para UNIX).
Espero que te sirva.
me ha gustado el artículo, pero sólo una nota: en ETEO, una universidad del grupo Mondragón que se encuentra en la localidad guipuzcoana de Oñati, sí se imparte COBOL en la carrera de informática de gestión
Muy buen artículo, sí señor. Y por aportar algo, hace unos años se estudiaba COBOL en la facultad de informática de la UEX en Cáceres. Por cierto, cuando yo programaba el Basic de mi C-64, no odiaba la sentencia GOTO, claro que eran otros tiempos y uno podía hacer un programa de forma ordenada sin prisas por cumplir plazos de proyectos.
GRacias por traerme a la memoria este gran lenguaje, que me dio muchos quebraderos de cabeza, y muchas satisfacciones
Una entrada de culto, felicidades por eso, muy interesante. Y lo mejor es que tú lo viviste!!. Yo desearía haber podido ser testigo de los albores de la informática, pero nada, soy de los 90′s
Un saludo, y mis respetos.
@Svast… Pues ¡te lo cambio sin verlo!
Ya te cuento yo lo que tú quieras, y a cambio me quitas veinte años de encima, a ver si fuera posible…
No te preocupes. Dentro de veinticinco o treinta años podrás publicar en la SupraRecojoNet tus propias “Historias de un Informático del Siglo XX”, y cuando digas que los discos tenían 200 Gb en 3 pulgadas y media, que programabas tecleando en un teclado, y que los ordenadores no te entendían cuando les pedías que hicieran algo hablando, no te creerán…
Salud para verlo!! Y gracias por vuestros comentarios
Me acaban de pasar esta estupenda história y es buenísima.
Recuerdo lo que me decía mi profe de Cobol de FPII (sí, hace ya mucho) cuando le preguntaba ¿por qué no nos enseñáis VBasic, C, etc. en vez de Cobol? .. y él me decía que seguramente lo que me daría de comer durante muchos años sería el Cobol y no el VBasic, etc. .. y qué verdad, todavía me da de comer !!!
Quería saber si existe algún diccionario de Coboliano, seguro que a alguien ya se le ha ocurrido explicar el significado de:
y que solo alguien que haya trabajado o trabaje en Cobol (al menos de la antigua escuela) sabe su significado.
Hola, Yo también soy un cobolero desde los ochentas y aún sigo haciendo aplicaciones (en COBOL!) para empresas de diversa índole. La nostalgia es inmensa. Me acuerdo cuando empecé a laborar en mi primer trabajo formal (montando papel en las impresoras Burrougs) con computadores B3700 que “corrían” a tres (3) megas de velocidad y discos duros del diámetro de un LP (LD) que almacenaban hasta veinte (20) megas de información. De allí el costo de almacenaje y el Año 2000. Hablarle del Sorter, la Perforadora de Tarjetas, la Lectora de Cinta Perforada de Papel, las Lectoras de Cinta Magnética y otros periféricos a mis hijos les causa risa e incredulidad: acostumbrados al disco portátil de 500 GB, la USB y Redes inalámbricas para ellos eso es PREHISTORIA COMPUTACIONAL. En la actualidad desarrollo en .NET, Delphi y Power Builder pero nunca dejaré de utilizar el compilador más fácil, transportable y sencillo de codificar. Y como alguien ya lo dijo: Me ha dado para subsistir todos estos años. Felicitaciones y gracias por su tiempo. Aquí desde Bogotá, Colombia.
Aunque creo que este comentario llega tarde – he localizado estas páginas de rebote desde un manifiesto de apoyo al ahora llamado System i (antes AS400, despues iSeries, que manía le da a IBM en cambiarle el nombre a las máquinas)- dices que el COBOL es mayoritario en el AS400 y no creo que sea así. El 400 es RPGero por una razón fundamental, el coste del compilador. El compilador de COBOL es mas caro que el de RPG y las empresas se inclinaron por esa razón por el segundo. Soy profesional de la informática desde hace mas de veinte años y ahora mismo se sigue trabajando en RPG pero de otro “tipo” ahora es ILE RPG o RPGLE, con instrucciones en formato libre, nada de las hojas de codificación de antaño, de forma que hasta los programadores jóvenes que vienen del mundo de PC lo asimilan perfectamente. Enhorabuena por tus artículos, realmente me han emocionado, no llevo tanto tiempo como tú en esta profesión, empezé con un S/36 y sigo trabajando en AS400 o iSeries o System i o como quiera IBM llamarle dentro de poco. Servidores estables, seguros y que son capaces de mover ficheros de millones de registros sin inmutarse.
Justo viendo Connections de James Burke, recordé a Cobol, quien diría que la moda textil tendría un papel importante en la informática.
http://www.youtube.com/view_play_list?p=0C43386079D8B683&playnext=1
Hola, un articulo muy bueno, yo se cobol pero soy mas experto en Pacbase y la verdad es que cuesta aprender y hacer las cosas bien, pero una vez que lo sabes manejar, te simplifica mucho la vida, haces programas como churros, eso si, el COBOL que genera es una p…. mierda, yo solo lo miraba cuando me fallaba algun programa para ver las cosas ocultas que hace el pacbase e intentar corregirlo. Por cierto si alguien sabe de empresas que necesiten programadores cobol o pacbase que se ponga en contacto conmigo que estoy al paro jaja mi email es ruben_lo25@hotmail.com Saludos
Hola, yo también he formado parte de los dinosaurios coboleros, esto es como el rock ¬ roll. Los viejos coboleros nunca mueren. Por cierto estoy intentando localizar a alguien interesado en impartir un curso de COBOL/PACBASE en Barcelona.
pffffff, que de años….justo este celebro mis 25 jugando con esto tan divertido del Mainframe…aún, aunque ahora ya ni lo veo…. Yo era de la rama pija, de los de sistemas, y aunque he tocado algo el COBOL, lo que recuerdo con autentico aprecio era el VM, bajo el que podias tener varios VSEs, algun MVS, y por supuesto los usuarios de CMS (usuarios nativos VM)y su lenguaje REXX. Con el REXX jugabamos los “listos” y nos permitiamos el lujo de tocar registros generales y hacer autenticas pirulas sin despeinarnos….¡Que tiempos aquellos!. ¡¡¡¡¡¡¡¡ Recuerdo como si fuera ayer mi primer dia en la oficina en Sevilla, donde habia una pantalla de fosforo verde conectada a una red internacional, funcionando bajo VM, y corriendo una aplicacion de correo online (hace 24 años de esto, aunque parezca mentira)!!!!!!!!!
Muchas gracias por hacernos reverdecer viejos laureles y por enseñar a nuestros chicos de hoy que esto de la informatica tuvo algo de arte.
excelente el articulo pero te hago una consulta que programa (nombre) corresponde a esta dos imágenes
http://eltamiz.com/elcedazo/wp-content/uploads/2009/02/pc-cobol-screen.png
http://eltamiz.com/elcedazo/wp-content/uploads/2009/02/mfcobol.jpg
y de donde se pueden descargar
sdos
Es cierto, el COBOL es un gran desconocido y no recuerdo que durante la carrera se haya siquiera mencionado. Yo lo conocía, sólo de nombre, antes de empezar a trabajar con él, porque en los años 80 mi madre estuvo estudiándolo (aunque a la mujer la programación no le gusta y nunca se dedicó a ello) y recuerdo que tenía un libro marrón con el retrato de la Mona Lisa hecho con letras. Luego llegó lo del efecto 2000 y se volvió a hablar del COBOL, aquello pasó y volvió a olvidarse. Una pena, porque sin él hoy en día el mundo se pararía…
Encontrado un programador muerto en el baño con un tarro de champú en la mano. Las instrucciones de uso decían: - Aplicar - Aclarar - Repetir
Excelente artículo, me encanta la serie.
Jo, está fenomenal esta serie
Por decir algo, ya que lo único que me ha hecho feliz de la programación ha sido el Basic y el Visual Basic, así que no puedo compartir más experiencias con vosotros. Pero vamos, que mis primeros programas también los grababa en cintas magnetofónicas.
Una cuestión: ¿un mainframe es lo mismo que un superordenador?
No. Lo que se llama (o se llamaba, quién sabe) un mainframe es un ordenador central diseñado para ser “central”, el gran ordenador de una empresa. Su hardware está diseñado para ser de alto rendimiento en “cargas mixtas”, pero es un software lo que lo hace realmente ser “central”.
Un mainframe actual de IBM con z/OS (como ahora se llama el ínclito MVS) es capaz de dar servicio a 100 usuarios de time sharing (trabajando en edición de ficheros, compilación y submisión de jobs, etc, con tiempos de respuesta subsegundo, que va más rápido que el propio PC), ejecutar entre 100 y 200 transacciones por segundo (CICS o IMS: cada transacción puede ser desde una consulta de saldo a un ingreso, un pago de cheque o de recibo, un alta de depósito, etc: cada una de ellas puede acceder a decenas de tablas), y ejecutar 200 ó 300 jobs batch (llenos de sorts, cargas y descargas de tablas, programas diversos, etc).
Simultáneamente
Con su CPU al 101% continuamente (es por el prefetch, claro), sin caerse y manteniendo el rendimiento sin despeinarse, 24 horas al día, 7 días a la semana y sin necesidad de reiniciar cada vez que se instala algo…
.
Un “superordenador” es otra cosa: no es de propósito general sino que está diseñado para una función determinada: cálculo de explosiones nucleares, meteorología, desencriptación de claves indescifrables, etc. Suelen estar compuestos por centenares o miles de procesadores pequeños interconectados: el principal problema de diseño es conseguir que los procesadiores hagan algo útil sin molestarse continuamente unos a otros.
Gracias por tu comentario.
Gracias a ti por tu respuesta. Me maravilla poder preguntar a un experto y hallar respuesta, es impagable esto.
Yo empecé a programar BASIC en un MSX, luego en un Amiga y ya en la Universidad conocía Fortran, Delphi, Visual C++, Visual Basic, etc… y la verdad que me encantaba. Lástima que mi carrera profesional no ha tenido ya mucho que ver con la programación, aunque aún he podido programar en AutoCad, Excel y Acces en Visual Basic.
Respecto a los superordenadores, hace poco oí un reportaje que me pareció fabuloso. ¿Qué opinas de la computación cuántica? Es cuestión de pocos años que la veamos. En ese programa decían que habría un pequeño problema y es que el que tuviese un PC cuántico, podría desencriptar cualquier clave. Aunque ya existen encriptadores cuánticos. Fascintante!!
Pues es que no sé nada de computación cuántica. Lo poco que he leído por ahí, que parece más bien ciencia ficción que otra cosa.
Creo que su principal reto será conseguir fiabilidad. O sea, que uno más uno siempre dé dos. Siempre, siempre, no con una probabilidad del 99,999%… O sea, que le faltan unos añitos para ser una realidad “comercial”… ¡Espero llegar a verlo!!!
No te preocupes cuando tus comentarios se salen por las ramas… igual nadie los lee solo se hay q saltar a las partes importantes…
Bueno, pues parece que Cobol cumplió 60 años, que alguien escribió un articulo glosándolo (y haciendo enlazando este artículo)…
…Y por lo menos veinte veces (hasta hoy) se ha fusilado el artículo en diferentes sitios y lugares, sin cambiar mayormente ni una coma. He dejado cuatro o cinco enlaces a dichos artículos y he borrado los doce o quince restantes. Y los que lleguen a partir de ahora, claro.
Así está el patio, amigos. Eso de ser original está claro que en estos tiempos es rarísimo.
¡Y por lo menos esta vez el autor original ha referenciado la fuente (y todos los demás también, claro: no cambian ni una coma, ya digo)!!! De los que no referencian nada, ni se sabe cuántos debe haber.
En fin, lo importante es que los coboleros de pro estamos de enhorabuena. Felicidades.
Así es el mundo del instagram, twiter y de la mediocridad intelectual. Un saludo amigo Mac y enhorabuena por tus escritos.
Fuente “el Temiz”?
Jeje.
Eso, además. Pero al menos el enlace es correcto. Algo es algo…
{ 6 } Trackbacks
Historia de un Viejo Informático. El Cobol. Bonus Track: el “Virus del Milenio”….
Siguiente entrada de la serie… ahora le toca el turno al Cobol….
[...] » noticia original [...]
[...] artículo en la serie de informática histórica de Macluskey en El Cedazo, en esta ocasión sobre el lenguaje COBOL, que fue creado en 1959 y todavía se usa hoy en [...]
[...] en la serie de informática histórica de Macluskey en El Cedazo, en esta ocasión sobre el lenguaje COBOL, que fue creado en 1959 y todavía se usa hoy en [...]
[...] de un viejo Informático el COBOL. Recuperado de: https://eltamiz.com/elcedazo/2009/03/02/el-cobol-virus-del-milenio/ Compártelo:TwitterFacebookMe gusta:Me gusta [...]
[...] La mayoría de lenguajes de programación van y vienen, pero COBOL ha logrado convertirse en toda una leyenda que a sus 60 años recién cumplidos está sorprendentemente vivo y extendido. Sentencias de la Procedure Division en un pantalla ISPF, instrucciones que conforman el programa. Fuente: El Temiz [...]
Escribe un comentario