Este programa informático de 1958 sigue usándose hoy en día: sustituirlo sería demasiado caro

No te creas todo lo comentado en Xataka, más bien créete poco. No porque quieran mentir descaradamente, simplemente no saben de lo que escriben, muchas veces se dedican a traducir artículos, pero quieren darle "un toque personal", pues ya a una mala traducción, pues la rematan.

Esto ni es tecnología obsoleta, ni hardware obsoleto (no se ni de donde sacan algún dato que ponen en el artículo)... nada de nada. Por ejemplo ese "servidor obsoleto" resulta que es un Mainframe IBM Z10, ese modelo concreto no se el precio, porque hay muchas variantes, pero te puedo decir que la configuración más básica superaba los 95K$ americanos de precio de salida, pero el comentado creo que se acerca al medio millón de dólares, y es termino medio, porque hay configuraciones que rondaban los 2'5M de dólares americanos... Pero bueno, si han confundido MI MIPS o SI MIPS con MIPS.

Lo que llaman tecnología obsoleta es tecnología punta, no hay nada más punta que un Mainframe, incluso ese modelo que va a tener 10 años. Porque cuando compras un Mainframe no es para cambiarlo a los 2 años... te tiene que durar años y años... así este recibirá soporte aun una década más. Eso no impide que siguieron saliendo modelos nuevos.

Y he dicho el precio del hardware, pero esa es solo una parte, porque, aunque estos tengan una aplicación propia, recurrirán a IMS DB, IMS TM, CICS... y eso no compras la licencia, sino que pagas año a año.

Después lo que llaman software obsoleto, supongo que porque está escrito en COBOL, pues ni de lejos... es cierto que hoy en día si construyes una aplicación nueva como esta, pues seguramente no optes por COBOL o PL/1 sino por JAVA por ejemplo, o incluso ahora puedes ir por JavaScript (hay una versión de Node.js corriendo estos Mainframes)... Pero para esos volúmenes de datos, pues solo un Mainframe puede con ellos, solo algo como CISC puede con miles de transacciones simultaneas, solo IMS u otra base de datos por el estilo puede ofrecerte las prestaciones adecuadas para trabajar con esos volúmenes de datos.

Alguno dirá que para grandes volúmenes de datos ya no solo queda la opción de bases de datos jerárquicas o en red... que hay Teradata, Hadoop... bases de datos NoSQL, etc. Pero la respuesta es que no, es cierto que podría reutilizarse avances por ese lado, pero implicarían invertir una fortuna en tecnología base para hacerla equivalente. Además seguirías necesitando un Mainframe. Eso sí, te podrías deshacer del impuesto IBM (al final IBM la máquina te la vende a precio de coste, no ganan prácticamente nada con el hardware -igual que otros fabricantes, incluso en este caso que podrías cambiar uno de los suyos por este IBM sin problemas, como es el caso de los que venden Fujitsu o Hitachi- el negocio es el software que te "alquilan", el soporte, el preparar nuevos trabajadores... Porque mantener la evolución de los mainframes implica unas inversiones tremendas, para al final de año vender unos cuantos miles de unidades -por mucho que el más barato ronde los 100K$ y aunque vendieras todos a 2M$, al final hay mucha competencia y vendes a coste o incluso puede que por debajo de coste-, el negocio no es vender mainframes, sino el resto).

¿Por qué han intentado buscar alternativas? Sencillo, porque le pasa como a los bancos, grandes empresas, etc... y es algo que se viene arrastrando desde el cambio de los 80 a 90, con la popularización de los PCs con SO con interfaces gráficas amigables. Para cuando yo empecé la ingeniería informática en el 93 (coño ahora mismo no estoy seguro si fue en el 93 o en 92), pues ya se decía que COBOL estaba muerto, porque seguía anclado en interfaces de texto... las empresas dejaron de comprar terminales por PCs, etc. Ya apareciera Visual Basic, Power Builder también por esas fechas, Delphi aparecería también a mediados de los 90... después las bases de datos relacionales ya estaban maduras con Oracle e Informix a la cabeza durante esa década (y por detrás Sybase, MS SQL Server -inicialmente era la misma que la de Sybase-, DB2, Interbase, Ingres....), para aplicaciones de gestión más monopuesto pues DBASE, Clíper, Fox Pro, el reciente Access, Paradox... pues eran más prácticos que COBOL para ese tipo de aplicaciones y ya habían ganado en ese ámbito hacía años. Y desde 1995 la popularización de tecnologías web y especialmente Java, pues dieron un puntillazo final. Pues antes un ambiente así, en la Universidad COBOL ni se mencionaba, solo los que estudiaban FP en aquellos años seguían tocando algo de COBOL y por poco tiempo porque con los ciclos eso también cambió. Y España no fue una excepción, sino lo usual. Realmente muchas empresas es instituciones intentaron migrar fuera de COBOL a mediados de los 90.

