Migración de RPG a Java en IBM iSeries

Question

Nuestra empresa utiliza IBM iSeries para la mayoría de nuestro procesamiento de datos. Todas nuestras aplicaciones internas están escritas en juegos de rol. Según el mapa de ruta de IBM, IBM está presionando a las compañías para que se trasladen a Java/J2EE. Estamos buscando modernizar nuestras aplicaciones internas a una interfaz más GUI. Proporcionamos una presencia web externa mediante el uso de web Asp.Net, aunque tal vez los proyectos greenfield podrían ser Java. Una opción es usar una aplicación de raspador de pantalla mientras se mantiene en RPG, pero creo que puede ser mejor ir lentamente por el camino de hoja de ruta de IBM y pasar a Java. Nuestro objetivo es migrar a una interfaz GUI y estar en línea con la hoja de ruta de IBM.

¿Ha estado involucrado con una migración de rol a Java, incluso si solo los proyectos greenfield eran Java y los proyectos brownfield seguían siendo RPG?

Mi gestión tiene miedo de que:

1) la actualización de JRE en las estaciones de trabajo, los clientes particularmente delgadas, podría causar una pesadilla administrativa (Nuestra empresa utiliza 80% clientes ligeros y 20% PC) y

2) Java exige demasiada sobrecarga de la estación de trabajo para ejecutarse efectivamente

3) Incompatibilidad entre los clientes de JRE a medida que actualizamos, lo que puede romper otras aplicaciones que requieren el JRE.

¿Puede arrojar algo de luz sobre esto? ¿Hay grandes beneficios? ¿Tienes muchos problemas?

ACLARACIÓN: Solo estoy interesado en una migración a Java. ¿Cuál es el nivel de dificultad y pierdo algo al pasar de RPG a Java? ¿Las pantallas son muy receptivas cuando se migran a Java?

Answer 1

Mi empresa también está intentando migrar a Java desde RPG.

1. No estamos intentando usar un JRE en un thin-client, estamos pasando a aplicaciones web entregadas a través de un navegador. Esto puede implicar (eventualmente) reemplazar nuestros antiguos escáneres POS con algunos de los más nuevos basados ​​en PC.
2. He sido informado (por arquitectos de la compañía) de que la JVM en el sistema operativo iSeries tiene tiene algunos problemas de rendimiento. No sé personalmente cuáles son estas limitaciones. En nuestro caso, la migración ha implicado la asignación de un recurso de AIX, que se supone que es mucho mejor: hable con su representante de IBM sobre si solo necesita comprar la licencia del sistema operativo (solo programo el tema, no me involucro en hardware).
3. Consulte la respuesta a la pregunta 1. En un contexto más amplio, donde intenta actualizar el navegador (o cualquier otro recurso), esto generalmente se maneja teniendo licencias empresariales; la mayoría tendrá opciones para permitir forzado, remoto actualizaciones.

Algunas otras notas:

