479 meneos
6412 clics

Los bancos seguirán con COBOL porque Java no es la solución a sus problemas

Bill Curtis, ahora jefe de análisis de software y la empresa de medición de CAST, ha dicho que los bancos deben quedarse con las antiguas aplicaciones COBOL ya que estas no tienen los problemas de seguridad y desarrollo que aparecen con los nuevos lenguajes como Java.
etiquetas: cobol, java, bancos, análisis
usuarios: 224   anónimos: 255   negativos: 2  
197comentarios mnm karma: 623
Comentarios destacados:                                 
#1   Cobol. Cuando empecé la carrera por el 92 estaba mueriendo....juas!
#1   Cobol. Cuando empecé la carrera por el 92 estaba mueriendo....juas!
votos: 76    karma: 684
#2   #0 El titular es una cagada. No dice nada específicamente de Java. Pone como ejemplo Java como lenguaje moderno que aporta problemas en vez de soluciones. Podría decir lo mismo de VB o cualquier otra cosa.

#1 Menos mal que no has visto cosas desarrolladas con FORTRAN 77. Que las hay.
votos: 11    karma: 113
 *   sacreew sacreew
#5   #2 por desgracia si que las he visto, si...
votos: 0    karma: 11
#8   #2 El titular es el original de la noticia :-S

La verdad es que el artículo es un simple recordatorio del estado en el que se encuentran los sistemas informáticos del sector bancario.

Hay algo que no entiendo, ¿por qué no se olvidan de "migrar" el código existente y se dedicar a hacer un buen análisis de los procedimientos implicados para que así sea fácil realizar la programación en cualquier lenguaje? Me refiero, llevan décadas "migrando" el código y dedicando muchísimos recursos al asunto, no entiendo por qué siguen teniendo esta dependencia de COBOL/FORTRAN, la verdad.
votos: 12    karma: 107
#10   #8 ¿Una pregunta tonta? ¿Necesita un AS/400 Java? Tratamos muchas veces de trasladar estos "avances" a plataformas que no los necesitan y nunca los van a necesitar.

Los entornos MF. No necesitan todas esas moderneces. Se busca estabilidad y rapidez.
votos: 10    karma: 99
#12   #10 Hombre, es que se supone que un cambio de sistema implicará un cambio o adaptación de la plataforma, ¿no?

La cuestión entonces sería, ¿me permite la plataforma y sistema actual atender correctamente a todas mis necesidades actuales? ¿Puedo seguir actualizando mi sistema para acomodarlo a nuevos procedimientos o cambios en los procedimientos existentes?

¿Se puede seguir trabajando con una plataforma AS/400 con un código COBOL escrito hace 30 años y remodelado a lo largo de los años?
votos: 4    karma: 38
 *   babel_esp babel_esp
#16   #15 Me parece muy lógico, si un lenguaje de programación cubre tus necesidades y funciona de forma fiable... ¿Para que reescribir el código arriesgándote a meter nuevos errores?

Porque seguramente esté arrastrando código frankenstein que esté generando errores o consumo de recursos (CPU, RAM, tiempo de procesamiento) exagerados.