Ante lo anterior, te encuentras que la mayoría de los programadores que siguen trabajando con COBOL tienen más de 50 años, y porque eran los que estudiaron hace +30 años (en los 80), poco usuales son los que están entre 40 y 50 años (de todos los que coincidieron conmigo estudiando, solo uno se especializó en COBOL que yo sepa)... y por debajo de 40 años, pues prácticamente no hay, es rarísimo. Y de PL/1 prácticamente no hay nadie programando en ese lenguaje usado en Mainframes y que tenga menos de 50 años.

Lo anterior implica una situación viciosa: como no hay nuevos trabajadores que entren a competir con los asentados, pues es más difícil conseguir nuevo personal, en un momento en que muchos de los que había están llegando a la edad de jubilación (y se jubilan). Eso por si solo es un problema ya grave, porque tarde o temprano, pues la migración tendrá que hacerse, porque ya no quedará nadie para mantener esas aplicaciones. Pero al mismo tiempo, como cada vez hay menos personal, y la demanda es elevada de ese personal, pues para mantener el que tienes y reponer las perdidas, pues tienes que subir sueldos y otras prestaciones... Solo hay que ver la cantidad de demandas que hay en España de programadores, analistas, etc de COBOL/CICS/DB2 por ejemplo, y eso que la mayoría no salen en portales como Infojobs. Y eso que en España, con la reconversión del sistema financiero, en donde se ha reducido el número de entidades financieras a una fracción de las que había hace solo 10 años (prácticamente han quedado media docena de cajas de ahorros del centenar que había), pues ha echo que, de repente, había muchos menos empleadores y debería haber habido una sobre oferta de programadores COBOL con experiencia en sector financiero (varias decenas de miles de trabajadores de banda se han ido a la calle)... pues no ha sido así, prácticamente es de los cuadros de personal que se les ofreció quedarse en las nuevas entidades a todos.... pues se está buscando nuevo personal. El motivo es muy sencillo: como la mayoría tenía +50 años, muchos de ellos han aprovechado cambios de sede, etc, para negarse cambiar y tener derecho a despido y así jubilarse con un diñerillo extra. Tienen dinero de sobra para vivir el resto de la vida.

Ante situaciones como esa, pues la alternativa es intentar portar esas aplicaciones (totalmente funcionales y actualizadas... que funcionan perfecto, etc) a Java y otras opciones. Pero claro, no es que vaya a ser algo caro, que lo será... sino que es un problema tremendo, porque el nuevo tiene que ponerse en marcha al mismo tiempo que el antiguo aun funcione... es un sistema critico y meter software nuevo no probado (por muchas pruebas que hagas, pues no puedes similar apropiadamente lo que supondrá su uso final) y cualquier tontería no solo es un follón, puede ser muchísimo dinero.

