479 meneos
6302 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
«12
  1. #1   Cobol. Cuando empecé la carrera por el 92 estaba mueriendo....juas!
    votos: 76    karma: 684
  2. #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
  3. #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
  4. #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
  5. #5   #2 por desgracia si que las he visto, si...
    votos: 0    karma: 11
  6. #6   Corred Obsoletos, Buscaos Otro Lenguaje
    votos: 45    karma: 386
  7. #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
  8. #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
  9. #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
  10. #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
  11. #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
  12. #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
  13. #13   por los dioses de COBOL!
    votos: 35    karma: 282
  14. #14   #13 ¡Por las 13 colonias!
    votos: 21    karma: 178
  15. #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 tediosos).

    Porque el coste de mantenimiento tiene que andar por las nubes (¿dónde encuentras tú un experto en COBOL hoy en día?)

    Hay muchos motivos. Otra cosa es que no quieran gastarse el dinero que cuesta rehacer el sistema porque prefieran pan para hoy.
    votos: 3    karma: 26
  16. #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
  17. #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
  18. #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 expertos, no solo existen aún veteranos en activo, viejos guerreros de los 80 (y puede que hasta alguno de los 70) sino que quienes tienen software en COBOL se encargan de formar más para no quedarse sin gente. Te lo digo como alguien que aprendió a programar con COBOL hacia 1980 y que muy probablemente va a volver a trabajar en COBOL de nuevo este año después de haberlo dejado hace unos 25 años o más... vamos, aún usábamos GOTOs a mansalva :-D
    votos: 7    karma: 61
     *   iramosjan iramosjan
  19. #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 revisiones, y digamos que mucho mantenimiento no tienen por lo que la calidad del ensamblador generado puede que no sea la misma que se pueda obtener con Java o C/C++. De hecho la última versión estable de COBOL data del 2002, a la cual se añadió orientación a objetos, con los numerosos cambios que requiere.

    en.wikipedia.org/wiki/COBOL
    votos: 4    karma: 53
  20. #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 editor de texto te permite hacer 800 cosas, desde formatear y maquetar texto hasta diseñar diagramas pero si tus necesidades únicamente son de formateo de texto seguramente cualquier editor de texto de los 80 cubra todas tus necesidades con un consumo ínfimo de recursos. Con los programas de gestión pasa lo mismo: si tus necesidades son las mismas que hace 20 años (y en la mayoría de casos, al igual que con los editores de texto, lo son) hay muy pocas soluciones modernas que sean más óptimas que las antiguas.

    Como anécodta personal recuerdo la primera empresa para la que trabaje que estaba migrando todos sus programas de Prolog a un lenguaje moderno (velazquez, actual velneo) y no había ni un solo cliente que no se quejase de que los programas nuevos en sus superservidores modernos iban más lentos que sus viejos y vetustos servidores con su software en Prolog. Por supuesto todos decían que era mucho más bonito el tener barras de progreso, interfaces gráficas, botoncitos... pero a la hora de la verdad todos trabajaban más lento que, a fin de cuentas, es lo que les importaba.

    #17 ¿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 (y eso solo en una empresa que, además, solo tiene una parte de sus sistemas en Cobol). Depende mucho del sector en el que trabajes pero expertos en Cobol hay muchos más de los que pueda parecer.
    votos: 24    karma: 212
     *   juanma1980 juanma1980
  21. #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
  22. #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
  23. #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
  24. #26   Vale, pero de que colonia.
    votos: 0    karma: 7
  25. #27   El mundo no se acaba con Java, también existen otros quizá más apropiados.
    votos: 0    karma: 7
  26. #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
  27. #29   Escala? :troll:
    votos: 0    karma: 6
  28. #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
  29. #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
  30. #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 fuynfactory
  31. #33   COBOL dominará el mundo, y tengo la prueba: Los terminators están programados en COBOL  media
    votos: 6    karma: 74
  32. #34   Primera norma: si funciona no lo toques.
    votos: 5    karma: 41
  33. #35   #25 Jajaja lo has clavado.
    votos: 1    karma: 19
  34. #36   Cobol son los padres
    votos: 4    karma: 27
  35. #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 va a durar tanto como el banco.

    Esto es extrapolable a los sistemas (en el lenguaje que sea) que lleven 15 años o más. También han desarrollado una red de dependencias que nadie se atreve a desentramar.

    Si no se quita el COBOL no es porque no se pueda, es que no hay huevos (que conste que yo tampoco me atrevería)
    votos: 34    karma: 297
  36. #38   COBOL roolz!!
    votos: 0    karma: 7
  37. #39   a este ritmo también llegare usar de nuevo el de ensamblador :troll:  media
    votos: 1    karma: 16
  38. #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
  39. #41   No he entendido ningún comentario shit
    votos: 6    karma: 70
  40. #42   #39 Que grande el libro de trucos de la megadrive!!!
    votos: 4    karma: 40
     *   hangla hangla
  41. #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
  42. #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
  43. #45   Esto me parece propaganda para contrarrestar lo que se viene diciendo últimamente sobre la inestabilidad de los sistemas bancarios, sobre todo a raíz de la huelga de HP.

    La realidad es que sólo los sistemas internos "críticos" son programados en COBOL, el resto se hace en Java (sobre todo los diversos sistemas de banca on-line), y la totalidad de los sistemas son hechos por programadores "Junior".
    votos: 5    karma: 45
  44. #46   #41 Cobolizate hombre, si es que no vas a la ultima.
    votos: 1    karma: 25
  45. #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
  46. #48   #33 Es verdad, se ve claramente en la foto de 3 pixeles que has puesto :-D
    votos: 13    karma: 124
  47. #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
  48. #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
  49. #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
  50. #52   ¡Ahora entiendo la crisis! ¡Todo ha sido un error informático!
    votos: 3    karma: 35
  51. #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 llevan 40 años corriendo en ellos y que son el núcleo y corazón de auténticas corporaciones enormes no sean fácilmente modificables, ese "nivel" de integración con la lógica del negocio se ha perdido, cuando un programador actual de cobol y java pasan en 90% de su tiempo peleándose contra sus propias limitaciones y las de los lenguajes que utilizan (Java, sin ir más lejos, da trabajo en sí mismo, entre arreglos de fallos, softwares deficientes y demás, sin entrar siquiera en la lógica de negocio a grandes rasgos o ser capaz de presentar algo presentable en pantalla).

    Me lo dijo una vez un jefe de informática de una empresa, El Cobol a nadie le gusta excesivamente, se ve antiguo y feo, pero funciona, joder que sí funciona, y el 90% de la lógica vital del negocio está en él. ¿Quién va a poner su trabajo en peligro por tener cuatro colorines más y acceso Web si no es 100% vital para la empresa? Sobretodo cuando el acceso Web lo puedes tener igualmente parcheando esos Coboles y buscando soluciones alternativas sin cambiar una línea del código "obsoleto", transformando el Java en un simple "frontend" del viejo y feo Cobol, que sigue siendo donde corre lo importante y que no puede fallar.

    Os tocará la moral a los de Java, pero las cosas son como son.
    votos: 12    karma: 96
  52. #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
  53. #55   #47 La cuestión no es si tiene razón, que es muy discutible, la cuestión es por qué ha tenido que salir a decir esto ese analista precisamente ahora... si fuese tan evidente no se habría molestado.

    De hecho el texto refuerza mi afirmación (no es muy largo así que no voy a pegar nada): lo que pretenden es acallar las críticas internas y convencer a la opinión pública de que es la mejor o que no hay otra opción.
    votos: 2    karma: 25
  54. #56   #39 El libro de Dune en medio de los libros de informática... el paradigma del friki :-D
    votos: 3    karma: 37
  55. #57   #33 Foto en ultraresolución, así sí se ve bien claro.
    votos: 3    karma: 44
  56. #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
  57. #59   Los bancos quieren magia. Software ultrapotente a coste 0.
    votos: 2    karma: 22
  58. #60   Programar en Cobol tiene que ser el infierno en vida. Sólo alguien sin alma podría hacerlo.
    votos: 3    karma: -15
  59. #61   #46 COBOL es Hipster
    votos: 3    karma: 33
  60. #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
  61. #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
  62. #64   ya, pero si no llega a ser por C, ahora mismo se llamaría OBOL
    votos: 4    karma: 25
  63. #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 añadiendo módulos sin control, al final pasan los años y ya nadie sabe para que se hicieron las cosas. Asi que la regla básica en informatica "si funciona no lo toques"
    De todas formas, como comentáis, ni con un bomba nuclear se tumba algo en COBOL.
    votos: 8    karma: 78
  64. #66   #60 #62 no sé si tenéis el gusto de conoceros :troll:
    votos: 2    karma: 29
  65. #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
  66. #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
  67. #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
  68. #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
  69. #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
  70. #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
  71. #73   #22 Más óptimas no pueden ser.
    votos: 0    karma: 7
  72. #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
  73. #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
  74. #76   #50 Trabajo en el Santander. Créeme, van a seguir con COBOL muuuuchos años.
    votos: 3    karma: 27
  75. #77   Vaya, qué casualidad que me pasaran este vídeo ayer,

    www.youtube.com/watch?v=E3418SeWZfQ
    votos: 1    karma: 15
  76. #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
  77. #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 Maegruin
  78. #80   En 1996 tenía Cobol como asignatura, que recuerdos. Me alegra comprobar que los viejos roqueros nunca mueren.
    votos: 0    karma: 6
  79. #81   #70 600 líneas ya son líneas incluso para cobol, no hagamos código espagueti. ¬¬
    votos: 0    karma: 15
  80. #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 complejidad del Java para hacer cosas sencillas es muy incómoda.
    Y la justificación de la P.O.O. no me sirve, hay otros lenguajes orientados a objetos... incluido el PHP. Tarde o temprano las grandes empresas se darán cuenta de los costes brutales que están asumiendo por apostar por el Java y se pasaran a PHP, Ruby, Python...
    #58 "Mantener COBOL les va a salir mucho mas caro y problematico a la larga"... por qué? Eso me suena a dogma que no se puede demostrar. En un gran empresa, Java tiene sentido para lo que no puedas hacer en Cobol (servicios web, comunicación via xml, ...), y aun así creo que hay opciones más sencillas.
    votos: 2    karma: 35
     *   KimDeal KimDeal
  81. #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 probarlo todo. En el peor de los casos, modificar cientos de aplicaciones que también han evolucionado y crecido de una manera similar.

    Luego hay una segunda derivada, un poco más cachonda. En su día y con el efecto 2000 hubo que recuperar a algún dinosaurio de IBM para modificar programa en ensamblador del OS/360 (ni me acuerdo que CPU llevaba)

    Había dos teorías para justificar aquellos programas en ensamblador:
    - Eficiencia. Eran programas muy rápidos, adecuados a las soluciones HW de su época.
    - Hemos perdido los fuentes y no han quedado más cojones que desemsamblar y modificar aquí.

    Cada cual que elija la que más le guste.
    votos: 3    karma: 37
     *   jmfer jmfer
  82. #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
  83. #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
  84. #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
  85. #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 que da son predecibles y controlables. A lo anterior añadiremos el insignificante detalle de que esas aplicaciones manejan la pasta.
    De todas formas de sustituirse jamás debería hacerse por JAVA. simplemente porque Java no está hecho para ese tipo de operaciones intensivas. Java está hecho para llegar a cualquier equipo informático; se diseñó para que algo hecho con él pudiera ejecutarse hasta en una tostadora. Pero eso tiene un precio llamado JVM q es pesada hasta decir basta y es de locos usar algo tan pesado para hacer operaciones sobre datos de forma intensiva.

    En resumen, la discusion COBOL Java me parece tan absurda como decir que es mejor un deportivo que un camión. Ambos son vehículos pero cualquiera puede ver que no se diseñaron para lo mismo por lo tanto no se puede comparar.

    Asique que se planteen cambiar COBOL. Que se tomen su tiempo en probar nuevas soluciones pero las tiene q haber mejores y mejorables fuera de COBOL. Eso si x su bien que dejen java para los frontales web y no para las transacciones sino van a tener q aflojar una pasta en maquinas.
    votos: 6    karma: 59
  86. #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
  87. #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
  88. #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
  89. #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
  90. #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
  91. #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
  92. #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
  93. #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
  94. #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
  95. #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 abnog
  96. #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
  97. #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
  98. #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
«12
comentarios cerrados

menéame