Y los jefes de los departamentos de informática de las grandes empresas (e incluso los grandes jefes de las grandes empresas) lo son más todavía.
Y a pesar de que parece que la informática por todo lo de moderno e innovador que pueda tener no es inmune a dichas costumbres. Podemos ver como todos los días casi aparecen nuevos lenguajes de programación, nuevos sistemas de bases de datos, nuevos paradigmas de programación, interfaces mejores, procesadores cada vez más potentes… pero al final los grandes jefes siguen con lo que conocen: el Cobol y los Host o Mainframes…
Ahora mismo en mi empresa de por las mañanas estamos inmersos en un cambio de plataforma… cambio de qué… pasamos de host Bull a uno Ibm, pero de cambio de plataforma nada, seguimos con Cobol y con una estructura centralizada.
Yo pensaba que cuando los jefes que comenzaron programando en Cobol se jubilasen, empezaríamos a ver algunos cambios… error, (ahora tenemos jefes jóvenes, que no han programado en Cobol…) la gente sigue con las costumbres heredadas.
No voy a discutir la potencia de un mainframe y el cobol, su seguridad… pero si que me parece cuanto menos curioso que nadie se plantee un cambio de estrategía. Dado que en un proceso de este calibre lo vas a tirar todo a la basura y vas a empezar de nuevo, pues a lo mejor podríamos poner algo más avanzados.
Si has estudiado informática de forma reglada (o como yo a salto de mata) recordarás la innovación de la programación estructurada (gosub en lugar de goto) luego vino la programación orientada al objeto (estoy mirando la librería y tengo varios tochos que me amanazan con el fuego del infierno si no piendo en métodos, clases y objetos…) pero al final el corazón de mi empresa sigue funcionando con moves to… no consigo entenderlo, me supera.
Claro que en algunos sitios si que se innova, pero claro lejos de aquí. Un bicho como Google, pues no usa cobol ni usa mainframes… pero claro es que allí la gente se arriesga e investiga y tienen la mente más abierta… y aquí pues seguimos comprando máquinas de vapor, eso si más modernas, pero siguen siendo máquinas de vapor. Es como la historia de las locomotoras, en los años 30 y 40 del siglo pasado, las máquinas de vapor alcanzaron el cénit de su gloria, pero fue efímera; el diesel y el motor eléctrico las superaban, pero las compañias ferroviarias no conocían otra cosa y el cambio tardo más de 30 años en realizarse. Aquí tenemos el cobol (vapor) que no hace mal su tarea, pero que alguien se quite las anteojeras y mire a su alrededor, que hay más opciones…
Pero lo fácil es seguir el camino de todos, así será difícil fracasar pero nunca conseguiremos destacar del resto.
Anterior y Posterior
8 Comentarios
Comentarios Cerrados
El mótivo de de que sigan con cobol es que los programas van a ser prácticamente los mismos.
Podrán coger a un grupo de programadores cobol (gente sin experiencia con un cursillo de diez días) para que migren los programas, salvando las minímas diferencias de sintaxis.
No creo que se haga un rediseño de la aplicación.
Se pasarán a IBM o porque la máquina de Bull se queda pequeña o porque Bull dejará de dar servicios.
Yo estuve en una administración autonómica en la que se intento cambiar el programa de contabilidad de Cobol a Oracle, se contrató a la propia Oracle, estuvieron cinco años programando, se hizo todo nuevo, y al final se tiró todo a la basura (salío en prensa el despilfarro antes y después), y al final siguen con Cobol.
Lo bueno de los programas Cobol en grandes sitios (banca, administración pública, seguros) es que si se siguen estándares de programación.
Los gotos están prohibidos en todos los sitios en los que he trabajado (un banco, dos compañias de seguros, una administración y una universidad).
Y la programación cobol estará hecha a base de programas pequeños que se van llamando unos a otros.
Has comentado que Google no trabaja así, pero lo que hace google es basicamente buscar cadenas de texto, para eso el cobol no sirve, ni el java, pero para las aplicaciones de banca, impuestos, y demás el cobol funciona muy bien. Los hosts de IBm (y supongo que los de Bull también) tienenun código máquina que es casi Cobol, un move se corresponde con una instrucción máquina, lo mismo que un perform.
La programación cobol está muy estandarizada, en muchos sitios trabajan con ‘software factorys’, en las que se se tienen 8 o 9 tipos de programas interactivos y 8 ó 9 de programas batch. Con esa topología se hace todo, y los programas son pequeños, manejables, muy fáciles de probar y de leer, ya que el cobol es autocomentado.
Coincido con xlopez en todo lo que ha dicho. ¿Para qué vamos a montar un servidor web+servidor aplicaciones+2 años de becarios programando servicios web+1 año hasta estabilizar el programa si simplemente queremos una cosa que haga la contabilidad?
Saludos.
El problema de los mainframes es la centralización, que es el mismo problema que tiene Cobol. Si tu empresa no crece o solo crece jerarquicamente de manera local no vas a necesitar más, los usuarios serán más pero en el mismo edificio con lo que solo necesitas tu red local ampliada.
Pero en la banca y la administración al final se han tenido que hacer birguerías para descentralizar ciertos procesos y aún así muchos cálculos siguen centralizado. He visto cientos de terminales OS/2 con tarjetas de emulación de terminal para adaptarse a entornos antiguos e ir conmutando entre escritorio y terminal, yo mismo trabajé así una temporada con AS400.
En la administración (por lo menos en la que yo trabajo, aunque no soy funcionario) los cálculos de nómina por ejemplo son centralizados, pero los datos se introducen distribuidamente por eso ha habido que hacer una migración de entorno para facilitar al usuario la introducción de datos y gozar de los beneficios de nodos distribuidos y clusters de servidores de aplicaciones; antes era lo mismo solo que había un pedazo ordenador que cuando se calcula la nómina nadie podía entrar a trabajar, eso por mucho que digan es un atraso.
Lo de mantener cobol es simplemente un problema de economía, si no aporta beneficios no merece la inversión de cambiarlo, no me creo que tenga esa arquitectura más seguridad (no digo ya estabilidad) que los sistemas que hay hoy día, por muy robusto que fuera el SO, el problema es que antes manejando terminales eran 1000 y ahora son 200.000 y para que eso haya pasado, ciertamente ha habido que cambiar algunas arquitecturas (en los sistemas y en los cerebros de algunos marmolitos).
No puedo entrar a valorar tan especificamente los procesos que se usan para programar. Lo que si quizas estamos acostumbrados es al tradicional “si esto funciona, que siga”, aqui nadie arriesga, hay poca innovacion, da miedo el cambio, arriesgar capital,etc. Despues no queremos comparar con otros paises, incluso de la zona europea pero no hay nivel,creo.
Xlopez y Coincido: las razones de que se implante Cobol las tengo claras, lo que yo intento trasladar es que nadie se ha planteado hacer ningún otro tipo de planteamiento, sobre todo si tenemos en cuenta que la migración es total; me explico no aprovechamos nada del código antiguo, ningún programa, todo se hace de nuevo. En estas circunstancias la ventaja de heredar el código se pierde y puede que otro planteamiento estuviese en igualdad de condiciones para considerarse.
Kike: tu plantemiento es más parecido al mío. Uno de los problemas que le veo a los Mainframes y al Cobol es justamente su diseño antiguo. Está muy bien para hacer transacciones cortas y simples, del tipo de hacer un ingreso, cobrar una compra en tarjeta de crédito… pero hoy en día en las Oficinas bancarias se hacen operaciones muy complejas: solicitudes de préstamos, seguros… que requieren muchos datos y un interfaz rico, y ahí el Cobol y el modelo de Mainframe se muestra pesado. De todas maneras como me estoy enrollando mucho, voy a ver si aclaro las ideas y preparo otra entrada sobre el tema.
Por cierto, gracias por los comentarios, normalmente estas entradas más “raras” suelen tener pocos comentarios.
Hola Tendero, yo tampoco creía que esto creciera tanto.
Como tu dices el intefaz de usuario de los programas cobol es muy espartano, por eso en la mayoría de sitios en los que se usa cobol (o en los sitios en los que he trabajado yo) se usa una arquitectura mixta.
Para la faena de verdad (las transacciones, el acceso a la base de datos, etc.) se usa cobol, mientras que para la presentación visual se usa o bien java (servlets + jsps) o bien clientes pesados (con .net).
Xlopez:
Efectivamente, nosotros con el sistema antiguo teníamos una estructura de cliente pesado que comenzó con Visual Basic y evolucionó hacia .net. Además apoyado con bases de datos SQL…
En el sistema nuevo esta basado en java, pero me llama la atención que tenemos consultas donde para aumentar la velocidad el usuario se aburre en los desplegables (envían de 50 en 50 items…) con lo cual para que el Host no se agobie, agobiamos al usuario y al cliente.
Tal vez la solución sea tener bien diferenciadas las tareas del ordenador central y el cobol por un sitio y las del clinte final por otro.
Os comento mi experiencia. Llevo 20 años programando, desde el C, BASIC, COBOL, DELPHI, VISUAL BASIC etc. Pero al final, despues de estar cambiando de lenguaje porque dicen que uno es mejor que otro, te das cuenta de que no.Tenemos que hacernos una pregunta ¿ Porque ha durado tanto tiempo el COBOL ? ¿ Porque no habia otro lenguaje ? no, no nos engañemos, siempre han salido lenguajes nuevos diciendo que van a desbancar al COBOL, pero al final siempre se quedan a mitad de camino. El COBOL fue concebido para GESTION pura y dura, y en eso nadie le gana. Sus ficheros indexados son lo mas robusto que he visto en mi vida (hasta ahora nunca le he visto el limite), y eso que he trabajado con varias bases de datos, pero cuando un cliente ha estado trabajando con un programa en cobol, y está acostumbrado a una rapidez y una solidez, cuando le cambias el lenguaje (que es lo de menos) y le pones una base de datos, ahí es cuando empiezan los problemas, a decirte que ¿ porqué esto va ahora mas lento que antes ?.Con todo esto quiero decir que si vas hacer una aplicacion de gestion, el cobol sigue siendo la mejor opcion si quieres estabilidad y rapidez, si quieres hacer otras cosas quizas no. Ademas es el unico lenguaje que sigue un estandard para programar, hay unas sentencias fijas para todos los compiladores, y otras de propietario de cada compilador para que haga algo en concreto. El cobol ha seguido actualizandose desde sus origenes, no se parece en nada a los coboles de antaño, hoy por hoy el cobol puede hacer lo que quieras, y si mañana tu proveedor de cobol dice que no sigue actualizando tu compilador, pues vale, te cambias de compilador y a seguir programando, cosa que no ocurre con los demas lenguajes, simplemente te quedas en la estacada, y a aprender otro lenguaje si quieres seguir trabajando.
Con todo esto no quiero decir que sea el mejor lenguaje, ni un defensor a ultranza de el, pero si que tengo que decir que a mi me sigue dando muchas satisfacciones con el cliente final, y hasta ahora no ha venido ninguna empresa de programacion a quitarme el sitio, que creo que eso es lo que queremos todos los programadores.
Un saludo a todos.
Rafa