Ir al contenido principal

Cobol, no recomendado para menores de 50 años

Por necesidades del proyecto en el que trabajo he pasado del mundo Eclipse, Java, Spring, Hibernate, Maven y Subversion al mundo COBOL/CICS/DB2. ¿Qué si se nota la diferencia? No, no he notado apenas diferencias a la hora de desarrollar (modo ironia ON).

Os daré mi visión general de cómo se desarrolla en este lenguaje y lo compararé con el desarrollo con Eclipse.  Esta destinado para que el programador que no tenga ni idea de Cobol pueda hacerse una pequeña idea (Dios mio no siento las piernas!!!). Perdonad todos los coboleros por mis explicaciones de este lenguaje porque no llevo mucho tiempo con él y apenas se hacer nada.









Primer programa


Escribir un programa en Java que escriba 'Hola Mundo' por pantalla es relativamente sencillo. Te creas una clase Java, con un método main y escribes una línea System.out.println ("Hola Mundo"). Luego ejecutas tu mini-programa desde Eclipse/NetBeans con tu JRE y en la ventana Output de Eclipse te sale tu mensajito. 


En COBOL, es un poquitín más complicado. Para comenzar tiene un entorno de desarrollo más tedioso en el que tienes que moverte casi siempre con teclado. Crear, editar, borrar, copiar y pegar programas se hace de forma similar al ultraconocido vi de Unix. Te puedes hacer dos tipos de programa y siempre lo tienes que indicar en la cabecera: ONLINE o BATCH.


  • ONLINE son programas que se utilizan para interactuar con el usuario. Ejemplo: Se arranca una transacción que arranca el programa A. El programa A envía un mapa (ventana tipo formulario) y termina el programa (aunque no la Tx). El usuario rellena la información y cuando la introduce se vuelve a reanudar la Tx anterior, lanzándose de nuevo el programa A. El programa recibe el mapa y procesa los datos del usuario realizando la lógica oportuna.
  • BATCH son programas que se ejecutan background sin necesidad de interactuar con el usuario. Se lanzan desde un archivo JCL, que es un archivo en el que se definen una serie de pasos o acciones mediante un lenguaje de script (parecidos a los scripts UNIX). Aparte de lanzar los programas que creamos mediante JCL, normalmente tendremos disponibles una serie de programas útiles que podemos definir en nuestros JCLs para copiar, crear y borrar ficheros, acceder a BBDDs, transformar ficheros, ect...


Al igual que en Java todos son objetos y se ejecutan mediante un entorno controlado que es la JVM, en una máquina Mainframe hay un sistema operativo (ej.: z/OS) que se encarga de lanzar transacciones que se corresponden con la ejecución de uno o más programas realizados en COBOL. Cada Tx. tiene asociada una cola que será la que gestiona la ejecución de esa Tx.


Pienso que la forma más fácil de escribir un 'Hola Mundo' en COBOL es crear un programa BATCH que tenga la estructura básica obligatoria con un párrafo (son como procedimientos o bloqués de código con nombre) que haga un DISPLAY (como el System.out). Luego crearemos un JCL que lance este programa, los submitimos(jaja, ejecutamos vamos)  y listo. En definitiva, más líneas de código y dos elementos  (JCL y Programa BATCH).


Estructura de programa


Si en un programa Java típico tendríamos clases, cada una de ellas con atributos con tipos determinados y métodos con una interfaz determinada, en Cobol un programa tiene una estructura dividida en secciones obligatoria, cada una de ellas con un fin:

  • IDENTIFICATION DIVISION, donde se describe el nombre del programa, el autor, fecha creación....
  • ENVIRONMENT DIVISION. Datos referentes a la máquina donde se escribe el programa. Tiene una subsección llamada INPUT-OUTPUT-SECTION donde se definen por ejemplo los ficheros que se utilizan en el programa y tipos de ficheros.
  • CONFIGURATION SECTION
    • FILE SECTION. Se define el nombre lógico de los ficheros de la INPUT-OUTPUT-SECTION indicando el tipo de fichero, su acceso y la COPY asociada a su estructura.
    • WORKING-STORAGE-SECTION. Variables de trabajo que utiliza el programa. Se borran una vez que finaliza la Tx. asociada.
    • LINKAGE-SECTION. Variables que se utilizan para la comunicación con otros programas de otras Tx. 
  • PROCEDURE DIVISION. Se definen los bloques de código de los que consta el programa.
Mientras que en un programa java la información entre un objeto A y otro B se pasaría mediante un mensaje tipo B.metodo(a,b), en COBOL deberíamos rellenar los datos de a y b en la LINKAGE SECTION mediante una copy (EST-AB) y el programa A llamaría al PROGRAMA B mediante la sentencia LINK (misma TX) o XCTL (diferente Tx) indicando la COPY que se utiliza para llamar al programa B (EST-B). 

