top of page

ASNA Monarch

ASNA Monarch® realiza la migración de las aplicaciones IBM i en RPG a .NET

Monarch transforma las aplicaciones escritas en ILE RPG o RPG/400®, en aplicaciones nativas .NET de Microsoft. Para un cambio de plataforma, Monarch migrará su base de datos de IBM i a SQL Server™. El resultado será una versión .NET basada en navegador web de sus aplicaciones RPG. Una vez migrado a .NET, puede extender y ampliar las aplicaciones de muchas maneras.

Beneficios de Monarch

Beneficios de ASNA Monarch

  • Monarch amplía las aplicaciones al completo. Con ASNA Monarch no solo migrará su código RPG/400 o ILE RPG, sino que también migrará todos los archivos necesarios como CL, DDS, archivos de impresión y de mensajes.

  • Monarch también puede migrar su base de datos. Para migraciones completas, ASNA Monarch puede también migrar su base de datos IBM i al Servidor MS SQL. Gracias a que Monarch utiliza ASNA DataGate, el acceso a nivel de registro existente en el RPG necesitará una mímina modificación para trabajar con el Servidor SQL.

  • Su aplicación de toda la vida se reubica en .NET.  Los profesionales de pantalla verde RPG, cada vez son más difíciles de encontrar. Migrando sus aplicaciones heredadas en .NET, está protegiendo el futuro de la aplicación. Una vez migrada a .NET, puede ser mantenida y potenciada por una nueva generación de programadores .NET.​

  • Etapas de la modernización/migración. ASNA Monarch funciona en consonancia con ASNA Wings para facilitar una estrategia de migración/modernización por etapas. Es decir, Wings se puede utilizar en las primeras etapas para ofrecer una interfaz de usuario modernizada, para después y paralelamente al avance del proyecto, migrar la lógica del negocio a .NET.

  • Ponga en manos de jóvenes programadores su legado de aplicaciones RPG. Una migración ASNA Monarch tiene como objetivo convertir las aplicaciones en ASNA Visual RPG o C# como lenguaje de .NET. Para aquellas empresas que necesiten programadores jóvenes para gestionar estas aplicaciones, C# es una gran opción. Las que dispongan de talento de programación RPG, lo es ASNA Visual RPG.

  • Proporcione a la interfaz de usuario de su aplicación un aire más moderno. Las aplicaciones ASNA Monarch contienen una presentación basada en navegador, implementada con el modelo de programación ASP.NET. Esta capa de presentación puede ser modificada y ampliada con técnicas estándar de desarrollo Web.

  • Herramientas analíticas incluídas. Monarch incorpora las herramientas necesarias para crear una hoja de ruta racional para la aplicación a migrar. Las aplicaciones RPG son muy extensas, en muchas ocasiones con más de un millón de líneas de RPG. El migrar estas aplicaciones tan grandes es complicado, y sin una buena guía el éxito es muy difícil de conseguir. Monarch ofrece las herramientas necesarias, como diagramas de llamadas o mediciones de aplicación, para una migración exitosa.

  • ASNA Servicios de migración disponibles. ASNA Monarch puede ser adquirida y desarrollada por su propio equipo, o puede contar con los especialistas de ASNA, altamente cualificados en la migración de aplicaciones y que pueden ayudarle con alguna o todas las etapas de la migración de sus aplicaciones.

Características Monarch

ASNA Monarch es un conjunto de programas que migran las aplicaciones RPG existentes en el IBM i a .NET, utilizando tanto la DB2 de IBM i como SQL Server. Monarch incluye un sofisticado componente analítico que ayuda al plan de migración, y “agentes” de migración que llevan sus aplicaciones RPG, CL y DDS a .NET. Monarch se convierte ASNA Visual RPG o Microsoft C#.

Migración a ASNA Visual RPG o Microsoft C#

Monarch puede migrar sus aplicaciones RPG a ASNA Visual RPG o Microsoft C#. El lenguaje seleccionado por usted dependerá de su tipo de negocio y de la estrategia de sus aplicaciones a nivel evolutivo. Existen dos tendencias de pensamiento sobre este tema, y generalmente viene definido por la trayectoria de su actual equipo de programadores RPG.

  • ASNA Visual RPGMicrosoft C#

Sin embargo, y si su equipo de programación RPG está muy consolidado en los conocimientos de RPG, y no conocen otras herramientas de desarrollo, será mejor para usted utilizar Monarch para migrar sus aplicaciones a ASNA Visual RPG. No sólo mantendrá a su equipo de programadores RPG, sino que probablemente serán los mismos que escribieron originalmente la aplicación, y serán los encargados de su modernización.

  • Microsoft C#

En el caso de que su equipo de programación RPG cuente en sus activos humanos con programadores expertos y consolidados en RPG junto con más jóvenes y especializados en C#, será más plausible, utilizar Monarch para producir aplicaciones C# y para la buena estrategia de la empresa.

Con ASNA Monarch, cualquiera de las dos opciones que escoja será completamente válida.

Utilice tanto la DB2 de IBM I o Microsoft SQL como servidor de sus aplicaciones migradas de su base de datos

ASNA Monarch conecta a través de ASNA DataGate a un servidor de base de datos subyacente. Este servidor puede ser el IBM i (utilizando su propia base de datos DB2) o Microsoft SQL Server. Este último es generalmente el objetivo cuando la finalidad del negocio es migrar todas las aplicaciones fuera de la plataforma IBM i. De todos modos, muchas empresas no utilizan Monarch para migrar su información fuera de la plataforma IBM i, sino para tener la capacidad de migrar sus aplicaciones RPG a .NET, para su posterior mejora y personalización.

