Aunque el COBOL no esté dentro de la temática habitual de este blog, si habéis leido mi entrada sobre mis diez años como programador, sabréis que los proyectos a los que me dedico durante el día tienen a ese maravilloso lenguaje como base para el desarrollo. Por este motivo, cada vez que se habla de COBOL salto como un resorte y en uno de esos saltos, Jose Antonio Blanco cometió la locura de dejarme participar en el podcast We.Developers.
Supongo que la audiencia le bajará estrepitosamente. Si queréis echar un vistazo al guión que preparé, es el cuerpo principal de este post.
Citas relacionadas con COBOL
No hay muchas, la verdad. Las mejores son las que hacen un poco de leña con el lenguaje, como la de Dijktstra. Son un poco ofensivas pero la verdad es que son graciosas. Echale un vistazo a estas a ver que te parecen:
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
— Edsger DijkstraCobol has almost no fervent enthusiasts. As a programming tool, it has roughly the sex appeal of a wrench.
— Charles PetzoldA computer without COBOL and FORTRAN is like a piece of chocolate cake without ketchup or mustard.
— John KruegerThe tree large enough that a stake capable of killing COBOL could be fashioned from its trunk has not yet grown anywhere upon the face of this verdant planet.
— Dan Martinez
Como puedes ver, las tres primeras son bastante jocosas con el lenguaje... la última es bastante real y es la que no buscar herir el lenguaje. Vendría a traducirse a algo así como:
El árbol lo suficientemente largo como para que una estaca capaz de matar al COBOL pudiera sacarse de su tronco todavía no ha crecido lo suficiente en ningún lugar de este verde planeta.
- Dan Martinez
Historia
A finales de los años 50, con la aparición de las primeras máquinas comerciales los usuarios empazaban a reclamar a los fabricantes una convergencia en los lenguajes de programación ya que por aquel entonces lo habitual era que cada fabricante tuviera su propio lenguaje para comunicarse con sus máquinas.
Una comisión formada por fabricantes de ordenadores, usuarios, trabajadores de la Universidad de Pennsylvania y el Departamento de Defensa de los Estados Unidos fue la que, después de tan solo seis meses de trabajo, definió el lenguaje COBOL, siglas de COmmon Bussines Oriented Language.
Un par de años antes, Grace Hopper había desarrollado FLOW-MATIC, un lenguaje pionero ya que empleaba instrucciones en ingles para comunicarse con la máquina. Precisamente para poder transformar estas instrucciones en lenguaje máquina, Grace Hopper creó el primer compilador. Este lenguaje FLOW-MATIC fue en el que más se basó la comisión por lo que, a modo de atribución, se llama a Grace Hopper la madre de COBOL ya que en realidad no tuvo un papel tan preponderante en la comisión.
Después de la primera definición del lenguaje en el año 59, se realizaron varias revisiones mayores: en el 68, 74, 85 y 2002. La más frecuente suele ser una mejora del año 89 sobre la del 85. La del año 2002 es la que introduce muchos más cambios como orientación a objetos, soporte a mucho más tipos de variables, generación y parseo de XML pero no está muy implementada.
Características
La principal característica del COBOL está en su propio nombre: es un lenguaje totalmente orientado a la automatización de procesos de negocio. Quizá ese y no otro sea el principal motivo por el que sigue tan vigente. La mayoría de los lenguajes de programación de los que hablamos hoy en día (C, Java, C++, Objective-C, PHP, Javascript, Python, Ruby, etc) sirven para hacer cualquier tipo de programa. Obviamente están orientados a unas determinadas tecnologías o nichos de mercado: juegos, desarrollo web, drivers, aplicaciones de escritorio, aplicaciones móviles, etc pero no hay ninguno que sirva específicamente para hacer un CRM. COBOL fue diseñado específicamente para dar respuestas a una serie de necesidades que tenían las empresas para automatizar sus procesos. Todos querían un único lenguaje que les permitiera hacer eso, automatizaron sus procesos, procesos que en su mayoría no han cambiado en los últimos 50 o 60 años: emisión de recibos, listados de inventario, contratación de productos, control de actividad de procesos, etc.
Otra característica novedosa para la época era que soportaba nombres de variables y de métodos de hasta 32 caracteres. Por esto se habla a veces de la verbosidad del COBOL. El código es muy legible y casi autodocumentado. Una de las cosas que tuvo muy en cuenta la comisión para el diseño del lenguaje es que un Gerente sin formación técnica pudiera leer el código fuente de un programa y entender que es lo que estaba pasando (luego llego el GOTO y acabo con este sueño dorado). Todos los lenguajes de programación tienen una fuerte influencia de la lengua inglesa pero con pocos tienes la sensación de estar hablando con la máquina como con COBOL: Como programador, escribir i++ y que la variable i aumente su valor en una unidad es una sensación de poder. Para un usuario, leer ADD 1 TO INDEX no deja lugar a dudas. Eso no quita para que no haya que poner comentarios: la duda que nos surgirá cuando leamos la instrucción anterior en cualquier lenguaje es: ¿por qué cojones aumenta el indice?
Es un lenguaje de tipado débil. Solo hay dos tipos de variables: numéricas y alfanuméricas. Dentro de las numéricas hay bastantes tipos de empaquetamientos: binario, hexadecimal, decimal comprimido, sin comprimir, editados... un lenguaje dedicado al mundo empresarial tiene que tener una buena gestión de variables numéricas. Es importante destacar que en la definición de la variable se indica explícitamente su longitud, es decir, el número de bytes que necesita. También pueden contruirse arrays.
Las variables pueden agruparse dentro de otras variables (una especie de estructuras de C... pero solo una especie) identificandose la pertenencia a un grupo mediante la indentación por código de nivel. Un ejemplo sería una cuenta corriente: A nivel 01 estaría la variable CUENTA-CORRIENTE, a nivel 05 tendríamos CODIGO-BANCO, CODIGO-SUCURSAL, PRIMER-DIGITO-CONTROL, SEGUNDO-DIGITO-CONTROL y NUMERO-CUENTA. Si utilizamos numéricos de base decimal solo ocuparíamos 20 bytes, es decir, los 20 bytes estarían divididos en cinco bloques de 4, 4, 1, 1 y 10 bytes.
01 CUENTA-CORRIENTE
05 CODIGO-BANCO PIC 9(4).
05 CODIGO-SUCURSAL PIC 9(4).
05 PRIMER-DIGITO-CONTROL PIC 9.
05 SEGUNDO-DIGITO-CONTROL PIC 9(1).
05 NUMERO-CUENTA PIC 9(10).
No es necesario definir el tipo y la longitud de la variable de primer nivel. Siempre será alfanumérica y ocupara los mismos bytes que las variables que agrupa. En este caso, si queremos tratarla como numérica tendríamos que redefinirla como numérica. Esto se hace con la instrucción REDEFINES.
01 CUENTA-CORRIENTE-NUMERICA PIC 9(20).
01 CUENTA-CORRIENTE REDEFINES CUENTA-CORRIENTE-NUMERICA.
No hay variables de tipo booleano, se construyen mediante niveles especiales de indentación pero en realidad se parecen mas a un enum. La diferencia con los enum es que podemos evaluar variables numéricas y alfanuméricas.
La estructura de un programa COBOL es muy rígida: Consta de cuatro partes aunque no todas son obligatorias: - Una primera de encabezado (IDENTIFICATION DIVISION), donde se pone el nombre del programa, el autor, las fecha de compilación, etc. - Una segunda de configuración del entorno (ENVIRONMENT DIVISION), cuando el programa accede a ficheros esta es la sección donde se informan las características de dicho fichero, si en lugar de trabajar con punto como separador decimal se utilizase la coma se indicaría en esta sección. - Una tercera para los datos (DATA DIVISION) donde se definen todas las variables que va a utilizar el programa, se aporta algo más de información sobre los ficheros que se hubieran definido en la sección anterior, etc. - Una cuarta para las instrucciones (PROCEDURE DIVISION) que sería lo que actualmente entendemos por programa. Es donde se tira el código.
Además de la rigidez de la secciones, el número de columna donde se escribe también es muy importante: los seis primero caracteres están reservados, el séptimo solo se utiliza para comentar o descomentar el código. Del 8 al 11 están reservados para la identificación de las divisiones y las secciones, los niveles 01 de variables y las definiciones de los ficheros. Esto es lo que se conoce como zona A. De la 12 a la 72 es la zona normal para codificar y se conoce como zona B. De la columna 72 a la 80 tampoco se debe escribir ya que el compilador no va a leer lo que ahí escribamos. Esta estructura procede de la forma original de programa en COBOL. Al principio no había IDE´s si no que se usaban fichas de programación. Estas fichas se introducían en los compiladores y si todo era correcto se generaban las tarjetas perforadas con las que funcionaban los mainframes. Aunque ya no haya tarjetas perforadas y se utilicen IDE´s para la codificación, estas restricciones se mantienen en los compiladores actuales.
Plataformas y Variantes
Aunque la plataforma habitual son los Mainframes se pueden encontrar programas para ordenadores personales. En este punto puedo meter la pata porque el entorno que yo conozco es el mainframe. Aunque el lenguaje COBOL es el mismo, a la versión del lenguaje que se utiliza para desarrollar aplicaciones que luego van a correr en sistemas operativos de ordenadores personales se la llama RM-COBOL. Hay empresas actuales que comercializan productos para seguir desarrollando y manteniendo estos programas como MicroFocus.
En entorno mainframe la versión más extendida es la del año 85 revisada en el 89. En algunos lugares se puede encontrar una versión denominada ENTERPRISE que además se actualiza con más frecuencia. Cuando me han hablado de ella, lo que más me han destacado es que permite trabajar con variables numéricas de mayor tamaño por lo que se usa en entidades financieras en las que los importes son muy elevados y existe riesgo de perder cifras significativas.
La versión de 2002 "oficializa" algunos desarrollos de terceros existentes que permiten embeber código COBOL en servicios .NET, Java, etc. Yo no he conocido a nadie que haya hecho algo de esto. No se si será más habitual en otros tipos de clientes, en otros países o si será algo menos frecuente como los programas RM-COBOL.
Entornos de desarrollo
Aunque se puede programar en cualquier editor de notas. He conocido gente que escribían los programas en Ultra-Edit, otros que lo hacían en SPFPC, un programa MS-DOS con el que se puede escribir un programa, compilarlo, ejecutarlo, etc.
IBM, que es la reina indiscutible en este baile, tiene herramientas de desarrollo COBOL sobre Rational por lo que los programadores de COBOL no tendríamos nada que envidiar a los de Java, aun así, creo que lo más normal si se trabaja en entorno mainframe es usar el IDE que provee el sistema operativo del mainframe o algún otro IDE de terceros que se instale en el mainframe.
El sistema operativo Z/OS, es el que actualmente traen los ainframes de IBM. Este sistema operativo incluye las funcionalidades originales del MVS pero se le ha agregado compatibilidad con UNIX, soporte para espacios de memoria virtual lo que hace que los mainframe no solo sirvan para tener las funciones clásicas. Entre las características que tiene este sistema operativo se encuentra la de traer de serie un entorno de desarrollo en el que crear, compilar y ejecutar programas contra el propio mainframe... y desde el propio mainframe. Porque no hemos de olvidar que el acceso a este bicharraco se hace siempre desde terminales tontos. En este entorno de desarrollo, cada usuario puede tener su configuración,... el sistema operativo es multiusuario y multitarea. Yo puedo conectarme en mi pc de Madrid al Host de mi empresa, desde un portátil en el AVE Madrid-Barcelona, en el equipo de un compañero en la oficina de Barcelona... y si lo hago con mi usuario y contraseña siempre estaré viendo mi configuración, mis programas, mis librerías y mis permisos. Esto es así desde los años 70... ¿Cuantos años lleva Linode ofreciendo estas ventajas a los desarrolladores? Si, no se puede comparar lo que puede desarrollarse en un mainframe con lo que podemos hacer desde una virtualización de Linode pero la reflexión que yo siempre me hago es que los ciclos también llegan a la tecnología.
Como en cualquier otro lenguaje, COBOL no sería nada si no fuera por otras tecnologías que están a su alrededor. Igual que PHP casi siempre va acompañado de MySQL y de un servidor Apache, el COBOL siempre va rodeado de una serie de términos (tecnologías) que suelen verse en ofertas de empleo. Se suelen buscar expertos en COBOL-CICS-DB2 con conocimientos de JCL, VSAM, IMS, SORTFD o cosas así. Salvando las distancias y pidiendo perdón de antemano a los compañeros del PHP por las confianzas que me estoy tomando, COBOL-CICS-DB2 es el LAMP, MAMP o WAMP del PHP:
CICS es el nombre del terminal de teleproceso que incluyen los mainframes y que son los que permiten las conexiones on-line al sistema desde cualquier terminal tonto o emulador de terminal tonto. Es también el encargado de servir información a los servicios web (estos ya desarrollados en cualquier lenguaje aunque Java es un habitual) que se conectan al CICS a través de algún Gateway. No requiere unos conocimientos adicionales al lenguaje, solo que hay una serie de instrucciones en el lenguaje que solo sirven cuando el programa se va a utilizar en una instalación CICS.
DB2 es una base de datos relacional, igual que MySQL, SQL Server, Oracle, etc. Es un producto de IBM que se puede instalar en distribuido y en mainframe. Al igual que el CICS, el único conocimiento adicional que se requiere es el de saber SQL, ya que es como se accede a la base de datos desde un programa COBOL.
IMS es un gestor de bases de datos jerárquicas, no es lo más actual pero todavía se sigue usando en algún sitio.
VSAM es un sistema de almacenamiento indexado. Aunque también esta muy desfasado, todavía es posible encontrar instalaciones que los usan. Los ficheros de tipo VSAM se usan para hacer la persistencia del DB2 así que para IBM siguen siendo de gran importancia.
JCL es el sistema que se utiliza para ejecutar un proceso Batch. No sirve solo para procesos COBOL sino también para lanzar muchas utilidades que vienen en el Sistema Operativo de los mainframes: utilidades del DB2, procesos de ordenamiento de ficheros planos con SORTFD. Es como un fichero de configuración o mejor, como una plantilla en la que se le dice al sistema operativo el entorno en el que se quiere ejecutar el programa, que programa es el que se va a ejecutar, quien es el usuario que lo lanza para ver si tiene permisos, donde están los ficheros, que estructura tienen, que tamaño se les ha definido, etc. Quizá es a la hora de preparar un JCL cuando mayor es la sensación de estar trabajando con una tecnología con más de 50 años de historia: se habla de fichas, cilindros, pistas, cintas...
Para que se usa hoy en día
Hoy en día el COBOL está presente en multitud de situaciones cotidianas. Casi todos los sistemas bancarios están desarrollados en COBOL: ordenes de transferencia, venta de acciones, de valores, conciliaciones bancarias, procesos de facturación de grandes compañías telefónicas, o de grandes cadenas de supermercados. Aplicaciones completas de gestión de compañías de seguros, procesos de control de centrales eléctricas, aplicaciones de inventario de almacén... y así hasta el infinito. Cuando se habla de la longevidad del COBOL no es porque queden muchos procesos antiguos que nadie se atreve a migrar, es que como esos desarrollos no están aislados, se sigue haciendo nuevo desarrollo en esta plataforma.
Quizá no somos conscientes porque la capa de presentación que vemos nosotros es una aplicación de escritorio tipo Windows, o una página web pero el COBOL está ahí, por debajo. Incluso en alguna aplicación de un dispositivo móvil, los datos son extraídos por un programa COBOL.
Si alguien se ha fijado alguna vez en unos ordenadores todo-en-uno que suele haber en El Corte Ingles en los que te buscan si un articulo está agotado o si lo puedes encontrar en otro centro a través de una pantalla negra en la que van tecleando y pulsando las teclas de función para moverse por las pantallas habrá visto un terminal CICS. La agencia de viajes y los seguros de El Corte Ingles también se contratan con un terminal CICS.
Para mal o para bien, procesos muy críticos para compañías que mueven un gran volumen de dinero están desarrollados en COBOL, podrían haberse desarrollado en cualquier otro lenguaje más moderno y con más prestaciones pero se desarrollaron en COBOL. A día de hoy, plantearse una refactorización completa de esos programas a otro lenguaje no solo requiere mucho tiempo si no también una gran valentía, y en realidad hay que plantearse también si compensa el cambio.
Esta claro que IBM tiene bien agarrados a los departamentos de sistemas que tienen un mainframe... pero también hay que entender que no todas las empresas son como Facebook o Twitter que pueden plantearse un gran cambio de tecnología. Aunque parezca mentira, en esas grandes entidades financieras, compañías telefónicas, cadenas de alimentación hay departamentos de Sistemas que no son muy grandes y que tienen que hacer frente a desarrollos nuevos y a mantenimientos muy fuertes por lo que no es de extrañar que sigan apostando por conservar esa tecnología. Una tecnología que no está dando ningún problema, por otro lado, ¿hay que cambiarla simplemente porque sea vieja o no haya muchos programadores?
Sobre el número de programadores y su cotización también hay que aclarar algunas cosas. Lo primero es una triste noticia: la cotización de un programador COBOL no está unida a un sueldo alto. Gana como cualquier otro programador experimentado en Java, .Net o lo que sea. Aunque no hay una necesidad tan alta de programadores COBOL como hubo en los años del efecto 2000 o del cambio de la peseta al euro, se siguen haciendo muchos mantenimientos y nuevos desarrollos que requieren programadores COBOL y estoy convencido de que la demanda no disminuirá en los próximos años.
Futuro
Hay una frase que se le atribuye a Bill Gates que dice: "no se que lenguajes de programación habrá en el futuro pero COBOL estará allí". Yo estoy totalmente de acuerdo.
Como ya he comentado en el apartado anterior, el COBOL está presente en procesos de vital importancia para empresas que mueven muchísimo dinero y además está presente en los procesos que garantizan que esas empresas sigan ganando dinero. Mientras IBM siga sirviendo Series Z estos procesos habrá que seguir manteniéndolos. Además, a medida que van apareciendo nuevas tecnologías, estas empresas no optan por sustituir los procesos COBOL por procesos codificados en lenguajes más modernos si no que buscan formas para que los procesos COBOL sigan funcionando: es posible enviar un email desde un JCL, perfectamente podría enviarse un SMS, hacer una notificación PUSH o lo que venga a continuación.
Está claro que el COBOL no se va a utilizar para programar la próxima Red Social, o para hacer el Backend de un whatsapp, pero las empresas que mantienen procesos COBOL también utilizan tecnologías actuales que se han podido integrar así que a medida que sigan apareciendo nuevas tecnologías y estas se puedan seguir integrando, el COBOL seguirá.
A veces aparecen corrientes a favor de la desaparición del COBOL, o que auguran el final de IBM... hay hueco para todos y lo seguirá habiendo.
¿Como se puede aprender COBOL?
Los programadores COBOL son como los Sith, siempre van juntos maestro y aprendiz... es una tradición oral que va pasando de generación en generación y de la que nunca queda constancia escrita... o casi.
Ahora más en serio, por hacer caso a Dijkstra, las universidades no enseñan COBOL, tampoco enseñan Objective-C... las universidades son así. Yo aprendí a programar en COBOL en una academia, a través de una oferta de trabajo para gente que no tuviera experiencia en programación o muy poca experiencia. No se anuncian tanto como las que te enseñan a programar en Java o a hacer aplicaciones para iOS o Android pero buscando un poco se pueden encontrar. En IBM los tienen pero son bastante caros. Actualmente, como para cualquier lenguaje, se puede aprender a programar en COBOL a través de internet: habrá que buscar un emulador de un Host, una licencia de MicroFocus y buscar algún tutorial. Si que es cierto que conseguir un mainframe no es algo que pueda hacerse a través de ebay por lo que algunas de las características del lenguaje más relacionadas con esta arquitectura se tendrán que programar en alguna academia buena o directamente en el centro de trabajo.
Enlaces de interes:
Su historia, en la wikipedia
Su historia, en Alt1040
Foro de cobol en castellano
Empresa comercializador de RM/COBOL
Curiosidad, el blog de alguien que quiere aprender COBOL en 2012
La Biblioteca de Alejandría: La documentación de IBM
Hasta Jeff Atwood habla de él