Para la comunicación entre programas también se pueden utilizar las colas. Hay dos tipos de cola, colas TD (que son generales a todos los programas y de solo lectura) y colas TS (que se pueden crear desde los programas y son de lectura/escritura).

Normalmente cuando queremos trabajar con una estructura de datos en un programa COBOL definimos COPYS, que son ficheros en los que se define un conjunto de campos con una longitud y tipos determinados y luego hacemos un INCLUDE de esa COPY en el programa. En Java lo que haríamos sería crear una clase diferente y luego incluir esta clase con una relación de clientela.

Tipos


En Java hay muchos tipos predefinidos en la JRE tipos numericos (int, double, long...), cadenas (String), colecciones (Stack, List, Vector...), recursos (File, Socket,... ) además podemos crear tipos personalizados creando clases.

En COBOL, los campos pueden ser o PIC X (alfanumérico) o PIC 9(numérico) indicando entre paréntesis la longitud que ocupa el mismo.


  • PIC 9(2). Campo numérico de 2 caracteres.
  • PIC(X). Carácter alfanumérico.
Simplemente esto, aunque se pueden crear tipos numéricos comprimidos (COMP-3), formateados (Z), numericos con decimales sin signo y con signo... En general es esto. Las listas de elementos se pueden crear con la palabra OCCURS:

01 ESTRUCTURA_PROGRAMA.
      05 CAMPO-LISTA OCCURS 4 TIMES.          
            10 CAMPO1     PIC X.
            10 CAMPO2     PIC 9.

CAMPO-LISTA es una lista de 4 elementos formados por campo1 y campo2.



Entorno de desarrollo


Hay múltiples entornos de desarrollo en Java (IDE, NetBeans, Intelligent Idea, JBuilder...). En COBOL desconozco si hay muchos o pocos y lo que se puede hacer con cada unos de ellos, aunque me imagino que todos serán similares. Aquí tenemos uno en el que se puede:


  • Crear, modificar y borrar fuentes Cobol y mapas. (¿Eclipse? ¿UltraEdit?, ¿dónde estáis?, os necesito). Mucho teclado y teclas F1..F12, como los frikis.
  • Realizar la compilación de fuentes y mapas. Compilar es fácil pero compilar un programa sin errores es tarea harto difícil. Si acabarás de conocer al compilador de COBOL se presentaría diciéndote: 'Hola soy el compilador de COBOL y te voy a joder la vida...'. Se queja hasta por la columna en la que defines una sentencia. Es muy importante que cada sección y cada sentencia esté en su sitio, obligando al programador a dejar todo atado y  bien atado.
  • Utilidades para la gestión de ficheros.
  • Utilidades para el manejo de DB2. Bendito TOAD, cuanto te echo de menos!!! 

En general los fuentes COBOL están en librerías, mientras que los fuentes java se encuentran en paquetes. Agrupaciones lógicas al final. Cuando se compilan los fuentes Java se generan .class que pueden empaquetarse en .JAR. En COBOL cuando se compilar los fuentes, copys, mapas, rutinas, ect.. se crean ficheros con todo el código linkado  y se dejan el librerías especiales para que luego puedan ser ejecutadas correctamente. 



Ficheros


Utilizar un fichero en código Java es muy sencillo. Con una línea de código podemos comenzar a leer o escribir de un fichero:

BufferedReader in = new BufferedReader(new FileReader("foo.in"));


Sin embargo en COBOL tenemos que hacer varias cosas:

  • Primero tenemos que definir el tipo de ficheros y nombre lógico en el programa en la ENVIRONMENT-SECTION.
  • Tenemos que asignar la estructura del fichero (mediante una copy por ejemplo) y asignarla al fichero, además de indicar el tipo de fichero en la sección DATA-DIVISION.
  • Definir los ficheros (de entrada o salida) en el JCL que lance el programa que utiliza los ficheros. Aquí es donde se indicará la ruta física de los ficheros.
Hay varios tipos de ficheros: aleatorios (acceso aleatorio), secuenciales (acceso secuencial) y ficheros VSAM (acceso por clave). En programas BATCH se puede acceder a todos los tipos de ficheros mientras que en programas ONLINE se suelen utilizar sólo los VSAM. Además, a los ficheros VSAM se accede de forma diferente desde programas ONLINE y BATCH.


Bases de datos


En Java se utilizan los drivers JDBC para acceder a todas las diferentes bases de datos. Se accede mediante un objeto DataSource pasando una cadena de conexión de una BBDD o mediante JNDI obteniendo un DataSource desplegado en un servidor de aplicaciones.

