Estoy totalmente de acuerdo con lo que dices, yo soy un viejo "System Programmer" de finales de los 80's y estuve en el mundo Main Frame hasta comienzos del 2000, conocí desde Sistemas VSE/SP, VM, MVS y AS/400 y lo que cuentas lo entiendo completamente, estoy totalmente de acuerdo con tu comentario.
me gusto mucho el video, yo apenas voy comenzando en cobol, tus videos de instalacion de z/os 11 me ayudan mucho. Tiene todo el sentido lo que comentas, donde trabajo estan tratando de migrar un sistema a java, no esta soportando la carga como lo hace cobol, a mi me gusta mucho java pero sin duda o son los ingenieros los que les falla el diseño o cobol tiene grandes ventajas a comparacion de otros sistemas. Ojala tu canal tenga un gran crecimiento es muy util e interesante
Muy buen video!! Por lo que estoy viendo en clientes con z/OS es que bastantes buscan migrar sus aplicaciones a otros entornos en la nube. Su objetivo es quitar el Mainframe. Algunos están intentándolo con Microfocus (que IBM les demandó, pero creo que no llegó a nada) y otros rehacen sus procesos. Dos clientes que llevamos ya han sacado muchos de sus procesos con el objetivo de quitar su Mainframe en 2025. Otro cliente también tiene planes de quitarlo cuanto antes. Creo que en Mainframe cada vez habrá menos trabajo a la larga
Llevan diciendo eso 40 años, que el Mainframe lo van a quitar y tal. Si es cierto que cada vez mas empresas lo estan quitando, pero depende tambien del nivel de servicio que estan dispuestos a asumir, las grandes empresas que no se pueden permitir parar lo van a seguir manteniendo. Pero esto es lo mismo que el Cloud Repatriation: Cuando se den cuenta que los servicios en Cloud son muchisimo mas caros de mantener, muchas empresas volverán al CPD tradicional, y cada vez son mas los ejemplos que me estan terminando dando la razón.
@@mainframecorner Tienes razón! desde que conocí el Mainframe hace unos 14 años siempre lo han querido quitar, pero no daba el rendimiento esperado. También están aprovechando "el negocio de la modernización y el cloud" porque es atractivo e interesa vender estos servicios. Además, si yo fuese Amazon (por ejemplo), pondría un precio menor a los que migran del MF y, una vez ya sean mis clientes y hayan quitado el MF, se lo iría subiendo. Los clientes quieren quitar el MF para ahorrar y ganar más, pero las empresas de servicios cloud también quieren ganar más y eso lo van a pagar los clientes antes o después.
Buena opinión, gracias Y si en mi experiencia he visto que lo natural es simple lo mejor en el as400 A como he visto en las conexiones o soportes a sistemas abiertos son ineficiente o no al 100%
Modestamente, actualizar sistemas legacy con arquitecturas "state-of-the-art" es más una estrategia de tech-marketing. Lo mismo pasa con Rust intentando integrarse al kernel de Linux, lo que Torvalds ha descrito como una discusión filosófica. Incluso la Casa Blanca sugiere dejar C++ por lenguajes más seguros, o en el mundo JS donde cada año sale un nuevo y mejor framework de desarrollo web ¿?. Como mencionas, la tecnología AS/400 es increíble, funciona bien, y no tiene sentido reinventar lo que ya funciona salvo ampliar alguna funcionalidad para necesidades puntuales de interacción. Gracias por el vídeo
En el caso de aplicaciones de este tipo creo que lo que comentas de crear VPARS o LPARS con sistemas Linux para ejecutar esas aplicaciones Java u similares, mejor. O bién poner servidores tipo xSeries x86. Pero es mi opinión, esta claro que los sistemas zSeries y pSeries són los mas estables y robutos del mercado a nivel de hardware sin duda. Pero para esas aplicaciones Java mejor tener instancias u particiones separadas con Linux para ellas.
Buen dia, es que no es una cosa u otra, son las dos y al mismo tiempo. Eso es lo fantastico! Si tengo que meter 10 millones de registros, lo voy a hacer con un RPG, y seguramente ese RPG lo voy a ejecutar desde una aplicacion web java, que tambien esta corriendo dentro del as400, y lo voy a submitir en la qs36evoke y el java ira mirando como esta corriendo ese batch y reportando el estado en la WEB... Este hermoso aparato es una caja de herramientas, cada uno sabra que usar para poner un clavo o sacar una tuerca...
Yo tenia años que no tocaba RPG y gracias a dios que decidí comenzar de Cero con el free RPG y puro SQL. Coño que belleza de lenguaje y que capacidad de ejecutar todas las tareas de la máquina con puro SQL. Para mi del punto de programacion yo pondría todos los servicios dentro de un AS/400. La integración de una estructura DS con la tabla SQL es para cagarse. Me quedo con el AS hasta el fin de mi vida. Jodanse todos esos consultores artuditos como dices tú. Fuc..java linux y todas esas mierdas.
Jajaja, me causa mucha gracia tu comentario. Yo he venido aprendiendo todas y cada una de las modernas tecnologías desde Lenguaje Máquina, Ensamblador, BASIC, Cobol, RPG, FoxPro, DB2, DBase, C++, Java, etc. Python, Javascript y otras hiervas como Docker, Kubernetes y la verdad se pueden grandes cosas con todo esto al precio de que cada vez es más complejo y por ende es más dificil lograr estabilizar estos sistemas. Supongo que es equivalente a la época del AS 400 ya que se consideraba tecnología complicada y de "La NASA". Los sistemas que se hacían en los AS eran sistemas simples y directos y no se tenía que considerar tanta cosa como multihilos, multiprocesos, tuberías, UX/UI, etc. y en ese aspecto la programación en COBOL y RPG es exageradamente sencilla.
Estas bastante errado en tu ultima frase, RPG, COBOL y demas no son exageradamente sencillos de programar, y de hecho una de las cosas mas brutales que tiene el AS/400 es su dispatcher que permite multihilo y descomposición en tareas simples un programa complejo lo que le dota de redundancia y paralelismo aunque tu no hayas querido programarlo asi. Lo que la gente desgraciadamente no entiende es que en los frameworks actuales se introducen miles de funciones en APIs que se precargan en el codigo objeto aunque luego de esas miles de funciones tu programa solo use dos. Y asi luego un programa hecho en free que crea 10 millones de registros ocupa varios KB, y el mismo programa en JAVA ocupa varios megas y te come la mitad de la RAM ya que la JVM precarga todas las APIs aunque luego solo vayas a usar dos funciones de ellas. Y asi es como la calidad de la programacion actual es la que es y ha bajado la eficiencia brutalmente. No se trata de ser nostalgicos, se trata de practicidad y economia en la programacion, y lamentablemente hoy en dia en vez de investigar por que tu programa va muy lento, se prefiere comprar una maquina mas potente. Y asi nos va.
la semana pasada estaba solicitando soporte a IBM y me di cuenta que en el formulario decía OS/400 en vez de IBM i, los propios creadores le siguen llamando 400.
La IBM actual que está haciendo esos rebranding, es la IBM de toda la vida? IBM "made in USA"? Porque buena parte ha sido vendida a Lenovo y no sé si a otras marcas. Te mereces muchos más suscriptores, excelente contenido, gracias!
IBM "made in USA" es la que todavia fabrica Mainframes y equipos POWER. El resto, efectivamente, PCs y servidores, fue vendido a Lenovo hace ya varios años.
Apa Urtzi!!! Puede ser que parte de la culpa del rendimiento del servidor de minecraft venga tambien por el rendimiento de la JVM en entornos PowerPc?? Nunca he desarrollado para ese entorno, pero me podria cuadrar. Estaria bien hacer pruebas de rendimiento a eso. Un saludo!!!
En los anos 2000 fui un desarrollador de aplicaciones Visual Basic 6.0 conectado a OS/390 a través del SNA Server y recuerdo el uso de unos archivo especiales para invocar las transacciones. ¿Actualmente se hace esas integraciones hacia el AS/400 con Host Integration Server?... Es que ahorita es que vengo retomando el uso de COBOL/CICS (Instalé una máquina virtual Hécules con OS/390 siguiendo todos tus videos) porque seguí el rumbo de .NET/Java y ahora estoy viendo la posibilidad de integrar aplicaciones con AS/400 como lo hacía años.
AS/400 nunca he necesitado HIS, eso era para conexiones SNA puras con OS/390, AS/400 es un sistema operativo distinto. Todo se hace ahora via TCP/IP, y la gran mayoria de usos que se le da al AS/400 es como custodio de datos, es decir, acceso al DB2 via JDBC o ODBC.
Repito, esas confundiendo los sistemas: Hercules es un emulador de Mainframe (MVS, OS/390 y z/OS), pero el AS/400 es otro sistema DISTINTO que ademas no puede ser emulado. Te veo muy perdido, y eso que has trabajado con esos sistemas :)
100 % de acuerdo con tus palabras, irónicamente lo que esta pasando ahora es que cada vez mas app va a trabajar en el IFS (uso de PASE)...entonces llega el punto que te pones a pensar para que quiero seguir usando el IBM i , si al fin al cabo me conviene pasar a una distribución de Linux , migrar mi base de datos / convertir mis PGM de COBOL o RPG a algun lenguaje mas actual y usar directamente otra tecnología, lo que hacia fuerte al AS/400 (hoy IBM i ) era como bien indicas vos la relacion "DB2 -RPG/COBOL/C" , todo lo que armes ahí vuela, si queres pasar esa misma lógica a Java o algún lenguaje que corra en PASE esto cambia, y el rendimiento puede ser menor o igual a un X86 como indicaste en el ejemplo...el trabajo duro lo va a tener IBM para poder "mejorar el rendimiento" en PASE para que se acerque lo mas posible al Nativo que conocimos hace años...sino los Clientes con equipos IBM i van a empezar a migrar a otras plataformas, ya que no tiene sentido seguir estando en un IBM i .
No creo que eso vaya a pasar, porque por esa regla de tres, tu pueden poner una LPAR de Linux junto a otra LPAR de AS/400 en la misma maquina fisica, y coexistir sin problemas, y eso no ha generado un exodo de programacion "legacy" a nuevas tecnologias...
Claro, igual entiendo que lo que platea es ...que posibilidad hay de que una Empresa nueva decidiera usar IBM i , eso es lo que tenemos que analizar, ya que al ser un sistema heredado la cantidad de nueva empresas a adoptar este tipo de sistemas tiende a ser nula. Lo que si es de admirar es que la mayoría si lo tiene no lo migra y eso habla muy bien de está tecnología que se va ayornando constantemente con lo "nuevo"
Pues yo he visto comprar maquinas IBM i pero solamente para custodio de datos DB2 porque son mucho mas eficientes que un Oracle RAC o varios SQL Servers de Microsoft y sus licencias son mucho mas baratas tambien. No es muy habitual, pero existen casos (uno muy cerca de mi casa en la Autoridad Portuaria de Bilbao) que cuando quieren eficiencia y velocidad, optan por estas máquinas. Ahora bien, el gran resto de empresas que tienen IBM i es porque han ido manteniendo sus aplicaciones COBOL y RPG tradicionales.
Otro problema del AS400 en el ejemplo de Minecraft es el consumo, una máquina virtual sobre arquitectura PC no solo tiene hoy mayor rendimiento sino que a un consumo energético mucho menor.
Lo de consumo energético no te lo compro, he podido comprobar el consumo de un POWER10 frente a un Servidor x86 y consumen lo mismo a dia de hoy. Es mas, cuando ves una instalacion Mainframe al ver los racks tan grandes siempre se piensa que como tradicionalmente consumian un montón, pues sigue siendo asi, pero nada mas lejos de la realidad, yo he visto una granja de 16 servidores VMware que superaban con creces el consumo de un Mainframe, por lo que todo depende del punto de vista y del numero de maquinas.
Muy parecida es la figura en Mainframe zOS, esta muy a la moda “falsa la modernización “ impulsada por los hyperscalers, basicamente mover las apps a otro entorno con un performance muy pobre ñ.
Si, en z/OS tienen esa capa nueva llamado ZOWE que pretende "dockerizar" los procesos internos del mainframe, pero no se yo si eso va a cuajar a corto plazo...
Yo no conozco nada sobre cobol y estas chunches de las que hablan pero me encanta la idea de procesar millones de registros lo más veloz posible! Creo que bien las nuevas tecnologías irán reemplazando a otras pero en el caso de los procedurales en maquinones de los que hablan son esenciales para mantener una integridad. El problema de las nuevas generaciones es que hacen código pensando que va a funcionar a la N y no es así.
Yo creo que el problema de base es que no habría que seguir usando software de hace 20 años. Y no se cuanta vida le va quedar a esto pero creo que poca. Al final todo va a tirar a la nube con clusters con HA sobre capas de virtualizacion que son mucho más eficientes. En cuando a rendimiento les han comido los huevos desde hace tiempo , que un macstudio Max te va a rular ese server de Minecraft millones de veces más rápido que el as400, y tampoco es que los equipos Unix sean inestables, con fuentes redundantes en buen cpd puedes tener uptimes brutales y sino siempre tirar a por el cluster, ha, y tecnologías más modernas. La bolsa de Tokio por ejemplo rula sobre un cpd cloud dedicado montado por oracle y por amigos que trabajan en ellos la mayoría de bancos están migrando todo a microservicios en aws cosas así.
No puedo estar mas en desacuerdo contigo, el software bien programado te puede durar 20, 40 o 60 años sin problema, no hay ninguna necesidad de cambiarlo si sigue cumpliendo con su función, es muy eficiente y se programa y programaba teniendo el rendimiento y la economía de la CPU muy en cuenta, y precisamente ese desdén que muestran las nuevas tecnologías de programación con respecto en la eficiencia de sus compiladores y generadores de código objeto es lo que hace que se requieran cojomaquinas para ejecutar los mismos programas que antes ocupaban un mega y ahora ocupan 10 gigas porque incluyen miles de APIs en sus mastodónticos frameworks que luego en la practica ni se utilizan pero que se añaden como código objeto, lo que luego da lugar a inestabilidades en su ejecución. Por supuesto, un AS/400 no esta pensado para soportar un Minecraft, eso fue un ejemplo que yo monté para comprobar que tal se comportaba JAVA, y al final JAVA es lo que es, un mastodonte que come recursos como por un tubo para escribir por pantalla "hola mundo". Respecto al HA que comentas, creo que estamos hablando de cosas distintas, y tecnologías distintas. Todavía no he visto un Oracle RAC que garantice los 6 "nueves" de disponibilidad cosas que estas arquitecturas si que hacen y me atrevo a decir que no son comparables. Tu pretendes clonar y replicar maquinas para garantizar la calidad del servicio, yo con una te hago lo mismo. Así que imagínate si pongo dos y monto un DB2mirror, en vez de 6 nueves, tendría 12, por lo que siempre seguiría ganando la robustez (y ojo, debo decir que el AIX de IBM es de los mejores Unix que he visto en mi vida). No estamos hablando de duplicar hardware, estamos hablando de la disponibilidad de aplicaciones criticas, y tiene mucho que ver la naturaleza de su programación. Basta con ir a la base de datos de CVEs para comprobar las vulnerabilidades y flipar las pocas que tienen z/OS o OS/400 y compararlas con Linux o Windows... Por ultimo, es innegable que el Cloud ha venido para quedarse, pero un banco de renombre, va a seguir teniendo su core en un DB2 bajo un mainframe con z/OS con aplicaciones COBOL bajo CICS, eso un hecho y punto, te guste o no. Lo que se llevan a la nube son microservicios y capas de presentación, pero todos esos microservicios al final consultan un CICS o un IMS, por lo que tu argumento es invalido. Y el ejemplo de la Bolsa de Tokio es una evidencia anecdótica, yo te puedo poner 100 ejemplos de bolsas y mercados de valores (en España BMX) que tienen en su core un Mainframe y no por eso desacredito a Oracle y su gran trabajo en Tokio.
@@mainframecorner si si, pero ya me entiendes, que las cosas tienen que evolucionar poco a poco y tampoco es bueno quedarse estancados en cosas old-school con codigo de 30-40 años simplemente porque funciona, para alguna aplicacion muy puntual igual si aun asi, hay que ir evolucionando y hay formas de hacer las cosas estables, large scale, super low lantency, etc como estan probando en los CPDs gigantes de IA que ya ni usan TCP/IP. Va a cambiar todo esto mucho sobre todo en los próximos 5-10 años. Aunque no nos guste, algun día los mainframes acabaran muriendo
Me entra la duda si mas bien sería posible hacer una VM con QEMU para correr un AS400 virtualizado. El hecho de que Java vaya mas lento en el AS400 se puede deber a que el procesador de la JVM esté más cercano su arquitectura a los x86 que a los PowerPC por lo que para una misma instrucción, se generen más instrucciones equivalentes para el PowerPC. Eso explicaría la caída de rendimiento. Por otro lado dependería si el PowerPC es RISC o CISC. Es de mencionar que aquí lo más conviente talves sería usar algun compilador JIT para generar el código en lenguaje máquina del PowerPC y probar si este es el caso. Otra es lo que dices tu, los llamados a Kernel desde Java tengan alguna especie de penalización por pasar a bibliotecas legacy a diferencia de Cobol y RPG que están más perfilados al AS400. Lo que si he notado es que los sistemas ahora son más complejos en todo aspecto sin embargo son menos estables que los sistemas desarrollados en estas tecnologías.
No, QEMU no te sirve para emular un AS/400 y es porque la MI es un secreto celosamente guardado por IBM asi que sin esa capa es imposible poder levantar el sistema.
Estoy al 100% contigo!! gracias por todos tus vídeos y tus esclarecedoras exposiciones!!
excelente explicación
Estoy totalmente de acuerdo con lo que dices, yo soy un viejo "System Programmer" de finales de los 80's y estuve en el mundo Main Frame hasta comienzos del 2000, conocí desde Sistemas VSE/SP, VM, MVS y AS/400 y lo que cuentas lo entiendo completamente, estoy totalmente de acuerdo con tu comentario.
Gracias por tu trabajo, una fuente enorme de conocimiento. Seguiré atento tus aportes. Saludos.
me gusto mucho el video, yo apenas voy comenzando en cobol, tus videos de instalacion de z/os 11 me ayudan mucho. Tiene todo el sentido lo que comentas, donde trabajo estan tratando de migrar un sistema a java, no esta soportando la carga como lo hace cobol, a mi me gusta mucho java pero sin duda o son los ingenieros los que les falla el diseño o cobol tiene grandes ventajas a comparacion de otros sistemas. Ojala tu canal tenga un gran crecimiento es muy util e interesante
Me harias un gran favor si compartes mi contenido en tus redes para que llegue a mas gente, gracias!
Gracias Urtzi.
Muy buen video!! Por lo que estoy viendo en clientes con z/OS es que bastantes buscan migrar sus aplicaciones a otros entornos en la nube. Su objetivo es quitar el Mainframe.
Algunos están intentándolo con Microfocus (que IBM les demandó, pero creo que no llegó a nada) y otros rehacen sus procesos. Dos clientes que llevamos ya han sacado muchos de sus procesos con el objetivo de quitar su Mainframe en 2025. Otro cliente también tiene planes de quitarlo cuanto antes.
Creo que en Mainframe cada vez habrá menos trabajo a la larga
Llevan diciendo eso 40 años, que el Mainframe lo van a quitar y tal. Si es cierto que cada vez mas empresas lo estan quitando, pero depende tambien del nivel de servicio que estan dispuestos a asumir, las grandes empresas que no se pueden permitir parar lo van a seguir manteniendo. Pero esto es lo mismo que el Cloud Repatriation: Cuando se den cuenta que los servicios en Cloud son muchisimo mas caros de mantener, muchas empresas volverán al CPD tradicional, y cada vez son mas los ejemplos que me estan terminando dando la razón.
@@mainframecorner Tienes razón! desde que conocí el Mainframe hace unos 14 años siempre lo han querido quitar, pero no daba el rendimiento esperado.
También están aprovechando "el negocio de la modernización y el cloud" porque es atractivo e interesa vender estos servicios.
Además, si yo fuese Amazon (por ejemplo), pondría un precio menor a los que migran del MF y, una vez ya sean mis clientes y hayan quitado el MF, se lo iría subiendo.
Los clientes quieren quitar el MF para ahorrar y ganar más, pero las empresas de servicios cloud también quieren ganar más y eso lo van a pagar los clientes antes o después.
Excelente.
Eres un figura. Genial.
Buena opinión, gracias
Y si en mi experiencia he visto que lo natural es simple lo mejor en el as400
A como he visto en las conexiones o soportes a sistemas abiertos son ineficiente o no al 100%
Modestamente, actualizar sistemas legacy con arquitecturas "state-of-the-art" es más una estrategia de tech-marketing. Lo mismo pasa con Rust intentando integrarse al kernel de Linux, lo que Torvalds ha descrito como una discusión filosófica. Incluso la Casa Blanca sugiere dejar C++ por lenguajes más seguros, o en el mundo JS donde cada año sale un nuevo y mejor framework de desarrollo web ¿?. Como mencionas, la tecnología AS/400 es increíble, funciona bien, y no tiene sentido reinventar lo que ya funciona salvo ampliar alguna funcionalidad para necesidades puntuales de interacción. Gracias por el vídeo
En resumen: si funciona, no lo toques.
En el caso de aplicaciones de este tipo creo que lo que comentas de crear VPARS o LPARS con sistemas Linux para ejecutar esas aplicaciones Java u similares, mejor. O bién poner servidores tipo xSeries x86. Pero es mi opinión, esta claro que los sistemas zSeries y pSeries són los mas estables y robutos del mercado a nivel de hardware sin duda. Pero para esas aplicaciones Java mejor tener instancias u particiones separadas con Linux para ellas.
Buen dia, es que no es una cosa u otra, son las dos y al mismo tiempo. Eso es lo fantastico! Si tengo que meter 10 millones de registros, lo voy a hacer con un RPG, y seguramente ese RPG lo voy a ejecutar desde una aplicacion web java, que tambien esta corriendo dentro del as400, y lo voy a submitir en la qs36evoke y el java ira mirando como esta corriendo ese batch y reportando el estado en la WEB... Este hermoso aparato es una caja de herramientas, cada uno sabra que usar para poner un clavo o sacar una tuerca...
Yo tenia años que no tocaba RPG y gracias a dios que decidí comenzar de Cero con el free RPG y puro SQL. Coño que belleza de lenguaje y que capacidad de ejecutar todas las tareas de la máquina con puro SQL. Para mi del punto de programacion yo pondría todos los servicios dentro de un AS/400. La integración de una estructura DS con la tabla SQL es para cagarse. Me quedo con el AS hasta el fin de mi vida. Jodanse todos esos consultores artuditos como dices tú. Fuc..java linux y todas esas mierdas.
Jajaja, me causa mucha gracia tu comentario. Yo he venido aprendiendo todas y cada una de las modernas tecnologías desde Lenguaje Máquina, Ensamblador, BASIC, Cobol, RPG, FoxPro, DB2, DBase, C++, Java, etc. Python, Javascript y otras hiervas como Docker, Kubernetes y la verdad se pueden grandes cosas con todo esto al precio de que cada vez es más complejo y por ende es más dificil lograr estabilizar estos sistemas. Supongo que es equivalente a la época del AS 400 ya que se consideraba tecnología complicada y de "La NASA". Los sistemas que se hacían en los AS eran sistemas simples y directos y no se tenía que considerar tanta cosa como multihilos, multiprocesos, tuberías, UX/UI, etc. y en ese aspecto la programación en COBOL y RPG es exageradamente sencilla.
Estas bastante errado en tu ultima frase, RPG, COBOL y demas no son exageradamente sencillos de programar, y de hecho una de las cosas mas brutales que tiene el AS/400 es su dispatcher que permite multihilo y descomposición en tareas simples un programa complejo lo que le dota de redundancia y paralelismo aunque tu no hayas querido programarlo asi. Lo que la gente desgraciadamente no entiende es que en los frameworks actuales se introducen miles de funciones en APIs que se precargan en el codigo objeto aunque luego de esas miles de funciones tu programa solo use dos. Y asi luego un programa hecho en free que crea 10 millones de registros ocupa varios KB, y el mismo programa en JAVA ocupa varios megas y te come la mitad de la RAM ya que la JVM precarga todas las APIs aunque luego solo vayas a usar dos funciones de ellas. Y asi es como la calidad de la programacion actual es la que es y ha bajado la eficiencia brutalmente. No se trata de ser nostalgicos, se trata de practicidad y economia en la programacion, y lamentablemente hoy en dia en vez de investigar por que tu programa va muy lento, se prefiere comprar una maquina mas potente. Y asi nos va.
la semana pasada estaba solicitando soporte a IBM y me di cuenta que en el formulario decía OS/400 en vez de IBM i, los propios creadores le siguen llamando 400.
Genial
La IBM actual que está haciendo esos rebranding, es la IBM de toda la vida? IBM "made in USA"? Porque buena parte ha sido vendida a Lenovo y no sé si a otras marcas.
Te mereces muchos más suscriptores, excelente contenido, gracias!
IBM "made in USA" es la que todavia fabrica Mainframes y equipos POWER. El resto, efectivamente, PCs y servidores, fue vendido a Lenovo hace ya varios años.
Apa Urtzi!!!
Puede ser que parte de la culpa del rendimiento del servidor de minecraft venga tambien por el rendimiento de la JVM en entornos PowerPc??
Nunca he desarrollado para ese entorno, pero me podria cuadrar. Estaria bien hacer pruebas de rendimiento a eso.
Un saludo!!!
Pues cuando quieras, podria darte acceso remoto a una de mis maquinas para que lo pruebes en tus carnes :)
Acá en Chile pasa lo mismo. Todos saben que es un AS/400 y todos se confunden cuando se usa el nombre actual.
En los anos 2000 fui un desarrollador de aplicaciones Visual Basic 6.0 conectado a OS/390 a través del SNA Server y recuerdo el uso de unos archivo especiales para invocar las transacciones. ¿Actualmente se hace esas integraciones hacia el AS/400 con Host Integration Server?... Es que ahorita es que vengo retomando el uso de COBOL/CICS (Instalé una máquina virtual Hécules con OS/390 siguiendo todos tus videos) porque seguí el rumbo de .NET/Java y ahora estoy viendo la posibilidad de integrar aplicaciones con AS/400 como lo hacía años.
AS/400 nunca he necesitado HIS, eso era para conexiones SNA puras con OS/390, AS/400 es un sistema operativo distinto. Todo se hace ahora via TCP/IP, y la gran mayoria de usos que se le da al AS/400 es como custodio de datos, es decir, acceso al DB2 via JDBC o ODBC.
@@mainframecorner Maravilloso, voy a ver el hilo de videos que tienes de AS/400 para montar uno con Hercules
Repito, esas confundiendo los sistemas: Hercules es un emulador de Mainframe (MVS, OS/390 y z/OS), pero el AS/400 es otro sistema DISTINTO que ademas no puede ser emulado. Te veo muy perdido, y eso que has trabajado con esos sistemas :)
@@mainframecorner Entiendo... Tienes mucha razón
100 % de acuerdo con tus palabras, irónicamente lo que esta pasando ahora es que cada vez mas app va a trabajar en el IFS (uso de PASE)...entonces llega el punto que te pones a pensar para que quiero seguir usando el IBM i , si al fin al cabo me conviene pasar a una distribución de Linux , migrar mi base de datos / convertir mis PGM de COBOL o RPG a algun lenguaje mas actual y usar directamente otra tecnología, lo que hacia fuerte al AS/400 (hoy IBM i ) era como bien indicas vos la relacion "DB2 -RPG/COBOL/C" , todo lo que armes ahí vuela, si queres pasar esa misma lógica a Java o algún lenguaje que corra en PASE esto cambia, y el rendimiento puede ser menor o igual a un X86 como indicaste en el ejemplo...el trabajo duro lo va a tener IBM para poder "mejorar el rendimiento" en PASE para que se acerque lo mas posible al Nativo que conocimos hace años...sino los Clientes con equipos IBM i van a empezar a migrar a otras plataformas, ya que no tiene sentido seguir estando en un IBM i .
No creo que eso vaya a pasar, porque por esa regla de tres, tu pueden poner una LPAR de Linux junto a otra LPAR de AS/400 en la misma maquina fisica, y coexistir sin problemas, y eso no ha generado un exodo de programacion "legacy" a nuevas tecnologias...
Claro, igual entiendo que lo que platea es ...que posibilidad hay de que una Empresa nueva decidiera usar IBM i , eso es lo que tenemos que analizar, ya que al ser un sistema heredado la cantidad de nueva empresas a adoptar este tipo de sistemas tiende a ser nula. Lo que si es de admirar es que la mayoría si lo tiene no lo migra y eso habla muy bien de está tecnología que se va ayornando constantemente con lo "nuevo"
Pues yo he visto comprar maquinas IBM i pero solamente para custodio de datos DB2 porque son mucho mas eficientes que un Oracle RAC o varios SQL Servers de Microsoft y sus licencias son mucho mas baratas tambien. No es muy habitual, pero existen casos (uno muy cerca de mi casa en la Autoridad Portuaria de Bilbao) que cuando quieren eficiencia y velocidad, optan por estas máquinas. Ahora bien, el gran resto de empresas que tienen IBM i es porque han ido manteniendo sus aplicaciones COBOL y RPG tradicionales.
Otro problema del AS400 en el ejemplo de Minecraft es el consumo, una máquina virtual sobre arquitectura PC no solo tiene hoy mayor rendimiento sino que a un consumo energético mucho menor.
Lo de consumo energético no te lo compro, he podido comprobar el consumo de un POWER10 frente a un Servidor x86 y consumen lo mismo a dia de hoy. Es mas, cuando ves una instalacion Mainframe al ver los racks tan grandes siempre se piensa que como tradicionalmente consumian un montón, pues sigue siendo asi, pero nada mas lejos de la realidad, yo he visto una granja de 16 servidores VMware que superaban con creces el consumo de un Mainframe, por lo que todo depende del punto de vista y del numero de maquinas.
@@mainframecorner Pues no lo sabía, gracias.
Muy parecida es la figura en Mainframe zOS, esta muy a la moda “falsa la modernización “ impulsada por los hyperscalers, basicamente mover las apps a otro entorno con un performance muy pobre ñ.
Si, en z/OS tienen esa capa nueva llamado ZOWE que pretende "dockerizar" los procesos internos del mainframe, pero no se yo si eso va a cuajar a corto plazo...
Yo no conozco nada sobre cobol y estas chunches de las que hablan pero me encanta la idea de procesar millones de registros lo más veloz posible! Creo que bien las nuevas tecnologías irán reemplazando a otras pero en el caso de los procedurales en maquinones de los que hablan son esenciales para mantener una integridad. El problema de las nuevas generaciones es que hacen código pensando que va a funcionar a la N y no es así.
Creo que AS/400 juega en otra liga y sacarlo de su entorno natural es un error, al igual que Linux no compite con un RPG para Intel
Lo idea es la coexistencia, y asi poder sacar lo mejor de ambos mundos.
Yo creo que el problema de base es que no habría que seguir usando software de hace 20 años. Y no se cuanta vida le va quedar a esto pero creo que poca. Al final todo va a tirar a la nube con clusters con HA sobre capas de virtualizacion que son mucho más eficientes. En cuando a rendimiento les han comido los huevos desde hace tiempo , que un macstudio Max te va a rular ese server de Minecraft millones de veces más rápido que el as400, y tampoco es que los equipos Unix sean inestables, con fuentes redundantes en buen cpd puedes tener uptimes brutales y sino siempre tirar a por el cluster, ha, y tecnologías más modernas. La bolsa de Tokio por ejemplo rula sobre un cpd cloud dedicado montado por oracle y por amigos que trabajan en ellos la mayoría de bancos están migrando todo a microservicios en aws cosas así.
No puedo estar mas en desacuerdo contigo, el software bien programado te puede durar 20, 40 o 60 años sin problema, no hay ninguna necesidad de cambiarlo si sigue cumpliendo con su función, es muy eficiente y se programa y programaba teniendo el rendimiento y la economía de la CPU muy en cuenta, y precisamente ese desdén que muestran las nuevas tecnologías de programación con respecto en la eficiencia de sus compiladores y generadores de código objeto es lo que hace que se requieran cojomaquinas para ejecutar los mismos programas que antes ocupaban un mega y ahora ocupan 10 gigas porque incluyen miles de APIs en sus mastodónticos frameworks que luego en la practica ni se utilizan pero que se añaden como código objeto, lo que luego da lugar a inestabilidades en su ejecución. Por supuesto, un AS/400 no esta pensado para soportar un Minecraft, eso fue un ejemplo que yo monté para comprobar que tal se comportaba JAVA, y al final JAVA es lo que es, un mastodonte que come recursos como por un tubo para escribir por pantalla "hola mundo". Respecto al HA que comentas, creo que estamos hablando de cosas distintas, y tecnologías distintas. Todavía no he visto un Oracle RAC que garantice los 6 "nueves" de disponibilidad cosas que estas arquitecturas si que hacen y me atrevo a decir que no son comparables. Tu pretendes clonar y replicar maquinas para garantizar la calidad del servicio, yo con una te hago lo mismo. Así que imagínate si pongo dos y monto un DB2mirror, en vez de 6 nueves, tendría 12, por lo que siempre seguiría ganando la robustez (y ojo, debo decir que el AIX de IBM es de los mejores Unix que he visto en mi vida). No estamos hablando de duplicar hardware, estamos hablando de la disponibilidad de aplicaciones criticas, y tiene mucho que ver la naturaleza de su programación. Basta con ir a la base de datos de CVEs para comprobar las vulnerabilidades y flipar las pocas que tienen z/OS o OS/400 y compararlas con Linux o Windows... Por ultimo, es innegable que el Cloud ha venido para quedarse, pero un banco de renombre, va a seguir teniendo su core en un DB2 bajo un mainframe con z/OS con aplicaciones COBOL bajo CICS, eso un hecho y punto, te guste o no. Lo que se llevan a la nube son microservicios y capas de presentación, pero todos esos microservicios al final consultan un CICS o un IMS, por lo que tu argumento es invalido. Y el ejemplo de la Bolsa de Tokio es una evidencia anecdótica, yo te puedo poner 100 ejemplos de bolsas y mercados de valores (en España BMX) que tienen en su core un Mainframe y no por eso desacredito a Oracle y su gran trabajo en Tokio.
@@mainframecorner si si, pero ya me entiendes, que las cosas tienen que evolucionar poco a poco y tampoco es bueno quedarse estancados en cosas old-school con codigo de 30-40 años simplemente porque funciona, para alguna aplicacion muy puntual igual si aun asi, hay que ir evolucionando y hay formas de hacer las cosas estables, large scale, super low lantency, etc como estan probando en los CPDs gigantes de IA que ya ni usan TCP/IP. Va a cambiar todo esto mucho sobre todo en los próximos 5-10 años. Aunque no nos guste, algun día los mainframes acabaran muriendo
Me entra la duda si mas bien sería posible hacer una VM con QEMU para correr un AS400 virtualizado. El hecho de que Java vaya mas lento en el AS400 se puede deber a que el procesador de la JVM esté más cercano su arquitectura a los x86 que a los PowerPC por lo que para una misma instrucción, se generen más instrucciones equivalentes para el PowerPC. Eso explicaría la caída de rendimiento. Por otro lado dependería si el PowerPC es RISC o CISC. Es de mencionar que aquí lo más conviente talves sería usar algun compilador JIT para generar el código en lenguaje máquina del PowerPC y probar si este es el caso. Otra es lo que dices tu, los llamados a Kernel desde Java tengan alguna especie de penalización por pasar a bibliotecas legacy a diferencia de Cobol y RPG que están más perfilados al AS400.
Lo que si he notado es que los sistemas ahora son más complejos en todo aspecto sin embargo son menos estables que los sistemas desarrollados en estas tecnologías.
No, QEMU no te sirve para emular un AS/400 y es porque la MI es un secreto celosamente guardado por IBM asi que sin esa capa es imposible poder levantar el sistema.
@@mainframecorner Ohhh muchas gracias por tu respuesta