Hace 10 años | Por babel_esp a computerworld.es
Publicado hace 10 años por babel_esp a computerworld.es

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.

Comentarios

D

#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.

kampanita

#2 por desgracia si que las he visto, si...

babel_esp

#2 El titular es el original de la noticia

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.

D

#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.

babel_esp

#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?

delawen

#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.

D

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

¿Y si no lo hay?

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).

Cualquier modificación va a ser cara, no por el código sino por poder asegurar que no afecte a la calidad del código.

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

Si tanto dinero se ganara con Cobol, la gente lo estudiaría en masa y el precio bajaría. Oferta y demanda.

iramosjan

#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.

D

#25 Jajaja lo has clavado.

totem

#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

j

#49 Eso, y así echamos unas risas comentando los titulares.

kovaliov

#22 Más óptimas no pueden ser.

maloconocido

#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 documentación. Otro es el control de código, habría muchísima suerte si el código estuviese en un repositorio. Puede que todavía haya rutinas de COBOL guardadas en disketes de 5 1/4. Y ¿alguien se ha preguntado por los tests automáticos? ¿TDD? Si hubiesen desarrollado los fabulosos sistemas con técnicas basadas en tests automáticos, migrar a cualquier cosa sería más parecido a un paseo por una calzada de baldosas amarillas.

PD: ¿Cuánto fan de COBOL hay escondido por ahí?

equisdx

#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.

HyperBlad

#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.

D

#70 600 líneas ya son líneas incluso para cobol, no hagamos código espagueti.

HyperBlad

#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.

KimDeal

#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.

D

#88 Tienes razón, no trabajo en Cobol.

maloconocido

#88 ¿547 líneas para hacer un join?

EternoViajero

#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..

HyperBlad

#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.

paranoid_android

#70 #96 30000? Menudo chollo, en la aseguradora en la que trabajo el programa de contratación de pólizas tiene 112000 líneas.

MycroftHolmes

#17 Yo soy AP Cobol, y mi sueldo es 30k

Vamos, lo habitual en Madrid, tampoco es para echar cohetes

piki.g.saraza

#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.

iramosjan

#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

PythonMan8

#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".

Dangi

#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

serlec

#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 definición que cualquier framework de reciente factura y nada más lejos de la realidad tan malo puede ser un cobol poco optimizado como bueno un proceso Hibernate bien hecho, pero para eso hacen falta arquitectos no programadores haciendo procesos con un "how to" de javaHispano, con todo el cariño para javaHispano.

c

#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.

ivp

#12 no olvides la seguridad (muy económica) que ofrece el AS/400, ahora conocido como iSeries. Un C2.
http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria

JanSmite

#10 Yo soy de la opinión de que "si no está roto, no lo arregles."

D

#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 código. Mientras que el tamaño de un módulo Java tiene 30 líneas de código”, ha declarado. "En COBOL existe una fuerte correlación entre el tamaño del sistema y de la densidad de los defectos. Es exponencial, cuanto mayor es el sistema, más alta es la densidad de los defectos en cada cien líneas ",

La modularización tiene sus puntos fuertes, pero no es una panacea, muchas veces al dividir un todo en módulos tienes muchos más problemas antes, incluso problemas que no tenías, y tampoco es seguro que unas partes con menos errores, conformen un todo con menos errores.

Incluso muchas veces se usan lenguajes orientados a objetos como si fueran programación estructurada (cosas como abusar de getters y setters), y no siempre el principio de ocultación de la información funciona bien. Hay muchas soluciones teóricas, que en principio suenan muy bien, pero en la práctica no son tales. Hay que saberlas evaluar.


Además, al tratarse de sistemas antiguos hay muy poca gente cuyos conocimientos técnicos permitan detectar y resolver rápidamente los problemas que surgen.


Esto depende de cuanto estés dispuesto a pagar y cuanta estabilidad estés dispuesto a ofrecer. En España esto es un mal genérico que aplica a cualquier tipo de modelo de desarrollo.

D

#8 Yo creo que por seguridad.

D

#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.

D

#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.

Peka

#1 Lo mismo me dijeron del ASP, ahora me lo dicen del PHP, pero sigo haciendo en los dos soluciones buenas y fiables.

P

#1 Bill Gates dijo algo así como: No sé que leguajes de programación habrá en el futuro, pero COBOL seguirá existiendo"

kampanita

#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.

D

#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.

j

#43 ¿El mismo Bill Gates que dijo que nadie necesitaría más de 640K de RAM en el futuro?

Juan_Esmíz

#74 No, este no existe.

yemeth

#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.

Moléculo

#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?

D

#68 Por higiene se suelen reiniciar (IPL), al menos bianualmente coincidiendo con el cambio de hora por ejemplo (aunque no es necesario)

Seta_roja

#78 entonces te refieres a semestralmente?

CalifaRojo

#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.

Waskachu

#75 qué alternativa propones... PHP + MySQL? 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.

KimDeal

#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.

Waskachu

#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.

KimDeal

#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.

Waskachu

#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.

maloconocido

#94 Que el software sea libre o no es totalmente independiente de que sea potente o tenga "facilidades"

ED209

#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

M

#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....