El acceso de los programas COBOL a BBDDs se resume a DLI y DB2.


  • DLI es una ¿base de datos? jerárquica. Es bastante antigua. Se divide de forma jerárquica (árbol) donde cada nodo hoja es un segmento. Cada segmento contiene una información determinada y tiene un nodo padre menos el nodo raíz. Para acceder a una información puede que tengamos que recorrer varios segmentos antes de llegar a ella.
  • DB2. Otra base datos bastante antigua. 



Desarrollo gráfico


En entorno Java hay muchos frameworks para desarrollar aplicaciones gráficas tanto web como de escritorio (JavaFX, JSF, GWT, ZK... ). Dichos frameworks permiten realizar ventanas complejas con una gran diversidad de controles gráficos diferentes.

 En COBOL, las aplicaciones gráficas están basadas en pantallas de 24 líneas de 80 caracteres y no hay más (el CICS).

Hay herramientas para definir las etiquetas y campos de los mapas y definir en qué posición va cada cosa. La comunicación con los programas se realiza mediante colas y COMMAREAS y con las sentencias SEND / RECEIVE


Definición de mapa COBOL


Control de versiones y pases a producción


En desarrollo Java (y en cualquier lenguaje) normalmente hay un programa de control de versiones (SourceSafe, CVS, Subversion, GIT...) para controlar las diferentes versiones de la aplicación que estamos generando, coordinar los cambios de todos los programadores y saber quién ha hecho qué cosa y cuándo. También suele existir una herramienta de integración continua (CruiseControl, Hudson, Jenkins...) que se encarga gestionar todo el ciclo de vida de las aplicaciones, desde empaquetado de la aplicación hasta su despliegue en los diferentes entornos. 

En CICS, al menos aquí, no hay control de versiones. Hay entornos y se hacen copias de seguridad de todos los elementos del código en producción. Si estás en desarrollo puedes meter la mata y perder alguna que otra hora de trabajo.


Conclusiones


En definitiva, aunque COBOL (Common Business Oriented Language) se creó en 1959 y se haya sustituido en muchos casos por entornos PCs con aplicaciones visuales, todavía sigue teniendo buena salud en entornos bancarios. Se creo en una época en que la compatibilidad entre los diferentes sistemas no era la mejor y tenía una característica clave para su éxito, era fácil de entender programas codificados en COBOL hasta para una persona que no era programadora. Hoy en día por ejemplo, se sigue utilizando hasta en un 70% de las transacciones del Reino Unido.


Salu2. Jose.

