La respuesta nos lleva al Departamento de Defensa de los Estados Unidos, donde en 1958 se desarrolló una aplicación encargada de gestionar los contratos de los servicios para la administración. Aquel programa se desarrolló en el veterano COBOL, y es tan complejo y crucial que sigue funcionando hoy en día casi de la misma forma que hace 60 años.
#4:
Yo tengo todavía un par de clientes con programas de 1992, en MS-DOS y no los quieren cambiar porque funcionan perfectamente y ahí están, dando caña cada día
Yo tengo todavía un par de clientes con programas de 1992, en MS-DOS y no los quieren cambiar porque funcionan perfectamente y ahí están, dando caña cada día
#25 Porque el que escribió el código no es que esté jubilado, es que ya cria malvas desde hace años.
Y por supuesto, nadie se interesó por esa aplicación del "frikazo del cobol".
#25: Documentando el código o valorando más el aprendizaje de Cobol se podría solucionar, que aquí parece que solo existe la culebrita bicéfala (llamadas Dos y Tres) y JavaScript (sí, ese lenguaje de programación que hasta hace poco todas las variables podían ser cualquier cosa, no podías declarar un int, un double o un float como tal).
Tampoco digo de volver todos a Cobol, sino de no pensar que la programación consiste en que las empresas y particulares usen solo los lenguajes de programación que a nosotros nos gustan.
#37 ya, pero eso es un bucle fácil de leer, con una variable con un nombre claro. Más fácil aún algo tipo:
For (Client client: clients) cuando tienes objetos tipo lista en lenguajes fuertemente tipados.
Ahá, pero luego te encuentras con lenguajes que no están fuertemente tipados, con nombres de variables de mierda, con firmas de escribir muy eficientes pero crípticas de leer (como las lambda expessions en Java)
Cobol es un coñazo de escribir pero fácil de leer y generalmente se seguían procesos muy estrictos en los bancos, lo que hacía que no hubiera variables con nombres chungos.
Por cierto, los lenguajes no fuertemente tipados en entornos empresariales me parecen una muy mala decisión
#28 yo por lo que tengo visto en múltiples proyectos apenas se documenta.
Se tienen recogidas las múltiples historias de ususario pero mantener un documento funcional de la aplicación no se hace.
Quizás al principio por cosas de la primera entrega pero los sucesivos manteninientos solamente se cubre la solicitud y ya.
Eso le añades unos años y la documebtación se traduce en leéte el código y esperar que el Dios de la aplicación se acuerde.
#14 "El servidor en el que se ejecuta es modesto: un IBM 2098 E-10 de 2008 con 8 GB de RAM cuya potencia de proceso es de 398 MIPS."
Eso por que no querrán renovarlo y pasarse a un flamante IBM Z15:
""un sistema z15 puede ejecutar hasta 1 billón de transacciones web seguras al día. IBM z15 ofrece un alto rendimiento con un máximo de 190 núcleos configurables y hasta 40 TB de memoria. Escale para crecer con un máximo de 2,4 millones de contenedores en un solo sistema." https://www.ibm.com/es-es/marketplace/z15/details
#12 ¿Sin hardware para ejecutar cobol en un ibm? Ya se ocupará mucho ibm de que eso no ocurra, caiga quien caiga. Antes cierran la fábrica de hardware que dejan de dar soporte al lenguaje por excelencia de una porción tan enorme de mainframes como las que ahora corren cobol.
#20 Ya, pero ahí está el tema. Trabajar con pesetas era trabajar con números enteros, y no había problemas de redondeo. La conversión a euros no era tan trivial en aquel monstruo con overlays y base de datos propia.
#16: Sí, porque si pones otro ordenador tienes que homologarlo (una bula papal es más barata de conseguir).
¿Has visto que la palabra "homologación" no tiene ni S, ni E ni Y? Es porque las homologaciones son tan caras que esas letras de estar, serían convertidas en símbolos monetarios ($€ y ¥) y usados para pagarlas.
A ver,...mola el artículo, pero no me lo creo. No se puede estar usando un software como ese, sobre un hardware como ese, por razones como "esa".
Se podría actualizar "fácilmente" hoy en día, cualquier cárnica/consultora te lo despacha mejor o peor en un breve lapso de tiempo. Lo de usar disquetes de 8"...anda ya. Sería super fácil conectar uno de 3,5" con la interfaz adecuada...
Los motivos de que siga usando (si realmente se usa), vayan ellos a saberlo. Pero que eso te lo actualiza un chaval de dam de grado medio, también
Yo recuerdo con cariño aquel 2002 en el que un colega me pidió que le pasara al euro un programa de gestión que le hice en Turbo Pascal allá por el año 1992.
El cobol ha tenido la suerte de ser el primero en implantarse en la banca,por eso es costoso cambiar servidores y programas.El cobol funcionando en unix y teniendo que pagar un soporte muy caro para los tiempos modernos.
Desde que ibm comprò red hat,estan quitando el.cobol como el banco santander.
Comentarios
Yo tengo todavía un par de clientes con programas de 1992, en MS-DOS y no los quieren cambiar porque funcionan perfectamente y ahí están, dando caña cada día
#4 Yo tengo por lo menos 50 instalaciones en MS-DOS con Hardware pinchado en Bus ISA.
#7 Hotia. Madre mía, que tiempos ¿ 4.77 mhz ?
#8 Me imagino que los ordenadores de #7 no tengan un procesador Intel 8088 como los que metían en los IBM 5150
#4 Y hacen bien.
Regla número uno en informática: si funciona bien, NO LO TOQUES.
#19 regla número uno en la vida
#19 #22 regla numero cero de la informatica, no dejes que algo deje de funcionar por no tocarlo, que te puedes encontrar sin repuestos.
#19 Eso es hasta que el usuario decide hacer cambios.
Entonces empiezan los parcheos y sudores frios por jugar con la caja negra que nadie entiende.
#25 Porque el que escribió el código no es que esté jubilado, es que ya cria malvas desde hace años.
Y por supuesto, nadie se interesó por esa aplicación del "frikazo del cobol".
#25: Documentando el código o valorando más el aprendizaje de Cobol se podría solucionar, que aquí parece que solo existe la culebrita bicéfala (llamadas Dos y Tres) y JavaScript (sí, ese lenguaje de programación que hasta hace poco todas las variables podían ser cualquier cosa, no podías declarar un int, un double o un float como tal).
Tampoco digo de volver todos a Cobol, sino de no pensar que la programación consiste en que las empresas y particulares usen solo los lenguajes de programación que a nosotros nos gustan.
#28 El COBOL está tirao de leer. Hay que documentar, sí, pero el código COBOL siendo un coñazo de escribir, es muy fácil saber lo que hace
#35: Sí, pero mejor comentar de más que de menos.
A ver, tampoco hace falta llegar a esto:
for(int i=0; i
#37 ya, pero eso es un bucle fácil de leer, con una variable con un nombre claro. Más fácil aún algo tipo:
For (Client client: clients) cuando tienes objetos tipo lista en lenguajes fuertemente tipados.
Ahá, pero luego te encuentras con lenguajes que no están fuertemente tipados, con nombres de variables de mierda, con firmas de escribir muy eficientes pero crípticas de leer (como las lambda expessions en Java)
Cobol es un coñazo de escribir pero fácil de leer y generalmente se seguían procesos muy estrictos en los bancos, lo que hacía que no hubiera variables con nombres chungos.
Por cierto, los lenguajes no fuertemente tipados en entornos empresariales me parecen una muy mala decisión
#28 yo por lo que tengo visto en múltiples proyectos apenas se documenta.
Se tienen recogidas las múltiples historias de ususario pero mantener un documento funcional de la aplicación no se hace.
Quizás al principio por cosas de la primera entrega pero los sucesivos manteninientos solamente se cubre la solicitud y ya.
Eso le añades unos años y la documebtación se traduce en leéte el código y esperar que el Dios de la aplicación se acuerde.
¡Larga vida al COBOL!
Lo que funciona no hay razón para abandonarlo.
#2 Sí la hay: mejorarlo.
#5 mejorarlo, optimizarlo, tener una alternativa para cuando el hardware sobre el cual funciona deje de funcionar....
#6 #12 Antes te deja de funcionar tu hardware orgánico que las maquinas que están con cobol. (Firmado un no-programador de Cobol)
#13 pues. la maquina sobre la que esta funcionando es del 2008, asi que al menos ha dejado de funcionar 1 maquina. #12
#13 Joder que veloz ha sido #14 , nada más que decir
#15 Vale, vale ya. Que me deprimís mas que picar código en microsoft visual basic.
#14 Ups, eso me pasa por ir de listo.
#14 "El servidor en el que se ejecuta es modesto: un IBM 2098 E-10 de 2008 con 8 GB de RAM cuya potencia de proceso es de 398 MIPS."
Eso por que no querrán renovarlo y pasarse a un flamante IBM Z15:
""un sistema z15 puede ejecutar hasta 1 billón de transacciones web seguras al día. IBM z15 ofrece un alto rendimiento con un máximo de 190 núcleos configurables y hasta 40 TB de memoria. Escale para crecer con un máximo de 2,4 millones de contenedores en un solo sistema."
https://www.ibm.com/es-es/marketplace/z15/details
Ni Batman tiene uno de esos.
#2 No tener que pagar una millonada cuando el programador de 3500 años se jubila...
Mantenibilidad...
Que tiempos aquellos, en los que todavía no se había inventado la obsolescencia programada.
#3 Todo componente electronico tiene una vida util, la programes o no. ya veremos que les pasa cuando se queden si hardware para el software.
#12 ¿Sin hardware para ejecutar cobol en un ibm? Ya se ocupará mucho ibm de que eso no ocurra, caiga quien caiga. Antes cierran la fábrica de hardware que dejan de dar soporte al lenguaje por excelencia de una porción tan enorme de mainframes como las que ahora corren cobol.
#39 A mi no me parece una gran idea atarse de esa manera, pero bueno, supongo que en ese mundo no habra muchas opciones.
#3 lo que me sorprende que no hayan tenido la necesidad en 60 años de cambiar el modelo de gestión.
Esto ne suena más a caja negra + gestionar dinero, combo perfecto en cualquier banco.
#20 Ya, pero ahí está el tema. Trabajar con pesetas era trabajar con números enteros, y no había problemas de redondeo. La conversión a euros no era tan trivial en aquel monstruo con overlays y base de datos propia.
#21 Dios, las odiosas reglas de reondéos del euro, qué pesadilla en aquél momento.
Como Saber y Ganar.
Yo he visto pruebas de reflejos para el psicotécnico del carnet de conducir con viejos MSX (ostia ahora dudo si era un amstrad) con cartucho.
#16: Sí, porque si pones otro ordenador tienes que homologarlo (una bula papal es más barata de conseguir).
¿Has visto que la palabra "homologación" no tiene ni S, ni E ni Y? Es porque las homologaciones son tan caras que esas letras de estar, serían convertidas en símbolos monetarios ($€ y ¥) y usados para pagarlas.
#33 Tron Guy era el encargado de un emulador de estas máquinas, lo sé en qué estado anda.
A ver,...mola el artículo, pero no me lo creo. No se puede estar usando un software como ese, sobre un hardware como ese, por razones como "esa".
Se podría actualizar "fácilmente" hoy en día, cualquier cárnica/consultora te lo despacha mejor o peor en un breve lapso de tiempo. Lo de usar disquetes de 8"...anda ya. Sería super fácil conectar uno de 3,5" con la interfaz adecuada...
Los motivos de que siga usando (si realmente se usa), vayan ellos a saberlo. Pero que eso te lo actualiza un chaval de dam de grado medio, también
#11 en los bancos pasan estad cosas, meter por encima web pero ppr debajo el sistema caja negea intocable
#24 Doy fe.
Yo recuerdo con cariño aquel 2002 en el que un colega me pidió que le pasara al euro un programa de gestión que le hice en Turbo Pascal allá por el año 1992.
Le dije que ni de coña, claro.
#9 Si hiciste bien el programa, el cambio debería ser trivial.
#9 Que pasó, ¿no quiso hacerte una paella a las doce de la noche y bailar con un traje de pollo?
#30 Ni aún así.
Y nadie sabe por qué (titular Xatakoso)
El cobol ha tenido la suerte de ser el primero en implantarse en la banca,por eso es costoso cambiar servidores y programas.El cobol funcionando en unix y teniendo que pagar un soporte muy caro para los tiempos modernos.
Desde que ibm comprò red hat,estan quitando el.cobol como el banco santander.