KimDeal

#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.

a

#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.

D

#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.

R

#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.

LuisPas

por los dioses de COBOL!

babel_esp

#13 ¡Por las 13 colonias!

k

#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

KimDeal

#87 excelente explicación. Aunque discrepo con lo de dejar Java para los portales web, habiendo soluciones más sencillas,

p

#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 porcentaje altísimo de las páginas web con lo cual php es algo muy muy a tener en cuenta y q no debe despreciarse para nada.

Sin embargo en una situación de páginas muy dinámicas. Con contenido sacado de diversas BBDD, con muchas funcionalidades dependientes unas de otras, con datos sacados de grandes sistemas transaccionales (como los sistemas COBOL) y otro tipo de paginas con un negocio complejo y laborioso veo un poco suicida meterse con php. Básicamente ante un uso de datos dinámicos tan grandes la estructura interna que da la POO es lo idóneo. Los intentos que he visto de hacer estas cosas en php acaban cn programas inmantenibles, con apaños de por medio para entenderse y cruzar bien todo lo que te llega del resto de sistemas, veo complicao hacer que se entiendan con sistemas heterogeneos en general y ademas son malamente evolucionables debido a esa falta de estructura (o estructura mas flexible) que tan sencillo hace a php.
Además hay que contar que el apache y similares están mas bien diseñados para gestionar peticiones a la velocidad del rayo dando una puerta de acceso al servidor realmente muy segura pero no me parece una bestia de carga precisamente. Si lo que tienes son muchas piedras (datos) que cargar y mover de un lado a otro hasta que las entregas al usuario compensa el peso de una maquina virtual.
De todas formas al final muchas veces la solución que se tiene es hacer la parte estática y con un negocio sencillote en php para tener algo realmente rápido y el negocio complejo en java. De cara al usuario no hay ninguna diferencia pero estás equlibrando el trabajo y consiguiendo un sistema mas robusto.

Si discrepas de mi opinión me encantaría saber la tuya.

serlec

#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.

berzasnon

"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

J

#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?

D

COBOL dominará el mundo, y tengo la prueba: Los terminators están programados en COBOL

satchafunkilus

#33 Es verdad, se ve claramente en la foto de 3 pixeles que has puesto

gorgias1976

#33 Foto en ultraresolución, así sí se ve bien claro.

D

#33 el efecto 3D de tu imagen es acojonante, parece que el Terminator va a salir de la pantalla

Pirenaico

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

D

No he entendido ningún comentario

ChukNorris

#41 Cobolizate hombre, si es que no vas a la ultima.

D

#46 COBOL es Hipster

D

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.

D

#4 Las españolas, querrás decir lol

#39 Es que ensamblador es irreemplazable. A no se que quieras reinventar la rueda y hacer lo mismo con otro nombre.

g

#4 No todo está en Google, pero si no está en Google no existe

FutreTheGreat

¡Y mi madre diciendome todos los días que tire los apuntes y los libros viejos! ¿¡Quién tiene razón ahora?! ¡¡¿Quiénnn?!

r

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...)

KimDeal

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.

R

#58 Sin ofender, pero se nota que nunca has trabajado en entorno bancario, no te haces una idea del tamaño de esos sistemas

D

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.

http://en.wikipedia.org/wiki/COBOL

D

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".

NapalMe

Primera norma: si funciona no lo toques.

rogerius

¡Ahora entiendo la crisis! ¡Todo ha sido un error informático!

EternoViajero

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...!

D

#60 #62 no sé si tenéis el gusto de conoceros

s

Ya hace un tiempo que vi este artículo: cobol nos sobrevivirá a todos:

http://www.itworld.com/career/341879/cobol-will-outlive-us-all

D

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

EspecimenMalo

Cobol son los padres

m

ya, pero si no llega a ser por C, ahora mismo se llamaría OBOL

D

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

D

#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.

paranoid_android

#51 He votado negativo sin querer! Perdón, te lo compenso en otro.

bega

Los bancos quieren magia. Software ultrapotente a coste 0.

f

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

f

a este ritmo también llegare usar de nuevo el de ensamblador

hangla

#39 Que grande el libro de trucos de la megadrive!!!

superplinio

#39 El libro de Dune en medio de los libros de informática... el paradigma del friki

prejudice

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, ...)

fingolion

Vaya, qué casualidad que me pasaran este vídeo ayer,

D

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.

D

Vale, pero de que colonia.

D

El mundo no se acaba con Java, también existen otros quizá más apropiados.

D

COBOL roolz!!

Smoje

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

HyperBlad

#50 Trabajo en el Santander. Créeme, van a seguir con COBOL muuuuchos años.

Konata_Izumi_II

Escala?

Mobinto

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.

TwinBee007

En 1996 tenía Cobol como asignatura, que recuerdos. Me alegra comprobar que los viejos roqueros nunca mueren.

M

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.

j

#44 En Cobol se puede acceder a bases de datos relacionales como DB2.

Sofrito

Programar en Cobol tiene que ser el infierno en vida. Sólo alguien sin alma podría hacerlo.

D

#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.

KimDeal

#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.

Sofrito

#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.

KimDeal

#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...

1 2