RPG a Java

RPG a java

¿RPG a java?

Relacionar a RPG y Java en la misma línea parece un sin sentido. Los dos son lenguajes de programación, eso sí, pero el primero es un lenguaje procedimental que data de 1959, con altas dependencias de la plataforma de despliegue y, el segundo, una alternativa moderna aparecida en 1995, con orientación a objetos y con la libertad casi total de desplegarse en cualquier entorno.

Resulta evidente que RPG y Java son dos lenguajes difícilmente comparables, por eso el proceso de trasladar código RPG a Java se plantea como un gran reto.

Desde hace varios años existe una presión real de mercado para modernizar antiguas aplicaciones RPG a un entorno GUI, WEB, Cloud o, incluso, a un entorno móvil o de código abierto.

Además, por su parte, IBM está alentando a las empresas a trasladar el RPG a java/J2EE.

El desafío está servido.

Algunos conceptos sobre RPG y java

El RPG es un lenguaje que fue concebido por IBM para su equipo 1401 (1959 – 1971) pero su gran popularidad está vinculada a las plataformas de tamaño medio para aplicaciones comerciales IBM AS/400 (1988) que se popularizaron en los años 90 y que hoy, en sus versiones más modernas, conocemos como IBM i. El éxito del tándem AS/400 y RPG fue tan grande que hasta el día de hoy siguen manejado millones de transacciones cada día.

Sin embargo, este lenguaje que cumplió un enorme ciclo de 70 años, ha envejecido mal, demostrado no poder dar respuesta a todas las exigencias actuales de los departamentos de IT. Digamos en honor de RPG que sus orígenes son muy lejanos, de hecho nació como un lenguaje que ayudaba en la transición desde las maquinas tabuladoras, a los primeros ordenadores modernos. Que se haya mantenido desde ese momento de nuestra prehistoria informática hasta el día de hoy es sin duda excepcional.

Por su gran difusión las aplicaciones que se desarrollaron en código RPG para AS/400 son ahora tema de estudio con el objeto de encontrar soluciones de modernización hacia plataformas actuales. Hay una enorme cantidad de experiencia, buenas ideas, mucho trabajo y aplicaciones útiles almacenadas en esas plataformas. Sn dudas, un patrimonio que no podemos perder.

Pero la evolución entre entornos tan dispares no es trivial. Y lo primero que se evidencia es que tanto la forma de trabajar como la arquitectura de las aplicaciones diseñadas en ambos lenguajes son completamente diferentes.

Esto obliga a estudiar concienzudamente el sistema original RPG y descubrir todos los puntos significativos, entender cuáles serán los problemas del cambio de lenguaje y los riesgos asociados.

Solo este proceso de análisis y conocimiento, puede asegurar el éxito y debe ser realizado siguiendo protocolos precisos que garanticen la consistencia del nuevo sistema y la calidad del nuevo código que se desplegará en el entorno de destino.

No hay soluciones mágicas, pero sí hay soluciones sólidas y muy probadas. Se requiere tecnología, trabajo concienzudo y experiencia. Pero el tesoro escrito en RPG y depositado dentro de los AS/400 puede volver brillar en plataformas modernas en plazos y costos muy rentables.

Las personas

Si bien se encuentran muchos conversores y transpilers en el mercado que prometen realizar la tarea de convertir RPG a java, generalmente fallan en el aspecto humano.

No basta con traducir de RPG a Java, hay que entender y limpiar el sistema original que se va a modernizar. Son sistemas con 10, 20, 30 o más años de edad con muchos aspectos que deben mejorarse.

También la experiencia y el conocimiento del equipo que realizará la migración son determinantes. Sin olvidarse de señalar la empatía y comprensión con la que debe abordarse el contacto con el equipo de personas que utiliza y mantiene el viejo software a migrar y que legítimamente consideran como “obra suya”.

Tanto los responsables que toman  la decisión, como los que crearon el sistema y los usuarios del mismo, deben encontrar beneficios en el proceso y en los resultados.

Estos mensajes importantes, solo los pueden comunicar de forma correcta un equipo con la experiencia y empatías entrenadas para tal fin.

El objetivo no solo es que el software traducido funcione exactamente igual que el código RPG original. Esto es obvio. Pero además es de vital importancia que el personal que giraba alrededor del sistema candidato a convertirparticipe activamente en el proceso de modernización, ya sea colaborando en la confección de los protocolos que se aplicaran en el citado proceso, así como en las pruebas de validación y certificación del código convertido.

Algunos puntos de atención.

Como ya hemos comentado RPG y Java son dos realidades muy distintas. Gestionar esas diferencias como puntos de atención, es un factor de éxito.

Podemos señalar rápidamente algunos.

  • Dependencia de la plataforma

El RPG está prácticamente embebido dentro de la plataforma AS400. Esta dependencia del código RPG de las distintas versiones de los sistemas operativos de la Serie i es el primer escollo a salvar.