Comentarios

  1. Hola tengo 47 años y hace 21 que trabajo en Natural/Adabas es un lenguaje también para Host bastante parecido al Cobol con sus JCL sus pantallas tambien son negras como la que muestras..., hace 5 años mi empresa empezó a trabajar en java y se ha ido migarndo todo parece que por fin me toca a mi pasar a java y me voy a volver loca, yo estoy acostumbrada a saber lo que hago, controlar los erores,.. ahora me puede dar un infarto, cada vez que pregunto algo me dicen que busque en internet (que es como te he encontrado) nadie sabe contestar a nada, a nade le importa lo que ocupa de memoria nada ni lo que tarda ninguna instrucción, si un usuario está 2 minutos mirando a la pantalla esperando una busqueda a nadie se le cae la cara de verguenza, la verdad es que no entiendo esta filosofía.
    No tengo el aspecto del dinosaurio del principio y gracias a estos lenguajes que todavía responden muy bien se han movido los bancos, hacienda, la renfe, telefónica, el corte inglés,..., que parece que antes del java no existía la informática, creo que podemos respetarnos todos y avanzar, que aunque sea jurásica todavía tengo hipoteca, hijos con estudios y hasta me dejan conducir, así como 20 años más de trabajo si la crisis y la salud no o remedian. Cuando tengas 45 hablamos
    Saludos
    Saro

    ResponderEliminar
    Respuestas
    1. Te has parado a pensar cuanto vale una maquina IBM sobre la que corren los programas CICS y un maquina donde correr un servidor de aplicaciones que puede ser OpenSource por ejemplo JBoss.

      Cobol es superior en determinadas cosas a Java, pero Java es un lenguaje mucho más abierto e imaginativo que el encapsulado Cobol, el articulo no me parece que pretende en ningún momento humillar a la gente que trabaja en Cobol como tu intentas hacer parecer.

      ¿Por qué no intentas desarrollar una aplicación Web con Cobol? ¿Tiene entorno para desarrollos móviles?

      Nadie dice que el Cobol debe desaparecer pero hay que avanzar. Por cierto yo tambien he visto transacciones Cobol que dan timeout y por eso no digo que Cobol sea lento.

      Salu2 y no tengas tanto miedo al Java que no muerde.

      Eliminar
    2. Trabajar en informática implica ser proactivo y buscar en google es gran parte del mismo. Somos de informática para poder brindar una solución tecnológica a un requerimiento de usuario, no podemos depender constantemente de otros para resolver un problema y mas habiendo avanzado en seniority. Mi papá es desarrollador hoy en visual basic y hoy también hace desarrollos en .net, tiene 54 años y tiene la habilidad de adaptarse al cambio y a las tecnologías para brindar mejores soluciones. No es un tema de edad, es un tema de no caer en el facilismo de conocer una tecnología y no salir de ahí. Yo tuve el desagrado de trabajar en cobol seis meses y no pude mas!!!!! Por suerte salí de eso!!!

      Eliminar
    3. Cada cosa para lo que es.... A nadie se le ocurre correr un Gran premio de F1 con un Volkswagen GOLF ni tampoco ir a la compra en un FOCUS WRC de 350cv.... El COBOL esta muy bien para lo que se diseño (sistemas bancarios, gestiones transaccionales) y el JAVA esta muy bien para otro tipo de cosas (Aplicaciones graficas, WEB, Mobiles, etc, etc, etc...)....

      En mi caso personal, he trabajado en los 2 ambitos y me costo muchisimo mas hacerme al entorno J2EE, ya que me parece un poco una torre de Babel donde tienes de todo pero muchas veces no lo que necesitas..... Aunque al principio es mas trabajoso, en mi opinion el COBOL es mas controlable y (salvando la apariencia que en el fondo es lo de menos) en su campo funciona mucho mejor que el JAVA (creo que los Bancos ya lo saben...).

      Eliminar
  2. Bueno, como diría Jack el Destripador, vamos por partes.

    En primer lugar este artículo solo pretendía ser una comparativa entre el desarrollo COBOL y Java y mostrar que son dos conceptos completamente diferentes, sin entrar en cual es mejor o peor o más o menos eficiente.

    La potencia y memoria de las máquinas actuales no tiene nada que ver con los recursos de las máquinas respecto a hace unos cuantos años, por tanto, es menos relevante cuanta memoria ocupan las instrucciones de un programa. Yo he trabajado en Java y se pueden controlar perfectamente los errores y tener todo el control. Se puede depurar línea a línea un programa. Además, hay herramientas para hacer una monitorización del programa y saber qué cantidad de memoria consume en cada momento, qué tiempo de CPU... El tener el control de algo lo da la experiencia en un determinado trabajo. Yo cuando me falla algo en COBOL me pongo a temblar, no porque sea difícil, sino porque no tengo experiencia y no tengo ni idea.

    A mi también se me cae la cara de vergüenza si una búsqueda tarda dos minutos en contestar. Pero esto podría estar motivado por problemas en la red, una consulta poco optimizada, bases de datos con mucha sobrecarga... No tiene que ser por el lenguaje Java.

    Estoy de acuerdo en qué muchas empresas han salido adelante con COBOL, pero no tiene nada malo migrar a un entorno Java. Aprender algo nuevo nunca tiene nada de malo y en el mundo de hoy en día en nuestra profesión es bueno saber cuales son las tendencias qué se siguen a la hora de hacer las cosas.

    Respecto al último tema que comentas es más chungo. Me gustaría llegar a los 45, pagar hipoteca y tener hijos y todo ello con un trabajo dentro del mundo de la informática como tú. El problema es que mucha gente con los trabajos de hoy en día no puede ni pagarse la hipóteca y mucho menos tener hijos. Y con la última reforma laboral, más dificil todavía parece. Así que estaría encantando de llegar a los 45 y poder decirte que he hecho todo lo que has hecho tú con mi trabajo de Java, Cobol, C++ , .NET o Administrador de Sistemas.

    P.D.: Si tienes alguna pregunta en Java me lo puedes consultar y estaré encantado de ayudarte.

    Un saludo.

    ResponderEliminar
  3. Te ha quedado genial. Es muy gracioso ver a alguien de java hablando de host! Normalmente los compañeros de ventanas se alejan de nosotros en cuanto les enseñas la pantalla negra... jaja Y ni te cuento cuando les abres un fichero en modo hexadecimal para ver un dato... jajaja

    Bueno, que sepas que no en todas partes es tan malo. En mi trabajo tenemos un IDE para codificar, compilar, consultar fuentes... Eso sí, de los JCL no te libra nadie! jaja.

    Ánimos y si necesitas ayuda con cobol, nos vemos en el Consultorio Cobol : )

    www.consultoriocobol.com

    ResponderEliminar
  4. Jose Ivan Nieto T19 de junio de 2012, 4:09

    Apreciados amigos. Soy colombiano y he vivido ambos mundos, el mundo CISC precisamente con COBOL/NATURAl/ADABS (podrán deducir que no soy muy joven que digamos) y el mundo WEB con Java y PHP. La verdad y con todo respeto por los desarrolladores web (del cual también soy un integrante), la velocidad de un cobol es muy pero muy superior a la velocidad de una aplicación en java o PHP. Vale la anotación de la flexibilidad, obviamente los ambientes web / DB son mucho más flexibles pero dicha flexibilidad es relativa. Nosotros por ejemplo, manejamos nuestro core en COBOl y toda la parte estadística y de inteligencia de negocios la manejamos en Java / PHP / DB. A propósito, también desarrollo en Natural / Adabas y vale aclarar que la seguridad que dan los estornos CISC difícilmente se encuentran en entornos Web / DB.

    Jose Iván
    jint@saas-online.info

    ResponderEliminar
  5. Hola,

    cualquier persona que haya trabajado con COBOL y con otros lenguajes, sabrá que mientras que los lenguajes actuales tienen a ser más cercanos al programador, COBOL no es para cualquiera. Ni tiene que serlo.

    COBOL es lo que es, y vale lo que vale, gracias a su forma de trabajar. No ha durado 50 años (más los que le quedan), por magia, sino porque no hay sustituto mejor o igual en lo que hace.

    Los superordenadores del mundo se manejan a traves de consola, no de ventanitas. Un conocido mio decía: "hay a quien le gusta jugar a programar, mientras que otros trabajamos en ello".

    Un saludo.

    ResponderEliminar
  6. Coboleros Por El Mundo27 de agosto de 2012, 13:05

    Añado una información muy interesante que he encontrado en MENEAME (http://www.meneame.net/story/lenguaje-programacion-implementan-mayores-proyectos-software-eng/1) sobre qué lenguajes implementan los mayores productos software. Podeis ver la comparativa en el siguiente enlace http://www.lextrait.com/vincent/implementations.html.

    Os pongo también un comentario que me hace mucha gracia:

    - Hey, yo hago drivers con Javascript.

    - Buah, yo envío patches del kernel escritos en COBOL y me la sopla que Linus me escupa en la cara.

    - Bah, yo reinvento la rueda todas las semanas haciendo en C/C++ cosas que son más eficientes en Java, coz I'm worth it.

    - Para huevos lo míos, que compilo Java en nativo para usarlo en entorno CGI... menudos blandengues los que piensan más en la arquitectura que en la escalabilidad.

    - Muahaha, no tenéis ni idea, hay que seguir el hype y hacerlo todo con lenguajes funcionales... ya veréis cuando convierta el API de Windows y haya que usar functors en todas las llamadas. Sus váis a cagar.

    - Milongas. Yo estoy creando un compilador inline para poder sustituir ECMAScript por C... Estoy seguro de que acceder directamente a la memoria hará a los navegadores más seguros. Muahahaha, los tengo cuadraos!

    MORALEJA: todos los lenguajes no son adecuados para todo. Hay que utilizar cada lenguaje donde corresponde según el tipo de aplicación.



    ResponderEliminar
  7. Generacion Dinosaurio
    No Logre dejar de leer y eso que tenia prisa me recordo mis años de programador y mis programas con RUN COBOL creo que los dinosaurios que llegamos a programar con tarjetas y conocimos la evolucion de la programacion tenemos una secuencia de programacion que podemos adaptar a cualquier lenguaje y el gusto del reto (ahora sin precion) un reconocimiento a ustedes por que yo me estoy volviendo obsoleto con la nueva programacion

    - Pregunta: Cual es el compilador actual de cobol?
    - Lo puedo bajar de internet?
    -- A su completa dispocicion =>> calderon_arturo@hotmail.com

    PDT Contesteme alguien porfa.

    ResponderEliminar
    Respuestas
    1. Echa un vistazo ha este link: http://www.freebyte.com/programming/cobol/ hay varias opciones para compilar programas en tu PC.

      Eliminar
  8. Como programador COBOL me alegro de que la gente piense que el COBOL no sirve para nada ,cuanta menos gente sepa programar en COBOL mucho mejor para todos los coboleros porque no nos faltará trabajo y seguiremos cobrando más que otros programadores.Tengo conocidos javeros en paro y sin embargo todos los coboleros que conozco tienen trabajo. El COBOL nace en los años 60 y si aún sigue utilizándose es porque para lo que se utiliza no tiene rival, ningún lenguaje de programación puede igualar a COBOL en velocidad y fiabilidad a la hora de procesar millones de datos y realizar millones de operaciones con ellos en un mainframe, por eso todos los grandes procesos de bancos y aseguradoras están desarrollados en COBOL y luego les ponen una interfaz de JAVA para que sea más agradable a la vista pero lo que se ejecuta por debajo es todo COBOL y eso raramente va a cambiar porque no tiene sentido cambiar una cosa que funciona bien y menos cuando se trata de datos y operaciones criticas como puede ser todos los que manejan los bancos y aseguradoras.

    ResponderEliminar
    Respuestas
    1. tio esto ultimo que he leido de tu comentario de mezclar cobol con java me ha dejado rayao por completo, estoy intentando sacar adelante un proyecto en el que pretendo llevar un programa de contabilidad en la web, pero necesito que eso funcione en un navegador de la misma forma que en cualquier maquina, y se me acaba de ocurrir segun he visto tu comentario, que si existe una forma de implementar el proyecto en cobol y crear una aplicacion de java que simplemente muestre los datos al usuario en el navegador eso iria más que de perlas. tu que opinas? esque no me convence node.js, no php, no java(solo java) ni nada de nada. pero me ha dado una idea, voy a investigar

      Eliminar
    2. Amigo, en la empresa donde trabajo, hacemos eso que necesitas, el procesamiento fuerte lo hace cobol y las interfaces para usuario las realizan aplicaciones java con tecnologias como JSF y coldfusion. el api para intercomunicar los mainframes con las aplicaciones modernas son IBM MQ.

      Saludos. desde Costa Rica.

      Eliminar
  9. Segun mi experiencia, COBOL hoy dia se sigue usando porque el coste de cambiar la infraestructura host de una gran empresa es tan desproporcionado que nadie queire oir hablar de ello mientras se pueda evitar, no porque no haya ningun lenguaje que pueda sustiruirlo.

    En cuanto a los lenguajes, cierto que cada uno vale para una cosa, y aunque se puede hacer practicamente de todo con todo (compliquese la vida cada uno como quiera), es algo a tener en cuenta. Sin embargo, hay que evolucionar, y desde luego, se puede lo que hace COBOL en otros lenguajes sin añadir demasiada complejidad al asunto (Logicamente no recomiendo java para realizar tareas COBOL, pero tampoco es bueno despreciar el C, perl, haskell o usar varios y comunicarlos a traves de colas MQ).

    He visto en uno de los comentarios esta frase: "
    Los superordenadores del mundo se manejan a traves de consola, no de ventanitas. Un conocido mio decía: "hay a quien le gusta jugar a programar, mientras que otros trabajamos en ello"." La verdad es que solo se me ocurre una cosa, no porque programes en vi vas a programar mejor que alguien que use codeblocks, eclipse o el ide que sea, que una herramienta para facilitarte la vida no es mas que eso, una herramienta, la programacion la pone el que codifica.

    Un saludo.

    ResponderEliminar
  10. He llegado aqui por casualidad y he de decir que tengo 35 años y llevo casi 10 trabajando con COBOL.
    No se pq se relaciona el COBOL con gente mayor de 50. Tambien quería comentar que no esta reñido el trabajo en COBOL con el trabajo en otros lenguajes mas visuales. Hasta hace poco, donde trabajaba, todos los procesos se realizaban en cobol por eficiencia, pero las interfaces donde se pedian o se mostraban datos a los usuarios iban en .NET para hacerlo más "amigable".
    Como comentaban antes, cada cosa es para lo que es, pero eso no impide que se puedan combinar unas con otras para sacar lo mejor de cada una ;)

    Saludos

    ResponderEliminar
  11. me parece observar que cada uno piensa que su lenguaje es el mejor; y sí, el artículo humilla al Cobol; es común en las nuevas generaciones despreciar el Cobol y creer que los wizard y asistentes de las nuevas herramientas son la única manera de hacer aplicaciones; como experiencia personal puedo decirles que he tenido que hacerme cargo varias veces de sistemas o aplicaciones hechas por otras personas y mi conclusión es la siguiente; no importa el lenguaje en el que se desarrolle siempre y cuando el desarrollo sea claro, lógico, coherente y con el acento puesto sobre su posterior mantenimiento; no siempre escribir menos líneas, aunque mas ingenioso, es más inteligente que separar adecuadamente las tareas y hacerlo fácil para uno mismo y para el que venga después; los "genios" tienen que entender que si un sistema necesita de manera imprescindible a una determinada persona,
    el sistema no sirve.

    ResponderEliminar
  12. Bill Gates: "No sé qué lenguajes habrá en el futuro, pero seguro que Cobol estará todavía allí".

    ResponderEliminar
  13. Bueno, yo soy un gerente de proyectos de 60 años, por lo que mi experiencia es al reves del que menciona el artículo, empecé con Cobol hace 40 años, pero a lo largo de mi carrera he utilizado todo tipo de herramientas, y lenguajes, Yo actualmente utilizo java (programo), en Eclipse, he utilizado Natural/Adabas no solo en mainframes, sino en unix, windows. Estos ultimos lenguajes tienen las extensiones correspondientes para desarrollar aplicaciones Web.
    Pero ademas de trabajar con java en desarrollo de aplicaciones, trabajo en integraciones y modernizaciones de aplicaciones, utilizando Web Services o colas de mensajerias para poner a conversar aplicaciones heterogéneas, modernas o legacy.

    Yo podría escribir el articulo al reves, de Cobol/CICS/VSAM , NATURAL/ADABAS mainframes, ides como Eclipse, generadores como Genexus, herramientas de integración como WebMethods, MQ Series, etc..

    Y aun estoy trabajando en todo esto.

    saludos

    ResponderEliminar
    Respuestas
    1. saludos amigo, mi nombre es Juan Apastillado y tengo 68 años, fui programador en cobol utilizando las computadoras grandes, de esto ya tiene como 15 años, y como me fastidie de trabajar para las empresas, decidí borrar todo de mi mente, pero ahora el gusanito de programar vuelve a mí, solo que ahora pretendo hacerlo en mi PC con windows 10 de 64 bits, no te imaginas todos mis intentos por COMPILAR, llevo meses a intervalos preguntando por los pasos a seguir sin obtener una respuesta sencilla, ya tengo escrito en varios editores el famoso "HOLA MUNDO" te agradecería infinito que con tu experiencia me dijeras los pasos a seguir, COMO SI YO NO SUPIERA NADA.
      AGRADECIENDO DE ANTEMANO TU ATENCIÓN.
      MI CORREO ES VAKCH3333@HOTMAIL.COM

      Eliminar
  14. Yo veo un error grande de concepto, y es que se indica que el Cobol es un lenguahje de los años 60.
    Si mirais un poco la evolucion del Cobol, en concreto COBOL Enterprise de IBM, vereis que no ha parado de evolucionar. El cobol actual tiene parsers para XML, y es orientado a objetos, aunque muchos coboleros no lo usan, o por desconocimiento oporque no lo necesitan en las aplicaciones que desarrollan.
    Ademas un programa COBOL escrito hace 20 años es compatible actualmente, sigue funcionando, cosa que no es cierta en JAVA con los "deprecated", teniendo que tener diversas versiones de maquina virtual para que funcionen las diversas aplicaciones.

    ResponderEliminar
  15. El primer lenguaje de programación que aprendí fue el Fortran 90/95, todo mundo en la escuela estaba emocionado con el Visual Basic y era el que todos querían aprender a usar; pero a mi me llamó más el Fortran por lo que hacía (código optimizado, enfoque al cómputo paralelo y numérico) y de hecho, reté a los VisualBasiqueros a que comparáramos la velocidad de ejecución haciendo lo mismo con un modelo de fenómenos de transporte planteado en ecuaciones diferenciales parciales con un millón de nodos, simplemente Visual Basic nunca pudo llegar a un resultado, siempre la computadora se quedaba colgada, en cambio, en Fortran, esos cálculos los resolvía en 20 minutos.

    Ahora el Fortran, el Fortran 2003, ya está entrando en el paradigma de la orientación a objetos, ya tiene clases, herencia, polimorfismo, sobrecarga, ocultamiento, etc, lo mismo el COBOL, en el estándar 2002. Pese a que Java, C++, C#, Python, Ruby y otros más ganen terreno y adeptos, nunca podrán derribar a los clásicos Fortran y COBOL, se los digo a todos por la experiencia de hacer proyectos en todos y cada uno de los lenguajes que he citado aquí.

    Saludos

    ResponderEliminar
  16. Cuando yo estudiaba el COBOL ya estaba muriendo... 20 años después sigo picando en COBOL y en cualquier otro lenguage que me pidan. Incluso en algún proyecto he seguido utilizando GOTO's porque así lo exigían las normas de la casa. Al fin y al cabo lo que nos da de comer es construir programas, rutinas, servicios, interfaces.... lo que me pidan, bien sea en COBOL, REXX, C, visual.

    Me han gustado muchos los comentarios que he leído ( no los he podido leer todos) y creo que aunque pasen otros "taitantos años " seguiremos teniendo COBOL, FORTRAN, NATURAL, C, C++, ASM.. para muchos años. Puede que cambie el IDE en el que se desarrolle pero en el fondo estarán centralizando el negocio.

    ResponderEliminar
  17. Hola Gente: Estuve leyendo con interés esta nota porque trae a mi mente reminiscencias de mis 25 años, cuando puse mis pocas neuronas al servicio de un IBM S-34 fundamentalmente en CoBOL, y también en RPG, despues pasamos al S-36 y mas tarde a los AS-400. También trabaje 7 años en IMS con COBOL y DB2. Me simpatizó el comentario de "hola Mundo" en Java, y sobre el particular quisiera hacer un comentario. Cuando recién comencé lo primero que aprendí fue que habian lenguajes como el Fortran (en esa época) o el C/C++ (hoy) que permite, o esta diseñado, o permite un pequeño volumen de ingreso de datos, gran cantidad de cálculosinternos devuelve un pequeño volumen de datos de salida. Otros lenguajes (llámese CoBOL, RGP, etc.) que a la inversa, permite faraónicas cantidades de datos de entrada, pequeñas y sencillas algoritmos, y grandes volúmenes de datos de salida, que pueden ser, modificaciones de registros, o altas de registros, o grandes informes impresos, típicos de tratamientos bancarios, o emisión de recibos de sueldo. Cada cosa esta diseñada para cada necesidad, lo que no quita que podríamos clavar un clavo con una llave combinada, o aflojar un tornillo con un cuchillo.
    CoBOL representó un hito en su tiempo y aún hoy, porque cumplió con creces una necesidad y que además se proyectó por 55 años, y va por más. Gracias al CoBOL yo crié mis 13 hijos desde mi silla de ruedas. Por lo que vale este tributo al lenguaje Mainframe por excelencia (a mi humilde entender).
    Gracias por vuestra paciencia!!!

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Soluciones Alchemy Classic 389 elementos