Porque seguramente cada mínima modificación que tengan que hacer sea carísima (y a lo mejor, de ahí viene que todos los procesos bancarios sean tan lentos y…   » ver todo el comentario
votos: 3    karma: 26
#22   #16 Curiosamente los programas más antiguos son los más óptimos ya que la potencia de las máquinas de la época era la que era. El ZX-81 tenía un ajedrez que ocupaba la escandalosa cifra de 1kb. Recuerdo también una entrevista al equipo de Dinamic cuando sacaron el Aspar GP donde hablaban de haber tenido que eliminar una decoración de un circuito porque pesaba demasiado, cosas casi-impensables hoy en día.
Un buen paralelismo creo que sería con los editores de texto. A día de hoy cualquier…   » ver todo el comentario
votos: 24    karma: 212
 *   juanma1980
#25   #22 Creo que esa sensación de que no queda nadie que sepa COBOL es porque no se ve, no se habla de él (es como el Club de la Lucha), parece que no se mueva nada... pero si no se ve movimiento es porque quien cruza la Puerta Oscura que guarda el espectro de Grace Hopper no sale hasta que se jubila.
votos: 12    karma: 98
 *   iramosjan iramosjan
#35   #25 Jajaja lo has clavado.
votos: 1    karma: 19
#49   #22 ¿Un experto en Cobol? Sin levantarme de mi silla tengo a 2 enfrente. Si me levanto y me doy una vuelta por el departamento creo que son unos 20

¿Navegando por meneame en horas de trabajo? Juan Manuel, pase por mi despacho mañana a primera hora :troll:
votos: 6    karma: 55
 *   totem totem
#105   #49 Eso, y así echamos unas risas comentando los titulares.
votos: 1    karma: 15
#73   #22 Más óptimas no pueden ser.
votos: 0    karma: 7
#149   #20 #70 ¿Cómo se puede asegurar que un programa de esos -no trivial- no contiene errores? Yo aseguraría más bien lo contrario.

#22 Sobre la eficiencia: los algoritmos modernos son muchísimo más eficientes que los antiguos, a menudo se suele afirmar que el tiempo de ejecución de un algoritmo moderno en una máquina antigua es menor que el de un algoritmo antiguo en una máquina moderna.

Uno de los mayores problemas para migrar los sistemas en COBOL es, como se ha mencionado, la falta de…   » ver todo el comentario
votos: 3    karma: 27
#24   #23 Si, creo que como bien dices, la antigüedad de los sistemas es el factor mas importante en este caso. El problema que le veo es que no es solo una parte la que tienes que migrar, sino que hablamos de gran parte de la infraestructura de tu negocio, y la gran mayoría son aplicaciones críticas, por los datos que manejan.

#17 Lo ganan los que están dentro y los pocos que se van incorporando. Es como un gremio, con un nicho de bastante seguridad como son los bancos y aseguradoras.
votos: 0    karma: 19
 *   equisdx equisdx
#70   #17 Yo mismo me considero experto en COBOL, y hay muchísimos... en Madrid y Barcelona. ¿Lo que ganamos? Hombre, no somos mileuristas, pero tampoco es que nos vayamos a retirar a la edad de un futbolista...

Por cierto, el tío del informe no tiene ni pajolera idea de Cobol. ¿600 líneas un programa o rutina COBOL? En esas líneas entran poco más que comentarios, declaraciones de entorno, constantes, variables y unas pocas líneas de proceso. Un programa de 600 líneas es sencillísimo. Yo he trabajado con alguno de 30.000 líneas.
votos: 3    karma: 36
#81   #70 600 líneas ya son líneas incluso para cobol, no hagamos código espagueti. ¬¬
votos: 0    karma: 15
#88   #81 Supongo que esto lo dices desde el desconocimiento y que no trabajas con Cobol... Acabo de abrir un programa al azar de los más simples que te puedes encontrar. Coge dos ficheros, cruza por sus claves y saca en otro fichero los registros que coinciden. Tiene 547 líneas. Y, créeme, no hace nada, no tiene ninguna lógica. Luego he abierto otro programa sencillito, que tiene algo de tratamiento de datos (no mucho) y tiene 994 líneas.
votos: 2    karma: 26
#91   #81 como te dice #88 600 lineas en un programa Cobol es normal. Yo recuerdo que la media estaba en 1000 lineas por módulo.
votos: 0    karma: 10
#117   #88 Tienes razón, no trabajo en Cobol.
votos: 0    karma: 15
#142   #88 ¿547 líneas para hacer un join?
votos: 1    karma: 12
#96   #70 30000 lineas de Código??? jur jur jur, no te has pasado un poco mucho?

La media 2000... bueno, si las COPY's las pones a saco, me creo lo de las 30000 ..pero de experto.. o_o
votos: 0    karma: 7
#111   #96 No, no estoy exagerando. Obviamente es un caso extremísimo, se trataba del alta de un nuevo contrato de préstamos en una instalación en la que no había control de calidad de ningún tipo. Y no, las copys estaban "bien" puestas. Había una amalgama de párrafos, llamadas a rutinas, comentarios, modificaciones asteriscadas, código redundante, displays, etc, etc que era intratable. De hecho, cada vez que había que tocar algo, no compilaba por exceso de líneas, se volvía loco, literalmente. Teníamos que buscar displays y asteriscos inservibles para quitar y poder meter nuestras líneas. Pero vamos, te aseguro que la cifra es real. Obviamente, el programa no era mío, era fruto de una evolución descontrolada a lo largo de muchos años.
votos: 1    karma: 13
#136   #70 #96 30000? Menudo chollo, en la aseguradora en la que trabajo el programa de contratación de pólizas tiene 112000 líneas.
votos: 0    karma: 8
#101   #17 Yo soy AP Cobol, y mi sueldo es 30k

Vamos, lo habitual en Madrid, tampoco es para echar cohetes
votos: 2    karma: 26
#104   #17
Al generar demanda de cobol estás provocando que la haya oferta de cobol ¿es eso bueno? ¿Es el cobol un lenguaje útil hoy día para otra cosa que no sean los bancos?

Es cómo si hablas de una emisora de radio que sólo usa discos de vinilo. Y dice, cambiarnos a digital ahora nos sale caro. Y tu dices, si la radio funciona lo que hay que hacer es más expertos en tocadiscos. Oferta y demanda.

Lo que pasa es lo de siempre, si se hubiese hecho progresivamente pues hoy no costaría tanto. Y defender el cobol, es cómo defender el IE6 para que siga funcionando en el ordenador del jefe.
votos: 2    karma: 2
#18   #16 ¿Estas diciendo que un lenguaje de hace 22 años consume mas recursos que un lenguaje actual? Te puedo asegurar que el mismo codigo que se programa hoy en dia podria correr tranquilamente en una maquina de hace 5,10 ó 15 años de antiguedad.

Aparte que el lenguaje esta mas que trillado y los posibles debug estan mas que conocidos y catalogados. Puesto que no ha cambiado apenas el codigo , no hay errores nuevos por conocer.

Ademas te puedo presentar a mas 15 programadores entre ellos varios expertos. Aun se enseña el lenguaje, y en estos momentos hay empresas que realizan cursillos para enseñar a sus nuevas incorporaciones.
votos: 17    karma: 173
#20   #16 Es software que ha estado en funcionamiento desde hace 20, 30, y hasta 40 y más años; tendría fallos, pero hace mucho que saltaron, se vieron y se arreglaron. Esos programas son el equivalente informático de los refugios antinucleares de la misma época, serán bastos, feos y pesados para los estándares de hoy, pero no los reventarías ni con una bomba atómica. Puede que despilfarren recursos - aunque lo dudo - pero errores no tienen.

Y respecto a las modificaciones y a donde encontrar…   » ver todo el comentario
votos: 7    karma: 61
 *   iramosjan iramosjan
#130   #16 El problema es que seguramente con toda seguridad no cubre las necesidades.

Hoy en día, Los sistemas informáticos no son parte del banco, son el banco en sí mismo. Si la competencia tiene un sistema más moderno que le permite mejorar el procesado de datos, análisis de riesgo, control de morosos, sistemas IA, ... entonces el banco en cuestión está "jodido".
votos: 2    karma: 24
#129   #15 Fijo que el programa no esta ni comentado, y que tienes que ir descifrando que hace cada linea o conjunto para luego traducirlo a un lenguaje mas moderno, que seguro que tiene algunas rutinas implementadas como funciones directamente en el lenguaje. Pero quien se arriesga a hacer eso, sabiendo que es un sistema critico y que se van a gastar una morterada en las pruebas de seguridad y estabilidad.

Mejor dejarlo como esta mientras funcione
votos: 1    karma: 13
#159   #15 aquí el tema es que ese código no es ni fiable ni estable, la decisión a tomar es migro lo que tengo a una tecnología donde haya más facilidad de encontrar profesionales y sea más estructurado y de fácil comprensión o analizo lo que tengo lo descifro y documento debidamente para poder hacer un mantenimiento eficiente, pues la respuesta del autor es que es mejor la segunda opción, eficiencia y estabilidad? Ya estamos con lo de siempre, la pantalla verde es más rápida y eficiente por…   » ver todo el comentario
votos: 0    karma: 6
#185   #37 #15 Desde luego Cobol no cubre las necesidades de un banco, ni de lejos, ¿Cuántas webs están hechas en cobol? Eso es sólo el comienzo, otra cosa es que Java sea la solución. Llevo años conviviendo con parte de la lógica hecha en cobol y es un auténtico infierno. Además de caro, carísimo en muchos aspectos.
Además de que a los agujeros de seguridad que se refiere este señor son comunes a cualquier servidor sea del lenguaje que sea incluido cobol. Es lo tiene la interoperatibilidad.
votos: 0    karma: 9
#92   #12 no olvides la seguridad (muy económica) que ofrece el AS/400, ahora conocido como iSeries. Un C2.
en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria
votos: 0    karma: 9
ivp ivp
#177   #10 Yo soy de la opinión de que "si no está roto, no lo arregles."
votos: 0    karma: 15
#195   #10 A mi juicio este no es artículo escrito por un especialista en la materia, se sueltan muchos conceptos ambiguos que en el mundo de la informática carecen de significado y contexto. Es cierto que una tecnología que nace ahora es mejor que otro que ya existía. Lamentablemente en informática se buscan soluciones/metodologías que sirvan para cualquier proyecto, y en el mundo real no funciona así.

“Los programas COBOL son inmensamente complejos, el tamaño de sus módulos tiene 600 líneas de…

  » ver todo el comentario
votos: 0    karma: 6
#119   #8 Yo creo que por seguridad.
votos: 0    karma: 10
#11   #2 ¿Me puedes decir qué tienes contra el fortran 77? Fuera de coñas, hay mucho soft científico y técnico circulando y en uso que está escrito en fortran. De hecho incluso en forma de extensiones para cosas tan actuales como python o similares. Si os fijáis, fortran es frontend de compiladores como los gnu o llvm.
votos: 4    karma: 44
#67   #2 Fortran se usa en la mayoría de software para cálculos en física y química subatómica. Yo lo estudié en la carrera, hace 12 años.
votos: 3    karma: 28
#9   #1 Lo mismo me dijeron del ASP, ahora me lo dicen del PHP, pero sigo haciendo en los dos soluciones buenas y fiables.
votos: 8    karma: 60
#43   #1 Bill Gates dijo algo así como: No sé que leguajes de programación habrá en el futuro, pero COBOL seguirá existiendo"
votos: 4    karma: 40
#47   #45 esto es simplemente una realidad, nada de propaganda ni conspiranoias.
#43 lo mismo que decía Bill Gates yo ya lo tenía claro hace 25 años. Mi primera profesora de Cobol siempre tenía esa frase en la boca.
votos: 0    karma: 11
 *   kampanita kampanita
#74   #43 ¿El mismo Bill Gates que dijo que nadie necesitaría más de 640K de RAM en el futuro? :troll:
votos: 1    karma: 14
#107   #74 No, este no existe.
votos: 1    karma: 14
#3   Ellos no necesitan una solución, necesitan no gastar dinero en migrar los sistemas. COBOL no tendrá problemas de seguridad supongo que porque tiene un propósito muy concreto y todos los sistemas de seguridad que hay por medio antes de llegar a aplicaciones desarrolladas en COBOL es enorme.
votos: 12    karma: 135
#23   #3 Sale mas caro encapsular el cobol en java que en migrarlo todo. Otra cosa es quitar un sistema con un rodaje de mas de cincuenta años. Algo de razon tiene el articulo
votos: 1    karma: 25
#4   Un gran problema es que las grandes TIC no invierten en formación porque todo está "en google". No, amigos, NO TODO está en google.
votos: 7    karma: 63
#108   #4 Las españolas, querrás decir xD

#39 Es que ensamblador es irreemplazable. A no se que quieras reinventar la rueda y hacer lo mismo con otro nombre.
votos: 1    karma: 17
 *   --151124--
#180   #4 No todo está en Google, pero si no está en Google no existe :-P
votos: 0    karma: 6
 *   geaplanet
#6   Corred Obsoletos, Buscaos Otro Lenguaje
votos: 45    karma: 386
#7   Pues va a ser que no estoy de acuerdo. ABAP es una alternativa muy "elegante" a COBOL.

Lo que pasa es lo que pasa siempre: A ver quién es el chulito que migra el HOST ese que lleva 22 años encendido.

Edit: Todo lo demás, son excusas.
votos: 39    karma: 334
#40   #7 apuesto a que llevas razón, no es de extrañar,... da pereza y reparo migrar algo en cuanto sea un poco crítico, no me quiero imaginar a esos niveles, tiene que ser el Coco y te inventas cualquier excusa como que el Java o el otro no es lo bastante seguro.
votos: 2    karma: 28
 *   yemeth yemeth
#68   #40 Y que a ver quién averigua todo lo que hace esa hipotética caja que ya te digo, en la mayoría de los casos llevan de cinco años para arriba sin un reinicio, porque como "te dejes algo" ya "la has cagao" y tienes 20 integraciones que te fallan y es cuando se pierden transferencias, se quedan lelos los cajeros, etc...

Pero no os creáis, que se va haciendo, ¿eh?
votos: 0    karma: 8
#78   #68 Por higiene se suelen reiniciar (IPL), al menos bianualmente coincidiendo con el cambio de hora por ejemplo (aunque no es necesario)
votos: 1    karma: 17
#128   #78 entonces te refieres a semestralmente? ?(
votos: 0    karma: 9
#75   #7 He leído ABAP y elegante y no he seguido leyendo más comentarios...

Lo que les faltaba a los bancos, atarse a SAP.
votos: 5    karma: 53
#84   #75 qué alternativa propones... PHP + MySQL? :palm: O igual quieres hacer todo el sistema en Java?? Es una locura, Java para la interfaz.

Ahora mismo SAP es, te guste o no, una plataforma super potente.
votos: 0    karma: 10
 *   Waskachu Waskachu
#89   #84 ya empezamos. Tienes alguna idea de lo que se puede hacer en PHP y MySQL, o has leido cuatro cosas sobre software libre y te suena a perroflautas y rojos peligrosos?
Lo del SAP es de juzgado de guardia. Que metan esos clavos por implantarte un sistema rígido y cerrado, que implica enormes dificultades de adaptación, solo es posible porque quién toma la decisión de comprar SAP no tiene demasiada idea de informática y se ha dejado convencer (o untar) por algún comercial.
Podría hablarte de una famosa ONG que se dejó varios millones de euros en un SAP cuando se le propusieron otras soluciones en software libre por un 10% del coste.
votos: 3    karma: 40
#94   #89 ni software libre ni nada de eso, hablo de potencia, de facilidades. De tener un sistema complejo montado en apenas dos semestres, que con otros lenguajes podría llevar una década. Mantenimiento, utilidades... todo el entorno de SAP si sabes cómo manejarlo...

En fin que yo tampoco digo que sea la panacea SAP, pero que no veo yo a un banco montando sus sistemas en PHP + MySQL... o en Java... Lol.
votos: 0    karma: 10
 *   Waskachu Waskachu
#99   #94 no ves a un banco montando sus sistemas en php, mysql o java porque seguramente desconoces estos lenguajes. Yo he trabajado también con el lenguaje de programación de SAP (el ABAP) y es un lenguaje lamentable. Le faltan muchísimas cosas y utilidades que tiene cualquier lenguaje decente, que hacen que la tarea del programador sea más eficiente.
La potencia depende principalmente del hardware, así que el SAP no se justifica tampoco por ese lado.
votos: 0    karma: 10
#102   #99 dime algunas de ellas... ABAP es un lenguaje orientado a objetos como los demás, con sus private, public, protected (sí, también tiene herencia!), variables estáticas... además de poder manejar fácilmente sentencias SQL. Dispone de excepciones, clases locales, globales...

Y luego además dispones de todo el entorno SAP.

Ah y si quieres, puedes usar el Dynpro o el Webdynpro para las interfaces.

Dime qué utilidades le faltan porque yo ahora mismo no caigo.
votos: 2    karma: 28
 *   Waskachu Waskachu
#143   #94 Que el software sea libre o no es totalmente independiente de que sea potente o tenga "facilidades"
votos: 0    karma: 6
#171   #94 está claro, Facebook está pensando migrar sus sistemas a COBOL o a SAP porque los comentaristas de esta noticia dicen que es lo más de lo más
votos: 0    karma: 6
#103   #84 Súper potente, súper grande, súper compleja, súper cara, con un motor súper obsoleto, y que como se te ocurra implantarlo te van a tener súper pillado por los huevos el resto de tu vida.

Claro que para grandes corporaciones no hay otra alternativa que usar SAP porque sencillamente no hay otra opción. Pero de todas maneras aquí se estaba hablando de bancos, que necesitan un animal totalmente distinto a un ERP.
votos: 5    karma: 50
#79   #7 Como decia un profesor mio de la carrera, si algo funciona no lo toques.

Al final es coste de migrar sistemas de este tipo se dispara, porque no es solo el software de la aplicación si no hardware, migración de datos, tests....
votos: 1    karma: 13
 *   Maegruin
#97   #7 Me pregunto qué leches tiene que ver ABAP con COBOL. Sí que ambos son lenguajes de programación... y punto.

COBOL es un lenguaje compilado con el que puedes desarrollar aplicaciones autónomas, y ABAP es un lenguaje que se usa exclusivamente dentro de una aplicación comercial (SAP) para extender sus funcionalidades.
votos: 8    karma: 80
 *   abnog
#100   #7 ABAP ni es elegante ni es una alternativa a nada. En ABAP no se pueden hacer ni la mitad de cosas que en Cobol, Java, PHP u otros. Al menos era así hace unos años.
votos: 2    karma: 26
#158   #100 Hombre, con ABAP puede hacerse exactamente lo mismo que con Cobol, RPG, PHP, etc. Es un lenguaje cómodo y potente en tratamiento de datos, aunque está orientado al entorno del ERP del que forma parte. Y SAP es una gran herramienta.
votos: 0    karma: 6
#13   por los dioses de COBOL!
votos: 35    karma: 282
#14   #13 ¡Por las 13 colonias!
votos: 21    karma: 178
#19   Las únicas migraciones que conozco son a SAP y de una parte muy pequeña. Migrar todo el COBOL a otra cosa requiere una inversión de dimensiones Bíblicas, queda COBOL para días
votos: 5    karma: 71
#21   Bueno, no sé, pero decir que Java es un lenguaje nuevo estaría bien si viviéramos en 1995-2000.
Es como decir que NFS (también ideado por Sun Microsystems, empresa que desarrolló Java) es algo nuevo, y seguramente sus sistemas lo utilicen para sus sistemas de archivos distribuidos junto con VFS. Todo de 1985.

Si para que algo esté asentado y sin fallos de seguridad debe llevar 54 años en marcha (COBOL ideado en 1959), difícilmente lo llevan, porque incluso los compiladores de COBOL tienen…   » ver todo el comentario
votos: 4    karma: 53
#26   Vale, pero de que colonia.
votos: 0    karma: 7
#27   El mundo no se acaba con Java, también existen otros quizá más apropiados.
votos: 0    karma: 7
#28   Ya hace un tiempo que vi este artículo: cobol nos sobrevivirá a todos:

www.itworld.com/career/341879/cobol-will-outlive-us-all
votos: 2    karma: 31
#29   Escala? :troll:
votos: 0    karma: 6
#30   "Y agrega que, para superar los fallos y defectos, los bancos deben analizar su código y averiguar exactamente cómo funciona. El científico considera que el problema de la industria financiera es que los sistemas se crearon hace años y muchos operan con poca comprensión de por qué ha sido diseñado de esta manera".

Está pasando. El ser humano involuciona, ya no se entiende la tecnología, es como si las cosas funcionaran de un modo mágico. la gente de dentro de 100 años hablará de las maravillas de los Antiguos, y se maravillarán de ellas aunque hayan dejado de funcionar por falta de energía o de mantenimiento :troll:
votos: 8    karma: 86
#168   #30 no necesito que pasen 100 años para hablar maravillas de los antiguos pues ya lo hago. Vamos! como no se puede hablar maravillas de quienes construyeron la stargate?
votos: 1    karma: 15
#31   ¡Y mi madre diciendome todos los días que tire los apuntes y los libros viejos! ¿¡Quién tiene razón ahora?! ¡¡¿Quiénnn?!
votos: 5    karma: 60
#32   los bancos si tienen problema grave de seguridad.... algunos chupaderos de la política en su dirección, es mas destructivo que el peor virus informático
votos: 1    karma: 16
 *   fuynfactory
#33   COBOL dominará el mundo, y tengo la prueba: Los terminators están programados en COBOL  media
votos: 6    karma: 74
#48   #33 Es verdad, se ve claramente en la foto de 3 pixeles que has puesto :-D
votos: 13    karma: 124
#57   #33 Foto en ultraresolución, así sí se ve bien claro.
votos: 3    karma: 44
#72   #33 el efecto 3D de tu imagen es acojonante, parece que el Terminator va a salir de la pantalla :troll:
votos: 3    karma: 50
#34   Primera norma: si funciona no lo toques.
votos: 5    karma: 41
#36   Cobol son los padres
votos: 4    karma: 27
#37   Aunque el mensaje es correcto, la realidad es otra.

El Java, C, C++ o lo que sea claro que puede hacer lo que hace el COBOL, el problema es que no hay huevos a tocar unos programas que llevan 20 años funcionando y tienen una red de interdependencias que no conoce ni el tato. El apagar un programita en COBOL puede arrastrar consecuencias en sistemas que ni se sospecha porque ni están documentados. Si a esto le añadimos que suelen mover el core del negocio y está relacionado con pasta, el COBOL…   » ver todo el comentario
votos: 34    karma: 297
#65   #37 Exacto. El problema de tocar COBOL y modernizarlo ( por asi decirlo ), es casi una quimera. Muchas partes del código estan sin documentar. Estuve trabajando un tiempo para el ayuntamiento, para modificar todos los programas COBOL a raíz del tema del efecto 2000 y habia partes de código que eran un cristo, nada o casi nada de documentación, preguntabas a alguien del departamento por si conocia esa parte del programa y nadie sabia nada. Cuando se lleva usando la misma estructura y se van…   » ver todo el comentario
votos: 8    karma: 78
#83   #65

Aparte de eso, suele haber una experiencia muy desastrosa en el proceso de retirada de aplicaciones. Apagas una y se caen 10 que dependían de ella, directa o indirectamente.

Dónde trabajé durante años, toda la planta está almacenada en un sistema mainframe (tan moderno que ni siquiera incluye DNI para identificar al propietario, eso hay que ir a buscarlo a otro sistema) y el resto de los sistemas de la compañía han crecido a su alrededor.

El cambiar esto, significa al menos, volver a…   » ver todo el comentario
votos: 3    karma: 37
 *   jmfer jmfer
#157   #37 Si que hay huevos, todos los días nos papamos programas de hace 20 años para adaptarlos, corregirlos, etc...

Ya mas en serio, no solo se mantienen sistemas antiguos, también se crean aplicaciones nuevas todos los años, y se continúan haciendo en cobol.

Se adapta a las necesidades, es robusto, fiable y procesa grandes cantidades de información muy rápido.
votos: 1    karma: 15
 *   Radix2
#38   COBOL roolz!!
votos: 0    karma: 7
#39   a este ritmo también llegare usar de nuevo el de ensamblador :troll:  media
votos: 1    karma: 16
#42   #39 Que grande el libro de trucos de la megadrive!!!
votos: 4    karma: 40
 *   hangla hangla
#56   #39 El libro de Dune en medio de los libros de informática... el paradigma del friki :-D
votos: 3    karma: 37
#41   No he entendido ningún comentario shit
votos: 6    karma: 70
#46   #41 Cobolizate hombre, si es que no vas a la ultima.
votos: 1    karma: 25
#61   #46 COBOL es Hipster
votos: 3    karma: 33
#44   Se olvidan de mencionar los datos: los bancos tienen sus datos en Oracle u otras BD de fabricación propia, y de allí es que se roban la pasta. Y contra eso NO pueden utilizar COBOL, así que no tienen otra que modernizarse, a menos que decidan costear el altísimo mantenimiento.
votos: 3    karma: -13
#138   #44 En Cobol se puede acceder a bases de datos relacionales como DB2.
votos: 1    karma: 16
#50   Eso de que los bancos van a seguir con Cobol... el Banco Santander está estudiando implantar Open Cobol que genera interfaces en C, C++ y Java a través del código original de Cobol, si bien tienen que realizar labores de rendimiento para ver si ejecutan las tareas a la misma velocidad, si realmente funciona bien, el objetivo del banco es quitarse las costosas licencias de Cobol e intentar integrarlo con el resto de sistemas

Al parecer el objetivo es empezar por un banco alemán si las pruebas de rendimiento obtienen los frutos esperados
votos: 0    karma: 7
#76   #50 Trabajo en el Santander. Créeme, van a seguir con COBOL muuuuchos años.
votos: 3    karma: 27
#51   Una de las razones fundamentales de la duración del Cobol son los equipos donde funcionar, por mas que se hable maravillas de Linux/Unix jamas estarán a la altura de la estabilidad del VMS, hoy OS9, y pasa lo mismo con el Hardware, por mucho que veamos clusters y datacenters nunca darán el servicio de un Mainframe, veo complicado, casi imposible que un Intel i7 sea capaz de dar el mismo servicio que ha dado un IBM 4381 durante años
votos: 4    karma: 24
#86   #51

Si haces como los mainfraneros, es decir, te prohíbo el SQL dinámico, te corto todas las transacciones que duren más de 2 segundos de CPU, para los sistemas 7x24 todos los días dos horas para hacer la copia de seguridad, te hago yo estable hasta un Windows Vista.
votos: 3    karma: 41
#132   #51 He votado negativo sin querer! Perdón, te lo compenso en otro.
votos: 0    karma: 8
#52   ¡Ahora entiendo la crisis! ¡Todo ha sido un error informático!
votos: 3    karma: 35
#53   Migrar el Cobol... Hoy debe ser el día de los inocentes informáticos.
Realmente nadie puede hacerlo con garantías y sobretodo nadie quiere asumir esas responsabilidades y riesgos. Los Mainframes de IBM sobre los que corre el Cobol tienen unos niveles de seguridad, eficiencia y funcionamiento a prueba de fallos absolutamente espectaculares, y no se equivoque nadie, son sistemas que se modernizan igual que todo lo demás, bueno, quizás algo más lentos, pero se modernizan, aunque los programas que…   » ver todo el comentario
votos: 12    karma: 96
#87   #53 Y porque nos iba a tocar la moral. Aquí hay cosas diseñadas para realizar X.
A lo que voy, cualquiera que entienda de Java ni se plantea sustituir COBOL con JAVA. Es absurdo comparar 2 lenguajes diseñados para cosas diferentes. Soy de los que piensan q ya va tocando sustituir COBOL porque por mucho que diga este tío tiene que haber soluciones mejores, pero como ya han dicho por ahí a ver quién es el guapo que cambia algo que esta hiperdepurado y que se conoce tan bien que todos los fallos…   » ver todo el comentario
votos: 6    karma: 59
#95   #87 excelente explicación. Aunque discrepo con lo de dejar Java para los portales web, habiendo soluciones más sencillas,
votos: 1    karma: 16
#110   #95 Supongo que esas soluciones mas sencillas pasan por php y similares. Bueno pues si y no y explico mi propia experiencia y mi opinión.
Mientras tengas contenido estático o "ligeramente" dinámico estoy de acuerdo. php tiene una curva de aprendizaje y desarrollo cojonuda y se ejecuta directamente en un apache con el modulo d php ahorrándote una máquina virtual. Además la depuración es muy cómoda al ahorrarte redespliegues. Esta situación de "semidinamicidad" se da en un…   » ver todo el comentario
votos: 1    karma: 16
#118   #87 #54 Lo de que Java está diseñado para correr en electrodomésticos es más viejo que Matusalén: Java hace años que está diseñado para correr en mainframes y soportar cargas de trabajo bestiales. Precisamente cuando hablamos de mainframes lo que ocupa la MV es una nadería: ¿a quién le importa que cualquiera programa necesite de 30MB para arriba cuando todo lo que tiene que soportar ocupa 16GB en RAM? Yo estoy manteniendo un sistema que no para de evolucionar desde hace 20 años, decenas de…   » ver todo el comentario
votos: 6    karma: 49
 *   pawer13 pawer13
#164   #53 no te mosquees pero que tamaño y coste de hardware tienen esos mainframes de IBM de los que hablas? Joder que precio por precio se doblan costes y se habla de eficiencia cuando te meten RAM y procesadores para aburrir a precio de oro, que no nos vamos a enfadar que puede haber una convivencia, pero me hace gracia lo de la seguridad esta claro que vas a tener más problemas en un entorno cliente servidor que en un Host bien cerradito.
votos: 0    karma: 6
#54   Llevo años riendome de cobol
Parece que al final me tendré que tragar mi orgullo y aprender cobol
(con lo feliz que era con C, Java, PHP, Python, Nodejs, ...)
votos: 1    karma: 16
#58   Java nuevo? Si nacio en 1995!!! eso es el jurasico de la informatica.

Que digan que no tienen ni puta idea de como funcionan los programas que tienen hechos, o que costaria mucho la creacion de cero de programas mas modernos, pero que no digan sandeces.

De hecho, el mantener COBOL porque no tienen ni puta idea de como funcionan sus sistemas les hace a la larga tener muchos mas problemas. La migracion a java les puede durar 5 o 6 años, con un buen plan y gastandose el dinero en buenos equipos (no en consultoras). Mantener COBOL les va a salir mucho mas caro y problematico a la larga. Pero ellos sabran (o quiza el problema es que no saben...)
votos: 8    karma: 59
#82   muahahahaha, la venganza de los coboleros!!! Yo hice un esfuerzo de pasarme de Cobol a Java pero mi cerebro no lo resistió. En cambio, con el PHP triunfé... Mi profesor de Java, un tipo que llevaba más de 10 años trabajando con él decía que era "una porquería de lenguaje". Lo decía medio en broma, pero yo he llevado proyectos con una parte en Java y una parte en Cobol y la diferencia entre los dos equipos de programadores era considerable, tanto en rapidez como en eficiencia. La…   » ver todo el comentario
votos: 2    karma: 35
 *   KimDeal KimDeal
#160   #58 Sin ofender, pero se nota que nunca has trabajado en entorno bancario, no te haces una idea del tamaño de esos sistemas
votos: 0    karma: 9
 *   Radix2
#59   Los bancos quieren magia. Software ultrapotente a coste 0.
votos: 2    karma: 22
#60   Programar en Cobol tiene que ser el infierno en vida. Sólo alguien sin alma podría hacerlo.
votos: 3    karma: -15
#66   #60 #62 no sé si tenéis el gusto de conoceros :troll:
votos: 2    karma: 29
#71   #60 Lo que es un infierno es programar en un sistema que depende de una runtime para funcionar, JVM, que ahora tenemos un error y un agujero de seguridad, que ahora Microsoft mete una dll nueva y nos falla algo, un infierno era programar en RMCobol bajo Unix o Windows, programar en Cobol en un ordenador de verdad, un z9 es una maravilla.
votos: 5    karma: 53
#85   #60 aquí uno que ha programado en Cobol, en Java, en .Net y en PHP. De todos ellos, el Cobol es el más agradable. El infierno para mi se llama Java, seguido de .Net. En cambio PHP también me resulta muy cómodo.
votos: 1    karma: 20
#90   #85 PHP es un buen lenguaje. Yo programo en él. En realidad, más que programar en Cobol, lo realmente sádico tiene que ser trabajar sobre las aplicaciones de la Banca. Tiene que ser brutal.
votos: 5    karma: 50
#93   #90 no creas. Lo bueno de la banca es que los proyectos suelen estar bien organizados y los equipos muy especializados, con gente de sistemas, de front end, de backend, varios DBA...
votos: 0    karma: 10
#62   Los Coboleros persistimos aunque hace años nos llamaban obsoletos ... y cuando explicas en que programas la gente pone cara de cirscunstancia, sisi, pero seguimos teniendo curro...!
votos: 3    karma: 33
#63   No es ni cuestión de pasta, es cuestión de huevos. Yo desde luego jamás me metería en la migración de ninguno de esos sistemas, antes prefiero mendigar :-D
votos: 2    karma: 28
#64   ya, pero si no llega a ser por C, ahora mismo se llamaría OBOL
votos: 4    karma: 25
#69   En la noticia no se dice nada de que haya problemas con los lenguajes modernos, de hecho dice que los lenguajes modernos son más fáciles de mantener.

Lo que pasa es que "si funciona, no lo toques". No saben cómo funcionan sus programas, sólo que funcionan, y rehacerlos en otro lenguaje sería muy costoso y aparecerían errores nuevos, algo normal al traducir algo de un lenguaje a otro.
votos: 0    karma: 6
#77   Vaya, qué casualidad que me pasaran este vídeo ayer,

www.youtube.com/watch?v=E3418SeWZfQ
votos: 1    karma: 15
#80   En 1996 tenía Cobol como asignatura, que recuerdos. Me alegra comprobar que los viejos roqueros nunca mueren.
votos: 0    karma: 6
#98   Respecto a mi anterior comentario en esta noticia, Java puede compilarse a código nativo gracias a GCJ.
Otra cosa distinta es el bytecode para una JVM.
votos: 0    karma: 12
«12
comentarios cerrados

menéame