Migración de RPG a Java en IBM iSeries

java-ee ibm-midrange (4)

Cuando IBM dice que debería 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 sé la estrategia de migración sugerida.

Nuestra compañía usa un 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 RPG a Java, incluso si solo los proyectos nuevos eran Java y los proyectos brownfield seguían siendo RPG?

Mi administración tiene miedo de que:

1) actualizar JRE en las estaciones de trabajo, especialmente los clientes ligeros, podría causar una pesadilla administrativa (nuestra empresa utiliza 80% de clientes ligeros y 20% de PC) y

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

3) Incompatibilidad entre los clientes de JRE a medida que actualizamos, potencialmente rompiendo otras aplicaciones que requieren el JRE.

¿Puedes 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?

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 iSeries. Las estaciones de trabajo acceden a sus aplicaciones a través de un navegador web como ASP.NET.

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

Mi compañía también está intentando migrar a Java desde RPG.

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.
Me han informado (arquitectos de la compañía) que la JVM en el sistema operativo iSeries 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).
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 con licencias empresariales; la mayoría tendrá opciones para permitir actualizaciones forzadas y remotas.

Algunas otras notas:

Debería poder pasar simplemente a .NET, aunque puede necesitar hardware / particiones diferentes 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 de la 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 tienden a 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 a archivos a la pantalla de visualización) estar en un archivo. Esto también hará que intentar envolver RPG para llamar de forma remota sea efectivamente imposible. SI has separado correctamente todo en los Programas de Servicio, deberías poder envolverlos (como el equivalente a una llamada a método nativo, casi) prolijamente. Desafortunadamente, no he visto nada aquí que no tienda a depender de 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 en iSeries efectivamente desaparece 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 usar incorrectamente), 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 se permite, CONST generalmente se recomienda y la mayoría de los parámetros son de tipo DS (estructura de datos: este 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 lo hace variable global, y no está disponible dentro de los procedimientos.
El RPG es bastante más simple que Java, en general, y OO-programming es un paradigma bastante diferente. Estas son algunas de las cosas que pueden hacer tropezar a los desarrolladores que migran a Java:
1. Las matrices en RPG comienzan en 1. Las matrices en Java comienzan en 0.
2. Java no tiene parámetros de ''salida'', 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 / from numbers / strings 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 (las gratuitas , 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 tal como está en RPG, siempre se usa para asignaciones. Use el operador double-equals, == para las comparaciones de valores en Java.
8. Los objetos (estructuras de datos) no se pueden comparar significativamente con == - a menudo necesitarás implementar un método llamado equals() .
9. Las cadenas no son mutables, no se pueden cambiar. 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 tipos de valores, por lo que tampoco se pueden comparar con == .
10. No hay equivalentes incorporados a las directivas de precompilación /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, de hecho) se manejarán con instrucciones import static import o import static , mientras que las variantes de código común generalmente se manejan mediante un marco o definiendo una nueva clase.

Estoy seguro de que hay muchas otras cosas, avíseme si tiene alguna otra pregunta.

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 los 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.