La otra opción, ya tomada en cuenta, pues es que COBOL vuelva al sistema educativo y todo lo demás que eso implica. Pero es como con los médicos, que hace 20 o 30 años había algo de exceso de oferta y por tanto muchos cogieron maletas y se fueron por Europa adelante... ahora en España empieza a haber un problema de que tampoco ya llegan los que salen de las facultades, porque una parte se van fuera por mejores sueldos y porque la medicina privada paga más. Pero no sirve de nada duplicar plazas en la universidad, si después llega el MIR o como se llame y ahí la oferta de plazas para las especialidades, pues no aumenta y no es fácil que aumente de un año para otro. Y como eso no es fácil e implicaría que las medidas que se decida tomar, pues no funcionarían en años y años (entre cambiar planes de estudios -varios años antes de empezar a usarse-, años de estudios de los nuevos estudiantes que cursen esos planes, que cojan experiencia, etc, al final pasan 15 años) y no es darlo solo, tendría que poner a disposición de los estudiantes equipos con los que aprender... y eso es mucho dinero que las propias universidades no quieren gastar, porque los que mandan no ven forma de sacar tajada. Y el resultado es que esta situación es así desde finales de los 80 (cuando se definió los planes educativos que se dieron a los largo de los 90 y que siguieron en vigor hasta los famosos planes 2000 y más reciente lo cambios al marco de Bolonia). Y comento la situación en España, pero en USA más de lo mismo, incluso en algunos casos peor, porque allí los que tendrían que tomar medias, pues son los que más dinero están haciendo con el problema.

hasta luego

Hablas de no tomarse en serio lo que se publica en Xataka pero tu comentario carece de sentido.

Comentas que solo un mainframe es capaz de aguantar esa cantidad de datos. Tu conoces el termine de computación distribuida? o la nube? sabes que usan empresas como facebook, google y amazon para sus servidores?

Un mainframe tiene muchísimas desventajas con respecto a la computación distribuida, que pasa si ocurre algún problema y el mainframe se daña o es necesario reiniciar? pierdes el servicio hasta que lo resuelvas. O que pasa si el mainframe se queda sin potencia suficiente y necesitas meterle mas recursos? pues a apagar la maquina, meterle unas tarjetas de RAM (por ejemplo) y volverla a encender. Y si la arquitectura de la maquina no soporta mas recursos? pues a comprar una nueva.

Con la computación distribuida ganas redundancia, así un equipo falle completamente tu sistema seguirá funcionando, también ganas escalabilidad horizontal prácticamente infinita, puesto que si necesitas mas recursos te basta con encender otro equipo detrás un balanceador.

Hoy por hoy los lenguajes de programación permiten la implementación de patrones y paradigmas complejos que son producto de la evolución del software y tienen como objetivo generar código de calidad en el menor tiempo posible y con la mayor mantenibilidad posible, eso es algo que un lenguaje procedimental tradicional no puede ofrecerte pues en esa época no se hablaba del desarrollo de software y sus metodologías como se habla estos años, en aquella época (y como muchos aún hacen ahora) la gente se sentaba a programar lo que le pedían como buenamente podían, sin buenas practicas o patrones.

Eso daba como resultado código que es difícil de mantener, que no utiliza los recursos de forma optima y que es susceptible a fallos. Lógicamente en programas como el del articulo el paso del tiempo y las actualizaciones han logrado pulir todos esos problemas.

Finalmente, ¿Porque no se sustituye? por costes, tal como dice el articulo. El sistema es de misión critica, no puede permitirse errores o tiempo offline y ademas es usado por quien sabe cuantos trabajadores de la administración publica. Invertir en un nuevo desarrollo implicaria entrenar a todos esos trabajadores en el uso del nuevo sistema, hacer una inversión para adquirir una arquitectura apta para este nuevo sistema.

Eso sin contar las complicaciones propias del desarrollo, probablemente en algún punto ambos sistemas deban coexistir, adicionalmente el sistema debe pasar por auditorias exhaustivas que garanticen su fiabilidad, todo esto se traduce en un gran gasto y como el sistema actual funciona pues el gobierno no se lo ha planteado.

Me llamas chiflado y dices que cualquier PC usando hardware actual le da 100000 patadas a un mainframe... yo no se quien será el loco. Me gustaría que me indicaras que PC, según tu, con el hardware que quieras, puede con unos cuantos miles de transacciones por segundo, después que sean realmente 24/365 (aun algunos mainframes que no se reinician más que cada varios años, mientras tanto trabajando las 24 horas del día y los 365 días del año)...

Aun así, seguiría sorprendido a considerar que un mainframe actual no es hardware actual... pero bueno, primero dime ese super PC que puede hacer lo que hace un mainframe y después hablamos.

Claro que se puede, la calidad de un código no depende del lenguaje (aunque hay lenguajes que te ponen más fácil crear código de calidad).