ASNA DataGate realiza de una manera transparente la selección de la base de datos, a la aplicación migrada. Se podría migrar una aplicación RPG con Monarch e inicialmente conectarla con el IBM i, para después dirigir la aplicación al servidor SQL (teniendo en cuenta que la base de datos ha sido migrada al Servidor SQL). Esta es una de las características que le ofrece ASNA Monarch; el enfoque por etapas que le permite la migración gradual de su aplicación a .NET.

Una vez más, con ASNA Monarch, cualquiera de las dos opciones que escoja será completamente válida.​​​​​​​

Caracteristicas

ASNA Monarch conecta a través de ASNA DataGate a un servidor de base de datos subyacente. Este servidor puede ser el IBM i (utilizando su propia base de datos DB2) o Microsoft SQL Server. Este último es generalmente el objetivo cuando la finalidad del negocio es migrar todas las aplicaciones fuera de la plataforma IBM i. De todos modos, muchas empresas no utilizan Monarch para migrar su información fuera de la plataforma IBM i, sino para tener la capacidad de migrar sus aplicaciones RPG a .NET, para su posterior mejora y personalización.

ASNA DataGate realiza de una manera transparente la selección de la base de datos, a la aplicación migrada. Se podría migrar una aplicación RPG con Monarch e inicialmente conectarla con el IBM i, para después dirigir la aplicación al servidor SQL (teniendo en cuenta que la base de datos ha sido migrada al Servidor SQL). Esta es una de las características que le ofrece ASNA Monarch; el enfoque por etapas que le permite la migración gradual de su aplicación a .NET.

 

Una vez más, con ASNA Monarch, cualquiera de las dos opciones que escoja será completamente válida.

Monarch Cocoon—donde se origina la transformación de la aplicación

SNA Monarch Cocoon es una aplicación .NET que interroga específicamente las librerías del iSeries para descubrir los programas de bibliotecas y relaciones de los programas. Esta información se utiliza para descubrir las dependencias del programa, el análisis y planificación de la migración. Cocoon proporciona información como:

 

  • Programa call graph – Para detector dependencias de programa objeto en otros programas objetos OS/400 (es decir, los llamados programas y las API del Sistema).

  • Referencias cruzadas de uso de objetos – para identificar qué programas usan los objetos (tales como archivos, áreas de datos, etc.).

  • Host RPG vista de origen – para ver de una forma rápida a los códigos fuentes del sistema principal.

  • Los factores de densidad – le ofrezcan las cifras sobre la dificultad de migración de cualquier programa. Estos factores ayudan a planificar y asignar recursos de la migración.

  • Notas de la pantalla – a “diary” un área “diario”, donde registrar anotaciones sobre cada objeto descubierto.​

 

Cocoon produce gráficos de dependencia que muestran exactamente las diferentes dependencias que existen en la aplicación RPG de su IBM i. También muestra información como los objetos que han perdido su fuente, que programas de objetos son llamados con poca o nula frecuencia, y que objetos aparecen como caducados con su código fuente

Monarch Gameplan—especificar su estrategia

Monarch Gameplan define al programa o grupo de programas que desea migrar. Normalmente se crea un Gameplan para cada aplicación o sección de la aplicación que migre con Monarch. Un Gameplan especifica los atributos del programa tales como: las listas de bibliotecas, el programa de punto de entrada y la plataforma de base de datos activa.

 

Las formas gráficas en que Monarch presenta los objetos de IBM i y sus dependencias, facilitan las herramientas que necesita para crear gameplans racionales. Este trabajo analítico es muy importante para realizar una migración con éxito. La ventaja de establecer unos planes para la migración con Monarch Cocoon, facilitará el buen funcionamiento de la misma.

Monarch analítico en acción

En el lenguaje de Monarch, un cluster es un grupo de grupos. Los grupos pueden ser clasificados de diferentes maneras, pero la vía más común de hacerlo es identificarlos como agrupaciones naturales. Un cluster se forma por la entrada de un programa, combinado con tan solo aquellos programas que pueden ser llamados siguiendo el gráfico de llamadas. Normalmente los programas se migran por grupos de clusters y el reto de la migración, con complejos y grandes programas RPG, es identificar el punto de entrada de cada cluster.

A menudo se cree que utilizando las opciones de menú del IBM i, es un buen modo de definir los puntos de entrada del clúster, lo que es bastante desacertado. Consideremos un menú con dos opciones, la primera en la que el programa A llama al cluster A (izquierda); la segunda opción, en la que se llama al programa U en el cluster B. Podrá comprobar que tanto el programa A como el U, realizan llamadas de programa durante su ciclo de vida.

Esquema símil de migración de dos clusters

Los componentes analíticos de Monarch muestran que el programa V del cluster B, realiza una llamada al programa F del cluster A (tal como se indica en la figura de la izquierda, flecha en color rojo). Esto indica que, identificar los clusters directamente desde el menú de opciones, no es tan simple como parece. Aceptar la presentación de los clusters A y B tal como se define en la imagen, podría provocar problemas en el proceso de migración ya que, ambos clusters incluyen las llamadas que realiza el programa F.

Monarch muestra la dependencia del cluster B en el programa F del cluster A

Utilizando los gráficos de dependencia de Monarch, se identifica un nuevo cluster. Este nuevo cluster C será migrado en primer lugar, para después hacer lo mismo con el A y el B. De esta forma, el cluster C está listo para ser compartido con sus dos clusters originarios (tal como se indica en la imagen de la izquierda, con las flechas en color verde). Dependiendo del modo en el que el cluster C haya sido migrado, la función de C será una u otra. Si no utiliza ningún archivo de pantalla, lo más probable es que se migrara como una biblioteca de clases .NET. De una manera alternativa, se migraría con sus capacidades interactivas disponibles.

Monarch muestra que lo que se suponía que eran dos clusters, son en realidad tres clusters

bottom of page