• Usted debe ser capaz de moverse a simplemente usando .NET, aunque es posible que tenga diferentes hardware/particiones para ejecutar el entorno. Puede hablar con DB2 de esa manera, al menos. El único beneficio que tiene Java es que se ejecutará en el mismo sistema operativo/hardware que la base de datos.
• He visto una aplicación screenscraper aquí (estaba en VB.NET, pero estoy bastante seguro de que se aplica el ejemplo). El raspado de la pantalla se logró colocando/colocando caracteres en posiciones específicas en las pantallas (el equivalente a substring()). Esa podría ser solo la API que estábamos usando, creo que he oído hablar de soluciones que podían leer los nombres de los campos. Sin embargo, también confió en el flujo del programa RPG para su lógica, y de otro modo no era mantenible.
• La mayoría de los programas de rol que he visto y escrito suelen ser una violación de MVC, lo que significa que no puedes hacer nada menos que pruebas de integración: la historia y la arquitectura del lenguaje (y algunos desarrolladores) prefieren que todo (acceso de archivo a la pantalla) en un archivo. Esto también hará que intentar envolver RPG para llamar de forma remota sea efectivamente imposible. SI ha separado correctamente todo en Programas de Servicio, debería ser capaz de envolverlos (como el equivalente de una llamada a método nativo, casi) prolijamente - desafortunadamente no he visto nada aquí que no haya tendido confiar en uno o más trucos que no soportarían el uso típico de la Web (por ejemplo, usar un archivo en QTEMP para controlar la ejecución del programa; la sesión del iSeries desaparece de manera efectiva cada vez que se solicita una nueva página ...).
• Java como lenguaje tiende a promover una mejor separación del código (tenga en cuenta que también se puede utilizar de forma incorrecta), ya que no tiene bastante historia de rol. En general, puede ser útil pensar en Java como un lenguaje donde todo es un programa de servicio, donde todos los parámetros se pasan con VALUE establecido, OPTIONS(*nopass : *omit) no está permitido, CONST es generalmente recomendado, y la mayoría de los parámetros son del tipo DS (estructura de datos - esto es un tipo distinto en RPG) y pasado por puntero. Los parámetros de nivel de módulo son desaprobados, si se prefiere encapsular todo en las estructuras de datos aprobadas o en los propios procedimientos del programa de servicio. STATIC tiene un uso algo diferente en Java, lo que hace que las variables sean globales, y no está disponible dentro de los procedimientos.
• RPG es bastante más simple que Java, en general, y OO-programming es un paradigma bastante diferente. Aquí hay algunas cosas que pueden hacer tropezar a los desarrolladores que migran a Java:
  1. matrices en RPG comienzan en 1. Las matrices en inicio de Java en 0.
  2. Java no tiene parámetros '' ouput, y todos los tipos primitivos se pasan por valor (copiados). Esto significa que la edición de un entero no será visible en los métodos de llamada.
  3. Java no tiene codificación empaquetada/firmada, por lo que traducir a/desde números/cadenas es más complicado. El tipo de fecha en Java también tiene algunos problemas serios (incluye tiempo, tipo de), y es mucho más difícil cambiar de manera significativa a/desde una representación de personaje.
  4. Es más difícil leer/escribir archivos en Java, incluso cuando se usa SQL (y olvidarse de usar E/S nativas directamente con Java); sin embargo, esto se puede mitigar con un buen marco de trabajo.
  5. No hay operadores ENDxx en Java, todo usa corchetes ({}) para especificar el inicio/final de los bloques.
  6. Todo en Java está en formato libre, y no hay especificaciones de columnas de ningún tipo (aunque todavía se requieren firmas de procedimientos). No existe un límite estricto en la longitud de la línea, aunque ~ 80 caracteres todavía se recomiendan. Las herramientas (gratis, incluso) son mejores, de período, y en general mucho más útiles (aunque puede llevar un tiempo acostumbrarse para las personas expuestas a SEU). También hay enormes bibliotecas gratuitas disponibles para descargar.
  7. El signo = no es sensible al contexto en Java como en RPG, es siempre utilizado para asignaciones. Use el operador double-equals, == para realizar comparaciones de valores en Java.
  8. Objetos (estructuras de datos) no se pueden comparar significativamente con == - a menudo tendrá que implementar un método llamado equals() en su lugar.
  9. Las cadenas no se pueden modificar, no se pueden modificar. Todas las operaciones realizadas en cadenas (ya sea en la clase/estructura de datos en sí, o desde bibliotecas externas) devuelven nuevas referencias. Y sí, las cadenas se consideran estructuras de datos, no son tipos de valores, por lo que tampoco se pueden comparar con ==.
  10. No hay equivalentes incorporados a las directivas de precompilador /copy. Intentar implementarlos es usar Java incorrectamente. Debido a que estos se usan generalmente para tratar con el código 'repetitivo' (definiciones de variable o código común), es mejor tratar esto en la arquitectura. Las definiciones de variables (TODAS las especificaciones D, en realidad) se manejarán con las declaraciones import o import static, mientras que las variantes de código común generalmente son manejadas por un marco, o definiendo una nueva clase.

Estoy seguro de que hay una serie de otras cosas por ahí, hágamelo saber si usted tiene cualquier otra pregunta.

Answer 2

Cuando IBM dice que debe pasar a Java/J2EE, probablemente debería mover sus aplicaciones a aplicaciones web como sus aplicaciones web asp.net. Probablemente deberías utilizar una interfaz rica en características como JSF o GWT.

Las aplicaciones web no tienen que preocuparse por los problemas de JRE ya que solo necesita un navegador estándar.

Sin embargo, no sé RPG y no conozco la estrategia de migración sugerida.

Answer 3

Distribuir y administrar un cliente gordo sería una auténtica pesadilla.

La solución ideal es una aplicación web basada en Java alojada en el iSeries. Las estaciones de trabajo acceden a sus aplicaciones a través de un navegador web como ASP.NET.

He estado utilizando el Grails Framework para modernizar y crear nuevas aplicaciones y está funcionando maravillosamente.

Answer 4

Soy un desarrollador involucrado en la modernización as400. Hasta ahora, a partir de mis experiencias, puedo darle mis ideas.

Además de los sitios web basados ​​en Java EE, probablemente pueda utilizar servicios web basados ​​en jax-ws, que brindan servicios para diferentes pantallas planas y de cuadrícula.

Los clientes pueden consumirlos en la tecnología que deseen. Hay algo de retraso, pero la usabilidad general es buena, como en las aplicaciones normales basadas en web.