El uso intensivo de funcionalidad del S.O. incluida dentro de los programas RPG es quizás el mayor problema. Por ejemplo, hay que buscar alternativas a funcionalidades como el Open Query File (OPNQRYF), Work Submitted Job (WRKSBMJOB) o Work Spool Files (WRKSPLF), de uso permanente por los programadores RPG.

  • Velocidades de acceso

Las consultas en RPG basadas en sistemas de archivos PF (physical file) y LF (logical file) son sumamente rápidas, por lo que también es clave la optimización de las consultas SQL en la plataforma de destino. Un AS/400 programado en RPG es una plataforma muy rápida ejecutando aplicaciones comerciales que incluyen mucho acceso a disco. El sistema resultante debe mantener o mejorar estas prestaciones

  • Lógica de procesamiento

El RPG es un lenguaje diseñado como no estructurado, pero debemos traducirlo a un lenguaje moderno fuertemente estructurado. Así, por ejemplo, una lista de instrucciones de flujo, que probablemente incluirá una cantidad apreciable de GOTOs, deberá convertirse a un código estructurado.

  • Secciones rígidas.

Algunas de las instrucciones en código RPG se alejan del paradigma de los sistemas abiertos y de Java. Por ejemplo, pantallas y programas están fuertemente acoplados, lo que presenta dificultades para evolucionar a una arquitectura multicapa.

Así como el  manejo de la información a nivel de bit con instrucciones como BITON y BITOF.

  • El problema de encoding

Aunque la primera respuesta es convertir los archivos de AS/400 a tablas de una RDB y transformar el EBCDIC a UTF-8, sin embargo, en algunos casos, esta solución puede ser problemática debido a la vinculación con sistemas externos que también usan EBCDIC. No hay una formula única, solo el análisis detallado del sistema puede guiarnos.

Impacto de la migración

  • Reducción y racionalización de costos.

El producto final no solo estará instalado en una infraestructura con menores costes, también las licencias de software presentan fuertes ahorros respecto la plataforma nativa.

Pero quizás el hecho fundamental es que toda la inversión ahora se dirigirá hacia el futuro de nuestros sistema IT.

Dejaremos de invertir en tecnologías que sabemos obsoletas y tarde o temprano habrá que sustituir.

  • Mayor productividad y mejor control

Además, se incrementa visiblemente la productividad, y los tiempos de prueba y desarrollo son menores, con lo que también descienden en general los costos de mantenimiento.

Por otro lado, un gran número de herramientas modernas, permiten un control de nuestras operaciones DEVOPS del que ahora carecemos.

  • Estandarización de la tecnología.

La tecnología moderna de tipo estándar, presenta puntos de integración sencillos con subsistemas propios o de terceros. Superando así el efecto “isla” que producen los sistemas Legacy, con los que es difícil interaccionar.

  • Nuevo mundo de recursos.

Tanto la nueva tecnología como el personal que la conoce es más accesible que en las plataformas Legacy.

Todos los recursos involucrados puedan reemplazarse  y modernizase más fácilmente.

Además de un mantenimiento más ágil, las habilidades requeridas para mantener el sistema resultan más fáciles de conseguir.

Cómo hacer una migración de RPG a java

Sin ninguna duda, Base100 provee las opciones mas flexibles para iniciar el camino de modernización de aplicaciones legacy.

Totalmente independizados de plataforma, el enfoque de Base100 no pone limitación al elegir el destino de la migración pudiendo seleccionar entre interfaces de acceso basadas en HTML5 o frameworks java como Angular o React, por ejemplo.

También, luego de una evaluación del sistema a transformar se construye un plan de modernización donde podremos elegir soluciones del tipo Caravel Express accediendo a traducciones prácticamente automáticas por medio de un rehosting en Java o Caravel Convert donde se propone una reingeniería basada en herramientas y la planificación humana está orientada a los aspectos finales.

Base100 no hace planteamientos rígidos y de procesos de larga duración, ofreciendo resultados sumamente flexibles en tiempos realmente reducidos.

Con Base100 tiene la seguridad de que toda la funcionalidad del sistema operativo y de todo tipo de objetos Legacy es convertida, garantizando un comportamiento idéntico en la plataforma de destino.

El sistema resultante transforma la arquitectura AS/400 a los estándares actuales de arquitectura abierta, ya sea para desplegarlos On premises o en Cloud.

La modernización de aplicaciones legacy

Esta es la razón de existir de Base100. Es lo que hacemos. Es lo que somos.

Sabemos que los Sistemas Legacy deben migrar hacia las nuevas tecnologías, pero somos conscientes que las decisiones las toman las personas que conviven día a día con ese sistema.

Queremos ayudarle a tomar la mejor decisión posible para cada uno de los problemas puntuales a los que se enfrenta.

¡Confíe en la experiencia Base100!

Le ofrecemos un conjunto de herramientas y productos con el objeto de que cualquier proceso de implementar soluciones de modernización de Mainframe z/OS o IBMi AS/400 hacia tecnologías mas modernas sea con una garantía de éxito indiscutible.

Puede seguir aquí:

¿Le interesa la propuesta?

¡Sigamos avanzando y hablemos de modernización!

Contáctenos