Hace algún tiempo salió una actualización del Juego Alchemy Classic en la que aparecían más elementos (389 en lugar de 238). Aparte de añadir elementos mejoran algunas traducciones en castellano y mejoran la interfaz, aunque todavía hay algún error en algunos nombres de elementos. Aquí os dejo las soluciones para los que estén atascados y no puedan dormir por las noches: Sustancia primaria Aire=Elemento primario  Fuego=Elemento primario  Agua=Elemento primario  Tierra=Sustancia Primaria Arena=Piedra + Aire Piedra=Tierra + Fuego Arcilla=Arena + Pantano Caliza=Tierra + Amonitas Carbono=Fuego + Madera Cloro=Fuego + Sal + Electricidad CO2(Dióxido de Carbono)=Ceniza + Ácido nítrico Electricidad=Relámpago+ Metales Gas natural= Yacimiento de gas + Pozo Helio=Refinería de gas + Gas Natural Hidrógeno=Electricidad + Agua Hielo=Frío + Agua Imán=Piedra + Metales Metano=Deshechos Vegetales + Pantano Oxígeno=Electricidad + Agua Petróleo=Unidad

JAXB: Leer y escribir ficheros XML

Muchas veces en nuestras aplicaciones debemos manejar documentos XML ( Extensible Markup Language ). Este lenguaje se ha convertido en un estándar para intercambio de datos entre programas y aplicaciones a través de Internet. En un esquema XML (o  XSD ) podemos definir los elementos que pueden aparecer en un documento XML así como las relaciones entre los mismos. JAXB ( Java Architecture for XML Binding ) es un estándar Java para transformar un esquema XML (o  XSD ) en una representación a objetos java. Mediante la API de JAXB podemos mapear un objeto Java a un documento XML ( "marshall" ) y el proceso contrario, es decir, a partir de un esquema XML crear su conjunto de objeto Java asociado ( "unmarshall" ). JAXB Resumiendo lo que nos proporciona JAXB es: Generación de objetos Java a partir de un XSD a través de un compilador Proporciona capacidades de marshall/unmarshall (escribir fichero XML desde java y al contrario) Integración con Maven a través de xj

Matemáticas y cine.

El otro día estaba viendo por la televisión una película llamada 21 blackjack . En una escena de la película el profesor de matemáticas ( Kevin Spacey ) le presenta a uno de sus alumnos la siguiente situación: se encuentra en un concurso en la que debe escoger entre tres puertas (1,2 y 3). En dos de ellas hay una cabra, sin embargo en una de las 3 hay un flamante coche nuevo. El alumno responde que quiere abrir la puerta. El presentador, conocedor de lo que hay detrás de cada puerta decide abrir otra puerta diferente mostrando detrás de ella una cabra. El profesor se dirige al alumno y le pregunta, ¿cambiarías la puerta o te quedarías con la puerta que tienes? Muchos de nosotros cambiaríamos de puerta pensando que es una treta del presentador para engañarnos. ¿Cual elegiríais vosotros? Al comienzo tenemos 1/3 de probabilidades de acertar la puerta donde está el coche. Una vez que el presentador abre la puerta con una cabra, la mayoría de gente piensa que hay la misma probabilidad de