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.

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.

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.

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

Vista de la aplicación ASNA Monarch Cocoon

ASNA 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

Cocoon muestra dependencia de gráficos
del programa de objetos de IBM i

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.

Esquema símil de migración de dos clusters
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.
Monarch muestra la dependencia del cluster B
en el programa F
del cluster A
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 que lo que se suponía
que eran dos clusters,
son en realidad tres clusters
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.